CSS should really solve this and other issues with styling form controls.

(In reply to comment #1)
> CSS should really solve this and other issues with styling form controls.

I'm not involved in that WG. Is there a process to push things over there that makes sure it doesn't get lost?

It is a known issue. Nobody has taken the time to solve it however.

Note that no matter what browsers should be free to show _fewer_ options than you want, right?  So you won't get "the same" anyway...

(In reply to comment #4)
> Note that no matter what browsers should be free to show _fewer_ options than
> you want, right?  So you won't get "the same" anyway...

Fewer is fine - it's about the size of the space that I want to make available to the drop-down. And it's also a problem that the display mechanism changes from drop-down to list when you use @size.

Hmm.  I'm not sure why you want to set the space available for the dropdown from inside the page.  What's the use case, exactly?

Created attachment 967 [details]
Uncontrollable drop-down

shows how a drop-down's length cannot be controlled by the Web page author.

(In reply to comment #6)
> Hmm.  I'm not sure why you want to set the space available for the dropdown
> from inside the page.  What's the use case, exactly?

For example I have a drop-down box that is overlayed onto the video viewport. There are a few lines of the Web page visible below the video viewport, but it looks really ugly - and is possibly even off the page (see attached screenshot).

Similarly when you do an iframe, the drop-down box may actually overlap into the rest if the Web page and the Web page author has no means to control this.

Yes, but the other option makes it easy to make the dropdown too small (e.g. smaller than one option in the user's font-size for dropdowns), no?  I'd really rather have the dropdown be usable for all users than "pretty" for some users.

(In reply to comment #9)
> Yes, but the other option makes it easy to make the dropdown too small (e.g.
> smaller than one option in the user's font-size for dropdowns), no?  I'd really
> rather have the dropdown be usable for all users than "pretty" for some users.

The @size attribute already exists. It declares how many lines are visible and seems perfect to solve the use case that I have. @size obviously should not be misused in the way that you propose and http://dev.w3.org/html5/markup/select.html seems to say that it has to be positive, so at minimum 1.

However, it also has the side effect to turn the dropdown functionality off and turn it into the list display.

So, my suggestion was to add a means to specify what type of display you want: drop-down or list. That would solve the issue.

Alternatively we could of course add another size specifier, such as @rows which would keep it as a drop-down, but allow specification of the max number of displayed rows. It would have to be a positive integer, too.

So, neither has the problem that you specify.

If specifying height through CSS would be allowed, then indeed there would be the problem that you specify. So, maybe indeed CSS is not the solution?

Well, hold on.  If you plan to use @size for this, how are you planning to make sure that the dropdown size matches the size of the random other stuff behind it, exactly?

(In reply to comment #11)
> Well, hold on.  If you plan to use @size for this, how are you planning to make
> sure that the dropdown size matches the size of the random other stuff behind
> it, exactly?

I either know how big it is from the layout or I calculate it during presentation and set it through JavaScript. It's at least easier than having to re-code a whole drop-down box by hand.

First off, the way that @size works is how things have worked for ages. Every time you see a list on a website, such as the cc-list on this very page, it relies on @size to accomplish this. It sucks, but changing it will break a very large percentage of sites on the web so it unfortunately that isn't an option. So whatever solution we'll come up with here will have to involve some other mechanism.


So, that said, moving on to the actual problem at hand:

Isn't this a quality-of-implementation issue? What you are saying is that in some browsers, having a <select> with a large number of elements results in unusable UI. So you are asking for a mechanism to set the size of the dropdown so that you can take responsibility for keeping it usable.

Rather than adding a mechanism for "Useable UI please!", why not always require browsers to have usable UI? I.e. is there a use case for showing exactly X number of items in the dropdown, or do you simply not want it to grow large enough to become unusable?

(In reply to comment #13)
> First off, the way that @size works is how things have worked for ages. Every
> time you see a list on a website, such as the cc-list on this very page, it
> relies on @size to accomplish this. It sucks, but changing it will break a very
> large percentage of sites on the web so it unfortunately that isn't an option.
> So whatever solution we'll come up with here will have to involve some other
> mechanism.


My proposal is backwards compatible - no existing Website will change the way in which it works.

What is broken about @size is that it does two things:
1. It fixes the number of options that are visible to the user (and puts a scrollbar on so you can reach the rest).
2. It changes the layout from a drop-down to a list.

I am asking to introduce a new attribute, such as @mode which can take on two values: "drop-down" and "list". If that attribute is not provided, the element will continue to work as it does, so this is backwards compatible and will not break any old sites. If the attribute is provided, then the list will either be a "drop-down" with the number of options limited to @size (and a scrollbar if necessary), or it will be a "list" with the number of options limited to @size (and a scrollbar if necessary).



> So, that said, moving on to the actual problem at hand:
> 
> Isn't this a quality-of-implementation issue? What you are saying is that in
> some browsers, having a <select> with a large number of elements results in
> unusable UI. So you are asking for a mechanism to set the size of the dropdown
> so that you can take responsibility for keeping it usable.

That is a secondary issue indeed. I am more worried about the side effect of using @size (namely turning it from a drop-down to a list) than about the incompatible implementations between browsers of how many should be shown by default when @size is not provided. That latter problem is indeed under-specified in the spec and we may want to add a spec for what the default size is. Then we can chase up the browsers to make it compatible.


> Rather than adding a mechanism for "Useable UI please!", why not always require
> browsers to have usable UI? I.e. is there a use case for showing exactly X
> number of items in the dropdown, or do you simply not want it to grow large
> enough to become unusable?


What is exactly the best number of items to show really depends on your user interface layout. But indeed that number should not go out of your window, or worse: out of your current desktop.

> What is exactly the best number of items to show really depends on your user
> interface layout.

How so?

(In reply to comment #15)
> > What is exactly the best number of items to show really depends on your user
> > interface layout.
> 
> How so?

If the <select> element is part of an overlay, e.g. a lightbox or a menu or something similar, it would be expected to stay within the boundaries of that lightbox. The same probably applies for iframes.

At the very least it has to stay visible within the desktop (i.e. not go off the bottom of the screen), or better even visible within the browser window.

(In reply to comment #16)
> (In reply to comment #15)
> > > What is exactly the best number of items to show really depends on your user
> > > interface layout.
> > 
> > How so?
> 
> If the <select> element is part of an overlay, e.g. a lightbox or a menu or
> something similar, it would be expected to stay within the boundaries of that
> lightbox. The same probably applies for iframes.

This is not generally the case in desktop applications. Dropdown boxes get their own widget which often goes outside the main application window.

This is especially true on Mac OSX where dropdown boxes positioning depends on which item is selected.

> At the very least it has to stay visible within the desktop (i.e. not go off
> the bottom of the screen), 

This I agree with. Are there implementations that doesn't do this?

> or better even visible within the browser window.

Again, see above, this is not how desktop applications behave.

(In reply to comment #17)
> (In reply to comment #16)
> > (In reply to comment #15)
> > > > What is exactly the best number of items to show really depends on your user
> > > > interface layout.
> > > 
> > > How so?
> > 
> > If the <select> element is part of an overlay, e.g. a lightbox or a menu or
> > something similar, it would be expected to stay within the boundaries of that
> > lightbox. The same probably applies for iframes.
> 
> This is not generally the case in desktop applications. Dropdown boxes get
> their own widget which often goes outside the main application window.
> 
> This is especially true on Mac OSX where dropdown boxes positioning depends on
> which item is selected.


Agreed, this is not how it works. What I am saying is that as a Web application developer this is what you may want to do because of the layout of your page.

For example, I have an application with a menu overlayed on a video and I need the drop-down to stay within the dimensions of the video. Also, I need the drop-down to be the same length in all browsers. The @size attribute seems to be the solution for this, but it also turns off the drop-down functionality, which makes it not usable. Overall, this means I cannot use the select for my very simple drop-down box.



> > At the very least it has to stay visible within the desktop (i.e. not go off
> > the bottom of the screen), 
> 
> This I agree with. Are there implementations that doesn't do this?
> 
> > or better even visible within the browser window.
> 
> Again, see above, this is not how desktop applications behave.

I haven't checked, but these aren't the point - they would be bugs in those applications and not something that we'd need to develop a standard for.

Why do you need the dropdown to stay within the video?

Why do you need it to be the same size in all browsers? What about on platforms that doesn't display a dropdown at all, such as the iPhone?

It seems that we agree that the behavior of keeping the dropdown within the widget/iframe/application it originates from does not match how desktop applications behave. Why do you want web applications to behave differently from desktop apps? People generally aim for the opposite.

Also, if you need for the dropdown to stay within a given box (such as the box occupied by a <video>), then @size isn't enough since you also need to be able to specify if the dropdown opens upwards or downwards.

Also, what do you expect to happen if the browser window is part-way off the screen, such that the box that you expect the dropdown to render in would be partly off screen?

(In reply to comment #19)
> Why do you need the dropdown to stay within the video?

This is how the Web page layout is defined and a design requirement. It looks better that way.

I'm apparently not the only Web developer that needs to do this - it has created many headaches before:
http://stackoverflow.com/questions/570642/height-of-an-html-select-box-dropdown 
http://stackoverflow.com/questions/4457232/limiting-the-displayed-height-of-a-select-drop-down
http://www.webdeveloper.com/forum/showthread.php?t=80761
http://forums.asp.net/t/1226413.aspx
http://dojotoolkit.org/reference-guide/dijit/form/Select.html
(you'll find a gazillion more if you start searching)


> Why do you need it to be the same size in all browsers? What about on platforms
> that doesn't display a dropdown at all, such as the iPhone?


User Interface consistency. That stuff works differently on phones and tablets is well understood and different UI features are used there.
 

> It seems that we agree that the behavior of keeping the dropdown within the
> widget/iframe/application it originates from does not match how desktop
> applications behave.

That is not what I am asking for. I don't want the browsers to work differently. I and an attribute that allows me to define the height of the drop-down.

> Why do you want web applications to behave differently
> from desktop apps? People generally aim for the opposite.

I don't want HTML to work differently to desktop apps. Desktop applications allow me to restrict the length of the drop-down.

For example MFC: http://pheadra.tistory.com/entry/MFC-How-to-set-ComboBox-DropDown-Height

And wbPython also allows it: http://wxpython-users.1045709.n5.nabble.com/wxPython-Vertical-size-of-ComboBox-Adjustable-td2271308.html

No luck with QT, which just truncates the list when you set a height.

So, I wouldn't say that this is an unreasonable request - it is possible in other user interface toolkits.


> Also, if you need for the dropdown to stay within a given box (such as the box
> occupied by a <video>), then @size isn't enough since you also need to be able
> to specify if the dropdown opens upwards or downwards.

That would be an additional parameter that I cannot currently control and it might be nice to add that, too. But it's not what this bug is about.


> Also, what do you expect to happen if the browser window is part-way off the
> screen, such that the box that you expect the dropdown to render in would be
> partly off screen?

I don't want the browser to behave differently when rendering the drop-down (e.g. Firefox continues to render it when half off screen - that's fine). I only want to be able to tell it the maximum length of the drop-down rather than being restricted to whichever choice the browser implementers made.

(In reply to comment #20)
> (In reply to comment #19)
> > Why do you need the dropdown to stay within the video?
> 
> This is how the Web page layout is defined and a design requirement. It looks
> better that way.
> 
> I'm apparently not the only Web developer that needs to do this - it has
> created many headaches before:
> http://stackoverflow.com/questions/570642/height-of-an-html-select-box-dropdown 
> http://stackoverflow.com/questions/4457232/limiting-the-displayed-height-of-a-select-drop-down
> http://www.webdeveloper.com/forum/showthread.php?t=80761

None of these say *why* they want to limit the size.

> http://forums.asp.net/t/1226413.aspx

This is asking for a new feature to work around bugs in the browser (the fact that the dropdown goes outside the screen). It's better that we ask browsers to fix their bugs rather than to add features to work around them.

> http://dojotoolkit.org/reference-guide/dijit/form/Select.html

This doesn't actually select the number of items displayed, but rather limits the size in pixels. That sounds like something better done using CSS.

> > It seems that we agree that the behavior of keeping the dropdown within the
> > widget/iframe/application it originates from does not match how desktop
> > applications behave.
> 
> That is not what I am asking for. I don't want the browsers to work
> differently. I and an attribute that allows me to define the height of the
> drop-down.

I guess I'm confused. What did you mean by "For example, I have an application with a menu overlayed on a video and I need the drop-down to stay within the dimensions of the video"

> > Why do you want web applications to behave differently
> > from desktop apps? People generally aim for the opposite.
> 
> I don't want HTML to work differently to desktop apps. Desktop applications
> allow me to restrict the length of the drop-down.

Sure, but they don't generally limit the size to that of a contained widget, right?

> > Also, if you need for the dropdown to stay within a given box (such as the box
> > occupied by a <video>), then @size isn't enough since you also need to be able
> > to specify if the dropdown opens upwards or downwards.
> 
> That would be an additional parameter that I cannot currently control and it
> might be nice to add that, too. But it's not what this bug is about.

Well, if what this bug is about doesn't solve your use case then it seems like it should simply be WONTFIXed. That is why it's better to file bugs on problems rather than suggested solutions.

> > Also, what do you expect to happen if the browser window is part-way off the
> > screen, such that the box that you expect the dropdown to render in would be
> > partly off screen?
> 
> I don't want the browser to behave differently when rendering the drop-down
> (e.g. Firefox continues to render it when half off screen - that's fine). I
> only want to be able to tell it the maximum length of the drop-down rather than
> being restricted to whichever choice the browser implementers made.

But then it might not stay inside the box that the video is occupying, which seemed to be what you wanted?


I'm still confused as to why you are wanting to do all this. However if we think about it in terms of simply wanting greater control of the style in which the dropdown is displayed, then it seems like CSS is the right solution. Something like a pseudo-element which represents the dropdown and on which you could set things like border, width and height.

Would that solve your use cases?

(In reply to comment #21)
> (In reply to comment #20)
> > (In reply to comment #19)
> >
> > http://dojotoolkit.org/reference-guide/dijit/form/Select.html
> 
> This doesn't actually select the number of items displayed, but rather limits
> the size in pixels. That sounds like something better done using CSS.

Through the size in pixels it also limits the number of items displayed, when it actually snaps to the height of the closest item through limiting that size. That's actually what I'm after.

We can solve it through CSS, but it seems to me that the attribute @size which already exists would already be the right means to solve the problem. A drop-down's height is not generally defined by the height of the number of its entries but by the height it takes up in the flow of the page (without being dropped down). So, defining a height through CSS seems the wrong approach. It's the number of items that are displayed that defines the height of the drop-down.


> > > Why do you want web applications to behave differently
> > > from desktop apps? People generally aim for the opposite.
> > 
> > I don't want HTML to work differently to desktop apps. Desktop applications
> > allow me to restrict the length of the drop-down.
> 
> Sure, but they don't generally limit the size to that of a contained widget,
> right?

No. And again, that's not what I'm after. I want a means to be able to set the height from JavaScript. I can already calculate how much space I have available through other means and if I want to stay within the height of a video element or an iframe or whatever, I have that height. I also have the height of each entry in the drop-down. So, if I can tell the browser how many items I want to display maximum, then I can limit the size to whatever I need.


> > > Also, if you need for the dropdown to stay within a given box (such as the box
> > > occupied by a <video>), then @size isn't enough since you also need to be able
> > > to specify if the dropdown opens upwards or downwards.
> > 
> > That would be an additional parameter that I cannot currently control and it
> > might be nice to add that, too. But it's not what this bug is about.
> 
> Well, if what this bug is about doesn't solve your use case then it seems like
> it should simply be WONTFIXed. That is why it's better to file bugs on problems
> rather than suggested solutions.

I don't actually have a problem with the dropdown going upwards or downwards, which is why this bug is not about that. I've tried to explain the problem that I have as well as I could: namely that I cannot control the height of the drop-down box item list. I'm sorry if I failed. I also pointed to many other people having the same problem, particularly that first stackoverflow article. I don't know how else I can describe the problem. You really have to try to do it to understand the issue.


> 
> > > Also, what do you expect to happen if the browser window is part-way off the
> > > screen, such that the box that you expect the dropdown to render in would be
> > > partly off screen?
> > 
> > I don't want the browser to behave differently when rendering the drop-down
> > (e.g. Firefox continues to render it when half off screen - that's fine). I
> > only want to be able to tell it the maximum length of the drop-down rather than
> > being restricted to whichever choice the browser implementers made.
> 
> But then it might not stay inside the box that the video is occupying, which
> seemed to be what you wanted?

If I tell it to display a maximum number of items, it will, since I have calculated that number of items from the available space.



> I'm still confused as to why you are wanting to do all this. However if we
> think about it in terms of simply wanting greater control of the style in which
> the dropdown is displayed, then it seems like CSS is the right solution.
> Something like a pseudo-element which represents the dropdown and on which you
> could set things like border, width and height.
> 
> Would that solve your use cases?

How would that interact with @size?

> We can solve it through CSS, but it seems to me that the attribute @size which
> already exists would already be the right means to solve the problem.

Actually, as I pointed out in comment 13, we can't use the @size attribute for this since it's used to choose between a dropdown and listbox.

> > > > Why do you want web applications to behave differently
> > > > from desktop apps? People generally aim for the opposite.
> > > 
> > > I don't want HTML to work differently to desktop apps. Desktop 
> > > applications allow me to restrict the length of the drop-down.
> > 
> > Sure, but they don't generally limit the size to that of a contained
> > widget, right?
> 
> No. And again, that's not what I'm after. I want a means to be able to set
> the height from JavaScript.

We're definitely going in circles here :)

You keep saying that you want to limit the number of displayed items. I keep asking why you want to do so.

So far the only answer you've given is that you want to display the dropdown within a given widget (such as a video or an iframe), but when I point out that your proposed solution doesn't cover that usecase you say that that is not the use case you are after.

> I can already calculate how much space I have available
> through other means and if I want to stay within the height of a video element
> or an iframe or whatever, I have that height. I also have the height of each
> entry in the drop-down. So, if I can tell the browser how many items I want to
> display maximum, then I can limit the size to whatever I need.

How are you getting the height of a entry in the drop-down? I guess getComputedStyle on a individual <option> could work, though I'm not sure that that gives the right value in implementations that doesn't use CSS to display the dropdown, such as the one in Safari. I'm also not sure that it'll work while the items aren't displayed, such as when the dropdown is not expanded, since there won't be any frames for it. We could require that to work of course...

If the use-case is to ensure that the dropdown is a given size in pixels (or mm), such that it can "stay within the height of a video element or an iframe or whatever", it seems weird to me though require the page to first calculate the size of each individual item, then divide the desired height by the item height, and finally to set the size expressed in items. Not to mention the pain if <option>s can be differently sized...

Seems much simpler to be able to set the size in pixels (or mm) in the first place.

(In reply to comment #23)
> > I can already calculate how much space I have available
> > through other means and if I want to stay within the height of a video element
> > or an iframe or whatever, I have that height. I also have the height of each
> > entry in the drop-down. So, if I can tell the browser how many items I want to
> > display maximum, then I can limit the size to whatever I need.
> 
> How are you getting the height of a entry in the drop-down? I guess
> getComputedStyle on a individual <option> could work, though I'm not sure that
> that gives the right value in implementations that doesn't use CSS to display
> the dropdown, such as the one in Safari. I'm also not sure that it'll work
> while the items aren't displayed, such as when the dropdown is not expanded,
> since there won't be any frames for it. We could require that to work of
> course...
> 
> If the use-case is to ensure that the dropdown is a given size in pixels (or
> mm), such that it can "stay within the height of a video element or an iframe
> or whatever", it seems weird to me though require the page to first calculate
> the size of each individual item, then divide the desired height by the item
> height, and finally to set the size expressed in items. Not to mention the pain
> if <option>s can be differently sized...
> 
> Seems much simpler to be able to set the size in pixels (or mm) in the first
> place.

OK, fine by me. That does solve the problem.

This is a presentational issue, and thus out of scope for HTML. It should be fixed in CSS or the binding language, once we have one. From HTML's point of view, there's nothing that even guarantees that <select> will _have_ a drop-down. It could be a dialog (as in Lynx) or a slide-up (as in Mobile Safari) or an audio prompt (as in speech-based UAs) or it could be some sort of braille UI or it could be a horizontal sequence of options (as in the Android keyboard's autocomplete selection widget) or...

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: out of scope

(In reply to comment #25)
> This is a presentational issue, and thus out of scope for HTML. It should be
> fixed in CSS or the binding language, once we have one. From HTML's point of
> view, there's nothing that even guarantees that <select> will _have_ a
> drop-down. It could be a dialog (as in Lynx) or a slide-up (as in Mobile
> Safari) or an audio prompt (as in speech-based UAs) or it could be some sort of
> braille UI or it could be a horizontal sequence of options (as in the Android
> keyboard's autocomplete selection widget) or...

When this is moved to that CSS section pls warn. I'm for having something like this working so that what is referred here does as we, webmasters, want.

mass-moved component to LC1