[whatwg] Forms-related feedback

[Ian Hickson]

On Fri, 7 Sep 2012, TAMURA, Kent wrote:
>
> Proposal:
> 
> I'd like to propose adding new IDL attribute to HTMLInputElement.
>    readonly attribute DOMString rawValue;
> 
> It returns text content which a user actually see in an input field.
> [...]
> * For email type, it returns a string which a user is editing.  It means it
> returns a string without Unicode -> Punycode conversion and without
> normalization of whitespace and commas.

This only makes sense if the control is a text control, which is not 
necessarily the ideal UI. For example, consider the GMail UI for typing 
e-mail addresses. What would you expose as the rawValue when the control 
contains two user chips, one word that is not yet converted to an e-mail 
address, and the user is dragging one of the chips to the end?


> * For number type, it returns user-editing string. If a user typed '123+++'
> into a number field, rawValue would be '123+++' as is.

What if the number control is a spin dial and the user has the dial 
between numbers "1" and "2"?


> * For date, datetime, datetime-local, month, time, week, the attribute 
> returns a string in a field. If a field is text-editable, it should 
> return user-editing string like email and number.  If a field has a 
> fixed localized date/time string chosen by a date/time picker, the 
> attribute should return the localized string.
> [...]
> - We can enable text field selection APIs for email, number, and other 
> types

How would this work when the control isn't a text control? I don't 
understand. For example, consider a date control that is actually three 
separate text fields (year month day); how do you envisage the selection 
API working and how would rawValue help with this?


> - JavaScript-based screen readers can read user-visible content of input 
> fields.

Screen readers don't have to be limited to the HTML APIs. I'd expect a 
screen reader to have a much more intimate API to talk to the UA.


> Strings returned by rawValue attribute may be browser-dependent and 
> locale-dependent. However it would be useful.

I think browser-dependent and locale-dependent APIs are a recipe for 
interoperability disaster.


I agree with the underlying use case of more detailed control over the 
widgets. But the way to fix that isn't to bolt on more and more 
browser-specific APIs to <input>, IMHO; the long-term fix is to implement 
a Web components model and allow the controls to be directly overridden.


On Mon, 10 Sep 2012, Kang-Hao (Kenny) Lu wrote:
> 
> For inputs that are being edited (date, datetime, datetime-local, month, 
> time, week, number), I wonder if we should instead remove restrictions 
> like this:
> 
>   # User agents must not allow the user to set the value to a non-empty
>   # string that is not a valid floating-point number.
> 
> and just let .value returns the raw input while a user is editing the 
> value and let value sanitization algorithm happen afterward.

I don't really understand the value in this. Why can't the page just get 
out of the way and let the browser and user work together?


On Tue, 11 Sep 2012, TAMURA, Kent wrote:
> 
> Yes, I'd like to enable selection API for at least type=email and 
> type=number.  All of their existing implementations are text fields. I 
> haven't seen a request to suport selection API for type=email, etc.. 
> However lack of selection API looks a defect to me.

Why does the page need to touch the selection?


On Fri, 7 Sep 2012, Mikko Rantalainen wrote:
> 2012-09-07 07:35 Europe/Helsinki: Ian Hickson:
> > On Thu, 30 Aug 2012, Jonas Sicking wrote:
> >> 
> >> I think while in theory we could rely on UAs to enable barcode entry 
> >> anywhere, which definitely would provide the maximum capabilities for 
> >> [...]
> > 
> > In this respect it's similar to the WebKit-proprietary x-webkit-speech 
> > attribute on <input>. In fact, this suggests that if other browsers 
> > are interested in supporting speech input, maybe we should standardise 
> > it as an inputmode value, e.g. inputmode="speech". Possible the 
> > inputmode="" attribute in that case could be switched to a list of 
> > tokens, so you could in fact do inputmode="latin-prose speech" or 
> > inputmode="numeric barcode" in order to provide the user agent with 
> > more flexibility in the UI.
> 
> While I agree that inputmode attribute should be made a space separated 
> list of tokens, I'd avoid stuff like "latin-prose". Expected input 
> language should be specified via lang or xml:lang attributes instead.

"Latin" here doesn't refer to the language, but to the input method (e.g. 
QWERTY or QWERTZ keyboard as opposed to hiragana mode in Japan).


> Examples of somewhat sensible inputmode values for input type=text:
> 
> - "unicode" or "text"

This isn't "sensible" since it doesn't say whether a dual-label 
latin/hiragana keyboard should be in latin mode or hiragana mode or 
whether a dual-label numeric/alphabetic phone keypad should be in numeric 
or alphabetic mode.


> - "numeric" (prefer numeric input but allow any text)

That one is fine.


> - "barcode"

Barcode is borderline (and is the topic of this subthread). I could see 
having a barcode input method, e.g. on a phone the on-screen keyboard 
could be replaced by a viewfinder. However, this seems more theoretical 
than practical.


> - "speech" or "voice" (prefer voice input)

While I could see this being an explicit input method, in practice I think 
it's more likely that authors would prefer to switch their input device 
into this mode rather than focusing the control and finding themselves 
already in this mode. But it's borderline, like barcode.


> - "word"
> - "sentence"

Word with what kind of script? Sentence with what kind of script?


> - "letters" (e.g. "letters voice" means spell by letter)
> - "ascii" (prefer real 7 bit ascii over unicode text)

I don't understand how these would be used or why they're input methods 
rather than types or patterns.


On Fri, 7 Sep 2012, Tobie Langel wrote:
> 
> There seems to be some overlap, at least in semantics, with the capture 
> attribute described in HTML Media Capture[1] and recently filed for 
> inclusion in the Living Standard HTML spec[2].
> [1]: http://dev.w3.org/2009/dap/camera/
> [2]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17879
> 
> Anyway these two concepts can be reconciled or their distinction 
> clarified?

I must admit that I don't really see the point of the capture="" 
attribute. But in any case I don't think type="file"-specific features 
should be overloaded onto type="text"-specific features; that's just going 
to cause problems. Better to keep them separate.


On Thu, 13 Sep 2012, TAMURA, Kent wrote:
> 
> Making an input element invalid state if the input has an invalid string 
> specified by a user with browser UI. "An invalid string" means a string 
> which doesn't match to a required format defined by a type.
> 
>   e.g. If a user typed "-" to input[type=number], input.validity.valid
> would be false and form submission would be prevented.
> 
> A. In such case, make input.validity.typeMismatch true, or
> B. Introduce new IDL attribute to ValidityState.
> input.validity.invalidUserInput?
> 
> This behavior should be applied to the following types:
>   number, color, date, datetime, datettime-local, month, time, and week
> 
> Background:
>   If an input type is implemented as a text field, it is very hard for UA
> to reject invalid strings for the type. For example, "-" is not a valid
> floating-point number, but UA can't prevent users from typing "-".  So the
> field can contain invalid strings though its value IDL attribute is empty.
> If a user tries to submit the form in such situation, the field is valid
> unless the required attribute is specified.
>   WebKit clears the invalid string when the field loses focus or the form
> is submitted.  A sanitized value (empty string) is submitted.
>   Opera doesn't clear the invalid string. It silently submits a sanitized
> value (empty string).
>   IE10 has a behavior similar to WebKit.  However if a user
> type "-1abc", "-1abc" is submitted.
> 
> I don't like clearing user input.  It's not a good user experience.  Users
> don't expect their input strings are cleared by UA.
> Also, I don't like submitting empty value silently. Users expect their
> input strings are submitted.
> I think the best UI is to notify users about a field has an invalid string,
> and give a chance to correct it.  Applying the standard form validation
> mechanism must be reasonable.

Done ("badInput").


On Tue, 20 Nov 2012, Mounir Lamouri wrote:
> 
> Currently stepUp(n) and stepDown(n) are very basic methods. They more or 
> less do value += n * allowedValueStep; with n = -n; if stepDown() was 
> called. In addition of being pretty dumb, there are a lot of reasons why 
> they can throw.
> 
> At Mozilla, we think that the main use case for stepUp() and stepDown() 
> is to create a UI with spin buttons: clicking on the up arrow would call 
> stepUp() and clicking on the down arrow would call stepDown(). Such a 
> use case needs methods that do better than just adding n * 
> allowedValueStep. In addition, we think that throwing is very often a 
> bad idea and that should happen when the developer clearly did something 
> wrong.
> 
> So, we would like to change the stepUp()/stepDown() algorithm to match
> the following behaviour:
> - we only throw if the input type doesn't allow those methods or if
> there is no allowed value step;
> - if the value isn't a number (aka empty string), we should just exit
> the steps;
> - if the value is below the minimal allowed value and n is negative, we
> should exit the steps;
> - if the value is above the maximal allowed value and n is positive, we
> should exit the steps;
> - if the element is suffering from a step mismatch, and n is negative,
> the value should be changed to the next valid value. Otherwise, it
> should be changed to the previous allowed value;
> - newValue = value + n * allodValueStep;
> - if the newValue is below the minimal allowed value, the newValue
> should be equal the minimal allowed value;
> - if the newValue is higher than the minimal allowed value, the newValue
> should be equal the minimal allowed value.
> 
> Such a behaviour creates a real added value in stepUp() and stepDown() 
> that make those methods useful compared to simply do value += n * 
> allowedValueStep; and prevent throwing when there is no need to.

Done, though I described it in a different way. (I hope it's equivalent.)


> [1] The only difference between Chrome's spin buttons behaviour and our 
> proposal is that when value is the empty string, it is setting value to 
> 0 and continue to the next steps (unless the 0 is below the minimal 
> allowed value and n < 0, in that case value=min). It might be 
> interesting to specify something better than "do nothing" if value="".

I'm open to doing that too; what would you preference be?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'