187256 - Optimize sub-medium <absolute-size> values

Status: NEW

(Core :: CSS Parsing and Computation, defect, P5)

Description

[Felix Miata]

I've often seen in discussion among web page developers that absolute-size is
virtually worthless. I believe a fix to this would have the power to reverse
that opinion and make these sizes useful.

http://www.w3.org/TR/REC-CSS2/fonts.html#font-size-props recommends a scaling
factor of 1.2 between adjacent indexes. This seems reasonable enough for sizes
above medium, but inhibits usability at sizes below, particularly at lower
resolutions and small default pixel sizes appropriate thereto. A good
description of the currently rendered values of the sub-medium sizes would be as
follows: xx-small=nano, x-small=microscopic & small=extra-small.

The CSS2 factor of 1.2 is larger than it sounds, since it is applied to the
height of the character box, not to the area it occupies. For example, applying
the 1.2 factor in reverse using the default 16px setting to go from medium to
xx-small, the difference is a 9/16 or 44% reduction in maximum character height.
The real difference is better reflected by the area of the character box, 256px
vs. 81px, for a reduction of 68%. If the 1.2 factor is to be applied uniformly
regardless of default size, then it should be applied to the area of the box,
not its height.

The overall scaling is currently biased toward the 9px usability floor. 9px is
generally agreed to be the usability floor. Yet, 9px is the value rendered by
every xx-small value from the minimum selectable default value of 10px up
through 16px. An example of this incongruous result is when 12px is the default
selected: both xx-small and x-small are rendered at 9px, while small is rendered
at 10px, and 11px is skipped to render medium at 12px.

My thought on the current scaling is that it is either a holdover from the
anachronistic use of point values, which produce considerably coarser scaling
than pixel values when DPI is above 72, or a blind adherence to the W3C 1.2
scaling recommendation, without the results ever having been seriously evaluated
for optimal usability.

Selection of a default size is of necessity a compromise between too small to
read and unacceptably little viewport content. Typically this means that sizes
significantly smaller than medium can easily become functionally illegible,
depending on the visual capability of the user. IMO, at any reasonably selected
default size and combination of display size and resolution, the current
renderings of xx-small are always painfully small, though usually legible. This
shouldn't and needn't be so.

The first attachment (HTML) contains four tables applicable to default pixel
values from 10-28:

	Row 1
		Current pixel assignments
		Recommended pixel assignments
	Row 2
		Current pixel deltas
		Recommended pixel deltas

The second attachment (ZIP) contains the first, plus the linked files it refers
to, each of which renders the current values alongside the recommended values
for one selectable default font size contained in the table. Proper use of the
latter requires setting the browser's default text size to the selected value.

Comment 1

[Felix Miata]

Attachment: HTML tables of Mozilla's <absolute-size> Assignments by Resolution and Default Size

Comment 2

[Felix Miata]

Attachment: ZIP of Attachment #110408 plus to files to which it links

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

See also bug 111879

The 1.2x factor yields some annoying results in real-world use, especially on
most X11 systems with the default fonts.

For wgate's use, we patched the font-size tables (we have to use fairly large
fonts for TV) and lowered the 1.2x factor as well.  I find 1.2x too big a jump
at the high end as well (personally).

Comment 4

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

It's worth comparing to
http://style.cleverchimp.com/font_size_intervals/altintervals.html
on which I think our current code is at least partly based.

Comment 5

[Felix Miata]

I spent considerable time studying that page before filing this bug. Prolly
should have included that link when I filed. 1.2 is way too much decrement on
the many pages where authors fix page body text at 11px or 12px or .8em.

Comment 6

[Felix Miata]

Attachment: 1024x768 screenshot - comparing impact of 16px default to 17px default

This is a visual example of a small prefs change causing a disproportionate
impact. By using user.js, the default size can be one not provided by the prefs
UI. 17px is missing from the UI, but produces a marvelous impact on sites using
the <font size="x"> tag or css absolute-sizes to serve tiny text. The single
pixel increase from 16px to 17px produces a 2px increase in 'small' and
'size="2"', and a 3px increase in 'x-small' and 'size="1"'. The net result
matches the values in the table of recommended values in the first attachment.

Here's a tabular interpretation of the screenshot:
	    pixels dotbox dotdelta  pixels dotbox dotdelta
x-small  10px	 100			13px	 169
small	  13px	  169	   69%	     15px     225     33%
medium 16px    256	51%	  17px	   289	   28%

Comment 7

[Felix Miata]

Another try on the table (paste from fixed pitch):
        pixels dotbox dotdelta pixels dotbox dotdelta
x-small  10px   100             13px   169
small    13px   169     69%     15px   225     33%
medium   16px   256     51%     17px   289     28%

Comment 8

[Felix Miata]

Attachment: Testcase

Comment 9

[Felix Miata]

Attachment: Patch v1

On inspection of the original tables, one can see a bias toward the 9px
legibility floor. This patch, in addition to optimizing the table values,
removes the bias in the original ranges for default sizes beyond the
tables, introducing to sub-medium sizes a progressive increase similar
to >medium sizes:

Old
  static PRInt32 sFontSizeFactors[8] =
	60,	75,	89,	100,	120,	150,	200,	300
 Increase	25%	19%	12%	20%	25%	33%	50%
New
  static PRInt32 sFontSizeFactors[8] =
	70,	77,	86,	100,	120,	150,	200,	300
 Increase	10%	12%	16%	20%	25%	33%	50%

It also compresses the range from xx-small to medium, and extends the use
of table values up to a 20px default size.

Using the range from xx-small to medium in the original table, the apparent
difference in size was 9^2=81 to 16^2=256, making xx-small a mere 32% of
medium. The new difference is 12^2=144 to 16^2=256, upping xx-small to 56%
of medium, giving xx-small 78% more dots per character than previously.

Comment 10

[Felix Miata]

Attachment: screenshot 800x600 72 DPI w/ patch applied & 13px default

Comment 11

[Felix Miata]

Attachment: screenshot 1024x768 96 DPI w/ patch applied & 16px default

Comment 12

[Felix Miata]

Attachment: screenshot 1280x1024 120 DPI w/ patch applied & 20px default

Comment 13

[Felix Miata]

Attachment: screenshot 1280x1024 120 DPI w/ patch applied & 22px default

Comment 14

[Felix Miata]

Attachment: screenshot 1600x1200 144 DPI w/ patch applied & 26px default

Comment 15

[Felix Miata]

Attachment: screenshot portion 1600x1200 144 DPI w/ different patch applied & 26px default

Line 368
-  static PRInt32 sFontSizeFactors[8] = { 70,77,86,100,120,150,200,300 };
+  static PRInt32 sFontSizeFactors[8] = { 75,81,89,100,120,150,200,300 };

Comment 16

[Felix Miata]

I suppose after all that work I should take this. ;-)

Comment 17

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

A few quick comments on the patch, although I haven't looked closely:
 * we don't need detailed comments describing what the code used to do. 
Comments should describe what the code does, and why, perhaps mentioning why it
doesn't do what it used to, but this seems to have too much describing the old
code (which is always in cvs).
 * Are you sure there aren't other bugs on this topic?  This really seems like
it ought to be a duplicate of a bug that has many more people cc:ed.
 * Very briefly (i.e., in a sentence or two), how does the approach you've taken:
   (a) deviate from Todd Fahrner's proposal?
   (b) deviate from WinIE's behavior?
 * Have you tested that this table does reasonable things with various font size
defaults (especially smaller ones, such as all integer pixel values in the range
9px to 16px)?

Comment 18

[Felix Miata]

> * Are you sure there aren't other bugs on this topic?  This really seems like
it ought to be a duplicate of a bug that has many more people cc:ed.

I searched Bugzilla before I originally filed the bug without finding one
directly or materially indirectly on point. I'm cc'd on many bugs on font size
issues, and have read many others, and can't recall discussion on this subject
elsewhere.  The cc list here isn't particularly long. The list of actual cc's
with each change I've applied has been considerably larger.

> * Very briefly (i.e., in a sentence or two), how does the approach you've taken:
   (a) deviate from Todd Fahrner's proposal?
   (b) deviate from WinIE's behavior?

The first of the two arrays in comment 11 is Fahrner's basic proposal, which is
both IE6 and the current Mozilla behavior, except that Mozilla applies a 9px
floor to small sizes based upon default values under 17px. In array 1, the %
change between sizes increases as the size deviates away from medium, making the
change e.g. between xx-small and x-small larger than the difference between
x-small and small. In array 2, the % change increases between sizes as the size
deviates away from xx-small, lowering the impact of each successive reduction
below every other size, making it less likely for any particular Mozilla user to
be unable to read sub-medium "<absolute-size>" text when medium has been
appropriately chosen.

> * Have you tested that this table does reasonable things with various font size
defaults (especially smaller ones, such as all integer pixel values in the range
9px to 16px)?

Attachment 110409 [details] has pages specifically designed for each possible small px
default, and I did open each of them briefly to see that the "actual" sizes
matched the "recommended". The content of that attachment is currently live via
http://members.ij.net/mrmazda/auth/absolute-sizes-M.html. I also opened the
testcase briefly with each possible default size from 26px on down. Those,
except for the variant last, are the source of the screenshots attached right
after the patch today.

>* we don't need detailed comments describing what the code used to do. 
Comments should describe what the code does, and why, perhaps mentioning why it
doesn't do what it used to, but this seems to have too much describing the old
code (which is always in cvs).

Patch with less commentary to follow.

Comment 19

[Felix Miata]

Attachment: Patch v2

Less commentary about old behavior; more about new behavior. Behavior
unchanged.

Comment 20

[Felix Miata]

Attachment: Linux screenshot 1024x768 100 dpi 17px default w/ patch v2 applied

A good URL alternate to the testcase:
http://www.elsid.co.za/download/css_fontsizes.htm

Comment 21

[Felix Miata]

Attachment: Linux screenshot 1024x768 100 dpi 17px default w/ patch v2 applied

A good URL alternate to the testcase:
http://www.elsid.co.za/download/css_fontsizes.htm

Comment 22

[Felix Miata]

Comment on attachment 124641 [details]
Linux screenshot 1024x768 100 dpi 17px default w/ patch v2 applied

Using 1.4rc1, I saved to disk as html the "changes submitted" page from
attachment 124640 [details]. The result, in addition to the local file, was a new
attachment 124641 [details] to bug 187256.

Comment 23

[Felix Miata]

Comment on attachment 124577 [details] [diff] [review]
Patch v2

Mercy, both timeless and bz are away at once.

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 124577 [details] [diff] [review]
Patch v2

Since dbaron has already looked at this and knows a lot more about it than I
do, he's the one who should do the review.

Comment 25

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 124577 [details] [diff] [review]
Patch v2

r=[e-mail].  I've worked on this code before to improve handling of
greater-than-default font pref sizes.

Comment 26

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

Comment on attachment 124577 [details] [diff] [review]
Patch v2

>-      { 9,    9,     9,     9,    11,    14,    18,    27},
>-      { 9,    9,     9,    10,    12,    15,    20,    30},
>-      { 9,    9,    10,    11,    13,    17,    22,    33},
>-      { 9,    9,    10,    12,    14,    18,    24,    36},
>-      { 9,   10,    12,    13,    16,    20,    26,    39},
>-      { 9,   10,    12,    14,    17,    21,    28,    42},
>-      { 9,   10,    13,    15,    18,    23,    30,    45},
>-      { 9,   10,    13,    16,    18,    24,    32,    48}
>+      { 9,    9,     9,     9,    11,    14,    18,    27 },	// unchanged
>+      { 9,    9,     9,    10,    12,    15,    20,    30 },	// unchanged
>+      { 9,    9,    10,    11,    13,    17,    22,    33 },	// unchanged
>+      { 9,   10,    11,    12,    14,    18,    24,    36 },
>+      {10,   11,    12,    13,    16,    20,    26,    39 },
>+      {11,   12,    13,    14,    17,    21,    28,    42 },
>+      {12,   13,    14,    15,    18,    23,    30,    45 },
>+      {12,   13,    15,    16,    18,    24,    32,    48 },
>+      {12,   13,    15,    17,    20,    26,    34,    51 },	// new
>+      {13,   14,    16,    18,    22,    27,    36,    54 },	// new
>+      {13,   15,    17,    19,    23,    28,    38,    57 },	// new
>+      {14,   16,    18,    20,    24,    30,    40,    60 }	// new

Could you drop the "unchanged" and "new" comments and restore the original
end-of-line style (so cvs diff will show what was unchanged)?

>-// The 2 lines below marked "anchored" have the exact pixel sizes used by
>-// WinNav4 for Times/12pt and Courier/10pt at 96ppi. As you can see, the
>+// The 2 lines below marked "anchored" have the exact medium pixel sizes used
>+// by WinNav4 for Times/12pt and Courier/10pt at 96ppi. As you can see, the
> // HTML size 3 (user pref) for those 2 anchored lines is 13px and 16px.
> //
> // All values other than the anchored values were filled in by hand, never
>-// going below 9px, and maintaining a "diagonal" relationship. See for
>-// example the 13s -- they follow a diagonal line through the table.
>+// going below 9px,

Most of this comment doesn't make sense anymore.  Why does it matter than 13
and 16 were defaults used by Nav4 now that we no longer get the rest of the row
from Nav4?

> //
>   static PRInt32 sQuirksFontSizeTable[sFontSizeTableMax - sFontSizeTableMin + 1][8] =
>   {
>-      { 9,    9,     9,     9,    11,    14,    18,    28 },
>-      { 9,    9,     9,    10,    12,    15,    20,    31 },
>-      { 9,    9,     9,    11,    13,    17,    22,    34 },
>-      { 9,    9,    10,    12,    14,    18,    24,    37 },
>-      { 9,    9,    10,    13,    16,    20,    26,    40 }, // anchored (13)
>-      { 9,    9,    11,    14,    17,    21,    28,    42 },
>-      { 9,   10,    12,    15,    17,    23,    30,    45 },
>-      { 9,   10,    13,    16,    18,    24,    32,    48 }  // anchored (16)
>+      { 9,    9,     9,     9,    11,    14,    18,    28 },	// unchanged
>+      { 9,    9,     9,    10,    12,    15,    20,    31 },	// unchanged
>+      { 9,    9,    10,    11,    13,    17,    22,    34 },
>+      { 9,   10,    11,    12,    14,    18,    24,    37 },
>+      {10,   11,    12,    13,    16,    20,    26,    40 }, // anchored (13)
>+      {11,   12,    13,    14,    17,    21,    28,    42 },
>+      {12,   13,    14,    15,    17,    23,    30,    45 },
>+      {12,   13,    15,    16,    18,    24,    32,    48 }, // anchored (16)
>+      {12,   13,    15,    17,    20,    26,    34,    51 },	// new
>+      {13,   14,    16,    18,    22,    27,    36,    54 },	// new
>+      {13,   15,    17,    19,    23,    28,    38,    57 },	// new
>+      {14,   16,    18,    20,    24,    30,    40,    60 }	// new

Again, no "anchored", "unchanged", or "new" comments are needed.


I'm curious if Eric Lawrence has any comments on this, since he's worked on
related code for bug 72164.

Comment 27

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

Comment on attachment 124577 [details] [diff] [review]
Patch v2

>+  static PRInt32 sFontSizeFactors[8] = { 70,77,86,100,120,150,200,300 };
>+//  	70,	77,	86,	100,	120,	150,	200,	300
>+//  Increase	10%	12%	16%	20%	25%	33%	50%
>+// Size to size change increases progressively from xx-small base value

Also, I'd expect this to look a little more like the 20px row in the table.

Finally, did you leave any differences between the quirks table and the strict
table?	I don't see any at first glance.  If not, they could be combined.

Comment 28

[Felix Miata]

"Also, I'd expect this to look a little more like the 20px row in the table"

Scale       70%    77%    86%   100%
Table       14     16     18     20
Computed 14.00  15.40  17.20     20
Computed 15.40  16.94  18.92     22

My idea of optimization is that at the small sizes represented in the tables, we
set rounding error to favor visually perceptible uniform deltas over the
theoretical ideals in the scale. It's only when medium reaches 22px that the
rounded delta hits a 2px minimum. As long as the table is limited to integers,
if you conventionally round the computed values, then you wind up with a 1px
table increment between xx-small & x-small, while 3px between small & medium.

If the eye sees four rows of apparently uniformly incrementing small sizes, it
shouldn't notice significant delta disparity between xx-small & x-small and
small & medium. With strict rounding, that's what happens, as the former is 1/14
(7.1%- significantly short of the 10% scale), while the latter 3/17 (17.7% -
beyond the 16% scale). The former can to a larger extent be exacerbated by font
& font server limitations that sometimes supply adjacent px sizes that have
little or no perceptible difference.

Another problem is that the larger the size, the harder it is to perceive a 1px
difference as a real difference in the first place.

The reason we have the tables (AFAIK) is because the difference between sizes
needs to be compressed the smaller the size, in order to maintain perceptible
deltas within the constraint of the 9px intelligibility floor, and the tables
are less expensive than the calculus required to compress further as medium is
decreased.

The current method just bunches everything up against the intelligibility floor,
such that e.g. no matter which default one selects from 9px to 16px, most of
http://www.microsoft.com/ looks exactly the same. I made with/without
screenshots all the way from 11px default to 22px default of both the Microsoft
home page and this testcase: http://members.ij.net/mrmazda/auth/AbsDemo.html. If
you want I can zip them up (81 files) and attach to the bug.

I hope the answer to your question is in there somewhere. :-) This is so much
compromise as long as we're stuck with needing the tables.

"Finally, did you leave any differences between the quirks table and the strict
table?"

Differences between the tables remain in >medium sizes, which I didn't touch at all.

Comment 29

[Felix Miata]

Attachment: Patch v3

As per comment 26, comment removal only.

Comment 30

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

So, the reasons I've been delaying reviewing this patch:
 * there's way too much information in this bug for me to coherently process any of it
 * none of that information actually seems to cover compatibility with other browsers (both standards and quirks mode) -- at least a trustworthy summary of which browsers we're moving closer to and what we're moving further from would be useful
 * this is an area of code in which we should have a strong status quo bias, so I'm unlikely to accept a patch I don't have high confidence in

Comment 31

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

http://lists.w3.org/Archives/Public/www-style/2005Nov/0052 contains a clearer summary of the proposed changes, where it says:

# My proposed changes essentially are three:
# 
# 1-progressively, as much as possible within the limits of font size
# availability to browser rendering engines, increase the delta between
# sizes all the way from smallest to largest;
# 2-compress the deltas at the smaller sizes;
# 3-at the smaller default sizes replace wide deltas between small &
# medium and smaller deltas between x-small and small and 1px or 0 deltas
# between xx-small and x-small with more even deltas between each of those
# sizes.

I'm still not quite sure what #1 means.

Comment 32

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

Comment on attachment 125604 [details] [diff] [review]
Patch v3

(In reply to comment #18)
> > * Very briefly (i.e., in a sentence or two), how does the approach you've taken:
> >  (a) deviate from Todd Fahrner's proposal?
> >  (b) deviate from WinIE's behavior?
> 
> The first of the two arrays in comment 11 is Fahrner's basic proposal,

Starting with a reference to an array in another comment doesn't help me understand the question "what does this patch make us do?", which is what I was asking, and what you consistently failed to answer.  Without a summary, I'm basically going to have to reverse-engineer your code to figure out what it's doing, and reverse-engineering large tables of numbers isn't pleasant.  It's never gotten to the top of my todo list, and probably never will, so marking as review-denied.  You're welcome to re-request review if you provide a concise summary (a few sentences that can be understood on their own) of what you're changing and how the change moves us closer to or farther from WinIE and Todd Fahrner's proposal.

Comment 33

[Felix Miata]

(In reply to comment #31)
> # 1-progressively, as much as possible within the limits of font size
> # availability to browser rendering engines, increase the delta between
> # sizes all the way from smallest to largest;
 
> I'm still not quite sure what #1 means.
 
What we have now for our proportional default of 16px, and increase from size to size:
xx-small: 9px
x-small: 10px - 11%
small: 13px - 30%
medium: 16px - 23%
large: 18px - 18%
x-large: 24px - 33%

Quoting Fahrner "The scaling interval between steps in this system varies nonlinearly along the scale...". 

The object is to flatten the nonlinearity of the steps along the scale, primarily from xx-small through medium:
xx-small: 12px
x-small: 13px - 8%
small: 15px - 15%
medium: 16px - 7%
large: 18px - 18%
x-large: 24px - 33%

With what we have now, whether a user sets his default to any of 13px, 14px or 15px, or stays with our 16px, his xx-small is 9px and his x-small is 10px. My proposal would cause xx-small and x-small for those same four default choices to change by the exact same number of px as medium has been changed, which means only by reducing the default to 12px would xx-small decrease to 9px and x-small to 10px.

The overall effect is a compression of the range between xx-small and medium, and visually more uniform steps between sizes. https://bugzilla.mozilla.org/show_bug.cgi?id=111879#c0 describes why compression is a good thing.

Comment 34

[Felix Miata]

Attachment: a look at current vs. proposed side-by-side

Comment 35

[Felix Miata]

(In reply to comment #31)
> # My proposed changes essentially are three:
> # 
> # 1-progressively, as much as possible within the limits of font size
> # availability to browser rendering engines, increase the delta between
> # sizes all the way from smallest to largest;
> 
> I'm still not quite sure what #1 means.
 
line 198 of nsStyleUtil.cpp currently reads:
static PRInt32 sFontSizeFactors[8] = { 60,75,89,100,120,150,200,300 };

It represents a % increase from size to size from medium down that does not increase on each increment, while it does so increase from medium up:
60 (xx-small)	-> 75 (x-small)	  = 125%
75 (x-small) 	-> 89 (small)	  = 119%
89 (small)	-> 100 (medium)	  = 112%
100 (medium)	-> 120 (large)	  = 120%
120 (large)	-> 150 (x-large)  = 125%
150 (x-large)	-> 200 (xx-large) = 133%

The proposal
static PRInt32 sFontSizeFactors[8] = { 70,77,86,100,120,150,200,300 };
changes that to progressive increases (deltas):
70 (xx-small)	-> 77 (x-small)	  = 110%
77 (x-small) 	-> 86 (small)	  = 112%
86 (small)	-> 100 (medium)	  = 116%
100 (medium)	-> 120 (large)	  = 120%
120 (large)	-> 150 (x-large)  = 125%
150 (x-large)	-> 200 (xx-large) = 133%

sFontSizeFactors only applies with default sizes of more than 16px. At smaller sizes, lookup tables are used. The proposed changes to the lookup tables attempt as much as possible to keep the deltas purely progressive, It really isn't possible, as long as the table values must be integers, to retain progressivity, but the proposal does improve it overall. Attachment 321024 [details] in part is intended to show this.

(In reply to comment #32)
> You're welcome to re-request review if you provide a concise
> summary (a few sentences that can be understood on their own) of what you're
> changing and how the change moves us closer to or farther from WinIE and Todd
> Fahrner's proposal.
 
1-Summary:
Web page developers often claim that absolute-size is virtually worthless. One reason for this is excessive granularity of change between sizes. Another is "unpredictability", which I believe partially applies to the percentage increment between sizes, and partially to differences among browsers.

The proposed fix ultimately should have the power to reverse that opinion by making these sizes useful:
A-it makes percentage increases from size to size:
  1-purely progressive (default sizes >20px)
  2-progressive on average (default sizes in lookup table)
B-it makes increments, on average, less granular

2-Comparison to IE & Fahrner's (incomplete) proposal:
Current is closer to IE than is proposed patch. Both current and IE mostly match Fahrner in their erratic, non-progressive increases and excessively large increments. Keeping increases progressive and compressing the increments are both incompatible with maintaining a match to current IE, Webkit & Opera.

My opinion of Fahrner's proposal is that it serves to do little more than rationalize equating the excessively granular <font-size=[1-6]> to CSS x-small through xx-large.

My hope is to get the spec recommendation changed, following a Gecko lead, and have IE, Webkit & Opera change accordingly. To that end, I've tried to wake up the subject
on the www-style mailing list. http://lists.w3.org/Archives/Public/www-style/2008May/0175.html

Comment 36

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

What do you mean by progressive?

Comment 37

[Felix Miata]

(In reply to comment #36)
Similar to its use describing US Federal Income tax rates, where the tax rate increases as income increases.

The rate of increase increases with each successive increase; in comment 35, deltas of 110%, 112%, 116%, 120%, 125%, 133%.

Comment 38

[u32858]

GCC list spotted this problem I reported to them was due to Firefox:

http://www.mail-archive.com/[e-mail]/msg39703.html

Screenshot of tiny text of font-size:smaller. See what it looks like at present for me with default Firefox3:
http://img219.imageshack.us/my.php?image=firefox3inlineub4.png

Comment 39

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

Comment on attachment 125604 [details] [diff] [review]
Patch v3

Removing superreview request (but leaving review request) per new review rules.

Comment 40

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

Comment on attachment 125604 [details] [diff] [review]
Patch v3

I think making substantial changes to the ratio of medium/xx-small is just going to worsen compatibility across browsers and make authors even less likely to use these sizes.  I think we probably want to keep the general ranges of these sizes relatively similar to what other browsers are doing, which it doesn't seem like this patch is doing.


That said, should we really be limiting ourselves to integers?  On what platforms do we still round font sizes to integers?  On at least some platforms, sub-pixel values of font sizes actually cause gradual changes rather than jumps at a specific point.

Comment 41

[Felix Miata]

(In reply to comment #40)
> (From update of attachment 125604 [details] [diff] [review])
> I think making substantial changes to the ratio of medium/xx-small is just
> going to worsen compatibility across browsers and make authors even less likely
> to use these sizes.  I think we probably want to keep the general ranges of
> these sizes relatively similar to what other browsers are doing, which it
> doesn't seem like this patch is doing.

Other than as an initial size on body (most commonly small), it's rather rare that any use them now, because the steps are quite coarse, non-linear, and an inexplicable mixture of regressive and progressive. The worst part about status quo is the bottom end of the range (xx-small) is too much smaller than default to categorize as legible WRT to any optimal default selection.

Don't forget, CSS sizes are nominal, not real. 60% in CSS (xx-small) is physically 36%. If Gecko takes the lead, and some find its lead useful, others could follow, eventually leading widespread use, and less variability among browsers on individual pages.
 
> That said, should we really be limiting ourselves to integers?

In theory at least, no good reason I can think of.

>  On what
> platforms do we still round font sizes to integers?  On at least some
> platforms, sub-pixel values of font sizes actually cause gradual changes rather
> than jumps at a specific point.

I've yet to observe any such thing. Which platform(s) produce different sizes among all when 15px, 15.33px, 15.5px 15.75px & 16px are specified in the same block with the same family and other attributes?

Comment 42

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

Attachment: font sizes from 15px to 16px

It looks like we round to the nearest pixel on Linux (although I'd remembered otherwise) but deal with all the increments on Mac.  Haven't tested Windows yet -- probably most interested to test newer versions (and maybe also the D2D backend).

Comment 43

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 44

[Felix Miata]

I ran out of ideas how to move this forward after more than 7 years of frustration.