Re: CSS 2.1 WD and non-CSS presentational hints

[Wed, 28 Aug 2002 11:05:18 -0400] Stuart Ballard:
>There's no particular logic to this cascade ordering, but there isn't 
>any particular logic to the existing ordering either - except for the 
>logic of practicality, in that this ordering provides the behavior we want.
>
>Thus a snippet of a UA stylesheet might look like this:
>b { font-weight: bold !important }
>strong { font-weight: bold }
>i { font-style: italic !important }
>em { font-style: italic }

At this point, I'm confused: *why* is this the behavior we want?
How is it helpful that <B> and <STRONG> --- which are no different from the
standpoint of CSS, and probably little if at all different in most people's
understanding of HTML --- behave differently in a user style sheet?

CSS is not concerned with the "semantics" of the document language: only
its form.  It's seems to me illogical that CSS would treat <B> and <STRONG>
differently.  CSS doesn't care that <B> is presentational and <STRONG> is
purposeful.  On the other hand, <CENTER> and <DIV ALIGN="CENTER"> ---
though *HTML* may consider them equivalent --- appear completely different
to CSS.  I see no reason we should expect CSS to treat them the same (it
obviously doesn't, and can't, select them in the same way!).

The value of the CSS 2 cascade order over the proposed CSS 2.1 order is
connected with the typical *formalism* of "non-CSS presentational hints":
in particular, the fact that it is not always easy or even possible to
write rules to implement them (or to exclude them).  It has nothing to do
with whether they are "presentational" in terms of document language
semantics.  CSS doesn't care about document language semantics --- it's
only the formal and presentational characteristics that matter.  <B> and
<STRONG> *are* two cases of the same thing as far as CSS is concerned.


I'm beginning to think we're getting hung up on the *words*
"non-CSS presentational hint" --- let's try an experiment.

Let's see what happens if we invent a new term... say, "gruffle"...
and use it instead.  Now, we start with CSS2 section 6.4.4 (see
<http://www.w3.org/TR/REC-CSS2/cascade.html#q12>), slightly amended:

     6.4.4 Precedence of gruffle

     The UA may choose to honor gruffle, for example the FONT element or
     the "align" attribute in HTML.  If so, the gruffle 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.

What could "gruffle" be?

At this point in the standard, we are finishing the section on the cascade.
There's been a detailed explanation of how, once the CSS rules that apply
to a particular element in the document tree are found, they are
prioritized to yield (along with the inheritance and initial value rules)
a unique value for each property of each element.

Since gruffle has to be "translated to the corresponding CSS rules" it
appears that it is not defined in terms of CSS.  Corroborating this is the
fact that 6.4.4 states where in the cascade the effects of gruffle are to
be placed... and every possible source of CSS rules (author style sheets,
user style sheets, STYLE attributes and the user agent default style sheet)
has already been placed in the cascade.

It's also clear that gruffle must affect CSS properties --- otherwise, how
could it be "translated to the corresponding CSS rules" and what would be
the point of giving it a place in the cascade?  Finally, the examples ---
"the FONT element or the "align" attribute in HTML" --- tell us that we're
talking about something that appears in the document.

So, given those things that we can derive from the usage of gruffle, we
might construct a definition something like this:

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

(Sound familiar?  That's exactly how I derived my definition
of "non-CSS presentational hint.")


We now have two ways that a user agent can infer CSS properties from a
particular language feature: it can define the presentation of that feature
in the user agent default style sheet, or it can interpret it as gruffle.
(Author style sheets, user style sheets and the STYLE attribute may enhance
or override the inferred presentation; but the default presentation a user
agent applies to a language feature must either be treated as gruffle or be
defined in the user agent default style sheet --- and never both.)


Next we might ask whether the CSS standard should attempt to specify what
SHOULD (or even MUST) be given its default presentation by means of the
user agent default style sheet, and what is appropriately gruffle.

At <http://www.w3.org/TR/REC-CSS2/sample.html> the CSS 2 standard makes
some suggestions --- pretty reasonable ones, in my humble opinion; but it
does not say this is normative (which I also think is appropriate).

We can note something else: what *cannot* be expressed in a CSS rule (for
example, the FACE attribute of the <FONT> tag in HTML) *must* be gruffle.

Beyond this, we have two options: we can declare the choice of whether to
implement a particular feature of a particular document language as gruffle
or through the user agent default style sheet (provided it can be
represented in CSS as implemented by the user agent) to be the business of
the user agent, or we can attempt to specify how user agent implementations
should decide what is gruffle and what isn't.

I think user agent implementations can manage this for themselves; but were
I to suggest guidelines, they would be "formal" ones --- for example, that
the default presentation of unattributed elements should nearly always be
defined through the user agent default style sheet, and the presentational
effects of attributes should generally be implemented as gruffle.  (Why?
because element names can always be represented as simple selectors in a
CSS rule, so it's easy to write rules for them; and it's helpful if the
effects of the element rules are separated from the effects of attributes
applied to those rules.  By contrast, attributes have values: when these
cannot be enumerated --- either literally or as a practical matter --- it's
generally not be possible to represent the effect of the attribute as a CSS
style rule.  For consistency and ease of understanding by users who might
want to write a user style sheet, since some attributes must be gruffle,
it's probably best that all attributes are gruffle.)

I wouldn't suggest that whether the elements or attributes are "semantic"
or "presentational" in terms of the *document*language* should have
anything to do with how they are managed in CSS.
-- 
Randall Joseph Fellmy aka Randy@Coises.com

Received on Thursday, 29 August 2002 05:21:14 UTC