- 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