Html: Non-normative note about disabled controls disallows selection

[domenic]

Via https://bugs.chromium.org/p/chromium/issues/detail?id=626581. See also https://bugzilla.mozilla.org/show_bug.cgi?id=195361.

https://html.spec.whatwg.org/multipage/forms.html#the-readonly-attribute:attr-input-readonly says

The difference between disabled and readonly is that read-only controls are still focusable, so the user can still select the text and interact with it, whereas disabled controls are entirely non-interactive. (For this reason, only text controls can be made read-only: it wouldn't make sense for checkboxes or buttons, for instances.)

This note implies a connection between focusability and text selection, and between disabledness and text selection, which I cannot find anywhere in the normative parts of the spec. Furthermore, it is uncharacteristic of the spec to constrain UI features like text selection in this way.

Probably we should just remove the mention of selection? Unless someone can find a normative requirement I missed.

Alternately we could add a user-agent stylesheet rule of user-select: none, if this is desired behavior.

[upsuper]

I think this is the desired behavior as it matches general expectation from native apps, so I'd suggest we add user-select: none in user agent style sheet. And it still makes sense to allow authors and users to revert this behavior via specifying user-select in their style sheets.

[domenic]

I don't find that argument persuasive, as it would argue for adding * { user-select: none; } to match native apps.

[upsuper]

Normal text in document is considered content text, which is different from form controls. I can probably argue that we should have label { user-select: none; }, but not for other things.

I believe browsers have made great effort on making appearance of form controls match native widgets by default. That indicates that we expect users to have the same experience on form controls as they have on native apps.

[upsuper]

And people against this usually state that everything else is selectable in web pages, which is simply not true. Are we going to allow text inside buttons to be selectable? Or items in select lists to be selectable?

[domenic]

Text inside buttons and select boxes is selectable in Chrome and Edge (I don't have Safari to test with).

To me, this back-and-forth underscores my point: the spec should not be placing restrictions on browser UI choices like this. Firefox wants to enforce a UI where web pages act more like native apps, and that's fine. Other browsers have chosen not go that route. That should be a product decision, not a spec decision.

[sideshowbarker]

That “disabled controls are entirely non-interactive“ note was added in https://github.com/whatwg/html/commit/65216fce862018e2052a7edd24485e41839dae6d and the commit message doesn’t reference any bug number or discussion.

[upsuper]

Text inside buttons and select boxes is selectable in Chrome and Edge (I don't have Safari to test with).

Actually, no. Text inside <button> is selectable, but text inside <input type="button"> is not. You may want to make them consistent.

[upsuper]

I still think the spec should say one way or the other. I'm fine to make Gecko match the spec even if it requires the different way, although I don't quite agree with it.

[jrouquie]

I would like to take the user point of view. It seems that

• developers aren't always aware of the selectability implication when they just want their control to be non focusable
• and that users are frustrated of not being able to copy-paste the text (see for instance https://bugzilla.mozilla.org/show_bug.cgi?id=195361#c38 ).

Surely the spec could help both, by making focusability and text selection independant, and by allowing casual users (the majority who don't know about user agent stylesheet) to select text, unless maybe when the developer explicitely forbids it.

[domenic]

I've posted a clarification at #1873 that makes the spec not take a stand on the UI issues like selectability, so Firefox can continue with their preferences and others can continue with theirs. As an editor it is my strong opinion that this is a more appropriate line to draw, especially given that it already matches the normative contents of the spec, and just clarifies a confusing non-normative note.

[annevk]

Note that selection with form controls is scoped somehow. E.g., if you have a textarea and select text around, the text inside the textarea is not selected and vice versa. That is probably also why you see differences between <input type=button> and <button>.

I don't think we have a good definition yet of how these controls work in terms of selection, focus, and general user interaction.

[upsuper]

Actually, in Blink, if you select text around a textarea, the content inside the textarea is also selected. That matches what CSS UI 4 says for user-select: contain.

[annevk]

It seems strange for CSS to start defining this as they haven't really defined form controls in much detail at all thus far. If that's their plan however I suppose it makes sense for HTML to defer to that.