The "value" attribute of <input type="button"> should be directionality-capable

[jfkthame]

In the list of "directionality-capable attributes" at [1], I was surprised to find that the "value" attribute of was not included, even though this attribute's text is clearly expected to be rendered.

A simple testcase

data:text/html;charset=utf-8,<input dir="auto" type="button" value="العربي Latin">

(where the Arabic text logically precedes the Latin) shows the button label rendered with LTR directionality (the Arabic text appears on the left, the Latin on the right) in both Firefox and Safari; however, in Chrome it renders with RTL directionality (Arabic on the right, Latin on the left).

AFAICS, this is a Chrome bug w.r.t. the current spec, as this attribute is not listed as directionality-capable, but I think it would make more sense from an author's point of view to align the spec (and other browsers) with Chrome's behavior here.

See also the Firefox bug report https://bugzilla.mozilla.org/show_bug.cgi?id=1428316.

[1] https://html.spec.whatwg.org/multipage/dom.html#directionality-capable-attribute

[annevk]

Is it problematic if we apply this to all types of input elements or should we list the ones this should work for? E.g., it does not make much sense for <input type=date>, but it wouldn't be observable either, so probably fine?

cc @whatwg/i18n

[jfkthame]

I'd guess that applying it to all types of input is probably fine. Interestingly, further testing in Firefox shows that value does seem to be treated as directionality-capable for some types of input (any of those that simply render as a text field, I think), though the spec doesn't support that AFAICS; it says their placeholder (if present) would be directionality-capable, but not value.

[annevk]

Ah, I think currently it follows from https://html.spec.whatwg.org/multipage/dom.html#the-directionality (note how that refers to the "value" concept) coupled with https://html.spec.whatwg.org/multipage/dom.html#directionality-of-the-attribute. That does currently exclude input elements in the Button state though (and Reset/Submit Button).

[aphillips]

@annevk Values such as number, date, etc. shouldn't be directionality-capable since it is their local representation that's meant to be displayed and the value is a locale-neutral wire format.

The button case looks like an oversight to me: the value is meant to be displayed. What's more 4.10.5.1.21 disallows dirname on type=button, so the direction applied by dir=auto can't be discovered server-side.

[annevk]

So let's see. We want to change:

If the element is an input element whose type attribute is in the Text, Search, Telephone, URL, or E-mail state, and the dir attribute is in the auto state

To include Submit Button, Reset Button, and Button.

And we want to allow dirname on those three button states as well.

Note that we don't allow dirname for Telephone, URL, and E-mail. I guess that's fine?

[aphillips]

Note that we don't allow dirname for Telephone, URL, and E-mail. I guess that's fine?

I think that's right. I guess technically they could be directional, but in practice they aren't. IIRC, Adlam is the only numbering system where the digits are RTL and I don't think that'll be used much for phone numbers?

[annevk]

On reflection, I think my conclusion surrounding applying dirname to buttons is wrong as dirname is for end-user-supplied content and button values are supplied by the web developer. So this should be exclusively about updating the "directionality" algorithm.

cc @r12a

[aphillips]

The button values are supplied by the web developer, but when submitted the button's value looks just like any other value. While the web developer might own the receiving process, it's probably easier and better if the directionality of all fields work in the same way, rather than some requiring the developer to remember what direction was applied to a control like a button. (Also, many web applications are localized, often dynamically, so that button's direction will vary according to the locale used to compose the page--and not always derivable from the locale itself)

[annevk]

Thanks, that's compelling. I've folded that improvement into #9669 so we can keep this focused on "directionality".

Two outstanding questions for this issue:

• Should the value of a button should influence the directionality of the button itself or should it just influence the directionality of the attribute? I'm guessing the button itself makes the most sense.
• Should we reconsider what we do for Telephone here: https://html.spec.whatwg.org/#the-directionality? It seems like such a weird special case.

cc @fantasai @rniwa

[aphillips]

I agree that Telephone kind of "sticks out funny" and probably should not be an exception.

I played with it here a bit.

I noticed a bug in FF: dir=auto doesn't work on the button's value (works in Chrome). My tendency is to think that the value should influence the button, but I'm not sure if there might be weird side effects.

[annevk]

The main effect would be whether :dir ends up matching differently because of it, as far as I know. And I tend to agree it's better if it does.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17835 seems to cover the telephone change based on an extensive discussion with @aharon-lanin. I guess that argues for keeping it, even if it's a little weird.

(This also makes me wonder if custom elements should be able to set their own directionality, but that might be some quite advanced bit of technology that's not really needed in practice.)