- From: <bugzilla@jessica.w3.org>
- Date: Fri, 06 May 2011 11:38:16 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12245 --- Comment #18 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-05-06 11:38:15 UTC --- (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. -- 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 Friday, 6 May 2011 11:38:17 UTC