Antiquated HTML Snippets and Artefacts(vale.rocks) |
Antiquated HTML Snippets and Artefacts(vale.rocks) |
> 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?
https://www.w3.org/International/questions/qa-byte-order-mar...
> <!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.
filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src='image.png');Edit: and down memory lane: the spacer.gif
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’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…
I am continuously in awe of the Web's decentralized and open nature that allows something like this to happen-- for one reasonably complex file/application to be compatible with 30 years of co-evolving client software written by many different developers and teams, much of it no longer supported.
I do bemoan the loss of the <?xml-stylesheet?> processing instruction and the JavaScript XSLTProcessor API.
Smart Tags was present in some beta versions of MSIE6, but was removed before release. The MSSmartTagsPreventParsing meta tag never did anything useful - by the time its use was widespread, the feature it controlled had already been killed.
(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
If you're doing string matching via Casefold or NFKC_Casefold [a], characters from both the needle and the haystack are converted to lowercase (with exceptions for algorithm stability reasons) before being compared.
Why lower case and not upper case? Theoretically, the choice is arbitrary, but given the distribution of lower-case vs upper-case characters in most texts, you can use the fact that lower case occurs more often to optimize your algorithms by skipping the case conversion for most characters.
a: https://www.unicode.org/versions/Unicode17.0.0/core-spec/cha...
I literally saw daily deals that were microsoft word files saved as HTML. Ugh.
https://www.w3.org/International/articles/ruby/styling.en.ht...
Also, an aside, but it's seldom these days that I see inspirational page design but this page is gorgeous.
At least they were quite inspired for the naming.
::facepalm emoji::
<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
Mention of usage by Yandex: https://yandex.com/support/webmaster/en/controlling-robot/me...
(As for external search engines,FWIR, in its heyday some search engines briefly regarded it quite respectfully, but eventually due to SEO spam they either started to ignore it, or took it as a negative signal, allegedly. But as pointed out in sibling comment, it still survives in Yandex, what is quite surprising plot twist for me.)
Like, it's really no big deal I guess. You were always going to find out this info from sources compiled by other people. But at least don't do the "I'll change some words and call it mine" high school essay plagiarism technique. There was clearly real research done here as well, it's not like it would've been that much harder to write it yourself.
Edit: LLM's used as a context-aware thesaurus called out here... https://vale.rocks/posts/ai-usage#:~:text=Apart%20from%20tho...
source:
> X (formerly Twitter) now falls back to Open Graph tags when twitter:* tags are absent, making the dedicated Twitter Card markup redundant for most use cases.
article:
> X falls back to the widely respected Open Graph meta tags, making the Twitter-specific declarations largely useless.
source:
> The Twitter Card Validator was retired and the original Twitter Developers documentation is no longer accessible.
article:
> 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).
source:
> Twitter's Do Not Track support was effectively dropped following the platform's transition to X. The original Twitter privacy options documentation is no longer accessible, and the signal is not honored in practice.
article:
> Twitter also had a Do Not Track meta tag for opting out of tracking when using Twitter for Websites widgets. Again, the documentation (previously at https://dev.twitter.com/web/overview/privacy) is now inaccessible, and it seems the tag is no longer respected.
source:
> XML-RPC pingbacks have been widely disabled by default due to their use in DDoS amplification attacks. Use Webmention instead.
article:
> They functioned somewhat similarly to how WebMentions do. Unfortunately, pingbacks rather quickly became an avenue for spam and SEO-gaming, so fell out of fashion. Vulnerabilities allowing sites to be tied up in DDoS attacks also became widely exploited.https://html.spec.whatwg.org/multipage/semantics.html#meta-k...
So, it's standardized and not deprecated.
It has this note though:
"Many search engines do not consider such keywords, because this feature has historically been used unreliably and even misleadingly as a way to spam search engine results in a way that is not helpful for users."
HTML 4.01 says the following:
"This specification does not define a set of legal meta data properties. The meaning of a property and the set of legal values for that property should be defined in a reference lexicon called a profile. For example, a profile designed to help search engines index documents might define properties such as "author", "copyright", "keywords", etc."
Note to self: Apparently, I mentally froze around 2009, so I have some decades to catch on. It seems the breaking point was after 2009 Hixie's WONFIX for adding keywords [0], at a time when both `keywords` and `description` were both swept aside into "MetaExtensions" [1]. The turning point I clearly missed came in 2010 [2] and got resolved through [3].
[0] https://lists.w3.org/Archives/Public/public-html-bugzilla/20... [1] https://web.archive.org/web/20090205191845/http://wiki.whatw... [2] https://lists.w3.org/Archives/Public/public-html/2010Feb/016... [3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=7525
Client side image maps and the script element were (AFAICT) both introduced in Netscape 2.
Even when scripting was introduced, you didn't necessarily have the ability to move elements around freely on the page. I think (but I'm not certain) that it wasn't until Netscape 4 era that you had enough layout primitives to implement the multi-layer positioning approach to custom clickable areas.
<div class="image-map">
<img src="funnycats.jpg">
<a
href="cats.html"
style="position:absolute; background: transparent; left: 8.5%; top: 12.5%; width: 59%; height: 87%;"
></a>
</div>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.
Your first point is correct. It could be reasonable to omit initial-scale=1 during development, or have something that complains on width overflow.
Your second is unavoidable: omitting initial-scale introduces a worse failure (excessively small text).
Your third I disagree with: when overflow occurs it will almost always be obvious that you could scroll, because you’ll have text or image that runs to the inline-end edge of the viewport rather than being contained by a page margin as is universally practised.
Your fourth isn’t useful—by that argument all documents should be zoomed out until the entire thing fits on screen; but we don’t do that in general because having to manage the zoom to get a useful result is unpleasant, yet that’s what you’re advocating for.
Your fifth is irrelevant, I think entirely unrelated to initial-scale.
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.
> People often pair initial-scale=1 with overflow-x: hidden in their CSS […]
(That one in particular really seems like a strawman.)
Spotted under PPK's share <https://front-end.social/@ppk/117201706620768380>