This has been discussed for ages, but I can't find a bug on it, so here we are. Currently, a Mozilla user has to learn the look and feel of three different widget sets: the XUL widgets in her chosen skin, the clunky HTML form controls, and the native widgets used in HTML listboxes and popup menus and (in the case of Mac OS and Windows) in the file picker dialogs. Even disregarding the poor usability from requiring the user to be fluent in three different widget languages, this situation just looks extremely ugly and unprofessional. The Classic theme brings the number of look-and-feels the user needs to learn from three down (nearly) to two. This RFE is a request to allow the number to be brought from two down to one: all HTML form controls should be rendered in exactly the same manner as the XUL widgets for the user's currently selected theme. Styles applied to the widgets by the author's or user's style sheet should cascade from those specified by the current theme. Implementing this would probably fix about 90 percent of the bugs in the `HTML Form Controls' component.

This is impossible using any technology we currently have. It is only possible if the skin author deliberately writes additional rules for the HTML form controls on the assumption that he/she is mapping them to the XUL widgets.

If this gets implemented, it should (only) be available as an option (preference) IMHO.

David, this is the RFE (which may be a tracker bug, if necessary) *for* the technology required to do this. It seems to have been talked about a lot -- e.g. in bug 47632 you said `I think the eventual right thing to do here is to map the HTML form widgets to the XUL widgets using XBL, thus unifying the widget sets'. And in bug 16082, Ian Hickson said `When widgets go XBL, this [bug] might get solved along with it'. So I filed this bug. Obviously it will require more work to make Mozilla themes more resilient to being stretched and styled, but c'est la vie. Karl: No other Web browser has a `Make HTML form controls look like crap' option. Currently Mozilla does, and you can't turn it off.

> Karl: No other Web browser has a `Make HTML form controls > look like crap' option. > Currently Mozilla does, and you can't turn it off. 1 I don't think the "look like crap" 2 Theme widgets wouldn't be stylable by web pages, which is a disadvantage.

I'll take this for now and post my thoughts.

Ok, here's what we know: (1) Form controls have to work in an embedding environment, i.e., without the "chrome" URLs that enable skin switching technology. (2) We want form controls to be fully customizable using XBL. (3) Given that the tag sets differ between HTML and XUL, the same style rules cannot be used to describe both. This means a skin author has to actively choose to include rules for HTML form controls in a skin. (4) Some users won't want the form controls picking up the skin settings. So here are some thoughts on how we could design things so that this would be possible: (1) We make sure there is a pref that toggles a skin's ability to skin the content area. Users can choose to selectively enable/disable this pref from our preferences UI. (2) In the same way we have a special skin scrollbars sheet, we'll have a special skin form widgets sheet. If the pref is set to allow this to be used, then a skin can supply definitions for the HTML form widgets that will be used. (3) The forms sheet will cascade with some already-chosen default agent sheet. That default sheet will be used in the case where no chrome registry or skin-switching technology exists. So I think this is certainly possible, with the caveat that the skin author will have to choose to skin the form controls and write the rules that ensure the widgets look/behave just like the XUL counterparts. For simpler widgets (e.g., button, checkbox) this will be easy. Could get more challenging for things like <select>.

Where possible, an HTML forms style sheet should be able to cascade from XBL definitions defined in the XUL style sheet for the same skin -- e.g. just reuse the look and feel of XUL <menulist> for HTML <select>, the look and feel of XUL <button class="normal"/> for HTML <input type="submit"/>, the look and feel of XUL <button class="block"/> for HTML <button>, etc. But there will need to be extra rules to map HTML CSS to XBL stuff -- e.g. {tinting,stretching} the bitmap graphics used in a theme like Aqua when the {background color,size} of a widget is changed. In the case of the Classic skins on each platform, it will be necessary to extrapolate what the native widget might have looked like if it was possible to style it -- and different skins may refuse to apply various CSS properties, depending on how flexible they are.

I don't see how you can support anonymous content in HTML controls because websites wouldn't be able to restyle it.

-> Future (well moz 1.1)

QA Contact Update

*** Bug 89006 has been marked as a duplicate of this bug. ***

*** Bug 91818 has been marked as a duplicate of this bug. ***

The target milestone for this is wrong, it should be Mozilla 1.0 or sooner. Mozilla will remain "beta-quality" to Mac users until this bug is fixed. The major reason people buy a Macintosh is for the consistant user experience. If Mozilla doesn't even provide an internally self-consistant human interface (let alone consistant relative to the rest of the system), it will be unacceptable to the majority of Mac users. After using Mozilla 0.9.3 heavily for a while, this is honestly the second most annoying bug (behind missing "page setup" menu which forces me to launch Netscape 4.78 to print landscape). Note that I don't care about the technology used to fix the look and feel of forms, nor do I care how it looks with weird CSS tags, but a 99% solution for the "classic" (MacOS 9) and "Aqua" (MacOS X) skins is necessary to achieve release quality for the vast majority of Mac users.

->bryner

*** Bug 107496 has been marked as a duplicate of this bug. ***

*** Bug 109302 has been marked as a duplicate of this bug. ***

*** Bug 111457 has been marked as a duplicate of this bug. ***

shouldn't XBL form control going into earlier milestone? something within the next two milestones would be nice. bryner/trudelle can you guys evaluate?

*** Bug 47052 has been marked as a duplicate of this bug. ***

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)

Work on XBL form controls is ongoing in the tree, but will not be completed for 0.9.8. -> 0.9.9.

This bug isn't really distinct from 57209. *** This bug has been marked as a duplicate of 57209 ***

verifying

Modern skin controls look extremely ugly on web pages. I hope this feature is removed before XBL form controls are enabled by default.

I agree with Jesse that form controls looks better in the usual look - gray, like the ones in IE.