W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > December 2010

[Bug 11554] :read-write selector spec is ambiguous on editable input/textarea fields

From: <bugzilla@jessica.w3.org>
Date: Wed, 15 Dec 2010 13:44:20 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1PSreW-0000Ab-P5@jessica.w3.org>

Ms2ger <Ms2ger@gmail.com> changed:

           What    |Removed                     |Added
                 CC|                            |Ms2ger@gmail.com
          Component|pre-LC1 HTML5 spec (editor: |HTML5 spec (editor: Ian
                   |Ian Hickson)                |Hickson)

--- Comment #1 from Ms2ger <Ms2ger@gmail.com> 2010-12-15 13:44:19 UTC ---
(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);

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 15 December 2010 13:44:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:35 UTC