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

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.  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.  So you're right, we do want
to support other values instead of 1-7 -- probably pt and maybe rem
rather than percentages, but that's an aside -- but we still have to
support the old values.

> I'm fuzzy on the details of the execCommand API but it seems like the
> proposed editing API should be treating the old size values as
> obsolete, just as the <font> element is, and allow an additional set
> of values oriented towards style usage. That way someday in the future
> all user agents can drop support for size=7 altogether.
>
> Example:
>
>  document.execCommand("fontSize", false, "150%");

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.

> It seems like adding xxx-large to work around interop problems for the
> styleWithCSS = true case is getting it backwards. We should be
> changing the syntax of execCommand to allow more CSS-like relative or
> absolute values.

We do want to do that (or rather introduce new commands that do that),
but we still have to support the old values forever.


On a further note: I think it's valuable in general to make it easy to
convert legacy HTML markup into CSS markup.  For instance, MediaWiki
allows <font size> in user input.  This means that the pages it
generates are invalid HTML5.  It would be great if support for <font>
could be phased out in favor of CSS, but that requires porting all
existing uses.  If they could be mechanically converted to CSS with a
(near-)guarantee that the new markup would produce the same results,
then in principle one could run a script that did that and then reject
<font> in input from that point forward.  But if there's no exact CSS
equivalent, it's much harder to get rid of old uses automatically,
because there's much greater risk of introducing bugs.  There's no
reason CSS shouldn't have feature-parity with obsolete HTML markup.

Received on Wednesday, 18 April 2012 07:13:17 UTC