Point of implementation: This page reacts poorly to changes in the user-agent’s default font sizes, because it defines the size of blocks like “The Yesterweb”

Point of implementation: This page reacts poorly to changes in the user-agent’s default font sizes, because it defines the size of blocks like “The Yesterweb” in pixels, but fills it with contents in an unknown font family and size so that its contents are liable to overflow messily (that is, in the “CSS is awesome” meme way). Things are made more complex by the use of the magic monospace, so that the font size inside the body element is not scaled according to the number that’s almost certainly 16px (1.2 [for html] × 1.2 [for body] × 16px = 23.04px), but rather according to the number that’s probably 13px (1.2 × 1.2 × 13px = 18.72px). I long ago changed my monospace font size to 16px, so I get overflow. I wonder whether browser makers would be open to the idea of removing the monospace font size thing. Shrinking the font-size to 81.25% is just a bad idea in general in almost all monospace fonts used now (… and it was never a particularly good idea in the first place). These days, almost no one hits it because it’s rare to use just `font-family: monospace` (instead it’ll normally be a foolishly complex list of options that mostly just makes things worse these days, except in Firefox on Windows pending https://bugzilla.mozilla.org/show_bug.cgi?id=713680 https://bugzilla.mozilla.org/show_bug.cgi?id=713680), and when people do hit it they normally get confused if they’re not familiar with it and almost always want to work around it. But bringing it back to a more useful discussion point: this is a good demonstration of a problem that used to occur regularly, but is now exceedingly rare. The concept of responsive design and especially mobile devices helped make this happen.