I think you're missing the point here — there is real confusion caused by the dual interface of attributes and properties. The C++ implementation is utterly irrelevant to me as a component author and consumer
-
-
Replying to @Rich_Harris @dmitryshimkin and
I grok the point. That DOM has both is clearly not great! MSFT's DOM was correct (and Netscape/IBM were *super* wrong). But if you want property-only components, or want to only handle attributes up-front, can do that today. What's missing?
1 reply 0 retweets 1 like -
Replying to @slightlylate @Rich_Harris and
I mean, if you're saying "we want syntactic support for a version of HTML that relies on properties", that's doable but a big lift. Size of effort is perhaps part of why JSX crowd continues with fork instead of proposing new parsing mode?
1 reply 0 retweets 1 like -
Replying to @slightlylate @dmitryshimkin and
> What's missing? Predictability. Consistency between components. The React model is so successful in part because of its obviousness — there's only one way to get data into a component > if you're saying ... I'm not. I think HTML is fine
1 reply 0 retweets 3 likes -
Replying to @Rich_Harris @dmitryshimkin and
...but it's HTML that *creates* this split. WC only give you high fidelity access to both sides. If you want property-only components, go nuts! It's all there.
1 reply 0 retweets 6 likes -
Replying to @slightlylate @dmitryshimkin and
"go nuts, it's all there" is *the whole problem*. When an API is well-designed, there's usually only one way to do something
2 replies 0 retweets 5 likes -
Replying to @Rich_Harris @dmitryshimkin and
Then don't use attributes in your elements! Ignore them! Throw or ignore in post-construction attr changes! Preach the no-semicolon-but-for-components message! WC open up the guts of HTML and DOM. What you do with that power *is up to you*.
1 reply 0 retweets 4 likes -
Replying to @slightlylate @dmitryshimkin and
And that's the problem. Really don't understand why you're not getting this. But it strikes at the heart of the disconnect between WC and framework camps — frameworks only succeed when the APIs are logical and learnable
2 replies 1 retweet 5 likes -
Replying to @Rich_Harris @slightlylate and
So, just for clarity, you would prefer a WC model that doesn't mirror how built in elements behave?
1 reply 0 retweets 0 likes -
Replying to @lamplightdev @slightlylate and
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
1 reply 0 retweets 2 likes
Built-ins absolutely have internal hooks for responding to attributes they are defined to care about. That's what attributeChanged gives you too.
-
-
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 - 24 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.