Both Mastodon and Tumblr have microformats support built in. Twitter and Facebook used to, but they decided they'd rather be silos than protocols
Microformats Wiki
21–30 of 69 posts
Re: Microformats Wiki
#22I don't get it. The big problem with the old meta tags is that nobody follows standards[1], and they were frequently abused to misrepresent the document in a favorable way (especially keywords and description). How would this help alleviate those problems? [1] To this day. I've learned, from building a parser for my search engine, you can't just select the tag if you want the title of a page. You need to select the t…
I think these things are very related, but Microformats isn't going to solve this problem on its own. After all, it's been around for quite a while, just like most of these conventions. 10-15 years ago, we had a bunch of different ways everyone was trying to schematize their data on the web, and since we never all agreed to just use one of them, everyone now uses fragments of all of them — and of other pseudo-proprie…
Indeed - every silo wants you to use their own specific markup, but even then they choose what to show. I made a post a while back that gave a different summary on every silo platform https://www.kevinmarks.com/partialsilos.html
Of course, since then some of the silos have died or given up on their own systems, but microformats remains useful if you want to co-operate.
Re: Microformats Wiki
#23Earlier quoted context omitted.
Plus tag is valid in SVG context, where it does what `title` attribute does on HTML elements (provides content for HTML tooltips and screen readers). And since inline SVG is valid in HTML, you can get valid title tags (from SVG namespace) outside HEAD element Plus if there wasn't TITLE in the head and is encountered inside BODY (not valid), it is adopted into the HEAD from document object model's perspective as if it…
You complicate the description and make it sound much harder than it actually is. Concerning HTML parsing in general: it is easy, genuinely easy, one of the easier things to implement, because it’s well-defined , and in a format that matches the implementation. You’re basically just translating the algorithm from pseudocode into code. Sure, it’s long, but it’s not hard. and being optional is purely a parser concern,…
I'm not sure if I follow your line of thoughts correctly. I agree that yes, HTML parsing is well defined in current standard, but (subjectively, for me) it is far from "easy", given the amount of states and back-compat "burden" with plenty of often overlooked exceptions. (I like to explore them but I'd never try to make a compliant HTML parser from scratch, probably.)
I was in fact responding to
> […] I've learned, from building a [HTML] parser […] you need to select the title tag in the -tag.
what gave me impression OP really rolls his own HTML parser and relies on some possibly dangerous assumptions that are not in fact granted (however well defined) by the specs — for me one of such assumption is especially "HTML parsing is easy" / "I understand HTML well enough to parse it myself" — and wanted to point out possible further gotchas wrt "selecting the -tag" (e.g. that it may be hard when there is no tags) or that "selecting the first title tag" could possibly not give the right one.
But maybe I'm just little slow and all those "Idiosyncrasies of the HTML parser" [1] are notoriously known. And sure, many scenarios could be waved out as unimportant border-cases, maybe.
---
As for querying the document, i.e. having the state when the document is ready and "something" did the parsing and tree heavy lifting for us (so we have DOM and JS) we can surely reach for ancient namespaced
document.getElementsByTagNameNS("http://www.w3.org/1999/xhtml", "title")[0]?.textContent?.trim()
---
Re: Microformats Wiki
#24Google prefers JSON-LD though[0]. Also I'm not keen on defining content with styling classes. [0] https://www.searchenginejournal.com/google-structured-data-p...
The class attribute isn't just for styling though. See https://html.spec.whatwg.org/multipage/dom.html#global-attri... > authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content.
TIL! So those obnoxious JavaScript frameworks using classes for declaring logic are actually valid???!!
Re: Microformats Wiki
#25Earlier quoted context omitted.
You complicate the description and make it sound much harder than it actually is. Concerning HTML parsing in general: it is easy, genuinely easy, one of the easier things to implement, because it’s well-defined , and in a format that matches the implementation. You’re basically just translating the algorithm from pseudocode into code. Sure, it’s long, but it’s not hard. and being optional is purely a parser concern,…
I'm not sure if I follow your line of thoughts correctly. I agree that yes, HTML parsing is well defined in current standard, but (subjectively, for me) it is far from "easy", given the amount of states and back-compat "burden" with plenty of often overlooked exceptions. (I like to explore them but I'd never try to make a compliant HTML parser from scratch, probably.) I was in fact responding to > […] I've learned, f…
To implement an HTML parser, you don’t need to worry about the corner cases at all, because the spec has your back and spells out exactly how every single case should be handled, in the form of state machines, which is how you will implement it. There are involved details, to be sure, but it’s genuinely not hard to follow the spec. The idiosyncrasies document you cite is for authors of HTML: implementers genuinely don’t need to worry about them, because it’s all covered by the spec.
For document.title: naturally in a browser you would use that; I intended to describe just how you would achieve it without that. And I completely forgot about document.getElementsByTagNameNS for some reason, which is of course more sensible than a querySelector + find. Note that .textContent.trim() doesn’t match the algorithm which is spelled out in the spec (just below the earlier link), on two counts. Firstly, all sequences of ASCII whitespace in the middle of the string need to be collapsed to a single space ("\r\n\f\t hello\r\n\f\t world\r\n\f\t " → "hello world"). Secondly, .textContent is insufficient, including the text content of element children as well, whereas the spec says child text content (with a link to the exact definition); HTML syntax can’t produce such elements (the parser switches into RCDATA state), but XML syntax can, as can DOM manipulation by scripting. Examples that are both titled “included” rather than the textContent “inclexcludeduded”:
data:application/xhtml+xml,inclexcludeduded
data:text/html,incldocument.querySelector("title").append(b=document.createElement("b"),"uded"),b.append("excluded")Re: Microformats Wiki
#26Google prefers JSON-LD though[0]. Also I'm not keen on defining content with styling classes. [0] https://www.searchenginejournal.com/google-structured-data-p...
The class attribute isn't just for styling though. See https://html.spec.whatwg.org/multipage/dom.html#global-attri... > authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content.
> values that describe the nature of the content
vs
> rather than values that describe the desired presentation of the content.
Or could it be that the meaning here is that you should write descriptive classes such as 'alert-box' instead of 'red-box'.
Re: Microformats Wiki
#27PSA: the best way to enable Microformat-like stuff with almost no effort is to keep describing content with reasonable class names even if you never pay any special attention to the microformats.org standards. One unfortunate side effect of things like Tailwind CSS is that some folks with a single-minded focus on looks are now using only the Tailwind class names, but you can do both. If before you'd have written some…
I'd argue that using the `class` attribute for describing the content of a field is overloading it, and that it should only be used for linking to CSS styles.
You're better off using another attribute, e.g. some data-* attribute, for semantic information.
Re: Microformats Wiki
#28PSA: the best way to enable Microformat-like stuff with almost no effort is to keep describing content with reasonable class names even if you never pay any special attention to the microformats.org standards. One unfortunate side effect of things like Tailwind CSS is that some folks with a single-minded focus on looks are now using only the Tailwind class names, but you can do both. If before you'd have written some…
I'd argue that using the `class` attribute for describing the content of a field is overloading it, and that it should only be used for linking to CSS styles. You're better off using another attribute, e.g. some data-* attribute, for semantic information.
The HTML Standard disagrees:
> […] authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content.
[*]: https://html.spec.whatwg.org/multipage/dom.html#global-attri...
Re: Microformats Wiki
#29It's worth noting Microformats is introduced 17 years ago, and was last updated about 12 years ago. It never really picked up traction, largely because players like Google have their own knowledge graph, and similar structured formats like RSS have lost their popularity since then.
SEO was always a good argument to adopt some of the microformats. Search engines can make use of that to pick apart content. It's just that we have a few more tools than just microformats for that now; including some structural html 5 tags.
What died out is attempts to do stuff with microformats via browser extensions. This was once a thing that e.g. MS did when they launched Edge. Those extensions have largely disappeared or just never really caught on.
Re: Microformats Wiki
#30PSA: the best way to enable Microformat-like stuff with almost no effort is to keep describing content with reasonable class names even if you never pay any special attention to the microformats.org standards. One unfortunate side effect of things like Tailwind CSS is that some folks with a single-minded focus on looks are now using only the Tailwind class names, but you can do both. If before you'd have written some…
Is there any evidence this matters at all?