W3C home > Mailing lists > Public > www-style@w3.org > April 2012

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

From: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
Date: Wed, 18 Apr 2012 16:26:27 +0800
Message-ID: <4F8E7AB3.2010908@csail.mit.edu>
To: Aryeh Gregor <ayg@aryeh.name>
CC: John Daggett <jdaggett@mozilla.com>, Ryosuke Niwa <rniwa@webkit.org>, WWW Style <www-style@w3.org>, Ehsan Akhgari <ehsan@mozilla.com>
(12/04/18 15:12), Aryeh Gregor wrote:
> On Wed, Apr 18, 2012 at 9:49 AM, John Daggett <jdaggett@mozilla.com> wrote:
>> Why does it need to be relative?  Why not allow percentages instead?
> Background: the idea is that document.execCommand("fontsize", false,
> "foo") is what authors call when the user selects some text and picks
> a size of "foo" from a drop-down.

The drop-down would then have a 1~7 scale, but as I said, I haven't seen
a real world WYSIWYG which provides this. (The is reasonable, given how
weird 3 in the middle is.)

>  Currently, the API supports only
> values of 1 to 7.  Here's a demo that uses it:
> http://www-archive.mozilla.org/editor/midasdemo/
> Most real-world WYSIWYG editors use execCommand() sparingly if at all
> because of lack of interop, but there are enough existing users of
> execCommand() that we can't break them.  

Given that IE and Opera don't support "styleWithCSS" (and also WebKit
outputs the proprietary -webkit-xxx-large), I doubt it breaks anything
if you just say "fontSize" doesn't support "styleWithCSS". Even your
current workaround - output <font size=7> when the value is 7 - won't
break anything.

As another idea: always output with the 'rem' unit when "styleWithCSS"
is on. This is as you said, relying on the 'font-size' of the root
element being fixed, but I think this is better than adding a value
that's mostly useless.

If there's strong use case of a unit relative to the initial font size
instead of the font size of the root, which is pretty much the use cases
of the 'xx-large' keywords, we should instead introduce that unit.

> This is more or less what we're planning to do, but we still have to
> support the existing fontSize command forever -- just like we have to
> support <font> forever, even though it's obsolete.  So it would be
> nice if it could be implemented cleanly in terms of CSS.

If all implementers support the last statement, I am fine withdrawing
all my opinions regarding this.

> There's no reason CSS shouldn't have feature-parity with obsolete 
> HTML markup.

Besides no one has any interest in moving the CSS3 Marquee Module
forward. And lack of feature-parity is this case is a myth. Of course
you can use any absolute length as 'font-size'.

Googling "CSS xxx-large" gives me very few results. This value is
clearly not very useful for Web developers, but if implementers really
want it for performance reasons and whatnot, as a user I should be happy
to accept any performance improvement.

I should note that adding a new value to 'font-size' means that we have
to update all the documentation about 'font-size', and this is a cost.

Received on Wednesday, 18 April 2012 08:27:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:14 UTC