(In reply to Sam Foster [:sfoster] (he/him) from comment #3)
I'm looking at how to break this down into actionable bugs. Basically, if we imagine a tree of CSS files which import/include other CSS files, we need roughly one bug for each non-empty node in that tree (though some we may be able to group together.)
Quite a number of these
%includes are from a platform-specific "parent" stylesheet, which maybe defines some
var()s and some overrides, then includes all the shared rules. There's 2 obvious ways to handle this case:
- We can inline the included stylesheet and move those platform-specifics into @media blocks - resulting in a single shared stylesheet for all platforms. This will contain some rules in there that will never be applicable for other platforms. Maybe that's ok. Maybe we treat that as an optimization problem at build time - culling out @media blocks which will never match (if we measure a problem that warrants this.)
- We leave the structure as-is, and
@import the shared stylesheet instead of
%include-ing it. For the most part that should work ok. There may be cases where going from
%include e.g. at the bottom of the stylesheet, to @import at the top may change the cascade, so some case will be needed.
So, I think that might be a case by case decision, and it makes sense to have a bug for each.
Where we have nested includes - notably in platform-specific browser.css, browser.inc.css, and toolkit global.css - I suggest we work our way up the include/import tree in the same manner as above. Does that sounds reasonable?
Yes. For browser.css especially, I also wonder if some stuff could be imported dynamically to reduce potential performance impact. We shouldn't need UITour sheets until UITour actually starts. Ditto the translation infobar and the "edit bookmark" panel, the sidebar, etc. etc. We'd need to be cautious about the impact of images linked from such sheets not being preloaded, however.
Note that if we want to have an import for the
shared sheet, in an ideal world we change packaging such that we can use a relative import that can be resolved both in the source tree and the built URL set. This would mean some changes to packaging (so that, e.g. for downloads, the shared sheet ends up in a subdirectory like
chrome://browser/skin/shared/downloads.css and the non-shared sheet can import
../shared/downloads.css or something), but should be doable in a bunch of cases. That would help with the linting etc. so that tools can resolve the URLs (which they cannot for
Its a lot of bugs to file so I would appreciate a sanity-check before I start.
I'd start with the non-browser.css, non-global.css trees to get some practice, so it's less daunting and complex, and there's immediate results (ie more files that we can lint, whereas solving something deep inside the tree for
browser.css won't improve things as quickly if the resulting files still have other includes).