No, I'm not saying that — built-in elements don't give you hooks to respond to changing attributes. I'm saying that if you're designing custom elements, you could do so in a way that doesn't inherit the long standing confusion about attroperties — one of the DOM's worst aspects
-
-
Replying to @Rich_Harris @lamplightdev and
Built-ins absolutely have internal hooks for responding to attributes they are defined to care about. That's what attributeChanged gives you too.
1 reply 0 retweets 2 likes -
Replying to @slightlylate @lamplightdev and
Again, Alex, I *could not care less* about the C++ inside browsers. As a component author and consumer that is just not in any way pertinent
1 reply 0 retweets 2 likes -
Replying to @Rich_Harris @lamplightdev and
Which is why I keep reiterating that *you don't have to use any of it* if you don't want HTML integration. We opened up DOM and the HTML parser to you, warts and all. Feel free to reject whichever don't serve you!
2 replies 0 retweets 4 likes -
Replying to @slightlylate @lamplightdev and
It's not about the choices I make or reject when writing my own components! It's about navigating the choices made by the authors of every component I ever come across while building an app. Why is this so hard to grok?
2 replies 0 retweets 8 likes -
Replying to @Rich_Harris @lamplightdev and
It's not! The most interoperable WC work like HTML. There's plenty of space for a sect that rejects some of that interop advantage for other conveniences. They'll need to name this variant for themselves to avoid confusion, tho.
1 reply 0 retweets 2 likes -
Replying to @slightlylate @Rich_Harris and
As a passive observer of this convo: Alex is saying that WC give you a way to essentially build builtins: a new html element. The *external* API of your WC shouldn't include knowledge of attributeChanged, but internally should fire a DOM event that consumers can listen on...
1 reply 0 retweets 1 like -
Replying to @mikesherov @slightlylate and
So you get all the quirks of building a builtin, now in JS! Rich is saying that no one wants to build components like that. And that saying "oh don't use the bits you don't like" is a cop out, because we maybe had a chance to fix attroperties and didn't.
1 reply 0 retweets 2 likes -
Replying to @mikesherov @slightlylate and
Both of these statements are true. Rich envisions a chance to do something better than the html we've had forever. Alex is saying you can build things that are just like the html of today.
1 reply 0 retweets 4 likes -
Replying to @mikesherov @slightlylate and
Pretty much it. Custom elements were an opportunity to break with the mistakes of the past; instead we doubled down on them
1 reply 0 retweets 3 likes
You're missing my point: breaking with HTML means defacto interop fail (as we have in most userland FWs today). Can do that -- and in fact can do it better with WC! -- but that's about local choices you're no less free to make in WC than before.
-
-
Replying to @slightlylate @mikesherov and
Firstly, this isn't breaking with HTML/DOM — there's precedent for element properties changing without the attribute also changing (`input.value = x`, etc). Secondly, what are these interop failures you keep referring to?
2 replies 0 retweets 4 likes -
Replying to @Rich_Harris @mikesherov and
You can build getter/setter only components with WC *TODAY*. Avoid reflecting if you want! Advertise it as the hot new thing! Sell it like a brat at a ballgame! Ignore attributes like they're going out of style! WC are a pallete of options. Pick/chose what works best for you.
2 replies 0 retweets 1 like - 15 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.