The status quo is that both browsers and JS ecosystem are doing a poor job. The JS ecosystem often has an excuse because we don't have access to the primitives that are needed. That's not to say that it would be good even if we did. The game theory might not align.
-
-
Replying to @sebmarkbage @wycats
One exception is scrolling and things like position: sticky. That's an area where browsers focused on using their leverage to build one UI component well. (Although they also didn't give us the control to fix it ourselves.) But that's just one of many features that needs fixing.
1 reply 0 retweets 3 likes -
Replying to @sebmarkbage @wycats
Couldn't agree more with Seb here. WC relatively was never what developers wanted but what some browsers wanted to try and work around _them_ needing to solve the above problem. Better primitives are what developers want and need, at the platform level, not API/WC level.
2 replies 0 retweets 2 likes -
Replying to @TheLarkInn @wycats
It might be possible for developers to solve this in user space but what we need is not WC/convenience APIs. We need access. Access to compositor threads, access to cache, access to hardware, access to local data, access to OS level UI outside the browser frame...
2 replies 0 retweets 7 likes -
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.
2 replies 0 retweets 2 likes -
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
In practice frameworks can do that because mouse events cross the shadow boundary, what's the problem? CSS and DOM isolation are pretty intertwined on the implemention side. I think it's good DX that we don't have to many kinds of scopes that interleave down the tree.
1 reply 0 retweets 0 likes
Keep telling yourself that and we'll keep not using WC, which breaks your utopian future. Or we can fix it. I vote for that.
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.