Re: [css3-fonts] Addition of font-size: xxx-large

On Wed, Apr 18, 2012 at 11:07 AM, John Daggett <jdaggett@mozilla.com> wrote:
> I don't think more sensible values for fontSize will break anything here.
> Let the old, not very interoperable behavior remain, and define a new
> behavior that's a better match for CSS and more likely to be interoperable.

We still need to spec and implement the old values, and that would be
easier if we had a CSS equivalent.  Also, note my second argument
(automatic translation).

> Why the restriction?  Why not allow any value that's allowed for font-size?

This is tangential, but: generally, the meaning of commands that set
style is "ensure the computed style of the selected text is X".  So
document.execCommand("forecolor", false, "red") means that all
selected text has a computed 'color' of 'red' (or equivalent).
Likewise, document.execCommand("fontsize", false, "2") means that all
selected text has a computed 'font-size' of however many pixels <font
size=2> works out to.  This still makes sense, because <font size=2>
means a constant font size.

But what would document.execCommand("fontsize", false, "1.1em") mean?
The computed value of "font-size: 2em" varies with context.  It could
mean "make the selected text twice as large", so if you ran it on
<span style="font-size: 1.1em">foo</span> it would change it to
1.21em.  But a) I'm not aware of any WYSIWYG editors that expose that
functionality, and b) it would work differently from all other
commands and therefore be a pain to spec and implement.

So only absolute values work straightforwardly.  rem might work,
because it's always constant within a page, but it would still risk
giving odd results if you put the content in a different page.  E.g.,
at default font sizes 'large' is equal to '1.2rem', but then if you
move the content to a different page the stuff with font-size: large
might get bigger or smaller than the stuff with font-size: 1.2rem.
Moving content from page to page is a very common use-case for web
WYSIWYG -- you write it on the "New blog post" page, and then the
innerHTML gets slurped out and dumped onto your actual blog.  The
pages might have totally different styles, but it should look the same
regardless.  That's the idea of WYSIWYG, after all!  If *all* the text
got scaled up or down, that's fine, but not if some did and some
didn't.

Another side point, just for clarity: there's also a method
document.queryCommandValue() that will return the current value of the
selected text as a string for the given command.  For instance,
document.queryCommandValue("forecolor") will return the selected
text's color.  document.queryCommandValue("fontsize") already returns
only "1" to "7" and we can't change that for compat reasons, so we'd
really be looking at adding a separate command that returns values in
pt or whatever.

On Wed, Apr 18, 2012 at 11:18 AM, Christoph Päper
<christoph.paeper@crissov.de> wrote:
> Aryeh Gregor:
>
>> There is no CSS equivalent to <font size=7> …
>
>  h6  1   xx-small    0.6rem              9.6px =  7.2pt
>           x-small    0.75rem            12px   =  9pt
>  h5  2      small    0.89rem            14.2px = 10.7pt
>  h4  3      medium   1rem               16px   = 12pt
>  h3  4      large    1.2rem             19.2px = 14.4pt
>  h2  5    x-large    1.5rem             24px   = 18pt
>  h1  6   xx-large    2rem               32px   = 24pt
>      7  xxx-large    3rem               48px   = 36pt

rem is not equivalent because it's relative to the root value.  If the
spec required these specific sizes for the various keywords, though,
that would solve the problem too.  Then the CSS equivalent of <font
size=7> would be <span style="font-size: 48px">.  But currently it
doesn't.

John, could the spec be updated to require specific point-size values
for the various keywords (particularly <font size=7>)?  That would
also satisfy my request.

However, these exact values appear not to match browsers.  In IE10
Developer Preview, <font size=1> gives a computed style of 10.06px
instead of 9.6px, 2 is 13.33px instead of 14.2px, and 4 is 18.06px
instead of 19.2px.  Firefox, Chrome and Opera are all the same, except
they round to the nearest pixel.

For the keywords, in IE10 Developer Preview I get xx-small = 8.86px,
not 9.6px; x-small = 10.06px instead of 12px; small = 13.33px instead
14.2px; large = 18.06px instead of 18px.  Again, all other browsers
agree except they round to the nearest pixel.  If we allow for
rounding, browsers differ from the spec for xx-small, x-small, and
small, and also for <font size=2> and <font size=4>.  Also, <font
size=1> is the same as x-small, not xx-small.

So the spec needs to be updated here anyway.

On Wed, Apr 18, 2012 at 11:26 AM, Kang-Hao (Kenny) Lu
<kennyluck@csail.mit.edu> wrote:
> If all implementers support the last statement, I am fine withdrawing
> all my opinions regarding this.

Well, Ryosuke does editing for WebKit and supports the change,
although I don't know if he can speak for WebKit in this respect.  I
work for Mozilla and support the change, although I can't speak for
Mozilla.  I'd be happy with just speccing that <font size=7> is 48px,
though.  That works well enough for me.

On Wed, Apr 18, 2012 at 11:27 AM, Christoph Päper
<christoph.paeper@crissov.de> wrote:
> Usually I try to refrain from name-calling, but which moron specified such crap

Some nameless Microsoft engineer in the 1990s.  It was either before
CSS existed or when CSS was brand-new, so they supported only HTML
formatting, not CSS.  It was a logical decision at the time, and now
we're stuck with it.

> and who, in their right mind, would recommend its usage – today, after the Dark Ages of the Web have long gone?

We don't, but we still have to specify and implement it, to support
existing content.

Received on Wednesday, 18 April 2012 08:47:18 UTC