Splitting css - color, layout, topography

Separating css properties/values

[nyteshade]

I'm finally at the last chapter of DOM scripting and it suggests separating a single n.css into three as listed in the subject line. No problem, I've got about a hundred pages in my domain and this action is reasonable plus I wager that there will be some ability to dynamically apply color themes down the road. However, how may I separate properties like:

text-shadow: 1px 1px 1px black;
-moz-box-shadow: 3px 3px 3px #888;
-webkit-box-shadow: 3px 3px 3px #888;
box-shadow: 3px 3px 3px #888;

I've not found a separate property for color for these, or should each just be listed in color.css? Thx!

[penders]

IMO I would have said they would all be part of your color.css. (topography = typography ?) text-shadow could be part of typography.css, but that's debatable.

However, I'd question whether it was a good idea to split your main CSS file into three? Three files means 3 HTTP requests which potentially slows things down. You could perhaps have 3 separate sections in the 1 CSS file? Or, if you wanted to have 3 physical files, combine these server-side and send a single combined file to the client?

But I think I'd only split the CSS up like this if I wanted to give separate control to another process. eg. the end user might want to change the colors. But I don't think this is always relevant? Just my opinion.

[nyteshade]

thx penders:

According to Jeremy Keith - author DOM scripting:

It isn't always easy to decide where to put certain style declarations. Fonts and sizes clearly belong in the typography.css file. But what about margins and padding? It's hard to say whether they are part of the layout or should be considered typographical information. Here [in his book] the padding information is in layout.css... Margins are applied in typography.css.

Also,

Three files means 3 HTTP requests which potentially slows things down.

Does your statement above still apply when:

@import url(color.css)
@import url(layout.css)
@import url(topography)

...are use, for example, in:

<link rel="stylesheet" type="text/css" href="styles/prime.css">

That is, does the @import occur server-side?

[penders]

The CSS is processed entirely by the browser, so @import will issue another HTTP request.

You would need to use PHP or some other server-side script to combine the files (and perhaps minify, gzip and cache it).

[nyteshade]

Yes, that was an uninformed question, mea culpa. Think I'll just separate them, make sure they work properly, then recombine them under prime.css in sections as you suggested.

You would need to use PHP or some other server-side script to combine the files (and perhaps minify, gzip and cache it).

DOM scripting refers to a minimizer process that I'll do once I've finished the final chapter. As for gzip and caching, that's more reading I've got ahead of me, thx!

[penders]

I'd be interested to hear other peoples views on splitting CSS into modules like this - even if it's just for development and combined later for deployment.

If, for example, you're developing a "menu". It could be more work to have to maintain 3 separate CSS files (or 3 separations... color, layout, etc.) for this 1 module? What about a "menu.css" and make it easier to transfer into other projects?

[nyteshade]

FYI:[stevesouders.com ]appears to have something to say about @import.

[alt131]

Hi penders, good question - and I too would be interested in others thoughts.

In the end I think it depends on workflow - splitting is often required to accommodate multiple workflows in large organisations with multiple teams/team members. Smaller shops will use pre-existing "libraries" for commonly related items like menus. Probably more like enhanced code snippets really, to save re-writing from scratch. Of course, what happens next is the interesting bit. Those who can't see any benefits of splitting css will drop mine them into the site css file and modify as required - while others won't - although i wil note that has led to people like Nichole Sullivan who speacialise in uuntangling the redundancy, duplication, over qualification and download implications.

Nyteshade, good spotting on the Souder article. Also note the date: 2009, and compare to Keith's book which is 2005. Actually it isn't that the coding community didn't know or care about download speed in 2005, it's just that ... well, I'm not really sure what happened around then <sigh>. Jeremy Keith is very well respected, and part of the group of people pushing for a much more accessible and efficient web, so hard to argue. But in terms of your original question I would note three things.
1. The css for a website of around 100 hundred pages should be small enough to keep in one file. If it's not, then I would look for redundancies, inefficiencies, and maybe too much over-qualified code causing it to bloat.

2. The system of organisation should be intuitive and have some relationship to something. Per the recommendations margin and padding are part of the box model. That's layout. I would never consider them to be part typography, and cannot imagine any logical reason to put the margins of the same element in a different file to the element's padding. I don't think humans (unless following Keiths book) would think to look for them in different files either, and user agents don't expect code to be written that way.

3. The flaw in that sort of approach (IMO) is that takes a micro-level focus on the code itself - the property/values (form) - it isn't looking at the macro level of what code does - style HTML elements (function).

Of course I'm fascinated by the micro-detail of css, but that's because I believe increased knowledge will make it easier to write clean, simple code that will deliver content to the user as efficiently as possible. That Keith's approach leads to trying to split a property that is not designed to be split, just so the values can be re-classified so they can then be written into completely different files when that does improve delivery to the end-user highlights the difference between focussing on the form of the code, not the function it is supposed to perform.

[nyteshade]

alt131, thanks for another thoughful response. Just so you know, I have the 2nd edition of Keith's DOM scripting, 2011; and I was kind of puzzled that he did not elaborate a bit more on @import. But not a problem, I've worked passed it.

Your comment:

...highlights the difference between focussing on the form of the code, not the function it is supposed to perform.

...gets to the heart of the question of splitting the css into separate files. Splitting the color may have some utility, but I was just sitting here staring at the rest of it thinking, why? It's sort of like normalizing a database to the nth level for the sake of 'form' only to denormalize it for performance.

So, underneath the 'color' section I put a comment line: Layout AND Topography. Works for me. Peace.

[nyteshade]

penders: #:4397153

Update on my sticky-mail request: I think I have a handle on the minify/gzip/php thing. I started with closure compiler as suggested by my book DOM Scripting, and it works just fine. No doubt I'll be back here with specific questions *when* I get stuck.

[edited by: alt131 at 11:39 pm (utc) on Jan 6, 2012]
[edit reason] Thread Tidy [/edit]

[lucy24]

I wouldn't break up the CSS at all unless there are clearly distinct pieces that are #1 very large (so that the extra request is outweighed by download time) and #2 aren't used by all files. If you have 1000 pages and 950 of them use both stylesheets, it's hardly worth the trouble.

In fact I tend to move in the opposite direction. Any given directory has its own stylesheet, but if a style is used only by one document, that stays within the document itself. The moment two documents use the same style, into the shared stylesheet it goes.

All of that is assuming the stylesheet itself is laid out in a way that makes it easy for you to find and edit individual pieces. That's a personal choice. Mine for example is groupled thematically: headers, paragraphs, tables, text modifiers (that is, things that are most likely to show up in a span). If you have one of those stylesheets that's jammed into a single line with not one speck of whitespace* anywhere, all bets are off. Besides, it's very annoying for site visitors who want to snoop into "How did they do that?" territory.


* The kind that requires moderatorial action when someone posts a sample ;)

[nyteshade]

lucy24, thank you for your input. For some of you code gods this stuff may seem, academic. But me, two years in to this http stuff and I'm still asking novice questions partly because I'm sitting at home in my jamjams and not in a production environment where I could just nudge an answer from a mentor. So,I read books. Some authors have their way of doing things... me, I work their examples and question everything and then come here for updates, confirmation et cetera. Thanks again.

[alt131]

Hi nyteshade, and thanks for the update. Plus the correction about the year of Keith's book (oddly it isn't mentioned on the book site and I found it quite hard to find.) However, 2011 means I am now officially perplexed by his decision to suggest this technique :)

I'm still asking novice questions partly because I'm sitting at home in my jamjams and not in a production environment where I could just nudge an answer from a mentor.

Ok, sans** the coding apparel I don't think your questions are novice ones - and that's because you are putting such effort into thinking about things. And remember the forum exists to ask questions. The WebmasterWorld mission statement is on the about [webmasterworld.com] page and I think the last sentence is important for the many members who are also working solo:

Think of us as part of your extended site development and process team.

Feel free to share these css gods. After yesterday's "duh" I think time to make a sacrifice to keep them happy ;) Anyone have spare goats/sacks of wheat/whatever keeps them happy?

** the information about
Edit reason:
Fairly critical clarification :)

[thesheep]

How to structure CSS is a very interesting topic.

I've found Jonathan Snook's site "Scalable and Modular Architecture for CSS" to have some very sound ideas for how to approach this (you can just Google "SMACSS" to find it).

In particular I like his ideas about using explicit sub-classing to minimise the depth of CSS rules, which seems unintuitive at first, if you're trying to reduce the amount of markup, but actually makes a lot of sense from the point of view of scalability and maintenance.

[nyteshade]

In reply to my own reply msg:4398456 above. Splitting the *.css file into color-layout-topography is a real nuisance to maintain. I thought it would be kool and add some accessibility but I see from w3.org WAI pages that needed changes can be made via the browser and I can live without the kool factor. I'm going back to the single css file, amen.

[penders]

...I see from w3.org WAI pages that needed changes can be made via the browser...

How do you mean? And what does this have to do with splitting CSS files?

[nyteshade]

My initial thought on splitting the CSS file was to offer a visitor theme options (kool factor); then came the practical idea that themes may be a way of providing accessability to visually impaired visitors; then came the thought of offerring choices in color contrast if, for instance, my original choice in colors put a strain on an individuals eyes (I have eye issues so these thoughts just naturally bubbled up).

Actually, I only split off the color rules into a different section of my prime CSS file in preparation to creating two files. One for color and the other for topography and layout per the book I recently completed, DOM scripting.

The most visable downside to this method IMHO is maintenance. Each time I encounter a problem with the presentation in a page as a result of CSS or if I want to change or remove a rule then I need to be sure to search for two possible rules in the CSS file, one for color the other for layout and topography. The benefit, for me and my admittedly small number of less than one hundred pages, is nominal, but I'm just guessing. Maybe webMasters with thousands of pages have a different view no doubt. Still, apart from whatever technical value the splitting may allow, the process of not being able to complete the CSS shorthand properties in one place and having to search for more than one rule for the same selector was becoming frustrating.

In my frustration I started looking for a better way(a way out without feeling guilty). So off to w3.org I went. Here [w3.org ] describes how a visitor can alter a web page. So I rationalized that instead of me deciding the theme or trying to make a determination on all the possible colors or contrasting attributes that may provide relief from eye strain, let the user decide (aka passing the buck).

I have not tested this, but I can see that IE [windows.microsoft.com ]
allows text and color changes and even allows user to add a user stylesheet.

[alt131]

Hi Nyteshade, thanks for a very interesting post. It may not seem productive given you circled back to the start, but it's been really interesting watching your thinking evolve, and I know you will have learned so much as well. It's about personal coding goals, but I really appreciate the importance you've given to accessibility, and I personally believe that a coder develops better coding practises if they start thinking about it from the beginning.

Regrettably the "gotcha" - as you identified - has been connecting splitting css files with increasing accessibility. There isn't a connection, and as we've discussed, splitting shouldn't really be necessary on such a small site. I think the splitting idea was further complicated by Keith's principles - I'm still a bit baffled by them, for all the reasons already given.

Changing styles for accessibility reasons is a different issue, and the css isn't split on a property/value basis as Keith was suggesting. The split is on the basis of the property/values you want to over-ride when a user selects a particular style/sheet. You've probably already figured this out, but it's not about putting the padding for an element in one file and the margins in another for organisational purposes. It's about identifying that (as an eg) you want very high contrast/large fonts, so you want nil back-ground images, a different font-colour and an increased font size.

Less about splitting the css at the property/value level, more about identifying the styles that need to be adjusted to achieve the desired outcome. (Form versus function again ;) ) Sure, you may need to adjust the margins/padding as well, but this isn't about organising them into different files, it's about over-riding the initial design.

I think its great you've figured users can (and frequently do) set their own browser preferences. A good reminder that style facilitates the delivery of content ;) Second, "best" practise to always keep in mind things like font-size, colour contrast ratios and the size of targets (like links etc) to achieve maximum accessibility - which frequently improves usability anyway.

Third, this is your own small site and you are interested in this, so I would encourage you to keep exploring providing basic assistance without trying to predict every user need. Things that will accomodate a wider range of issues, like a means to increase text-size. You might also investigate an "extreme" switch that strips out most of the layout leaving a very high contrast font/background and large fonts. Never a pretty design result, but covers a wide range of user needs and from a coding perspective, a good test of how well the content has been structured as well.

g* "style sheet switching" for different techniques - plus ideas of things to consider. And of course, back here with questions - or even just to keep us informed about this interesting progression.