tkent-google
Discussion issue for attribute mappings
https://github.com/tkent-google/std-switch/tree/3418f78239e5a99ca6c37099ecb3edfc45e21b29#content-attributes discusses two models for attribute mappings. Here I will list some pros/cons.
A) Compatible with <input type=checkbox>
- (+) Consistent, and thus relatively easy to understand, especially for reset behavior.
- (+) Easy to refactor between checkboxes and switches. (Is this important?)
- (-) Historically, the
checked=""<->defaultCheckedand nothing <->checkedbehavior has been quite confusing for developers. Some frameworks have worked to hide it. Maybe we should not propagate it.
B) Simple mappings
- (+) Simpler mental model, matching 99% of all HTML attribute mappings
- (+) Allows styling based off of attributes, e.g.
#my-switch[checked], instead of pseudo-classes. See #3. (I think this is a pro because it removes the footgun of trying to use attribute selectors and it only working for default checkedness.) - (+) More generally, storing state in the tree instead of internally makes various operations, e.g. cloning or serializing, simpler for developers.
- (-) The usage of
defaultchecked=""can be a bit confusing. Especially because you could write<std-switch defaultchecked>(with nochecked=""attribute) where it is not checked "by default". Maybe we could fix this by renaming it tocheckedafterreset=""?
I think this issue would benefit a lot from web developer feedback.
Not sure what sort of feedback is wanted here, but I would favor (B) primarily for the advantage of styling. This type of element in particular is one where you might want to style it differently depending on the checked state. I have used this pattern of a boolean attribute quite a bit in my own custom elements, such as this drop down menu that does exactly the same thing for styling purposes.
Styling should be possible in either; if we did (A) then either :checked or :state(on) or similar would be used. See #3.
I would prefer A given the attribute names are checked/defaultChecked because the improved ergonomics of B don’t trump the reduced er ... meta ergonomics ... of having to remember an exception to an exception. I know "HTMLInputElement.prototype.checked" and ""HTMLSwitchElement.prototype.checked" would not be the same content attribute technically, but from a dev perspective there will probably be a reasonable expectation that "input elements that have the checked + defaultChecked interface do x".
Thanks @bathos!
Do you think it'd be different if we used "on" instead of "checked"? See #2.
B) seems the most straight-forward for me as a user. That also seems to be inline with https://developers.google.com/web/fundamentals/web-components/best-practices#aim-to-keep-primitive-data-attributes-and-properties-in-sync-reflecting-from--property-to-attribute-and-vice-versa
Yes — it’s the common naming that makes it a footgun from my POV if they behave differently, not the different behavior itself.
I think (B) is preferable if we assume that there will eventually be a larger, more actively used, set of new controls than the current built-in set. Then we can establish a new norm, and the existing elements will be the exception.
+1 for (B) with "on" instead of "checked". Drawing a parallel with physical switches, you don't check them, you turn them on/off.
At this moment, my conclusion is (B) with on.
If we implemented the switch control as <input type=switch>, we should follow the existing convention. However we'd like to introduce new element and we don't need to follow the confusing convention. Also, form reset is rarely used and the weirdness of defaultchecked in (B) doesn't matter.
I'll update the explainer for (B) with 'on', but I'll keep this issue open because I might change my mind. 🤔
Custom elements can inherit from built-in ones, can't they? If users could write something like <input type="checkbox" is="std-switch" /> to fall back to a checkbox when std-switch isn't available (or JavaScript is disabled), that'd be a pretty big advantage of of (A).
