I try to combine properties of several classes. This is done by assigning a
space separated list of class definitions to an element. However, IE shows a
kind of preference when choosing the right property which I think is
probably wrong. Here's what it does:
If two classes are defined in a stylesheet providing the same property, and
if these two classes are assigned to one single element, the preference
which class's property is used is *not* set by the elements class definition
but by the sequence of class definitions in the stylesheet.
I think this takes away much flexibility. Any opinion?
Here's an example:
-----------------
..c1
{color: black;
}
..c2
{color: red;
}
-----------------
<span class="c1 c2">This is shown red.</span>
<span class="c2 c1">This is also shown red.</span>
-----------------
To my opionion it should be:
-----------------
<span class="c1 c2">This is shown red.</span>
<span class="c2 c1">This is shown black.</span>
-----------------
31  6773 
Axel Dahmen wrote: I try to combine properties of several classes. This is done by
assigning a space separated list of class definitions to an element.
However, IE shows a kind of preference when choosing the right
property which I think is probably wrong. Here's what it does:
IE is broken in regards to multiple classes assigned to a single
element!
--
Google Blogoscoped http://blog.outer-court.com
"Axel Dahmen" <No****@NoOneKnows.de> wrote: I try to combine properties of several classes. This is done by assigning a
space separated list of class definitions to an element. However, IE shows a
kind of preference when choosing the right property which I think is
probably wrong. Here's what it does:
If two classes are defined in a stylesheet providing the same property, and
if these two classes are assigned to one single element, the preference
which class's property is used is *not* set by the elements class definition
but by the sequence of class definitions in the stylesheet.
That's correct behaviour.
Check out http://www.w3.org/TR/CSS2/cascade.html#specificity
and http://www.w3.org/TR/html401/struct/...tml#adef-class
There's nothing there to imply that multiple classes specified for a
single element have anything other than equal specificity. Thus the
standard CSS specificity rules apply and the stylesheet determines
which applies.
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
Do you think it might be worth proposing such behaviour to the CSS group?
---------------------------
"Steve Pugh" <st***@pugh.net> schrieb im Newsbeitrag
news:40********************************@4ax.com... "Axel Dahmen" <No****@NoOneKnows.de> wrote:
I try to combine properties of several classes. This is done by assigning
aspace separated list of class definitions to an element. However, IE
shows akind of preference when choosing the right property which I think is
probably wrong. Here's what it does:
If two classes are defined in a stylesheet providing the same property,
andif these two classes are assigned to one single element, the preference
which class's property is used is *not* set by the elements class
definitionbut by the sequence of class definitions in the stylesheet.
That's correct behaviour.
Check out
http://www.w3.org/TR/CSS2/cascade.html#specificity
and
http://www.w3.org/TR/html401/struct/...tml#adef-class
There's nothing there to imply that multiple classes specified for a
single element have anything other than equal specificity. Thus the
standard CSS specificity rules apply and the stylesheet determines
which applies.
Steve
"Axel Dahmen" <No****@NoOneKnows.de> wrote: "Steve Pugh" <st***@pugh.net> schrieb im Newsbeitrag
news:40********************************@4ax.com.. . "Axel Dahmen" <No****@NoOneKnows.de> wrote:
If two classes are defined in a stylesheet providing the same property,
and if these two classes are assigned to one single element, the
preference which class's property is used is *not* set by the elements
class definition but by the sequence of class definitions in the stylesheet.
That's correct behaviour.
Check out
http://www.w3.org/TR/CSS2/cascade.html#specificity
and
http://www.w3.org/TR/html401/struct/...tml#adef-class
There's nothing there to imply that multiple classes specified for a
single element have anything other than equal specificity. Thus the
standard CSS specificity rules apply and the stylesheet determines
which applies.
Top posting fixed. Don't do it again.
Do you think it might be worth proposing such behaviour to the CSS group?
No. It would be tricky to combine with the current specificity rules
and would cause a number of existing pages to suddently change in
appearance when/if browsers supported it.
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
Philipp Lenssen wrote: I try to combine properties of several classes. This is done by
assigning a space separated list of class definitions to an element.
However, IE shows a kind of preference when choosing the right
property which I think is probably wrong. Here's what it does:
IE is broken in regards to multiple classes assigned to a single
element!
Which IE? There are many versions, on 2 platforms. FWIW, they seem
to work in MSIE 5.0/Win2k.
--
Brian
follow the directions in my address to email me
> Top posting fixed. Don't do it again.
??? Do you think it might be worth proposing such behaviour to the CSS group?
No. It would be tricky to combine with the current specificity rules
and would cause a number of existing pages to suddently change in
appearance when/if browsers supported it.
Hmmm... good news: There is no tricky part, it's simply "last serves first".
As multiple class references can only appear at one place (in the class
attribute), specificity rules don't apply. Anything more specific overrides
the class definition anyway.
BTW: Specificity rules have changed from CSS1 to CSS2 already. The new
definition would just put an undefined state into definition. As no one can
actually use this feature by now (is undefined behaviour), there are no web
pages to break.
*Axel Dahmen* <No****@NoOneKnows.de>:
If two classes are defined in a stylesheet providing the same property, and
if these two classes are assigned to one single element, the preference
which class's property is used is *not* set by the elements class definition
but by the sequence of class definitions in the stylesheet.
Correct, that's a matter of the cascade and specifity in CSS.
.c1 {color: black;}
.c2 {color: red;}
<span class="c1 c2">This is shown red.</span>
<span class="c2 c1">This is also shown red.</span>
Sure, a space separated list is a list of equals in HTML. Anything else is
the job of CSS.
Why do you give both classes on both elements anyway? There's surely a
better way in almost any situation you would want to do that.
--
The Hitchhiker's Guide to the Galaxy:
"The Universe, as has been observed before, is an unsettlingly big place,
a fact which for the sake of a quiet life most people tend to ignore."
"Axel Dahmen" <No****@NoOneKnows.de> wrote: BTW: Specificity rules have changed from CSS1 to CSS2 already.
Only in so far as that the CSS2 specs refer to things (attribute
selectors and pseudo-classes) that didn't exist in CSS1
CSS1:
To find the specificity,
count the number of ID attributes in the selector (a),
the number of CLASS attributes in the selector (b),
and the number of tag names in the selector (c).
Concatenating the three numbers (in a number system with a large base)
gives the specificity.
CSS2:
A selector's specificity is calculated as follows:
count the number of ID attributes in the selector (= a)
count the number of other attributes and pseudo-classes in the
selector (= b)
count the number of element names in the selector (= c)
ignore pseudo-elements.
Concatenating the three numbers a-b-c (in a number system with a large
base) gives the specificity.
Perhaps you're getting confused with the change in cascade order with
regards to !important styles?
The new
definition would just put an undefined state into definition.
It's not undefined at all. I gave you the definition earlier - the
standard CSS rules apply - if both classes are otherwise equal (i.e.
if the stylesheet has them as .foo and .bar and not as .foo and
p.bar) then the last specified takes precedence. What's not undefined
about that?
As no one can
actually use this feature by now (is undefined behaviour), there are no web
pages to break.
I use multiple classes on some of my web pages, so yes it would change
existing web sites.
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
Axel Dahmen / 2003-10-27 21:47: [Steve Pugh <st***@pugh.net> wrote:]
Do you think it might be worth proposing such behaviour to the CSS group?
No. It would be tricky to combine with the current specificity rules
and would cause a number of existing pages to suddently change in
appearance when/if browsers supported it.
Hmmm... good news: There is no tricky part, it's simply "last serves first".
As multiple class references can only appear at one place (in the class
attribute), specificity rules don't apply. Anything more specific overrides
the class definition anyway.
But the idea behind the classes is that those are used to define in
which class(es) an element belongs to. All classes are equal to each
other and element's "type" isn't defined by the order of those classes.
For example, if you have two elements inside a block level element
<div>
<a class="foo bar"></a>
<a class="bar foo"></a>
</div>
and you want to style those differently, then you must add a third
class to one of them to specify that that element is special.
I'm not sure about the history of this decision, but I'm pretty sure
that it has something to do with performance when it comes to
scripting. When a script modifies the class attribute or stylesheet,
it would be harder to take the order of classes into the
consideration when recalculating the specificity. It's not
impossible, but for the vanishing easier of use this behavior would
give to page author, it's not worth it.
If the order of class names in class attribute had any importance
the correct cascading order would be much harder to implement. Say
we have following style
..foo { font: bold italic serif; }
..bar { font: small sans-serif; }
* .foo { font-family: monotype; }
and the order of class names did matter, then how should the above
mentioned markup be rendered? How the style could be effectively
computed without scanning the whole stylesheet set when a script
added one extra rule?
BTW: Specificity rules have changed from CSS1 to CSS2 already. The new
definition would just put an undefined state into definition. As no one can
actually use this feature by now (is undefined behavior), there are no web
It's not undefined. The defination says that the order of class
names in class attribute doesn't make any difference.
--
Mikko
Steve,
you're writing about specifiers in CSS definitions - I'm not.
I'm talking about using more than one class specifier in an element's class
attribute. Precedence of these is not defined in the CSS specs.
----------------------------------------------------------
"Steve Pugh" <st***@pugh.net> schrieb im Newsbeitrag
news:6s********************************@4ax.com... "Axel Dahmen" <No****@NoOneKnows.de> wrote:
BTW: Specificity rules have changed from CSS1 to CSS2 already.
Only in so far as that the CSS2 specs refer to things (attribute
selectors and pseudo-classes) that didn't exist in CSS1
CSS1:
To find the specificity,
count the number of ID attributes in the selector (a),
the number of CLASS attributes in the selector (b),
and the number of tag names in the selector (c).
Concatenating the three numbers (in a number system with a large base)
gives the specificity.
CSS2:
A selector's specificity is calculated as follows:
count the number of ID attributes in the selector (= a)
count the number of other attributes and pseudo-classes in the
selector (= b)
count the number of element names in the selector (= c)
ignore pseudo-elements.
Concatenating the three numbers a-b-c (in a number system with a large
base) gives the specificity.
Perhaps you're getting confused with the change in cascade order with
regards to !important styles?
The new
definition would just put an undefined state into definition.
It's not undefined at all. I gave you the definition earlier - the
standard CSS rules apply - if both classes are otherwise equal (i.e.
if the stylesheet has them as .foo and .bar and not as .foo and
p.bar) then the last specified takes precedence. What's not undefined
about that?
As no one can
actually use this feature by now (is undefined behaviour), there are no
webpages to break.
I use multiple classes on some of my web pages, so yes it would change
existing web sites.
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
> >The new definition would just put an undefined state into definition.
It's not undefined at all. I gave you the definition earlier - the
standard CSS rules apply - if both classes are otherwise equal (i.e.
if the stylesheet has them as .foo and .bar and not as .foo and
p.bar) then the last specified takes precedence. What's not undefined
about that?
Have a look at http://www.w3.org/TR/CSS21/selector.html#q10. There you'll
see that it's undefined. [Well, only if I didn't read quicker than my eyes
can follow... :) ]
> and you want to style those differently, then you must add a third class to one of them to specify that that element is special.
No, not necessarily. Take a look at the quote I gave with my last recent
posting.
I'm not sure about the history of this decision, but I'm pretty sure
that it has something to do with performance when it comes to
scripting. When a script modifies the class attribute or stylesheet,
it would be harder to take the order of classes into the
consideration when recalculating the specificity. It's not
impossible, but for the vanishing easier of use this behavior would
give to page author, it's not worth it.
There is no performance issue. Actually, what a reading application does
right now is exactly what I suggest, except for ordered access of class
definitions when more than one are given to an element.
An, moreover, I actually *want* to exploit this precedence in scripting! I
want to set particular elements to a "disabled" style by adding the
..disabled class to them:
-- CSS file -------------------------------------------
..someElem
{color: ButtonText;
background-color: ButtonFace;
}
..disabled
{color: GrayText;
}
-- JavaScript file -------------------------------------------
if (someCtrl.value==null) someOtherCtrl.class+=" disabled";
Please refer to my last recent posting. What I want to do is to add a
"disabled" look to some distinct control types without always having to
create two classes for each state:
"myDef" and "myDefDisabled"
"myOtherDef" and "myOtherDefDisabled"
...
-------------------------------------
"Christoph Paeper" <cr*****@gmx.net> schrieb im Newsbeitrag
news:bn***********@ariadne.rz.tu-clausthal.de... *Axel Dahmen* <No****@NoOneKnows.de>:
If two classes are defined in a stylesheet providing the same property,
and if these two classes are assigned to one single element, the preference
which class's property is used is *not* set by the elements class
definition but by the sequence of class definitions in the stylesheet.
Correct, that's a matter of the cascade and specifity in CSS.
.c1 {color: black;}
.c2 {color: red;}
<span class="c1 c2">This is shown red.</span>
<span class="c2 c1">This is also shown red.</span>
Sure, a space separated list is a list of equals in HTML. Anything else is
the job of CSS.
Why do you give both classes on both elements anyway? There's surely a
better way in almost any situation you would want to do that.
--
The Hitchhiker's Guide to the Galaxy:
"The Universe, as has been observed before, is an unsettlingly big place,
a fact which for the sake of a quiet life most people tend to ignore."
In article Axel Dahmen wrote: Steve,
you're writing about specifiers in CSS definitions - I'm not.
Well, you should.
I'm talking about using more than one class specifier in an element's class
attribute. Precedence of these is not defined in the CSS specs.
It is. Using two or more classes in same element doesn't make any
difference as the order of classes don't have any meaning neither in HTML
spec, nor CSS spec.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Saapi lähettää meiliä, jos aihe ei liity ryhmään, tai on yksityinen
tjsp., mutta älä lähetä samaa viestiä meilitse ja ryhmään.
*Axel Dahmen* <NO*****@NoOneKnows.de>:
What I want to do is to add a "disabled" look to some distinct control
types without always having to create two classes for each state:
That doesn't explain why for you the order of the content of the class
attribute is important. !important exists.
"Christoph Paeper" <cr*****@gmx.net> schrieb im Newsbeitrag
Why do you top-post and full-quote?
F'up2 comp.infosystems. www.authoring.stylesheets
--
»Es ist schwer, die Wahrheit zu sagen,
wenn man gelernt hat, mit Freundlichkeit zu überleben.«
Peter Turrini
"Axel Dahmen" <NO*****@NoOneKnows.de> wrote: >The new
>definition would just put an undefined state into definition.
It's not undefined at all. I gave you the definition earlier - the
standard CSS rules apply - if both classes are otherwise equal (i.e.
if the stylesheet has them as .foo and .bar and not as .foo and
p.bar) then the last specified takes precedence. What's not undefined
about that?
Have a look at http://www.w3.org/TR/CSS21/selector.html#q10. There you'll
see that it's undefined.
Why would it be defined in the section on attribute selectors?
The rules you are looking for are on the next page: http://www.w3.org/TR/CSS21/cascade.html
"Finally, sort by order specified: if two rules have the same weight,
origin and specificity, the latter specified wins. Rules in imported
style sheets are considered to be before any rules in the style sheet
itself."
I'll repeat: "the latter specified wins"
Seems perfectly defined to me.
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
"Axel Dahmen" <NO*****@NoOneKnows.de> wrote: you're writing about specifiers in CSS definitions - I'm not.
I'm talking about using more than one class specifier in an element's class
attribute. Precedence of these is not defined in the CSS specs.
You're still top posting, and full-quoting. Do you want to be kill
filed?
In HTML each of the multiple classes has equal weight.
In CSS, the precedence of conflicting rules is given by weight
(!important or not), origin (user or author stylesheet, etc.) and
specicifity. If all of those are equal then it is given by the order
they rules appear in the stylesheet.
So which rule takes precedence is precisely defined.
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/> You're still top posting, and full-quoting. Do you want to be kill
filed?
That's up to you. Stop bugging me!
Well I think we're looking at a special case here. IMHO the definition you
referenced gives room for interpretation. Here's why:
If two class definitions are given at an element's attribute, actually *two*
distinct cascading searches must be performed, one for each class
identifier. This is necessary (and unavoidable) because each of the class
identifiers may address different attributes. Although the result of both is
a pointer into the cascading hierarchy, we're still looking at two distinct
cascading searches here.
The specification doesn't mention this case explicitly (i.e. how to *mix*
the result of *more than one* cascade search - it's talking about just *one
single* cascade search). Nonetheless it can still be interpreted your way
though, as I admit. However, since a) that case isn't defined in the specs
explicitly, b) it is easier to handle [and c) because it makes sense], I
suggest to add a new definition to the specs, defining that the precedence
of a result vector is defined by sequence.
--------------------------
"Steve Pugh" <st***@pugh.net> schrieb im Newsbeitrag
news:da********************************@4ax.com... "Axel Dahmen" <NO*****@NoOneKnows.de> wrote:
>The new
>definition would just put an undefined state into definition.
It's not undefined at all. I gave you the definition earlier - the
standard CSS rules apply - if both classes are otherwise equal (i.e.
if the stylesheet has them as .foo and .bar and not as .foo and
p.bar) then the last specified takes precedence. What's not undefined
about that?
Have a look at http://www.w3.org/TR/CSS21/selector.html#q10. There you'll
see that it's undefined.
Why would it be defined in the section on attribute selectors?
The rules you are looking for are on the next page:
http://www.w3.org/TR/CSS21/cascade.html
"Finally, sort by order specified: if two rules have the same weight,
origin and specificity, the latter specified wins. Rules in imported
style sheets are considered to be before any rules in the style sheet
itself."
I'll repeat: "the latter specified wins"
Seems perfectly defined to me.
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
> That doesn't explain why for you the order of the content of the class attribute is important. !important exists.
Well, !important may work for this particular task. However, it gives only
one level of precendence.
Imagine you are writing a CSS library (for which the @import rule is
perfectly suited). Now you want to provide a general design used for
particular states in your library. So you're probably going to define a
".disabled" class, a ".selected" class, a ".emphasized" class and so on...
After that you want to combine these classes with arbitrary elements in
regard to their current state. How are you going to do this?
If my suggestion would apply, you'd write general functions like:
function updateClass()
{
this.class=this.originalClassDef;
if (this.selected) this.class+=" selected";
if (this.disabled) this.class+=" disabled";
}
function setDisabled(newState)
{
this.disabled=newState;
updateClass();
}
"Axel Dahmen" <NO*****@NoOneKnows.de> wrote: Well I think we're looking at a special case here. IMHO the definition you
referenced gives room for interpretation. Here's why:
I'm sorry I'm having difficulty following what you're trying to say.
Maybe if you actually replied to specific parts of my post rather than
quoting the whole of it (including sig) after your post, it would be
clearer.
If two class definitions are given at an element's attribute, actually *two*
distinct cascading searches must be performed, one for each class
identifier.
And how is this is different to :
a class and an id?
a class and an element?
etc., etc.
Matching rules to elements always involves looking at ALL the styles
available to the document.
This is necessary (and unavoidable) because each of the class
identifiers may address different attributes.
You don't mean attribute do you? The only attribute in your example is
class. Do you mean property? If you do all I can say is so what?
Any number of different styles can apply to any element in a document.
Some of these may set the same property, some may set different
properties. This is the case for every element, every time. Having two
classes makes no difference here.
Although the result of both is
a pointer into the cascading hierarchy, we're still looking at two distinct
cascading searches here.
What is a cascade search anyway? I can't find the term in the CSS
specs and Google doesn't return anything relevant.
The specification doesn't mention this case explicitly (i.e. how to *mix*
the result of *more than one* cascade search - it's talking about just *one
single* cascade search).
Maybe because there's no such thing as a cascade search?
The CSS spec does give clear rules for deciding which styles apply to
which elements
Nonetheless it can still be interpreted your way though, as I admit.
It's the only interpretation.
However, since a) that case isn't defined in the specs
explicitly,
Why does it need to be? The general rules only allow for one correct
result. No need for special rules.
b) it is easier to handle
I beg to differ. The rules for determining which styles take precdence
should be in the CSS not the HTML. Separation of structure and
presentation, remember? You're proposing allowing HTML to override
CSS, that's a step back to the dark ages (aka the 1990s).
[and c) because it makes sense],
Why does it make sense?
Why should the order that classes are listed in the HTML imply a
preference?
To me it makes sense that
I
suggest to add a new definition to the specs, defining that the precedence
of a result vector is defined by sequence.
Go on, suggest it to the W3C. We're not stopping you. Knock yourself
out.
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
> >If two class definitions are given at an element's attribute, actually
*two* distinct cascading searches must be performed, one for each class
identifier.
And how is this is different to :
a class and an id?
a class and an element?
etc., etc.
I have the impression we're discussing about two different topics. I'll try
to distinguish mine from yours: Your argument above always involves two
different subjects of selectors. Each of your example above does. - I'm
talking about *one single* subjects of selector adressing more than one
selector. There is no definition inside CSS specs defining specificity
within one single subject of selector.
Matching rules to elements always involves looking at ALL the styles
available to the document.
So?
This is necessary (and unavoidable) because each of the class
identifiers may address different attributes.
You don't mean attribute do you? The only attribute in your example is
class. Do you mean property? If you do all I can say is so what?
Sorry, I've been using a colloquial expression here. Didn't want to refer to
the specs for particular expressions each uses for the same term. I'll try
to stick to the correct expressions from the specs now.
Any number of different styles can apply to any element in a document.
Some of these may set the same property, some may set different
properties. This is the case for every element, every time. Having two
classes makes no difference here.
I agree with you here. However, you didn't say anything about precedence in
this paragraph ;)
What is a cascade search anyway? I can't find the term in the CSS
specs and Google doesn't return anything relevant.
Please step back from the specs and start thinking... I've been trying to
explain a process here, using my own words. - I was not reciting the specs,
I was making a point. What I actually did was describing what happens when
an application tries to find a value for an element's property.
The CSS spec does give clear rules for deciding which styles apply to
which elements
Not in this case. You'll find nothing in the specs describing how to deal
with one single subject of selectors addressing more than one selector.
The rules for determining which styles take precdence
should be in the CSS not the HTML. Separation of structure and
presentation, remember? You're proposing allowing HTML to override
CSS, that's a step back to the dark ages (aka the 1990s).
While preparing my argument on this one, there was a moment where I stopped
and thought: Damn, there is a point in your argument and I've got to refrain
and step back... However, there is an argument on that:
In the end, the application of those rules always resides in the document.
By defining elements and attributes in the HTML, the HTML document defines
what kind of entity exists. By giving two selectors in one single class
attribute, still the HTML defines the entity and its properties. CSS has
been designed to give elements of a particular type and state (e.g. checked)
a particular look.
What you say, is that:
a) <element class="something checked">
- is equivalent to -
b) <element class="something" checked>
- is equivalent to -
c) <element checked class="something">
Both b) and c) are equivalent in the sense that the sequence of attributes
doesn't matter. If you'd transfer this to a) by saying "the sequence of
selectors *within* a subject of selectors doesn't matter", you'd be right.
This was the moment where I stumbled...
However, this is not the case. You'll not find any paragraph in any W3C spec
asserting this. I say that an attribute value of "something checked" is
different from "checked something".
And the specs should reflect this.
"Axel Dahmen" <NO*****@NoOneKnows.de> wrote: >If two class definitions are given at an element's attribute, actually*two* >distinct cascading searches must be performed, one for each class
>identifier.
And how is this is different to :
a class and an id?
a class and an element?
etc., etc.
I have the impression we're discussing about two different topics.
No, we're discussing the fact that class="foo bar" is covered by the
existing CSS rules, despit what you may think.
I'll try
to distinguish mine from yours: Your argument above always involves two
different subjects of selectors. Each of your example above does. - I'm
talking about *one single* subjects of selector adressing more than one
selector.
What is the "subject"? Do you mean the element?
Matching rules to elements always involves looking at ALL the styles
available to the document.
So?
So your argument that your case is somehow more complex is clearly
nonsensical.
What is a cascade search anyway? I can't find the term in the CSS
specs and Google doesn't return anything relevant.
Please step back from the specs and start thinking... I've been trying to
explain a process here, using my own words. - I was not reciting the specs,
I was making a point. What I actually did was describing what happens when
an application tries to find a value for an element's property.
You still haven't explained what a 'cascade search' is.
The CSS spec does give clear rules for deciding which styles apply to
which elements
Not in this case.
Yes in this case. You have two classes, therefore you have two sets of
rules. When those rules are in conflict then the process given in the
CSS spec for determining which one takes precdence is quite clear. Why
do you think it isn't?
You'll find nothing in the specs describing how to deal
with one single subject of selectors addressing more than one selector.
Again with the wacky terminology. How can a "selector address more
than one selector"? That's just gibberish.
A selector is something like
..foo
or
p.foo > .bar
or
div#foo:first-child
More than one selector can match a given element.
And CSS has rules for resolving conflicts when they do. You have been
told what those rules are that they are quite clear in determining
which style applies in your class="foo bar" example. You have also
seen that browser correctky apply those rules to your example.
So all you're left with is the fact that you think your way is better
and that the rules should be changed. As this would break existing
documents I don't think this is a good idea.
What you say, is that:
a) <element class="something checked">
- is equivalent to -
b) <element class="something" checked>
- is equivalent to -
c) <element checked class="something">
No.
What I say is that
<element class="something checked">
is equivalent to
<element class="checked something">
Nothing more and nothing less.
Your (b) and (c) are totally different as they use the checked
attribute rather than a classname checked. (b) and (c) are obviously
the same but (a) is quite different to them both.
Both b) and c) are equivalent in the sense that the sequence of attributes
doesn't matter.
Yes.
If you'd transfer this to a) by saying "the sequence of
selectors *within* a subject of selectors doesn't matter", you'd be right.
You're discussing apples and oranges here.
Comparing attributes to the values of attributes makes no sense. I'm
making no such comparison.
You'll not find any paragraph in any W3C spec
asserting this. I say that an attribute value of "something checked" is
different from "checked something".
And the specs should reflect this.
So I throw your challenge back at you. Find a single paragraph in any
W3C spec that says that the order that attribute values appear within
a space separated list makes any difference.
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
> What is the "subject"? Do you mean the element?
I'll reply tomorrow. Just for now: "subject of selectors" isn't my term. It
comes from the CSS spec. Have a look there.
"Axel Dahmen" <NO*****@NoOneKnows.de> wrote: What is the "subject"? Do you mean the element?
I'll reply tomorrow. Just for now: "subject of selectors" isn't my term. It
comes from the CSS spec. Have a look there.
http://www.w3.org/TR/CSS2/selector.html#subject
"The elements of the document tree that match a selector are called
subjects of the selector."
In other words, yes you do mean the element.
So when you said I'm talking about *one single* subjects of selector adressing more than
one selector.
You were talking about a seingle HTML element that is matched by
multiple selectors in the CSS. Big deal, that's the case the
overwhelming majority of the time. Your claim that your situation with
two class values is somehow more complex than other selector matches
is still completely bogus.
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
I agree and refrain.
by replacing following CSS rules:
----
.cls1
{prop: value1;
}
.cls2
{prop: value2;
}
----
with
----
*[class~="cls1"]
{prop: value1;
}
*[class~="cls2"]
{prop: value2;
}
----
I saw the precedence applicable.
qed.
Maybe. But it's OT, it's arrogant, it isn't helpful - and it's not worth any
more discussion.
---------------------
"Stan Brown" <th************@fastmail.fm> schrieb im Newsbeitrag
news:MP************************@news.odyssey.net.. . In article <bn**********@online.de> in
comp.infosystems.www.authoring.stylesheets, Axel Dahmen
<NO*****@NoOneKnows.de> wrote: You're still top posting, and full-quoting. Do you want to be kill
filed?
That's up to you. Stop bugging me!
That's pretty arrogant, from someone who _asked_ for help, and
_asked_ what was meant by top posting.
--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
2.1 changes: http://www.w3.org/TR/CSS21/changes.html
validator: http://jigsaw.w3.org/css-validator/
*Axel Dahmen* <NO*****@NoOneKnows.de>:
Imagine you are writing a CSS library (for which the @import rule is
perfectly suited). Now you want to provide a general design used for
particular states in your library.
I'm not sure I understand what you mean by "CSS library". Of course it would
consist of style rulesets, what else? And what "states"?
So you're probably going to define a ".disabled" class, a ".selected" class,
I'd use the appropriate attribute and apply styles with an attribute
selector.
a ".emphasized" class
I'd use the appropriate element and apply styles with an element selector.
and so on...
Yeah, maybe there are valid examples, let's pretend there were.
After that you want to combine these classes with arbitrary elements in
regard to their current state. How are you going to do this?
By using a scripting language to access the DOM probably, or, if available,
by using appropriate CSS pseudo-classes.
function updateClass() {
this.class=this.originalClassDef;
if (this.selected) this.class+=" selected";
if (this.disabled) this.class+=" disabled";
}
function setDisabled(newState) {
this.disabled=newState;
updateClass();
}
With this (pseudo) code you could get something like
class="foo bar selected disabled selected selected disabled selected
selected disabled"
I've not much knowledge about the DOMs, but I'm pretty sure there's a way to
set and remove classes that's not based on simple string manipulation
(.addClass() and .removeClass() probably). If not, you should at least test
whether the class is already set.
--
"The squeaking wheel doesn't always get the grease.
Sometimes it gets replaced."
Vic Gold This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: CheGueVerra |
last post by:
First of all Hello all you css freak. geeks and gurus. I just started using
css for some web pages I had to do at work and I'im testing some stuff at
home to understand more. Now, I wanted to...
|
by: Scott McChesney |
last post by:
I'm writing a Windows application for a client, and I've run into a problem
I don't know how to solve.
The UI is relatively simple - a listbox on the left (in a panel), and a
third-party tab...
|
by: Herb Stull |
last post by:
I'm trying to give users a choice of the visual interface used in my ASP.NET
application using Cascading Style Sheets.
Ideally I'd like to offer them several choices for backgrounds, fonts, etc....
|
by: Fred Nelson |
last post by:
Hi:
I have a VB.NET web application that has been running just fine for several
months without any cascading style sheets. Suddenly several users have had
problems with the layout of the...
|
by: Fred Nelson |
last post by:
Hi:
I have a VB.NET web application that has been running just fine for several
months without any cascading style sheets. Suddenly several users have had
problems with the layout of the...
|
by: tschwartz |
last post by:
I have an xml document in which elements are hierarchically related to
eachother conceptually. Unfortunately, the hierarchical relationship
is not modelled in the schema (i.e., the elements are...
|
by: Green Xenon [Radium] |
last post by:
Cascading Style Sheet is such a hazard to your privacy. It allows
others on the internet to see your monitor and files. It allows them to
copy images on your monitor to their computers. It also...
|
by: kcdoell |
last post by:
I have three tables:
One for the Division location:
tblDivision
DivisionID = Autonumber
DivisionName = Text
One for the Working Region:
tblWrkRegion
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
| |
