This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

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
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-08 19:46 UTC by Anton P
Modified: 2012-12-04 00:52 UTC (History)
1 user (show)

See Also:

Attachments

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

I agree with your proposal
s/keywords/values
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
::marker.

http://lists.w3.org/Archives/Public/www-style/2012Jan/0493.html

This supports the proposal
s/keywords/values/