I get what you're saying, but whereas 'these features could be designed differently' is considered valid collaboration, 'these features are unnecessary' doesn't seem to be
-
-
Replying to @Rich_Harris @gregwhitworth and
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.
3 replies 0 retweets 4 likes -
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 @matthewcp and
Is it equivalent? It feels very different — less composable, results in more duplication
1 reply 0 retweets 0 likes
The idea of a syntax for opting a rule-set (or set of rule-sets) into a particular group was also explored. Same perf implications at style resolution time.
-
-
Replying to @slightlylate @matthewcp and
What kind of perf implications are we talking about? For all we hear about JS perf, I never hear anyone talk about CSS perf, and my understanding was that it hadn't been a meaningful problem for years
1 reply 0 retweets 1 like - 3 more replies
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.