<select size> "broken" on smartphones? Options

[DanGoldman]

It seems to me there is a problem how smartphones display the HTML "select" tag when the "size" attribute is used. No matter what "size" is set to, the smartphone browser displays it as one line. I first noticed this problem on a kindle fire (amazon silk). But when I tested on an ipod and galaxy player, with various browsers, I see the same thing.

Here are screenshots of a w3schools example that show the problem I see:

http://www.ehdp.com/out/silk-select-size-fails.png - Fails to display <select size="3"> correctly.

http://www.ehdp.com/out/desktop-select-size-works.jpg - Desktop browser displays <select size="3"> correctly.

Here are the w3schools pages with the <select size="3"> example:

http://www.w3schools.com/tags/att_select_size.asp
http://www.w3schools.com/tags/tryit.asp?fi...tml_select_size

There is nothing special about w3schools here, or the number "3". It is just a convenient example to test <select size> HTML tag.

I understand the need to modify browser behavior in some cases to make the user experience better on smartphone. But I think this case is a big mistake. This is not just a cosmetic difference. This severely damages or makes basically unusable any website designed to use the "size" attribute. For example, try the following (the ones of concern to me) on desktop vs smartphone:

http://www.ehdp.com/vn/ro/txu1/pd1/dgw/en_US/index.htm - <select size="N"> boxes are messed up
http://www.ehdp.com/vn/ro/txu1/pd1/dgw/en_US/ajax.htm - try changing age or "race of woman"

http://www.ehdp.com/vw-ajx/img02-bb1.htm is a desktop screenshot showing a "select size" situation that is totally destroyed when the smartphone browser ignores the "size" attribute.

If I want the select box to be three lines tall, why should the smartphone or other device overrule my choice? Why not let me, the developer, decide? And I don't see the advantage of wiping out "size", I don't see the user benefit. If it was just a cosmetic difference, I would not mind. But it is a functional difference. It makes the select box display and work incorrectly, messes up the interface.

I call it "broken" because it does not work as specified (display several lines). Is that the case, or am I missing something? Is there any kind of work-around for this, to make the select "size" attribute work on smartphone browsers?

Thanks,
Daniel

[Christian J]

I assume all the affected mobile browsers are simply buggy (until recently some of them couldn't handle CSS scrollbars either, completely breaking many pages). FWIW, http://stackoverflow.com/questions/1576008...n-chrome-safari suggests specifying an explicit height with CSS. Alas I'm not able to check if it works in other mobile browsers too.

BTW, seems even desktop Chrome has trouble with SIZE attribute values higher than 1:

CODE

<select size="2">
    <option value="0" selected="selected">Default</option>
    <option value="1">select 1</option>
    <option value="2">select 2</option>
    <option value="3">select 3</option>
    <option value="4">select 4</option>
    <option value="5">select 5</option>
</select>

[pandy]

I'm not sure cell phones are buggy. My HTC displays an overlay with radio buttons when I click the select box. I think that's more easy to use on a small touch screen, so I say they do it this way by choice.

Furthermore...
"Visual user agents are not required to present a SELECT element as a list box; they may use any other mechanism, such as a drop-down menu."

http://www.w3.org/TR/html401/interact/form...def-size-SELECT

[DanGoldman]

Christian J,

Thank you for taking a look and verifying what I saw. I was kind of shocked, needed a reality check from someone else.

I have tested on safari and chrome under ipod, and tested on default browser under galaxy player, and under silk on kindle fire. They all show same behavior (ignores size attribute), so it even makes me think this was a conscious design decision (I think a very bad decision).

As you point out, the desktop chrome also has trouble with SIZE, it displays the wrong count of items. I saw that, but did not want to muddy the waters. At least desktop chrome displays a few items, which is tolerable, does not "break" the interface.

Thank you for the CSS suggestion. I will try that as a workaround, and post back what happens. If I use text-based units for the height, perhaps it might work OK.

Thanks again,
Daniel

[DanGoldman]

Hi pandy,

Thank you for your response.

I was not questioning the behavior when the user clicks. I was questioning the visible display. I know a smartphone needs to make certain behavior changes, or even compromises. But if you look at the screenshots links I posted, I think you will see how the displayed behavior breaks the interface, makes it so ugly / inconvenient to be basically unusable. And I don't see any upside.

I guess it's a matter of opinion how to define "buggy". If someone makes a design decision, and it works as designed, maybe we don't call that a "bug". Since the smartphones universally seem to ignore the SIZE attribute, I suppose it is a design decision. But I would suggest that it's the totally wrong design decision. The SIZE attribute is there for a very good reason, because it is useful and required in certain situations. The design decision to ignore SIZE seems totally wrong. Let the developer decide whether to use SIZE or not, even via DOM using javascript, if needed. Totally disabling SIZE takes away that flexibility.

SIZE - "If a SELECT element is presented as a scrolled list box, this attribute specifies the number of rows in the list that should be visible at the same time. Visual user agents are not required to present a SELECT element as a list box" - That's a very good point you make, something I would have never guessed, that the HTML specification surprisingly makes SIZE something not to be relied upon. Seems crazy. Why have an attribute that is subject to being totally ignored? What is the advantage of breaking SIZE? Let the developer decide. Even if "not required", I would suggest common sense would lead to giving the user expected behavior, not encouraging broken interfaces by totally ignoring SIZE attribute.

Anyway, I know whoever designed the HTML specification or smartphone browsers is not going to listen at this point. They made their ill-considered decisions many years ago. I will try the CSS workaround suggestion and see if that works.

Thanks again,
Daniel

[jimlongo]

Currently both Safari and Chrome are not respecting the select size attribute, or rather If set to "1" they will both display a drop down.
Otherwise they are using the default which is "4". (Add more elements to the select list to see this).

I'll check to see if a bug report has been filed to Safari.

Since those are the widely used mobile browsers that would probably account for what you're seeing.

[jimlongo]

the life of a browser bug . . .

https://bugs.webkit.org/show_bug.cgi?id=28900
http://code.google.com/p/chromium/issues/detail?id=4579

I guess the last comment on the chrome bug list about sums it up . . .

Version 29.0.1547.66 m -still not fixed. it's not a major bug. but it's not expected. Oh well... just use a drop-down instead, much nicer.

Good luck.

[DanGoldman]

Hi jimlongo,

Thanks for the reply. I think the bug reports you cited are a different issue. I am not complaining about chrome desktop browser displaying four items for <select size="2"> instead of two items. The wrong number of items is certainly an irritation, ridiculous not to fix, but it does not totally break the interface. I am complaining about every smartphone browser totally ignoring the SIZE attribute, totally screwing things up. You can look at the screenshots I posted before to see how it takes away basic functionality.

BTW, thanks for posting the threads, I found some of the comments on the chromium thread about the four vs two bug (still exists after four years) a kind of black humor, for the apparent incompetence of the developers and designers, and to apply pretty much to the smartphone browser <select size> problem:

Voice of reason - "Hey, guys, this really is a no-brainer. This is a bad decision that should be reversed. This really is a bug that is being passed off as a decision. The fact that code was written a certain way does not imply intent. Webkit's claim that this "improves usability" is nonsense. The "user" in this case is not the person viewing the screen; it's the person writing the HTML. If the programmer wants a box size 2 or 3, what possible reason could there be to say, no, it must be at least 4, because that will "improve usability"? It makes no sense. Why not just fix this. "

Voice of reason - "Come on now, this is ridiculous. Chrome claims to be HTML-compliant. Load of BS. This needs to get fixed quick."

Totally idiotic reply - "It's not a major bug. but it's not expected. Oh well... just use a drop-down instead, much nicer. Good luck."

Anyway, back to the more severe bug, with <select size> broken on smartphone browser, any suggestions? I am not optimistic, seeing that this appears to be a "design decision", and that it takes so many years to fix the apparently simple bug with four vs two on chrome select.

Thanks,
Daniel

[Christian J]

I have tested on safari and chrome under ipod, and tested on default browser under galaxy player, and under silk on kindle fire.

I think all of those are based on the webkit rendering engine.

On this test page http://www.w3.org/MarkUp/Test/HTML401/curr...17_6-BF-01.html my Opera Mobile and Firefox work properly, but (again) not my webkit-based Android browser...

[Christian J]

Thank you for the CSS suggestion. I will try that as a workaround, and post back what happens. If I use text-based units for the height, perhaps it might work OK.

Is http://stackoverflow.com/questions/1493720...e-renders-blank saying that CSS height do not work, just making the empty box higher? Perhaps the idea of adding a SELECTED attribute on the first OPTION helps webkit browsers display at least something, instead of an empty blank menu. Edit: I see that you already do that on http://www.ehdp.com/vn/ro/txu1/pd1/dgw/en_US/

As a sidenote, maybe a SELECTED default value should be provided anyway for usability reasons, for the same reasons as with radio buttons:

Always offer a default selection for radio button lists. By definition, radio buttons always have exactly one option selected, and you therefore shouldn't display them without a default selection. (Checkboxes, in contrast, often default to having none of the options selected.)
If users might need to refrain from making a selection, you should provide a radio button for this choice, such as one labeled "None." Offering users an explicit, neutral option to click is better than requiring the implicit act of not selecting from the list, especially because doing the latter violates the rule of always having exactly one option chosen.
http://www.nngroup.com/articles/checkboxes-vs-radio-buttons/

You may also consider using checkboxes or radio buttons instead, they might be easier to handle even for desktop users.

This post has been edited by Christian J: Oct 22 2013, 06:37 PM

[DanGoldman]

Christian J,

Thanks a million. That's progress. I downloaded the opera "mini 7" browser to my ipod and tested. <select size="n"> worked perfectly. It displays the multiple items perfectly. Then, when I tap on the select, it pops up a nice interface to change the selection. The w3.org test page ("Three options shall be visible at the same time since "size = 3" is set on the SELECT element") clearly indicates someone there "gets it", despite the silly text in the HTML reference seeming to suggest that SIZE can be ignored. Why create a useful / standard function, and then say the browser (such as webkit) can just ignore it?

http://www.ehdp.com/out/ipod-opera-select-is-perfect.png - opera displays <select size> perfectly on ipod

-------------------------

I tried the CSS workaround. Totally fails, as you suggested (I just saw your post), as you see in the screenshot:

http://www.ehdp.com/out/ipod-safari-css-select-fails.png

The webkit programmers have made it impossible for the select size to work correctly. The select box gets bigger, but not better.

--------------------------

I use SELECTED, as you suggest, but that does not solve the fundamental problem. I agree it's even worse / more embarrassing if the select is totally blank (as in the w3schools example), but SELECTED does not solve the basic problem that webkit ignores SIZE.

----------------------

I use checkboxes and radio buttons when appropriate, know all about them. But <select size> meets a need that checkboxes and radio buttons cannot fill, because you cannot scroll them. That's the whole point. Checkboxes and radio buttons are not easier to use in this case, lead to incredibly messy, cluttered interface. Imagine a scroll list 8 items high with 300 total items vs 300 checkboxes.

Any suggestions what might be done about webkit failure? You've already helped.

Thanks,
Daniel

[Darin McGrew]

Webkit's claim that this "improves usability" is nonsense. The "user" in this case is not the person viewing the screen; it's the person writing the HTML.

No. I am the user of my browser. The people who create web sites are not the users of my browser.

That applies to my desktop/laptop browsers (which are configured to enforce a minimum font size, for example). That applies to my mobile browsers (which I actually wish would behave less like screen browsers, to present a web experience more optimized for the handheld platform).

That's the way the web is designed to work. Despite the efforts of some designers, that's the way the web still works.

</soapbox>

[DanGoldman]

Hi Darin,

Thanks for posting. But I beg to differ with your analysis.

First, a minor point, I did not say [The "user" in this case is not the person viewing the screen; it's the person writing the HTML.] - I was quoting someone else.

Second (my disagreement), in this case the "user" IS the person writing the HTML. The person writing the HTML can choose to use SIZE or not. They can choose to modify the behavior of the SIZE attribute through DOM / JavaScript, but not if SIZE is totally ignored by the browser. I think of HTML as a kind of API (a very simple one, I know it is a markup language) that programmers and designers "use" to create web pages. If the API is broken (as it is in this case), bad things result, interfaces that look terrible and are basically not usable on a smartphone.

I agree that a smartphone browser should behave somewhat different to give a better user experience. Having a minimum font size is quite reasonable. And once the <select> is clicked on, it's great to have a special popup optimized for small screen. But this is not one of those "better user experience" cases, it's a "worse". Unless I am missing something, to ignore the SIZE attribute is just a bad design decision, a real stinker. The benefit of <select size> is obvious. <select size> was very purposefully included. What's the benefit of throwing out <select size>?

That's the way the web is designed to work. Despite the efforts of some designers, that's the way the web still works.

I don't understand your point concerning "the way the web works". Could you clarify?

Any suggestions how to get, whoever might be in the position to do it, to fix webkit so that it recognizes <select size> as any reasonable browser should?

Thanks,
Dan

[jimlongo]

Any suggestions how to get, whoever might be in the position to do it, to fix webkit so that it recognizes <select size> as any reasonable browser should?

File a bug report. You're not going to find anyone here who can fix it for you.

[DanGoldman]

jimlongo,

You're right, of course, I should file a bug report. Could you suggest where? I did some research on webkit and found it kind of confusing, with at least one possible branch of the development. Do you have any suggestions which place(s) to file?

Dan

--------------------

Darin,

Just wanted to emphasize I didn't mean any disrespect by disagreeing some. This group is extremely helpful. You and any other admins are certainly to be thanked. Any suggestions you might have where to file a bug report greatly appreciated. I'm willing to put in the time to explain and document, and see if the developers choose to make the change.

Dan

[pandy]

Dan, I think you miss Darin's point. The author never has the last word about how a webpage should display. Also, I think you missed my link to the w3c.

"Visual user agents are not required to present a SELECT element as a list box; they may use any other mechanism, such as a drop-down menu."

http://www.w3.org/TR/html401/interact/form...def-size-SELECT

[DanGoldman]

Hi pandy,

No, I didn't miss the point of Darin's you cite. Where did I ever suggest I expected to have "the last word about how a webpage should display"? Any decent author accepts a certain variation in display, and obviously more variation with a smartphone display (eg, orientation changes). But I expect a reasonable behavior, I don't expect a browser to totally ignore a standard functionality. To quote my previous full reply to Darin (that you perhaps missed):

I agree that a smartphone browser should behave somewhat different to give a better user experience. Having a minimum font size is quite reasonable. And once the <select> is clicked on, it's great to have a special popup optimized for small screen. But this is not one of those "better user experience" cases, it's a "worse".

---------------------

And no, I did not miss your link to the w3c. Go back to post #5. I fully addressed it. I even thanked you there. You just need to read the previous reply.

And if you go back to post #9, by Christian J, you will see a link to where the w3c has a standard functionality test for correct operation of the SELECT tag, with the wording: "Three options shall be visible at the same time since "size = 3" is set on the SELECT element." That seems to contradict the (to me) very bad notion that a browser can choose to ignore the SIZE attribute (as expressed in the w3c link you resent).

If you could suggest appropriate website(s) to submit a bug report to fix webkit so that it recognizes <select size> on smartphone, as any reasonable browser should, that would be appreciated.

Thanks,
Daniel

PS - Will be some 10 hours before I can check back. I appreciate everyone who has posted.

This post has been edited by DanGoldman: Oct 23 2013, 01:37 AM

[Christian J]

"Visual user agents are not required to present a SELECT element as a list box; they may use any other mechanism, such as a drop-down menu."

http://www.w3.org/TR/html401/interact/form...def-size-SELECT

Of course that implies that this "other mechanism" actually works. A totally blank SELECT element is not a working mechanism, IMHO:

[Christian J]

Imagine a scroll list 8 items high with 300 total items vs 300 checkboxes.

True. OTOH 300 items would be difficult even in a SELECT menu. Here's a page about SELECT menu usability: http://www.nngroup.com/articles/drop-down-...-use-sparingly/ (especially the "Design to avoid" section).

Any suggestions what might be done about webkit failure? You've already helped.

For short lists (say 5 items) maybe you could still use radio buttons? For longer lists maybe you could use a CSS dropdown menu like http://www.htmldog.com/articles/suckerfish/dropdowns/ but with radio buttons instead of links.

Or you might redesign the form. For example, the "Age of Woman" menu might be replaced with a text field where the user just enters the woman's actual age, then the server-side script assigns that value to one of the desired age intervals.

[jimlongo]

If you could suggest appropriate website(s) to submit a bug report to fix webkit so that it recognizes <select size> on smartphone, as any reasonable browser should, that would be appreciated.

I would encourage you to submit (add to) the bug report list at http://www.webkit.org