Re: Class Selectors Extension Proposals

Alberto Pacheco wrote:

>  Let be the following style sheet definition, eg "my_app_style.css"
> 
>     .x1 { a:i1; b:j1; c:k1; }
>     .x2 { a:i2; b:j1; c:k1; }
>     #x3 { a:i3; b:j2; c:k2; }
> 
>  Let be an HTML page:
> 
>     @import url(my_app_style.css);
>     ..
>     <span class="x1">    OK  :-) </span>
>     <span class="x2">    OK  :-) </span>
>     <span    id="x3">    OK  :-) </span>
>     <!--
>         Here, user realizes he/she needs a derivative x-class behavior
>         but he/she do not reuse any of them because he/she needs "a:i4"
>     -->
>     <span style="a:i4; b:j1; c:k1;"> Bad choice!! Human makes mistakes  :-O
> </span>
> 
> Is there a better CSS solution for this _user_requirement_? Let's see
> (please help me if I missing something):
> 
>  (1) With standard CSS:
>     <span class="x1" style="a:i4;"> Reuse x1 but change a to i4. STYLE has
> higher SPECIFICITY than CLASS selector </span>
> 
>  (2) With ECMA Script, ie JavaScript:
>     <span id="x3"> Reuse x3 and change an attribute value using JavaScript
> </span>
>     <script language="JavaScript"> x3.style.a="i4"; </script>
> 
>  (3) XML/XSLT/FOSI/DSSL: I feel it can be done but I ignore how to do it
> (please help/forgive me)
>     -- Other solution(s) --
> 
>  (4) With my proposal..  a little more "OO-like" as Manos said ;-)
> 
>     .x { a:i1; b:j1; c:k1; } /* Just define one x-class and reuse/extend it
> */
>     ..
>     <span class="x[a:i4]"> Reuse x definition but change a to i4 </span>
>     <span id="x[a:i5]"> Same for ID selectors: reuse x definition but change
> a to i5 </span>
> 

I fail to see anything that is impossible with the current models for class names and rule 
sets.  I would do as follows.

.x {
    a: i1;
    b: j1;
    c: k1;
    }
.x4 {
    a: i4;
    }

<span class="x x4">This element belongs to two classes, each addressed in the style 
sheet and given appropriate declarations.</span>

We have yet to find a use case that falls outside the ability of the current models.

-- 
Etan Wexler <mailto:ewexler@stickdog.com>

Received on Friday, 24 May 2002 21:25:35 UTC