User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release) Build ID: 20140506152807 Steps to reproduce: Since the last update of Firefox (v29.0.1), I am experiencing incorrect behavior for HTML form fields. This code: <input type="number" size="3" maxlength="8" /> Generates an input box with a length of 8 characters. This does not match HTML standards and even MDN documentation for the input element. This incorrect behavior was not present in earlier releases. Since this incorrect behavior influences user interfaces, this major bug is a potential cause of end users no longer to be able to use certain websites and web applications. I've already found several web forms that were broken in Firefox. How could this ever have ended up in an end user release? Now I have to start clients advising to switch to another browser after I've used Firefox faithfully for ten years myself. Actual results: Displayed input has length of maxlength attribute (size is ignored) Expected results: Displayed input should have length of size attribute

Important: forget what I said about the maxlenth attribute. This is irrelevant. The issue is just about ignoring the size attribute. This does not change the importance. In the meanwhile I also found out that ignoring the size attribute for type=number is part of the HTML5 specification. And several other browsers already contained the same behavior. There probably is a good reason why this was decided, but since it breaks existing websites I don't understand why this was ever introduced.

It does indeed look like the size attribute is ignored for type="number" In the test type="text" still adheres to the size attribute. If this is what is in the spec then https://www.w3.org/Bugs/Public/ is the correct place to file a bug.

(In reply to Sint from comment #1) > Important: forget what I said about the maxlenth attribute. This is > irrelevant. > > The issue is just about ignoring the size attribute. > This does not change the importance. > > > In the meanwhile I also found out that ignoring the size attribute for > type=number is part of the HTML5 specification. And several other browsers > already contained the same behavior. > > There probably is a good reason why this was decided, but since it breaks > existing websites I don't understand why this was ever introduced. If this works the same on several other browsers (I'm going to assume either webkit and blink, or blink and trident/ie), then how did this behaviour break existing websites that weren't broken before? (Note that comment #2 is correct in that this isn't the right place for spec bugs, but it probably makes sense to check previous discussion) Note also that webkit explicitly changed their behaviour to what ours is now: https://bugs.webkit.org/show_bug.cgi?id=60673

I'm not going to discuss the spec. Also I admit that the spec wasn't quite clear to me at this point. At the same time, browser developers are always responsible for their own product. Changing the spec that's been followed for existing websites is always a risk, especially in the way HTML5 was set up (no specific doctype required). I'm very surprised issues like this receive so very little attention, while the way existing (non-HTML5) websites render can change so dramaticly. I understand your position on following the spec and referring to Webkit. The alternative mentioned by commenters on the Webkit ticket you mention involves: "<input type=number> is supposed to size according to the min/max/step attributes so that it will be as wide as necessary to represent the longest allowed number" While testing a bit further, Firefox in my findings does not size according to min/max/step attributes at all. So you are breaking old behavior without implementing the correct new behavior. How do you explain this then? I'm not sure what to do now. I wouldn't prefer using css as a fix for issues. Using min/max/step makes no difference for Firefox at the moment. As this changes my finding from a spec bug back into a Firefox issue, should I fire a new bug ticket, or will this one including the relevant infos be re-opened?

(In reply to Sint from comment #4) > I'm not going to discuss the spec. Also I admit that the spec wasn't quite > clear to me at this point. > > At the same time, browser developers are always responsible for their own > product. Changing the spec that's been followed for existing websites is > always a risk, especially in the way HTML5 was set up (no specific doctype > required). I'm very surprised issues like this receive so very little > attention, while the way existing (non-HTML5) websites render can change so > dramaticly. I think you're biased as to the importance of this particular problem. The combined scope of HTML5 and CSS3 is very big. You ran into this particular problem. Other people run into other problems. We'd all like our particular issues to be "blocking" but realistically, most people style most of their webpages with CSS anyway. Certainly I've seen e.g. bug 988870 garner more dupes than this issue. Equally, because of scope, it's almost impossible to have tests for every eventuality, which means shipping a bug-free layout engine is essentially impossible (certainly it's never happened in practice). > The alternative mentioned by commenters on the Webkit ticket you mention > involves: > "<input type=number> is supposed to size according to the min/max/step > attributes so that it will be as wide as necessary to represent the longest > allowed number" > > While testing a bit further, Firefox in my findings does not size according > to min/max/step attributes at all. > > So you are breaking old behavior without implementing the correct new > behavior. > How do you explain this then? > > I'm not sure what to do now. I wouldn't prefer using css as a fix for > issues. Using min/max/step makes no difference for Firefox at the moment. > > As this changes my finding from a spec bug back into a Firefox issue, should > I fire a new bug ticket, or will this one including the relevant infos be > re-opened? None of the above. This is being tracked in bug 771493 already, so there's no need for a separate bug being on file. :-)

The cause is indeed not very common. But for instance many web application frameworks (like CakePHP) have been using these kinds of elements, attributes and values for some time now, so I won't be the only one in the universe facing issues like this. Adding superfluous CSS, like a width in pixels, makes no sense and could even break things in the future. Good to know there already was a ticket about this. Hoping it will be resolved in the very near future. Reports like mine won't harm I think...