This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
Another name could be fontSizeCss, which is what they are, really. But I really don't care about the name too much.
It will only support a few types of CSS length, though, not arbitrary values.
Currently CSSOM recommends serializing to px. I'm not sure what implementations will align on though in the end.
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.
Users expect pt? What is that based on?
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.