Closed Bug 58317 Opened 24 years ago Closed 23 years ago

Use XBL-ified widgets of current theme for HTML form controls

Categories

(Core :: Layout: Form Controls, enhancement, P3)

Product:
Core
Component:
Layout: Form Controls
Type:
enhancement

Tracking

()

Status:
VERIFIED DUPLICATE of bug 57209
Milestone:
mozilla0.9.9

People

(Reporter: mpt, Assigned: bryner)

References

Details

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.
Assignee: rods → hyatt
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>.
Status: NEW → ASSIGNED
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.
Blocks: 66829
Blocks: 57209
-> Future (well moz 1.1)
Target Milestone: --- → mozilla1.1
QA Contact Update
QA Contact: bsharma → vladimire
Blocks: 74058
*** 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.
Blocks: xforms
No longer blocks: xforms
Target Milestone: mozilla1.1 → mozilla1.0
->bryner
Assignee: hyatt → bryner
Status: ASSIGNED → NEW
*** 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)
Target Milestone: mozilla1.0 → mozilla1.0.1
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0.1 → mozilla0.9.8
Work on XBL form controls is ongoing in the tree, but will not be completed for
0.9.8.  -> 0.9.9.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
This bug isn't really distinct from 57209.


*** This bug has been marked as a duplicate of 57209 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
verifying
Status: RESOLVED → VERIFIED
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.
No longer blocks: 57209
You need to log in before you can comment on or make changes to this bug.