W3C home > Mailing lists > Public > www-style@w3.org > February 2014

Re: [css-counter-styles] question about API

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 17 Feb 2014 07:52:02 -0800
Message-ID: <CAAWBYDBnuNsXVqpPMSwKDOUWVYbyn9pV4SzwpW3+Ga3AL9z_nw@mail.gmail.com>
To: Xidorn Quan <quanxunzhen@gmail.com>
Cc: Reece Dunn <msclrhd@googlemail.com>, www-style list <www-style@w3.org>
On Sun, Feb 16, 2014 at 5:51 AM, Xidorn Quan <quanxunzhen@gmail.com> wrote:
> On Fri, Feb 14, 2014 at 10:02 PM, Xidorn Quan <quanxunzhen@gmail.com> wrote:
>> It is a very reasonable point. I agree with you that it is easier for
>> developers to use this API if it returns initial value for unspecified
>> descriptors. I thought there should be a way to distinguish whether a
>> descriptor is explicitly declared, which seems to have no sense.
>>
>> (Oh, I changed my stand the second time...)
>
> Well, I'd like to change my stand again. I still think that we should
> provide a way to check whether some descriptors are specified.
>
> In the 'override' system, unspecified descriptors should inherit the
> value from the corresponding descriptor of style it overrides instead
> of the initial value. If the system is 'override' and the initial
> value is returned for unspecified descriptors, it is unable to know
> whether a descriptor is unspecified, or specified with the initial
> value occasionally. Or do you want to return the inherited value
> directly? I don't think it's a good idea since it requires to parse
> another style to generate the values.
>
> Consequently, my suggestion is that, if a descriptor is unspecified,
> for 'system' descriptor, yes, the initial value can be returned, while
> for other descriptors, null should be returned.

We decided on this issue at the last WG telcon.  We didn't have strong
reasons to prefer any of the three options (null, empty string,
initial value), so we went with what implementations already did for
@font-face, which is return the empty string.

~TJ
Received on Monday, 17 February 2014 15:52:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:19 UTC