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

On Mon, Feb 17, 2014 at 1:32 AM, Reece Dunn <msclrhd@googlemail.com> wrote:
> 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?

Do you think, to reduce the consumer's burden, we should also expand
the 'auto' for 'range' and 'speakAs'? And return decimal instead of
the specified 'fallback' if the latter is not available? I don't think
so. What you want is computed value, not the style data itself. I
agree that it is easier for some API users if the computed values are
reachable, but I don't think we should return them here, and the
values returned should not depend on its context and any other rules
at all, which will complexify not only the implementation of API but
also the usage.

For the usage of API, for example, we have two counter styles A and B,
B overrides A, and no descriptors specified in B. Assume that in the
begining, prefix of A is empty, and one function reads the prefix from
B and saves it to a variable, then another function changes prefix of
A to some other value. According to your suggestion, the value of
prefix of B is magically changed as well, but client may miss such
change since it may not take care that the value in B is affected by
A, and may continue using the cached out-of-date value. It is much
more intricate than returning a sentry null, which reminds the client
to take care itself.

For implementation, parsing and rendering are two different stages.
Maintaining a pointer from one style data structure to another may
introduce burden which is much heavier and more dangerous than in
script code.

> Why make system a special case?

Because value of system will not be affected by any other descriptors
or rules, and it has a static initial value. However, if for
consistency, returning a sentry null or empty string is acceptable as
well.

Regards,
Xidorn Quan

Received on Monday, 17 February 2014 00:50:59 UTC