W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > May 2011

[Bug 9670] Allow "size" attribute for input-type "number"

From: <bugzilla@jessica.w3.org>
Date: Wed, 11 May 2011 23:09:51 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QKIXP-0003GT-Vo@jessica.w3.org>

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #7 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-05-11 23:09:51 UTC ---
(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:

Status: Rejected
Change Description: no spec change
Rationale: There doesn't seem to be a compelling reason to support this.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 11 May 2011 23:11:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:49 UTC