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

selectionStart/End/Direction on input and textarea should not be nullable #2175

Closed
foolip opened this issue Dec 14, 2016 · 7 comments
Closed

Comments

@foolip
Copy link
Member

foolip commented Dec 14, 2016

https://html.spec.whatwg.org/multipage/forms.html#the-input-element
https://html.spec.whatwg.org/multipage/forms.html#the-textarea-element

For both elements, the spec currently says:

  attribute unsigned long? selectionStart;
  attribute unsigned long? selectionEnd;
  attribute DOMString? selectionDirection;

However, the prose never return null:
https://html.spec.whatwg.org/multipage/forms.html#dom-textarea/input-selectionstart
https://html.spec.whatwg.org/multipage/forms.html#dom-textarea/input-selectionend
https://html.spec.whatwg.org/multipage/forms.html#dom-textarea/input-selectiondirection

http://codepen.io/anon/pen/VmEgww is a test case for this. Chrome, Edge, Firefox and Safari all return 0 as the intial values for selectionStart and selectionEnd

There's some interesting variation for selectionDirection, but it's never null.

Spec change is trivial, but need to update web-platform-tests.

Found by @LoonyBean while investigating why this is nullable in spec but not in Blink.

@foolip foolip added good first issue Ideal for someone new to a WHATWG standard or software project needs tests Moving the issue forward requires someone to write tests labels Dec 14, 2016
@domenic
Copy link
Member

domenic commented Dec 14, 2016

They do return null:

For input elements, calling these methods while they don't apply, and setting these attributes while they don't apply, must throw an "InvalidStateError" DOMException; and getting these attributes while they don't apply must return null. Otherwise, they must act as described below

There are previous bugs on this that changed it from throwing to returning null. Web platform tests were even updated :)

@foolip
Copy link
Member Author

foolip commented Dec 14, 2016

Oh, so I started by testing textarea, and didn't think about <input type=color> and such. I take that for textarea they actually can't ever return null, and we could change the IDL to reflect that?

@foolip
Copy link
Member Author

foolip commented Dec 14, 2016

Previous changes were in #1006

@annevk
Copy link
Member

annevk commented Dec 15, 2016

So we have a section "APIs for the text control selections" where there is an IDL fragment that lists some things shared between input and textarea elements. This change breaks that snippet as they no longer match. How do you want to fix that?

@annevk annevk reopened this Dec 15, 2016
@domenic domenic removed good first issue Ideal for someone new to a WHATWG standard or software project needs tests Moving the issue forward requires someone to write tests labels Dec 15, 2016
@foolip
Copy link
Member Author

foolip commented Jan 4, 2017

Sorry, I didn't notice that. Would it suffice to append // nullable only for input for the three attributes?

@annevk
Copy link
Member

annevk commented Jan 4, 2017

Maybe we should just remove the extract?

@zcorpan
Copy link
Member

zcorpan commented Jan 4, 2017

Removing SGTM.

annevk pushed a commit that referenced this issue Jan 18, 2017
domenic added a commit that referenced this issue Feb 6, 2017
Fixes #2275 by making it do nothing, instead of throwing, when it does
not apply. This matches all browsers.

In the process, this inlines the "does not apply" behavior (which was
previously in a prelude that readers often missed; see e.g. #2175), and
makes all the setters, getters, and methods into algorithms with steps
instead of just paragraphs.
domenic added a commit that referenced this issue Feb 9, 2017
Fixes #2275 by making it do nothing, instead of throwing, when it does
not apply. This matches all browsers.

In the process, this inlines the "does not apply" behavior (which was
previously in a prelude that readers often missed; see e.g. #2175), and
makes all the setters, getters, and methods into algorithms with steps
instead of just paragraphs.
alice pushed a commit to alice/html that referenced this issue Jan 8, 2019
alice pushed a commit to alice/html that referenced this issue Jan 8, 2019
alice pushed a commit to alice/html that referenced this issue Jan 8, 2019
Fixes whatwg#2275 by making it do nothing, instead of throwing, when it does
not apply. This matches all browsers.

In the process, this inlines the "does not apply" behavior (which was
previously in a prelude that readers often missed; see e.g. whatwg#2175), and
makes all the setters, getters, and methods into algorithms with steps
instead of just paragraphs.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants