-
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
Fix form inheritance behavior for autocapitalize #3373
Conversation
I'm actually not sure "form-associated element" is what we want either. These are the form-associated elements: https://html.spec.whatwg.org/multipage/forms.html#categories
However, WebKit currently only applies form inheritance to elements it considers to be "form controls" (elements implemented by subclasses of HTMLFormControlElement). This includes:
I.e. Safari doesn't inherit for img or object elements. Does this list make sense to use in the spec? It seems a tad arbitrary but I also don't see any compelling reason to deviate from the behavior as already implemented. |
I wonder what @hober and @othermaciej think. It seems better to reuse an existing set if we can. Listed/submittable are both pretty close. (@rlanday you also need to make it public you're a member of the https://github.com/google organization so @whatbot knows the IPR is in order.) |
@cdumez might know about this or may know who to ask. |
FWIW I could go either way. We already divide form-associated elements up into several subcategories, and adding a new one called "Autocapitalizable elements" (or something more generic?) would be reasonable; trying to specify autocapitalization for img and object doesn't make a lot of sense. Note that "listed elements" = "form-associated elements" minus On the other hand, not inventing a new category just for this sounds kind of nice as well. |
In the interest of coming to a conclusion so I can move forward with implementing this in Chrome, I propose we pick one of the following two options:
I would be fine with either option, but would like to be able to resolve this fairly soon. |
@rlanday Out of those two options, (2) is clearly better. Changing the behavior creates compatibility risk and the only benefit is spec simplicity. Seems like compat should clearly win, unless we can do something to evaluate the risk and demonstrate the simplicity value. As for changing to use the set of form-associated elements: it seems like the difference between HTML's concept of "form-associated elements" and WebKit's set of "form elements" is the inclusion of The list of "listed form-associated elements" is a closer match, except for the inclusion of |
@othermaciej my understanding is the choice of list here, whether it's { input, textarea } or listed elements or form-associated elements, is the behavior of the IDL attribute on e.g. Concretely: <form autocapitalize="words">
<input type="text" id="textInput">
<img id="image">
<object id="object">
</form> We know that No matter how that question is answered, I don't think anyone is planning to actually use the autocapitalization information to attempt to auto-capitalize stuff inside images or objects somehow. So I don't think it has much practical impact, and this is mostly about getting edge-case interop. |
I agree with @domenic. I don't think there's much actual compatibility risk here, but if we think there might be some in only including |
I guess the more I stare at it, the more I think just using form-associated elements is the "conceptually cleanest" approach: we have decided that part of the computation of the But, I can understand the desire for shortest-path-to-interop. In that case we can just update the patch with a new category ("form-associated autocapitalizable elements", I suppose). |
It’s probably less risky to expand the set Safari is shipping than reduce it. Safari’s choice of elements that inherit autocapitalize behavior is likely an artifact of implementation and not any kind of purposeful choice. But sadly mobile-centric sites sometimes come to depend on our quirks, even when it seems kind of improbable that they would. So we usually try to do some kind of testing before making changes. |
@othermaciej, based on what you're saying, I think we should just update the spec to exactly match the current implementation. I don't think we have a compelling reason to change the behavior, other than just not having to list the elements in the spec. If everyone is OK with this, I will update this pull request after I update the test case I'm working on to cover this behavior and verify that it passes in iOS Safari. |
3831cd8
to
9501f0b
Compare
I've updated the pull request and verified that this is the correct of elements that inherit the attribute in iOS Safari. |
Hmm, I'd rather define a new category, as I discussed earlier. That avoids the awkward note. |
9501f0b
to
fab120c
Compare
Ah, I apologize. Updated again. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks so much for the extra work here; I forgot how tricky adding a new category is. (One day, maybe, all that stuff will be auto-generated.)
One small issue but otherwise LGTM
source
Outdated
<var>element</var>'s <span>form owner</span>.</p></li> | ||
<li><p>If <var>element</var> is an <span | ||
data-x="category-autocapitalize">autocapitalize-inheriting | ||
element</span>, return the <span>own autocapitalization hint</span> of <var>element</var>'s |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't you still need the form owner check? E.g. document.createElement("button")
has no form owner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, did not mean to remove that. Fixed
fab120c
to
bfb3f6c
Compare
Is #3373 (comment) talking about web-platform-tests? |
Yes, I’m adding a WPT in https://chromium-review.googlesource.com/c/chromium/src/+/872090. |
Great, thanks! |
Kent Tamura ([email protected]) noticed a discrepancy between the autocapitalize form inheritance behavior I'm implementing in Chrome (and which iOS Safari has already implemented) and the behavior as defined by the spec:
https://chromium-review.googlesource.com/c/chromium/src/+/872090
In particular, the spec currently says only
<input>
and<textarea>
elements inherit autocapitalize (both the IDL attribute and the used behavior) from their form owner. iOS Safari implements this behavior for all form control elements. This discrepancy creates some subtle differences in behavior:The IDL attribute for non-
<input>
non-<textarea>
elements (e.g.<select>
,<fieldset>
, etc.) in a<form>
with autocapitalize set won’t be inherited according to the current spec behavior, but will according to the behavior as actually implemented in WebKit.Chrome supports contenteditable on
<output>
elements (it appears iOS Safari does not). This means if you write something like this:the spec says that the
<output>
should not inheritautocapitalize="characters"
, but WebKit does inherit it for the IDL attribute. (This case is kind of strange because although the<output>
is a form field, its contents are only editable because it hascontenteditable
on it).This pull request changes the spec to match the iOS Safari behavior and the behavior I intend to implement in Chrome. The new behavior is that the IDL attribute is inherited for all form-associated elements with a form owner, and for the oddball
<output contenteditable>
case, this is reflected in the used autocapitalization value as well./form-elements.html ( diff )
/forms.html ( diff )
/indices.html ( diff )
/input.html ( diff )
/interaction.html ( diff )