11554 2010-12-15 08:37:30 +0000 :read-write selector spec is ambiguous on editable input/textarea fields 2011-08-04 05:15:04 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified PC All RESOLVED FIXED http://dev.w3.org/html5/spec/Overview.html#selector-read-write P2 normal --- 1 ehsan ian bzbarsky ian mike mounir Ms2ger public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 43373 0 ehsan 2010-12-15 08:37:30 +0000 Please see the :read-write selector in the current version of the spec. To quote it here: The :read-write pseudo-class must match the following elements: * input elements to which the readonly attribute applies, but that are not immutable (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 * any element that is editable I find it really hard to determine whether this means that :read-write should match the input element in the following markup or not: <div contenteditable="true"> <input readonly> </div> I would expect the logical thing to do here would be to make it match :read-only, which is what would be inferred from the spec if the bullet point list above is interpreted as a set of if-else conditions. But I think we should be more specific here anyways. 43377 1 Ms2ger 2010-12-15 13:44:19 +0000 (In reply to comment #0) > The :read-write pseudo-class must match the following elements: > > * input elements to which the readonly attribute applies, but that are not > immutable (i.e. that do not have the readonly attribute specified and that are > not disabled) Doesn't apply, as the readonly attribute is present. > * textarea elements that do not have a readonly attribute, and that are not > disabled Doesn't apply, as it isn't a textarea. > * any element that is editable "editable" is defined as follows: > Specifically, if an HTML element has a contenteditable attribute set to the > true state, or *it has its contenteditable attribute set to the inherit state > and if its nearest ancestor HTML element with the contenteditable attribute > set to a state other than the inherit state has its attribute set to the > true state,* or if it and its ancestors all have their contenteditable > attribute set to the inherit state but the Document has designMode enabled, > then the UA must treat the element as *editable* (as described below). The input has no contenteditable attribute, so it is in the /missing value default/ state, which is /inherit/. Its parent has a contenteditable attribute in the /true/ state, so the clause I emphasised above applies. Thus, the element is "editable". This clause applies, so :read-write matches. > > I find it really hard to determine whether this means that :read-write should > match the input element in the following markup or not: > > <div contenteditable="true"> > <input readonly> > </div> > > I would expect the logical thing to do here would be to make it match > :read-only, which is what would be inferred from the spec if the bullet point > list above is interpreted as a set of if-else conditions. But I think we > should be more specific here anyways. IMHO, it is sufficiently clear. In pseudo-code, the bullet points would read bool IsReadWrite(Element* e) { if (e->IsHTML("input") && e->ReadonlyApplies() && !e->Immutable()) return true; if (e->IsHTML("textarea") && !e->HasAttr("readonly") && !e->Disabled() return true; if (e->Editable()) return true; return false; } bool IsReadOnly(Element* e) { return e->IsHTML() && !IsReadWrite(e); } 43398 2 ehsan 2010-12-15 16:03:12 +0000 So, is this intentional for readonly input elements to match :read-write? Should the UA allow the user to treat them as editable controls, as if they had no readonly property to begin with? 43399 3 bzbarsky 2010-12-15 16:33:14 +0000 > IMHO, it is sufficiently clear. No, it's not (as evidenced by at least two smart people getting confused by it so far!). What would be sufficiently clear is: The :read-write pseudo-class must match elements that satisfy any of the following conditions: followed by a list of conditions. If you mean something, just say what you mean instead of implying it! 43402 4 mounir 2010-12-15 17:21:25 +0000 So, according to the specs, the input in this case has :read-write applying: <div contenteditable> <input readonly disabled> </diw> Is this input's value modifiable by the user? I would say no, at least because of the disabled attribute [1]. So, we have an element matching :read-write but is technically read-only. Do we really want to do that? Can't we have this list changed to this: * If the elemnet is an input element to which the readonly attribute applies, but that are not immutable (i.e. that do not have the readonly attribute specified and that are not disabled) * If the element is a textarea element that do not have a readonly attribute, and that are not disabled * If the element is not an input element nor a textarea element and is editable That way, the input element in the previous code will be read-only and match :read-only. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#enabling-and-disabling-form-controls 43426 5 Ms2ger 2010-12-16 13:15:57 +0000 I'm not sure how else "The :read-write pseudo-class must match the following elements:" would be read than as the intersection of the sets defined by each bullet point. Also, IMO, it makes sense for the input to be :read-write as, despite not being able to type *into* the input, one can delete the entire input. 43427 6 Ms2ger 2010-12-16 13:17:11 +0000 (In reply to comment #5) > as the intersection The union, I should say. 43435 7 bzbarsky 2010-12-16 17:34:56 +0000 > I'm not sure how else "The :read-write pseudo-class must match the following > elements:" would be read Other places the spec uses similar wording for if/else cascades (which is how I believe Mounir read it) or conditions that need to be anded as opposed to or'ed. Seriously, just being explicit about which set operations should be applied to the sets defined by the conditions instead of writing something that implies something and then hoping that everyone, including non-native-English-speakers will properly understand your implications seems like a no-brainer to me.... 43511 8 mounir 2010-12-21 21:04:29 +0000 (In reply to comment #5) > Also, IMO, it makes sense for the input to be :read-write as, despite not being > able to type *into* the input, one can delete the entire input. Being able to delete the input doesn't mean you can write into it/modify it. That is how I was seeing :read-write but I guess you can consider that deleting is already a form of interaction... 44204 9 ian 2011-01-11 19:51:35 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: Apologies for the weak text. I've tightened it up. I've also made whether inputs and textareas match :read-write not get affected by whether they're inside editing hosts. 44205 10 contributor 2011-01-11 19:51:45 +0000 Checked in as WHATWG revision r5769. Check-in comment: clarify :read-write http://html5.org/tools/web-apps-tracker?from=5768&to=5769 53558 11 mike 2011-08-04 05:15:04 +0000 mass-move component to LC1