Making HTML Legal Documents (Like MPL) Look Good

A few months ago I bought “Typography for Lawyers” (TFL), an excellent book that I would recommend to all lawyers. And since the biggest document I was working on at the time was, of course, published in HTML, I started spending a few minutes here and there on learning enough CSS to make the license look better. (Understandably, the book’s very pragmatic advice is focused on Word and Pages, not HTML.)

Fine Print by CJ Sorg, used under CC-BY 2.0I’ve published the experiment (Compare with the plain-jane HTML MPL 1.1). [Update: the experiment is no longer available, but the official, final version of the license incorporates many lessons from it.] This is just an experiment and a personal hack, but I’m happy to hear more suggestions and improvements, and if the final result works, I’ll suggest we use it instead of the traditional plain HTML version. Some notes on the process, including links to the (abbreviated) blog posts at the TFL website (for much more thought and detail, buy the book):

• Fonts: This was hard. The author of Typography for Lawyers is himself a former font designer, and (correctly, I think) a font snob. Given that I was not going to splurge for fancy webfonts just for this project, I spent a lot of time browsing and playing with Google Web Fonts. This is clearly not ideal (for example, it has only one monospace option for Exhibits A and B, and I’d like a slightly more subtle serif for the titles) but I think I found a decent combination of fonts – or at least an improvement on the system fonts. Presumably, if this became Official, some better font choices could be used.
• Small Caps: I’d never given small caps much thought until reading TFL. The book is quite positive on them under certain circumstances, and that led me to experiment and eventually to use them as headers. Unfortunately, Google Web Fonts is limited here – none of the Google Web Fonts appear to have true small caps. TFL recommends strongly against fake smallcaps, but I think these look decent so I’ve used them; I’d be happy to replace with a better one if that was available.
• Hyphenation and Justification: TFL does not necessarily recommend full justification, but demands hyphenation if you do fully justify. Since Mozilla just added support for hyphenation, I turned on hyphenation and justification, and I think it looks good (if you’re using a recent build.) In production, it would probably be better to either use something like hyphenator that works cross-browser, or use some sort of browser feature detection to turn off justification for browsers that don’t also support hyphenation.
• Line length: TFL recommends something between 45 and 90 characters per line. (The Supreme Court’s well-designed documents are about 65 characters per line.) Unfortunately, as best as this CSS newbie can tell, there is no good way to do this simply in CSS. I ended up with a total hack, using the “alphabet trick” described in TFL to estimate the right width sildenafil tablets 100mg.
• ALL CAPS:TFL IS AGAINST ALL CAPS FOR ENTIRE PARAGRAPHS. My experimental HTML version uses some gross CSS to create a highlighting box around the two traditionally all-caps blocks in the text.
• “smart” quotes: We know that people copy and paste from the HTML version of the license into plain text files, even though (with MPL 2) we’re going to provide a very nicely formatted plain text version of the license. And of course, copying and pasting curly quotes into plain text gets… messy. And so, I am conflicted about this. The HTML linked above uses smart quotes, while the plain text uses straight quotes. Inevitably that will lead to some problems; suggestions on how best to fix (use javascript to modify what is copy-and-pasted if someone does that?) are welcome.

Of course, I’m still very bad with CSS and HTML, so I’m sure this document can be improved, and I’m happy to take suggestions and fixes. Regardless, it has been an educational experience for me and I’m glad I toyed with it!

Share this:

• Click to share on Mastodon (Opens in new window)
• Click to share on Bluesky (Opens in new window)

Published by Luis Villa

43 thoughts on “Making HTML Legal Documents (Like MPL) Look Good”

Luis, thank you for this link and book recomendation! It’s great to see there’s more font lovers amongst lawyers :) I completely agree that legal texts have to use proper typography, not (only) for æsthetics, but mainly legibility and clarity. Legalese is hard enough to understand as it is, and we’re doing no-one a favour by obfuscating it even further with ugly fonts and messed up kerning. I’m really happy how HTML5 is making this simpler …so I can have the same liberty with styling on my blog then in my documents with ConTeXt. P.S. Yes, someday, when I have some time free, I will have to rework my website — hardware-, software-, layout- and font-wise.

Yeah, my site needs some font love too ;) But really, it needs all kinds of love that I have not had time to give it of late…

Okay i seriously never expected such a post in my whole life! Also i am not very into typography, but i enjoy fonts. And you made wonderful decision there.
Just one thing, you probably want to remove the second tag.

For smart quotes, the Q element exists. Note that MDC says there may be compatibility problems with (older versions of?) IE, so you may need to consult with someone, or do some verification. (Someone might argue that that’s not the type of quotation the HTML Q element is specced for.[1] Well, when the alternatives up for discussion include other transgressions like JS hacks, I think this infraction isn’t much of a problem.) For line length, the ch unit exists, but that’s CSS3, so again, compatibility comes up. [1] I’m speculating, here. I don’t know if this is an issue that comes up, actually.

Colby: at least here, foo doesn’t seem to actually do the visually right thing- it just gives straight quotes. But I suppose I can style that with CSS? [I’d really love to not care about earlier IEs, but unfortunately lots of lawyers are stuck with old IEs still, so that is also a consideration.]

I’m interested in your opinions on the legal ramifications of publishing legal documents in such a way as to rely on external technology to render the document visibly and legibly to somebody. That is, by using any sort of dynamic encoding system (here, HTML plus CSS; to extrapolate, possibly absurdly, consider JavaScript enhancements) for a legal document implicitly means that, in order for a person to read the document and make a judgement as to whether or not to accept its terms, some instrument must interpret the encoding, act upon its directions, and produce the readable, interpretable form of the document. Implicit in that is the presumption that when all parties prospectively bound under an agreement codified in such a document actually see the document, they all see it the same way. Now, clearly, within manageable bounds of reason mere typographical variations involving change of letter forms in a document, or change of font weight or size, are probably not legally interesting. In other words, it doesn’t seem likely that one party to an agreement might claim that they were duped by such variation in rendered output. However, in a case where the formatting directives are more involved, there’s always a chance that some browser bug, or browser limitation, could result in the presented form of a hypothetical document being quite incorrect: sentences or paragraphs missing or incorrect, or text overlaid on other text to create an illegible mess. I guess what I’m really wondering about is the degree to which the “mechanization” of legal documents taken from print media into the online world has impacted, or may impact, the assumptions around the way a prospective party to an agreement “consumes” the document.