There are use-cases that require hard encapsulation. For Salesforce they are saying that the current APIs are not quite hard enough! So jumping in and telling people that their uses-cases aren't valid is a bit like me opening an issue in Svelte saying to use React instead.
-
-
Replying to @matthewcp @gregwhitworth and
I'm fairly sure that between us, we could come up with a declarative encapsulation mechanism that wasn't tied to shadow DOM. If such a thing were possible, it would meet Salesforce's use case, along with many others that aren't currently served by the platform
1 reply 0 retweets 2 likes -
Replying to @Rich_Harris @matthewcp and
Unlikely thanks to Spectre/Meltdown. Could imagine something that's <iframe> like + worklets, however, but will break all data flow.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @matthewcp and
Eh? I don't follow. I'm just talking about CSS!
2 replies 0 retweets 0 likes -
Replying to @Rich_Harris @matthewcp and
The model for CSS style application is why SD looks the way it looks. CSS applies via DOM structure. The cascade is a consequence. Encapsulation that doesn't apply via DOM structure can't work w/o major perf implications for all of CSS.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @Rich_Harris and
BTW, I want to explicitly state that we could *absolutely* have missed something. We whiteboarded and prototyped dozens of alternatives over hundreds of hours, but obviously not perfect. If you *can* come up with something that integrates better, let's talk!
1 reply 0 retweets 0 likes -
Replying to @slightlylate @matthewcp and
You're telling me that, hypothetically, something like <div scope="foo"> 'shadow' DOM <div scope="bar">'light' DOM</div> </div> could never be treated the same way by the browser as this? <my-foo> <my-bar>light DOM</my-bar> </my-foo>
1 reply 0 retweets 0 likes -
Replying to @Rich_Harris @matthewcp and
We built (and shipped, and then unshipped) `<style scoped>` which was ~roughly this: https://developers.google.com/web/updates/2012/03/A-New-Experimental-Feature-style-scoped …
@tabatkins will likely remember more about why we abandoned, but perf impact was unacceptable IIRC.2 replies 0 retweets 0 likes -
Replying to @slightlylate @Rich_Harris and
There may have been perf implications, I don't recall. My reason for abandoning it was that upper-boundary (prevent styles from escaping) without lower-boundary (prevent styles from infecting) protection ended up of minimal use in practice to our early devs. Mostly a footgun.
2 replies 0 retweets 11 likes -
Replying to @tabatkins @slightlylate and
Not to mention, <style scoped> was nearly identical to just putting an ID on the container and using that in your selectors. A lot of implementation complexity for a not-that-useful feature that was easy to emulate by hand.
1 reply 0 retweets 3 likes
Ah, yeah, inability to stop cascade downward. Had a niggling feeling that was a contributor.
-
-
Replying to @slightlylate @Rich_Harris and
Fun fact: the big hole
@stubbornella has identified is precisely wanting a (limited, safe, composable) way of sending selected styles downward. Solving the problems we meant /deep/ for, but in a much safer way now1 reply 0 retweets 3 likes -
- 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.