(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);
}

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?

> 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!

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

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.

(In reply to comment #5)
> as the intersection

The union, I should say.

> 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....

(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...

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.

Checked in as WHATWG revision r5769.
Check-in comment: clarify :read-write
http://html5.org/tools/web-apps-tracker?from=5768&to=5769

mass-move component to LC1