Well from the (incomplete, as turned out) info I gathered it turned out that it was never standardised to begin with (unlike meta description, for example), so it did not even have to be "deprecated". (Like it ever meant something in the real world…) I am definitely for any obsolete mischief, so it brings me joy hearing there is vernacular continuity!
(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.)
"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."
Ha, I stay corrected! Crawling back under rock to re-read WHATWG and historical W3C docs to fill the voids…
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].
It's normal for it to appear denser vertically. Your example of increased line height looks suitable for subheadings, but in no way represents the typographic tradition of its use.
"Michael Hart's email messages and blog posts had equal line length paragraphs in monospaced font: he chose the wording in such a way that each line had the same number of characters."
It probably used pixel-by-pixel conversion (decode input format -> encode output format), which is lossy, not the libjxl native way to convert JPEG (it needs to know about the original JPEG data, not the raw image data).
A warning about openbsdhandbook[.]com - this website has completely incorrect information for some things. Like hallucinated, even though I think it was created before LLMs.
For BSD (especially OpenBSD) you can pretty much just use the man pages and the online FAQ. They are really good.
If you want a book, Absolute OpenBSD is good though a bit out of date now. A lot of it would still be applicable though, if backed up by the current man pages.
Reading undeadly.org is a another good way to keep up on developments.
Dang, I didn't know that. I thought it was decent enough to get people exposed to doas(1), pkg_add(1), syspatch(8), etc... from which they could then read the man pages.
Thanks for pointing this out and I appreciate the other recommendations in this thread. Massive +1 for @jcs. That dude is awesome and puts out great stuff.
I recently learned that Russ also wrote software for The On-Line Encyclopedia of Integer Sequences (https://oeis.org) and is the president of the OEIS Foundation.
reply