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

It seems that this discussion would benefit greatly from opinions of
those who participated in the previous discussion that led to the
current mapping. I am not one of such people but I think if we add
'xxx-large', we should probably add 'xxx-small' for consistency.

I don't think adding a pair of keywords that are mostly useless is a
good idea. I should note that the discussion on bug 14251[1] indicates
that the "fontSize" command isn't very useful anyway because it doesn't
allow arbitrary size and we'll eventually have something better.

(12/04/18 0:48), Ryosuke Niwa wrote:
> On Tue, Apr 17, 2012 at 5:11 AM, John Daggett <jdaggett@mozilla.com> wrote:
> 
>>  > CSS 3 Fonts, like CSS 2.1, defines <absolute-size>s ranging from
>>> xx-small to xx-large.  The legacy HTML <font size=1> corresponds to
>>> xx-small, 2 is small (skipping x-small), and 3-6 are medium to
>>> xx-large.  There is no CSS equivalent to <font size=7> -- 3rem is
>>> different because it varies if you change the root element's font
>>> size.  I would like to request that a "font-size: xxx-large" value be
>>> defined, corresponding to <font size=7> (scaling factor of 3).
>>>
>>> WebKit already supports "font-size: -webkit-xxx-large".  Both HTML5
>>> and HTML Editing APIs refer to a nonexistent CSS value of "xxx-large":
>>
>> 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?
>>
> 
> Because <font size=7> element is what execCommand("fontSize", false, 7);
> would generate when styleWithCSS is set to false. What do you suppose UA
> should generate when styleWithCSS is true?

Some options:

1. <font size=7> as suggested by Areyh.
2. <span style="font-size: <number>px"> where <number> is the initial
font size in pixels times three.

>> The lack of xxx-large causes significant problems for editing (in the
>>> sense of <http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html>).
>>> Rich-text editing commands (document.execCommand()) can create styles
>>> using either CSS or HTML tags.  The fontSize editing command accepts 1
>>> to 7 as parameters, because it was designed before CSS was commonly
>>> supported.  The parameters 1 to 6 work fine, but in CSS mode,
>>> document.execCommand("fontSize", false, "7") can't do anything useful.
>>> WebKit produces -webkit-xxx-large, which isn't interoperable, and
>>> Gecko doesn't support CSS mode for fontSize at all.  The editing spec
>>> says to output <font size=7> here even in CSS mode.
>>
>> 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.
> 
> 
> That won't work at all. The value 7 has been supported since the dawn of
> time, and there could be lots of Web contents out there with <font size=7>.
> When user selects such contents and copy & paste, remove style, or reapply
> style, editing commands would need to split elements, clone elements,
> etc... and these operations would likely end up needing spans with inline
> style declarations that matches the style of <font size=7> when
> styleWithCSS is set to true.

I am a bit lost here. But in any case, if someone can give me some
examples where the "fontSize" command is really used on the Web, I will
appreciate that. The closest thing I can find is [2] and [3], but I
should note two things:

1. I haven't seen a font size UI that uses the 1~7 scale for a while, if
I've ever seen one.

2. The example[3] has '4' as the default value. This is clearly wrong.
('3' would be correct)

What I am trying to say is, given how weird the 1~7 scaling, with 3 in
the middle, is, I doubt there exist real world pages that relies on
this, but I am happy to be proved wrong.

>> Unless there's really a lot of Webkit-specific content that actually uses
>> this.
>>
> 
> I bet there is. This is particularly relevant in emails sent by old mail
> clients.

For what it's worth, my Mail 5.1 sends '<span class="Apple-style-span"
style="font-size: <number>px;"' for every font size in the UI.

(12/04/16 18:43), Aryeh Gregor wrote:
> WebKit already supports "font-size: -webkit-xxx-large".  Both HTML5
> and HTML Editing APIs refer to a nonexistent CSS value of "xxx-large":

While WebKit can count as a reason, I think it's a bit strange to count
in what's written on the drafts as objective reasons.

(12/04/17 20:37), Aryeh Gregor wrote:
> 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.

I don't think it very hard if you just replace xxx-large with "a
nameless value used to indicate a font size 50% larger than 'xx-large'",
so it's not clear whose life is made easier with this.

> The additional implementation cost is very small; I'd be happy to
> write patches for Gecko.

I'd be happy to write patches for WebKit too.


[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=14251
[2] http://www-archive.mozilla.org/editor/midasdemo/
[3]
http://samples.msdn.microsoft.com/workshop/samples/author/editing/HTML_Editor/StepThree_B.htm


Cheers,
Kenny

Received on Tuesday, 17 April 2012 19:32:53 UTC