Re: I18n Core WG comments on CSS3 Selectors

On Sat, 21 Jan 2006 00:22:15 +0900, Bjoern Hoehrmann <>  

> * Richard Ishida wrote:
> 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.

see my reply to a mail from Daniel about the unclearness of dependency of  
this draft on CSS.

> 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?

again: do you depend on css or not?

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

to allow for statements like "@namespace foo url(xxx);", where "xxx" is  
conformant to
'xmlns:' NCName (NCName being definded at .

> 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.

It is not the draft which makes the confusion, but the fact that esp. in  
the last years of W3C standardization various notion of types have been  
created. Since you seem to aim this document for a wider audience, you  
might not only technical issues into account, but also readability / wider  
context issues.

> 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?

the same as comment #2 - but this work into a wider context, please - if  
you want to have a wider audience than CSS.

Regards, Felix.

Received on Monday, 23 January 2006 14:07:57 UTC