link-preview-brainstorming: Difference between revisions
Jump to navigation
Jump to search
(→proposals: expand proposal to include specific other types of body objects) |
m (-=) |
||
(One intermediate revision by the same user not shown) | |||
Line 9: | Line 9: | ||
== proposals == | == proposals == | ||
General | General approaches: | ||
* | === publishing === | ||
* | * In general: use [[h-entry]] on the <code><body></code> element with a few additions like <code>u-photo</code>, <code>u-audio</code>, <code>u-video</code> | ||
* Use [[h-card]] for pages of people or organizations, | |||
* [[h-product]] for product pages | |||
* (or whatever top level object the page represents) | |||
=== parsing === | |||
Using a [[microformats2]] parser, look for the first <code>h-*</code> on the page and use its: | |||
* p-name (called "title" in some other approaches) | |||
* p-summary (called "description" in some other approaches) | |||
* u-url | |||
* u-photo (called "image" in some other approaches) | |||
* u-audio | |||
* u-video | |||
Existing link preview schemes allow differentiating the "page name" from the "site name," such as OpenGraph's <code>og:site_name</code>/<code>og:title</code> and Twitter Cards's <code>twitter:domain</code>/<code>twitter:title</code>. Is this worth investigating? | Existing link preview schemes allow differentiating the "page name" from the "site name," such as OpenGraph's <code>og:site_name</code>/<code>og:title</code> and Twitter Cards's <code>twitter:domain</code>/<code>twitter:title</code>. Is this worth investigating? | ||
Line 29: | Line 32: | ||
* A "site microformat" may scratch the itch of those who like putting up invisible rel=author and similar data, allow for explicit site-wide legal disclaimers vs. page-level (like Tumblr's policies vs. the content its users copyright on their blogs on a tumblr subdomain), site-wide tags/categories, and other various publisher vs. author distinctions. | * A "site microformat" may scratch the itch of those who like putting up invisible rel=author and similar data, allow for explicit site-wide legal disclaimers vs. page-level (like Tumblr's policies vs. the content its users copyright on their blogs on a tumblr subdomain), site-wide tags/categories, and other various publisher vs. author distinctions. | ||
Examples in the wild | == Examples in the wild == | ||
Examples on the web of pages with h-entry on body: | |||
* http://www.w3.org/TR/2013/WD-css-counter-styles-3-20130221/ | * http://www.w3.org/TR/2013/WD-css-counter-styles-3-20130221/ | ||
** see parsed version: http://microformat2-node.jit.su/?url=http%3A%2F%2Fwww.w3.org%2FTR%2F2013%2FWD-css-counter-styles-3-20130221%2F&callback=&filters= | ** see parsed version: http://microformat2-node.jit.su/?url=http%3A%2F%2Fwww.w3.org%2FTR%2F2013%2FWD-css-counter-styles-3-20130221%2F&callback=&filters= | ||
* ... | |||
== see also == | == see also == |
Latest revision as of 01:24, 8 December 2016
This article is a stub. You can help the microformats.org wiki by expanding it.
This is part of an effort to define a standard link-preview microformat.
- link-preview-examples
- link-preview-formats - document from Facebook/OG, Google/G+, IE10, Twitter Cards
proposals
General approaches:
publishing
- In general: use h-entry on the
<body>
element with a few additions likeu-photo
,u-audio
,u-video
- Use h-card for pages of people or organizations,
- h-product for product pages
- (or whatever top level object the page represents)
parsing
Using a microformats2 parser, look for the first h-*
on the page and use its:
- p-name (called "title" in some other approaches)
- p-summary (called "description" in some other approaches)
- u-url
- u-photo (called "image" in some other approaches)
- u-audio
- u-video
Existing link preview schemes allow differentiating the "page name" from the "site name," such as OpenGraph's og:site_name
/og:title
and Twitter Cards's twitter:domain
/twitter:title
. Is this worth investigating?
- The
<title>
element usually features both, and sometimes a tagline. It's invalid to nest tags inside of it, so breaking it down is probably a bad idea. - The actual "domain name" should be easily computable, but the site name is often different. For example, multiple word names.
- The site name is usually marked up in a nice heading somewhere, so it should be trivial to attach another class name to it.
- A "site microformat" may scratch the itch of those who like putting up invisible rel=author and similar data, allow for explicit site-wide legal disclaimers vs. page-level (like Tumblr's policies vs. the content its users copyright on their blogs on a tumblr subdomain), site-wide tags/categories, and other various publisher vs. author distinctions.
Examples in the wild
Examples on the web of pages with h-entry on body: