- From: François REMY <fremycompany_pub@yahoo.fr>
- Date: Wed, 18 Mar 2009 17:06:37 +0100
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: "CSS 3 W3C Group" <www-style@w3.org>
From: "L. David Baron" <dbaron@dbaron.org> Sent: Wednesday, March 18, 2009 1:45 AM > On Thursday 2009-03-12 22:21 +0100, François REMY wrote: >> But, I just found another problem : The spec isn't clear about how the UA >> must >> treat 'none' as value for counter-increment. In fact, the prose NEVER >> talk about >> the effect of 'none'. So, the browser should treat none as a non-effect >> value, if it >> can't understand it otherly. > > I agree that the spec should be clarified here. > > I think IE8's behavior (not accepting 'none') is incorrect. But I > also think Gecko's behavior (it rejects 'none 1' but accepts 'foo 1 > none 1') is incorrect. > > I think we probably want to say that either: > > (1) 'none' is a valid value on its own, but any value containing > 'none' as a counter name is invalid, or > > (2) 'none' as a value on its own means that no counters are > incremented/reset, but use of 'none' in any other values implies > that there is a valid counter named 'none'. I personnally propose the (2) to be chosen, because it's the 'most normal way' to handle the things. We just say that 'none' is a specific value that can't be interpreted as 'none 1'. > > Note that the same issue is present with 'inherit' and (in css3) > 'initial'. Yes, and no. Yes, the spec itself don't speak about them, but a globaler spec define clearly the behaviour when we have prop: initial and prop: inherit. No spec says what do to when we have prop: none. So we need to consider 'none' as 'none' 1 here. > -David > > -- > L. David Baron http://dbaron.org/ > Mozilla Corporation http://www.mozilla.com/ >
Received on Wednesday, 18 March 2009 16:07:16 UTC