67749 - Make forms.css platform-specific

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, enhancement)

Description

[Matthew T (active 1999-2002)]

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.

Comment 1

[rods (gone)]

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.

Comment 2

[Matthew T (active 1999-2002)]

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.

Comment 3

[Hixie (not reading bugmail)]

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).

Comment 4

[Matthew T (active 1999-2002)]

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;
}

Comment 5

[Vladimir Ermakov]

QA Contact Update

Comment 6

[Simon Fraser [no longer active]]

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

Comment 7

[Daniel Borgmann]

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".

Comment 8

[rods (gone)]

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.

Comment 9

[basic]

what is the status of this bug?

Comment 10

[Mike Kaply [:mkaply]]

Attachment: Makefile change to give OS/2 its own forms.css

I'd like to get something done now for OS/2.

Our form elements look horrible because of the XP forms.css

Comment 11

[Mike Kaply [:mkaply]]

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 12

[hacker formerly known as [e-mail]]

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

r=cls

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.)

Comment 14

[Mike Kaply [:mkaply]]

> 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 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 16

[Mike Kaply [:mkaply]]

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.

Comment 17

[Asa Dotzler [:asa]]

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.

Comment 18

[Mike Kaply [:mkaply]]

Attachment: The right fix

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.

Comment 19

[Mike Kaply [:mkaply]]

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

Comment 20

[Matthew T (active 1999-2002)]

Yes please.

Comment 21

[Mike Kaply [:mkaply]]

Attachment: An even better fix

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 22

[hacker formerly known as [e-mail]]

Comment on attachment 95291 [details] [diff] [review]
An even better fix

r=cls on the makefile change.

Comment 23

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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")

Comment 24

[Mike Kaply [:mkaply]]

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.

Comment 25

[Vladimir Ermakov]

verifying per coments