Bugzilla – Bug 15458
Computed Value line of 'content' property fails to handle the case of <string> or <counter>
Last modified: 2012-12-04 00:52:51 UTC
Reported by Simon Sapin.
The Computed Value line of the 'content' property defined in 12.2
# On elements, always computes to 'normal'. On :before and
# :after, if 'normal' is specified, computes to 'none'.
# Otherwise, for URI values, the absolute URI; for attr()
# values, the resulting string; for other keywords, as
This fails to handle the case of <string> or <counter>.
Conversation begins: http://lists.w3.org/Archives/Public/www-style/2011Nov/0797.html
Bug description: http://lists.w3.org/Archives/Public/www-style/2011Nov/0798.html
With <string>, presumably the computed value should be the same as the specified value.
With <counter>, should it be treated like attr()?
Anton, by <counter> treated like attr(), do you mean the computed value should be string representation of the counter value?
Arguably CSS 2.1 counters could be resolved to their value at "computed value time", but I do it later in WeasyPrint (when creating boxes from elements.) Not sure what other UAs do. However, css3-page introduce page based counters. These can definitely not have a value by the time computed values are required. (In paged media, we only know where page breaks end up when doing layout.)
I propose that both <string> and <counter> stay as specified in the computed value. Actually, "for other keywords" just need to become "for other values", which I think is what was intended.
I agree with your proposal
Tab Atkins Jr writes:
2.1 doesn't actually specify one way or another whether counters are
kept as-is or turned into the string they represent at computed-value
time. However, all browsers agree that they're kept as-is. Lists
matches this in its definition of the computed value of 'content' on
This supports the proposal