Intent to unship: HTML scoped style sheets (<style scoped>)

HTML scoped style sheets is a feature that allows the effects of style
sheets to be scoped to a subtree of a document. Support for this
feature was introduced first in Chrome 19 behind a flag (in mid-2012)
and in Firefox 21 without a pref (in mid-2013). Since then, Chrome
removed their implementation in Chrome 37, and the feature was removed
from the spec last year due to lack of interest from other implementors.

Continuing to support <style scoped> also impacts the Quantum CSS
project, as significant work would need to be undertaken to implement
this feature, if we are to avoid differences in Web platform feature
coverage with Stylo enabled and disabled.

So we have decided to unship <style scoped>. This work is being done in
https://bugzilla.mozilla.org/show_bug.cgi?id=1291515 and I intend to
land patches in the next couple of days.

Since we are still early in the Beta cycle, and it would be helpful to
find out whether removing <style scoped> impacts Web compatibility
earlier rather than later, I also plan to uplift a patch to disable
<style scoped> in content documents to Beta.

Hey Cam,

We use a scoped stylesheet for styling the popup for <select> [1]. We chose
this route to limit performance impact as well as limit our temporary
stylesheet from affecting other parts of the browser UI. Will your removal
also remove support in the chrome/parent process?

[1] http://searchfox.org/mozilla-central/rev/2bcd258281da848311769281daf735
601685de2d/toolkit/modules/SelectParentHelper.jsm#45

Thanks,
Jared
> _______________________________________________
> dev-platform mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-platform
>

For now we'll keep <style scoped> available in chrome documents. But in
the medium term , we will want to style chrome documents with Servo too
https://bugzilla.mozilla.org/show_bug.cgi?id=1294570, and at that point
we'll have to remove <style scoped> entirely. If generating document-
wide style sheets like
<style>
#some-unique-id-12345 option { ... }
</style>

isnot performing as well as <style scoped>, we can fix that.  (We do
have plans to make this kind of style sheet addition faster than Gecko
handles it currently, which is to re-run selector matching on the entire
document.)

DevTools also uses a scoped stylesheet in its tooltip widget [1].
I have filed a bug [2] to remove it.

Cameron, what bug should this one block (iiuc chrome support will be
removed a bit later, so we have some time, do you already have a bug for
that part?)

Thanks!
Patrick

[1]
http://searchfox.org/mozilla-central/source/devtools/client/shared/widgets/tooltip/HTMLTooltip.js#643
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1374555

Thank you.
Actually, let me backtrack a little. I might be misremembering our
plans for Stylo in chrome documents. Chris or Bobby, can you remind me
whether we are still planning to target chrome documents?
If we are, then it makes it a little more urgent to remove current
usages of <style scoped>.  But I can help with that if needed.  For
Beta, though, I will still uplift a patch that just prefs it off in
content documents.

We are aiming to use Stylo for chrome documents, but it does not
necessarily need to block Stylo V1. IIUC, we can continue to use the
Gecko style system in the chrome process or documents. TY is working XBL
support now.

Yeah - stylo for the frontend would be nice, but it's not part of our MVP.

It wouldn't be hard, just presumably implementing a few more scattered
internal things and fixing more bugs exposed by the heavier usage of XBL.
But we could ship in 57 without it, and so it seems foolish to widen our
scope before driving our existing blockers to zero. If everything else is
done early, we can see whether we want to try for stylo-chrome in 57 as
well.

On Tue, Jun 20, 2017 at 10:56 AM, Chris Peterson <[email protected]>
wrote:

Thanks for confirming what I thought was the case. :-)
I'm using https://bugzilla.mozilla.org/show_bug.cgi?id=1345702 for the
removal of <style scoped> entirely.

Why only in the medium term? Restyling is very costly for browser.xul
right now, and it would be very nice if we can use Stylo to gain some
advantages there, especially since costly restyles in the parent process
do mean UI jank for our users. I realize that Stylo won't immediately
be able to style browser.xul, but it seems like we should definitely
prioritize getting rid of front-end side dependencies that would prevent
us from using it as soon as the Stylo side of things are ready and
sounds like the issue Jared mentioned is one such issue. Does this
sound right?

By medium term, I mean "not too long after 57". :-) But yes, it would
be helpful to have the existing chrome document uses of <style scoped>
removed as soon as we can. Although I figured that the work involved in
removing them wouldn't be so great, since there aren't many of them.

Even as a (web authoring) fan of <style scoped>, I agree with the
evidence/data and reasoning with this intent to unship.

FWIW, as a fan, and having used <style scoped> on my own website, I
also developed and deployed a cross-browser workaround for it,
specifically for the use-case of applying special (custom) styling to
a single post in a series of posts (stream / feed), e.g. on a home
page showing most recent posts.

* about: http://tantek.com/2015/185/t1/coded-per-post-styling-style-scoped
(with more links for more details)
* example: http://tantek.com/2015/178/t1/lovewins-css3-pride-rainbow-background

Thus it is possible, and let me know if there's anything I can help
with there on the authoring side.
(I can also publish another custom styled post to demonstrate it
working within a stream of posts if that would help).

Thanks,

Tantek

I have filed https://bugzilla.mozilla.org/show_bug.cgi?id=1375224 and
attached a patch to remove our dependency on <style scoped>.

Thanks,
Jared

On Wed, Jun 21, 2017 at 10:56 AM, Ehsan Akhgari <[email protected]>
wrote: