- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Sun, 19 Oct 2003 20:24:26 +0300
- To: www-style@w3.org
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 parts. 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 SYSTEM id. 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 examples. 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 selection. -- Henri Sivonen hsivonen@iki.fi http://www.iki.fi/hsivonen/
Received on Sunday, 19 October 2003 13:24:30 UTC