[Seaside] CSS classes naming convention

[Avi Bryant]

On Fri, 18 Mar 2005 18:07:40 +0300, Dmitry Dorofeev
<dima-sender-3c337a at yasp.com> wrote:

> All CSS class names should start with prefixes.
> 
> 1. For navigation related containers (menus, tabs, batched list pages links,  etc) prefix should be
> 'navigation-'
> 
> 2. For all over containers which provide different page layouts (tables, columns, listings of items, news etc)
> prefix should be 'container-'
> 
> 3. For all components that don't fit in previous two prefix should be 'component-'
> 
> ----------------------------
> 
> Prefix should be followed by class name of the component. Example: 'container-WADateEntry'

I wonder about using prefixes vs. multiple classes.  For example, if
instead we did

<div class="container WADateEntry">...</div>

Then we could have some css styles that applied to *all* containers,
and some specific to WADateEntry:

.container {border: solid 1px}
.WADateEntry {background-color: green}

It would also allow multiple categorization and thus a richer taxonomy:

<div class="container date input validated WADateEntry">...</div>


> There are options for customizeable 'skins':
> 1. If particular component have configurable options (say skins i.e. different styles)
> They should follow class name. Example: 'container-WADateEntry-small'
> <div class="container-WADateEntry-small">
> 
> 2. Use additional div element
> <div class="container-WADateEntry"><div class="small">...</div></div>
> 
> I still not sure what is better.

Hm, how are you picturing these skins being used?  Ie, how do you tell
it whether or not to output a particular class name?  For simple
skinning (where the CSS wants to change but the HTML doesn't need to),
it seems like you want to use an additional div element *around* the
component:

<div class="small"><div class="container WADateEntry">...</div></div>

That way the component itself doesn't even have to be told which skin
is active, and you can either add a decoration or just wrap the div
around it from the parent.  It also means that you can apply the skin
once at the top level of the page and it'll carry down to the rest of
the components.

To define a skin, just add that skin's class as a prefix to every CSS selector:

.small .container {border: dashed}
.small .WADateEntry {margin: 2px}

> I don't know if it good idea to follow naming convention for CSS classes inside component.
> Example:
> 
> <div class="container-WADateEntry">
>         <div class="header">Date selector</div>
> </div>
> 
> I think it would be easier for both designers and developers.

I think this is fine, as long as it's always in the context of the
component's class and all CSS defined for it is also defined within
that context.  And again, it allows for more cross-cutting definitions
- it's useful to be able to give a default and overrides:

.header {font-size: 24px} 
.WADateEntry .header {font-size: 18px}
.small .WADateEntry .header {font-size: 14px}

etc.

Now, here's a challenge: clearly we're going to have to come up with a
set of classifications for types of components, and types of parts of
components, and so on.   I'm a believer in the idea of "folksonomy",
which is to say, roughly, that I think the best thing is for these
categories to emerge by letting people choose whatever they want, but
making it easy for them to reuse the choices of others.  So, how do we
build a system where it's easier for me to reuse a CSS class that
you've already defined than for me to define a new one myself?

Avi