[meta] Move out parts of global.css into their own files
Categories
(Toolkit :: Themes, task)
Tracking
()
People
(Reporter: ntim, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: meta)
With Shadow DOM, only document stylesheets included within the shadow DOM and UA sheets (e.g. xul.css) apply.
Some CE (e.g. menupopup and panel) use classes from global.css in their shadow DOM markup, and currently they include the complete chrome://global/skin/global.css.
I was looking into using shadow DOM for popupnotification (bug 1625931), and it uses the .panel-footer and .close-icon classes from global.css. Including global.css is far from ideal since it includes all stylesheets from widgets.css and a bunch of other classes.
My proposal would be moving out parts like .close-icon into their own file like close-icon.css then importing them from global.css (for non-shadow consumers) and from the shadow DOM of the relevant consumers as:
<html:link rel="stylesheet" href="chrome://global/skin/close-icon.css"/> (from the shadow DOM markup)
or
@import url(chrome://global/skin/close-icon.css) (from the relevant component stylesheet).
I don't have a strong preference for one or the other.
Dão, what do you think of this plan? Just to be clear, I'm only planning to start with the classes I need.
| Reporter | ||
Updated•5 years ago
|
Comment 1•5 years ago
|
||
(In reply to Tim Nguyen :ntim from comment #0)
My proposal would be moving out parts like
.close-iconinto their own file likeclose-icon.cssthen importing them fromglobal.css(for non-shadow consumers) and from the shadow DOM of the relevant consumers as:
<html:link rel="stylesheet" href="chrome://global/skin/close-icon.css"/>(from the shadow DOM markup)
Sounds good to me for this particular case, not sure how well it scales. I guess alternatively we could style ::part(close-icon) in global.css?
| Reporter | ||
Comment 2•5 years ago
•
|
||
(In reply to Dão Gottwald [::dao] from comment #1)
(In reply to Tim Nguyen :ntim from comment #0)
My proposal would be moving out parts like
.close-iconinto their own file likeclose-icon.cssthen importing them fromglobal.css(for non-shadow consumers) and from the shadow DOM of the relevant consumers as:
<html:link rel="stylesheet" href="chrome://global/skin/close-icon.css"/>(from the shadow DOM markup)Sounds good to me for this particular case, not sure how well it scales. I guess alternatively we could style
::part(close-icon)inglobal.css?
The problem with ::part(close-icon), in addition to the verbosity of maintaining both selectors, is that selectors like these don't work:
.close-icon > .button-icon,
.close-icon > .button-box > .button-icon,
.close-icon > .toolbarbutton-icon {
Comment 3•5 years ago
|
||
(In reply to Tim Nguyen :ntim from comment #2)
The problem with
::part(close-icon), in addition to the verbosity of maintaining both selectors,
There are four rules in global.inc.css so I don't think I buy that argument.
is that selectors like these don't work:
.close-icon > .button-icon, .close-icon > .button-box > .button-icon, .close-icon > .toolbarbutton-icon {
Could be exposed as another part, e.g. "close-icon-image"?
| Reporter | ||
Comment 4•5 years ago
|
||
(In reply to Dão Gottwald [::dao] from comment #3)
is that selectors like these don't work:
.close-icon > .button-icon, .close-icon > .button-box > .button-icon, .close-icon > .toolbarbutton-icon {Could be exposed as another part, e.g. "close-icon-image"?
This isn't possible because the toolbarbutton and button custom elements don't use Shadow DOM. It would be a lot of work to start using shadow DOM for those elements (checking perf since those elements are widely used, fixing tests, rewriting external styles to shadow parts) and I suspect the cost-benefit isn't worth it at this point.
Updated•3 years ago
|
Description
•