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

Le 17/02/2013 21: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.)


What does "resolves away" mean?
When eg. a computed value is requested from CSSOM, it needs to be 
serialized to CSS from whatever is the internal representation. This may 
involve escaping, but is independent of how the value was parsed. 
Implementations could choose to keep CSS text around from stylesheets to 
make this cheaper, but there are many cases anyway where the computed 
value is not the same as parsed.


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

Yes, this part is clear.


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

Oh, right. Missed that. (Note to self: read the rest of the spec before 
saying something is missing …)


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

"Just parse as CSS" depends on whether you assume 2.1 or the css3-syntax 
ED. Comments are tokens in the former (and thus invalid, unless 
otherwise specified as ignored) but not in the latter.

HTML and SVG each define how to parse their presentational attributes, 
so they are kind of out of scope here. It would be nice if attr() was 
consistent with them both, but it doesn’t have to be.

So I guess we still have an issue of whether to allow comments in 
token-based attr() values? If we do, also consider whitespace between 
the value and a comment, or between two comments. css3-syntax’s "Parse a 
component value" would work:

http://dev.w3.org/csswg/css3-syntax/#parse-a-component-value

Or if it can not be referenced from a CR, something like "skip comments 
and whitespace tokens".

-- 
Simon Sapin

Received on Sunday, 17 February 2013 23:47:42 UTC