How to modularize stylesheets (and avoid collisions)?

[kj]

I would like to break down my stylesheets into a modules library,
but I can't figure out how to solve the problem of avoiding namespace
collisions for CSS classnames. What's considered "best practice"
in this area?

TIA!

kj

--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.

[Saul]

Re: How to modularize stylesheets (and avoid collisions)?

kj wrote:

I would like to break down my stylesheets into a modules library,
but I can't figure out how to solve the problem of avoiding namespace
collisions for CSS classnames. What's considered "best practice"
in this area?

We use a single generalised style sheet to control the display of any
content appearing in our pure content-driven sites. Essentially this
means we have the idea of a virtualised page layout that means we can
customise any content to any style we wish just from CSS (we have
one-click template switching examples on the site). This means our CSS
style sheets are richer and bigger than normal, but the benefit is
complete flexibility. It also means we have standardised names for
items and areas on the page.

Our approach is to consider the page as a series of layers, rather than
as a series of linear text elements (this follows the box model pretty
readily)

For instance the main .pagelayout 'box' has boxs that divide the page
into key areas (header, leftcol, main, rightcol, bottom etc) as layers
'on top' of it. From here we then create sub-classes (eg headright,
headmain, headtop). If necessary we can also subselect elements below
this. To swap from one header style to another is just a case of
overwriting these styles which allows a library of styles to be built
up and used.

If we place what we call 'components' into the HTML (eg a gallery
object, a music player object etc), then these take their own styling
following a similar pattern and naming convention again thinking of
each as a layer on top of the containing box. Once again this means
that components can be styled with a range of different CSS, and by
separating things this way means we can mix and match stylesheets.


Saul

https://www.notanant.com

communities of websites

[AndrewF]

Re: How to modularize stylesheets (and avoid collisions)?

Hi KJ,

I'd support Saul's post above in terms of best practice. Generally when
we build stuff we initially just lay all the content out in some really
light structural HTML so we have the pieces we are dealing with and
then start splitting it up using some divs as logical sections, so you
often end up with a header which might contain branding and navigation
then you'll end up with a footer, mainbody etc.

Once we are past that point we'll look at reusable components that may
or may not be called in, maybe things like a promo area or a login to a
system etc. If you are using a CMS [and even if you aren't and are just
straight building with HTML] then then you can decide when you might
want to "split out" to use other CSS files as well.

To a certain extent it all comes down to style. There are those that
say your definitions should be on one line, some others prefer listed
downwards. I'm a big fan of having a base style sheet that contains 80%
of the site and the 20% that may need to be a bit more detailed is
dropped out to another file which is called in when you need it. I'm an
old school C++ programmer though and it makes your life a *lot* easier
to have one object in one file but this isn't necessary for everything.

I'd be interested to see how many different "general" ways of putting
things together there are?

We also always use CSS Signatures so that people can override our
stylesheets if they really want to... a couple of the designers I work
with have created some pretty cool mashups doing this as well...

Cheers
AndrewF

[dorayme]

Re: How to modularize stylesheets (and avoid collisions)?

In article <1165524044.774 615.3280@16g200 0cwy.googlegrou ps.com>,
"AndrewF" <andrew@transit ionkiteboarding .comwrote:

Hi KJ,
>
I'd support Saul's post above in terms of best practice.

Hi AndrewF,

Where is this "above"? Please quote some of the things you are
replying to.

--
dorayme