- From: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
- Date: Wed, 18 Apr 2012 16:26:27 +0800
- 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.
Cheers,
Kenny
Received on Wednesday, 18 April 2012 08:27:05 UTC