- From: Stuart Ballard via GitHub <sysbot+gh@w3.org>
- Date: Mon, 22 May 2017 15:52:49 +0000
- To: public-css-archive@w3.org
> They don't do that, tho. As the SO answers state, :read-write doesn't match disabled form controls (tho it does in Chrome, at least), while it *does* match <textarea>, which isn't what you want. Actually I _would_ want it to match `<textarea>`, and anything that's `contenteditable` as well. > Regardless of how we decide this, it won't support your use-case properly. Perhaps I'm misunderstanding the discussion here, and if so I apologise. I thought that the issue was that the currently specified behaviour of `:read-only` and `:read-write` is problematic, vague, and doesn't have clear use cases; and that (probably because of these issues) they aren't widely used and maybe aren't worth continuing to support at all. My suggestion was to _change_ the specified behavior of those selectors to give them a clearer reason for existence, rather than removing them entirely or continuing to support something that's not especially useful or used. Specifically, my suggestion is to keep the behaviour of `:read-write` essentially unchanged, and define it explicitly as referring to any kind of editable _text entry_ (that is, `<textarea>` and all `<input>` types that render as textboxes, as long as they aren't `readonly` or `disabled`, along with anything `contenteditable`), and change the definition of `:read-only` to mean "editable text entry controls where editing is disabled", so it'd match `<textarea>`s and textbox `<input>`s that are `readonly` or `disabled`. Is there some reason why such a change can't be considered? -- GitHub Notification of comment by sab39 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/127#issuecomment-303141311 using your GitHub account
Received on Monday, 22 May 2017 15:52:56 UTC