This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 14253 - Add new fontSize variant that accepts pt/px/etc. instead of legacy values
Summary: Add new fontSize variant that accepts pt/px/etc. instead of legacy values
Status: NEW
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - HTML Editing APIs (show other bugs)
Version: unspecified
Hardware: All Windows 3.1
: P2 enhancement
Target Milestone: ---
Assignee: Aryeh Gregor
QA Contact: HTML Editing APIs spec bugbot
Depends on:
Reported: 2011-09-22 21:08 UTC by Aryeh Gregor
Modified: 2012-12-04 00:54 UTC (History)
4 users (show)

See Also:


Description Aryeh Gregor 2011-09-22 21:08:53 UTC
See discussion in bug 14251.  It seems like a straightforward and very useful addition.  Users want to control font size in conventional units like pt, not numbers 1-7.  That's a constraint that dates back to the fact that when these APIs were first invented, <font size> was the only way to control size . . .

We want it to only accept absolute units: in, cm, mm, pt, pc, px.  I suggest that queryCommandValue() always return pt values, like "12pt" or such, with floating-point allowed.  This way the unit is consistent.

What shall we call it?  fontSizeAbsolute is the first thing that comes to mind, but it's a terrible name.  Any suggestions?

Also, Ryosuke, do you think this is a good idea too?  Ehsan said he did, in bug 14251.
Comment 1 Ehsan Akhgari [:ehsan] 2011-09-23 19:27:03 UTC
Another name could be fontSizeCss, which is what they are, really.  But I really don't care about the name too much.
Comment 2 Aryeh Gregor 2011-09-23 19:33:36 UTC
It will only support a few types of CSS length, though, not arbitrary values.
Comment 3 Anne 2011-09-26 07:32:37 UTC
Currently CSSOM recommends serializing to px. I'm not sure what implementations will align on though in the end.
Comment 4 Aryeh Gregor 2011-09-27 19:27:24 UTC
All implementations use px for getComputedStyle(), but I think the new execCommand should return values in pt, because that's what users expect for font sizes.  They're the same anyway except for multiplication by a constant.
Comment 5 Anne 2011-09-27 21:57:59 UTC
Users expect pt? What is that based on?
Comment 6 Aryeh Gregor 2011-09-28 18:51:05 UTC
For WYSIWYG editors?  Can you find me one that *doesn't* use pt for font size?  LibreOffice doesn't even bother specifying a unit, it just has "11" and "12" and so on.  At least for English -- is it different in metric countries?  I just tried changing my UI language for Google Docs to Hebrew, and it's still pt.

Actually, I think fontSizePt would be a good name for the command.  We can just ignore the unit entirely and make it exclusively pt.