Move inputmode to not be dependent on forms

[dtapuska]

inputmode should apply to editing hosts as well as text based form controls. I'd prefer it wasn't inside the forms section. Perhaps there are other things as well that are applicable to content-editable.

This was discussed at TPAC in the editing group and it was indicated to just get the HTML spec updated.

@annevk How do you want to rejig the spec so that inputmode can be used on editing-hosts?

[domenic]

Very interesting. Other possibilities: autocomplete, autofocus. (I wonder why autofocus is nested under the "Form submission" section.)

I guess those sections would move under 6.6 Editing. Their wording will need to be rejiggered to talk less about form controls, and more about whatever we end up calling editable controls per #1892. Some new examples would be good.

And I guess all the element definitions that say that these attributes apply to only certain elements would need to remove that line, and they would need to move to the "Global attributes" section. Then the individual sections would need a conformance requirement saying that they are only used on editable controls.

First step is deciding which attributes beyond inputmode we want to move, IMO.

[dtapuska]

Personally I'd say autofocus, inputmode and https://rawgit.com/dtapuska/action-hint/master/index.html (eventually).

I'm not sure autocomplete is a great fit for content-editable at this time.

[annevk]

Do we have agreement on inputmode at this point? @mounirlamouri raised various issues around it in the past (and also suggested standardizing some of Apple's proprietary attributes in that area) and I don't think we've addressed any of that thus far.

Related:

• https://www.w3.org/Bugs/Public/show_bug.cgi?id=28228 (autocapitalize attribute and discussion on inputmode)
• https://www.w3.org/Bugs/Public/show_bug.cgi?id=28747 (autocorrect attribute)
• Digit input type #1626 (suggesting a new inputmode value)

[domenic]

I think there is a separable issue where we revise inputmode to be more in line with what browsers are interested in implementing. But indeed, I'm not sure of its current implementation status; maybe one path here is to remove inputmode entirely, then re-add it when it has multi-implementer interest, and at that time put it in a more general section.

[dtapuska]

My proposal presented at TPAC editing was https://rawgit.com/dtapuska/inputmode/master/index.html

It was decided that a separate spec shouldn't be written but we do it as a bunch of issues on the HTML spec. That is what motivated this issue.

My proposal adds a few additional keywords and don't implement some that are irrelevant on android. However I do see that some of them actually are supported by TSF so I'm not opposed to leaving some that already are there in if there was a strong desire from the community.

[mounirlamouri]

I think splitting capitalization behaviour and script specific types away from inputmode would be good.

@domenic would you be supportive of a pull request that adds autocapitalize to HTML?

[domenic]

I think splitting capitalization behaviour and script specific types away from inputmode would be good.

I realize this is probably an old discussion, so please feel free to link me somewhere it's been discussed previously, but why is that? Naively, they seem to fit together well.

would you be supportive of a pull request that adds autocapitalize to HTML?

Is there multi-vendor interest in it, and agreement on its behavior? If so, is there no strong opposition from other vendors? Those are generally the criteria. I suspect autocapitalize meets them, but you'd know better than me :). Also keep in mind that these days we are strongly encouraging tests with any pull requests, although I guess this might be an exception since it's not really testable except manually :(

[dtapuska]

@smaug---- I don't know who from Mozilla is relevant for Editing here.
@rniwa Can you comment on your support to move these things around? (autofocus, autocomplete, autocapitalize, inputmode)

On Android we don't have control over what type of script is supported on the virtual keyboard that I am aware of. So I don't really care to support all of those (see my initial proposal). But I understand that TSF (Microsoft's Text Services Framework) does support script information so I'm not opposed to keeping those values.

I do want to move this forward as this has been a topic for Polymer for some time now.

[smaug----]

Should this go to the proposed <contenteditable> only, not all the contenteditable stuff?
It was sort of agreed, or at least discussed that no new features should go to the old contenteditable.

@masayuki-nakano might have opinion on this.

[dtapuska]

@smaug---- I don't see <contenteditable> in the spec or any pull requests for adding this element. Where is the spec? To block this support on us collectively specifying contenteditable from the start seems like it would be a disservice to delivering a rich web experience.

[masayuki-nakano]

Although, as far as I know, nobody finishes implementing inputmode, I like making such attributes which are useful with <input type="text"> available with contentedtiable's editing host (like autofocus too).

So, for example,

<div contenteditable inputmode="latin">
  <p inputmode="latin-name"></p>
  <p inputmode="numeric"></p>
</div>

In this case, even if caret is in a <p>, these inputmode should be ignored because if browsers need to respect them, browsers needs to climbing up the tree from caret position at every selection change and it's unclear to respect which input mode when selection is not collapsed and across some inputmode attributes.

[smaug----]

@dtapuska I don't think there is a spec yet (not that there is a proper spec for contenteditable attribute either). was discussed during tpac, and new features should be exposed only there - that was at least the idea at that point. Better to ask editing task force folks about that.