Re: CSS 2.1 WD and non-CSS presentational hints

[Sun, 18 Aug 2002 15:27:59 -0700] Dylan Schiemann:
>After reading this thread, I think one important subtlety was missed or 
>not explained well enough.  That is that explicit presentational hints 
>provided through html will now be treated the same as all implicit html 
>presentational hints.

Both L. David Baron and Lars Knoll expressed appreciation for this effect
of the proposed change.

While I still think the disadvantages predominate, I agree that this could
be seen as an advantage.  On the other hand, the only rationale stated (by
Håkon Wium Lie) as a reason for the change on the working group's part was:

||  We changed this since we don't want to encourage the use of
||  presentational hints. It has been a goal of CSS to eradicate the use
||  of presentational attributes, and lowering their influence seems a
||  logical way of achieving this goal. 

and I maintain that this would be an inappropriate and ineffective way of
promoting that end.  "Lowering their influence" should not be taken at face
value, but must be translated into an understanding of how the change will
affect the relationship between different sources of presentational
specifications.  This change would create an illogical relationship between
non-!important user style sheet rules and presentational specifications in
the document: the relative priority would depend on whether document
presentational information was supplied as CSS rules or HTML attributes.
Why should the writer of a user style sheet know or care about that?

>For example, when you use the tag p for paragraphs, you are semantically 
>applying a definition of paragraphs.  Additionally, most user agents 
>give a default style of a margin of 1em on top and bottom.  p elements 
>have traditionally had their very own implicit presentational behavior.

Yes... in a CSS2-compliant browser, this is accomplished by means of
the user agent default style sheet.

>While a tag such as b has been used to style something bold, its 
>semantic meaning is really to emphasize a section of content, to make it 
>stand out in importance to the reader.  The semantic definition is that 
>the text inside a b tag is more important or emphasized than the 
>adjacent text not in a b tag.  Traditionally, user agents give b 
>elements a font-weight of 700.  Since the tag name suggests this 
>styling, I describe this as explicit presentational behavior

Here we'd best be careful about how we use our terms.

If you use the terms "implicit" and "explicit" in this way, then handling
of presentational information in CSS2 (or CSS 2.1/3 as proposed) does *not*
depend on whether it is "implicit" or "explicit."

Section 6.4.4 of the CSS 2 standard says:

||  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. 
||  Note. In a transition phase, this policy will make it easier for
||  stylistic attributes to coexist with style sheets.

from which, I think, we can derive a rough definition:

     A "non-CSS presentational hint" is information which is derived
     from the document and is translated into CSS properties by
     the user agent through some mechanism other than CSS style rules.

The presentational characteristics of the <B> element are normally defined
in a user agent default style sheet (as, for example, in the sample style
sheet at <>).  Hence, <B> is not
a "non-CSS presentational hint"  (since CSS --- in the user agent default
style sheet --- defines its presentation).  Note that the sample style
sheet includes only three attribute selectors (A[href] and two cases each
of [DIR="ltr"] and [DIR="rtl"]); we do not see, for example:
     P[ALIGN="left"]    {text-align: left}
     P[ALIGN="center"]  {text-align: center}
     P[ALIGN="right"]   {text-align: right}
     P[ALIGN="justify"] {text-align: justify}
so the ALIGN attribute will be treated as a "non-CSS presentational hint"
by a browser that emulates the suggested user agent default style sheet.

In practice, user agent default style sheets define the presentational
characteristics of tags (so they are not "non-CSS presentational hints");
presentational attributes (like <BODY TEXT=...>, <P ALIGN=...>, all the
<FONT> attributes) are not expressed in the user agent default style sheet,
and hence *are* "non-CSS presentational hints."

It is important to note that the effect of some presentational attributes
(generally those with an essentially infinite range of values, such as
<FONT FACE=...> or <BODY BACKGROUND=...>) *cannot* be represented by CSS 2
style rules.  (A particular instance can be translated into a style rule,
but the general method of translating many attributes into CSS properties
cannot be expressed in CSS 2.  There is no such syntax as:
     BODY[BACKGROUND] {background-image: url(attr(BACKGROUND))}
in CSS 2.  The practical simplification is that virtually *all*
presentational attributes are treated as non-CSS presentational hints.)

>When thought of in this context, it seems more consistent to move 
>presentational attributes to the user agent level because every html 
>element has a default style associated with it.  It equalizes the 
>signficance of implicit and explicit presentational hints from html.

While the terms "implicit" and "explicit" are dangerous (that is, easily
misunderstood or mis-applied) in this context, the principle is valid.  The
proposed change would make it irrelevant whether the browser implemented a
particular language element as a non-CSS presentational hint or through
rules in the user agent default style sheet: this would be an advantage.

>Likewise, I do not see a significant issue for user style sheets.  The 
>reason is that if someone were to define b {font-weight:normal;} in a 
>CSS2-compliant user style sheet, this would have had no effect in any 
>browser on the market...

You might want to test that statement.

It does have effect in both Internet Explorer and Opera... and both are
behaving according to the CSS2 specification in this particular case.

However, this would not be changed by the proposed CSS 2.1/3 specification.

>I don't see an obvious use case where setting a user 
>style sheet declaration under the CSS2 cascade order that would have 
>worked as expected before would not now do so

I thought I gave a clear example in the message that began this thread:

||  This change would make it impossible to set defaults in a user style sheet
||  that could be overridden by old-fashioned HTML.  For example, in CSS2,
||  a user can include this rule in a user style sheet:
||       BODY {color: navy; background: #FEC}
||  to make text appear, by default, in navy on a manilla background; a page
||  that specified either:
||       BODY {color: white; background: url(dark.png) black}
||  or:
||  would override this and be displayed with the indicated attributes.  The
||  suggested change would have the thoroughly unintuitive and illogical result
||  of making these two display differently: the first would follow the author
||  specifications, but the second would follow the user specifications.

Is there something about this that is not clear?

>because all declarations 
>would have had to include !important declarations to override them.

What purpose do you think declarations that are not marked !important
serve in a user style sheet?  Are they just an anomaly, never to be used?

>If a presentational html attribute is unspecified by the author, the user 
>agent style sheet will still usually present a default styling, so again 
>I see no issue with this change.

That is exactly my point... what does one do when one wishes
to change the *default* styling of an element from what is specified
in the user agent default style sheet without nullifying *explicit*
styling indicated in the document by HTML presentational attributes?

The proposed change would make this impossible.
Randall Joseph Fellmy aka

Received on Sunday, 18 August 2002 22:48:20 UTC