W3C home > Mailing lists > Public > www-style@w3.org > May 2011

Re: [css3-cascade] Browser extension style sheets and the cascade

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 17 May 2011 12:58:42 -0400
Message-ID: <4DD2A942.1020200@mit.edu>
To: "Jens O. Meiert" <jens@meiert.com>
CC: www-style@w3.org
On 5/17/11 12:43 PM, Jens O. Meiert wrote:
>> Isn't that up to the browser and/or extension?
>> […] If an extension wants to apply CSS to pages, it should, imo, be
>> free to put it in the right cascade level depending on what that CSS is
>> doing.
>> As a simple example, ad-blocking CSS probably belongs in the user level.
>> But CSS for implementing a subset of MathML functionality in a browser with
>> no native MathML support belongs in the UA level.
> That does not convince me yet that inevitably, this has to be a user
> agent decision.

To be clear, in Gecko's case it is the extension's decision.  The 
extension knows what it's doing and is in the best position to decide 
how to expose that in the CSS cascade.

> Neither am I convinced yet that this situation is
> actually beneficial for extension authors, authors, or even users (who
> will need to maintain the possibility of having the last say on
> styling, no matter how few people actually use user style sheets).

Users always have the last say (for example, they can uninstall 

> Back to why the spec may help, isn’t this problem a very valid and
> real CSS use case that would be particularly useful for implementors
> to have covered? So far I wouldn’t understand why a blind spot in the
> spec would be in any way beneficial.

What should the spec say, exactly?  An extension is just part of the UA; 
the concept of differentiating between the two doesn't really make that 
much sense.

More concretely, say you have an extension that exposes UI to manage 
user stylesheets.  It seems obvious that it should have the option of 
placing stylesheets in the user level, right?  Or do you disagree with that?

Received on Tuesday, 17 May 2011 16:59:10 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:46 UTC