GUI widgets look different on different platforms. Mozilla's HTML form controls look the same on all platforms. Therefore, Mozilla's form controls look different from native controls on most platforms. Having to learn to recognize two different appearances for the same GUI control makes life unnecessarily difficult for the user. Therefore, the fact that Mozilla's HTML form controls look the same on all platforms is a bug. This bug will eventually be (mostly) fixed by XBL form controls. XBL form controls won't be finished any time soon. In fact, probably not before Mozilla's first major release. And even when they are finished, there will still be things which should be platform-specific but which XBL form controls won't do (like the appearance of nested <fieldset>s, for example). So, we need a way of making the form controls look right on each platform. I suggest that /layout/html/document/src/forms.css import a forms-platform.css, where the contents of forms-platform.css is platform-specific. Then various changes can be made to make the widgets look nicer on each platform, particularly on Mac OS where (in comparison with native widgets) the current HTML form controls look extremely ugly.

I agree. I threw this idea out on the news group last fall and no one seemed to care. Sometime in the somewhat new future we will be moving over to XBL based form controls, so it would probably be best to do it then.

Rod, as I said in the original report, this is mainly necessary because we *don't* have XBL form controls yet. Once we do, there won't be nearly so much need for it. XBL form controls probably won't be finished by the next major release of Mozilla, but for that release to go ahead with the HTML form controls looking as they do now would be embarrassing. All that would be required to fix this bug is for forms.css to @import an empty forms-platform.css file, where forms-platform.css is copied from a different file when built on each platform. Once that was done (how long would it take? twenty minutes?) I would gladly contribute the Mac version of forms-platform.css myself.

mpt: Please do contribute it, frankly (as the author of the last major rewrite of the current widget set look!) I don't see much that can be improved. If you do find ways, then we might be able to use them on all platforms (since we don't even attempt to copy any particular platform except maybe Windows' drop-down).

I'm not going to contribute it if it's not going to be used. But obvious improvements on Mac OS would be things like this (this is a rough draft which probably contains some errors): select, input[type="checkbox"], input[type="radiobutton"] { background: ThreeDFace; border: 1px outset ThreeDFace; /* this applies to all platforms except Windows -- only Windows is stupid enough to make its popup menus look like text fields, GTK etc don't */ } input[type="submit"], input[type="reset"] { -moz-corner-radius: 2px; } input[type="submit"], input[type="reset"], input[type="radiobutton"], input[type="checkbox"], input[type="select"] { outline: 1px solid black; /* as long as outline follows -moz-border-radius */ } input[type="submit"]:disabled, input[type="reset"]:disabled, input[type="radiobutton"]:disabled, input[type="checkbox"]:disabled, input[type="select"]:disabled, input[type="button"]:disabled, button:disabled { outline: 1px solid #999; border-style: none; } input[type="submit"]:focus, input[type="reset"]:focus, input[type="select"]:focus, input[type="button"]:focus, button:focus, input[type="text"]:focus, textarea:focus { outline: 2px solid -moz-variation; /* unfortunately we can't have more than one outline at once :-( */ } input[type="radiobutton"]:focus, input[type="checkbox"]:focus { outline: 1px dotted -moz-variation; }

QA Contact Update

Can we drag this back from future, and do the build work necessary to get it in? I'm happy to do Mac work.

If this will finally lead to smaller borders in text widgets, than please do. ;) I still don't know what "plattform specific" does mean on systems which are themable and have no real "standardlook".

On monday (4/16) I'll take a look at the build isssues for Win and Linux if no one has gotten to them yet.

what is the status of this bug?

I'd like to get something done now for OS/2. Our form elements look horrible because of the XP forms.css

For the record, what we want to do on OS/2 is remove the following lines: font: field; font: list; font: list; font: button; I'm not sure that mpt's idea applies here, since the OS/2 version is actually removing stuff that is in the default forms.css. What we would essentially have to do is that anytime a platform wanted to change a default, we would have to move that default from forms.css into each platforms form-platform.css and then change it for the one platform that wants it.

Comment on attachment 79623 [details] [diff] [review] Makefile change to give OS/2 its own forms.css r=cls

Removing those 'font' lines seems quite odd. Are there other 'font' declarations that apply to the controls, or does this mean you'll be inheriting the font from surrounding content into the form control, which seems really wrong? Wouldn't it be better to fix nsDeviceContextOS2.cpp, function GetSysFontInfo, to return different fonts? (And while you're there, GetSysColorInfo can be removed -- I missed that in my patch that moved the color stuff completely to the LookAndFeel object.)

> Are there other 'font' declarations that apply to the controls, or > does this mean you'll be inheriting the font from surrounding content > into the form control, which seems really wrong? This is exactly what I want. I can give two examples. 1. I am on a Japanese page with Japanese buttons. I don't want to use my operating system button font for these buttons. I'm not on a Japanese machine and my operating system font can't display Japanese. I should be using the font that the page specifies. 2. I am on an operating system that uses bitmap fonts for entry fields. This webpage has specified a 6 pixel high entryfield (www.microsoft.com) If I use the operating system font, it can't be scaled down to fit in the entryfield. 4.x was much smarter about most of this. It only used the system fonts on Latin-1 pages. Mozilla uses them for all pages. This works great on systems that can query whether or not a font can display a given glyph, but OS/2 can't do that. > Wouldn't it be better to fix nsDeviceContextOS2.cpp, function > GetSysFontInfo, to return different fonts? GetSysFontInfo does not distinguish between content fonts and chrome fonts, so if I change that, it will change the entire OS/2 UI. Changing forms.css is the only way I can just change the content fonts. > GetSysColorInfo can be removed I'll open a bug for this.

Comment on attachment 79623 [details] [diff] [review] Makefile change to give OS/2 its own forms.css a=dbaron, although I have no idea how the OS/2 port is even remotely close to compliant with CSS2's rules on font selection given what you said.

I experimented with mpt's idea of including a forms-platform.css but could never get it working. In the end, I checked in an OS/2 specific forms.css on the branch and trunk to work around these problems.

adding fixed1.0.0 keyword (branch resolution). This bug has comments saying it was fixed on the 1.0 branch and a bonsai checkin comment that agrees. To verify the bug has been fixed on the 1.0 branch please replace the fixed1.0.0 keyword with verified1.0.0.

I got the @import working. That catch is that it has to be the FIRST command in the CSS file. So this is the better solution and it works great and will help mpt on Mac as well. The only issue is if we should just not have a default platform-forms.css and take the error on startup or create a blank one.

Anyone interested in this? especially given that XBL doesn't appear to be happening anytime soon?

Yes please.

OK, I think I have the right way to do this that minimizes change to other platforms. Basically, I include forms.css from platform-forms.css. Then in nsChromeRegistry, if we are OS/2, I default to platform-forms.css instead of forms.css The reason I did this as an #ifdef was to avoid a startup hit of actually checking for the existence of the file and then using it. What do people think of this solution?

Comment on attachment 95291 [details] [diff] [review] An even better fix r=cls on the makefile change.

Comment on attachment 95291 [details] [diff] [review] An even better fix sr=dbaron (although you might prefer "medium serif" or "medium sans-serif" (or "initial", if we implement it for 'font') over "inherit")

I'm marking fixed. We now have the facility for any platform to override forms.css by creating a platform-forms.css, updating the makefile, and then an #ifdef into nsChromeRegistry. All the facilities are there.

verifying per coments