-www-style
+www-archive
(dbaron has a point)
On Fri, 06 Feb 2009 22:57:18 +0100, Phillips, Addison <[email protected]>
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/>
