W3C home > Mailing lists > Public > www-style@w3.org > October 2003

[CSS21] Comments on the 2003-09-15 CSS 2.1 Draft

From: Henri Sivonen <hsivonen@iki.fi>
Date: Sun, 19 Oct 2003 20:24:26 +0300
To: www-style@w3.org
Message-Id: <170A2352-0259-11D8-9167-003065B8CF0E@iki.fi>

Links to non-normative versions

I suggest providing the diff between CSS 2 and CSS 2.1 with the final 
REC and linking to it.

3.1 Definitions

"Element" is defined using a normative reference to SGML. The SGML 
standard is not freely available on the Web. Considering it that the 
SGML specification is not available for linking and reading on the Web, 
I suggest removing the normative reference to SGML and defining 
"element" by reference to XML instead.

The definition for "ignore" says there are three meanings. However, it 
only list meetings introduced by "First" and "Second".

4.3.2 Lengths

I suggest calling "absolute" units "physical" instead, because people 
tend to consider pixels absolute in the context of computer graphics.

5.8.2 Default attribute values in DTDs

The requirement "Default attribute values may be defined in a DTD or 
elsewhere, but cannot be selected by attribute selectors." moves from 
the realm of rendering to defining what information a XML processor 
should expose. Specified attributes and defaulted attributes are 
normally considered equivalent as far as the reporting from an XML 
processor to an application is concerned. The CSS 2.1 Draft says 
building the document tree is beyond the scope of the spec. I think the 
CSS 2.1 spec should not require the XML processor to report whether an 
attribute was defaulted.

I suggest modifying the passage:
"Default attribute values may be defined in a DTD or elsewhere, but 
cannot be selected by attribute selectors. Style sheets should be 
designed so that they work even if the default values are not included 
in the document tree."
to this
"Default attribute values may be defined in a DTD or elsewhere. 
However, non-validating XML processors are not required to process the 
external DTD subset, so some user agents  do not process attribute 
defaults defined in the external DTD subset. Therefore, style sheets 
should be designed so that they work both when attributes are defaulted 
and when they are not. For interoperability and performance, it is 
recommended that Web browsers not process the external DTD subset."

5.9 ID selectors

Unlike class selectors, the id selectors are defined to depend on the 
IDness defined in the DTD. For performance reasons, Web browser can 
reasonably be expected not to process the external DTD subset. 
Therefore, id selectors when used with XHTML would fail in most if not 
all Web browsers. I suggest allowing the UA to have hard-coded 
knowledge about IDness based on the namespace--just like the UA is 
expected to have hard-coded knowledge about what constitutes class.

8.6 The box model for inline elements in bidi context

No definition is given for the term "bidi context".

9.10 Text direction: the 'direction' and 'unicode-bidi' properties

"This seemingly one-sided requirement reflects the fact that, although 
not every Hebrew or Arabic document contains mixed-directionality text, 
such documents are much more likely to contain left-to-right text 
(e.g., numbers, text from other languages) than are documents written 
in left-to-right languages."

Probably what is meant is that dominantly RTL documents are more likely 
to contain LTR parts than dominantly LTR documents are to contain RTL 

10.1 Definition of "containing block"

The example uses a HTML 4.0 Transitional doctype without a SYSTEM id. 
The implementation practice (and CSS 2.1 is about implementation 
practice) is not to treat such documents as specified in this section. 
It would probably be clearer to use an HTML 4.01 Strict doctype with a 

12.3.1 Specifying quotes with the 'quotes' property

"Note. While the quotation marks specified by 'quotes' in the previous 
examples are conveniently located on computer keyboards, high quality 
typesetting would require different ISO 10646 characters."

I think it would be better to use the high quality alternatives in the 

13 Paged media

"The computed value of box margins at the top or bottom of the page 
area is zero."

Is there a reason why same rule doesn't apply to left and right margins 
that touch the edges of the page area?

14.3 Gamma correction

" Mac using QuickDraw
     apply gamma 1.45 [ICC32] "

I think assuming a particular gamma based on platform is harmful. The 
display gamma is configurable on the Mac. When the user agent and 
doesn't really know the display gamma, I think it would be better not 
to try to "correct" it.  Applying "corrections" based on guesses has 
been harmful in connection to the PNG format.
See http://iki.fi/hsivonen/png-gamma.html

"(ColorSync-savvy applications may simply pass the sRGB ICC profile to 
ColorSync to perform correct color correction)"

The ICC rendering intent is not specified. If a PNG image where is 
marked to be in the sRGB color space, which rendering intent should be 
specified in order to match CSS colors in a User Agent that does color 
matching based on ICC profiles?

15.2 Font matching algorithm

I think the specification is too detailed here. When the page isn't 
displayed with the font the author primarily wanted, do this specifics 
of the font matching really matter? For example, on Mac OS X ATSUI 
already implements a font matching algorithm which could be considered 
good enough. Having to implement another matching algorithm on the 
application level is a performance problem. Consideration 
implementation difficulty, performance and the user experience, I think 
passing the list of font alternatives to the system Unicode imaging 
service and letting the system apply its fallback algorithm would be 
quite sufficient when the system offers font list-based fallback 
functionality. Also, considering user experience, allowing (but not 
requiring) the user agent to make decisions based on the content of the 
entire page is likely to be better than doing per character font 

Henri Sivonen
Received on Sunday, 19 October 2003 13:24:30 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:09 UTC