W3C home > Mailing lists > Public > www-style@w3.org > October 2012

Re: [cssom] Make CSSStyleSheet constructable

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 22 Oct 2012 14:32:30 -0700
Message-ID: <CAAWBYDAV683qzV7D+YfysexPPQJ3q7VUVwnRpREhU=6rhmuK+Q@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Dimitri Glazkov <dglazkov@google.com>, "www-style@w3.org" <www-style@w3.org>, Tony Ross <tross@microsoft.com>
On Mon, Oct 22, 2012 at 2:13 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> I'm not worried about reading the CSSOM here. I'm more concerned about
> script in one origin changing the sheet and affecting styles applied in
> another origin.

Why is this a problem?  (I don't have any idea.)

If it is a problem, I can imagine ways to fix it that sound like they
might be easy - for example, say that objects become readonly when
outside their constructing origin.

> On 10/22/12 5:00 PM, Tab Atkins Jr. wrote:
>> Can we just specifically neuter this?  Say that constructed
>> stylesheets explicitly drop the contents of comments (you need to
>> preserve the existence of them, unfortunately)
>
> Why?  Gecko certainly doesn't right now.

Because otherwise you can't unambiguously parse things.  I had Syntax
just dropping comments before, but dbaron complained.

Specifically, this is allowed and parsed validly: "box-shadow:
2px/**/2px;".  You can't just drop the comment, because then it'll
serialize as "box-shadow: 2px2px;", which obviously doesn't roundtrip.

You can't just do a general replacement of comments with whitespace,
either, because of something like this: ".foo/**/.bar { ... }" - the
meaning of the selector is obviously greatly changed if you replace
the comment with whitespace.

You can potentially do context-sensitive parsing, but dbaron objected
to that as well, as selectors may appear in property values in the
future, and he doesn't want to have to worry about that in the parser.

So, the only way to both maintain the current allowance around comment
insertion and avoid context-sensitive parsing is to preserve the
presence of comments in the token stream and serialization.

We could greatly limit its pollution by, say, dropping comments that
are contiguous with whitespace.  Or we could decide to change where
comments are allowed, to only allow them wherever whitespace is
allowed, rather than between every individual token.  But we can't
just drop them entirely, according to feedback I've gotten on the
Syntax spec.

~TJ
Received on Monday, 22 October 2012 21:33:18 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:01 GMT