These are hard problems to solve while also retaining the security model of the browser. Therefore it is probably *easier* for the browsers to just do it themselves.
-
-
I think these two ideas are orthogonal. Objectively, WC have a legitimate use case for many and I think we'll see more of this as time goes on. Exposing other useful APIs, such as access to hardware, can co-exist. Maybe in terms of priority the latter would have been more useful.
2 replies 1 retweet 6 likes -
Replying to @treshugart @sebmarkbage and
I agree with Trey here. Even with all of that access, you'd still need a way to tell the system that you're making a new element type. WC let you express that. It's literally just telling the parser to instantiate a class. the class can do whatever.
3 replies 0 retweets 4 likes -
Replying to @rob_dodson @treshugart and
It can do whatever, originally asynchronously, and nobody considered that a problem for EWM. More concerningly, you're forced to buy into the WC framework's DOM isolation story in order to get the benefits of CSS isolation.
1 reply 0 retweets 5 likes -
Replying to @wycats @rob_dodson and
In practice, all frameworks have alternative DOM isolation stories than WC but badly want CSS isolation. In practice frameworks want to intercept "anytime someone clicks a link on the page" even if using Shadow DOM for CSS isolation.
2 replies 0 retweets 4 likes -
Replying to @wycats @rob_dodson and
That doesn't mean frameworks are breaking DOM isolation. It means they offer a different isolation paradigm (based on declarative constructs and userspace components) for DOM but can't always accomplish that for CSS (because of light DOM leakage)
1 reply 0 retweets 2 likes -
Replying to @wycats @rob_dodson and
And frameworks use the non-isolated DOM as a substrate to building isolation paradigms on top. This is all fine but the style/event conflation set frameworks back years from using Shadow DOM for style isolation. Makes me sad.
2 replies 0 retweets 2 likes -
Replying to @wycats @treshugart and
There's a good thread where a member of the shadow dom team tried to explain why style isolation is coupled to DOM isolation. Let me try to dig that up...
2 replies 0 retweets 2 likes -
Replying to @rob_dodson @wycats and
I proposed an alternative form of declarative shadow DOM that opens up the separation here: https://github.com/whatwg/dom/issues/531 …. Hayato did respond, I think, with some of the points you describe. I (naively?) still think it could work, though - and should work.
2 replies 0 retweets 2 likes -
Replying to @treshugart @wycats and
hah yeah, same thread :) That's sort of the extent of my understanding. "Just separate them" sounds like an easy win but is possibly hard to implement? ¯\_(ツ)_/¯
1 reply 0 retweets 0 likes
"coupling them matches our implementation" sounds like something an app developer might say (if they weren't very good) not what we should expect from web specs.
-
-
Replying to @wycats @treshugart and
not a very nice thing to say
I'd like to give folks the benefit of the doubt that these really are hard problems. Don't mean we can't continue to work on them though.2 replies 0 retweets 1 like -
Replying to @rob_dodson @treshugart and
Didn't mean to be rude. Terseness wasn't helpful here. I believe they're hard but years have gone by. I can state categorically that Ember would be using Shadow DOM for CSS isolation today if not for the coupling. I also said that to people 2-3 YEARS ago.
0 replies 0 retweets 1 like
End of conversation
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.