W3C home > Mailing lists > Public > public-i18n-core@w3.org > January to March 2006

Re: I18n Core WG comments on CSS3 Selectors

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Fri, 20 Jan 2006 16:22:15 +0100
To: "Richard Ishida" <ishida@w3.org>
Cc: "'www-style Mailing List'" <www-style@w3.org>, <public-i18n-core@w3.org>
Message-ID: <fat1t19f8d3mcducfinv8v4lha5b28d1as@hive.bjoern.hoehrmann.de>

* Richard Ishida wrote:
>http://www.w3.org/International/reviews/0601-css3-selectors/

In #23, what do you mean by making the syntax module a dependency? It is
perfectly reasonable to use CSS Selectors without other parts of the CSS
syntax, e.g. as selection mechanism in an API, and the draft refers to
the module only to point out that that module defines a namespace prefix
binding mechanism.

Regarding #14, the draft has "Whether an element is represented by a
:lang() selector is based solely on the identifier C being either equal
to, or a hyphen-separated substring of, the element's language value, in
the same way as if performed by the '|=' operator in attribute
selectors." I don't really think this could be read to imply that |=
does or :lang does not consider inherited language information; what
should it say instead (avoiding duplication |='s definition)?

Regarding #10, while I am not sure what's wrong with en-cockney, it
would be good if the I18N Core Working Group could check other TRs and
RFCs for this error and report it as appropriate. This would then be a
rather common error.

I'm not sure in #7 what the "therefore" refers to. Could you elaborate
why the examples should be changed? They are perfectly reasonable as far
as I can tell.

Regarding #6, I'm a bit lost here, the draft notes precisely this three
times already and points out, three times, where additional information
can be found at some point. What's the problem here exactly?

In #5, what would it mean for CSS Selectors to "support" any specific
version of Namespaces in XML?

Using meaningless identifiers in section 2 as requested in #2 makes some
sense to me; I'm not sure though which part of the draft actually leads
to the confusion you cite.

I disagree with #2, the term element type has well-established semantics
in XML and SGML, I don't see how explaining that element types are not
data types, or personality types, or whatever. We should change s/type
element selectors/element type selectors/ in 1.3 though.

What did you have in mind for #1?
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Friday, 20 January 2006 15:21:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 October 2008 10:18:50 GMT