Re: [Bulk] Re: Counter-increment is not clear in CSS21 and CSS3

Sorry, I just realized I wanted to say : It's a breaking change from the 
spec, then.
Sorry for the unexepected 'not'.

--------------------------------------------------
From: "François REMY" <fremycompany_pub@yahoo.fr>
Sent: Wednesday, March 18, 2009 7:09 PM
To: "fantasai" <fantasai.lists@inkedblade.net>; "L. David Baron" 
<dbaron@dbaron.org>
Cc: <www-style@w3.org>
Subject: [Bulk] Re: Counter-increment is not clear in CSS21 and CSS3

> From: "fantasai" <fantasai.lists@inkedblade.net>
> Sent: Wednesday, March 18, 2009 5:52 PM
>> L. David Baron wrote:
>>> 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'.
>>>
>>> Note that the same issue is present with 'inherit' and (in css3)
>>> 'initial'.
>>
>> The CSSWG has accepted option 1. 'inherit' and 'initial' will be
>> handled the same way.
>
> Okay, it's not a breaking change from the spec, then.
> But whatever is the decision, the prose should be updated.
>
>>
>> ~fantasai
>>
>

Received on Wednesday, 18 March 2009 18:39:08 UTC