W3C home > Mailing lists > Public > www-style@w3.org > August 2002

Re: CSS 2.1 WD and non-CSS presentational hints

From: Coises <Randy@Coises.com>
Date: Tue, 27 Aug 2002 18:02:21 -0700
To: www-style@w3.org
Message-ID: <c22omu8pe33gvcfhv06clobl1faeni1dek@4ax.com>

[Tue, 27 Aug 2002 12:01:39 -0400] fantasai:
>Coises wrote:
>> 
>> The presentation of <b> is specified using CSS... so it can't be a
>> "non-CSS presentational hint."
>
>Yes it can. The <b> by itself, without CSS rules, suggests (hints)
>"boldface". A <b> element should be boldface even in a non-CSS-
>enabled graphical browser such as NS 3. Therefore it is a non-CSS
>presentational hint. Whether the /implementation/ that acts on
>this hint uses CSS syntax or not is irrelevant.

I base my suggested definition on the context in which the term arises.
The standard describes how all CSS rules (including those in the user agent
default style sheet) are prioritized in the cascade; then it adds a note:
     http://www.w3.org/TR/REC-CSS2/cascade.html#q12
which explains how to incorporate "non-CSS presentational hints" into the
cascade.

If something is in the user agent default style sheet, it already has a
place in the cascade: surely it makes no sense to place it in the cascade
*again* as a "non-CSS presentational hint."


>http://www.w3.org/TR/html401/present/graphics.html#edef-CENTER :
>   | The CENTER element is exactly equivalent to specifying the
>   | DIV element with the align attribute set to "center". 
>
>If <center> and <div align=center> are exactly equal, exactly why
>don't they behave the same way?

Because that statement comes from the HTML standard, not the CSS standard.
In pure HTML, they do behave the same way.  The HTML standard doesn't go
into detail about the effects of CSS: it isn't a concern of that standard.


>> I then examined the questions of whether this definition was useful, and
>> what its implications might be for "interoperability."  The results are not
>> ideal, but I believe they would be workable.
>
>If the purpose of a workable standard is interoperability and if under
>your defintion any implementation can pick and choose what it determines
>to be a "non-CSS presentational hint", then the results are not workable.

As I see it, the objects of definition and standardization are getting
a bit confused here. My intent in proposing that definition is to make it
clear to what the term "non-CSS presentational hint" must refer.  It seems
to me that it *must* mean essentially what I've defined it to mean for the
existing statements in the standard to make sense.

The question of standardization is a separate one.  Based on how the term
is used --- as a way of placing these hints in the cascade --- I repeat:

    Standardizing what should qualify as "non-CSS presentational hints" is
    precisely equivalent to specifying which presentational implications of
    a document language should be implemented through a user style sheet.

My argument is that it would not be appropriate for a CSS standard to
attempt to define this.  A necessary limitation exists: what can't be
expressed in a style sheet in the relevant version of CSS can't be part of
the user agent default style sheet.  The "Sample style sheet for HTML 4.0"
found here:
     http://www.w3.org/TR/REC-CSS2/sample.html
gives us a good idea what sorts of things the authors of the standard *do*
expect to appear in a user agent default style sheet.  Within these two
outer boundaries, the rest is left up to the user agent.

I think it should stay that way; apparently, you do not.


I question the contention that the results are not workable.  First, we
should note that if the change in weight found in the presently proposed
standards for CSS 2.1 and CSS 3 is adopted, the choice to represent a given
element of the document language in the user agent default style sheet or
as a non-CSS presentational hint will have *no*effect*whatsoever*.
(While I disapprove of the proposed change, I cannot deny that this is an
attractive feature.  Were it not for the grossly negative effect on the
utility of user style sheets, I would say it was a compelling feature.)

So it's the behavior in CSS1 and CSS 2 (which is essentially identical)
with which we must be concerned.

*Only* the interaction between user style sheets and document language
features is affected by the choice to implement a document language feature
as a user agent default style sheet rule or a non-CSS presentational hint.
In the absence of a user style sheet, the presentation of documents is
entirely independent of this choice.  So there is no problem with the
interoperability of *documents* across different browsers: only with the
interoperability of user style sheets.  Need user style sheets be
browser-independent?  For that matter, can they be?

In any case, the standard might further state what SHOULD (or even MUST) be
implemented in each way --- not as a definition, just as a part of the
specification.  However, I doubt that is necessary or desirable to do so:
and it might be difficult to phrase this in a way that is precise, yet does
not make assumptions about the document language outside the scope of CSS.
-- 
Randall Joseph Fellmy aka Randy@Coises.com
Received on Tuesday, 27 August 2002 21:02:52 GMT

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