W3C home > Mailing lists > Public > www-style@w3.org > May 2012

Re: [css3-values][selectors4] identifier matching and normalization

From: John Daggett <jdaggett@mozilla.com>
Date: Tue, 1 May 2012 22:22:15 -0700 (PDT)
To: fantasai <fantasai.lists@inkedblade.net>
Cc: www-style@w3.org
Message-ID: <1405050343.560289.1335936135266.JavaMail.root@mozilla.com>
fantasai wrote:

> >> We need to define whether/how the user-defined<identifier>  is
> >> Unicode-normalized, and whether an NFC counter-name is the same as
> >> an NFD counter-name.
> >
> > I think this has the potential to be a big rathole.  Wasn't there a
> > large discussion of this related to the Selectors spec?  Wasn't the
> > conclusion there to not make normalization a requirement?
> >
> > Since that conclusion is a subset of the issue here, I think you need
> > to state why you think that conclusion needs to be revisited.  And
> > also whether this decision has bearing on HTML5 or not.
> 
> The difference here is that we're defining matching purely within
> CSS. Selectors has to interact with everything else, and we couldn't
> figure out anything that made sense for the platform as a whole, so
> we sidestepped the issue. Within CSS, we don't have that problem.
> 
> (Thinking about it now, I think for Selectors normalization should be
> handled the same as case-sensitivity: CSS stores the name in its
> original language, and the markup language defines which forms are
> considered the "same" or "different". So if <nfc></nfd> is considered
> well-formed in that language, then both nfc and nfd would match that
> element; otherwise not.)

Just to put this in context, you're saying that in the example below
the rules for matching counters can be different than those for
matching id selectors. So the a-ring in "håkon" (just to use a random
example), which can be decomposed to 'a', followed by combining-ring-above, 
would match in the counters case but not in the id selector case where
id == 'håkon4' (more complete example here [1]):

  body {  
    counter-reset: håkon1 håkon2;
  }
  
  #test1 h1:before {  
    counter-increment: h\e5 kon1;
    content: "Section " counter(håkon1) ": ";
  }
  
  #test2 h1:before {  
    counter-increment: h\61 \30a kon2;
    content: "Section " counter(håkon2) ": ";
  }
  
  #h\e5 kon3 { color: red; }
  #h\61 \30a kon4 { color: blue; }
  
  <div id="test1">
  <h1>First</h1>
  <h1>Second</h1>
  </div>
  
  <div id="test2">
  <h1>First</h1>
  <h1>Second</h1>
  </div>
  
  <p id="håkon3">Red if matched</p>
  <p id="håkon4">Blue if matched</p>
  
I'm not sure it's a good idea to do normalization in one case but not the other, I
don't think differentiating between "within CSS" and "between CSS and something else"
is a terribly useful distinction.

Note also, that you'll need to explicitly define whether casemapping occurs before
or after normalization, since the order will affect the results (consider the use
of u+2126 Angstrom in the example above).

Rathole here we come...

Regards,

John Daggett

[1] http://people.mozilla.org/~jdaggett/tests/counternormalization.html
Received on Wednesday, 2 May 2012 05:22:45 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:53 GMT