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