User style sheets - how useful they are? (cascading)
Stanimir Stamenkov
useful for modifying the default styling brought by UA style sheets,
given the current cascading order [1] rules. Cases where one wants
to override author styling involve using !important rules which in
my experience get effect in much more than the desired places.
Compensating for this involves greater digging into and
understanding of the author styles (which could be quite big and not
easy to read), and finally causes adding bunch of "unrelated" rules
to the user style sheet.
Especially with the introduction of the @-moz-document rules, one
usually targets at overriding few specific author declarations, but
placing !important in the user style sheet often makes it override
other more specific author rules which one may don't really want to.
For example, the web page author has supplied:
.important {
color: red;
}
.important:hover {
color: green;
}
.important.other {
color: blue;
}
and the user style sheet contains:
.important {
color: inherit !important;
font-weight: bold;
}
This makes all '.important' rules have their 'color' overridden.
While this could be the intention, also, it is more often I want to
modify just the first rule I've identified by short inspection, and
I don't want to dig further to restore the effect of other rules
I've overridden undesirably.
Does it make sense to allow user styles/style sheets to specify they
want to be treated as author ones instead of user ones in the
cascading order? Example:
@cascade author;
/* The following rules will be added to the "author" stack. */
or:
@-moz-document cascade(author) url(...) {
/* The rules in this block will be added to the "author" stack. */
}
Or does this appear detail which is better handled by the way UAs
provide style customization capabilities to users, e.g. if the
Stylish extension [2] provided an option whether specific styles
should be added as user style sheet, or just added to the
page/author style sheets.
[1] http://www.w3.org/TR/CSS2/cascade.html#cascading-order
[2] https://addons.mozilla.org/addon/stylish/
--
Stanimir
Boris Zbarsky
> Or does this appear detail which is better handled by the way UAs
> provide style customization capabilities to users, e.g. if the Stylish
> extension [2] provided an option whether specific styles should be added
> as user style sheet, or just added to the page/author style sheets.
In terms of implementation, it's a lot simpler to have external metadata
for each sheet saying where it should go in the cascade than it is to
have internal metadata or to have things going into different levels of
the cascade on a per-rule basis.
-Boris
Stanimir Stamenkov
So I've written the Stylish extension author asking him whether it
is possible to add an "User/Author" style sheet toggle and he
replied the API that Stylish uses only allows for User and UA style
types. Quick search reveals this should be:
https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIStyleSheetService
Does it make sense to extend it with additional AUTHOR_SHEET type
which would register a sheet added to the end of the list of in
document specified author sheets?
--
Stanimir
Tony Mechelynck
You mentioned the !important modifier, but don't forget the :not()
pseudo-class. For instance you could have used something like (untested)
.important:not(:hover):not(.other)
{ color: inherit !important
}
.important
{ font-weight: bold
}
Best regards,
Tony.
--
Real programmers disdain structured programming. Structured
programming is for compulsive neurotics who were prematurely toilet-
trained. They wear neckties and carefully line up pencils on otherwise
clear desks.
Stanimir Stamenkov
> You mentioned the !important modifier, but don't forget the :not()
> pseudo-class. For instance you could have used something like (untested)
>
> .important:not(:hover):not(.other)
> { color: inherit !important
> }
> .important
> { font-weight: bold
> }
Yeah, but that requires one to study much more of the author style
sheet in order come up with the more specific selector, instead of
just using the one given in the original author rule. It won't
prevent from overriding similar rules the author adds in a later
stage, also.
--
Stanimir
Tony Mechelynck
As a rule of thumb, I recommend to always have the DOM Inspector ready
when adding rules to userChrome.css or userContent.css � that tool lets
you know easily which CSS rules apply where. No need to retrieve and
analyse the full text of all the separate style sheets which may be
cascaded over any data or chrome element.
As for the Stylish extension, I've heard it praised left and right � I
don't use it myself but I suppose it has its merits. You'd have to ask
someone familiar with it about how useful or how redundant DOMi may be
if you use Stylish.
Whatever you do, if your content pages or your chrome evolve, someday
your CSS rules are going to break: I take that as a fact of life. I had
a userChrome.css set of rules to get "flowing tabs" (i.e., a multi-row
tab bar) in SeaMonkey, as a replacement for one useful feature of the
Firefox-only Tab Mix Plus extension. My rules worked perfectly in
SeaMonkey 2.0.x and in 2.1a* older than 2010-12-27; but then there was a
change in the tabbrowser XUL and my rules broke. It cost me about a week
of patient detective work before I found (with the help of DOMi) how to
get my flowing tabs back in later versions of SeaMonkey 2.1* and above,
but I finally succeeded, actually with somewhat simpler rules because
additional classes had been added where I previously had to follow
several levels of vtab > vtab > htab heredity: similarly, if you have
written an @-moz-document section for some site and the site HTML
changes, your CSS may break; then you'll have to come back and change
whatever needs changing. /C'est la vie/.
Best regards,
Tony.
--
Slowly and surely the unix crept up on the Nintendo user ...
Boris Zbarsky
> So I've written the Stylish extension author asking him whether it is
> possible to add an "User/Author" style sheet toggle and he replied the
> API that Stylish uses only allows for User and UA style types. Quick
> search reveals this should be:
>
> https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIStyleSheetService
Yep.
> Does it make sense to extend it with additional AUTHOR_SHEET type which
> would register a sheet added to the end of the list of in document
> specified author sheets?
We could do that, yeah.
-Boris
Stanimir Stamenkov
> As a rule of thumb, I recommend to always have the DOM Inspector
> ready when adding rules to userChrome.css or userContent.css � that
> tool lets you know easily which CSS rules apply where. No need to
> retrieve and analyse the full text of all the separate style sheets
> which may be cascaded over any data or chrome element.
>
> Whatever you do, if your content pages or your chrome evolve,
> someday your CSS rules are going to break: I take that as a fact of
> life...
I use the DOM Inspector extensively. It proves my use case even
better. When I look at an element I want to override the styling
for, I may see the following rule (in DOM Inspector):
.important {
color: red;
}
Then if I don't look at the full author style sheet I'll place in my
user style sheet:
.important {
color: inherit !important;
font-weight: bolder;
}
And this will additionally override author styles like:
.important:hover {
color: green;
}
.important.other {
color: blue;
}
which I don't really want. If I could register a user/custom style
with author cascading order, at the end of the author specified
sheets, like:
.important {
color: inherit;
font-weight: bolder;
}
I know I'll override just the first rule. If the author styles
further evolve in a way the given rule does not have any effect
anymore - it's great. I'll probably don't need it, or I may need to
override completely different rule. However having the user rule like:
.important {
color: inherit !important;
font-weight: bolder;
}
will continue to mess with the evolving author styles like:
.important.special {
color: blue;
}
even if I've been smart enough to initially put in my user style
sheet rule like:
.important:not(:hover):not(.other) {
color: inherit !important;
}
.important {
font-weight: bold
}
--
Stanimir
Stanimir Stamenkov
> On 8/1/11 4:55 PM, Stanimir Stamenkov wrote:
>
>> So I've written the Stylish extension author asking him whether it is
>> possible to add an "User/Author" style sheet toggle and he replied the
>> API that Stylish uses only allows for User and UA style types. Quick
>> search reveals this should be:
>>
>> https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIStyleSheetService
>>
>> would register a sheet added to the end of the list of in document
>> specified author sheets?
>
> We could do that, yeah.
I've now opened:
https://bugzilla.mozilla.org/show_bug.cgi?id=676054
--
Stanimir
Stanimir Stamenkov
> Tue, 02 Aug 2011 02:04:06 +0200, /Tony Mechelynck/:
>
>> As a rule of thumb, I recommend to always have the DOM Inspector
>> ready when adding rules to userChrome.css or userContent.css � that
>> tool lets you know easily which CSS rules apply where. No need to
>> retrieve and analyse the full text of all the separate style sheets
>> which may be cascaded over any data or chrome element.
>>
>> Whatever you do, if your content pages or your chrome evolve,
>> someday your CSS rules are going to break: I take that as a fact of
>> life...
>
> I use the DOM Inspector extensively. It proves my use case even
While I've mainly spoken for Web content, here's and example
targeting chrome:
https://bugzilla.mozilla.org/show_bug.cgi?id=539765 (see
https://bugzilla.mozilla.org/show_bug.cgi?id=512462 also)
Now I have the following rules in my "userChrome.css":
statusbar, tab, treecol, toolbarbutton { color: ButtonText !important; }
toolbarbutton[disabled=true] { color: GrayText !important; }
This unwanted overrides and clashes with colors set by certain
Personas, and "disables" the dynamic label colors of ChatZilla tabs
(indicating new messages have appeared in the channel, etc.). If I
could just "overlay" the original sheet, as if my rules were the
original ones - whole lot of problems get solved.
For the above problem I'm preparing extension employing chrome
overrides (as I can't possibly specify overlay style sheet for any
possible document, or can I?), but this will require I override
whole style sheets (like <chrome://global/skin/global.css>,
<chrome://global/skin/tabbox.css>) and then I'll have to monitor and
update them in the extension whenever unrelated style rule (such I
haven't customized) changes appear in them.
May be I could have not hit this particular problem if sheets such
as <chrome://global/skin/global.css> and
<chrome://global/skin/tabbox.css> were registered as having UA
origin, but this is probably another topic.
--
Stanimir