Re: [cssom] Make CSSStyleSheet constructable

On 10/22/12 5:32 PM, Tab Atkins Jr. wrote:
> 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.)

It seems pretty fishy to me.  I would be very loath to ship an 
implementation with that behavior and then have all the smart folks who 
poke at this stuff turn it into an unending stream of XSS exploits.

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

That doesn't sound easy to me, because it's assuming all sorts of 
concepts that don't necessarily exist at the moment, either in specs or 
in implementations (like "outside of an origin" and "readonly stylesheet").

Mind you, I think with enough pain on both the spec and implementation 
side (think perf hit on every inline style set) we might be able to get 
there, but is that cost worth it?

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

Gecko would reserialize that as:

   box-shadow: 2x 2px;

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

Sure.  You can't drop them on the _tokenizer_ level.  But the _parser_ 
can and does drop comments from the token stream, and serialization is 
quite happy without them (unless you're an editor, of course).

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

It's not clear to me why these are tied to each other.  Preserving in 
the token stream, I agree.  Preserving in stored data structures and 
serialization, on the other hand, seems to only be necessary in cases 
(like variables) where all you know about your token stream is that it's 
a token stream.  As soon as you know anything else you can drop the 
comments.

Anyway, that's wondering further afield, and I agree that in the 
variables case the parsed version of the variable would contain the 
comment tokens and hence we may need some sanitizing of them in some cases.

-Boris

Received on Monday, 22 October 2012 21:39:51 UTC