Bug 15458 - Computed Value line of 'content' property fails to handle the case of <string> or <counter>
Summary: Computed Value line of 'content' property fails to handle the case of <string...
Status: NEW
Alias: None
Product: CSS
Classification: Unclassified
Component: CSS Level 2 (show other bugs)
Version: unspecified
Hardware: All Windows 3.1
: P2 normal
Target Milestone: ---
Assignee: Bert Bos
QA Contact: public-css-bugzilla
Depends on:
Reported: 2012-01-08 19:46 UTC by Anton P
Modified: 2012-12-04 00:52 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Anton P 2012-01-08 19:46:38 UTC
Reported by Simon Sapin.

The Computed Value line of the 'content' property defined in 12.2
(http://www.w3.org/TR/CSS2/generate.html#content) says:

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

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
Comment 1 Anton P 2012-01-08 19:48:56 UTC
With <string>, presumably the computed value should be the same as the specified value.

With <counter>, should it be treated like attr()?
Comment 2 Simon Sapin 2012-01-08 20:01:58 UTC
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.
Comment 3 Anton P 2012-01-08 20:48:58 UTC

I agree with your proposal
Comment 4 Anton P 2012-01-11 21:36:08 UTC
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