RE: [CSS21][css3-namespace][css3-page][css3-selectors][css3-content] Unicode Normalization

> 
> (dbaron has a point)

+1

> Anne replied to what I wrote:
> > It *is* emphatically something worth considering. I don't believe
> one
> > can categorically say that the "i18n guys don't want"
> normalization as,
> > for example, part of the parsing process. However, our focus (at
> least
> > in the I18N WG) is on what behavior CSS Selectors should have.
> 
> I think it should be clear from the feedback from vendors so far
> that just looking at Selectors is not the way to go.

... from a vendor perspective. From a specification perspective, we are talking about what Selectors should do. But quite obviously Selectors is only one example of the normalization issue, a point which is key in I18N's official comments (under review within the WG currently).

> 
> Changing just Selectors does not solve the problem. It merely
> fragments equality checks in implementations leading to more bugs and
> inconsistencies. It also fragments the Web platform. If you want to
> solve the problem you cannot just look at Selectors.

Changing Selectors addresses the problem with Selectors. It doesn't "solve" the overall problem. But it is one element of the problem and one that is useful in discussing the problem.

> >
> > The performance factors important to atomized strings probably
> don't
> > apply to these operations though. It is probably acceptable to
> handle a
> > random text match such as :contains with lower performance.
> 
> No it is not. 

Probably I didn't phrase that quite right. My point is not that "substring matching should be dog slow". My point is that there are relative levels of acceptable performance and it is possible that substring matching (such as :contains), since it used in a different way than DOM tree navigation, might have different measure of "acceptable" in handling normalization.

> :contains is _highly_ sensitive to very fast equality
> checks
> since CSS is live. (E.g. changes to the DOM requires checking if
> Selectors
> still match or not.) In fact, precisely because of performance
> reasons has
> this feature not been implemented yet in rendering engines.

I don't disagree, but would then note that normalization isn't the performance barrier, now is it? 

> 
> The same goes for many DOM operations.
> 

We need to resolve what the proper behavior should be ("requirements"). Implementations then have to meet requirements and may find diverse ways to achieve. Acceptable performance is a requirement. Normalization-related behavior may be. I see declarations that normalization "makes things too slow" without any empirical evidence (on either side) and the efforts seem to be to reject the proposed requirements solely on the basis of performance. If the requirements are the right ones, then it is up to implementers to create implementations that meet them (including performance requirements). Balancing performance with other needs is the key here. And, again, I don't believe I18N is saying that normalization must take place solely at the selectors level. It is that it needs to take place at the right level. This, in turn, may result in specifications (such as Selectors) having conformance requirements related to normalization. 

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

Received on Saturday, 7 February 2009 20:10:26 UTC