External Style Sheets leaves some lagging CSS in the head

Freeway
1

Morning one and all.

I’m using the latest version of Freeway 6 along with the ESS action and my own style sheet.

I have the document setup → output set to External Stylesheet and ESS is active and my style sheet is referenced and gets added as a link to the bottom of the head so i can over write any Freeway styles - perfect.

I have noticed in my current project that the css of the menu is being left in the head. I’m using the CSS menu action in this project to add the menu styles, and i believed that with External stylesheets checked, Freeway would extract this css and place it in its own stylesheets.

I have asked Softpress about this and they have suggested I ask here for suggestions. They think it is an issue with the ESS action.

Any suggestions would be appreciated, whether that be an alternative method or to correct something i’m doing wrong - more likely.

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

2

Hi Alan,

all I can say is:

Yes - recognized that, too. So as far as I can see, you don’t make sth. wrong and honestly I think there is nothing you could do. The clearfix action does btw. the same.

Is Anonymous doing something? If - you could collect the styles from head, putting them on another (manual) stylesheet linked properly and apply then Anonymous. But all is written without deeper thinking cause I’m currently anyway not “that happy” with all those stylesheet references within the FW page head (maybe a philosophical approach).

Cheers

Thomas

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

3

The CSS Menu Action does write its styles into the head, and there’s no way to change that at this time. I wrote some library code at the end of last year that will move the styles written by an Action out to a separate sheet, but this happened far too close to the release date of FW6, and so the naturally-conservative folks in Oxford didn’t use it. I hope that they actually make it redundant in future versions of Freeway, as what I had to do to step around Freeway’s publishing process was pretty heavy-handed. You’re not doing anything wrong here, that’s just how things work at the moment.

The ESS Action runs its “delete” clean-up at the very last callback in the publishing chain – there is nothing further I could do to remove those style tags. You might experiment with adding the ESS Action last – after you apply the CSS Menu – and see if that makes a difference, but I seriously doubt that it’s going to make any difference.

Walter

On Apr 10, 2013, at 7:12 AM, Alan Herbert wrote:

Morning one and all.

I’m using the latest version of Freeway 6 along with the ESS action and my own style sheet.

I have the document setup → output set to External Stylesheet and ESS is active and my style sheet is referenced and gets added as a link to the bottom of the head so i can over write any Freeway styles - perfect.

I have noticed in my current project that the css of the menu is being left in the head. I’m using the CSS menu action in this project to add the menu styles, and i believed that with External stylesheets checked, Freeway would extract this css and place it in its own stylesheets.

I have asked Softpress about this and they have suggested I ask here for suggestions. They think it is an issue with the ESS action.

Any suggestions would be appreciated, whether that be an alternative method or to correct something i’m doing wrong - more likely.

http://www.rmdecorsolutions.co.uk

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

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

4

Thomas, Walter - thanks for the responses.

I’m glad to know it’s not me. I assumed (and i’ve heard all the expressions that go with that word) that Freeway would just remove ALL CSS into external style sheets. I feel the more I’m learning about CSS and the cool things you can do with it, the tidier I want my pages to be, and that - for me anyway - means putting styles into a style sheet.

I could move those styles to an external sheet manually and remove the action, but i’d also have to add the list manually too as all the classes the action adds would also be removed - at least i imagine that’s what would happen.

The thing I like about using freeway is that I have a visual guide to my page whilst I’m creating/editing it and if I have to add lists back using markup / crowbar, then i’m kind of defeating the object and could just stay with Espresso.

I suppose if the OCD side of me wins, I could just add the styles to the external style sheet anyway, and then delete them from the final published page. More work but there’s only a dozen or so pages.

Thanks again for the feedback guys.

Al.

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

5

I was curious, so I just tried this in a test document (very briefly). I think there may be something to this order-of-actions issue after all, because I was able to hoover out the CSS Menu styles and publish them in an external sheet, then consume that in a separate page in the same site. Here’s what I did:

  1. Made a simple CSS Menu alone on a page.
  2. Duplicated that page, and applied the ESS Convert to Style Sheet Action to that page, using default settings. Renamed the file ‘menu.css’.
  3. Back on the first page, applied the ESS Use External Style Sheet Action, chose menu.css from the list of pages to use as a stylesheet, and published.

The head was blissfully free of all styles, the menu styles were all in their own sheet, linked into the head of the page, and that was that. I suspect that in your test, you applied the ESS Action to the page before you applied the CSS Menu Action. It is this order of operations that is the issue, as there is nothing more “last” than fwAfterEndHTML(). If both Actions use this callback to write their style code, then the race goes to the last Action on the page. ESS cannot remove a style block that CSS Menus adds after ESS has already run.

Walter

On Apr 10, 2013, at 9:11 AM, Alan Herbert wrote:

I’m glad to know it’s not me. I assumed (and i’ve heard all the expressions that go with that word) that Freeway would just remove ALL CSS into external style sheets. I feel the more I’m learning about CSS and the cool things you can do with it, the tidier I want my pages to be, and that - for me anyway - means putting styles into a style sheet.

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

6

Thanks for checking that out for me Walter.

I’ll give it a go later.

Kind regards

Al.

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

7

Walter, that worked a treat, thank you.

What I have done now is to set ESS to delete all the page styles and I’ve manually added those styles into my own stylesheet.

I’m happier using Espresso to manage/write my own styles - much easier to read through and make changes with syntax highlighting than a plain page. I’m not sure how bad multiple stylesheets are to a site, so i think keeping all the ‘extra’ stuff in one file seems better.

When ESS adds my custom stylesheet it does so with a pre HTML5 type link including type=“text/css” Is this ok on an HTML5 page?

Many thanks

Al.

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

8

HTML5 is remarkably forgiving, I don’t think an extra type= is going to hurt anything.

Walter

On Apr 11, 2013, at 7:33 AM, Alan Herbert wrote:

Walter, that worked a treat, thank you.

What I have done now is to set ESS to delete all the page styles and I’ve manually added those styles into my own stylesheet.

I’m happier using Espresso to manage/write my own styles - much easier to read through and make changes with syntax highlighting than a plain page. I’m not sure how bad multiple stylesheets are to a site, so i think keeping all the ‘extra’ stuff in one file seems better.

When ESS adds my custom stylesheet it does so with a pre HTML5 type link including type=“text/css” Is this ok on an HTML5 page?

Many thanks

Al.

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

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

9

Good to know Walter.

Cheers.

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

10

Multiple 'sheets are not bad, and are often useful and sometimes necessary, unless you’re talking about a crazy number. That said, it could be argued that fewer is better because it decreases the number of server requests and is generally considered good practice. But whether that actually matters to you or makes a noticeable performance difference for your site (or server) I can’t say.

If you use Yahoo’s YSlow browser plugin to check page performance it will always downgrade your score if you have multiple 'sheets but don’t take that as gospel.

Todd

I’m not sure how bad multiple stylesheets are to a site, so i think keeping all the ‘extra’ stuff in one file seems better.

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

11

Thanks Todd

Al.

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

12

Yeahh Todd,

… and spoken in WordPress terms (eg) you have indeed only one reference in the head (styles.css), but maybe ten different in the back for development and better overview (menu, framework, styles, snippets just to name a few) collected by @import “menu.css” and so on.

So the simple question (… cause we can’t influence this) is:

Why not think about this practice in Freeway?

Cheers

Thomas

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

13

I think it’s a great idea, certainly the sort of thing that can be automated. That fixes the whole problem with umpteen different sheets in the head when you start using masters. It doesn’t fix the issue of convoluted and over-specific styles, though.

Ideally, Freeway would rationalize its entire use of styles, and basically create a hash of styles in memory while the site is publishing, then generate a condensed single sheet at the end, after letting all the collisions and overrides work themselves out. I believe there is a part of WebKit (CSSKit?) that understands CSS the way a browser does. Maybe that could be leveraged somehow.

Walter

On Apr 11, 2013, at 10:50 AM, Thomas Kimmich wrote:

Why not think about this practice in Freeway?

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

14

If you’re referring to using @import then there’s a problem with IE7 which goes %@!$-up. I think IE8+ is fine.

Todd

I think it’s a great idea, certainly the sort of thing that can be automated.

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

15

Hmmm…

… spoken in SASS, the @import (better @include here) feature allows you to work on several different sheets which I totally like. So if I want to adjust something in a menu, and I created a menu.scss, simply open this file a play with it instead of opening the big styles.scss monolith where maybe somewhere in line 1258 is the menu entry.

But we are talking about PRE-Processing.

The final result is of course the one and only (even compressed) styles.css.

And that’s exactly my hope (and I hope that I understood Walter correctly) what could happen during the publishing of a Freeway-page. So in fact not an @import is somewhere part of a published page, everything happens one stage earlier. As a result, the master.css, styles.css and page.css are then all collected in a global.css.

But what about the stylesheets totally off Freeway?

Those little chunks that doesn’t live within a Freeway-page such as I build for WebYep or other CMSes or even fancy stuff that I prefer to play with it outside the Freeway shell?

So the question is @link or @import (as a special feature of the styles-palette which doesn’t exist yet)?

My personal attitude towards is:

If it is only a second sheet to include, I’d ever prefer the linked version. There are still browsers that don’t support @import so this would be the much safer way. But as long Freeway creates already 3-4 links and I have to add 1-2 more, I personally think that this is way too much.

I see Freeway (in contrast to their developers) not as a “one place isolated single soldier” work-station, but as a pretty cool tool to build a solid framework much quicker and purposeful. And honestly I got 5.5 so far to play nearby like that. With 6, I lost 75% of this flexibility (or I personally lost the overview - who knows).

Just another emotional one although I wanted to avoid this.

Cheers

Thomas

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

16

… spoken in SASS, the @import (better @include here) feature allows you to work on several different sheets which I totally like. So if I want to adjust something in a menu, and I created a menu.scss, simply open this file a play with it instead of opening the big styles.scss monolith where maybe somewhere in line 1258 is the menu entry.

I agree. Working with smaller files appeals to me too.

But we are talking about PRE-Processing.

The final result is of course the one and only (even compressed) styles.css.

Yep. I recently moved to Sass from LESS

And that’s exactly my hope (and I hope that I understood Walter correctly) what could happen during the publishing of a Freeway-page. So in fact not an @import is somewhere part of a published page, everything happens one stage earlier. As a result, the master.css, styles.css and page.css are then all collected in a global.css.

I suppose that would be the perfect solution, merging all those separate files into one.

Those little chunks that doesn’t live within a Freeway-page such as I build for WebYep or other CMSes or even fancy stuff that I prefer to play with it outside the Freeway shell?

So the question is @link or @import (as a special feature of the styles-palette which doesn’t exist yet)?

My personal attitude towards is:

If it is only a second sheet to include, I’d ever prefer the linked version. There are still browsers that don’t support @import so this would be the much safer way. But as long Freeway creates already 3-4 links and I have to add 1-2 more, I personally think that this is way too much.

I could be wrong about this but, if IE7 and below are the only browsers that don’t support @import then (for me and my site) that’s an acceptable trade-off as I get almost no IE7 traffic. But I know a lot of people still use it which would make @import a deal-breaker for others.

I suppose in the end the only truly safe option is to keep it all in one 'sheet. You could of course develop with multiple 'sheets and combine them all before going live. Not perfect but it is an option.

Todd

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

17

I think that this would fit into Freeway’s “generator” ethos anyway. The individual sheets are an interim step, not really important in the long run. Within reason, a single large stylesheet, even one which contains some overhead due to deep selectors (to avoid clashes between pages), will be cached once it loads and never requested again. Lots of little requests for unique files suffer the overhead of connection setup and teardown each time they are requested, even if there is a cache hit. Fewer total connections is a win, I believe, for most cases.

Walter

On Apr 12, 2013, at 11:08 AM, Todd wrote:

I suppose in the end the only truly safe option is to keep it all in one 'sheet. You could of course develop with multiple 'sheets and combine them all before going live. Not perfect but it is an option.

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

18

Walter, where do you stand on the @import debate in general (not just in the Freeway context)?

Todd

On Apr 12, 2013, at 10:16 AM, Walter Lee Davis email@hidden wrote:

I think that this would fit into Freeway’s “generator” ethos anyway. The individual sheets are an interim step, not really important in the long run. Within reason, a single large stylesheet, even one which contains some overhead due to deep selectors (to avoid clashes between pages), will be cached once it loads and never requested again. Lots of little requests for unique files suffer the overhead of connection setup and teardown each time they are requested, even if there is a cache hit. Fewer total connections is a win, I believe, for most cases.

Walter

On Apr 12, 2013, at 11:08 AM, Todd wrote:

I suppose in the end the only truly safe option is to keep it all in one 'sheet. You could of course develop with multiple 'sheets and combine them all before going live. Not perfect but it is an option.

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

19

I’ve never used it, but for no particular reason or another, just never have. I’ve seen it before, but I’m not clear what the benefits are. Is it for pipelining requests to avoid blocking?

Walter

On Apr 12, 2013, at 11:19 AM, Todd wrote:

Walter, where do you stand on the @import debate in general (not just in the Freeway context)?

Todd
http://xiiro.com

On Apr 12, 2013, at 10:16 AM, Walter Lee Davis email@hidden wrote:

I think that this would fit into Freeway’s “generator” ethos anyway. The individual sheets are an interim step, not really important in the long run. Within reason, a single large stylesheet, even one which contains some overhead due to deep selectors (to avoid clashes between pages), will be cached once it loads and never requested again. Lots of little requests for unique files suffer the overhead of connection setup and teardown each time they are requested, even if there is a cache hit. Fewer total connections is a win, I believe, for most cases.

Walter

On Apr 12, 2013, at 11:08 AM, Todd wrote:

I suppose in the end the only truly safe option is to keep it all in one 'sheet. You could of course develop with multiple 'sheets and combine them all before going live. Not perfect but it is an option.

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

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

20

I don’t know what you mean by pipelining requests. But the benefit, at least as far as I’m aware of, is that it allows for splitting a stylesheet into manageable chunks , e.g. reset, typography, positioning … whatever/however you like, then calling those individual 'sheets from within a parent css file. So instead of having calling all those files from the head with @link you’re only calling the parent file which in turn is calling the child files with @import. I don’t see how this reduces http requests (I don’t fully understand all that stuff) but for me the appeal lies in smaller css files to deal with, if I happen to be working with a couple thousand of lines of CSS or more.

Todd

I’ve never used it, but for no particular reason or another, just never have. I’ve seen it before, but I’m not clear what the benefits are. Is it for pipelining requests to avoid blocking?

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