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 @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 -
Replying to @slightlylate @dmitryshimkin and
I'm clearly not getting through to you. Giving up on this thread
1 reply 0 retweets 1 like
No, I hear what you're saying and I'm trying to point out that what you're asking for is something on top of HTML+DOM that restricts the contract. You can have that. But it's an opinion on top of HTML+DOM, not how HTML works. And that opinion is yours to provide.
-
-
Replying to @slightlylate @Rich_Harris and
I'm not getting how there are obvious or easy ways to improve the design in these respects either. Specifying something like WCs, you're sitting inside the DOM and HTML. You have to work with the grain of how they work. Otherwise, as extensions of HTML and DOM, WCs don't work.
1 reply 0 retweets 1 like -
Replying to @morewry @slightlylate and
Rich Harris Retweeted Rich Harris
Rich Harris added,
0 replies 0 retweets 1 like
End of conversation
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.