[Seaside] CSS classes naming convention

[Dmitry Dorofeev]

On 18 Mar 2005, at 18:33, Avi Bryant wrote:
>
> 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>

Excellent !
Shame on me, seems i never red the HTML spec seriously!

>
> 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}

Now i red the spec and see that additional div is not even necessary.
From: http://www.w3.org/TR/REC-CSS2/selector.html#class-html

To match a subset of "class" values, each value must be preceded by a 
".", in any order.

For example, the following rule matches any P element whose "class" 
attribute has been assigned a list of space-separated values that 
includes "pastoral" and "marine":

P.pastoral.marine { color: green }

This rule matches when class="pastoral blue aqua marine" but does not 
match for class="pastoral blue".

  Note. CSS gives so much power to the "class" attribute, that authors 
could conceivably design their own "document language" based on 
elements with almost no associated presentation (such as DIV and SPAN 
in HTML) and assigning style information through the "class" attribute. 
Authors should avoid this practice since the structural elements of a 
document language often have recognized and accepted meanings and 
author-defined classes may not.
------------------------
So we may have
<div class="container WADateEntry skin-small">...</div>

Now I think that skins should apply to components directly, without 
'wrapping them into div from the parrent'.
I would love to be able to select skin in the root component of the 
Seaside application ( comp setSkin: 'skin-small' )
and it automagically propagate to all children of the root. Plus 
ability to change skin to different one
at some Component with option to not propagate new skin to children. In 
this way skins may be managed and presented
as list of options in Seaside Application config page. You could easily 
change skin for all application or particular
components this way.

Next idea is to have 'nested skins'. I.e. ability to change aspects of 
skin in a more precise way
-color-scheme
-size
-borders ?

So people may choose combination from these options and have something 
like this:
<div class="container WADateEntry color-scheme-desert size-small 
borders-rounded">...</div>

Probably we are close to the very generic management system of styles 
for Web Applications here....


>>
>
> 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}

That looks fine for me.


>
> 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.

That is really not trivial task. At least we have containers, 
navigation and components.
Probably 'button', 'entry' would be good part of classification as it 
is common to have forms and buttons
displayed in the same way across the site. 'menu' and 'menu-item' are 
also common things for navigation.

>  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?

I think we can start with minimal classification common for all and 
every Web site.

-Dmitry.