- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 28 May 2013 17:53:23 -0700
- To: Simon Sapin <simon.sapin@exyr.org>
- Cc: www-style list <www-style@w3.org>
On Sun, May 26, 2013 at 9:09 PM, Simon Sapin <simon.sapin@exyr.org> wrote: > Le 18/02/2013 04:39, Tab Atkins Jr. a écrit : >> On Sun, Feb 17, 2013 at 10:46 AM, Simon Sapin<simon.sapin@kozea.fr> >> wrote: >>> >>> 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. >> >> I'm not sure about this. Yes, HTML and XML already have an escaping >> mechanism, but attr() resolves away at some point. If its value has >> things in it that look like CSS escapes, does that mean we'd have to >> serialize them escaped as well? >> >> (That might be okay - I suppose implementations probably currently >> handle serialization of strings and escapes by just including the >> character directly in the data, and then re-inserting the escape in >> the serialization stage if necessary.) > > I still find this unclear in the spec. I think that parsing a document > attribute for a 'string' or 'url' <type-or-unit> should not involve CSS > escapes, even if serializing the computed value requires such escaping. I think you're right. We should verify this with the WG, but I support just saying that it's a <string> or <url> whose value is the attribute's value. ~TJ
Received on Wednesday, 29 May 2013 00:54:13 UTC