Elliott wrote:
> What are the XHTML-Print operations that are affected by
> normalization? This discussion is useful for string
> processing (match, substring, sort) but I don't see how that
> affects printing. One possible area is CSS class names; are
> they restricted to ASCII?
The CSS 2 specification for identifiers is in Section 4.1.3 [1] and states
that CSS class names are not restricted to ASCII. So, if a class name is
written with precomposed characters in one place and anyone of the other
equivalent sequences in another place, then the two instances would only
match if they were normalized, preferably to Normalized Form C. The same
holds true for id attribute values.
>
> Also, I don't see how a new report can change the definition
> of an existing spec (XHTML). Isn't this a separate set of
> rules that might be folded into future revisions?
>
I think that the report [2] has been around for a while and I've just now
become aware of it. I think it's an omission that the XHTML-Print spec
doesn't reference [2] as a normative reference. This allows the situation
where naïve implementations fail in the situation noted above. This could
be addressed by adding a normative reference.
Jim
[1] http://www.w3.org/TR/REC-CSS2/syndata.html#q4
[2] http://www.w3.org/TR/charmod/
This archive was generated by hypermail 2b29 : Mon Sep 22 2003 - 18:51:21 EDT