Csswg-drafts: [css-values] Traditional absolute length units

[Crissov]

Absolute lengths

TL;DR

I’ve mentioned the didot point and cicero, its pica equivalent, several times on www-style during the past few years. Unlike recently added q, I’ve never really been convinced myself that it would make sense to specify these in CSS, although I suggested once in 2011 to _reserve_ the units dd and cc (among others).

After I’ve found out that Antenna House Formatter has added support for dd and cc, I felt reminded that it would have been a good idea to add the unit at least to some optional module of CSS, because then we would need to agree on a common standard definition for it.

As it turns out, AH claims to have defined 1dd as 0.01483in. That’s exactly 0.376682mm. The traditional definition of the didot point (based upon pre-metric French inches) indeed converted to roughly 0.376 mm, which has been used as an approximation by European typesetters, but in the later 20th century it had come to mean exactly ⅜ of an millimeter, i.e. 0.375mm or 1.5q would be an approriate contemporary definition that fits well with other CSS units. Just for the record, that’s approximately 0.01476in.

I haven’t found anything about custom units in the documentations of, for instance, Prince, Vivliostyle and Weasyprint yet, by the way.

These thoughts may apply to some other typographers units as well. Most traditional English points, though, including the one used by Teχ as pt, are close enough to the Postscript/CSS definition of 1/72 inch (bp in Teχ), so a separate unit seems unnecessary.

[tabatkins]

AH asked us to add q specifically, presumably due to usage. I suppose if they find that cc or dd are used often enough to be worth standardizing, they'll ask us to add them as well.

I'm fine with adding them, but want implementor interest first.

[Crissov]

My point is that implementor interest might be harmful in this case, because if AH supported it they’d likely want to standardize _their odd definition_ which doesn’t play well with _any_ of the existing length units, whereras a _proactively_ defined 1cc = 12dd = 4.5mm = 18q relationship might be more interesting for some (print) authors to adopt it.

Btw., did someone lately mention the coincidental ratio of approximately √2 between q and pt?

[tabatkins]

Interesting argument, but proactively defining things without sufficient interest isn't really something we do, for good reasons.

[Crissov]

I’m fine with that as long as 1dd is never defined as 0.01483in in a W3C spec. I’ve had enough of these “told you so” moments.

[plinss]

FWIW, Gecko used to have support for didot (as 'dt') and ciceros (as 'cc') where 15dt = 16pt and 1cc = 12dt (as in back in 1997, removed somewhere along the way for conformance reasons). It also had feet ('ft'), miles ('mi'), meters ('m'), kilometers ('km'), and extra typographic units 'en' (1/2 'em') and 'cap' (cap height, which still seems useful, especially with the new drop cap support).

[Crissov]

Thanks, I didn’t know that, @plinss. Support was removed in 2009 by @dbaron, bug 482146. JFTR, 1dt then was about 0.376296mm – even larger, but at least it fit with other units. I can imagine use cases for ft, m, en and cap (and maybe yd), but not mi or km – um/micron and nm or internal units like sp, twip and emu would have made more sense.

[Crissov]

Today I learned that (some descendants of) Teχ supports dd at 1238/1157 of its points, which is slightly above 376 µm, _and_ nd at 685/642 Teχ points which is intended to equal 375 µm. Most Teχ documentation only mentions dd, if at all.

[plinss]

I put mi and km in Gecko way back when mostly for fun and completeness (not sure why I omitted yd though) but there is a practical application: maps, where you use actual size for the elements and scale the viewport (makes more sense in SVG).

[dauwhe]

Traditional typesetting in the U.S. mostly uses picas/points and inches. Sadly, they're used in ways that CSS doesn't support—for example, 3p4.5 = 9/16in. Oh well. That's why typesetters always have a conversion chart near their desks.

[plinss]

Agreed, picas are extremely useful units and are still commonly taught and used in other software, but they're best used with points as the fraction, not a decimal fraction. Not having the traditional (pica)p(point) notation in CSS has been an oversight, let's fix it. Yeah it's a new parsing behavior, but I don't see it as being fundamentally incompatible, at least no worse than adding scientific notation was.

[frivoal]

If that would ease the transition into CSS for experienced typesetters used to other technologies, why not.

[Crissov]

Unlike teχers, traditional typesetters are probably fine with 72pt = 1in, at least.

calc(3pc + 4.5pt)        calc(3pc + 9pt / 2)        calc(3pc + 3pc / 8)        calc(9in / 16)
p(3, 4.5)     p(3 4.5)      p(3 p 4.5)    p(3pc 4.5pt)  p(40.5)      (3 p 4.5)     [3p4.5]
3-4.5pc       3+4.5pc       3:4.5pc       3,4.5pc       3/4.5pc       3&4.5pc       3..4.5pc
3pc-4.5       3pc+4.5       3pc:4.5       3pc,4.5       3pc/4.5       3pc&4.5       3pc..4.5
3p4.5pc       3p4.5pt

3pc4.5        40pt10        0in3.375      38.1dd        14mm1.15      57q37.5       
3.375pc       40.5pt        0.5625in      810twip       14.2875mm     57.15q        14287.5um
3⅜pc          40½pt         9⅟16in        9⁄16in        9÷16in

The real problem is not this particular traditional syntax, but vulgar fractions and (irrational) constants (like π or τ in #309 and ϕ or √2). The former can be done with calc() accurately, but non-coders are used to a more concise, symbolic syntax, which could be done with Unicode characters for the most part. I don’t think the p syntax alone is worth changing the grammar for, but vulgar fractions and constants might.

Sadly, this is an issue where switching to relative or metric length units doesn’t help much.

[fantasai]

@plinss @frivoal One issue per GitHub discussion, please. :) If you want NpM notation, file it separately (tagged under
css-values-4 and css-syntax). As for this issue, please list the exact units you would like to propose for inclusion in Values
and Units 4 so that we can discuss it with the WG. Thanks~

~fantasai

[Crissov]

@fantasai You’re right, the last four messages before yours (from dauhwe, plinss, frivoal and me) should be in a separate issue, although cicero and didot are used together much like pica and point.

I don’t really want or need the Didot point and cicero, but I want to make sure that _if_ they‘re implemented then their unit symbols are dd and cc with 1cc = 12dd = 4.5mm = 18q, i.e. 1dd = 0.375mm = 1.5q. That’s the only reason why I’m proposing to include them and I know it’s a weak one.

[Crissov]

Collecting and asserting units mentioned above, my proposal is to add the following absolute length units to css-values:

• General metric units:
  m ‘meter’, dm ‘decimeter’ and either mu for µ ‘micron’ or um for µm ‘micrometer’ (but not mum). Obviously, 1m = 10dm = 100cm = 1000mm = 1000000um or 1000000mu ≈ 3780px.
• Typographic metric units:
  cc ‘cicero’, dd ‘didot’ with 1cc = 12dd = 4.5mm ≈ 17px.
• General English units:
  yd ‘yard’, ft ‘foot’ and hd ‘hand’ with 1yd = 3ft = 9hd = 36in = 3456px.
• Fractional English units:
  sx ‘sixteenth-inch’ or ‘six-pixel’, tx ‘thirtysecondth-inch’ or ‘three-pixel’ and twip ‘twentieth-point’ with 1in = 16sx = 32tx = 96px = 6pc = 72pt = 1440twip.
• Common anchor unit:
  gcd, emu or, preferably, dot. 1q = 360dot, 1pt = 508dot, 1px = 381dot.

[frivoal]

I don't think many of these units would serve a practical purpose in CSS. How often do you have a layout with dimensions most conveniently expressed in yards?

Completeness for completeness' sake is not something we should pursue. Units that expose new capabilities (e.g. vh or lh or ic) are useful. Units that are a fixed ratio of existing units, but are a natural and often desired way to express common layouts are useful as well (e.g. in). The rest seems counter productive.

[Crissov]

I humbly disagree and kindly ask you to be more specific with your critique. I believe these units would improve productivity for some authors, once widely supported – and therefore should have been introduced as early as possible. They are also simpler and cheaper to implement than basically every other new CSS feature.

• m, dm, mu|um (my?) – I don’t even consider these different units from cm and mm. I chose meter and micrometer as the useful limits for now, because lengths in most CSS in the wild are ranging from less than a millimeter (e.g. underlines) to dozens of centimeters (e.g. viewport sizes). If I truly bought @plinss’s SVG map argument, I’d have proposed dam, hm and km as well (and probably sm and mi). Beyond these, SI gets ambiguous without case distinction anyway.
• cc, dd – They were the original reason for opening this issue. Although not used much for new designs any more, there’s lots of legacy material that c/should be transferred to an open format which relies on [css-values], e.g. EPUB. Ciceros also suffer from the same problem picas do, namely that those who used them are accustomed to a non-decimal notation, but decimal is all that CSS offers conveniently → #378.
• yd, ft – Personally, I’ll never need, want or use these. I just included them because some random British or American guys would demand them loudly anyway if dm and m were to be specced.
• hd – At 4in, this is arguably the most obscure and least useful unit I proposed. It’s mostly there as an English equivalent to dm. I’ll propose anthropometric units separately soon.
• sx, tx – See @dauwhe’s comment or #378 for why a 1/16-inch unit could improve the welcoming culture of CSS. They’re not integer multiples of pt (but px). Writing them as decimal fractions or calc() expressions feels awkward. Having both, or even the smaller tx at all, may be overkill, so just sx is fine with me, as would be changing the name and symbol.
• twip – Another unit I wouldn’t use myself, but within an in-pt system they kinda make sense for very small measures like kerning or stroke widths. Note that 1px = 15twip, i.e. it’s _a_ common divisor although not the largest (which would be a “quarter-point”).
• dot… – This is not really intended as a unit used by authors, but for internal (integer) representation with the minimum expected precision, like Teχ’s _scaled point_ sp. It is based on the smallest units currently available (q, px, pt), but could of course be changed to the GCD of twip and mu (which would be 1/25 of the current definition).

Let’s make CSS homey for more people!

[frivoal]

cc, dd, twip, sx and tx don't seem crazy to me. I think the demand is low, and I don't think they justify the work by spec writers, testers, browser vendors, print formatters, validators, documentation authors... until we see some evidence of a stronger demand. Yes, the work would be relatively small, but it is non 0.

For the tiny and the large units, I just don't see them being used. Yes, they exist out there, the SI systems (and others) are well defined and all that, so if we were to define them it is very obvious how to do so, but I just don't see any benefit to doing so, and again, while the costs are low due to this being a simple feature, they are not nothing.

[Crissov]

Fair enough. Documenting demand is something this issue is for.

I think it makes sense to eventually push these together with other new units to exploit some synergy effects.

[Crissov]

Dael Jackson @ www-style (2017-02-13): [CSSWG] Minutes Seattle F2F 2017-01-11 Part VI: Writings Modes, CSS Tables, Values & Units 4 Traditional pica notation #378 is discussed under the heading “Adding older typographic units”, actual units in “ciceros, didot, and ens”.

didot (dt) where 15dt=16pt, cicero (cc) where 1cc=12dt, en=0.5em

That’s exactly why I want didot points to be specified in CSS: They need a canonical abbreviation and definition and it should not be 15dt = 16pt, but 8dd = 3mm. They are continental European units, which should relate to the meter, not the English inch. (We could add different dt and dd, but why? CSS doesn’t share Knuth’s distinction of bp and pt in Tex either.)

[Crissov]

Regarding @dauwhe's comment from 2016-07-19: Doesn't this make sx and tx (and perhaps cc and dd as well) an issue for epub/dpub?

[Loirooriol]

IMO cc usually means "cubic centimetre", using it for "cicero" may be confusing.

[Crissov]

@Loirooriol In the context of CSS, this is as much a non-issue as pc meaning _parsec_ or pt meaning _picoton_ elsewhere. We do not have volumetric units in CSS and probably never will, but even then, ml for _milliliter_ is equivalent to cm³ or “ccm”.