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

On 17 February 2014 00:49, Xidorn Quan <quanxunzhen@gmail.com> wrote:
> 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.

There are two approaches to the JavaScript API:

1.  It is a simple representation of the style data expressed in the file.

2.  It is a representation of the actual initial values that would be used.

For (1) which is what the API implies and you propose, the JavaScript
API is a simple parse over the styles without any context resolution
applied. Thus, any value that is not specified should be null or an
empty string.

For (2) the JavaScript API has all of the semantics of the counter
style properties. This includes expanding an auto range to the
corresponding values.

There are also two use cases for the API:

a.  Creating/manipulating a counter style object;

b.  Querying the values of a counter style object.

For (a), approach (1) is more useful as it is then like writing a
@counter-style rule in CSS. This would also require a way of
validating the counter style once the values that need to be set are
set.

For (b), approach (2) is more useful as a client should not have to
implement the counter styles property logic to determine the actual
value.

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

So if a client wants the range of a property value, how will they do
it? They need to:
1.  if range is null or "auto" check if system is an "override" style
and if so get the range of the parent style;
2.  if range is null or "auto" then:
2.1.  if system is an "override" style get the system of the parent style;
2.2.  if the derived system value is "cyclic", "numeric" or "fixed"
then the range is "infinite infinite"
2.3.  if the derived system is "alphabetic" or "symbolic" then the
range is "1 infinite"
2.4.  otherwise (the system is "additive") the range is "0 infinite"
3.  otherwise the range is the value of the range property

This is in addition to parsing the actual range that is required by
this JavaScript API.

I think that the key questions are:

1.  When setting the values, how are inter-connected values validated?

2.  What are the intended use cases of the getter API?

Also note that the spec says for the properties that are not the name
property: "The remaining attributes on getting must return a DOMString
object that contains the serialization of the associated descriptor
defined for the associated rule."

This implies that this is the actual computed value, so
"@counter-style a { system: cyclic; }" would return a range of
"infinite infinite", not "auto" or null.

Tab: Can you clarify that this is the intended behaviour and clarify
the wording in the spec?

Thanks,
- Reece H. Dunn

Received on Monday, 17 February 2014 10:49:02 UTC