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.

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.

Move to M16 for now ...

*** This bug has been marked as a duplicate of 31413 ***

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

[C, thx for the clarification (in private email).] re-dupping. *** This bug has been marked as a duplicate of 31413 ***

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.

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

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.

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.

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

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.

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.

Matt's spec looks great. Assiging to Erik who's offer for help on this is much appreciated. clearing out nsbeta2

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?

Ok, I'll take it back. Maybe I'll find some time to do some UI for a change. Marking 'helpwanted' still.

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

Adding nsbeta2 keyword to bugs with nsbeta2 triage value in status field so the queries don't get screwed up

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

Adding mozilla 0.9.1 keyword.

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.

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.

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

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

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?

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

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

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.

Juraj, see dependant bug 80402

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

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

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.

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