RE: I18n Core WG comments on CSS3 Selectors

Procedural note: 

If you reply to Bjoern's questions, please respond to each comment in a
separate mailnote (as requested in the comment page).  We have degenerated
several times in the past into an mess of threads that can be very hard to
untangle by some people responding to some parts of a message like this, and
others to other parts.

In the past I have used subject headers such as "RE: I18n Core WG comments
on CSS3 Selectors [14]" to refer to discussion of comment #14, and found
that works well.

Felix, many of these questions are against comments you made.  I'll hold off
for a while to see whether you prefer to answer them.  I'm happy to reply to
those I raised, but may not do so today.

RI

============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)

http://www.w3.org/People/Ishida/
http://www.w3.org/International/
http://people.w3.org/rishida/blog/
http://www.flickr.com/photos/ishida/
 

> -----Original Message-----
> From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net] 
> Sent: 20 January 2006 15:22
> To: Richard Ishida
> Cc: 'www-style Mailing List'; public-i18n-core@w3.org
> Subject: Re: I18n Core WG comments on CSS3 Selectors
> 
> * 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:48:27 UTC