Re: [CSS21] response to issue 115 (and 44)

* Bert Bos wrote:
>CSS WG response:
>[...]

I object to these (IMO substantive) changes and probably a number of
other decisions. I am not sure which issue numbers they have exactly
hence my more general comments.

The CSS document representation is something each and every participant
in the CSS community needs to handle properly, authors, implementers,
evangelists, and it is thus crucial that rules and recommendations in
this regard are well-defined, understood and implemented. We know from
implementation and authoring experience that the CSS 2.0 Recommendation
was of little or no help to achieve this and I think that CSS 2.1 is
about to make things much worse.

I in particular object to the following:

  * deferring any decision or change in this regard to the upcoming
    css3-syntax specification.

We already have different rules for CSS 1.0 and CSS 2.0, yet a different
set of rules for CSS 2.1 and again a new set of rules in CSS 3.0 is not
acceptable, this will just add complexity and confusion to something
that already is too complex and too confusing.

We recently had an outcry about W3C Changing The Rules concerning a long
standing bug in the W3C CSS Validator and evangelists correctly pointed
out that giving the community an impression that the rules change,
whether they really change or not, is a completly wrong message to send,
undoing much of the progress we made so far. To quote Jeffrey Zeldman
<http://lists.w3.org/Archives/Public/www-validator-css/2004Feb/0020.html>:

[...]
  "You see," some will say. "These so-called standards are always
  changing. They can't be trusted any more than browsers can be
  trusted. We might as well do everything in Flash/ build for IE 
  Windows only/ use table layouts" etc.
[...]

This is also an unnecessary burden to place on implementers. If the
rules change, they need to fix it; fixing bugs is expensive and might
thus not happen at all. CSS already has a forward compatible syntax that
is bascially a promise for implementers that they do not have to change
their CSS parsing code to support the syntax of later versions of CSS
and keeping that promise in CSS 3 is certainly a good thing.

  * leaving any condition in this regard undefined with respect to style
    sheet conformance and required user agent behaivour including making
    or leaving any condition to cause user agent dependant behaivour

Tim Tool Developer is not an I18N expert, he does not know what to do if
the specification says nothing about how to handle a condition, and he
knows neither what to do when the specification says it is up to him to
decide. In fact, if the CSS Working Group does not know how to handle it
how could Tim be supposed to know it? Tim could make a decision on his
own, release his tool and see what happens. It is likely that the users
of his tool will complain because it does not work like other tools,
browsers, validators, etc. Unpleasant for Tim and his users, and Tim
does not even know how to fix it.

Tim should rather point users complaining about his after all fully
comforming tool to a validator or the specification that makes it clear
what he does is right and the user should fix the document in order to
work properly with his tool. I think it is crucial for the success of
CSS and adaption of CSS syntax for things beyond styling hypertext that
Tim is able to write his tool, and it should be easy for Tim to do so,
not at least because Tim's XML tools were simple to write and work fine
for everyone.

More specifically, I object - among others - to the changes proposed in 

  http://www.w3.org/mid/16427.61280.674857.670826@lanalana.inria.fr

as modified by

  http://www.w3.org/mid/16435.26816.6696.770444@lanalana.inria.fr

[...]
  1. An HTTP "charset" parameter in a "Content-Type" field
  2. The @charset at-rule
  3. BOM
  4. <link charset=""> or other metadata from the linking
     mechanism (if any) 
  5. charset of referring [stylesheet or document] (if any)
  6. UA-dependent mechanisms
[...]

Let alone <http://www.w3.org/TR/charmod/#sec-EncodingIdent> which says
specifications SHOULD NOT use the term "charset" as it is used in item
five, this is all wrong.

The vast majority of style sheets is referenced from documents delivered
as text/html for which there is no complete algorithm to determine the
encoding, you can only determine one if the encoding is defined in the
HTTP header or similar mechanism or if you manage to read a
corresponding <meta> element and there are no encoding errors. This is
quite uncommon in practise.

A simple and common case is that the document contains only us-ascii
characters but does not use <meta> to declare an encoding. What is the
"charset" of such a document? US-ASCII? ISO-8859-1? Windows-1252? UTF-8?
I don't know, hence I don't know how to implement 5) which makes 5)
equivalent to 6) in many cases. You might blame the HTML Working Group
for not defining rules for text/html, but CSS does not define them for
CSS either while the proposed change requires to rely on it.

An example:

  HTML document a) has <a charset=utf-8 href=b>...</a>
  HTML document b) has <link ... href=c.css> and no encoding declaration
  CSS document  c) has @import "d.css" and no encoding declaration
  CSS document  d) has @import "e.css" and no encoding declaration

In this case, given HTML's rules and the rules proposed for CSS, the
encoding of style sheet e.css is determined by HTML document a). This is
way too much indirection. Encoding information in the HTTP header is
already difficult for most people since it is not visible to them, many
do not even know there is such a thing as a HTTP header. This rule even
yields in inconsistent results for the same style sheet which is even
harder to understand and most likely yields in encoding errors which are
not covered by the specification at all. Not to mention that this rule
is inconsistent with a wide range of similar specifications, XML to
mention the probably most prominent one.

In fact, the CSS WG agreed in 03/2003 to a completly different set of
rules which is defined in http://www.w3.org/TR/css3-syntax/#css-style
i.e.,

  1) higher level protocol
  2) @charset
  3) utf-8

For item six <http://www.w3.org/TR/charmod/#sec-EncodingIdent> cleary
says "Specifications MUST NOT propose the use of heuristics to determine
the encoding of data [...] Heuristics are bad because they will not work
consistently across different implementations." and I completly agree.

I think and have proposed and propose again that the rules for text/css
must be the same as for application/xml in all it's aspects in CSS 2.1+;
this is basically what css3-syntax currently says plus proper handling
of the UCS signature plus well-defined, simple and implementable error
handling and conformance definitions. I think we gain much if the
specification just says, it works exactly as for XML, XHTML, SVG, SMIL,
... whatever they are called.

I am told users should not be punished for author mistakes; since any
kind of conflict resolution attempts likely yield in encoding errors and
attempts to recover from encoding errors likely yield in situations
where you properly read

  body { background-color: black }

but for some reason don't properly read

  body { color: white }

in which case the user has likely no access to the page; he would have
no problem using the site if the style sheet had been completly ignored.
Unstyled rendering is better than borken rendering, for both, content
providers and users, hence, yes, I am even suggesting to inherit XML's
error handling rules in this regard.

I understand that there is legacy content on the web and that mainstream
browser developers need to handle quirks, but that's what we have quirks
mode for. If there should be hints for quirks mode developers in the
specification, make it an informational note.

I see however no reason why CSS should have different rules than all
those other document formats and especially not insanely complicated
ever changing ones as the rules discussed above and proposals for CSS
Level 3 suggest. Maybe mainstream browser developers have the necessary
resources and expertise to understand and implement it, Tim Tool
Developer has not. He should not be required to. No one should.

Received on Thursday, 19 February 2004 23:17:53 UTC