W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

RE: [selectors-api] Selectors API I18N Review...

From: Phillips, Addison <addison@amazon.com>
Date: Tue, 27 Jan 2009 10:40:02 -0800
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
CC: "public-webapps@w3.org" <public-webapps@w3.org>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>
Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA017D83BA54@EX-SEA5-D.ant.amazon.com>
(This is a personal response)

Hi Lachlan,

I didn't expect any other response from you, really.

At a minimum, I think we would expect a health warning or warnings in the API spec, since Selectors themselves don't address the issue. Our WG could recommend some appropriate text that is not too dire-looking.


> While I understand that the
> CSSWG have not yet adequately addressed the i18n issues in their
> spec, there's nothing I can do to resolve that.

I recognize that. For reasons I won't go into here, I note that lack of maturity in CSS3 doesn't block your advancement. But advancing your document without the issue being resolved might lead to a "de facto" standard that is hard to overturn/undo.
 
> I could not define any normalisation in this spec without
> indirectly
> affecting how selectors work in other specs that use them, like CSS.

I agree. But my concern looks something like:

- You publish; various interoperable implementations are created which do not address Unicode normalization. Normalization is not addressed, since CSS3 hasn't dealt with it yet.

- CSS3 later decides to address normalization. One of two outcomes is possible:

   a. Defining normalization breaks the extant implementations; tough luck for the implementers.
   b. Everyone pretends that normalization isn't somehow important; tough luck for users.

We've been living in "world (b)" for some time now. The situation is becoming less pretty as more languages that use combining marks and compatibility forms come into common usage on the Web. So, as I said, I think it likely that our WG will want to help you advance in some useful (non-blocking) way. Our next meeting is tomorrow, so look for a formal response from us shortly.

Kind Regards,

Addison

Addison Phillips
Globalization Architect -- Lab126
Chair -- W3C Internationalization WG

Internationalization is not a feature.
It is an architecture.


> -----Original Message-----
> From: Lachlan Hunt [mailto:lachlan.hunt@lachy.id.au]
> Sent: Tuesday, January 27, 2009 9:39 AM
> To: Phillips, Addison
> Cc: public-webapps@w3.org; public-i18n-core@w3.org
> Subject: Re: [selectors-api] Selectors API I18N Review...
> 
> Phillips, Addison wrote:
> > I am writing on behalf of the I18N Core WG who discussed the
> > Selectors API WD in our call of 3 December [1].
> >
> > We reviewed the Selectors API working draft. In reviewing this
> draft,
> > we did not find any internationalization issues in the text of
> the
> > document. However, we would like to point out that the CSS3
> Selectors
> > themselves have outstanding internationalization comments not
> > addressed in the current version of that document [4] and which
> would
> > (we think) impact anyone who were to implement the Selectors API.
> Our
> > comments on CSS3 Selectors are located at [2]. We also note that
> > Unicode Normalization is not treated anywhere in this draft or in
> > CSS3 Selectors.
> 
> I'm not sure how I can address this issue.  While I understand that
> the
> CSSWG have not yet adequately addressed the i18n issues in their
> spec,
> there's nothing I can do to resolve that.
> 
> Since this API defers all processing requirements for selectors to
> the
> selectors spec (with the exception of trimming whitespace), it is
> the
> responsibility of selectors to deal with Unicode normalisation
> issues.
> I could not define any normalisation in this spec without
> indirectly
> affecting how selectors work in other specs that use them, like CSS.
> 
> > We are concerned that changes in CSS3 might impact implementation
> of
> > Selectors API and/or the text thereof and think our concerns
> probably
> > should be addressed before Selectors API advances to the next
> level
> > of maturity.
> 
> I do not believe the limitations of Selectors can have a direct
> impact
> implementation of this API.
> 
> This is the last issue I need to address before asking to have this
> spec
> proceed to CR, so I would like to be able to resolve it as quickly
> and
> as easily as possible.  If you have any proposals as to how exactly
> I
> can address it, I will certainly try and do so.
> 
> --
> Lachlan Hunt - Opera Software
> http://lachy.id.au/

> http://www.opera.com/

Received on Tuesday, 27 January 2009 18:40:54 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:29 GMT