W3C home > Mailing lists > Public > www-style@w3.org > May 2013

Re: [css3-values] Syntax of attribute values for attr()

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 28 May 2013 17:53:23 -0700
Message-ID: <CAAWBYDB5eWSqZ2X0bO8N2g=EQW9ywYjY06smrO_FJp_rFBm1Cg@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 29 May 2013 00:54:14 UTC