>> Bloating the loaded CSS with all
>> available combinations seems a bit
> We wanted the whole thing to work from a
> single stylesheet, so that it reduces the
> complexity of implementing it. It also means
> that when changing styles, the change is
> instantaneous, as it was with the original
> But I can see what you mean - there could
> come a point of complexity where it would be
> too bulky to load all the styles at once. So
> putting aside a server-side solution [I’ll
> come back to that in a mo ..] how would you
> envisage it works? Say, the default
> stylesheet is loaded, then added to or
> replaced by the selection of new styles -
> essentially the same functionality, but new
> style sheets are requested on the fly
> instead of loaded in advance. Is that what
> you mean?
Just an overview :) my opinions stem from me implementing CSS/tableless layouts to all the projects from my employer. Some CSS can get ... semi huge (its hard to keep a grip on efficency in front end within a big team thats still learning (at least where i am now ;)).
CSS files should represent a look, or a style, or a base style for the site. It makes more sense to seperate them into multiple files so that a “feel” can be worked on in isolation, and you know that what you are working on will be less likely to effect any other styles.
>> Also, putting “containers” into
>> the markup would be better if it
>> was able to be done on the fly.
>> Keep markup clean.
> Okay .. so where do created containers go?
> Where in the page are they appended? That’s
> the whole point of having a static container
> - so that the created elements have
> somewhere to go.
Append them wherever you want. If you have a standard layout naming convention, append them inside your container where appropriate.
There may well be a “controls” area within your layout that would be appropriate, but I dont think it that adding specific “body switcher” control divs should occur.
Use the CSS to position/style it.
Its really fine lines I guess. I like clean markup. I want my content accessible for browsers that do and do not support features.
I like the idea of things being easily implemented, but things need to be extendable also. With front end development i try to use the same practices for big sites as I do with small. The workload is comparable, but it lets small sites grow to massive sites with less upgrade time.
I have to finish this post, im at work :)