It made sense coming from SGML where you're mostly reading and writing text with an occasional bit of markup. Now it seems some people don't even know that text can appear on a page without first being munged in using the DOM.
Allow me to plug my project here to resurrect SGML in all its glory.
Just two days ago, my paper for parsing HTML5.1 in its entirety using SGML [1] has been accepted for the XML Prague conference, if anyone is interested.
A few years ago I managed to resurrect my first website which I wrote back in 1994/5 (found it on the waybackmachine.) When I re-published the site I left the uppercase HTML in place as historical artifacts sprinkled throughout the code. :)
hah, I just was taking a look at that old code again and found this little gem:
<H3 ALIGN = CENTER><BLINK>Frame ALERT!</BLINK><H3>
<P>
This document is designed to be viewed using <B>Netscape 2.0</B>'s
Frame features. If you are seeing this message, you are using
a frame <I>challenged</I> browser.
</P>
PS: I agree with Graham on his last point about web design, but that was the first example of fixed resolution that came to mind. I still write 2 or 3 css rules each time I read one of his essays.
Actually, this was not his last point. The last point was commented out (if you read the page's source, you'll find this after the 70 characters per line comment).
<!-- <b>How did you make the buttons in your site?</b><br><br>It's made with Yahoo Store. Yahoo Store made all the images in this site, not just the buttons but the titles and thumbnails as well. Within the software there is an image renderer, written in C, that takes as input s-expressions describing images.<br><br><b>What are the email addresses in white text at the bottom of the pages?</b><br><br>Bait for spam crawlers. -->
Here's my opinion:
The fixed resolution has fixed dimensions, not a fixed ratio. Meaning if you view the content on a different screen setting, the content will not change to preserve readability. It's different than the 70 characters per line because you still have 70 characters per line on a bigger screen. The eye not having to travel horizontally is the point because the travel can be irritating at any character size.. That's why code is limited to 70-80 characters per line.
However, this is a problem on mobile: on a big screen, the 70 character is a good thing because you still have a good chunk of text vertically and are able to read with ease. On mobile, on the other hand, your reading speed is way faster than 80characters * number of lines displayed on a mobile screen.. So you spend your time scrolling frantically to keep up with how fast your eyes are reading.
On a laptop, HN is too small but even having it zoomed at 150%, I still have a lot of leeway to read fast. On mobile, the layout is a bit better but every thread seems to go on like forever because the amount of scrolling is just insane.
70 characters per line was because horizontal eye scanning has a higher cost than vertical scanning. But a muscular action of the hand has a higher cost than both, which you're paying on mobile. Imagine reading a book in which each page has only 5 lines and you have to turn the page every couple of seconds. It's just way too tiring.
From Tim Berners-Lee -
"Some tags take parameters, called attributes. The attributes are given after the tag, separated by spaces. Certain attributes have an effect simply by their presence, others are followed by an equals sign and a value. (See the Anchor tag, for example). The names of tags and attributes are not case sensitive: they may be in lower, upper, or mixed case with exactly the same meaning. (In this document they are generally represented in upper case.)"
I don't think it was ever case sensitive. I'm pretty sure that in 1994, I was using lower case html tags without issue at university in Mosaic. Netscape Navigator definitely allowed you to use lower case tags. My final year project was littered with mixed case tags.
