- From: Aryeh Gregor <ayg@aryeh.name>
- Date: Tue, 17 Apr 2012 15:37:18 +0300
- To: John Daggett <jdaggett@mozilla.com>
- Cc: Ehsan Akhgari <ehsan@mozilla.com>, Ryosuke Niwa <rniwa@webkit.org>, www-style@w3.org
On Tue, Apr 17, 2012 at 3:11 PM, John Daggett <jdaggett@mozilla.com> wrote:
> I don't fully understand the logic behind the desired addition here.
> The <font> element is considered obsolete so why is important to try and
> make features associated with it's functionality interoperable? Is
> there much use of -webkit-xxx-large?
WebKit will add it automatically during editing if CSS mode is on.
This is probably a WebKit bug, but pages written using WYSIWYG in
WebKit will contain it (if they're written in CSS mode, which most
aren't, and if the user wrote something in font size 7).
> Again here, I'm not seeing why following the feature definition leads to
> any sort of problem in real use. It seems like you could just as well
> trim out the use of 7 from the set of permissible values and not much
> would change. Unless there's really a lot of Webkit-specific content
> that actually uses this.
document.execCommand("fontSize", false, 7) is supported by all
browsers and has been forever, so making it invalid would probably be
a compat problem.
> I don't think it's a big deal to add it but as Tab said these relative
> font-size values are a bit goofy to begin with, I'm not sure we should
> be adding new ones.
The cost is minimal, and it would make the platform a bit more
coherent. Legacy HTML formatting tags are around to stay, and it just
makes life easier if there are reliable CSS substitutes. The
additional implementation cost is very small; I'd be happy to write
patches for Gecko.
Received on Tuesday, 17 April 2012 12:38:15 UTC