Closed Bug 1457907 Opened 6 years ago Closed 6 years ago

"!important" rules in UA stylesheets replacing XBL stylesheets cannot be overridden

Categories

(Core :: CSS Parsing and Computation, enhancement, P3)

Product:
Core
Component:
CSS Parsing and Computation
Type:
enhancement

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: Paolo, Unassigned)

References

Details

Apparently, rules marked as "!important" in UA stylesheets cannot be overridden by other "!important" rules in regular stylesheets, even with higher specificity. This is an issue because we are using this type of stylesheets as a possibly easy way to replace XBL stylesheets.

This came up first in bug 1448822, but right now while working on bug 1446800 I noticed that this makes the alignment of the "Show All Bookmarks" item in the Bookmarks Menu incorrect on Windows, and not easily overridable.

If the platform does not support exactly what we want, we may have to edit these stylesheets heavily during the conversion anyways, that makes me wonder whether we should use UA stylesheets in the first place.

Thoughts?
Flags: needinfo?(bzbarsky)
Flags: needinfo?(bgrinstead)
Also, the inspector is apparently unable to process these rules correctly, so debugging becomes difficult as what is shown does not match reality.
I expect Boris will know more about why this happens, but I'll just note that we did discuss instead loading the sheets as preshints (https://bugzilla.mozilla.org/show_bug.cgi?id=1420229#c23), but it wasn't available at the time. I'd like to know how hard it would be to add that capability, which would have the additional benefit being closer to XBL sheet importance.
Flags: needinfo?(bgrinstead)
> rules marked as "!important" in UA stylesheets cannot be overridden by
> other "!important" rules in regular stylesheets

Sure.  See spec at https://drafts.csswg.org/css-cascade-3/#cascade-origin which clearly spells this out.  You might notice that in that spec !important reverses the relative precedence of origins, mostly.  For example, any normal author rule has higher precedence than any normal UA rule, but any !important UA rule has higher precedence than any !important author rule.  The exception is the override level, which has higher precedence than author both ways.

I believe what Gecko implements for XBL is more or less the opposite of override.  That is, XBL fits in at 5.5 (for XBL !important rules) and 8.5 (for normal XBL rules) in the above-linked spec list.

Thus there is no existing spec concept that behaves like XBL rules.

Putting things at the "preshint" level would not help per se, because there is no concept of !important preshints.  And when defining such a concept one would still need to decide where they go in the cascade.

Anyway, the upshot is this: We need to (1) eliminate use of !important in the relevant sheets or (2) deal with it changing precedence or (3) add a new non-spec cascade level for this stuff and keep carting it around in perpetuity.

That said, it's worth checking what the spec proposals are for shadow DOM styles and their precedence...  Maybe that would effectively give us (3)?
Flags: needinfo?(bzbarsky)
What's the reasoning for using UA sheets in the first place? Just overriding existing author styles?

(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #3)
> That said, it's worth checking what the spec proposals are for shadow DOM
> styles and their precedence...  Maybe that would effectively give us (3)?

We do implement (correctly, to the best of my knowledge), the rules for Shadow DOM. See the SameTreeNormal and InnerShadowNormal bits in [1].

Shadow DOM allows !important in "inner" trees to override !important in "outer" trees (including style attribute). I can try to explain the exact rules, since they're difficult to grasp.

Introducing a new cascade order looks like a huge pain to me, requires us to have extra storage for those rules, extra logic which isn't well-defined, etc... I'd really try to avoid it.

What's the wanted behavior from these stylesheets?

[1]: https://searchfox.org/mozilla-central/rev/08df4e6e11284186d477d7e5b0ae48483ecc979c/servo/components/style/stylist.rs#1255
Flags: needinfo?(paolo.mozmail)
Component: XUL → CSS Parsing and Computation
> What's the reasoning for using UA sheets in the first place? Just overriding existing author styles?

It's sort of like the UA sheet bits for HTML: in theory the XBL provides the default widget look which authors can then override.

> What's the wanted behavior from these stylesheets?

The current behavior is that normal rules in these sheets are overridden by normal rules in author sheets and !important rules in these sheets are overridden by !important rules in author sheets...
(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #5)
> > What's the reasoning for using UA sheets in the first place? Just overriding existing author styles?
> 
> It's sort of like the UA sheet bits for HTML: in theory the XBL provides the
> default widget look which authors can then override.
> 
> > What's the wanted behavior from these stylesheets?
> 
> The current behavior is that normal rules in these sheets are overridden by
> normal rules in author sheets and !important rules in these sheets are
> overridden by !important rules in author sheets...

Alright, I thought that De-XBL would also change the setup here rather than just moving styles around.

So the current behavior for XBL is the opposite to what Shadow DOM does now. At least for Shadow DOM, the point is that !important rules in Shadow trees override important rules everywhere else (even the style attribute). The reason for it is that !important in the Shadow Tree allows "blocking" the styles from being modified if needed.

See https://github.com/w3c/csswg-drafts/issues/2290#issuecomment-382465643 for Tab explaining why this is.

If so, it looks like that means that at least for non-nested cases Shadow DOM would behave as UA sheets behave now (assuming that XBL doesn't override actual UA sheets !important rules). Thus I'd prefer to not introduce a new cascade level that will make harder both using Shadow DOM & getting rid of this new level on the long term.
(In reply to Emilio Cobos Álvarez [:emilio] (Away-ish from 27/04 to 09/05) from comment #6)
> If so, it looks like that means that at least for non-nested cases Shadow
> DOM would behave as UA sheets behave now (assuming that XBL doesn't override
> actual UA sheets !important rules). Thus I'd prefer to not introduce a new
> cascade level that will make harder both using Shadow DOM & getting rid of
> this new level on the long term.

Of course if it's really a _lot_ of pain it may make sense to add it I guess, but I fear that the work to shuffle the styles one de-xbl is done so that they'd work using Shadow DOM / UA sheets, and so that we could eventually remove it will not be really prioritary, and we'll be stuck with this cascade level ~forever.
(In reply to Emilio Cobos Álvarez [:emilio] (Away-ish from 27/04 to 09/05) from comment #7)
> one de-xbl is done [..]

Should read *once* de-xbl is done
(In reply to Emilio Cobos Álvarez [:emilio] (Away-ish from 27/04 to 09/05) from comment #6)
> (In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from
> comment #5)
> > > What's the reasoning for using UA sheets in the first place? Just overriding existing author styles?
> > 
> > It's sort of like the UA sheet bits for HTML: in theory the XBL provides the
> > default widget look which authors can then override.
> > 
> > > What's the wanted behavior from these stylesheets?
> > 
> > The current behavior is that normal rules in these sheets are overridden by
> > normal rules in author sheets and !important rules in these sheets are
> > overridden by !important rules in author sheets...
> 
> Alright, I thought that De-XBL would also change the setup here rather than
> just moving styles around.

The idea for components.css is to give a place to put previously XBL stylesheets in a way that prevents us from having to rewrite the CSS / markup as we migrate individual bindings. The first stylesheet we migrated was originally put into a document style, but then we realized how much work tracking down and fixing style regressions was going to be. This decision was made in https://bugzilla.mozilla.org/show_bug.cgi?id=1416493#c26. IOW: it was done this way to make de-xbl less of a frontend rewrite.

We could revisit this decision given this bug. It could be the case that one or both of these things are true:
(1) We just had bad luck with menu.css and other sheets won't have as many conflicts when migrating to a document sheets (or the conflicts that come up will be easier to find/fix)
(2) We should refactor/rewrite CSS and markup in the process of converting a binding away from XBL

Although I'm not convinced. Even though I'd like to move to Shadow DOM or document stylesheets ultimately, tracking down CSS regressions caused by a cascade changes and interaction with other document sheets is pretty nasty business and I'd rather not couple that together with the ongoing XBL work. Maybe we can live with not using/being able to override !important from the ex-XBL/future-UA sheets? I don't have a good sense for how much work that saves vs converting them to SD/document sheets.
> IOW: it was done this way to make de-xbl less of a frontend rewrite.

Right.  I think we just didn't consider that XBL sheets would be using !important rules... So one question is: can we just get rid of those?
(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #10)
> > IOW: it was done this way to make de-xbl less of a frontend rewrite.
> 
> Right.  I think we just didn't consider that XBL sheets would be using
> !important rules... So one question is: can we just get rid of those?

Or alternatively: live with not being able to override the !important styles. It's hard to analyze exactly when a rule will get overridden from the frontend (or by looking at code). I wonder if we can instrument a try run to print any time this ends up happening. Is that something that's relatively easy to get at from the platform side where we could detect every time a XBL resource sheet has an !important rule that gets overridden by a document style?
Also, I guess we should generally prefer to import a binding's stylesheet as a document sheet or SD sheet if it's relatively simple / low-risk to do so.
ni? for Comment 11
Flags: needinfo?(emilio)
(In reply to Brian Grinstead [:bgrins] from comment #11)
> (In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from
> comment #10)
> > > IOW: it was done this way to make de-xbl less of a frontend rewrite.
> > 
> > Right.  I think we just didn't consider that XBL sheets would be using
> > !important rules... So one question is: can we just get rid of those?
> 
> Or alternatively: live with not being able to override the !important
> styles. It's hard to analyze exactly when a rule will get overridden from
> the frontend (or by looking at code). I wonder if we can instrument a try
> run to print any time this ends up happening. Is that something that's
> relatively easy to get at from the platform side where we could detect every
> time a XBL resource sheet has an !important rule that gets overridden by a
> document style?

To some extent, yeah. It's not terribly hard. Probably better if it was debug-only, presumably. And likely easier with bug 1458192, though we can also do it without I guess. Wanna file a bug for something like that? Do you want it to crash when that happens, or something else?

I imagine it should be a matter of asserting you're not an XBL important rule here:

  https://searchfox.org/mozilla-central/rev/8837610b6c999451435695e800f38d4acbc0a644/servo/components/style/properties/properties.mako.rs#3679

Maybe we need to keep track of another LonghandIdSet instead of just `seen` to avoid preventing false positives from some XBL rules overriding other XBL rules. But that'd be the easiest approach I think.

With bug 1458192 we'd just need to use a particular cascade order for XBL and all the data would be there already, which makes it a bit less invasive. Without it we'd need a bit more juggling around, but nothing terrible I suspect... Still it'd be slightly displeasing given that code is already complicated, but that'd be much easier to get rid of so I'm in if it avoids a new cascade level.
Flags: needinfo?(emilio)
(In reply to Emilio Cobos Álvarez [:emilio] (Away-ish from 27/04 to 09/05) from comment #14)
> (In reply to Brian Grinstead [:bgrins] from comment #11)
> > (In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from
> > comment #10)
> > > > IOW: it was done this way to make de-xbl less of a frontend rewrite.
> > > 
> > > Right.  I think we just didn't consider that XBL sheets would be using
> > > !important rules... So one question is: can we just get rid of those?
> > 
> > Or alternatively: live with not being able to override the !important
> > styles. It's hard to analyze exactly when a rule will get overridden from
> > the frontend (or by looking at code). I wonder if we can instrument a try
> > run to print any time this ends up happening. Is that something that's
> > relatively easy to get at from the platform side where we could detect every
> > time a XBL resource sheet has an !important rule that gets overridden by a
> > document style?
> 
> To some extent, yeah. It's not terribly hard. Probably better if it was
> debug-only, presumably. And likely easier with bug 1458192, though we can
> also do it without I guess. Wanna file a bug for something like that? Do you
> want it to crash when that happens, or something else?

I don't think we even need to land anything. I'm just looking for a try push that prints out or appends a line to a file whenever we hit this case so we have a general idea of how often and where we rely on this behavior (as a way to help make a decision on how to proceed here). If we knew the the location (file name / line number) of the XBL rule and the location of the document rule that's overriding it I think that'd be enough.
Yeah, this will help a lot with cases like bug 1448822 where we didn't remove the "!important" from the XBL stylesheet that we converted to a UA stylesheet because we didn't know what parts of the interface this would affect.
Flags: needinfo?(paolo.mozmail)
Alright, what about something like this:

  https://treeherder.mozilla.org/#/jobs?repo=try&revision=661050d16057fd36e6ebf1ed83a49f733f92160f

This prints for me, for example, when I toggle the drop down for the awesomebar:

  XBL important declaration for overflow-x from "#PopupAutoCompleteRichResult > richlistbox > scrollbox" at SourceLocation { line: 554, column: 1 } would override another declaration that applies to <scrollbox> (0x7f89113c5a60) (None): Some(".autocomplete-richlistbox > scrollbox")

Which means that the rule at:

  https://searchfox.org/mozilla-central/rev/8837610b6c999451435695e800f38d4acbc0a644/browser/base/content/browser.css#606

Would override (if it's inserted afterwards, not if it's prepended in this case, since the overriden sheet is a UA sheet):

  https://searchfox.org/mozilla-central/rev/8837610b6c999451435695e800f38d4acbc0a644/toolkit/content/xul.css#769

In any case it doesn't matter because the UA rule is the same, so that rule is useless (have I just found a good-first-bug? :P).

Some caveats:

 * Doesn't print the Sheet URL because I don't have it readily available. I could write more code for that, but finding the rule given the element, property and the selector should be trivial.

 * As you've seen, it doesn't handle declarations that would have the same effect. It'd be slightly annoying but doable, so let me know if you want me to do that.

 * It prints at style resolution time, which means it may print the same line multiple times if it affected multiple elements, or if the style of the element was recalculated. Generally most of the lines I expect them to be duplicates. Removing duplicates on your side shouldn't be much work, but let me know if it would.

Brian, Paolo, would something like that work for your purposes?
Flags: needinfo?(paolo.mozmail)
Flags: needinfo?(bgrinstead)
Also, we could split the css file into two files, where the non-`!important` rules would go into one stylesheet, which would then be loaded as a UA stylesheet, and all the `!important` rules would go into the other stylesheet, which would be loaded as an author stylesheet, which should solve most of the issues.
Priority: -- → P3
I prepared a simple test case based on the situation bug 1446800. This uses the macOS stylesheet since this is where I'm building right now, but it can be ported to other platforms. In fact, the issue originally appeared on Windows.

The starting point is:

https://hg.mozilla.org/try/rev/52176327c9cd760d4748a39b6292b704e36301e5
https://hg.mozilla.org/try/rev/244e73c35cd19a1f362cbe7323cfd281225170b3

We have both a STD-Normal rule and a STD-Important rule in the browser window stylesheet. The latter is supposed to overrride the XBL-Important rule, which is located in "menu.css", loaded a XBL stylesheet.

In this situation, if you add the "Bookmarks Menu" button to the toolbar and open it, you see a margin before the menu item text, but not before the "Show All Bookmarks" footer text.

Now we convert "menu.css" to a UA stylesheet:

https://hg.mozilla.org/try/rev/e9e0b749fad168ba98c804d45ee55587b0fe74b8

This breaks the footer text, which now has a margin before it, because XBL-Important overrides STD-Important. To fix this, we remove "!important" from the XBL rule:

https://hg.mozilla.org/try/rev/e067d24b00750fb927ba60ca634f7b9d7e598454

This fixes the problem with the footer, but introduces a problem with the menu items because the STD-Normal rule is not overridden anymore.

I think the patch from comment 17 and 19 needs rebasing now, so I didn't try it, but probably it doesn't provide all the information that we need anyways, because for the above case we need to extract three rules:

* The XBL-Important rule
* Any STD-Important rules that override it, creating a potential issue
  - If there are none, we may choose to leave the XBL rule as important, even though this may limit our styling options in the future
* Any STD-Normal rule that would create and issue when converting XBL-Important rule (as UA rule) to a normal UA rule
  - If we detect none, we have a little bit more confidence that can remove "!important" safely

Note that we can run the automation before and/or after the conversion from XBL to UA stylesheet to collect this information.

Emilio, do you think we can collect the information we need for the above example?
Flags: needinfo?(paolo.mozmail)
Flags: needinfo?(emilio)
Flags: needinfo?(bgrinstead)
Depends on: 1458426
See Also: → 1458426
Emilio and Boris - how bad is it technically (amount of upfront work, ongoing cost of complexity) to add a new cascade level that matches XBL sheets in terms of cascade, !important semantics, and not being considered UA? We are also seeing some strange behavior with menus when a user sets the 'Override the colors specified by the page' setting in about:preferences that I think is related to this via mUseDocumentColors.

I totally get the concern in Comment 7 about us never going back and deleting it. And I even can't commit that we'll prioritize converting ported styles to SD/document sheets, since finishing removing bindings is too far out to make any reasonable commitments. So just trying to get a sense for the cost we'd take on to do a new cascade vs dealing with UA sheets on a case-by-case basis.
Flags: needinfo?(bzbarsky)
No longer depends on: 1458426
I'm out of the loop enough on stylo that I can't easily answer this question.  Punting to Emilio.
Flags: needinfo?(bzbarsky)
(In reply to Brian Grinstead [:bgrins] from comment #21)
> Emilio and Boris - how bad is it technically (amount of upfront work,
> ongoing cost of complexity) to add a new cascade level that matches XBL
> sheets in terms of cascade, !important semantics, and not being considered
> UA? We are also seeing some strange behavior with menus when a user sets the
> 'Override the colors specified by the page' setting in about:preferences
> that I think is related to this via mUseDocumentColors.

So, I thought a bit about it, and there would be a few things to figure out... First of all is how to distinguish these stylesheets (I assume they'd only be added via a JS API or such?).

Right now UA sheets have a different origin, parsing mode and such, and thus we can distinguish them trivially. XBL sheets are normal author sheets stored in a different place, so we can also distinguish them easily.

The key is that to implement a different cascade level efficiently, you need the computed style data[1] stored in a different place as the other cascade levels.

Right now the way this works is:

 * If the sheet is document-level, then we store it per origin (author, user, user-agent), and that's the cascade-level of the rules in there. Right now we key a lot[2] of document-level things per origin, we'd need to add some sort of fourth origin, which wouldn't be defined in any spec, or treat them as author sheets (preferable I guess), but then we need another bit other than "Origin" to distinguish them, which not great.

 * If the sheet is not document-level (Shadow DOM / XBL), those are normal author sheets, which get stored in another place[3], somewhere reachable from the element the rules apply to, so we can apply them at a different step of the cascade.

I'm assuming we want these to be document-level sheets. Which means that we'd need to either add a new stylesheet origin, or stop keying stuff in terms of origin, and start doing it in terms of (origin, AuthorStyleSheetType) or something like that.

In general, it's probably simpler to add a new stylesheet origin completely, because it'd be way less code to change. Also, it's probably the less annoying thing to do in terms of maintenance. It's still probably non-trivial though, and I'd rather avoid it if possible.

[1]: https://searchfox.org/mozilla-central/rev/2aa42f2cab4a110edf21dd7281ac23a1ea8901f9/servo/components/style/stylist.rs#1949
[2]: https://searchfox.org/mozilla-central/rev/2aa42f2cab4a110edf21dd7281ac23a1ea8901f9/servo/components/style/stylesheets/origin.rs#102
[3]: https://searchfox.org/mozilla-central/rev/2aa42f2cab4a110edf21dd7281ac23a1ea8901f9/servo/components/style/author_styles.rs#21
(In reply to Emilio Cobos Álvarez [:emilio] from comment #23)
> (In reply to Brian Grinstead [:bgrins] from comment #21)
> > Emilio and Boris - how bad is it technically (amount of upfront work,
> > ongoing cost of complexity) to add a new cascade level that matches XBL
> > sheets in terms of cascade, !important semantics, and not being considered
> > UA? We are also seeing some strange behavior with menus when a user sets the
> > 'Override the colors specified by the page' setting in about:preferences
> > that I think is related to this via mUseDocumentColors.
> 
> So, I thought a bit about it, and there would be a few things to figure
> out... First of all is how to distinguish these stylesheets (I assume they'd
> only be added via a JS API or such?).

We'd have flexibility on how we load these sheets. A couple of options:

1) We could keep them document level and loaded globally through a sheet like components.css (appended in nsDocumentViewer::CreateStyleSet)
2) If we wanted to scope them to an element like XBL sheets do we could have a JS API that gets run in the connectedCallback / construtor on the Custom Element or similar. Or maybe a static property with the path to the sheet on the Custom Element class that gets stored in the registry and processed from C++.

I think (2) would actually be the smoothest transition from XBL sheets since there are likely selectors in existing XBL sheets are quite generic and assume they won't apply to the document. But either way would be workable. Is one of those easier than the other?
(In reply to Brian Grinstead [:bgrins] from comment #24)
> (In reply to Emilio Cobos Álvarez [:emilio] from comment #23)
> > (In reply to Brian Grinstead [:bgrins] from comment #21)
> > > Emilio and Boris - how bad is it technically (amount of upfront work,
> > > ongoing cost of complexity) to add a new cascade level that matches XBL
> > > sheets in terms of cascade, !important semantics, and not being considered
> > > UA? We are also seeing some strange behavior with menus when a user sets the
> > > 'Override the colors specified by the page' setting in about:preferences
> > > that I think is related to this via mUseDocumentColors.
> > 
> > So, I thought a bit about it, and there would be a few things to figure
> > out... First of all is how to distinguish these stylesheets (I assume they'd
> > only be added via a JS API or such?).
> 
> We'd have flexibility on how we load these sheets. A couple of options:
> 
> 1) We could keep them document level and loaded globally through a sheet
> like components.css (appended in nsDocumentViewer::CreateStyleSet)
> 2) If we wanted to scope them to an element like XBL sheets do we could have
> a JS API that gets run in the connectedCallback / construtor on the Custom
> Element or similar. Or maybe a static property with the path to the sheet on
> the Custom Element class that gets stored in the registry and processed from
> C++.
> 
> I think (2) would actually be the smoothest transition from XBL sheets since
> there are likely selectors in existing XBL sheets are quite generic and
> assume they won't apply to the document. But either way would be workable.
> Is one of those easier than the other?

I'd be opposed to adding a third form of style scoping for this (we have already XBL and Shadow DOM, and the benefit of getting rid of XBL is reducing complexity, this wouldn't help I think).

If you don't want to move to Shadow DOM directly from XBL (that'd be even easier :P, I'm assuming that has been considered already?), more than probably (1) would be easier.

It may be worth chiming in https://github.com/w3c/webcomponents/issues/468, since they're discussing different stuff about how to add styles to a custom element without Shadow DOM. Probably the "only compound selectors" approach wouldn't work for you. Google is working in prototyping also this "Fake Shadow Root" thing. I think it's quite hard for them to get buy-in (that "Fake Shadow Root" thing is pretty weird IMO), but your feedback may be valuable.
(In reply to Emilio Cobos Álvarez [:emilio] from comment #25)
> (In reply to Brian Grinstead [:bgrins] from comment #24)
> > (In reply to Emilio Cobos Álvarez [:emilio] from comment #23)
> > > (In reply to Brian Grinstead [:bgrins] from comment #21)
> > > > Emilio and Boris - how bad is it technically (amount of upfront work,
> > > > ongoing cost of complexity) to add a new cascade level that matches XBL
> > > > sheets in terms of cascade, !important semantics, and not being considered
> > > > UA? We are also seeing some strange behavior with menus when a user sets the
> > > > 'Override the colors specified by the page' setting in about:preferences
> > > > that I think is related to this via mUseDocumentColors.
> > > 
> > > So, I thought a bit about it, and there would be a few things to figure
> > > out... First of all is how to distinguish these stylesheets (I assume they'd
> > > only be added via a JS API or such?).
> > 
> > We'd have flexibility on how we load these sheets. A couple of options:
> > 
> > 1) We could keep them document level and loaded globally through a sheet
> > like components.css (appended in nsDocumentViewer::CreateStyleSet)
> > 2) If we wanted to scope them to an element like XBL sheets do we could have
> > a JS API that gets run in the connectedCallback / construtor on the Custom
> > Element or similar. Or maybe a static property with the path to the sheet on
> > the Custom Element class that gets stored in the registry and processed from
> > C++.
> > 
> > I think (2) would actually be the smoothest transition from XBL sheets since
> > there are likely selectors in existing XBL sheets are quite generic and
> > assume they won't apply to the document. But either way would be workable.
> > Is one of those easier than the other?
> 
> I'd be opposed to adding a third form of style scoping for this (we have
> already XBL and Shadow DOM, and the benefit of getting rid of XBL is
> reducing complexity, this wouldn't help I think).
> 
> If you don't want to move to Shadow DOM directly from XBL (that'd be even
> easier :P, I'm assuming that has been considered already?), more than
> probably (1) would be easier.

Yeah, migrating to Shadow DOM sheets will cause even more frontend rewriting than converting them to document sheets, since the XBL sheets are currently less important than document sheets and the SD sheets will be more important. The biggest hurdle right now IMO is the cascade and not the scoping so I'd be happy to punt on scoping for now.

The cascade change with UA sheets is workable, except unfortunately we are seeing other side effects of being UA like this bug and bug 1458426. I think we'd also be OK with being in the UA cascade but not identified as "UA" for other purposes (not sure if that would be more or less complex than the potential solution you outline in Comment 23).

> It may be worth chiming in https://github.com/w3c/webcomponents/issues/468,
> since they're discussing different stuff about how to add styles to a custom
> element without Shadow DOM. Probably the "only compound selectors" approach
> wouldn't work for you. Google is working in prototyping also this "Fake
> Shadow Root" thing. I think it's quite hard for them to get buy-in (that
> "Fake Shadow Root" thing is pretty weird IMO), but your feedback may be
> valuable.

OK I'll have a look, thanks.
Depends on: 1463820
Trying to figure out our options for Bug 1458426 - looking into loading these as document and shadow DOM sheets in Bug 1463820, although both are appearing to be a lot of work.

Emilio, would it be possible to give a rough estimate of the amount of work required to add the new origin as mentioned in Comment 23? Or alternatively somehow allowing sheets to be included in the UA cascade but not being identified as "UA" for other purposes (if that's even possible) as mentioned in Comment 26.
Sorry for the huge lag here. Adding a new origin seems a lot of churn and something that I'm not convinced we would get rid of soon.

Marking a rule node as coming from chrome rules, and apply special-casing for something like bug 1458426 is probably doable without too much churn...
I think we discussed most of this in person this week. I can prepare a build that prints XBL stuff that crosses shadow boundaries, or other similar stuff like the !important bits mentioned here I think, should it be needed.
Flags: needinfo?(emilio)
Blocks: 1470830
Thanks Emilio, I filed bug 1470840 with some more details of what we'd need from a build that detects which rules would be affected by the conversion away from XBL. Given the conclusion that we're not using UA stylesheets or new platfrom cascade levels going forward, I'm also closing this bug.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
No longer blocks: 1470830
Depends on: 1470830
You need to log in before you can comment on or make changes to this bug.