<style scoped> ?

[Ojan Vafai]

I know we have people working on styles that are scoped to shadow roots. Do we have anyone working on finishing up <style scoped> outside shadow roots? If not, we should remove the code.

[Elliott Sprehn]

+1 to removing the code. I don't think this feature makes sense now that we have ShadowRoot and it makes the implementation of the style resolver very complex since TreeScope is not always the scope of your styles. I think WebKit already removed it.

[Adam Klein]

I'd be interested to know how close to "done" the feature is in Blink. It's been shipping in Gecko for awhile (since Firefox 21, according to MDN). WebKit removed the code a few weeks ago (it was #ifdef'd out), but in the relevant thread (https://lists.webkit.org/pipermail/webkit-dev/2013-September/025526.html) there seemed to be some interest in re-implementing it. And it's specced in HTML (for whatever that's worth).

On Thu, Nov 7, 2013 at 2:07 PM, Ojan Vafai <oj...@chromium.org> wrote:

[Tab Atkins Jr.]

On Thu, Nov 7, 2013 at 2:40 PM, Adam Klein <ad...@chromium.org> wrote:
> And it's specced in
> HTML (for whatever that's worth).

Somewhat. I have yet to write the spec that ties together the scoping
concepts that <style scoped> uses, because Hixie doesn't want to deal
with those details in HTML.

~TJ

[Tab Atkins Jr.]

On Thu, Nov 7, 2013 at 2:39 PM, Elliott Sprehn <esp...@chromium.org> wrote:
> +1 to removing the code. I don't think this feature makes sense now that we
> have ShadowRoot and it makes the implementation of the style resolver very
> complex since TreeScope is not always the scope of your styles. I think
> WebKit already removed it.

I use scoped styles for local styling regularly, actually. Right now
I fake it by using an #id, but still.

~TJ

[Ojan Vafai]

I'm on the fence. <style scoped> seems like a reasonable way for sites to avoid having a large number of global style rules without needing to go fully down the much more complicated codepath of web components + shadow roots.

[Elliott Sprehn]

On Thu, Nov 7, 2013 at 2:46 PM, Ojan Vafai <oj...@chromium.org> wrote:

I'm on the fence. <style scoped> seems like a reasonable way for sites to avoid having a large number of global style rules without needing to go fully down the much more complicated codepath of web components + shadow roots.

It added so much complexity to our code though. Having to deal with both <style scoped> and ShadowRoot and Document level styles has made refactoring and improving our style system quite difficult.

[Ian Hickson]

On Thu, 7 Nov 2013, Adam Klein wrote:
> [...]

> there seemed to be some interest in re-implementing it. And it's specced in
> HTML (for whatever that's worth).

As Tab points out, I didn't do a very throrough job of speccing it (though
I think we're agreed on how it should work, it's just a matter of writing
it down more formally). But the feature has a huge amount of author
demand, from what I can tell.

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

[Jake Archibald]

Yes, so is this feature simply saving putting that ID in every selector? If so, it feels like selector nesting (which developer also want) would satisfy this and more.

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

[Tab Atkins Jr.]

On Tue, Nov 12, 2013 at 3:38 AM, Jake Archibald
<jakear...@google.com> wrote:
> Yes, so is this feature simply saving putting that ID in every selector? If
> so, it feels like selector nesting (which developer also want) would satisfy
> this and more.

Given that nobody's really willing to do the additional work necessary
for at-rules to be scoped, yeah, I guess it's equivalent to just using
an id selector + nesting.

~TJ

[Ian Hickson]

On Tue, 12 Nov 2013, Jake Archibald wrote:
>
> Yes, so is this feature simply saving putting that ID in every selector?
> If so, it feels like selector nesting (which developer also want) would
> satisfy this and more.

While you can certainly fake it in this manner, I think equating them in
this way misses the significant authoring benefit to a real scoping
solution. Using IDs in this way means you need to come up with unique IDs,
you have to rewrite the style sheet for each such ID (consider a blog with
multiple posts, each with the same styles so that it can be syndicated),
you can't use @import to import common styles, etc.

[Takashi Sakamoto]

+1 to remove <style scoped>. I agree that style scoped makes Blink much more complex.

However, I have one concern. Firefox has already implemented style scoped.

I'm not sure whether web developers will love style scoped or not.

Best regards,

Takashi Sakamoto

2013/11/8 Elliott Sprehn <esp...@chromium.org>

[Jon Rimmer]

On Tuesday, November 19, 2013 11:19:40 AM UTC, Takashi Sakamoto wrote:

+1 to remove <style scoped>. I agree that style scoped makes Blink much more complex.

However, I have one concern. Firefox has already implemented style scoped.

I'm not sure whether web developers will love style scoped or not.

Speaking as a developer, I think it's a useful feature for quick prototyping and ad-hoc collaboration on documents written in HTML, but not one that is going to revolutionise my workflow. Its primary appeal is that it reduces cognitive load and is reasonably intuitive. If I'm maintaining some internal documentation in HTML, and I need to add a section to it, I can write the markup and the styles together and stick 'em in a document, knowing I don't need to worry about breaking other content, or colliding with an existing id, or someone else colliding with my id later. Given the choice, I would rather have selector nesting in CSS than scoped styles, but I don't believe we'll get nested selectors for many years, if ever, regardless of whether scoped styles are removed, so that isn't really an alternative, IMO.

I think the key thing with scoped styles is that their primary use-case is the opposite of web components. The component APIs are intended for professional developers building well-engineered applications, but there has always been a large constituency of HTML authors who are not professionals, and for whom a requirement to use imports and shadow DOM would be overkill. Scoped style provides a simple way for them to write CSS that restricted to its target content and associated to it via proximity.

Finally, scoped styles have been written about quite a bit by web dev advocates in the past few years[1] with, as far as I can tell, a generally positive reception. That alone isn't a reason to keep pursuing a bad feature, but bear in mind that these kind of U-turns inevitably inspire a degree of WTFness amongst developers, particularly those who only dabble with the web and who are likely to see scoped styles as a useful way to just get stuff done. They damage the image of the web platform, just as equivalent deprecations and charges in direction damage the image of other platforms.

Thanks,

Jon

[1] https://www.google.co.uk/search?q=scoped+style

[Daniel Freedman]

On Tue, Nov 19, 2013 at 8:29 AM, Jon Rimmer <jon.r...@gmail.com> wrote:

On Tuesday, November 19, 2013 11:19:40 AM UTC, Takashi Sakamoto wrote:

+1 to remove <style scoped>. I agree that style scoped makes Blink much more complex.

However, I have one concern. Firefox has already implemented style scoped.

I'm not sure whether web developers will love style scoped or not.

Speaking as a developer, I think it's a useful feature for quick prototyping and ad-hoc collaboration on documents written in HTML, but not one that is going to revolutionise my workflow. Its primary appeal is that it reduces cognitive load and is reasonably intuitive. If I'm maintaining some internal documentation in HTML, and I need to add a section to it, I can write the markup and the styles together and stick 'em in a document, knowing I don't need to worry about breaking other content, or colliding with an existing id, or someone else colliding with my id later. Given the choice, I would rather have selector nesting in CSS than scoped styles, but I don't believe we'll get nested selectors for many years, if ever, regardless of whether scoped styles are removed, so that isn't really an alternative, IMO.

I think the key thing with scoped styles is that their primary use-case is the opposite of web components. The component APIs are intended for professional developers building well-engineered applications, but there has always been a large constituency of HTML authors who are not professionals, and for whom a requirement to use imports and shadow DOM would be overkill. Scoped style provides a simple way for them to write CSS that restricted to its target content and associated to it via proximity.

I feel like i have to interject here: web components are not only meant for "professionals", they're meant for everyone. I expect many devs to just take a few they found on html5rocks, css-tricks, or wherever and just pop them in a page. That they appear via HTML Imports and not script src is just a detail. That they may or may not have Shadow DOM is not something I expect many devs to care about whatsoever, because they are self-contained little blobs.

[Jon Rimmer]

On Tuesday, November 19, 2013 6:09:57 PM UTC, Daniel Freedman wrote:

On Tue, Nov 19, 2013 at 8:29 AM, Jon Rimmer <jon.r...@gmail.com> wrote:

On Tuesday, November 19, 2013 11:19:40 AM UTC, Takashi Sakamoto wrote:

+1 to remove <style scoped>. I agree that style scoped makes Blink much more complex.

However, I have one concern. Firefox has already implemented style scoped.

I'm not sure whether web developers will love style scoped or not.

Speaking as a developer, I think it's a useful feature for quick prototyping and ad-hoc collaboration on documents written in HTML, but not one that is going to revolutionise my workflow. Its primary appeal is that it reduces cognitive load and is reasonably intuitive. If I'm maintaining some internal documentation in HTML, and I need to add a section to it, I can write the markup and the styles together and stick 'em in a document, knowing I don't need to worry about breaking other content, or colliding with an existing id, or someone else colliding with my id later. Given the choice, I would rather have selector nesting in CSS than scoped styles, but I don't believe we'll get nested selectors for many years, if ever, regardless of whether scoped styles are removed, so that isn't really an alternative, IMO.

I think the key thing with scoped styles is that their primary use-case is the opposite of web components. The component APIs are intended for professional developers building well-engineered applications, but there has always been a large constituency of HTML authors who are not professionals, and for whom a requirement to use imports and shadow DOM would be overkill. Scoped style provides a simple way for them to write CSS that restricted to its target content and associated to it via proximity.

I feel like i have to interject here: web components are not only meant for "professionals", they're meant for everyone. I expect many devs to just take a few they found on html5rocks, css-tricks, or wherever and just pop them in a page. That they appear via HTML Imports and not script src is just a detail. That they may or may not have Shadow DOM is not something I expect many devs to care about whatsoever, because they are self-contained little blobs.

Yes, they're easy to use, but we're not talking about using a pre-existing component here, we're talking about using the supporting APIs to scope styles to a portion of a document.

Thanks,

Jon

[PhistucK]

Scope styles are good for letting commenters add their style that will only affect their comments. More creative freedom.

☆PhistucK

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

[Elliott Sprehn]

On Tue, Nov 19, 2013 at 12:58 PM, PhistucK <phis...@gmail.com> wrote:

Scope styles are good for letting commenters add their style that will only affect their comments. More creative freedom.

I don't believe that's true, you need to process the CSS and run it through a whitelist for that to be safe (otherwise someone will do something to break your layout (or worse execute script). At that point you might as well just append an id to the start of each selector. Appending an id or class is also better for reuse, users probably want their comments to all be styled the same on the page and appending the same <style scoped> over and over again is silly and expensive, instead you can just prepend all rules with .comment-user-{username} and only output a single <style> block at the top of the page that contains the styles for all users of comments on that page.

[PhistucK]

I am talking about the innocent case, not about the malicious one. Of course, if you want to protect your website, you have to take certain measures.

Anyway, it was just a use case. I am not sure I support this feature.

☆PhistucK

[jmar...@twitter.com]

Sorry to post this very late. I just got a wind of this being removed and wanted to voice some of concerns. For one, using scoped styles will allow for browsers to degrade gracefully, as if the scoped styles are not supported, the nested DOM elements would still render with global styles. Moving to a place in which you must rely on the ShadowDOM offers a more complicated approach to structuring content when you must support all sorts of legacy browsers. The reason I am concern is that from my perspective, people will start nesting iFrames to get this functionality, which is not probably the best solution. At least with scoped styles it will pave a better path to switching to ShadowDOM when it is supported by IE and Safari (if ever). Also, I think believing users will be good at creating appropriate specificity rules is a mistake, this will create more work and probably a lot of bad CSS written to overwrite styles. Anyway, just my 2 cents on the topic.

[kpym....@gmail.com]

I have seen different topics saying that implementing scoped brings complexity. Why ? 

Isn't it possible just to consider it as a syntactical sugar in the following way : all selectors in the scoped style are prepend with a randomly generated hashtag class. Here is an example. Consider a <p> containing <style scoped>, we generate a random class in a way to make the <p> element <p class="scopedautoclass3y4sdfojk9"> and then any selector in the <style scoped> is prepend with "p.scopedautoclass3y4sdfojk9 > ".

[Takayoshi Kochi]

Theoretically yes, you can implement that way.

Then the implementation sacrifices some performance, if implemented naively.

The selector matching logic can be optimized, but naive implementation would try to match

scoped rules against out-of-scope DOM elements which will always fail to match.

Other complication is related to co-existence of Shadow DOM style, which is also scoped.

The previous implementation tried to solve both in a unified manner, which resulted in

complexity and the <style scoped> part was removed.

--

Takayoshi Kochi

[kpym....@gmail.com]

Le mercredi 18 mars 2015 04:40:52 UTC+1, Takayoshi Kochi a écrit :

Theoretically yes, you can implement that way.

Then the implementation sacrifices some performance, if implemented naively.

The selector matching logic can be optimized, but naive implementation would try to match

scoped rules against out-of-scope DOM elements which will always fail to match.

I understand this, but this is already what is happening. Now we introduce an #id or a fake class and we 

put a global style to simulate "scoped". So it is not optimal but is not worse to the actual situation, from the performance point of view.

Even if from performance point of view this "syntactical sugar" is not good (nor bad than the actual situation), 

from designer point of view is a cleaner syntax I think.

By the way, if we want to increase performance, we can use #id in place of faka class : 

 - if the parent element has an id, we use it to prepend all scoped selectors, 

 - if the parent element has no id we introduce a hashtag unique id for this element and we use it to prepend all scoped selectors.

In this way we don't have to search the entire DOM for matches.

 

Other complication is related to co-existence of Shadow DOM style, which is also scoped.

The previous implementation tried to solve both in a unified manner, which resulted in

complexity and the <style scoped> part was removed.

I understand that if we want to implement "scoped" in the best way this is complicated.

That is exactly why I purpose this "syntactical sugar" implementation, that do not introduce new ruels of priority.

[PhistucK]

What if the ID that the element already has is not really unique (disallowed, but happens)?

☆PhistucK

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

[Takayoshi Kochi]

We are not saying that we will never implement <style scoped>,

we just removed the code for some reasons.

We may re-implement it in the future.

Contribution from external party is accepted, though I personally suspect that

adding a fake-id solution like your proposal will be considered a stop-gap solution

which will be removed again for the *real* implementation.

--

Takayoshi Kochi

[kpym....@gmail.com]

Le mercredi 18 mars 2015 11:09:12 UTC+1, PhistucK a écrit :

What if the ID that the element already has is not really unique (disallowed, but happens)?

Short answer :  Exactly the same as what is happening now if you have an id css selector and more than one (disallowed) elements with his id. No new rules.

Longer answer : Both "syntactic sugar" implementations are compatible with the W3C specifications : 

• The use of hashtag fake class is slower but guarantee consistency even in the disallowed case that you describe.
  
• The use of #id (if necessary hashtag fake id) is faster (I think), but is not relay consistent IF the page is not in accordance with the official recommendations. And I don't think that developing complex priority algorithms is justified to solve this kind of situations.

[kpym....@gmail.com]

Le mercredi 18 mars 2015 11:25:02 UTC+1, Takayoshi Kochi a écrit :

We are not saying that we will never implement <style scoped>,

we just removed the code for some reasons.

We may re-implement it in the future.

That is why I purpose a "simple" way to do it ;)

No complex new logic, no new rules and all this compatible with the W3C specifications.

[Takayoshi Kochi]

On Wed, Mar 18, 2015 at 7:41 PM, <kpym....@gmail.com> wrote:

That is why I purpose a "simple" way to do it ;)

No complex new logic, no new rules and all this compatible with the W3C specifications.

I'm happy to review the patch if you have.

But the feature has to go through "Intent to (re)ship" review on this list.

--

Takayoshi Kochi

[PhistucK]

None of the implementation options you proposed is compatible with the specification, or work cleanly.

- Adding classes to elements without classes affect styles (for example, *[class] would apply styles to them). Adding hidden classes of some sort basically introduce hacks to the implementation.

- Same for adding IDs and re-using existing IDs. But also, incompatible with the specification when non unique IDs exist.

Incomplete user agent implementations are not good. Less performant implementations are more acceptable, because they can be improved over time without changing the actual behavior.

However, this does sound like a reasonable polyfill implementation (every web page that wants it can include it and bear with the consequences). Perhaps you should invest in that, if there is none already.

☆PhistucK

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