https://www.w3.org/International/questions/qa-byte-order-mar...
filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src='image.png');Edit: and down memory lane: the spacer.gif
> <!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.
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 is back when every single byte mattered and saving a few MB was the difference between a good user experience and a bad one.
for those that never used this, you would do something like
<img src="funnycats.jpg" usemap="#funnycats-map">
<!-- the map defines clickable zones --> <map name="funnycats-map"> <shape="rect" coords="34,44,270,350" href="cats.html"> </map>
most ppl used something like Dreamweaver but bad-asses would do their own coordinates.
Why could you not have defined elements overlayed using high z index that were clickable, like invisible divs?
I do bemoan the loss of the <?xml-stylesheet?> processing instruction and the JavaScript XSLTProcessor API.
Smart Tags were present in some beta versions of MSIE6, but were removed before release. The MSSmartTagsPreventParsing meta tag never did anything substantial on the public internet - by the time its use was widespread, the feature had already been killed.
I’m not sure when I removed a bunch of `msapplication-` fields, but probably after 2021 ;)
I guess I can remove `apple-touch-` and `application-name` stuff next…
(It reminds me to finally gather and record remaining info about
<meta name="keywords" content="...">
[0] https://github.com/joshbuchea/HEAD/blob/master/DEPRECATED.md
Mention of usage by Yandex: https://yandex.com/support/webmaster/en/controlling-robot/me...
At least they were quite inspired for the naming.
Also, an aside, but it's seldom these days that I see inspirational page design but this page is gorgeous.
> 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?
<meta name="viewport" content="width=device-width, initial-scale=1">
"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.
Source: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
> 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
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.
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.