- From: Coises <Randy@Coises.com>
- Date: Tue, 20 Aug 2002 08:37:00 -0700
- To: www-style@w3.org
[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: http://www.coises.com/operabug/phints1.htm 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 implementation. 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 UTC