
-
-
Replying to @jyasskin @Paul_Kinlan
We drafted EWM out of the experience of legacy JS libraries and the WC experience. The motivation is/was to ensure that things are layered well so that when *one* part needs to be replace, not *all* of it must be. In fact, it's largely about replacing *less*.
1 reply 0 retweets 2 likes -
Lots of folks misconstrued EWM to privilege their everything-replacing systems. Not what we were going for, tho.
2 replies 0 retweets 2 likes -
Replying to @slightlylate @jyasskin
replacing less, sounds good, but it feels that we have to ship more of the new stack, with the eventual end state of "Moving more of the web into JS means that more of the fundamentals must be rebuilt in userland", it's just new fundamentals...
1 reply 0 retweets 2 likes -
I sincerely wince every time I hear things like Houdini will solve X (I just picked it as an example), knowing that we will have to ship all of the new layout framework, when all developers want is a new CSS property that does it for them.
1 reply 0 retweets 5 likes -
Replying to @Paul_Kinlan @jyasskin
huh? You don't have to ship a new layout framework. Instead, you get to use Grid (or whatever) as far as it'll take you and *when you were already going to introduce JS* or some other huge pile of hacks, you have a more efficient way to do it.
1 reply 0 retweets 1 like -
I see both sides. The low-level tools are great, but feel complicated for common patterns. It's become pretty routine to use say, int. observers all over a site to achieve what CSS should offer as a pseudo-class (eg ":stuck"). My worry is when efficient is viewed as good enough.
2 replies 0 retweets 4 likes -
Replying to @scottjehl @slightlylate and
(forgive me if there's progress on "stuck" in particular (that'd be great)... it's more of a comment on similar common patterns like accordions, tabs, stuff like that that we build differently every time, never knowing how to wire it up quite right for a11y)
1 reply 0 retweets 1 like -
One of the reasons we need to provide outgasses is that it takes *so long* for groups like CSSWG to make progress, and it's hard to judge how important a specific feature is. One of the goals of making the "hacks" more system-supported is to create semantic transparency.
2 replies 0 retweets 1 like -
yeah. Still there are a handful of features that I think are widely mentioned as needed and missing, and are unlikely to prove out that way. I'm not going to build a production design system that relies on resize observers, but I certainly still want container queries in CSS.
1 reply 0 retweets 4 likes
I'm optimistic about some of the work browser teams are doing now to better survey developers to get a better data-driven understanding of what should be tackled. In all cases, our goal w/ Blink is to move these sorts of decisions to a more evidentiary basis.
-
-
Replying to @slightlylate @scottjehl and
...but even with perfect prioritisation, bandwidth isn't there to solve all needs in declarative-land. Will continue to need escape valves, and they shouldn't make live *fundamentally* worse for end-users because devs got stuck somewhere.
1 reply 0 retweets 1 like -
I guess I'm unclear on how to show evidence of a pattern I want to use when I'm not going to build an approximated version of it that relies on JS APIs. I'd rather build with the less ideal existing alternative. Hard to use the production web as a proving ground for experiments
2 replies 0 retweets 4 likes - 4 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.