- From: Simon Sapin <simon.sapin@kozea.fr>
- Date: Sun, 17 Feb 2013 19:46:20 +0100
- To: www-style@w3.org
Hi, attr() defines a few <type-or-unit> keywords that determine how to parse an attribute value. Each keyword definition starts with either: 1. The attribute value will be parsed as the contents of a CSS <string> 2. The attribute value must parse as a (X) CSS token Does "parsing as <string>" mean interpreting CSS backslash-escapes? I think it should not, but the current spec text is unclear. Not interpreting escapes means that the <string>’s value is exactly as would be returned by element.getAttribute(name). HTML and XML already have an escaping mechanism, adding one is not necessary. "Parsing as a token" should fail if the tokenizer returns more than one token. But what about leading and trailing whitespace? I think they should be removed/ignored but again the spec is unclear. What about CSS comments? I think this should be consistent with "presentational hint" attributes, and [1] seems to indicate that they should not be allowed there. (Search for "SVG wart". Not sure if it also applies to non-SVG attributes.) [1] http://lists.w3.org/Archives/Public/www-style/2013Feb/0402.html The tokenizer does not even emit comment tokens in the current css3-syntax ED. We might need to change that because of the above. Finally, I think that attr(foo url) should also remove leading and trailing whitespace from the attribute value, in order to be consistent with HTML’s concept of "valid URL potentially surrounded by spaces" used for href attributes. http://www.w3.org/TR/html5/links.html#attr-hyperlink-href http://www.w3.org/TR/html5/infrastructure.html#valid-url-potentially-surrounded-by-spaces Note that all of these are clarifications rather than changes, so being in CR should not be a problem. Cheers, -- Simon Sapin
Received on Sunday, 17 February 2013 18:46:46 UTC