WHATWG
2023-11-15
plaintext logs
prev next
source on github
03:04
<Domenic>
We definitely would do simple reflection, whether it's value <-> value="" or initialValue <-> initialvalue="". Whether we would then have a getter/setter for the current value... probably?
03:06
<Domenic>
Some previous discussion in https://github.com/tkent-google/std-switch/issues/4
07:45
<annevk>
I think all that's weird is that the IDL and content attribute have a different name, otherwise the design still seems reasonable to me.
11:07
<Jake Archibald>

To summarise, it's agreed that input.value's behaviour is bad, but it isn't clear which of the following should have been 'the way'

  • defaultValue property & defaultvalue attribute pair that reflect. And a value property (no attribute) which gets/sets the current value.
  • value property & attribute pair that reflect.
11:11
<Jake Archibald>
The latter seems simpler, but that means interaction with the element results in attribute changes, which has surprised some (eg triggering DOM mutation listeners/observers).
11:19
<Jake Archibald>
The former has better DX for frameworks that have 'controlled' vs 'uncontrolled' patterns, where they either want to declare the current value or the initial value respectively.
11:34
<Jake Archibald>
If we went for the defaultValue + value model, I assume that the value getter would get from defaultValue if its own internal value wasn't set?
13:24
<annevk>
Jake Archibald: that's essentially how it works today. At the risk of being utterly redundant, content value is IDL defaultValue and IDL value is the internal value which defaults to content value.
13:26
<annevk>
I guess I'm not sure if I'd rename content value to content defaultvalue or rename IDL value to IDL currentValue and IDL defaultValue to IDL value. I kinda like the optics of the latter.
13:40
<Jake Archibald>
Makes sense. Although I think, without a "default" or "current" suffix, people would likely assume the value was 'current'