I’ve been given to understand that the Parchment .js/.css stuff currently distributed with Inform7 is woefully out of date, but at the same time I don’t see any hits on the Inform7 bug tracker for “parchment” or “css”. This “style.css” isn’t part of curiousdannii’s Parchment distribution (curiousdannii/parchment) and I can’t find it in ptomato/gnome-inform7 either. But I feel like someone out there might be interested in this patch, or even be able to suggest improvements, so I’m posting the link here.
Nope, according to w3schools.com/cssref/css_units.asp , which lists “em” but not “ch” as a valid unit of measurement in CSS. Apparently “em” in CSS isn’t defined as the width of an m anyway; it’s defined as the point size of the current font, regardless of how wide or narrow the font is. Which is a decent enough proxy for whatever it is we’re actually trying to measure.
I couldn’t find a .css file in your Github repo that looked at all similar to this one, so I figured it wasn’t proper to file an issue about it on Github… besides which I don’t see an “issues” page there, so I’m actually not sure where the Parchment bug tracker lives.
Not just in CSS; this is what “em” has always meant. (Specifically, in lead type it’s a square – the same distance across as the distance from baseline to baseline, without extra leading between the lines of text.)
Looks like “ch” is (or rather, will be; what you linked is a non-normative draft) new in CSS3. It’s equal to the width of the “0” glyph in the current font, which doesn’t really seem any closer to what we care about for displaying interactive fiction. I’d stick with “em”: it’s current, it’s supported, everyone (even W3Schools ) knows about it.
If ch was more widely supported it would be a reasonable measure of the average width of a character in a non-monospaced font. As it is now, Parchment does all measuring with the monospaced status line font.
