Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-ui-4] Readonly form control and user-select #285

Open
upsuper opened this issue Jul 8, 2016 · 10 comments

Comments

Projects
None yet
5 participants
@upsuper
Copy link
Member

commented Jul 8, 2016

Currently, for user-select, CSS UI 4 says

on editable elements where the computed value is always contain regardless of the specified value

and it defines "editable elements" as

an editable element is either an editing host or a mutable form control with textual content, such as textarea.

It seems this would exclude readonly form controls from the computation rule above, because according to the HTML Standard, readonly form controls are not mutable. But I think that rule should be applied to those controls as well.

@frivoal

This comment has been minimized.

Copy link
Collaborator

commented Jul 8, 2016

This suggestion does seem to match the current behavior of UAs. If you create a <textarea readonly> element, the selection will be trapped in it.

Do you have a suggestion for the phrasing? The following would probably work, but it looks a bit clunky:

an editable element is either an editing host or a form control with normally mutable textual content such as textarea, even if this form control is in non mutable state.

"normally mutable but in non mutable state" is an attempt to include <textarea readonly> but not <label>.

@frivoal frivoal added the css-ui-4 label Jul 8, 2016

@frivoal frivoal self-assigned this Jul 8, 2016

@upsuper

This comment has been minimized.

Copy link
Member Author

commented Jul 8, 2016

Actually, UAs other than Gecko allow text in disabled form controls to be selected as well... And there is a bug which urges Gecko to follow that behavior... But I don't think that makes much sense so I opened an issue for Chromium, hoping they could change their behavior.

For phrasing, I don't have any idea... Otherwise I would have included that in my post :)

I wonder whether it makes more sense to use user agent stylesheet to do that, rather than making it a computation rule.

@frivoal

This comment has been minimized.

Copy link
Collaborator

commented Jul 8, 2016

Actually, UAs other than Gecko allow text in disabled form controls to be selected as well...

Yes, it can be selected, but the selection cannot escape the element.

The fact that this is true no only with readonly but also with disabled is why I used the "non mutable state" wording in the proposed phrasing, instead of specifically referring to the readonly attribute.

As for whether that should be done via computation or via UA stylesheet, that's a good question, but regardless of the answer, we should put the desired behavior in the spec.

@upsuper

This comment has been minimized.

Copy link
Member Author

commented Jul 8, 2016

Yes, it can be selected, but the selection cannot escape the element.

I meant, I don't think disabled form controls should be selectable...

@frivoal frivoal changed the title [css-ui] Readonly form control and user-select [css-ui-4] Readonly form control and user-select Apr 24, 2017

@frivoal

This comment has been minimized.

Copy link
Collaborator

commented Nov 3, 2017

Actually, I don't think we want to do this with the UA stylesheet, as that would mean that authors could override it, which may not be implementable, since form controls are often rendered with native elements, and having a selection extent from one to outside may not be doable.

So I suggestn going with the phrasing proposed in #285 (comment)

I've checked if we could simply say that it computes to contain on replaced elements in general, but that does not seem to be true, as for instance there's not contain effect on embedded svg.

@frivoal frivoal added the Agenda+ F2F label Nov 3, 2017

@astearns astearns removed the Agenda+ F2F label Nov 6, 2017

@frivoal frivoal added the Agenda+ F2F label Mar 27, 2018

@frlinw

This comment has been minimized.

Copy link

commented Jun 14, 2018

Even if user-select default value is contain for readonly input text/textarea, why the user couldn't force it to none ?

@frivoal

This comment has been minimized.

Copy link
Collaborator

commented Jul 25, 2018

@frlinw on non mutable ones, that seems reasonable. On actually mutable ones, it's not clear how editing would work, so none should not be allowed.

@css-meeting-bot

This comment has been minimized.

Copy link
Member

commented Jul 25, 2018

The Working Group just discussed Readonly form control and user-select Agenda+ F2F css-ui-4, and agreed to the following:

  • RESOLVED: Accept florian's proposal
The full IRC log of that discussion <dael> Topic: Readonly form control and user-select Agenda+ F2F css-ui-4
<dael> github: https://github.com//issues/285
<dael> florian: Recap: across all browsers afaict when you have editable text area regardles if form control or from contenteditable. When you start selection inside it it can't extend outside. Selection is trapped within
<dael> florian: This behavior is exposed in user-select as contain. Current spec says on editable elements it always does contain. Currently spec as editable content is mutable form controls and contenteditable elements. Moz raised that read-only form controls are not mutable so we should update spec
<dael> florian: Second part is once we do it for normally mutable but currently unmutable switching to user-select: none might be okay. Not clear how editing would work with selection disabled and no one wants to do that.
<dael> florian: So making contain apply to normally mutable but not currently mutable and then making contain switch to none for those.
<dael> florian: Should I wordsmith that into spec or do people think I missed something?
<dael> Rossen: Opinions?
<dael> Rossen: Objections to accepting florian's proposal to the spec?
<tantek> I'd prefer to get Xidorn's opinion
<dael> Rossen: I think it's time to force progress since it's gone through 3 F2Fs.
<tantek> can we discuss in APAC call?
<tantek> otherwise I do not object
<dael> Rossen: tantek xidorn can add his opinion on github.
<dael> florian: We're resolving in favor of his opinion
<dael> tantek: I'm asking that...florian if that's true can you put that into the issue? Just a back and forth to confirm. Why not make sure. You've got wordsmithing, put it in the issue, give xidorn a chance to say yes
<dael> florian: Can I put in PR and merge when he says okay?
<dael> tantek: Sure
<dael> RESOLVED: Accept florian's proposal
<dael> Rossen: Summary is form controls should be selectable?
<dael> florian: More complicated
<dael> florian: I'll create a PR with proposal and merge
<dael> Rossen: We'll look at your PR

@frivoal frivoal added the Needs Edits label Jul 25, 2018

@frivoal

This comment has been minimized.

Copy link
Collaborator

commented Jul 25, 2018

Edits will be made in a pull request first, to give a chance to @upsuper to check.

@frivoal frivoal removed the Agenda+ F2F label Jul 28, 2018

frivoal added a commit to frivoal/csswg-drafts that referenced this issue Jul 28, 2018

frivoal added a commit to frivoal/csswg-drafts that referenced this issue Jul 28, 2018

@frivoal

This comment has been minimized.

Copy link
Collaborator

commented Jul 28, 2018

I made #2961 to attempt to close this. Agenda+

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.