W3C home > Mailing lists > Public > www-style@w3.org > March 2000

Re: Specificity of HTML

From: L. David Baron <dbaron@fas.harvard.edu>
Date: Fri, 3 Mar 2000 13:33:02 -0500 (EST)
Message-Id: <200003031833.NAA23797@is03.fas.harvard.edu>
To: thelawnet@yahoo.com, www-style@w3.org
On Fri, 3 Mar 2000 10:22:47 -0800 (PST),
=?iso-8859-1?q?Matthew=20Brealey?= (thelawnet@yahoo.com) wrote:
> 
> <blockquote cite="http://www.w3.org/TR/REC-CSS2cascade.html#q12">
> 6.4.4 Precedence of non-CSS presentational hints
> The UA may choose to honor presentational hints from other sources than
> style sheets, for example the FONT element or the "align" attribute in
> HTML. If so, the non-CSS presentational hints must be translated to the
> corresponding CSS rules with specificity equal to zero. The rules are
> assumed to be at the start of the author style sheet and may be overridden
> by subsequent style sheet rules.
> </blockquote>
> 
> This is badly and dangerously wrong.

It's exactly right, as far as I can tell, even after reading your
message.  In fact, it's one of the most important parts of the CSS
spec.  The transition from presentation hints to CSS depends on
correct implementation of this section.

> The issue is not 'presentational hints' but presentational _attributes_.
> It is not 'for example the FONT element or the "align" attribute', but the
> attributes of FONT and the "align" attribute. The suggestion that FONT be
> mapped to CSS with specificity of 0 makes no sense at all.

Unless I'm misunderstanding you, you seem to be complaining here about
the language used in the paragraph, not what the paragraph means.

> The reason that this is wrong is because it is not possible to map
> elements to CSS at all because of the way that value assignment works:
> 
> 1. If the cascade results in a value, use it.
> 2. Otherwise, if the property is inherited, use the value of the parent
> element, generally the computed value.
> 3. Otherwise use the property's initial value. The initial value of each
> property is indicated in the property's definition.
> 
> So for the code fragment <P>An element with <font color=red>red</font>, we
> should have {color: red} with zero specificity, and since there aren't (we
> assume) any other assignments that apply to FONT, the result is red text.
> If we wanted to override that we could have FONT {color: inherit /* or any
> other colour */}. But what the spec says, which is that the FONT _element_
> should somehow be converted into CSS with specificity of zero doesn't work
> - it is not possible (because the cascade is used before inheritance, so
> to do give elements themselves specificity removes this important
> distinction) to give elements specificity, only the attributes of those
> elements.

The spec doesn't say anything about elements being converted to CSS
rules.  It says that the corresponding CSS rules should be created so
that the non-presentational hints can be incorporated into the CSS
formatting model rather than processed outside of the CSS model.  In
this case such a rule would be:

<selector matching only that font element> {
  color: red;
  }

The element is not removed from the tree, if that's what you're trying
to suggest.

> Unfortunately this error has already broken one browser (WebTV, which does
> precisely what this paragraph suggests, and so when you specify BODY
> {color: black}, because the FONT _element_ is given specificity of zero,
> <FONT color="xxx"> will be ignored), so I think it imperative that this be
> fixed before it breaks any more.

WebTV has implemented this part of the spec incorrectly.

Are you saying that "for example the FONT element" should be changed to
"for example the attributes of the FONT element"?  Or are you proposing
a significant change?

-David

L. David Baron    Sophomore, Harvard (Physics)    dbaron@fas.harvard.edu
Links, SatPix, CSS, etc.     <URL: http://www.fas.harvard.edu/~dbaron/ >
WSP CSS AC                      <URL: http://www.webstandards.org/css/ >
Received on Friday, 3 March 2000 13:34:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:04 GMT