- 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