Intent to remove <style scoped>

[Elliott Sprehn]

Primary eng (and PM) emailsesp...@chromium.org

SummaryRemove <style scoped>
MotivationThis feature is not maintained, not shipping and no progress has been made in 5 months. It also adds a lot of complexity to how the scoped style system works for Shadow DOM.
Previous discussion and support for removal is here: 
https://groups.google.com/a/chromium.org/d/topic/blink-dev/JB8nFQXhAuQ/discussion
Compatibility RiskNone
Row on feature dashboard?http://www.chromestatus.com/features/5374137958662144
Requesting approval to remove too?Yes

[Tab Atkins Jr.]

LGTM

I'm not 100% sure whether we actually want to pursue this feature or
not in the future, but regardless, we can take up that question later.

On Wed, Mar 19, 2014 at 3:34 PM, Elliott Sprehn <esp...@chromium.org> wrote:
> Primary eng (and PM) emails...@chromium.org

> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+...@chromium.org.

[Hayato Ito]

LGTM.

<style scoped> has been burden for us to maintain.

I've felt several times that <style scoped> is the cause of code complexity when I work on Shadow DOM styling.

I'm not saying that blink shouldn't support <style scoped>.

I am saying that we can get benefits from the view of hack-ability of style system if we can forget <style scoped>.

We can reimplement <style scoped> later once we feel it's needed.

--
Hayato

[Adam Barth]

LGTM

[Ojan Vafai]

LGTM

[TAMURA, Kent]

LGTM3

--
TAMURA, Kent
Software Engineer, Google

[ethan...@gmx.net]

hi, without scoped css web components make no sense.

[Adam Barth]

Style are still scoped to ShadowRoots, which means they still work properly for web components.  This mechanism was duplicate functionality that let you scope styles at arbitrary points in the DOM.

Adam

[Tab Atkins Jr.]

On Tue, Apr 1, 2014 at 1:16 AM, <ethan...@gmx.net> wrote:
> hi, without scoped css web components make no sense.

The CSS-related behaviors of Web Components are completely unrelated
to scoped styles. Shadow DOM does not use scoped styles in any
meaningful sense.

~TJ

[danny...@gmail.com]

Very sad to see this one go. This feature was convenient for testing purposes and also served as a hacky workaround for cached and merged css/js files being served by CDN :((

[PhistucK]

It is probably very easy to emulate using an extension or a bookmarklet (looks for <style scoped>, adds #some-generated-unique-id to all of the non at-rules and adds an id="some-generated-unique-id" to the containing element, or uses the existing ID), if you are only talking about testing purposes.

☆PhistucK

[lonn...@startport.com]

This feature excites me more than any other I've seen in recent years. It allows each module to essentially "style itself" overriding unwanted cascading/inherited styles. Its a great flexibility that should have been there from the beginning.

Consider this, when it comes to the current state of inline styling, you can't put a selector into html attributes. For example, you can't do this:

<div style="span{color:red}">
    This is <span>red</span>.
</div>

The style attribute only has scope to effect properties of the div, you cannot insert selectors into the style attribute to control the entire scope (of all sub elements with that div).

Instead, you must "id" or "class" the div, and use some style sheet completely outside the location of this element to style it. This make modules too tightly coupled with the pages they appear on.

With style scopes, however, you could potentially showcase, on a single web page, a bunch of independently styled modules, without those modules having to cooperate with style-sheets of the page they are appearing on.

To achieve this now, without style scopes, it is always a pain the ass. You either have to style each attribute of each sub element (within a scope hierarchy), or play the id/class game, basically making your module have to "register" its styles OUTSIDE of itself with the page it is appearing on.

I say, let the modules style themselves, within the module, using selectors, in the scope where they exist. Then, if you put that module on a page, its layout and look, will be exactly like you designed it to be, without having to cooperate with the page it appears on.

Additionally, I also think <style scoped> should not be limited to inline selectors, it should also have the ability to call any stylesheet URL. Something like this:

  <style scoped href="AnyStyleSheetInTheWorld.css" type="text/css">
      <!--Add additional styles here if necessary -->
  </style>

The web will have truly matured when such flexibilities are ubiquitous. Let the modules layout and style themselves (inside themselves)!

[lonn...@startport.com]

By the way, I recall proposing something similar to this back 2005. Luckily, I was able to google and find it:
http://lists.w3.org/Archives/Public/www-html/2005Jul/0043.html

[PhistucK]

Web Components (Shadow DOM in particular) can have <style> in them that only affects the encapsulated DOM. This sounds like a (more real) module to me.

(Granted, it requires JavaScript which is pretty bad)

☆PhistucK

On Wed, Nov 4, 2015 at 7:37 AM, <lonn...@startport.com> wrote:

By the way, I recall proposing something similar to this back 2005. Luckily, I was able to google and find it:
http://lists.w3.org/Archives/Public/www-html/2005Jul/0043.html

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[keith...@gmail.com]

This is one of the most exciting potential features to me. I really hope it resurfaces, especially in its newer iteration in the working draft (https://drafts.csswg.org/css-scoping/). This relies on an @scope at-rule rather than the html scoped attribute. It makes more sense to me to do this in stylesheets rather than inline in the HTML document.

[franz....@gmail.com]

Agreed. The new iteration sounds very promising, and should be a nice CSS-only way to keep a sane CSS architecture while still decoupling styles from HTML

Regards

Franz Liedke

[mathew...@globalyceum.com]

Please inform me as to were I may voice my appeal in favor to continue to develop <style scoped>. If I'm in the right place then I believe works such as <style scope> is absolutely necessary. CSS is at best a quasi- language (perhaps a more appropriate term would be slang?) , it's purpose is to facilitate the presentation aspects of HTML. It lacks so many essential features that it has become more of a necessary burden than boon. Not being able to control CSS global influence effectively costs us more valuable time devising half-assed measures such as post-processing, BEM, etc.. Getting <style scoped> out there is a big step in the right direction. 

On Wednesday, March 19, 2014 at 3:34:27 PM UTC-7, Elliott Sprehn wrote:

[franz....@gmail.com]

There is a new version of the editor's draft at https://drafts.csswg.org/css-scoping/ that suggests a CSS-only solution for scoped styles. So even if <style scoped> is removed, implementing scoped styles will likely become possible in the future.

[Mathew Corley]

Thank you, sir. There is hope yet.

--

Regards,

Mathew Corley, Globalyceum.com

[tra...@ministrycentered.com]

LGTM

On Wednesday, March 19, 2014 at 3:34:27 PM UTC-7, Elliott Sprehn wrote:

[adamje...@gmail.com]

LGTM

On Wednesday, March 19, 2014 at 5:34:27 PM UTC-5, Elliott Sprehn wrote:

[seyedmojt...@gmail.com]

LGTM

[adi.zarf...@gmail.com]

what is the status of <style scoped> ?
I can use it in chrome, but I see this feature have been removed ?

am I using something deprecated or is this feature supported ?

In my use case, this feature is a blessing...

[PhistucK]

It was never enabled by default and it was removed from the code base itself about four years ago.

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/54b2c4e3-61d8-4d35-880b-02399a6deea0%40chromium.org.

[Domenic Denicola]

So in particular, when you use <style scoped> in Chrome, it is the same as using <style asdf>, or just <style>.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_%2B0np4WOGb7PvXH-cnn8RFZVVdzXYXAATNjsBqO0tqrkw%40mail.gmail.com.

[keith...@gmail.com]

<style scoped> is no longer in the spec. The way to do this now is with the Shadow DOM. https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM

[kimly...@gmail.com]

I am very sad this feature (scoped styling) was removed.  With programitcally loaded css from an outside source, I wanted to limit the scope without resorting to an iframe or something similar.  I've looked at shadow dom and it just doesn't seem to meet my need the way the scoped attribute would have. I wanted a very simply, html/xhtml only solution which scoped would have provided.   


~Kim