I was also thinking about charsets, BOM (byte order marks) and other shenanigans that had to be correct in the top of the file for things to display as expected. At least it was a struggle for 13 year old me why sometimes æøå showed up completely broken, and sometimes not. Today it feels like a solved issue, all files are UTF-8 all the way and it just works.
Ha, fantastic line that one. Transparent pngs caused so much unnecessary trouble in IE6, it was very annoying, and limited our options as graphic designers.
Hah, my thought as well, was a part of my standard page setup. And then using those transparent pngs to do rounded borders with 9 images nested within 9 divs!
I'd only add the Safari Pinned Tabs `meta` tag (https://developer.apple.com/library/archive/documentation/Ap...), which had you define a simple black and white SVG. This image would get used when a user pinned your tab in Safari, in color when active and black when inactive.
Thank you so much for this amazing resource. One of my projects is a hyper-compatible framework that builds websites that span the compatibility spectrum from Netscape 3.x to today's browsers, and this is very helpful.
Oh, that is so great to hear. Glad to provide it! While writing I was very much thinking about it from the perspective of stripping things out, rather than incorporating legacy code for legacy contexts. Really interesting to think about that line of usage.
Reminds me of how awkward HTML doctypes used to be. Nowadays it's very simple, but in the past? You had to refer to the URL of the doctype declaration on every page
This plus the X-UA-Compatible stuff mentioned in the article meant that for many people, the first few lines of code on a web page were something they probably copied from a tutorial or reference document every time, at least if they didn't have a CMS handy.
You only had to include a doctype if you needed to turn on strict XML rendering or do fun things with XSLT. It was great if you wanted to convert, say, TEI to something browsers could read.
You were always, since the days of HTML 1.0, able to use just <html> to open your document without a doctype. It would be in tag-soup mode, but for most documents (rather than applications) that was fine. Not only do you not need a doctype, but you don't even need a <head> statement... browsers will generate one if you leave it out.
This was not a HTML snippet by itself, but I remember early 2000s almost every website had three small icons somewhere: Set as homepage, Add to favorites, Contact (an envelope/email icon). I think I never used them (I didn't use Favorites back then, don't know why), but it was nice to see that they were available.
Ohh, conditional comments. We had so many IE holdouts on our site, I think only around 2021 I removed the last IE specific fallbacks, and I think some conditional comments were a thing until 2020.
I’m not sure when I removed a bunch of `msapplication-` fields, but probably after 2021 ;)
I guess I can remove `apple-touch-</i>` and `application-name` stuff next…
> These meta tags (and some other, less frequently used ones) were used on Twitter when generating link embeds. However, the documentation and card validator are no longer accessible (previously at https://dev.twitter.com/cards/getting-started and https://cards-dev.twitter.com/validator respectively). X falls back to the widely respected Open Graph meta tags, making the Twitter-specific declarations largely useless. They should be removed in favour of Open Graph tags. Further, they should be removed because X is an awful site with poor moderation that is owned by a man who publicly performed a Nazi Sieg Heil salute and has directly contributed to the rise of fascism in the United States of America and globally, among other horrors.
Ok but I believe `twitter:card` has no OG equivalent and still works?
Well, that escalated quickly. If my client wants Twitter tags, I'll write those Twitter tags. If my client wants dancing hamsters, I'll add those dancing hamsters. I don't care who Elon Musk is and what he did. I don't know the guy, but I do know my wife and family and they want food on the table.
All you need is initial-scale=1, not width=device-width, which is redundant.
"You do not need to set every viewport property. If only a subset of the properties are set, then Safari on iOS infers the other values. For example, if you set the scale to 1.0, Safari assumes the width is device-width in portrait and device-height in landscape orientation." https://developer.apple.com/library/archive/documentation/Ap...
You don't need both, but you should have the width set. From that page:
> A page fails the audit unless all of these conditions are met:
> - The document's <head> contains a <meta name="viewport"> tag.
> - The viewport meta tag contains a content attribute.
> - The content attribute's value includes the text width=.
I researched and tested this extensively the other day. `<meta name="viewport" content="width=device-width">` is all you need. https://vale.rocks/micros/20260902-1350
The same will happen regardless in the case of content extending beyond the width of the viewport. With `initial-scale=1` it'll be a horizontal overflow, without it'll zoom out. I argue that the latter is preferable (https://vale.rocks/micros/20260908-1315) but either way should never reach users due to the usability fails and major accessibility issues.
I disagree vehemently. I couldn't disagree more. The text has to be readable. If you force the reader to zoom in order to read the text, your website is fundamentally broken.
Moreover, neither of these considerations apply to images: "you risk having content off-screen which cannot be focused by a keyboard" "A user is extremely unlikely to think to scroll horizontally to see the rest of a document"
"There is even great president for it with documents on the web" Typo: precedent.
> either way should never reach users
This seems practically unavoidable with images, especially screenshots for example. Device widths vary, image widths vary. There is no magical image width that fits every device width, unless the image is very narrow. Moreover, I try to avoid JavaScript altogether when possible, so I don't want custom JS image viewers all over the place.
I was also thinking about charsets, BOM (byte order marks) and other shenanigans that had to be correct in the top of the file for things to display as expected. At least it was a struggle for 13 year old me why sometimes æøå showed up completely broken, and sometimes not. Today it feels like a solved issue, all files are UTF-8 all the way and it just works.
https://www.w3.org/International/questions/qa-byte-order-mar...
It is still important to declare UTF-8 either in <meta> or Content-Type header, otherwise it will usually default to Windows-1252. Yay compatibility!
Forever burnt into my mind is PNG alpha work-arounds in IE:
Ha, fantastic line that one. Transparent pngs caused so much unnecessary trouble in IE6, it was very annoying, and limited our options as graphic designers.
Hah, my thought as well, was a part of my standard page setup. And then using those transparent pngs to do rounded borders with 9 images nested within 9 divs!
Edit: and down memory lane: the spacer.gif
9 divs? That sounds pretty modern. I remember tables with 9 cells, with cellspacing=0 cellpadding=0 to remove spaces between those cells.
I remember both and I'm thankful that we were able to leave it behind.
Using images for rounded corners.....ugh. I forgot all about that.
I'd only add the Safari Pinned Tabs `meta` tag (https://developer.apple.com/library/archive/documentation/Ap...), which had you define a simple black and white SVG. This image would get used when a user pinned your tab in Safari, in color when active and black when inactive.
> The Protocol for Web Description Resources (POWDER) succeeded PICS but was also unsuccessful in its intentions
At least they were quite inspired for the naming.
Thank you so much for this amazing resource. One of my projects is a hyper-compatible framework that builds websites that span the compatibility spectrum from Netscape 3.x to today's browsers, and this is very helpful.
Oh, that is so great to hear. Glad to provide it! While writing I was very much thinking about it from the perspective of stripping things out, rather than incorporating legacy code for legacy contexts. Really interesting to think about that line of usage.
Reminds me of how awkward HTML doctypes used to be. Nowadays it's very simple, but in the past? You had to refer to the URL of the doctype declaration on every page
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
This plus the X-UA-Compatible stuff mentioned in the article meant that for many people, the first few lines of code on a web page were something they probably copied from a tutorial or reference document every time, at least if they didn't have a CMS handy.
Like many, I ended up memorizing the pattern at some point, and then typing it from memory.
My editor had templates and snippets. Very lux in 2000.
You only had to include a doctype if you needed to turn on strict XML rendering or do fun things with XSLT. It was great if you wanted to convert, say, TEI to something browsers could read.
You were always, since the days of HTML 1.0, able to use just <html> to open your document without a doctype. It would be in tag-soup mode, but for most documents (rather than applications) that was fine. Not only do you not need a doctype, but you don't even need a <head> statement... browsers will generate one if you leave it out.
Technically yes, but the struggle to keep IE out of quirks mode was real, and that meant a doctype and head and all the things.
I am almost positive that there was one version of IE where having any space or newline before the DocType would trigger quirks mode.
This was not a HTML snippet by itself, but I remember early 2000s almost every website had three small icons somewhere: Set as homepage, Add to favorites, Contact (an envelope/email icon). I think I never used them (I didn't use Favorites back then, don't know why), but it was nice to see that they were available.
Server side image maps are a fun one also: https://rickcarlino.com/2021/what-were-server-side-image-map...
Lots of mud at the base of the wall. I think it's a good sign. It'll be a bad sign if this list does't grow.
I do bemoan the loss of the <?xml-stylesheet?> processing instruction and the JavaScript XSLTProcessor API.
There is similar collection in the joshbuchea/HEAD project, in DEPRECATED.md [0].
(It reminds me to finally gather and record remaining info about
that's missing in both documents…)
[0] https://github.com/joshbuchea/HEAD/blob/master/DEPRECATED.md
Keywords aren't (completely) dead (yet), unfortunately. https://bsky.app/profile/vale.rocks/post/3muylxyhg5222
Mention of usage by Yandex: https://yandex.com/support/webmaster/en/controlling-robot/me...
Unfortunately the comments are still used by email developers having to code for Outlook
I recall adding the page transitions to my website c. 2003ish with FrontPage!
Also, an aside, but it's seldom these days that I see inspirational page design but this page is gorgeous.
Ohh, conditional comments. We had so many IE holdouts on our site, I think only around 2021 I removed the last IE specific fallbacks, and I think some conditional comments were a thing until 2020.
I’m not sure when I removed a bunch of `msapplication-` fields, but probably after 2021 ;)
I guess I can remove `apple-touch-</i>` and `application-name` stuff next…
About Twitter Embeds:
> These meta tags (and some other, less frequently used ones) were used on Twitter when generating link embeds. However, the documentation and card validator are no longer accessible (previously at https://dev.twitter.com/cards/getting-started and https://cards-dev.twitter.com/validator respectively). X falls back to the widely respected Open Graph meta tags, making the Twitter-specific declarations largely useless. They should be removed in favour of Open Graph tags. Further, they should be removed because X is an awful site with poor moderation that is owned by a man who publicly performed a Nazi Sieg Heil salute and has directly contributed to the rise of fascism in the United States of America and globally, among other horrors.
Ok but I believe `twitter:card` has no OG equivalent and still works?
Well, that escalated quickly. If my client wants Twitter tags, I'll write those Twitter tags. If my client wants dancing hamsters, I'll add those dancing hamsters. I don't care who Elon Musk is and what he did. I don't know the guy, but I do know my wife and family and they want food on the table.
Luckily, some people have enough money to be able to afford ethical inaction.
Good for them.
Love the ruby tags on Chinese text!!
Ruby tags apply to other scripts as well like Japanese and Korean. See https://www.w3.org/TR/css-ruby-1/.
I use them whenever I have an excuse!
can they be applied to any text? might be useful if you have a hard to pronounce english word
I’ve used them on Latin before.
GeoURLs seem like they would still be useful today.
I hope they support drones these days. ICBMs are too expensive and can't hit your coordinates as accurately.
It could be cool! Folks could use hCards rather than ICBM for that.
https://microformats.org/wiki/h-card
oh god, so many hacks, so many hacks
::facepalm emoji::
I thought PICS was a well-designed framework. I was disappointed when it didn't take off.
I would add this:
All you need is initial-scale=1, not width=device-width, which is redundant.
"You do not need to set every viewport property. If only a subset of the properties are set, then Safari on iOS infers the other values. For example, if you set the scale to 1.0, Safari assumes the width is device-width in portrait and device-height in landscape orientation." https://developer.apple.com/library/archive/documentation/Ap...
I've confirmed the behavior in testing.
This may be Safari-specific? Google recommends setting both: https://developer.chrome.com/docs/lighthouse/best-practices/...
You don't need both, but you should have the width set. From that page:
> A page fails the audit unless all of these conditions are met:
> - The document's <head> contains a <meta name="viewport"> tag.
> - The viewport meta tag contains a content attribute.
> - The content attribute's value includes the text width=.
I researched and tested this extensively the other day. `<meta name="viewport" content="width=device-width">` is all you need. https://vale.rocks/micros/20260902-1350
> I researched and tested this extensively the other day. `<meta name="viewport" content="width=device-width">` is all you need.
This is incorrect. Try adding an <img> that's wider than the device width. Then the whole page gets zoomed and the text unreadably small.
The same will happen regardless in the case of content extending beyond the width of the viewport. With `initial-scale=1` it'll be a horizontal overflow, without it'll zoom out. I argue that the latter is preferable (https://vale.rocks/micros/20260908-1315) but either way should never reach users due to the usability fails and major accessibility issues.
> I argue that the latter is preferable
I disagree vehemently. I couldn't disagree more. The text has to be readable. If you force the reader to zoom in order to read the text, your website is fundamentally broken.
Moreover, neither of these considerations apply to images: "you risk having content off-screen which cannot be focused by a keyboard" "A user is extremely unlikely to think to scroll horizontally to see the rest of a document"
"There is even great president for it with documents on the web" Typo: precedent.
> either way should never reach users
This seems practically unavoidable with images, especially screenshots for example. Device widths vary, image widths vary. There is no magical image width that fits every device width, unless the image is very narrow. Moreover, I try to avoid JavaScript altogether when possible, so I don't want custom JS image viewers all over the place.
The latest MDN recommendation is to use only width=device-width, with initial-scale being mostly redundant.
Source: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...