-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Submitting element directionality for various input element types #9206
Comments
Yeah, you are correct. That note is very misleading currently. I think extending step 11 is the way to go, though I would augment the existing conditional instead of adding a new step. Also, don't forget about |
We could check for whether dirname applies when the element is an |
We could, though I think checking the state is better because:
|
Sure, I can submit a pull request. I came up with three formulations for the condition. By referencing concept-input-apply, it stays somewhat actionable. I believe, for two and three, the note is not necessary anymore. If we remove the note, I would favor the latter two options.
|
Dropping the note seems good, how about something like:
|
…ch type This is in reference to the html issue [9206](whatwg/html#9206)
With regard to input elements, the dirname attribute only applies for the elements in the text and search state. But the algorithm for constructing an entry list does not enforce this. A possibility would be to extend step 11 with: If the element is an input element whose type attribute is not the Text or Search state, continue. This makes it easier for browsers to behave consistent and it becomes obvious for which types the submission of dirname would succeed.
Currently, a user could deviate from the standard and specify dirname on other types of input elements. While the standard states that dirname does not apply and must not be specified for non-text, non-search input types, it is not specified how to enforce this. Though, given multiple continue instructions within the construction of an entry list, it becomes obscure under which situations such a deviation might succeed.
I am currently implementing this attribute in Firefox and compared a first implementation to Chrome. I tested the attribute on an input element with empty value. Both browsers might submit the directionality if the type attribute corresponds to tel, url, email, password and number while only Firefox would also submit for hidden, date, month, week, datetime-local, range and color.
@zcorpan
The text was updated successfully, but these errors were encountered: