3 ms·
Great article. Maybe a hot take but I think it's a good thing that dialog and details modify the DOM. It allows for UI state to be serialized and stored in a na
by grose 2y ago
Great article. Maybe a hot take but I think it's a good thing that dialog and details modify the DOM. It allows for UI state to be serialized and stored in a native way. I think input.value should work the same way too (although it's probably too late for that). Consider how some browsers will remember what you input into forms when you hit the back button: I think representing this as a cached version of the modified DOM makes a lot more sense than whatever magic browsers currently use to remember it. Many CSS pseudoclasses like :checked feel like a pre-attribute-selector bandaid.
- jaffathecake 2y agoYeah, I get your point. On the other hand, I prefer the serialisation of the light DOM to reflect only changes I've made as the author. The serialisation isn't expected to represent page state. Imagine how that would work with <canvas>, or even things like event listeners.
- somishere 2y agoTend to agree ... with the added reflection that to a stylesheet, the DOM is the only worldview. Attributes - and the currently limited set of pseudo classes - afford its agency. If pseudos were extended to include all property state, DOM serialised or not, then we'd be onto something.
- shiomiru 2y ago> Consider how some browsers will remember what you input into forms when you hit the back button: I think representing this as a cached version of the modified DOM makes a lot more sense than whatever magic browsers currently use to remember it. That would not work either: > A control's value is its internal state. As such, it might not match the user's current input. > For instance, if a user enters the word "three" into a numeric field that expects digits, the user's input would be the string "three" but the control's value would remain unchanged. Or, if a user enters the email address " awesome@example.com" (with leading whitespace) into an email field, the user's input would be the string " awesome@example.com" but the browser's UI for email fields might translate that into a value of "awesome@example.com" (without the leading whitespace). From the standard: https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#a-form-control's-value https://html.spec.whatwg.org/multipage/form-control-infrastr...