There’s more than one HTML element designed to hold metadata.AnyHTML element can hold metadata with HTML+RDFa, but for the context of this article I’ll focus on the HTML-standard
element. It’s used to build link relations between documents and resources.
You’ll benefit from having read “Facebook和Twitter为什么这么糟糕at parsing RDFa metadata?” for context before reading this article. However, it’s not a requirement to get something out of this one.
I’d like to set the stage and introduce this topic with a quick recent-history lesson before I get into the difference between
elements and why URLs don’t belong in the former.
It was decided in the early days of the social web that sharing plain dull looking URLs wasn’t the most enticing customer experience. Good metadata would be key to deliver a better customer experience with detailed and image-rich previews of externally linked webpages. Existing metadata schemas had failed to see much adoption as there hadn’t been many immediate benefits to properly labeling webpages until that time.
“This wasn’t invented here!” said the engineers of Facebook, Twitter, VK, Weibo, and other companies upon seeing existing metadata schemas like the Dublin Core Schema or even Microformats. Instead of urging for the adoption of one of the existing metadata schemas, they all reinvented the wheel and introduced Open Graph Protocol by Facebook, Twitter Card, VK for Publications, Weibo Meta Tags, and similar proprietary metadata schemas. They then asked web publishers to implement and include all of these mostly overlapping in their webpages.
Web publishers were on board with the new schemas as it meant they’d get higher click-through rates from the rapidly growing social media platforms. Half a decade later we’ve seen some consolidation behind Facebook’s Open Graph Protocol as Twitter Cards and Weibo Meta Tags finally saw the benefits of using a single metadata schema instead of insisting on everyone else adopting their pages to suit the platforms.
What all of these companies got wrong independently was their URL data type, used for properties like “url” and “image” to reference the canonical location of the current URL and the location of a representative image. All of these schemas expressly stated that these should be given as string literals instead of URLs.
As an example, here’s the canonical page URL expressed using Open Graph Protocol:
This seems simple enough and is often seen along with other tags like
og:description. However, all the major search engines had agreed to use link-rel canonical to represent the exact same concept 14 months before Facebook’s introduction of the Open Graph Protocol.
Webpages now had to express their canonical URLs in two different ways:
So what’s the difference between these two objects (other than the vocabulary used to label them)? It comes down to data types: the
element is just a string literal whereas the
is a link. A link is aware of the base URL and any base URL overrides like the
元素,处理相对路径,并且使th规范化e link. A string is literally just a string.
element compared to a
You’ll notice the need to expressly convert the string returned from the
element to a URL object, manually specifying the base URL from the
element or by falling back to the current
, and then back to a string from simply reading the
It’s not just a semantic difference as its clearly better to get link type data from an element that natively understands the data type. The semantic difference between these two data types also becomes clear when parsing the document for Linked Data or as an HTML+RDFa document.
You also need to have perfect preexisting knowledge about the data in the element to know that you’re expecting to get from an URL from this one specific
element; compared to having the language level assurance of always getting a URL from the
The following example demonstrates combining the two separate elements discussed in this article into one element with as an HTML native link. This is useful if you want to minimize the elements needed to express identical metadata labels or you want to minimize the document size.
Unfortunately, the above example isn’t supported by either Facebook or Twitter who seem touse regex-parsing instead of RDFa parsingdespite both pushing a HTML+RDFa vocabulary standard. The above example is supported by the Bing and Google Search who parses RDFa as RDFa.
The point of this article was to argue for using
elements to express URLs. I can’t recommend that anyone change their Open Graph implementations to use them instead of
elements as that would probably cost you any benefit from including it in your documents. (Again due to the social platforms incredibly poor document parsers.) However, I’m hoping to have convinced you to not design your metadata schemas or parser to be as stupid as Facebook’s.