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

On 16 February 2014 13:51, 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.

Correct, and that should be handled by the implementation of the
Counter Styles API like it is done when the counter-style is used for
rendering the page.

That is, in the 'override' case, the initial value is the value of the
parent counter-style object. This is as per section 3.1.7 of the spec:
"If a counter style uses the override system, any unspecified
descriptors must be taken from the overridden counter style specified,
rather than taking their initial values."

> 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.

Don't you need to have all the counter styles parsed anyway (e.g. for
the fallback counter styles)?

The interesting case here is:

    @counter-style b { system: override a; ... }
    @counter-style a { ... }

as you need to delay resolution of the overrided styles until after a is parsed.

The other interesting case is when to flag an error if the overrided
counter-style does not exist. For example:

    @counter-style b { system: override a; ... }
    /* @counter-style a is not defined */

and:

    var b = ...; // look-up counter-style b
    alert(b.negative);

My concern here -- as I mentioned previously -- is that if the
implementation does not resolve the semantics behaviour of the Counter
Styles  and other CSS specs (w.r.t. initial values, override
resolution, etc.) that places a burden on the consumer of the APIs to
know about that. This will lead to:

a) the client code using the CSS APIs being more complex than needed;

b) bugs caused by client code not handling cases (e.g. override
behaviour) correctly.

If the implementor of these APIs has to handle this behaviour for the
CSS styles and rendering, why can't they do the same for the
JavaScript APIs? That is, you would need to parse the overriden style
when rendering the page so why is that more difficult to do from the
JavaScript API?

> 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.

Why make system a special case?

Thanks,
- Reece H. Dunn

> Regards,
> Xidorn Quan

Received on Sunday, 16 February 2014 14:33:04 UTC