Closed Bug 28899 Opened 25 years ago Closed 23 years ago

We need a CSS-compliant Font prefs panel

Categories

(SeaMonkey :: Preferences, defect, P3)

Product:
SeaMonkey
Component:
Preferences
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: pierre, Assigned: gerv)

References

(Blocks 3 open bugs,
URL
)

Details

(Keywords: helpwanted, meta)

Attachments

(13 files)

hacked version of pref-fonts.xul
6.26 KB, text/xul
Details
Here's how it looked a couple of days ago (sorry, I've lost my more recent screenshot)
69.13 KB, image/gif
Details
Let's try that one again
19.87 KB, image/gif
Details
Um ... Third time lucky?
19.85 KB, image/gif
Details
New fonts prefs panel
19.25 KB, image/gif
Details
New "calibrate display resolution" dialog
5.00 KB, image/gif
Details
Low-calorie reduced-fat calibration dialog
4.07 KB, image/gif
Details
Patch v1 - new Fonts panel, calibration dialog
23.23 KB, patch
Details | Diff | Splinter Review
calibrate-screen.xul
2.41 KB, text/plain
Details
Patch v.2
23.38 KB, patch
Details | Diff | Splinter Review
pref-calibrate-screen.xul
2.39 KB, patch
Details | Diff | Splinter Review
New fonts prefs panel - final look
18.25 KB, image/gif
Details
new calibration dialog - final look
3.59 KB, image/gif
Details 
The current Font prefs panel allows to select the serif and monospace fonts. We 
need to add the other CSS1 fonts:
  - sans-serif
  - cursive
  - fantasy

For an example of font prefs panel, please visit the page of our good friend Todd 
Farhner at http://style.verso.com/cssui/. I don't know whether Todd as 
successfully lobbied Microsoft to have his proposal implemented, but I remember 
having seen a screen snapshot of MacIE5 which resembles what you can see on this 
page.
Blocks: 28883
i've commented these out (they are in right now)
because it will take about 1 minute on unix to
load.
Rod is about to checkin some code that greatly improves the performance in drop-
down lists. It may make Unix usable.

Also when you re-enable these prefs, I'd like to change the default fonts on the 
Mac and use the same ones as on Windows: Times New Roman, Arial, Courier New, 
Comic Sans MS. I think that these fonts are provided with the OSes we are 
compatible with (8.5+).

I think these fonts are not provided by Apple they are provided by Microsoft on 
the Mac when you install IE for Mac. The appropriate Mac counter parts are Times, 
Helvetica and Courier. 

Well, the default should be *either* `Times' or `Times Roman' or `Times New 
Roman' or `CG Times', etc, depending on which exists. Mozilla can check for 
multiple names, right? I don't see why the list of defaults should be
platform-specific.

Matt, the font prefs panel can also take a long time to display on MacOS with 
many fonts installed. So when the panel is first opened, you may want to:
* draw the font popup menus as disabled initially, with one item -- `Loading
  fonts ...'
* load the font list, and populate the popup menus (leaving the menu disabled,
  and leaving `Loading fonts ...' as the selected item as the other items are
  added)
* delete the `Loading fonts ...' items
* set the menu selections to the correct values from prefs
* enable the menus.

If this sounds like a good idea to you, I'll go file a separate bug for it.

Right. The solution should be to have these 2 fonts in the default prefs (in that 
order):
user_pref("font.name.serif.x-western", "Times");
user_pref("font.name.serif.x-western", "Times New Roman");

Problem: I just checked and Mozilla gets confused if you set in the prefs a font 
that doesn't exist. When you open the pref panel, it defaults to the first font 
in the list instead of the last known good font.

I opened bug 29351 against "Preferences:Backend" for that.
Depends on: 29351
Status: NEW → ASSIGNED
Target Milestone: M15
Move to M16 for now ...
Target Milestone: M15 → M16

*** This bug has been marked as a duplicate of 31413 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
erm, why was this dup'd of a later, more specific bug? (i kinda view this as a
meta bug anyhow, so reopening and adding kw.)
Status: RESOLVED → REOPENED
Keywords: meta
Resolution: DUPLICATE → ---
[C, thx for the clarification (in private email).] re-dupping.

*** This bug has been marked as a duplicate of 31413 ***
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
Claudius: I think that everybody else on the CC list deserves to hear that 

clarification too. Why did you close this meta bug as dup of a more specific one? 

Also, the dependency on 29351 should be moved to 31413.


Reopening, for the same reasons as S.E.V. Liberman mentioned.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
If you, Pierre, don't think these are dupes, then they aren't and that can be the end of it.

I was part of a team that was triaging this bug along w/ hundreds of others and these two bugs stood out as dupes because they 
were both written by the same person and had the same exact original descriptions. We just thought you forgot you wrote the first 
one :-). The 'meta' issue did not come up until later, and if that's the case then shouldn't the other bug be listed as a 
dependency of this bug? If they aren't dupes then they certainly must have a dependency relationship.

You're right... Marking dependency on bug 31413
Depends on: 31413
I consider this nowhere near m16 considering the other important stuff that needs 
to get in. Unless this is ridicolously easy to build I would suggest latering 
this bug...

No way! The 5 generic font families are at the base of CSS2 Fonts specification. 
M16 is the feature-complete release. We had been talking about this font prefs 
panel for quit a while already, even before this bug was opened. Escalate the 
problem if you can't do it for M16, or request permission to implement it after 
M16, but please don't later it.

*** Bug 31413 has been marked as a duplicate of this bug. ***
German,

You need to make the call as to what we should do here.  If this means a change
in the Font prefs panel (i.e. implementing all or part of CSS-compliance), then
re-assign the bug to Erik van der Poel <erik@netscape.com> because he has
volunteered to do the implemnetation work (which he says should be easy).  Thanks.
Target Milestone: M16 → ---
German,

You need to make the call as to what we should do here.  If this means a change
in the Font prefs panel (i.e. implementing all or part of CSS-compliance), then
re-assign the bug to Erik van der Poel <erik@netscape.com> because he has
volunteered to do the implemnetation work (which he says should be easy). 
Thanks.
Assignee: matt → german
Status: REOPENED → NEW
Nominating for nsbeta3. Also marking 4xp, because the font prefs panel in IE5 for 
Mac OS has all the CSS font families listed.

Suggested UI at
<http://critique.net.nz/project/mozilla/prefs/tardis/#std-display-fonts>.
Keywords: 4xp, nsbeta3
Marking nsbeta2 because it is a feature. If it doesn't make it for beta2, I'm 
afraid it will be doomed for beta3.

PDT team, please make it an exception feature. I know it is a bit late, I wish we 
could have taken care of it sooner but the UI team has not been very cooperative 
on that problem.
Keywords: nsbeta3 → nsbeta2
I saw in another bug report that the beta2 Exception Feature deadline had passed. 
Is there anything special to do to make sure that this gets fixed for beta3?

Putting on [nsbeta2-] radar. Not critical to beta2.
Whiteboard: [nsbeta2-]
Keywords: nsbeta3
Matt's spec looks great.
Assiging to Erik who's offer for help on this is much appreciated.
clearing out nsbeta2
Assignee: german → erik
Keywords: nsbeta2
Target Milestone: --- → M18
Pierre, would you like to take this one? Erik has 15 nsbeta3 bugs and will only
have two weeks to do anything with them. It seems like you know what needs
doing here, and in a worst case scenario we can really just Future this, right?
Whiteboard: [nsbeta2-] → [nsbeta2-] (->pierre?)
Ok, I'll take it back. Maybe I'll find some time to do some UI for a change.
Marking 'helpwanted' still.
Assignee: erik → pierre
Keywords: helpwanted
Whiteboard: [nsbeta2-] (->pierre?) → [nsbeta2-]
Status: NEW → ASSIGNED
Denying for nsbeta3: not critical for release and there a loads of other big 
problems to work on. If we miraculously complete our current beta3+ bugs, we can 
pull this one up _maybe_.
Whiteboard: [nsbeta2-] → [nsbeta2-][sbeta3-]
Whiteboard: [nsbeta2-][sbeta3-] → [nsbeta2-][nsbeta3-]
Adding nsbeta2 keyword to bugs with nsbeta2 triage value in status field so the 
queries don't get screwed up
Keywords: nsbeta2
Feeling bored, I decided to have a go at hacking some XUL, and what I've just
attached is the result: a version of pref-fonts.xul which makes the fonts panel
match my spec.

It needs:
* transferral of hard-coded value and accesskey attributes to the proper files
* styling work to get the widgets the right width
* JavaScript work to insert the typefaces and sizes in the appropriate places,
  do the `default choices' trick, and set the appropriate preferences
* commenting out stuff which isn't implemented yet (like minimum font size).

Finishing this off would also fix bug 33641.

I have opened a bug on setting a minimum font size at install and a general 
pref for this: http://bugzilla.mozilla.org/show_bug.cgi?id=56440.
Block moved M18 bugs to mozilla0.9.1
Target Milestone: M18 → mozilla0.9.1
Adding mozilla 0.9.1 keyword.
Keywords: mozilla0.9.1
I'm afraid it will never get done...  I think we are in UI freeze already for 
6.5.  Besides, I'm leaving for a couple of months, Erik is leaving for good, and 
I don't know of any candidate to implement this for 1.0.

Result: Future.
Target Milestone: mozilla0.9.1 → Future
OK, here's a patch.
- Enable cursive and fantasy selection widgets
- reverse the meaning of the dynamic fonts pref as per MPT's spec

I've made it on Linux, and performance is acceptable. I set both boxes to random
fonts and went to a page claiming to have text styled as cursive and fantasy,
and it came out different. So I assume the back end is working.

Problems:
- For some reason the accesskey on the dynamic fonts checkbox doesn't want to
show
- The default values in the cursive and fantasy selection widgets is "blank" -
the panel needs to choose sensible fonts for these on each platform so I can
update the platform-specific prefs files.
- The fonts dialog has a very weird bug which removes some of the bits on first
viewing only on Classic. There may be a bug on this...

Gerv
OK, default font selections is a different bug (bug 61883). So my patch is ready
for initial review. I might even attach it this time :-)

Gerv
I had a chat about this with mpt on IRC and we ended up making some more
changes. He's currently reviewing the new UI, and _then_ I'll attach the patch.
Sorry for the delay ;-)

Gerv
screenshot?
Oh, I give up. Gerv can attach a more recent screenshot. Anyway, the new design 
also fixes bug 33641.
Assignee: pierre → gervase.markham
Blocks: 33641
Status: ASSIGNED → NEW
Attached image New fonts prefs panel — 

    
    

    
  
These aren't quite the final form - the calibrate dialog is going to lose the
vertical bar and so become much more simple, and there are a few other cosmetic
changes on the Fonts panel, but it's nearly there.

The calibration dialog works as follows - if you select "Other" from the
pulldown (which is 96 | 72 | <sep> | Other...), you get the dialog. When you
measure, it calcs a new value and inserts it into the pulldown, then selects it.
Very slick ;-)

Patches coming soon.

Gerv 

    
  
Keywords: nsbeta2, 
          
            nsbeta3
Whiteboard: [nsbeta2-][nsbeta3-]
Target Milestone: Future → ---
Blocks: 5599

    
    

    
  
Here - try this for size. Looking for r=, or comments. Who should we be asking
for review, now pierre has gone?

Gerv

    
    

    
  
Gerv, while I prefer the checkbox (in constrast to radios) "Allow documents to
use other fonts", the old wording was IMO clearer. Maybe "Allow page authors to
override there fonts"?

Overall: The new layout looks so much cleaner and is more correct, that I wonder
why it hasn't always been this way :).

    
    

    
  
mpt's words, not mine :-)

"Allow page authors to choose other fonts" ?

Gerv

    
    

    
  
does the back end allow different default sizes for the various proportinal
fonts?  If so, we should allow the user to do so, imo.

    
    

    
  
No :-( Otherwise yes, we would. mpt is quite annoyed about this.

Gerv

    
    

    
  

      
      
      
      

        Attached file
          
        calibrate-screen.xul
        — 
      

    


  

    
    

    
  
Gervase put this diagram in bug 61833:

    Fonts ::::::::::::::::::::::::::::::::::::::
                                                
    +-Fon_ts for: [default choices         :^]-+
    | :/: _Use dflt. choices for this encoding |
    | _Proportional: [Georgia      :^][  14:^] |
    |    _Monospace: [Courier New  :^][  12:^] |
    |        _Serif: [Times New Rom:^][  14:^] |
    |   Sa_ns-serif: [Trebuchet    :^][  12:^] |
    |      _Cursive: [Zapf Chancery:^][  16:^] |
    |      _Fantasy: [Desdemona    :^][  16:^] |
    | [ ] Minimum font si_ze:         :   8:^: |
    +------------------------------------------+
    [/] Allow documents to use _other fonts     
    For plain te_xt, use: [Monospace         :^]


If we wanted to allow the user to set the list of fonts for a CSS type font
perhaps we could add a "[more...]" button and show a list like the following:

    Fonts ::::::::::::::::::::::::::::::::::::::
                                                
    +-Fon_ts for: [default choices         :^]-----------+
    | :/: _Use dflt. choices for this encoding           |
    | _Proportional: [Georgia      :^][  14:^] [more...] |
    |    _Monospace: [Courier New  :^][  12:^] [more...] |
    |        _Serif: [Times New Rom:^][  14:^] [more...] |
    |   Sa_ns-serif: [Trebuchet    :^][  12:^] [more...] |
    |      _Cursive: [Zapf Chancery:^][  16:^] [more...] |
    |      _Fantasy: [Desdemona    :^][  16:^] [more...] |
    | [ ] Minimum font si_ze:         :   8:^: [more...] |
    +----------------------------------------------------+
    [/] Allow documents to use _other fonts     
    For plain te_xt, use: [Monospace         :^]


    More ::::::::::::::::::::::::::::::::::::::

    +-Font List for: <x-western> <Proportional>--------------+
    |                                                        |
    |                               Use these fonts          |
    |   Available Fonts             In this order            |
    | +------------------+-+      +------------------+-+     |
    | | Times New Roman  |^|      | Georgia          |^|     |
    | | Arial            |#|      | Impact           |#|     |
    | | Arial Black      |#|      | Lucida Sans Unico|#|     |
    | | Impact           | |      | Courier          | |     |
    | | MS Sans Serif    | | [>>] |                  | | [^] |
    | | Small Fonts      | |      |                  | |     |
    | | System           | | [<<] |                  | | [v] |
    | | Verdana          | |      |                  | |     |
    | | Courier New      | |      |                  | |     |
    | | Fixedsys         | |      |                  | |     |
    | | Lucida Console   |v|      |                  |v|     |
    | +------------------+-+      +------------------+-+     |
    +--------------------------------------------------------+


    
    

    
  
oops: bug 61883 (not 61833)

    
    

    
  
I'm confused. Why would the user want to configure a _list_ of fonts for a given
encoding and CSS family? When would Mozilla use any other than the first one on
the list (i.e. rendering the list unnecessary)?

There is another bug open on Mozilla having a list of fonts from which it makes
its _initial_ choices for these values, but that's a totally separate thing...

Gerv

    
    

    
  
mpt likes to mention a url that complains about too many command buttons.

gerv's spec (esp w/ bstell's additions) reminded me of it.

Face [Proportional:^]

Will try to use these fonts:
 12pt Georgia
 14pt Impact
 10pt Lucida Sans Unicode
 11pt Courier

<change>

What does minimum font size affect?

    
    

    
  
It's not my spec, it's mpt's spec.

I believe minimum font size is basically to prevent authors making fonts
unreadably small on Mac ;-) Seriously, it's also for the visually-impaired.

Gerv

    
    

    
  
Does it apply to all fonts, by typeface, by typename or ...?

    
    

    
  
Multiple fonts are useful for cases where you don't have a font that contains 
all characters. For example, if you have a font that contains Latin1 and another
that contains Greek, then you will want to to use one particular font for the 
Latin1 characters and another particular default font for the Greek characters.

Now, why exactly we would base things on the encoding is something I've never
quite understood. Going forward, everything will be in UTF8 or UTF16, so why
would basing something on the encoding help? Of course, this is not my area,
so what do I know...

    
    

    
  
Currently, the spec has minimum font sizes, when and if implemented, being set 
on a CSS-family and encoding basis.

I really think that setting multiple fonts per CSS family per encoding to be 
making this whole thing too complex :-)

Gerv

    
    

    
  
> Now, why exactly we would base things on the encoding
> is something I've never quite understood.

Me neither.

> Going forward,
> everything will be in UTF8 or UTF16,

And if it isn't, you can still write Japanese in US-ASCII, KOI-8-R &c.

If the font used should be based on anything, it should be based on the 
language of the current text.

And I *do* think it should be based on the language. Sometimes fonts contain 
just a couple of glyphs from one "language". When text in this language is 
rendered, most glyphs would be taken from another font (lower in the font 
list), but a few would be taken from the first font (higher in the font list). 
This will look very ugly!

    
    

    
  
> If the font used should be based on anything, it should be based on the 
> language of the current text.

There are several ways to determine the language:

good ways:
 1) html lang tag (currently working)
 2) xml lang tag (not implemented yet)

fallback ways:
 3) encoding of page (for non unicode encodings)
   (currently working for non unicode except I'm not sure 
    what happens for unicode)

Any other ideas?

> And I *do* think it should be based on the language. Sometimes fonts contain 
> just a couple of glyphs from one "language". When text in this language is 
> rendered, most glyphs would be taken from another font (lower in the font 
> list), but a few would be taken from the first font (higher in the font list). 
> This will look very ugly!

Exactly, this is why it is important for the user to control the fonts.


    
    

    
  
> There are several ways to determine the language:
>
> good ways:
>  1) html lang tag (currently working)
>  2) xml lang tag (not implemented yet)

And the 'Content-Language' HTTP header and/or meta http-equiv element. This 
specifies the language for the whole document (the (xml:)lang attribute 
overrides this).

For an example of a page using this, see <URL: 
http://home.no.net/huftis/nynorsk-programvare/mozilla/ >.

If you right-click and choose 'Properties' anywhere (on any page), you can see 
the language code for the chosen element. This indicated that Mozilla already 
has a way of figuring out the language on a per-element basis.


    
    

    
  
sorry i've rather silent here... i like the screenshot of the new Fonts panel.
:)

i've cc'd attinasi --marc, would you be able to review gerv's patches?
Keywords: patch

    
    

    
  
We already have three dimensions in this UI:
(1) The list of typefaces for each family
(2) The list of families for each encoding
(3) The list of available encodings.

Adding more dimensions (such as multiple typefaces for each family for each 
encoding) would, I feel, make the UI prohibitively complicated -- I'd much 
rather that those other dimensions be handled by smarter defaults/algorithms 
instead. Minimum font size would affect all families at once, rather than 
individual families, for the same reason. This UI already gives the user more 
power than I've seen in any other Web browser (apart from Opera, which is 
hideously complicated), so I don't think we need to worry about users being 
disappointed.

The URL timeless refers to is <http://iarchitect.com/controls.htm#CONTROLS23>.

`Allow documents to use _other fonts' is intended to eventually have siblings 
in `Allow documents to use _other colors' and `Allow documents to use _other 
styles'. Not all pages are written by authors.

    
    

    
  
> `Allow documents to use _other fonts' is intended to eventually 
> have siblings in `Allow documents to use _other colors' and 
> `Allow documents to use _other styles'. Not all pages are written 
> by authors.

I find the `Allow documents to use _other fonts' to be too indirect.
I'd prefer something more direct such as

  Override document's fonts

or

  Use documents fonts when possible



    
    

    
  
I cannot review the patches, sorry, I don't speak XUL...

    
    

    
  
Comments: great stuff, nice work Gerv and mpt! A few comments:
1) The calibrate-screen.xul textfield needs focus when the dialog comes up.
Either create a calibrate-screen.js, or embed a small script in the xul.
2)+<!ENTITY  units.centimetres                       "centimetres">
If we add this to en-US, it should be "centimeters". Sorry Gerv ;)
3) calscreen =
window.openDialog("chrome:communicator/content/pref/calibrate-screen.xul",
I still wonder how this is working, but it works...
should be |chrome://communicator/....|, as far as I know.

The rest is fine (holding my r= for now).

    
    

    
  
Brian,

thanks for adding me to the cc list! I'll start work on bug 33340 as soon, as
this bug is closed and since it'll impact the new UI, I'll actively solicit your
collective opinion.

A quick comment on the proposed changes: how do we look performance-wise? It's
been a while since I had a look and the XUL performance has been greaty
improved, but I still remember comments from Matt and Pierre on the problems
that surfaced when attempting to populate the font pref dialog with 5 drop-down
lists. 

Has any performance-optimization work been considered? We could e.g. initially
create the drop-down lists with only one font face and populate them fully only
when clicked . In addition we could cache the font face list on the pref window
to avoid multiple font enumerator invocations.



    
    

    
  
Gerv,

please allow me to raise a few more points with the calibrate-screen.xul popup:

1) should we name if pref-calibrate-screen.xul for naming consistency?
2) please consider persisting the unit of measure (<menulist id="units" 
persist="value">) to make it more locale-friendly
3) any particular reason to set screenX="10" screenY="10"? I think it looks odd 
to have the popup come up in the upper left screen corner
4) please consider persisting the screen position also (        
persist="screenX screenY")
5) making height="180"> moves the OK/Cancel buttons from the bottom, IMHO it 
looks nicer that way

Please let me know, if you'd like me to create an updated attachment.




    
    

    
  
> 1) The calibrate-screen.xul textfield needs focus when the dialog comes up.

I am using pref-fonts.js for the other stuff related to this dialog, so I'm sure
I can do it in there. 

> 2)+<!ENTITY  units.centimetres                       "centimetres">

Hmph. Well, I reserve the right to use the correct spelling in the entity name,
even if we use the wrong one in the displayed text ;-)

> A quick comment on the proposed changes: how do we look performance-wise? 
> It's been a while since I had a look and the XUL performance has been greaty
> improved,

Any performance problems this dialog had were not the fault of XUL :-) Premature
optimisation is the root of all evil. If, after we checkin, we find we have
performance problems, we'll deal with it. It's Not This Bug(TM). 

But I am not going to perfect this dialog to everyone's satisfaction, or I'll be
here all year. All I have to do at the moment is satisfy Fabian ;-)

Sidenote: I've just managed to crash Mozilla on this dialog by changing lots of
things and clicking OK; but that is the underlying fonts code, not the XUL (and
it's Not This Bug either.)

New patch coming with requested review changes.

Gerv

    
    

    
  
I think we want the buttons in attachment 33781 [details] right-aligned.

    
    

    
  
> 1) should we name if pref-calibrate-screen.xul for naming consistency?

I thought that "pref-" was reserved for preferences panels, but checking more
carefully, this seems not to be the case. Consider it renamed.

> 2) please consider persisting the unit of measure (<menulist id="units" 
> persist="value">) to make it more locale-friendly

Done.

> 3) any particular reason to set screenX="10" screenY="10"? I think it looks 
> odd to have the popup come up in the upper left screen corner

It now comes up centerscreen. This seems the only way of doing this nicely for
different screen sizes.

> 4) please consider persisting the screen position also (        
> persist="screenX screenY")

It seems you can't have both this and it coming up centrescreen - that is, if
you want to persist X and Y, you have to set initial values for them.

Note: the "Add Languages" dialog loaded from the Languages pref panel comes up
in the top left.

Someone decide what's wanted, OK? :-)

> 5) making height="180"> moves the OK/Cancel buttons from the bottom, IMHO it 
> looks nicer that way

On my setup they are quite a way from the bottom already. I've ditched the
absolute sizes and used sizeToContent().

> Please let me know, if you'd like me to create an updated attachment.

I can cope, thanks :-) If centrescreen is OK, then it's ready. If you want
top-left and persist X and Y, say so and I'll change it.

Gerv

    
    

    
  
Blake: Add Languages and the New Mime Type boxes have them centred, and so does
the prefs dialog itself. This is a standard box from the toolkit. If you
right-align them, you are being inconsistent. (This doesn't mean we don't want
to do this; but perhaps realigning all the boxes is another bug?)

Gerv

    
    

    
  
Re: button centering. My mistake. They are all centered on Linux, but I should
still be using okCancelButtonsRight. This is now fixed. Blake r=ed the idea of
bringing it up centrally, so here is a new patch.

Gerv

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch v.2
        — 
          — Splinter Review
      

    


  

    
    

    
  

      
      
      
      

        Attached patch
          
          
        pref-calibrate-screen.xul
        — 
          — Splinter Review
      

    


  

    
    

    
  
r=fabian

    
    

    
  
hyatt: Can you sr= this, please? It's the new and funky Fonts prefs panel UI.
I'll send an official request as well.

Gerv

    
    

    
  
could you please use 'cm' instead of centimetres?

    
    

    
  
Gerv,

looks good - it just occurred to me that you need to include pref-calibrate-
screen.xul in makefiles and the jar manifest.

here is, what a LXR search on pref-fonts.xul yields:

/xpfe/components/jar.mn, line 32 -- content/communicator/pref/pref-fonts.xul 
(prefwindow/resources/content/pref-fonts.xul)
/xpfe/components/prefwindow/resources/content/MANIFEST, line 21 -- pref-
fonts.xul
/xpfe/components/prefwindow/resources/content/makefile.win, line 50 -- .\pref-
fonts.xul \


    
    

    
  
You might be interested to know that the fix for bug 74899 has been backed out 
due to regression bug 80756. Even though I didn't have any problem on linux 
when I tested the patch. Adding shanjian to CC. Shanjian, maybe this panel 
fixes bug 80756 even with the patch for bug 74899?

    
    

    
  
Shanjian's patch for bug 74899 was for windows only.
 

    
    

    
  
timeless: If we do that, we'd have to use "ins." or similar, wouldn't we? Can
you find examples elsewhere in the UI where we use one style or the other?

It's not as if we are short of space in this dialog.

Juraj: I'll do a patch and roll it into the one with the sr= comments (if any.) 
It's not like I can mess this up, right? ;-)

Gerv



    
    

    
  
kb instead of kilobyte(s).  But I was talking about the internal code, naming 
it in/cm.  The external code could still be long or short form [and would be 
localizable].

    
    

    
  
I'll be _very_ annoyed if this doesn't get into 0.9.1... :-)

Gerv
Target Milestone: --- → mozilla0.9.1

    
    

    
  
Gerv, these patches look good. Can you attach a screenshot of:
a) the panel, and 
b) the calibration dialog?

Thanks!

    
    

    
  


  

    
    

    
  


  

    
    

    
  
Ben:

Here you are. The look hasn't changed much.

Gerv

    
    

    
  
gerv you asked about abbreviations... we use dpi =) so yes there are good 
examples of using them. It might even make sense to use them in general since 
they tend to be more recognizable worldwide.

    
    

    
  
Looks fantastic, and this should fix the fonts-panel-not-fitting bug too. 
sr=ben. 

    
    

    
  
Ben,

could you provide a pointer to the "fonts-panel-not-fitting" bug? 

I've observed something similar: when no font faces are available for a 
particular language group, we initialize the corresponding drop-down list with 
a very long and descriptive single element. It looks butt ugly and causes the 
dialog to overflow to the right.

    
    

    
  
Are all font-sizes in pixels? Now that the "Size" label is gone, you might
want to explicitly say 16 px, 13 px, etc.

    
    

    
  
Anyone who knows what a "px" is will know the sizes are in pixels :-) Otherwise, 
does your average user need to know? The fact that 26 is twice the size of 13 
should be enough.

Anyway, I'm not going through the review process _again_! This is going in 
_right_now_ :-)

Gerv

    
    

    
  
Feel free to do as you prefer - but it would look much nicer if you just append
" px" to read 13 px, 16 px, like Adobe Photoshop, etc :-)

Hmm... 13 px, next to 96 dpi, next to Text Size 150 %, etc, wouldn't that look
much nicer and uniform :-)

    
    

    
  
Checked in just now.

Gerv
Status: NEW → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED

    
    

    
  
vrfy fixed (other issues, followup bug should be filed separately :). checked
both themes.

linux comm 2001.05.23.08, and mozilla from 8pm last night
winnt comm 2001.05.24.09
mac comm 2001.05.24.08
Status: RESOLVED → VERIFIED

    
    

    
  
I have a question about this change.

If user select "Sans" or "San Selif" in the proportional selection, the HTML 
page will pick the fonts for the specified language.  
However, how can the user to use "Cursive", "fantasy", or "Monospace" font from 
UI?  There is no selection for "Cursive", "fantasy", or "Monospace" in 
preference dialog.


    
    

    
  
Here is a test HTML page that includes fantasy and cursive:
    http://www.w3.org/Style/CSS/Test/19981002/sec522.htm

    
    

    
  
I just got cc'd on this bug, sorry for the belated comments...

I find the layout of the 3 dropdowns (Proportional, Serif and Sans-serif) to
be confusing.  There should be some visual indication that Proportional is
related to Serif and Sans-serif.  Currently, all 3 look like peers.  In
the previous UI, there was a radio button.  That worked for me.  But if you
prefer another dropdown, maybe better layout (e.g., indentation) would help.

    
    

    
  
The way this works is as follows: the initial dropdown selects which font is 
used by default. The other five select which are used when one of the CSS font 
families is requested.

It was laid out like this because, when the back-end support is in place, it 
will be possible to select the "default" font independently of the fonts for the 
five font families. That dropdown will cease to say "serif" and "sans-serif" and 
will become a proper font dropdown.

Gerv

    
    

    
  
In my opinion, this current design is very confusing and not usable, and may be 
proposed to be changed for subsequent versions of Netscape, if will stay that 
way for Mozilla.

Suggestions:
At the very least the first "Proportional" drop down should be placed seperate 
from the others because it is not the same thing.
Then: in your explanation you are using the word "Default" 2 or 3 times. why 
not name it "Default". It is very confusing to see "Serif" and "Sans-Serif" in 
that first drop-down, then see serif again as the label for the next drop down.

    
    

    
  
<throws hands in the air>

Can the people who design UI in this product not agree on the spec for 
anything? Do you have any idea how frustrating it is to spend a month or so 
painfully dragging a large patch through review and super-review, only for 
people to pop up and say it's got to be all changed again? Please coordinate, 
OK?

> At the very least the first "Proportional" drop down should be placed seperate 
> from the others because it is not the same thing.

If you like, we can do this as a short-term measure. When the back end is fixed, 
they _will_ be the same thing.

> Then: in your explanation you are using the word "Default" 2 or 3 times. why 
> not name it "Default". It is very confusing to see "Serif" and "Sans-Serif" in 
> that first drop-down, then see serif again as the label for the next drop > 
down.

It's named Proportional because that's what it's called in some other browser - 
IE I think. Argue the toss with mpt, I don't care what it's called.

Gerv

    
    

    
  
German, when this bug was assigned to you, you said my design `looks great'.
Now, after the bug has sat stewing for well over a year, it has finally been
fixed, and suddenly you think my design is `very confusing and not usable'. Why
the huge change?

Why is `Proportional' not called `Default'? Because it's not the only default,
and never has been. Look in other browsers, such as Netscape 4.x (or 3.x, or
2.x), or Internet Explorer for Windows. There are two default fonts -- a
proportional one used for ordinary body text, and a monospace one used for TT,
PRE, CODE, and SAMP. Now that everything is based on CSS, the CSS `monospace'
font is an obvious match for those HTML elements. But there isn't such a
one-to-one match between a CSS family and the proportional font. You might want
to use a serif font, or a a sans-serif font, or a cursive font, or a font which
fits in none of the CSS categories, as your preferred proportional font.

Currently the back end only allows you to choose between whatever you have
chosen for `serif' and whatever you have chosen for `sans-serif', so that's why
they're the only options in the popup menu. Ultimately you should be able to
choose any typeface you like, whereupon the `Proportional' popup menu will
become just the same as the others in the list.

The current UI is certainly not perfect, for back-end reasons which Gerv and I
could do nothing about. But I think it's certainly an order of magnitude better
than the previous UI, which suffered from lack of flow, lack of CSS-savviness,
odd spacing and indentation, and mysterious disappearing text fields.

    
    

    
  
mpt: let's recall your ASCII art I was looking at almost a year ago which 
looked something like this:

+-Fonts for [default choices         :^]-+ ||
| [*] Use deft. choices for this encoding| ||
|                                        | ||
| Normal      [Georgia          :^][14]H | ||
| Monospace   [Courier New      :^][12]H | ||
| Serif       [Times New Roman  :^][14]H | ||
| Sans-serif  [Trebuchet MS     :^][12]H | ||
| Cursive     [Zapf Chancery    :^][16]H | ||
| Fantasy     [Desdemona        :^][16]H | ||
|+----------------------------------------+||
| [*] Allow documents to use other fonts   ||
| For plain text, use ( ) Normal (*) Monspc. 

Now that is "an order of magnitude better" then the currently implemented 
design , because it makes clear the relationship between the default for plain 
text, which can be chosen from either normal (proportional) or mono-spaced text.

In the current implementation the relationship between the "Proportional" 
dropdown and the other dropdowns mapping CSS fontnames to actual fonts is 
totally unclear, and it will look *very* confusing to a lot of users.

Users will not necessarily care whether or not the back end is implimentable, 
they look at the design and underlying functionality as a whole and will be 
stuck with that until the next version. In order to be successful you have to 
change the design to map to the underlying functionality that is available, and 
I think your old design does that while the current implimentation does not at 
all.

    
    

    
  
Is "Proportional" a CSS font type (or soon to be)?

If not, does it belong in the list of CSS font types?

Maybe:

+-Fonts for [default choices         :^]-+ ||
| [*] Use deft. choices for this encoding| ||
|                                        | ||
| Serif       [Times New Roman  :^][14]H | ||
| Sans-serif  [Trebuchet MS     :^][12]H | ||
| Monospace   [Courier New      :^][12]H | ||
| Cursive     [Zapf Chancery    :^][16]H | ||
| Fantasy     [Desdemona        :^][16]H | ||
|+----------------------------------------+||
| [*] Allow documents to use other fonts   ||
| Plain/unmarked text [Monospace     :^] | ||
 



    
    

    
  
That menu seems more intuitive to me. Proportional isn't a CSS font.

I also suggested adding units because that's what other professional products do 
(' px' in this case, instead of ' pt' which is the assumed default font-size 
unit in typography).

    
    

    
  
Er... there is some value in having a default/normal/whathever. I seem to 
recollect that in the old dialog, there used to be a question like "by default 
use [serif/sans-serif]".

    
    

    
  
bstell's proposal does not allow the user to specify a font to use in the 
proportional case when no font is specified, which is exactly what the dropdown 
he removed does.

I am patching up related stuff over in bug 81904. While I am there, I will 
insert a <separator class="thin"/> between the first dropdown and the subsequent 
five.

I don't see why people think that (perhaps with the above addition) this dialog 
is confusing. You specify different fonts, depending on what the web page author 
asked for, or didn't. If he specifies a "proportional" as opposed to monospace, 
font, you use the one listed in Proportional. If he is more specific, and asks 
for "sans-serif", you use the one listed in Sans Serif. What's the problem?

Gerv

    
    

    
  
This is where the "context help" would... help. Maybe we could experiment a
first content help on this panel? I'm not sure what Ian Oeschger's plans are for
the context help, however, and this is not the scope of this bug... maybe we
could open a new one about this issue?

    
    

    
  
Gervase: 
the problem with this design is the relationship between proportional and the 
other drop downs. To the end user It will not be clear at all why "sans-serif" 
would appear as both item in the list for "proportional" as well as it's own 
dropdown at the same level as "proportional". This implies some sort of 
hierarchical relationship between "Proportional and "Sans-Serif" in the user's 
mind, while the visual design/spacing of the dropdowns relative to each other 
does not. So the design looks like it is contradicting itself.

    
    

    
  
> bstell's proposal does not allow the user to specify a font to use in 
> the proportional case when no font is specified, which is exactly what 
> the dropdown he removed does.

Huh?

The dropdown list I proposed was specifically there to deal with the 
"case when no font is specified".

My point is that "Proportional" is not a CSS font type. I suggested moving
it away from the CSS font types set to give a visual hint that it is
separate.

Rather than adding what appears to be a new CSS font type I propose letting 
the user select which CSS font type to use when no font is specified (unless 
we really want to add a 6th CSS font type).


    
    

    
  
> The dropdown list I proposed was specifically there to deal with the 
> "case when no font is specified".

Sorry, my fault. Having it show "Monospace" confused me.

> My point is that "Proportional" is not a CSS font type. I suggested moving
> it away from the CSS font types set to give a visual hint that it is
> separate.

I will do that over in the other bug by inserting a separator; I want to 
minimise changes for 0.9.1. I have to revisit this whole issue (again <sigh>) in 
0.9.2, but hopefully rbs's backend changes will be in by then and the current 
format will be fine.

Gerv

    
    

    
  
German: The `For plain text, use:' is the choice of proportional/monospace for
viewing text/plain, message/rfc-822, and similar files. It wouldn't be used for
HTML. Currently the pref for message/rfc-822 is in the highly awkward `Message
Display' panel (no good if you just want to quickly view some ASCII art in a
message and then switch back to proportional), and the pref for text/plain (as
far as I know) doesn't exist at all.

I renamed `Normal' (from my original design) as `Proportional' mainly because
that's what Internet Explorer for Mac OS calls it. I didn't invent it, and
neither did Microsoft's Macintosh developers. It's what you have when you have
no CSS family applied to the text, and a user doesn't necessarily want such text
to be shown using the same font as any of the CSS families. You can see Internet
Explorer's font prefs at <http://www.chasms3.com/macie5/mie5pref3.htm>.

I agree that it would be a good idea to put a separator between `Proportional'
and the CSS families, until we get the ability to choose any typeface for
`Proportional' (rather than having to choose between whatever serif or
sans-serif happens to be). I had considered putting it under the other popup
menus temporarily, but thought that the confusion caused when it was moved back
up to the top (once you could choose any typeface) would outweigh the logical
benefit from having it at the bottom now. It's quite possible I was wrong, in
which case moving the popup menu under the others is worth considering too.

    
    

    
  
hum... It is kind of is a 6th CSS font type; the font to use for unmarked text.

> [named] `Proportional' mainly because that's what Internet Explorer for 
> Mac OS calls it

This does not seem to me to be a strong reason to use this name.

How about calling it "(Plain Text)" or "(Default Font)" or "(Unmarked Text)" ?
(and putting it at the end of the list?

> get the ability to choose any typeface for `Proportional'
(? including monospaced?)

Why not use one of the 5 CSS font types? 
What advantage does one get by having separate font selection here?



    
    

    
  
> hum... It is kind of is a 6th CSS font type; the font to use for unmarked 
> text.

Indeed. That's why it's in a list with the other five.

> > [named] `Proportional' mainly because that's what Internet Explorer for 
> > Mac OS calls it
> 
> This does not seem to me to be a strong reason to use this name.

Would it be a stronger reason if IE for Windows called it that? 

> How about calling it "(Plain Text)" or "(Default Font)" or "(Unmarked Text)" ?
> (and putting it at the end of the list?

"plain text" has monospace overtones. "Unmarked text" also sounds very wrong - 
you mean "un-marked-up text", and that's horrible. It's not "default font" 
because, as mpt has explained on 2001-05-31, there are several "default font"s.

> > get the ability to choose any typeface for `Proportional'
> (? including monospaced?)

Yep, suppose so - if you are perverse. But this would be a really strange thing 
to do.

> Why not use one of the 5 CSS font types? 
> What advantage does one get by having separate font selection here?

Because some people like their default font to be a serif font and some like it 
to be a sans serif font. Also, there are some fonts which are good "default" 
fonts which do not fall into any of the 5 categories.

Gerv

    
    

    
  
> Because some people like their default font to be a serif font and 
> some like it to be a sans serif font. 

Yes, one of the 5 CSS font types.

> Also, there are some fonts which are good "default" fonts which do not 
> fall into any of the 5 categories.

Sounds interesting. Would you kindly elaborate?


    
    

    
  
> > Because some people like their default font to be a serif font and 
> > some like it to be a sans serif font. 
> 
> Yes, one of the 5 CSS font types.

Yes, but we need UI to decide _which_, as we have now. Or are you happy with 
that?

> > Also, there are some fonts which are good "default" fonts which do not 
> > fall into any of the 5 categories.
> 
> Sounds interesting. Would you kindly elaborate?

See bug 61883. Specifically mpt's comment on 2001-04-29. A font called "Minion 
Web". It's also been discussed elsewhere, but I don't have the bug number.

Gerv

    
    

    
  
> Yes, but we need UI to decide _which_, as we have now. Or are you happy 
> with that?

We need UI to decide which. 

The question is does the UI provide a font list or CSS font type list?

I see Minion Web listed in bug 61883 but I don't see any discussion on
whether the 'no-markup-font' should be one of the 5 CSS font types or 
should be some other font.

I'd still like to understand the rational for selecting a new font for
'no-markup-font' text vs selecting one of the 5 CSS font types.


    
    

    
  
> I'd still like to understand the rational for selecting a new font for
> 'no-markup-font' text vs selecting one of the 5 CSS font types.

Because someone may well want: 
Proportional: Minion Web
Serif: Times New Roman
Sans Serif: Verdana

Because Minion Web doesn't fit either category (or so I'm told) you wouldn't 
want it as either your serif or sans-serif font. If the dropdown only allowed 
you to choose which of the five fonts selected below should be used for your 
Proportional font, then the above settings couldn't be created.

Gerv

    
    

    
  
For the record, Minion Web is definitely a serif typeface. It looks sorta like 
a cross between Plantin and Garamond, both of which are serif typefaces. If I 
had Minion Web installed, I'd choose it as my `Proportional' choice, but not my 
`Serif' choice. (Currently in IE I have Georgia for `Proportional', and Times 
New Roman for `Serif'.)

> I'd still like to understand the rational for selecting a new font for
> 'no-markup-font' text
(Option A)
>                       vs selecting one of the 5 CSS font types.
(Option B)

Ok then. Take the most common task: `How do I choose the font used for most 
text in Web pages?'. What follows is instructions for this under Options A and 
B. The instructions assume that the user is already in the Fonts panel, and 
that bug 33340 has been implemented (though they wouldn't be much different 
with it unimplemented). The instructions would not be affected by exactly where 
the `Proportional:' popup menu/radio buttons/whatever happened to be in the UI 
(which is what much of the post-fix discussion in this bug has been about).

Option A
--------
1.  Open the `Proportional' popup menu, find a typeface which you like, and
    choose it. You're done.

Option B
--------
1.  Open any CSS family popup menu *except* the `Proportional:' one (which
    doesn't list typefaces) *or* the `Monospace:' one (which, if bug 54786 is
    fixed, doesn't list proportional typefaces), and find a typeface which you
    like. Do *not* choose it, otherwise you'll lose your current selection for
    the family whose menu you opened (which might not be the appropriate family
    for your chosen typeface).
2.  Decide whether your chosen typeface could best be described as serif,
    sans-serif, cursive, fantasy, or monospace. (If you don't know what any of
    these mean, spend a few minutes looking them up in the online help.)
3.  In the relevant popup menu (`Serif:', `Sans-serif:', `Cursive:',
    `Fantasy:', or `Monospace:'), find your typeface again and choose it.
4.  Open the `Proportional:' popup menu, and choose whichever family you
    decided your typeface belonged to. You're done.

I know which of these I'd rather inflict on users.

    
    

    
  
What seems to cause confusion is that "Proportional" isn't an intuitive word
(compared to other words like: default, variable width, fixed width).

re: back-end: I have made enough progress in bug 61883 to allow individual fonts 
(rather than just a generic font) to be selected. Actually, the front-end would 
need to be revisited to match the changes.
Blocks: 61883

    
    

    
  
> If you don't know what any of these mean, spend a few minutes looking 
> them up in the online help.

The old font preference dialog "might" have been useable without knowing 
about the CSS font style spec. I'd be very surprised if anyone could really 
understand the current font pref dialog without knowing that a fair amount 
about CSS font types.

Why wouldn't most people implement Option B would by just choosing which of
the 5 CSS font types to use?

The Option B case you describe only applies to someone that knows alot about
fonts, thinks one is really cool but never spent the time to setup any of the
5 CSS fonts setting to use this really cool font. That seems like a very small 
percentage of people to build a UI for.

Lets just ignore for the moment the totally non-intuitive name 'Proportional'.
The goal was changing the font pref dialog from a 'maybe useable by an non- 
CSS expert' font pref dialog to a 'CSS compliant' font preference dialog.

If we feel that users need a 6th CSS font type then we should actively be 
pushing for a 6th font type.

What effort is being made to get it into a standard?

Lacking any effort to make it a standard why should we add a 6th CSS font 
type?

As far a I can tell this 6th type is not a standard, is not proposed to be
a standard, and is not in wide use (defacto standard).


    
    

    
  
> If we feel that users need a 6th CSS font type then we should actively be
> pushing for a 6th font type. What effort is being made to get it into a
> standard?

I don't know. What efforts *are* you making? You're the only person I've seen 
suggesting a sixth CSS font type. Personally, I'm happy with just five.

>           Lacking any effort to make it a standard why should we add a 6th
> CSS font type?

We shouldn't. If you want such a type, please get it accepted as a standard 
before filing an RFE for it.

All we're doing is allowing the user to specify a font for the common case 
where no CSS family is specified. We could do this the way Netscape 6 and iCab 
do, such that you can only choose this font from the ones already chosen for 
one of the CSS families. Or we could do this the way Internet Explorer and 
Opera do, such that you can have a font choice for CSS-unfonted proportional 
text which is separate from your font choices for the various CSS families.

I think it's fairly obvious that the approach taken by Internet Explorer and 
Opera is more usable than the approach taken by Netscape 6 and iCab, for the 
reasons I described in my previous comment -- it doesn't take nearly as many 
clicks to set the font you want for the majority of text on the Web.

I'm happy with changing `Proportional' to `Normal' (as it is in Opera), or to 
`Variable width', if that will make it easier to understand.

    
    

    
  
I don't recommend a 6th font so let's not have one.

The way "Proportional" work it *is* a 6th font.

> I think it's fairly obvious that the approach taken by Internet Explorer and 
> Opera is more usable than the approach taken by Netscape 6 and iCab, for the 
> reasons I described in my previous comment -- it doesn't take nearly as many 
> clicks to set the font you want for the majority of text on the Web.

This is just not true.

All a user would have to do is click on "Unmarked Text" dropdown and select one
of the already defined CSS font types.

This is *exactly* the same operation you propose except there is no 6th font.



    
    

    
  
> The way "Proportional" work it *is* a 6th font.

Of course. But it's not a CSS family -- though you seem determined to complain 
that it is, or that it should be, or that it shouldn't be, or something.

The idea is to have 6 font selections: 5 for the five CSS families, and 1 for 
when CSS is not applying. Just like Opera has 16 font selections: 5 for the 
five CSS families, and 11 for when CSS is not applying. Of course, the user 
doesn't need to know whether a particular selection is for a CSS family or for 
something else; so once you can choose a specific typeface for un-CSSed text, 
there will no longer be any need for extra spacing between the `Proportional' 
menu and the other menus, since all six menus will work in exactly the same 
way.

> All a user would have to do is click on "Unmarked Text" dropdown and select
> one of the already defined CSS font types.

As I described in detail in my 2001-06-05 comment, that would require two or 
three menu actions, whereas the current proposal would require only one. And 
since you'd still need a popup menu for choosing the CSS family to use for 
un-CSSed text (like we have now), you'd still have just as many controls in the 
GUI. So the UI would be just as complex, it would be slower to use, it would be 
less flexible, and it would be less internally consistent. That's why I said it 
was fairly obvious that the current proposal would be more usable than that; 
because it *is* fairly obvious.

    
    

    
  
Are you telling me that today when you change the "Proportional" menu you do:

    Option B
    --------
    1.  Open any CSS family popup menu *except* the `Proportional:' one (which
        doesn't list typefaces) and find a typeface which you
        like. Do *not* choose it, otherwise you'll lose your current selection
        for the family whose menu you opened (which might not be the 
        appropriate family for your chosen typeface).
    2.  Decide whether your chosen typeface could best be described as serif,
        sans-serif, (If you don't know what any of
        these mean, spend a few minutes looking them up in the online help.)
    3.  In the relevant popup menu (`Serif:', `Sans-serif:'), find your 
        typeface again and choose it.
    4.  Open the `Proportional:' popup menu, and choose whichever family you
        decided your typeface belonged to. You're done.

How many people have told you that they do it that way?

Would changing the number of entries in the "Proportional" menu from 2 to 5 
fundamentally change the user interaction?


    
    

    
  
> Are you telling me that today when you change the "Proportional" menu you do:

Not exactly, because (as I noted) bug 33340 hasn't been implemented. So
currently Step 1 is replaced by either `go to a separate app, such as a word
processor, to find the font you want', or `repeatedly choose a font, click `OK'
and go to a text-filled Web page to look at your selection, then enter
Preferences again, until you find the font you want'.

> How many people have told you that they do it that way?

It isn't possible to do it a shorter way, unless (as you were proposing) the
user is lucky enough to have their chosen font set as the font for one of the
five CSS families already. (Shades of Henry Ford with the Model T: `You can have
any color car you want, as long as it's the color of a bike you already own.')
If they want a font other than one of those ones, they have to perform two or
three menu actions -- setting one of the CSS families to be that font first,
then setting `Proportional' to refer to *that* family. Under the current
proposal, they'd have to perform only one menu action -- just setting
`Proportional' to the typeface they wanted.

> Would changing the number of entries in the "Proportional" menu from 2 to 5
> fundamentally change the user interaction?

The `Proportional' menu has never had two options, and never will (unless the
user has only two fonts installed), so I'm not sure how that's relevant. The
previous UI used radio buttons, and that was quite appropriate for a selection
where only two options (Serif/Sans serif) were available.

    
    

    
  
There is a screenshot a possible alternative at: 
http://style.cleverchimp.com/cssui/
Product: Browser → Seamonkey

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: