[Pro] Pro6 action issues?

Hi everyone,

Although I’m not an action developer, I’ve been seeing some issues that I wonder are conflicts or something. Let me try to explain.

I was working today on a simple file. I was trying to actually use the Master page so I was building my layout there then going to an instance page to check that it inherited the master stuff, and then previewing the instance page in the browser.

I can’t say exactly when, but at some point the layout began having problems and that is when I noticed that Freeway Pro 6.01 was leaving out some style code.

I first noticed it when I tried to use Tim Plumb’s Clearfix action. Applying the action to the Master (and thus the Instance) Page produced no result. Previously I had applied it in a 5.5 page and had gotten automatic results. So I tried applying it to specific items instead and while those items were written with the .clearfix class attribute, no clearfix style definitions were written.

Fed up with the whole Master page thing, I then severed links to Master and then began working on just the regular instance page. The Clearfix action still would not work page wise, but the item I applied it to took and the style code was written and okay. Good. Then when I needed to apply it a second time, I could not get it to take. Arrgh!

I don’t want anyone to think this is just a Clearfix thing – I had similar issues with Walter’s Remove Dimensions and ScriptyLightbox3 actions which seemed to cause Pro6 to write incomplete page code. Most functionality seems restored by removing then reapplying the action. But I also seemed to have instances where Pro6 would write style code with one of it’s new fancy class add-ons, but fail to put that class add-on in the page element…

It’s been a confusing day for me, plus I’ve a zillion emails asking for responsive stuff, so apologies if this is somewhat incoherent. I’ve not been able to reliably reproduce much of the problems - plus I’m not yet able to predict how this new version is going to write something so I’m still getting my bearings… in other words, don’t hesitate to ask for more clarity - I’ll provide what I can.

PS, if I’m the only one having problems with this stuff, then I will be super-embarrassed :slight_smile:


actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Hi Ernie,

just want to confirm - you’re not really alone, however couldn’t really detect a problem with the clearfix action (but honestly my example is much more basics then yours).

One of the major problems could be, that the former Freeway-code was more than quirky, cause it wrote the code everywhere. That parts that hadn’t been inline, one part went into the sheet1.css, the other part into the head-area.

Clearfix is now writing the code into the head-section while it was in 5.5 part of the stylesheet. I suppose other actions that are not working as expected doing pretty much the same. But while the sheet1.css is let’s say “everywhere available” - the head section is page-specific (and therefor maybe not entirely available).

But if I’m in here, a couple of words to 6:

Basically - I’m not the man of having issues to severally criticize a product. But honestly, the 5.5 already had (for me) all the so called “new features” - but way more into my control.

With 6 I lost a lot of that control which will me hesitate to switch in the near future (for production). For my screencasts I have to still figure out a strategy how to explain things.

Furthermore I lost my most important action and I hope the dev will find a way to bring it back.

The responsive stuff:

Me too :-), not tons but a few.

My major problem is currently on how to handle menus. I know - you do them out of action. CSS-menu is in the current version not really handy to do (out of the same reasons guessed above).

Could you spent a lil words on this, cause I think templates and native code is a bit like fire and ice.

Cheers

Thomas


actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Let me clarify by saying the file I have been working with today (and
having issues) I am not publishing external styles yet - they are all in
the head.

An example of Freeway strangeness would be adding the class f-ms to html
items, then writing the combined style code as #itemname.f-ms instead of
defining them separately. For part of the day, Pro6 failed to add the
f-ms class to some items, but then continued to write the item style
definition as #itemname.f-ms which as you guess made my head hurt very
much. But since it was only sometimes and I could not connect cause to
effect, who knows how the hell it happened. It’s okay at the moment.

Note to Softpress: If .f-ms is some standard bit like .f-lp, then it’s
my ever so humble but mad as fecking hell opinion that the you should NOT
combine the style definitions as you are doing. !!! Write it once
like you already do .f-lp then you don’t have to add it to the item style
definition in that weirdly wasteful way.

Where was I?

Thomas, you are right in that I do avoid using actions for a whole host of
things I can do more satisfyingly myself. Every time I see page code
produced by the css menu action, a part of me dies.


Ernie Simpson

On Fri, Feb 8, 2013 at 5:53 AM, Thomas Kimmich email@hidden wrote:

Hi Ernie,

just want to confirm - you’re not really alone, however couldn’t really
detect a problem with the clearfix action (but honestly my example is much
more basics then yours).

One of the major problems could be, that the former Freeway-code was more
than quirky, cause it wrote the code everywhere. That parts that hadn’t
been inline, one part went into the sheet1.css, the other part into the
head-area.

Clearfix is now writing the code into the head-section while it was in 5.5
part of the stylesheet. I suppose other actions that are not working as
expected doing pretty much the same. But while the sheet1.css is let’s say
“everywhere available” - the head section is page-specific (and therefor
maybe not entirely available).

But if I’m in here, a couple of words to 6:

Basically - I’m not the man of having issues to severally criticize a
product. But honestly, the 5.5 already had (for me) all the so called “new
features” - but way more into my control.

With 6 I lost a lot of that control which will me hesitate to switch in
the near future (for production). For my screencasts I have to still figure
out a strategy how to explain things.

Furthermore I lost my most important action and I hope the dev will find a
way to bring it back.

The responsive stuff:

Me too :-), not tons but a few.

My major problem is currently on how to handle menus. I know - you do them
out of action. CSS-menu is in the current version not really handy to do
(out of the same reasons guessed above).

Could you spent a lil words on this, cause I think templates and native
code is a bit like fire and ice.

Cheers

Thomas


actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options


actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Hi Ernie,
I can’t appear to reproduce these errors with the Action in Freeway 6.0.1. I’ve tried opening and using the sample document I put together for the Action originally in 5.5 (http://www.freewayactions.com/test/clearfix/) as well as recreating it from scratch in 6.0.1 and both appear to work as expected.

That is not to say I’ve had a easy time migrating some sites to Freeway 6. I spent several hours last night checking every page a rather large site and in the process found several things that I’ll be logging issues on later. I don’t know if they are bugs (I suspect they are issues with 6 opening 5.5 files) as some can’t be reproduced if I start afresh in Freeway 6.
Regards,
Tim.

FreewayStyle.com - Free Freeway templates and parts to download, use and explore - http://www.freewaystyle.com


actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Hey Tim, thanks for the reply.

Like I said, I’m not trying to focus on Clearfix - though I am having
problems with it. I’m having problems with an incoherent list of things
that I cannot make sense of.

The file I’m working with is built from scratch in Pro6 (6.01) and was not
updated from an older version.
http://cssway.thebigerns.com/products/pavlov-inline/

As part of my work, I duplicated a page within that document, and even
though the clearfix action could be seen as applied to the duplicated page
items, the still would not output with the clearfix class attribute.

This is the stuff that is driving me mad. Madder. Maddest.


Ernie Simpson

On Fri, Feb 8, 2013 at 8:15 AM, Tim Plumb email@hidden wrote:

Hi Ernie,
I can’t appear to reproduce these errors with the Action in Freeway 6.0.1.
I’ve tried opening and using the sample document I put together for the
Action originally in 5.5 (http://www.freewayactions.com/test/clearfix/)
as well as recreating it from scratch in 6.0.1 and both appear to work as
expected.

That is not to say I’ve had a easy time migrating some sites to Freeway 6.
I spent several hours last night checking every page a rather large site
and in the process found several things that I’ll be logging issues on
later. I don’t know if they are bugs (I suspect they are issues with 6
opening 5.5 files) as some can’t be reproduced if I start afresh in Freeway
6.
Regards,
Tim.

FreewayStyle.com - Free Freeway templates and parts to download, use and
explore - http://www.freewaystyle.com


actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options


actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Hi Ernie,

The f-ms class is used to target divs which are using styles generated by items on master pages. If the instance item has changed some settings from its master item, it will no longer output the f-ms class on the div because it is using a different style declaration with a selector that targets just the instance of that div on that particular page.

This is all related to the way Freeway 6 handles external master and page stylesheets. There is one bug which we are aware of that means if you have added a class to an item by using the Extended dialog, it will overwrite the f-ms class rather than adding to it. We will hopefully fix this soon.

Stewart


actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Hi Stewart, thanks for stepping forward to address this issue.

If I were writing style code for this, I would separate the definitions
like this:

  .f-ms { foo: bar; }
  #mypageitem { width: 100px; }
  #myotherpageitem { name: value; }
  #still-more-page-items { name: value; }

instead of the way you are writing it now in Pro6

  #mypageitem.f-ms { width: 100px; foo: bar; }
  #mypageitem.f-ms { width: 100px; foo: bar; }
  #myotherpageitem.f-ms { name: value; foo: bar; }
  #still-more-page-items.f-ms { name: value; foo: bar; }

(I know, I am presuming f-ms to have a property element when it’s only
function may be as a marker - let’s put that aside for a moment.)

It strikes me as horridly inefficient to write the code this way, unless
the properties/values of .f-ms change from item to item. Do they? If not,
then why are we writing this globby code?

Other style markers like .f-lp are not written this way. Is there some
logic I am missing?


Ernie Simpson

On Fri, Feb 8, 2013 at 9:22 AM, Stewart Fellows email@hiddenwrote:

Hi Ernie,

The f-ms class is used to target divs which are using styles generated by
items on master pages. If the instance item has changed some settings from
its master item, it will no longer output the f-ms class on the div because
it is using a different style declaration with a selector that targets just
the instance of that div on that particular page.

This is all related to the way Freeway 6 handles external master and page
stylesheets. There is one bug which we are aware of that means if you have
added a class to an item by using the Extended dialog, it will overwrite
the f-ms class rather than adding to it. We will hopefully fix this soon.

Stewart

_____________**
actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/**optionshttp://freewaytalk.net/person/options


actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Here’s some more library code documented:

http://actionsforge.com/articles/view/12-get-and-set-classname-attributes-in-freeway-6

These instructions should work in previous versions of Freeway as well, although I have not tested back beyond FW 5.5.

Walter

On Feb 8, 2013, at 8:15 AM, Tim Plumb wrote:

Hi Ernie,
I can’t appear to reproduce these errors with the Action in Freeway 6.0.1. I’ve tried opening and using the sample document I put together for the Action originally in 5.5 (http://www.freewayactions.com/test/clearfix/) as well as recreating it from scratch in 6.0.1 and both appear to work as expected.

That is not to say I’ve had a easy time migrating some sites to Freeway 6. I spent several hours last night checking every page a rather large site and in the process found several things that I’ll be logging issues on later. I don’t know if they are bugs (I suspect they are issues with 6 opening 5.5 files) as some can’t be reproduced if I start afresh in Freeway 6.
Regards,
Tim.

FreewayStyle.com - Free Freeway templates and parts to download, use and explore - http://www.freewaystyle.com


actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options


actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Hi Ernie,

f-lp is a class that is simply used to deal with a specific situation where we want to remove margins from the last paragraph of text so that if the div has an undefined height, it will be snug to the bottom of the text, as it is in Freeway. The style declaration for f-lp is always the same.

f-ms is something of a different beast. By using f-ms as a class on divs that have been generated from master items, it allows Freeway to remove this class from instance items whose settings have changed from the master item without having to reset any CSS properties that are irrelevant for the instance item.

While your example is reasonable, an example of why Freeway is doing this is:

Master page/stylesheet:

#m1.f-ms { position:absolute; left:117px; top:73px; width:406px; min-height:181px; z-index:1; background-image:url(…/Resources/cts_bw_v2.jpeg) }

Instance page 1/stylesheet (item has had background-image set to none):

#m1 { position:absolute; left:117px; top:73px; width:406px; min-height:181px; z-index:1 }

Instance page 2/stylesheet (item uses all the settings of the master item):
// No style declaration necessary

This is as opposed to having to reset the background-image property to none. This example is not ideal as background-image is reliable to reset, whereas other properties can be troublesome to reset reliably. It also allows the same name/id to be used for the div on the instance page. Removing the class allows Freeway to have free reign over the styling of the div without having to deal with attributes it may be getting from a simple id selector for the master style.

We do have intentions to finesse the output in this area - Freeway is trying to manage this in as reliable and consistent a way as possible in the output, but there will be improvements possible. An example would be not outputting f-ms when external stylesheets are off.

Stewart


actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Stewart, thanks for the very cogent reply.

So, f-ms is a class added to identify that item as associated with a
master item, and separate it from same-name items whose link to the master
are broken and whose attributes and values are different… is that right?
Like in

  #mybox.f-ms { foo: bar; }  <-- style of #mybox instances that use

attributes/values from master items
#mybox { otherfoo: otherbar; } ← style of #mybox instances that
break/differ from master items

I get that it must be a complicated process to sort out differences like
this.

While I don’t know what programmers can achieve with the code framework, I
can envision a different process for this.

Freeway Pro has long used a familiar mechanism for preserving the
uniqueness if id names. When you duplicate an item in FWP, the name is
appended… #mybox becomes #mybox1 and so on.

If that same logic were applied to master and instance item styling, then
it should produce cleaner code. For example, every instance of #mybox
that matches the master item #mybox would only need to have its style
code written once in any style location - #mybox { foo: bar; }

When an instance item is changed from the master item, breaking its link
should rename the instance item in the same way duplicating it would, e.g.,
#mybox1 – and would then have its style code written as #mybox1 { foo: bar; }

So, several pages based on the same master but each with this one item
“disconnected” from it’s master version, under this model would produce
style code that looks like this:

  #mybox { foo: bar; }  <-- style for the master item and all instance

items which remain identical to the master item
#mybox1 { foo: bar; } ← style for the instance item which has been
altered or unlinked from its master item
#mybox1a { foo: bar; } ← style for another instance item which has
been altered or unlinked from its master item
#mybox1a1 { foo: bar; } ← style for yet another instance item
which has been altered or unlinked from its master item
#mybox1a1a { foo: bar; } ← and so on

What Pro6 would have to accomplish to do this is to

  1. make sure that all id names on a single instance or master page are all
    unique within that page,

  2. make sure that all id names on all master pages are unique from all
    other id names on all the master pages,

  3. make sure that all id names of instance items which are linked to master
    items match the id names of their master items,

  4. make sure that all id names of all instance items which have been
    un-linked from their master items are appended and unique from one another.

This is just coming off the top of my head, so I imagine there are holes to
poke in it – what does anyone else think?


Ernie Simpson

On Fri, Feb 8, 2013 at 10:50 AM, Stewart Fellows email@hiddenwrote:

Hi Ernie,

f-lp is a class that is simply used to deal with a specific situation
where we want to remove margins from the last paragraph of text so that if
the div has an undefined height, it will be snug to the bottom of the text,
as it is in Freeway. The style declaration for f-lp is always the same.

f-ms is something of a different beast. By using f-ms as a class on divs
that have been generated from master items, it allows Freeway to remove
this class from instance items whose settings have changed from the master
item without having to reset any CSS properties that are irrelevant for the
instance item.

While your example is reasonable, an example of why Freeway is doing this
is:

Master page/stylesheet:

#m1.f-ms { position:absolute; left:117px; top:73px; width:406px;
min-height:181px; z-index:1; background-image:url(…/**Resources/cts_bw_v2.jpeg)
}

Instance page 1/stylesheet (item has had background-image set to none):

#m1 { position:absolute; left:117px; top:73px; width:406px;
min-height:181px; z-index:1 }

Instance page 2/stylesheet (item uses all the settings of the master item):
// No style declaration necessary

This is as opposed to having to reset the background-image property to
none. This example is not ideal as background-image is reliable to reset,
whereas other properties can be troublesome to reset reliably. It also
allows the same name/id to be used for the div on the instance page.
Removing the class allows Freeway to have free reign over the styling of
the div without having to deal with attributes it may be getting from a
simple id selector for the master style.

We do have intentions to finesse the output in this area - Freeway is
trying to manage this in as reliable and consistent a way as possible in
the output, but there will be improvements possible. An example would be
not outputting f-ms when external stylesheets are off.

Stewart

_____________**
actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/**optionshttp://freewaytalk.net/person/options


actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

I would follow the same process used in my css override tools – just write the same tag rule in both the master and the instance sheet. Because the master sheet is linked first in the head, any rules defined in it will be overridden by the same-name rule in the instance sheet. That’s how I worked things out for this library and example: style_accessors.fwaction.library.js · GitHub

Walter

On Feb 8, 2013, at 12:16 PM, Ernie Simpson wrote:

This is just coming off the top of my head, so I imagine there are holes to
poke in it – what does anyone else think?


actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

That makes good sense Walter, and satisfies my code aesthetics!


Ernie Simpson

On Fri, Feb 8, 2013 at 12:23 PM, Walter Lee Davis email@hiddenwrote:

I would follow the same process used in my css override tools – just
write the same tag rule in both the master and the instance sheet. Because
the master sheet is linked first in the head, any rules defined in it will
be overridden by the same-name rule in the instance sheet. That’s how I
worked things out for this library and example:
style_accessors.fwaction.library.js · GitHub

Walter

On Feb 8, 2013, at 12:16 PM, Ernie Simpson wrote:

This is just coming off the top of my head, so I imagine there are holes
to
poke in it – what does anyone else think?


actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Hi Ernie,

If that same logic were applied to master and instance item styling, then
it should produce cleaner code. For example, every instance of #mybox
that matches the master item #mybox would only need to have its style
code written once in any style location - #mybox { foo: bar; }

When an instance item is changed from the master item, breaking its link
should rename the instance item in the same way duplicating it would, e.g.,
#mybox1 – and would then have its style code written as #mybox1 { foo: bar; }

That’s actually how Freeway 6 worked during most of its development.

The problem we found (during beta testing) was that some users were targeting IDs via tag styles - and their pages got broken when the names were changed.

Jeremy


actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

On Fri, Feb 8, 2013 at 2:17 PM, Jeremy Hughes email@hidden wrote:

The problem we found (during beta testing) was that some users were
targeting IDs via tag styles - and their pages got broken when the names
were changed.

No doubt this is a difficult issue, worthy of some real thought. Like many
long-time users, I have grown used to going to the Style Editor to target
html item styles by their id attribute. However, as I’ve started working
with Pro6 I find this is a less reasonable workflow - for html items at
least. Since Pro6 now “scoops” up an item’s extended inline styles and
rolls them in with the auto-generated code, I think it makes more sense to
target item id’s at the item itself. At that point then it makes better
sense to bring the Style Editor interface to the item>Extended dialog
instead.


actionsdev mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options