- From: Domenic Denicola <d@domenic.me>
- Date: Fri, 4 Aug 2017 19:47:08 +0000
- To: Jonathan Zuckerman <j.zuckerman@gmail.com>, "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>
Hi Jonathan, sorry for the delay in responding here. > This doesn't quite jive with my understanding of the distinction between > `readonly` and `disabled` - to me, "readonly" and "disabled" controls can both > not be edited by the user, but "readonly" means that the value will be > included in the payload when the form is submitted, whereas "disabled" > means that the value will not be included. It seems like this distinction does > apply to `button`, `checkbox`, and `select` as well as for `input`. It's true that there is also an impact on form submission. This was discussed somewhat recently in https://github.com/whatwg/html/issues/2311. Perhaps the section you quoted should be updated to also point this out, and discuss the tradeoffs we go through in that thread. > One other related question - it seems like select inputs are always matched > by the `:read-only` selector in CSS, but the `readOnly` property in Javascript is > always `undefined` - the inconsistency there makes me think that something > is not right... https://jsfiddle.net/jrz/yt1c3ee7/ Yeah, unfortunately :read-only in CSS is only vaguely connected to the readonly="" attribute. It's more about "is it not possible to edit this?" You can find its full definition at https://html.spec.whatwg.org/multipage/semantics-other.html#selector-read-only. As you can see the reason <select> is :read-only is because it isn't considered an "editable" form control for these purposes---just like <div>. Note that divEl.readOnly is also undefined, so this is basically consistent.
Received on Friday, 4 August 2017 19:47:37 UTC