15458 2012-01-08 19:46:38 +0000 Computed Value line of 'content' property fails to handle the case of <string> or <counter> 2012-12-04 00:52:51 +0000 1 1 1 Unclassified CSS CSS Level 2 unspecified All Windows 3.1 NEW P2 normal --- 1 antonsforums bert simon.sapin public-css-bugzilla oldest_to_newest 62387 0 antonsforums 2012-01-08 19:46:38 +0000 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 62388 1 antonsforums 2012-01-08 19:48:56 +0000 With <string>, presumably the computed value should be the same as the specified value. With <counter>, should it be treated like attr()? 62389 2 simon.sapin 2012-01-08 20:01:58 +0000 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. 62392 3 antonsforums 2012-01-08 20:48:58 +0000 Thanks. I agree with your proposal s/keywords/values 62575 4 antonsforums 2012-01-11 21:36:08 +0000 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/