WC feature dev slowed after '16 as we waited for Mozilla and MSFT to catch up. Took their sweet, sweet time. Big new proposals moving faster recently, landing apace: intrinsic role, form participation, :part, etc. SVG (and MathML) extensibility need attention now.
-
-
Replying to @slightlylate @dmitryshimkin and
I'm attributing nothing of the sort — I know perfectly well that everyone here is smart and has good intent, and have never — would never — imply otherwise. But here you are again implying it's somehow my responsibility to convince Apple and Mozilla to prioritise these things,
2 replies 0 retweets 7 likes -
Replying to @Rich_Harris @slightlylate and
when I don't need to because I can already do them as long as I avoid WCs! I don't know why it's so hard to say 'these things have some value in the following scenarios, but they currently have some major drawbacks and shouldn't be considered a general solution'.
1 reply 0 retweets 4 likes -
Replying to @Rich_Harris @slightlylate and
Instead we get 'eat your greens, jam tomorrow' — just list after list of all the ways in which the specs will *eventually* catch up to userland. It's infuriating. Can you really not see why this sentiment is so widely shared?
1 reply 0 retweets 8 likes -
Replying to @Rich_Harris @dmitryshimkin and
I hear you. I'm frustrated as well, but you're ignoring how WC provide massive interop value for teams *today*. Why?
2 replies 0 retweets 2 likes -
Replying to @slightlylate @dmitryshimkin and
Partly because I almost never encounter people (at confs, JS meetups etc) actually using them, partly because I still believe if we'd designed the primitives slightly differently they would have more general utility
1 reply 0 retweets 7 likes -
Replying to @Rich_Harris @dmitryshimkin and
If you want to engage on the later, let's discuss (assuming constructive collaboration; nobody treating folks like idiots who don't care about other's concerns, etc.)
1 reply 0 retweets 1 like -
Replying to @slightlylate @dmitryshimkin and
I appreciate the gesture, but hasn't the ship sailed? It seems hard to imagine that we'd e.g. undo the coupling of encapsulated styles to SD in favour of a declarative mechanism, or eliminate attributeChangedCallback in favour of a unified interface for passing data to components
2 replies 0 retweets 3 likes -
Replying to @Rich_Harris @dmitryshimkin and
Declarative layered on imperative very much possible (and as explained up thread, considered at length) Apple will be the ones to convince re: attribute changed.
1 reply 0 retweets 3 likes -
Replying to @slightlylate @Rich_Harris and
But "unified" is misleading. HTML and SVG elements have attributes *and* properties. We can't pretend they don't.
1 reply 0 retweets 3 likes
We tried a way to unify data passing through DOM hierarchy (MDV); framework community had a *fit*
-
-
Replying to @slightlylate @dmitryshimkin and
But you can imagine an alternate timeline in which we decided (for example) that (for custom elements only), attributes were simply the input value to a function that determined initial properties, and from that point forward weren't treated as an interface
2 replies 0 retweets 2 likes -
Replying to @Rich_Harris @dmitryshimkin and
What happens when someone calls setAttribute()?
1 reply 0 retweets 0 likes - 18 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.