Below is the test post I used while developing my script to download Stack Exchange posts to publish on my blog. For a good long time I thought my script was broken because this page included so many missing glyph boxes (□). But then I started thinking about fonts for websites and it occured to me that maybe the problem isn't with my script, but with the browser. Indeed, switching to Arial fixes the problem and renders nearly the same as the original.

To try it out for yourself. Pick another font-family:

Arial, Courier or Times New Roman work pretty well because they have all the glyphs needed for this content. Also, any of these fonts serve as a backup if the primary font is missing a glyph or two:

Cambria, "Book Antiqua", Palatino, "Times New Roman", serif

On the whole, I think this illustrates the rather miserable state of typography on the web. Depending on your browser, operating system and what fonts you might have installed manually, this page might look fine by default (it does on Chrome for iOS for me) or it might not (as on Chrome for macOS for me). I don't have Cambria or Book Antiqua installed on my laptop, so the page defaults to Palatino, which doesn't have all the glyphs on this page. Adding serif does a lot less than you might expect since it defaults to Times (not to be confused with Times New Roman), which is also missing some glyphs.

If you are thinking (as I was not long ago) that it should be possible to have a font with all the glyphs, you will be saddened to discover (as I recently did) that such a font is impossible. There is also a mechanism for constructing a new font family, but that can be tricky to do without imposing a page load penalty. When you can't predict what glyphs are needed with certainty (as is the case for user-contributed content), it can be especially difficult to pick out a font to render the page correctly.

From what I can tell, the options are:

  1. Use a series of font possibilities in the font-family setting, which will mean every combination of OS and browser has the potential to see a different set of glyphs on the page.

  2. Construct a @font-face, which means users without your chosen font will need to download it during the page load.

  3. Just use a boring, but relatively complete and pervasive font such as Arial or Times New Roman.

Robert Bringhurst wrote in The Elements of Typographic Style:

Read the text before designing it.

The typographer's one essential task is to interpret and communicate the text. Its tone, its tempo, its logical structure, its physical size, all determine the possibilities of its typographic forms. The typographer is to the text as the theatrical director is to the script or the musician to the score.

When it comes to an infinite stream of articles created by a variety of people, we can, at best, take a statistical approach to reading the text. A Stack Overflow post will probably have some code, a bit of prose and possibly some test data. A post on a humanities Stack Exchange site will likely have no code, but will have block quotes instead. Science and math sites will have mathematical expressions (composed in MathJax) while the photography site will have plenty of images. Language sites often use specialized glyphs for non-Latin scripts and the IPA.

That's not a lot to go on when designing the page. Plus, you'll end up with the occasional outlier such as a Lovecraftian screed against using regular expressions to parse irregular syntax. In many ways, selecting a font for this sort of site is less like putting the finishing touches on a performance and more like gathering common props for the stars of the show (the post authors) to put to use. Perhaps the ideal solution to picking a font for a Stack Exchange site is to carefully construct one. But I think an argument can be made for avoiding creating any impression at all with typography by using a veritable tabula rasa of a font such as Arial.

And now, RegEx match open tags except XHTML self-contained tags answered on Stack Overflow by bobince:

You can't parse [X]HTML with regex. Because HTML can't be parsed by regex. Regex is not a tool that can be used to correctly parse HTML. As I have answered in HTML-and-regex questions here so many times before, the use of regex will not allow you to consume HTML. Regular expressions are a tool that is insufficiently sophisticated to understand the constructs employed by HTML. HTML is not a regular language and hence cannot be parsed by regular expressions. Regex queries are not equipped to break down HTML into its meaningful parts. so many times but it is not getting to me. Even enhanced irregular regular expressions as used by Perl are not up to the task of parsing HTML. You will never make me crack. HTML is a language of sufficient complexity that it cannot be parsed by regular expressions. Even Jon Skeet cannot parse HTML using regular expressions. Every time you attempt to parse HTML with regular expressions, the unholy child weeps the blood of virgins, and Russian hackers pwn your webapp. Parsing HTML with regex summons tainted souls into the realm of the living. HTML and regex go together like love, marriage, and ritual infanticide. The <center> cannot hold it is too late. The force of regex and HTML together in the same conceptual space will destroy your mind like so much watery putty. If you parse HTML with regex you are giving in to Them and their blasphemous ways which doom us all to inhuman toil for the One whose Name cannot be expressed in the Basic Multilingual Plane, he comes. HTML-plus-regexp will liquify the n​erves of the sentient whilst you observe, your psyche withering in the onslaught of horror. Rege̿̔̉x-based HTML parsers are the cancer that is killing StackOverflow it is too late it is too late we cannot be saved the trangession of a chi͡ld ensures regex will consume all living tissue (except for HTML which it cannot, as previously prophesied) dear lord help us how can anyone survive this scourge using regex to parse HTML has doomed humanity to an eternity of dread torture and security holes using regex as a tool to process HTML establishes a breach between this world and the dread realm of c͒ͪo͛ͫrrupt entities (like SGML entities, but more corrupt) a mere glimpse of the world of reg​ex parsers for HTML will ins​tantly transport a programmer's consciousness into a world of ceaseless screaming, he comes, the pestilent slithy regex-infection wil​l devour your HT​ML parser, application and existence for all time like Visual Basic only worse he comes he comes do not fi​ght he com̡e̶s, ̕h̵i​s un̨ho͞ly radiańcé destro҉ying all enli̍̈́̂̈́ghtenment, HTML tags lea͠ki̧n͘g fr̶ǫm ̡yo​͟ur eye͢s̸ ̛l̕ik͏e liq​uid pain, the song of re̸gular exp​ression parsing will exti​nguish the voices of mor​tal man from the sp​here I can see it can you see ̲͚̖͔̙î̩́t̲͎̩̱͔́̋̀ it is beautiful t​he final snuffing of the lie​s of Man ALL IS LOŚ͖̩͇̗̪̏̈́T ALL I​S LOST the pon̷y he comes he c̶̮omes he comes the ich​or permeates all MY FACE MY FACE ᵒh god no NO NOO̼O​O NΘ stop the an​*̶͑̾̾​̅ͫ͏̙̤g͇̫͛͆̾ͫ̑͆l͖͉̗̩̳̟̍ͫͥͨe̠̅s ͎a̧͈͖r̽̾̈́͒͑e n​ot rè̑ͧ̌aͨl̘̝̙̃ͤ͂̾̆ ZA̡͊͠͝LGΌ ISͮ̂҉̯͈͕̹̘̱ TO͇̹̺ͅƝ̴ȳ̳ TH̘Ë͖́̉ ͠P̯͍̭O̚​N̐Y̡ H̸̡̪̯ͨ͊̽̅̾̎Ȩ̬̩̾͛ͪ̈́̀́͘ ̶̧̨̱̹̭̯ͧ̾ͬC̷̙̲̝͖ͭ̏ͥͮ͟Oͮ͏̮̪̝͍M̲̖͊̒ͪͩͬ̚̚͜Ȇ̴̟̟͙̞ͩ͌͝S̨̥̫͎̭ͯ̿̔̀ͅ

Have you tried using an XML parser instead?

Moderator's Note

This post is locked to prevent inappropriate edits to its content. The post looks exactly as it is supposed to look - there are no problems with its content. Please do not flag it for our attention.

Jon here again. Here's the font selection tool for your convenience: