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, 20 Aug 2002 08:37:00 -0700
To: www-style@w3.org
Message-ID: <hae4muos09eak81gjeojtqv823dhpv7m2c@4ax.com>

[Tue, 20 Aug 2002 06:13:51 -0400] fantasai:
>Coises wrote:
>> In slightly different words: "If something in the document implies certain
>> values for one or more CSS properties, but the connection between the
>> document specification and the resultant CSS properties is not expressed in
>> CSS, that's a non-CSS presentational hint."  This seems reasonable to me.
>It doesn't to me because <b> should be considered a non-CSS presentational
>hint, and under your definition, it's not.

I disagree that <b> should be considered a non-CSS presentational hint.
The standard way to implement the presentation of <b> is through a
declaration in the user agent default style sheet.  The presentation of <b>
is specified using CSS... so it can't be a "non-CSS presentational hint."

I've place a page here:
that provides a simple test/demonstration.  In IE 6 for Windows, it can be
seen that <B> and <CENTER> are *not* "non-CSS presentational hints"...
while the attribute in <DIV ALIGN=CENTER> is.

The only browsers I have installed are IE 6 and Opera (the latter of which
screws up the CSS2 cascade implementation in such a way as to render its
results in this test unenlightening for our purposes).  It would be
interesting to know if other common browsers follow the IE 6 model.

>> Unfortunately, this definition does beg a new question: what SHOULD go in
>> the (real or virtual) user agent default style sheet, and what SHOULD be
>> treated as a "non-CSS presentational hint"?
>> I believe it will not be possible to define this in a CSS specification ---
>Wasn't this the question you were trying to answer?

In one sense, I suppose so; in another, no.

Specifically, L. David Baron wrote:

|| I've yet to see a good argument that CSS2.0 is interoperably
|| implementable, as written.  We need a much clearer definition of
|| "non-CSS presentational hint". 

As the term "non-CSS presentational hint" was at issue, I began by
suggesting a definition that appears to me to be clear and consistent,
without violating the "scope" of CSS (for example, without making reference
to specific document languages).  This definition does precisely determine
what is and what isn't a "non-CSS presentational hint" in any particular

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.

However, one might take "a much clearer definition" to be a request for
"a more definitive standard" rather than "an unambiguous definition."
In that sense my response has been, essentially, to argue that a definitive
standard is not possible within the framework of CSS.

>> At minimum, "non-CSS presentational hint" MUST include whatever affects CSS
>> properties but cannot be expressed in a style sheet.  For example, there is
>> no way to write a CSS 2 declaration that implements the BACKGROUND
>> attribute of the BODY tag in HTML; so that must be a non-CSS presentational
>> hint. 
>There's no way to write a CSS2 declaration, but what about CSS3? If you're
>giving a definition of non-CSS presenational hint, it should be a definition
>that doesn't need to change with every version of CSS.

The *definition* would not change.

If the user agent default style sheet changes in a particular
implementation, the status of specific language features
as non-CSS presentational hints in that implementation may change.

>> For example, a browser maker could choose to include:
>Which is exactly the problem David Baron is talking about. With your
>definition, what is and is not a presentational hint is determined
>by the browser's implementation, and thus is not predictable.

Would you agree that a particular matter of presentation cannot both be
defined by a user agent default style sheet rule *and* be treated as
a non-CSS presentational hint?  For example, that if <b> is considered
to be a non-CSS presentational hint, then it makes no sense to have
"b {font-weight: bold}" in the user agent default style sheet as well?

Would you agree that anything specified in the document which affects the
values of one or more CSS properties for one or more elements must be
accounted for in some way?  That if the effect of whatever-it-might-be on
CSS properties isn't derived from anything coded in the CSS language
(including possibly the user agent default style sheet), then it *must*be*
a non-CSS presentational hint?

Well, that's all my proposed definition says:  Take everything that affects
CSS properties.  Remove the things that derive their effect on CSS
properties from code that's written in CSS.  "Non-CSS presentational hints"
are whatever is left.

Now, that solves the problem of definition, but not of standardization;
however, it does cast the problem of standardization into a clearer light:

    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.

Do we want to do that in a CSS standard?  *Can* we do it in a CSS standard?
My thought is that such a thing should be presented, if at all, as part of
a document language standard, not as part of the CSS standard.  But (as I
explained in my previous post in this thread), I don't see this as
critical.  A general consensus seems to exist (at least for HTML); is it
really necessary to have user style sheets be entirely independent of the
browser?  (As different browsers have different user agent default style
sheets, it seems unlikely that they would be, even if they *could* be.)

The two other possible definitions mentioned:

  * any stylistic suggestion in the markup that is caused by the
    presence of an attribute rather than the presence of an element

  * any stylistic suggestion associated with markup that indicates
    a specific presentational effect

are actually not inconsistent (in intent) with my proposed definition.
Using my definition, either of these would simply be cast as a standard for
what things should *not* appear in a user agent default style sheet; using
either of these as a definition, what I've suggested would take the form of
the added observation (which, admittedly, isn't likely to be necessary)
that "the effect of non-CSS presentational hints should not be duplicated
by declarations in the user agent default style sheet."

To use the first definition/specification, we'd have to be careful to
exclude certain attributes, like ID, CLASS and STYLE.  And what about an
attribute like HREF on the A tag?  That attribute can cause a stylistic
suggestion, but we would normally expect to style it through style sheets.

The second definition/specification is better, but it doesn't seem to agree
at all well with current practice.

Both definitions, though, make (indirectly) a disturbing assumption about
the document language: that whatever does *not* meet the given criteria
(and has any effect on CSS properties at all) *can* be represented in the
user agent default style sheet.  It seems to me entirely possible that some
document language feature might not 1) be an attribute or 2) indicate a
*specific* presentation, but might have --- by conventional interpretation
of the document language --- effects on CSS properties which cannot be
expressed through CSS declarations.  In this case, we would have a dilemma:
the feature couldn't be defined in the user agent default style sheet
because (the relevant version of) CSS lacks the necessary power; it
couldn't be considered a non-CSS presentational hint because it either
isn't an attribute or doesn't indicate a specific presentation; and it
couldn't be omitted from the cascade entirely, because it affects CSS
properties (and thus its interaction with CSS must be defined).

Thus far, I haven't been able to think of a good example of the above.
(I'm sure one could be found using HTML and CSS1, but that might not be too
compelling, since CSS1 was pretty incomplete.  I don't know if an example
using CSS2 and any well-known current document languages exists.)
Randall Joseph Fellmy aka Randy@Coises.com
Received on Tuesday, 20 August 2002 11:37:32 GMT

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