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

-www-style
+www-archive

(dbaron has a point)


On Fri, 06 Feb 2009 22:57:18 +0100, Phillips, Addison <addison@amazon.com>  
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.


> The caution/concern that I would offer here is that automatic  
> normalization opens several potential issues, such as the interaction  
> between JavaScript and the normalized document and so forth. In the case  
> of Selectors, we (as a WG) have mainly focused on pointing out what the  
> behavior should be and not on defining how implementations should effect  
> that behavior. A higher-level normalization might be the best way to  
> achieve this in a given implementation---or, ultimately, in any  
> implementation. However, I would tend to say that such a decision  
> impacts many more technologies and specs and it should be arrived at  
> carefully.

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.


>> or (a feature that might be added to Selectors Level 4):
>>
>>    :contains("...") { ... }
>>
>
> 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. :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.

The same goes for many DOM operations.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Saturday, 7 February 2009 18:25:01 UTC