List controls have a couple of ugly drawing issues that we'd like to be able to tweak to improve their appearance for Cocoa widgets (and native skins in general). Currently, these tweaks are not possible via forms.css because much of the appearance is hard-coded. Specifically, I'd like to be able to: i) Remove the gap above the top item, and below the bottom item in the list ii) Control the drawing of the dotted focus outline around the focussed option
Moved to "Layout: Form Controls" (I assume "Layout: Floats" was a mistake).
Component: Layout: Floats → Layout: Form Controls
QA Contact: layout.floats → layout.form-controls
Nothing wrong with this in my mind if we don't regress Tp in the process... but I'm not sure where in the C++ those are being done offhand.
Dotted focus outline around focussed <option> element is drawn in nsListControlFrame::PaintFocus(). I'm not sure where the gap comes from.
Ergh. Replacing nsListControlFrame::PaintFocus with CSS would require actually changing what's focused (focus the option, not the select). That's likely to take some doing without breaking the various keyboard nav stuff, etc. :( What sort of control do you need over drawing that border? It may be possible to quick-hack something where we pick up the border style from some random style rule but keep the drawing in C++ for now. As for the gap, I'm guessing it comes from http://lxr.mozilla.org/seamonkey/source/layout/style/forms.css#159 -- if I set padding to 0 on a <select>, the gap disappears.
(In reply to comment #4) > What sort of control do you need over drawing that border? It looks like the Windows dotted focus outline, which doesn't look right on Mac. I'd prefer to hide it altogether, if I could (native list boxes don't separate focus and selection).
The problem then is that there's no good feedback on what will happen if the user presses down or up on the keyboard -- right now the focus outline (which can be present if nothing is selected).... In any case, it should be possible to change that via a mechanism similar to the one that handles the focus outlines we draw inside buttons, I guess.
(In reply to comment #6) > The problem then is that there's no good feedback on what will happen if the > user presses down or up on the keyboard -- right now the focus outline (which > can be present if nothing is selected).... On my Mac at least, when I navigate a multiple select list box (like the CC box on top of this page) with the keyboard, the focussed option is hightlighted (background-colour) with the focus colours dictated by the OS. That is, in addition to the dotted outline.
Try this: data:text/html,<select multiple><option>1<option>2<option>3</select> Click on option 2. Then ctrl-click it to unselect it. Now if you press down, option 3 will be selected. But option 2 no longer has the background color (since it's not selected). Are you saying there is other feedback for the user (other than the dotted outline) indicating that pressing down will select option 3, not option 1 or 2?
(In reply to comment #8) Ah, I think I see you point in this case. In Gecko, without the dotted outline, there is indeed no visual feedback that the select object has any kind of focus. The same happens when you access the object only with the keyboard: the dotted outline is currently the only visual indicator that the select object has any kind of focus. Note that in Safari, after de selecting option 2 in your example, using the arrow keys selects option 1. The problem here is that the dotted outline looks kinda foreign on the Mac. Safari and Onmiweb draw only an outline around the select object, when it has focus, nothing around the option. Deselecting option 2 in your example doesn't take away that focus ring. IE Mac does the same as Safari. And at the OS level, we have the same behaviour. And Opera 8 (didn't load the data url btw) does the same as Gecko (dotted outline on the option). iCab 3.0 has poor keyboard support. One option is to include a focus ring around the select object. That is what I've done in my 'PrettyWidgets' forms.css (available here: http://emps.l-c-n.com/articles/94). I'll attach a screenshot next.
Created attachment 188612 [details] screenshot for comment8 and 9 (widget uses my 'PrettyWidgets' forms.css
You need to log in before you can comment on or make changes to this bug.