[whatwg] Allowing size and maxlength attributes for all new input types would provide better fallbacks

Mon May 23 14:44:44 PDT 2011

On Wed, 16 Feb 2011, Jukka K. Korpela wrote:
>
> The current version disallows the size and maxlength attributes in input 
> elements when type="time", type="date", type="datetime", 
> type="datetime-local", type="number", type="range", or type="color" is 
> used. I suppose the reason is that for other new input types, browsers 
> are expected to use advanced user interface, either with no visible text 
> field or with a text field of a size determined by the browser.
> 
> However, the method of extending forms with new input types is based on 
> the clever idea that using a new attribute in input elements, 
> non-supporting browsers will imply type="text" and use a normal text 
> input field as fallback. This idea gets somewhat broken if size and 
> maxlength attributes cannot be used. Setting the visible width and 
> imposing a maximum length of input in characters are often useful hints. 
> E.g., for <input type="time">, it would be useful to have size="5" 
> maxlength="5" (perhaps combined with a CSS setting that sets the font to 
> monospace for consistency) to convey or support a message about expected 
> input format as well as to prevent some input errors.

During the transition period, I agree that it would be convenient to use 
maxlength="" and size="". And so go ahead and do so.

The useful transition period won't be very long. By the time validators 
have caught up with the new rules, it won't be necessary any more. So in 
the spec, I've just gone ahead and specced the end game.

> There considerations also apply to HTML5-supporting browsers if they 
> implement the new input types using text boxes. For example, input 
> type="color" could be implemented that way, with the required checks on 
> the user input but with no color picker.

While this is possible, it's certainly not the intent. I don't think we 
should encourage it.

> Using CSS for the width is less satisfactory, since there is no 
> "(average) width of characters" concept in CSS

The 'ch' unit.

> and there is no CSS counterpart to maxlength, which is a functional 
> rather than presentational attribute.

True, but 'maxlength' is not hugely helpful anyway -- in fact, UAs are 
moving towards not restricting users to the maxlength during editing, only 
using it as a hint during form validation, due to its usability problems. 
That kind of effect can be duplicated in script for legacy UAs easily.

> For the input types mentioned, the meanings of size and and maxlength 
> could be formulated so that user agents shall treat the size attribute 
> as a suggested visible width of a text box used for the value as text, 
> if such a presentation is used, and the maxlength attribute should be 
> ignored, as it is only meant for nonconforming browsers that treat the 
> element as having type="text".

I think allowing an attribute that does nothing is usually a sign of a 
mistake in the conformance rules. We don't want to be wasting authors' 
time, which (post-transition) is what this would be doing.

On Sun, 6 Mar 2011, Mounir Lamouri wrote:
> 
> Though, if you want to have a valid HTML code, the best solution is
> probably not to change the HTML specs to accept those attributes given
> that they will be completely useless if the UA support the given types.
> However, I think the web page should set the attributes in a compat
> check in javascript. Probably the same way you would have to set a few
> event handlers to create the widget you want. That way, you would only
> use these attributes when the UA would actually use them.
> For example, instead of:
> <input type='number' size='4' maxlength='4'>
> You could do:
> <body onload="
>   var i = document.getElementsByTagName('input')[0];
>   if (i.type != 'number') {
>     i.type = 'text';
>     i.maxLength='4'; i.size='4'; i.oninput=/*a event handler*/;
>     [...];
>   }">
>   <input type='number'>
> </body>

This is no more conforming (it's just as invalid). The only difference is 
that a static validator can't catch it.

On Thu, 10 Mar 2011, Mounir Lamouri wrote:
> 
> - <input type='time' size='5'> should be valid and might actually do
> something when the UA supports type='time' ;
> 
> I have no strong opinions against the former issue: I would agree that
> an implementation might follow the specs without a date picker. Such
> implementation could use the size attribute.

Unless such a UA exists, I'd rather not spend too much time worrying about 
how it would work.

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