kleinfreund, 28 days ago

@jaffathecake

> In fact, the value property doesn't reflect any attribute.

This doesn't sound entirely correct. Setting the value attribute is also (in addition to defaultValue) reflected by the value property if the input isn't dirty (e.g. the value property was set):

input.setAttribute('value', 'new')
console.log(input.getAttribute('value')) // 'new'
console.log(input.value) // 'new'
console.log(input.defaultValue) // 'new'

Or am I misunderstanding this?

jaffathecake, 28 days ago

@kleinfreund I see where you're coming from, but you can also explain that by it getting the defaultValue. Your explanation might be more accurate according to the spec, but it duplicates some logic

kleinfreund, 28 days ago

@jaffathecake Right, that makes sense.

One could say that the value property indirectly, via the defaultValue property, reflects the value attribute as long as the dirty flag isn't set.

Then again, to make this easier to understand, it's perhaps simpler to stick to simpler, separate rules:

• the defaultValue property reflects the value attribute
• the value property doesn't reflect any attribute
• the value property reflects the defaultValue property as long as the dirty flag isn't set

jaffathecake, 28 days ago

@kleinfreund yeah, that's the way I see it too

colby, 29 days ago

@jaffathecake "Initially, the value property defers to the defaultValue property" needs a re-read/correction.

jaffathecake, 29 days ago

@colby does it? What should it say?

colby, 29 days ago

@jaffathecake I don't have a recommendation for exact wording for you, but defining value in terms of defaultValue (rather than the other way around) is uncanny.

callionica, 29 days ago

@jaffathecake Nice article. When you stated the position that “attributes are for configuration”, you didn’t mention “attributes are for CSS”, so I wonder whether you considered it? For me, interesting state changes should be reflected as attributes so that they’re visible to CSS.

jaffathecake, 29 days ago

@callionica I disagree with that position - in the article I talk about how <details open> is a bad design.

callionica, 29 days ago

@jaffathecake You do say that you think there should have been a CSS pseudo class for targeting that state change. So I guess the implication is that you’d like to see a lot more pseudo classes? I’m not quite understanding the argument about why using attributes for state changes is bad though.

jaffathecake, 29 days ago

@callionica I believe the light DOM should be under the author's control, and the serialisation should represent changes the author made, not changes the browser made to itself.

This helps a lot with frameworks where you're trying to express "put the DOM in this shape" without overwriting interactivity, except in cases where you explicitly want that.

kleinfreund, 1 month ago

@jaffathecake Typo in "How frameworks handle the difference": extinction -> distinction?

jaffathecake, 1 month ago

@kleinfreund ohh, good catch. Pushing a fix…

tbroyer, 1 month ago

@jaffathecake Great post (as always)

Somewhat related (the first part): https://blog.ltgt.net/web-component-properties/

jaffathecake, 1 month ago

@tbroyer ohh this is a great deep dive