- From: L. David Baron <dbaron@dbaron.org>
- Date: Mon, 6 Aug 2012 00:16:01 -0700
- To: Cameron McCormack <cam@mcc.id.au>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Daniel Glazman <daniel.glazman@disruptive-innovations.com>, www-style@w3.org
On Sunday 2012-08-05 17:15 +1000, Cameron McCormack wrote:
> Tab Atkins Jr.:
> >...which Syntax also specifies. Everything here will be a bit simpler
> >once I finish up Syntax, as we'll have a clear and definite answer to
> >these kinds of questions (or at least a clear and definite base from
> >which to make alterations from).
>
> OK. One thing to take care with then is ensuring that additional
> white space is inserted between number tokens (and probably some
> others) when serializing them abutting would cause them to be
> reparsed differently. For example with:
>
> @supports (a: 1/**/.1) {}
>
> I think you would want the condition to be serialized either as "(a:
> 1 .1)" or "(a: 1 0.1)" and not "(a: 1.1)" or "(a: 10.1)", even
> though there was originally no white space token between the two
> numbers.
That might make sense in many cases, but I'm not sure it works as a
general rule; there are places in CSS where white space between
tokens does make a difference (in particular, in selectors:
"div/**/p" is not a valid selector while "div p" is).
This case is different from anything we've seen before (although I
expect variables will have similar issues), because we haven't
previously had to serialize anything other than known valid syntax
with a known meaning. Both @supports and variables introduce the
idea of storing arbitrary syntax, and APIs for both are likely to
require reserializing that syntax.
I'm inclined to agree with Cameron's original suggestion that
comments be preserved, because I don't see any other option that
preserves arbitrary syntax so that it can be re-parsed to get the
same result.
-David
--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla http://www.mozilla.org/ 𝄂
Received on Monday, 6 August 2012 07:16:37 UTC