W3C home > Mailing lists > Public > public-css-archive@w3.org > November 2017

[csswg-drafts] [css-list] `counter()` should not be allowed in anywhere `<string>` is accepted

From: Xidorn Quan via GitHub <sysbot+gh@w3.org>
Date: Fri, 03 Nov 2017 12:56:10 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-270969019-1509713768-sysbot+gh@w3.org>
upsuper has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-list] `counter()` should not be allowed in anywhere `<string>` is accepted ==
Brought by @Loirooriol in [#1026 (comment)](https://github.com/w3c/csswg-drafts/issues/1026#issuecomment-341435007), CSS Lists currently says:
> Counters ... can be used by an author anywhere that accepts a `<string>`.

This can potentially be problematic given my argument in [#1026 (comment)](https://github.com/w3c/csswg-drafts/issues/1026#issuecomment-341295647).

So what needs to be resolved here would be: should the counter functions be expanded at computed-value time (so that children inherit the expanded counter rather than the counter functions themselves), or at used-value time (so that children inherit the counter functions, and only replace it with the string when the value is used for rendering).

It seems to me that both approaches have some issues.

Making counter functions expanded at computed-value time means browsers may need to invalidate computed value when some siblings or siblings of ancestors change. This is probably doable but can be complicated with little benefit. It also means we would be changing how counter functions are handled in `content` property (which is currently expanded at used-value time), but this may not be a big deal as it may only affect anything other than the returned value from `getComputedStyle`.

Having them expanded at used-value time would be a lot more troublesome as we would need to expand every place which `<string>` may be accepted to also keep the details of counter functions, and calculate them when they are used. That could be a decent amount of boilerplate code. Furthermore, consider that `<family-name>` can be `<string>`, and `font-family` is inherited, it could make font even funnier to play with (from the browser engine side).

I think basically the issue is that, allowing counter functions elsewhere outside `content` property doesn't show much usefulness, so it doesn't seem to be worth its implementation complexity.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1929 using your GitHub account
Received on Friday, 3 November 2017 12:56:16 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 12:56:16 UTC