Per the HTML5 spec, a select element without a required attribute should have its size attribute default to 1. (http://www.whatwg.org/specs/web-apps/current-work/complete.html#the-select-element) `The size attribute gives the number of options to show to the user. The size attribute, if specified, must have a value that is a valid non-negative integer greater than zero. If the multiple attribute is present, then the size attribute's default value is 4. If the multiple attribute is absent, then the size attribute's default value is 1.` Current builds default to 0. Code used in test case (http://jsbin.com/aqana/2/edit): var select = document.createElement('select'); function testSize(el) { return el.size == 1; } testSize(select); // false
What do other browsers do? Firefox seems to match WebKit, but I didn't test IE.
Hmm, it appears that Webkit, Firefox 4 and IE8 all do the same thing, that is set @size to 0. I thought Gecko was doing something else last night, but I was mistaken.
Would you be willing to report a bug against HTML5? You can file it at <http://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG>, or simply e-mail the working group.
I've written the working group about this: http://lists.w3.org/Archives/Public/public-html/2010Aug/0126.html
(In reply to comment #4) Reading the message on the working group, it looks better to change the default size to 1 or 4. > http://lists.w3.org/Archives/Public/public-html/2010Aug/0126.html I'll be starting to work on this since it blocks the bug 50380.
Created attachment 75366 [details] Patch
FYI, we did this change for Gecko and some sites broke [1]. So, we've reverted to returning 0. By the way, the specs require to return 1 as a default value even if multiple is set (but I agree this non-sense). There is a bug filed for that [2]. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=603141 [2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=11162
Comment on attachment 75366 [details] Patch So I guess that we don't want to do this.
(In reply to comment #8) > (From update of attachment 75366 [details]) > So I guess that we don't want to do this. I agree. We shouldn't change this for now.
Ok, let's close it.