setters, because it'd be nice if updates were batched naturally. But similar idea)
-
-
Replying to @Rich_Harris @dmitryshimkin and
Hidden/style etc absolutely go through a system like attributeChanged inside setAttribute impl in C++ side of DOM
1 reply 0 retweets 1 like -
-
Replying to @Rich_Harris @dmitryshimkin and
So if you want "what other built-ins do", this is what they do!
2 replies 0 retweets 1 like -
Replying to @slightlylate @dmitryshimkin and
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
1 reply 0 retweets 3 likes -
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
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*.
-
-
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 @dmitryshimkin and
WC *are just DOM*. This isn't a WC/FW disconnect; it's JS-first (only?) vs. HTML+DOM. Don't want HTML? Don't use it!
1 reply 0 retweets 2 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.