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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Sun, 17 Feb 2013 12:39:12 -0800
Message-ID: <CAAWBYDB2u0CK+2Wv=BDaZ1-b06RocmQyWdVM+h2GhMYBBa8ELw@mail.gmail.com>
To: Simon Sapin <simon.sapin@kozea.fr>
Cc: www-style list <www-style@w3.org>
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.)

> "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.)

Multiple tokens is implicitly handled by the text - we specify that
the attr value must parse as "a [foo] token", not "a [foo] token and
optionally other stuff".

Whitespace is already handled - the paragraph preceding the list of
types says that, unless the type is "string", you need to trim leading
and trailling whitespace from the attribute value.

As for comments, unsure.  I'd prefer to just parse it as a CSS value,
full stop.  I've read the other email (though I'll wait until Tuesday,
the next work day for me, to respond to it) - the SVGWG considered,
back in the Switzerland f2f, making all their presentational
attributes parse explicitly as CSS, which means allowing comments.  If
implementations are okay with changing (and it sounded like FF was,
and WK was already there), I'd prefer to change.

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

No, if we did accept the SVG thing, we'd just add a flag that
prevented them from parsing as comments, so they'd instead fall down
into the DELIM case.

> 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

As stated above, already done.

Received on Sunday, 17 February 2013 20:39:59 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:08 UTC