[Pro] Many Style sheets

Hi,

I’m enjoying the new FW6 Pro and it’s really nice to see the code a little less cluttered with inline styling.

I was a little sad to see that there are links to 3 different stylesheets, as well as nav styling in the head and some inline styling in the div that wraps the nav.

That’s styling in 5 different places. Is there any way to improve this and consolidate the css into fewer files?

I had hoped to use FW6 as a tool for laying out a web design then switching to hand coding to build the full site, but with so many places where styling is placed, it makes it less easy.

Here’s the code from my basic page:

Untitled

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

Hi Sly,

I presume the nav styles in the head come from the use of the CSS Menu action or similar? If so I’m not sure there’s much that can be done about it other than not using the action. Weaver wrote an action called (I think) Remove Inline Styles which was very useful and might be used to move the inline nav stuff though I don’t know if it’ll work with FW6. Even if it does it might still cause issues with the cascade order of the menu CSS, I can’t say for sure.

As for the other 'sheets, I believe it’s the compromise that was made to remove more of the inline styles in v6. It seems like a “rob Pete to pay Paul” situation. Again, I’m not sure there’s a way around it that would be acceptable for your needs. If there were an option that would prevent FW from adding the 'sheet references then it would be much easier for you to manually consolidate everything s you like.

Todd
http://xiiro.com


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

Hi Sly,

There is no urgent reason for style information to be consolidated into one
location. CSS by design allows for style code to exist anywhere within a
document or outside of it. The Cascade Order defines how style definitions
in all these locations interact in a fashion that is both predictable and
manageable.

Consolidation is promoted usually for cosmetic reasons, or as a matter of
practical access. FWP6 follows an acceptably logical path of layered CSS
implementation in terms of how they use external stylesheets.

Anytime CSS code occupies a single location, the structure of that code
must bear the entire burden of the cascade order and becomes, by necessity,
much more complex. Too complex for a system like FWP to reason through, I
think. However, the layered system it does employ is a logical and
practical step forward. A big step closer I think to the possibility of a
single stylesheet preference.


Ernie Simpson, aka The Big Erns

On Fri, May 3, 2013 at 8:19 AM, Sly email@hidden wrote:

Hi,

I’m enjoying the new FW6 Pro and it’s really nice to see the code a little
less cluttered with inline styling.

I was a little sad to see that there are links to 3 different stylesheets,
as well as nav styling in the head and some inline styling in the div that
wraps the nav.

That’s styling in 5 different places. Is there any way to improve this and
consolidate the css into fewer files?

I had hoped to use FW6 as a tool for laying out a web design then
switching to hand coding to build the full site, but with so many places
where styling is placed, it makes it less easy.

Here’s the code from my basic page:

Untitled
  • nav1
  • nav2
  • nav3

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

True, but if you’re someone who’s concerned about http requests then it does present a problem.

Todd
http://xiiro.com

There is no urgent reason for style information to be consolidated into one location.


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

True, but if you’re someone who’s concerned about http requests then it
does present a problem.

Wouldn’t moving all the style definitions into the html document resolve
that?


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

True, but if you’re someone who’s concerned about http requests then it
does present a problem.

Wouldn’t moving all the style definitions into the html document resolve
that?

I’m not sure I follow. Do you mean move everything into the head with no call(s) to external 'sheets?

Todd
http://xiiro.com


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

Thank you chaps.

Yes Todd, I think that’s what Ernie means and I suppose, in a crazy way, might be the best way to pull them all together, so I can then extract them into one css file and then begin to hand code the rest of the site.


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

In that case yes TBE, it would reduce the number of http requests since everything would ride along with html file request. But that also presents its own set of problems unless, like Sly, you’re just using that as a jumping off point for hand-coding in which case it’s a moot point.

This was fun, good question.

Todd
http://xiiro.com

Thank you chaps.

Yes Todd, I think that’s what Ernie means and I suppose, in a crazy way, might be the best way to pull them all together, so I can then extract them into one css file and then begin to hand code the rest of the site.


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

The other issue is that you cannot cache these elements separate from the page itself. In this case, the entire page would be one cache hit or miss, rather than there being the kind of page-to-page speedup that you get when you hit one page, cache a big master css or js file, and then see a really noticeable speedup on pages 2, 3, etc. because those elements don’t need to come over the wire again.

Walter

On May 3, 2013, at 12:25 PM, Todd wrote:

In that case yes TBE, it would reduce the number of http requests since everything would ride along with html file request. But that also presents its own set of problems unless, like Sly, you’re just using that as a jumping off point for hand-coding in which case it’s a moot point.

This was fun, good question.

Todd
http://xiiro.com

Thank you chaps.

Yes Todd, I think that’s what Ernie means and I suppose, in a crazy way, might be the best way to pull them all together, so I can then extract them into one css file and then begin to hand code the rest of the site.


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

I’m not really serious - moving all style codes into any one location
(internal or external) is extreme in my opinion.

By suggesting styles be all inline or all in the head (which in either case
is all in-document) I’m just pushing back on the notion that three external
style sheets somehow equates excessive server calls.

Still, what do I know.


Ernie Simpson

On Fri, May 3, 2013 at 3:09 PM, Todd email@hidden wrote:

True, but if you’re someone who’s concerned about http requests then it
does present a problem.

Wouldn’t moving all the style definitions into the html document resolve
that?

I’m not sure I follow. Do you mean move everything into the head with no
call(s) to external 'sheets?

Todd
http://xiiro.com


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

And that’s the thing, what’s excessive? If you listen to the hall monitors anything more than 1 CSS call is excessive. My point was that if such things do matter to someone then 3 calls might indeed be unacceptable … to them.

Todd
http://xiiro.com

I’m just pushing back on the notion that three external
style sheets somehow equates excessive server calls.


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

There are systems that can automate bringing all of the styles together into a single sheet, but as Todd pointed out, the kinds of things you would need to do to your CSS selectors to make the whole thing work. Here’s the issue as I see it, and this thought exercise may spur someone to an interim solution. (Maybe me, who knows.)

  1. If you make your CSS styles using IDs, as Freeway does (and this choice is based upon how the existing page structure is designed – inherited from version 1 all the way up – in Freeway) then you will need to police the IDs for duplication not on a page-by-page basis, but a site-wide basis.

  2. If #item1 on page1.html is different in any way from #item1 on page2.html, then you have to do something to namespace these two elements, like rename one to #item1_page2 or something equally ugly. Otherwise, the last version of #item1 in the CSS source order (assuming you just concatenated these stylesheets together into one massive sheet) would “win”, and all elements with that ID would look the same, even if that wasn’t what you designed.

  3. If you throw master pages into this mix, then you have to further balance the need for the master style to corral elements across many pages, while still allowing for local differences in those individual child pages.

Freeway encourages you to draw individual items on individual pages, and style those elements and their contents as you please in a visual manner. A hand-coder intent on reducing her total amount of work would create styles based on a hierarchy of styles, possibly based on classnames rather than IDs. Rather than generating near-duplicate style blocks over and over (essentially moving the inline style block out to an external file or the page head) there might be a class to make an element half the width of the page, another to set the font styles to make the text gray and sans-serif (but defer to other, closer selectors like the heading level or tag name to make the more specific decisions about font size or leading). These class-based styles would be stacked up so you might see something like <div class="sidebar half right">whatever</div> rather than <div id="item#42">whatever</div>.

An Action or a post-processor cannot possibly untwist designer intent out of the generated HTML. A major interface change would be needed in Freeway itself in order to allow a designer to make repeatable elements and tag them with these sorts of element styles (as separate from the kinds of font or tag styles that Freeway already lets you generate. Imagine if you could select an element and make a class-based style out of it, and then edit that style to make it more or less specific. Now further, imagine if you could create and apply multiple styles on an element and see the result in the design interface.

This is an unbelievably difficult thing to pull off when you don’t have the crutch of HTML. Freeway would have to create an analogue of HTML and CSS rather than what they currently do, which is to create a layout in a WYSIWYG view and then extrapolate HTML and CSS from that at publish time. They are not re-rendering HTML in real time, they save that for an output step, which can take a variable amount of time depending on the complexity of your design. If they were to create HTML in real time, or chop and puree the existing HTML as Dreamweaver and other WYSIWYG editors do, then the output quality would suffer. I have never seen a line of Freeway’s code, but I have a highly-evolved mental model of its inner workings. This is something I wish could be made, but I am not at all sure how or if it could be done.

Walter

On May 3, 2013, at 12:16 PM, Sly wrote:

Thank you chaps.

Yes Todd, I think that’s what Ernie means and I suppose, in a crazy way, might be the best way to pull them all together, so I can then extract them into one css file and then begin to hand code the rest of the site.


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