No answers yet?

Any updates?

Sounds like the copy/paste broke. Here's a copy:

About the:
4.10.9 The select element

The specification states:
"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. <b>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.</b>"

I'd like to change the part:
"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."
to:
"If the multiple attribute is present, and there is no CSS indicating its height, then the size attribute's default value is 4  If the multiple attribute is absent and there is no CSS indicating its height, then the size attribute's default value is 1. else size is undefined and its height will be the one indicated with the CSS.
When min-height and/or max-height and/or height is defined using CSS, the select must have its height defined using the following priorities:
1º Its height must be exactly the amount in height.
2º Its height must not be bigger than max-height.
3º All text must be visible without vertical scrolling.
4º Its height must not be smaller than min-height.
5º The height applied to the select box must be the smallest possible height so that all the options are completely visible(Example: If max-height: 200px and min-height: 50px and all options can be viewed with height 100px, then the height applied must not be bigger than 100px)
" (Don't forget that by indicating a valid size number any height CSS used in the select box is ignored)

I have some reasons for this and I believe that by allowing this to work as I stated would allow site makers to make sites more easily and allow the server side and client side languages to process less information.
The advantages I can see by applying this are:

- if making a dynamic select box without a fixed number of visible options, Webmasters don't need to make code to count the number of options they are placing inside the select box, make limiters and then calculate the number of entries that the select has to have.
-- With this Webmasters may have cleaner code.
-- With this Webmasters may create the CSS and sent it to another file
-- Webmasters don't need to care about the server processing as the browser will do that for them. That also means less time spend trying to create a code to process that information and, as there is no code, there are no bugs for that which also means faster programming for the websites.

- if making a dynamic page using, for instance, javascript which adds and removed options from the select box as needed there's no need to make a function or a block of code to process and recalculate the new size for the select box (remember that the site owner may want to have top and bottom limits that needs calculation)
-- With this javascript (interpretable language) does not need to process this. So this means faster scripts.
-- No need to make code to execute this means it's less likely to make code with bugs also means javascript code is created faster.

- There are websites with user system that allow users to create their own CSS overrides to the main site CSS.
-- With this people could create their own CSS specifying how many options they want to be available for them to see when they are using the selectboxes. The other way this kind of personalization would be impossible with this simplicity. If the site owner wants them personalizable, there would need to have options for each one of the select boxes.

- There is one effect that some webmasters (like myself) like to apply to selectboxes which is to make its height slightly bigger than the fixed size so that when the last option visible in the selectbox is selected the select box changes its scroll in a way that the option immediately after becomes visible. With this standard for HTML5 this effect is impossible to accomplish without some fair amount of javascript.


... And there are the usual negative sides:

- Browser makers will have to create the code to test and operate these changes.
-- Not exactly a problem, though. This is one thing easy to apply and, as browsers use compiled programs they should be able to process this information without the user noticing the difference.


As you may notice, all I'm writing has work around (with exceptions) using more user side scripting or server side scripting but by applying then it would make the job really easier for users and webmasters.

source: https://www.w3.org/Bugs/Public/show_bug.cgi?id=12531