4 ms·
> Wait, you're proposing... No. Some significant differences between those examples and the new proposal: (1) (most important) Those are all implemented and r
by jmull 2y ago
> Wait, you're proposing...
No. Some significant differences between those examples and the new proposal:
(1) (most important) Those are all implemented and released. The time to debate how those things might best be handled is long over.
(2) The interactivity of text editing and selection are limited to local state of the control itself. Notably, they don't affect the DOM. pseudo-classes like :hover are effectively DOM operations, but are at least limited to a kind of boolean state flag, which is a lot less complicated and fraught than rendering arbitrary DOM subtrees.
Anyway, as I already mentioned, I'm not arguing against a reactive mechanism built in to the browser. I'm saying if you do it, it should not be a one-off for a single, specific case like <select><button><selectedcontent>, but should instead be a generally applicable mechanism.
- jaffathecake 2y agoI think the main issue is you're using "reactive" to mean something specific that you're not stating. The web is always going to have the DOM as its tree, so a system where one thing updates in reaction to another thing updating is always going to need to be explained in terms of DOM mutations, and their timings. The post details multiple ways of doing that, all of which are reactive by some definition. So, if you're saying it needs to be "reactive", it isn't of much value unless you detail how that works and how it's different to what's proposed.