[whatwg/fetch] :read-only and :read-write selectors: Consistency and cross-UA behavior (#672)

This is a cross-post of w3c/csswg-drafts#127 by @cvrebert, because [its issues are more relevant to HTML than to CSS](https://github.com/w3c/csswg-drafts/issues/127#issuecomment-368032602).

> Copying this over from http://lists.w3.org/Archives/Public/www-style/2016Apr/0294.html
(Disclaimer: My opinions are my own, not my employer's.)
>
> [:read-only is currently spec'd as (basically) `:not(:read-write)`](https://html.spec.whatwg.org/multipage/scripting.html#selector-read-only), and :read-write is currently spec'd as matching:
>
> * <input> elements to which the readonly attribute applies, and that are mutable (i.e. that do not have the readonly attribute specified and that are not disabled)
> * <textarea> elements that do not have a readonly attribute, and that are not disabled
> * elements that are editing hosts or editable and are neither <input> elements nor <textarea> elements (i.e. contentEditable / designMode)
>
> (A) This leads to an anomaly: Some inputs that the user can interact with to alter their "value" (which most folks would thus casually deem "writable") match :read-only instead of :read-write.
Namely, <input>s of type range, color, checkbox, radio, and file are :read-only since the readonly attribute doesn't apply to them.\
> (One can argue that this is a bug in HTML and that HTML should just allow the readonly attribute on these input types.)
>
> (B) There's a question of whether the buttonish <input>s (types: image, submit, reset, button) should be :read-only or :read-write. Arguably, they should be :read-only since the user cannot normally directly modify their values. They are interactive insofar as they're clickable, but they aren't editable. However, Chrome and Edge currently have them matching :read-write, which doesn't conform with the current spec.
>
> (C) There's a question of whether <input type="hidden"> should match :read-only or :read-write or neither. Per spec, it currently matches :read-only. But in Chrome and Edge, it currently matches :read-write.
>
>(D) I think there's some question as to how useful the contentEditable case is, particularly when it's lumped together with the form input cases.
>
> ***
> 
> Current state of affairs (FWICT):
>
> * WebKit matches the current spec and [doesn't want to change their implementation until the spec itself is changed](https://github.com/w3c/web-platform-tests/pull/2843#issuecomment-211687381).
> * Blink and Edge both suffer from 2 bugs relative to the current spec:
>   * :read-only doesn't match <input>s to which the readonly attribute does not apply
>     * https://bugs.chromium.org/p/chromium/issues/detail?id=604154
>     * https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/7229941/
>       * As stated in a comment and on the www-style thread, the Edge folks (understandably) don't think the spec's current behavior here makes sense.
>   * :read-write shouldn't match <input disabled> or <textarea disabled>
>     * https://bugs.chromium.org/p/chromium/issues/detail?id=604117
>     * https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/7226201/
>     * (Gecko's prefixed implementation also suffers from this bug)
> Gecko currently only has a prefixed implementation. Relative to the current spec, it has the one aforementioned bug.
>   * Feature request / unprefixing bug: https://bugzilla.mozilla.org/show_bug.cgi?id=312971
>
> ***
>
> And in light of the lack of compatibility and questions about the utility of these pseudos as-then-specd, it looks like Hixie asked the spec editors ~3 years ago in https://www.w3.org/Bugs/Public/show_bug.cgi?id=17812#c24 whether :read-only & :read-write could be removed from the spec altogether, but he never got a reply.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/672