This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The text below is copied from http://bugzilla.validator.nu/show_bug.cgi?id=741 *** Thanks. I now agree that "validator.nu behavior for this case conforms to the current spec". I had not expected such a backwards compatibility problem. I think that this is a problem in the specification because (as far as I know) legacy browsers do not know what to do with min and max attributes. So I either use input-type text with the size attribute which is supported by legacy browsers and HTML5 or I use inputtype number which is supported by HTML5 but where the size can not be specified. This makes it difficult to migrate from old-HTML to HTML5. Maybe this can be forwarded to those who care about this aspect of the specification? I agree with what someone else wrote on that problem: "A) What happens when your type=number has no min or max but you know how many digits it should fit? B) What happened to backwards compatibility? HTML5 inputs were supposed to be backwards compatible. type=number inputs fall back to type=text inputs when the browser has not implemented number inputs yet. text input size has always been controlled using size= (and css of course) and min/max/step values will have no effect on browsers that haven't implemented number. So if type=number is supposed to fallback to type=text why is it that including a size= attribute so that the text fallback doesn't get insanely long makes your html5 document invalid? Shouldn't size= be listed as "do not apply" rather than "must not be specified, ..."?" http://blog.danielfriesen.name/2010/04/20/html5-number-input-implementation-flops/
We have a specific case where this is being problematic. We have an exam marking tool, which presents a large grid of number fields. Specifying maxlength/size causes Opera to render the field as one character wide (which is reasonable, given it's out of spec). Not doing so causes everything else to render the field as around 12 characters wide. Either way, it's essentially useless in at least one browser. I feel the specification should instead indicate that size/maxlength should be ignored on number fields, not explicitly disallowed.
Another point is that it may be that the maximum value is far higher than the range normally used (or same for precision). For example, if I have a number that's normally 1-100, but may be 1-10000 with up to 3 decimal places of precision, I may want to have the field wide enough for 3 digits, not the full 9 digits that the number could need. Also, field size can be used to indicate importance (a larger field more readily attracts user attention), meaning that I may want to make it significantly larger than the biggest value it can hold.
Hello, I am also hit by this bug. More generally, I believe that @size and @maxlength should be allowed on input of @type {Date and Time, Date, Month, Week, Time, Local Date and Time, Number, Range, Color, File Upload}, in addition to the ones already allowed {Text, Search, URL, Telephone, E-mail, Password}. See http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#input-type-attr-summary A simple approach would be that @size and @maxlength could be allowed, while other values would take precedence when the @type values are properly implemented in a given browser. But I believe a better approach would be to use all of them (@size, @maxlength, @max). This seems to be Opera's approach. In the example of @type=number, @maxlength is needed to put a boundary on the number of decimals (e.g. "0.001" is ok but not "0.0001" when @maxlength=5). If the most typical values are small (e.g. 3 digits), but sometimes may be large, then @size is useful to define how many digits are visible at a time. Best regards, Alexandre http://alexandre.alapetite.fr
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: Wouldn't you always want all the digits visible? Why can't you size it in CSS? I don't understand the use case for maxlength="". Surely the other attributes already convey all the useful information?
The "size" attribute however is needed as a rendering hint, and cannot always be inferred correctly. It may need to be shorter than the maximum possible value, for example if rendering a data table where horizontal space is at a premium (this is the case that I'm looking at). It might also want to be longer than the maximum possible value, for example to match width of other fields in the same form, for appearance purposes. I suppose theoretically it could be sized using CSS, but surely if that's the correct response there's no need for the "size" attribute anywhere? It would seem a lot more straight forward to remove the explicit disallowing of "size" on number fields. Firefox & Chrome I believe both implement this anyway (Opera does mis-render such fields, though). With respect to the "maxlength" attribute, I think it is okay to infer from other attributes. In theory it might be important if the data is stored server-side to a certain number of significant digits, rather than by min/max & scale, but that seems an odd case.
On "maxlength" again - this is very useful for backwards compatibility. Without it, browsers that do not understand HTML 5 have no indication of maximum valid length for entered values. I would suggest that instead of being disallowed, the specification indicates it should be ignored by browsers that understand "min", "max" & "step" attributes.
(In reply to comment #5) > The "size" attribute however is needed as a rendering hint, and cannot always > be inferred correctly. It may need to be shorter than the maximum possible > value, for example if rendering a data table where horizontal space is at a > premium (this is the case that I'm looking at). If you're just worrying about the size from a presentation point of view, just use CSS to set the width. That will be far more reliably than size="". > It might also want to be longer > than the maximum possible value, for example to match width of other fields in > the same form, for appearance purposes. Again, that seems like a job for CSS. > I suppose theoretically it could be sized using CSS, but surely if that's the > correct response there's no need for the "size" attribute anywhere? It's useful on <input type=text> to give the expected width of the input without actually restricting the input length to that size. That doesn't apply to type=number since the data type is known. > Firefox & Chrome I believe both implement this anyway (Opera > does mis-render such fields, though). If the browsers already do it, that's a possible reason to change the spec. Firefox doesn't implement type=number, though, so at most that's one browser, and it's still new. > On "maxlength" again - this is very useful for backwards compatibility. Without > it, browsers that do not understand HTML 5 have no indication of maximum valid > length for entered values. I would suggest that instead of being disallowed, > the specification indicates it should be ignored by browsers that understand > "min", "max" & "step" attributes. That's plausible, I guess, though a bit confusing, as it would mean we are allowing an attribute that does nothing. Usually that's a sign of a mistake. If you think this should be considered further, please file a separate bug for this issue. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: There doesn't seem to be a compelling reason to support this.
mass-moved component to LC1