W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > March 2011

[Bug 12245] @size on <select> drop-downs is not enough to specify the drop-down maxlength on long options lists with scrollbars

From: <bugzilla@jessica.w3.org>
Date: Tue, 22 Mar 2011 05:16:37 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Q1txN-0001fI-UF@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12245

--- Comment #14 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-03-22 05:16:37 UTC ---
(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.

-- 
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 Tuesday, 22 March 2011 05:16:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 March 2011 05:16:46 GMT