link-previewThis article is a stub. You can help the IndieWebCamp wiki by expanding it.
WhyConsider showing a link-preview so your reader has some expectation of what they're going to get when they click a link. HowBy using an auto-embed function (like the CASSIS "auto_link" (not a typo) function), you can provide inline embedded images and videos in your plain text notes that have links. indieweb approachesA few indieweb sites are figuring out how to better support embedding:
Silo ExamplesVarious social network silos (e.g. Facebook, Twitter, Google+) show link previews underneath notes and comments that have one or more URLs, by extracting information from those URLs content and showing a title/summary/photo for those URLs underneath the posted note/comment. Facebook uses OGP from the first link in a post, e.g.: [1]
Facebook has a number of guidelines regarding images in their documentation: They show different link-preview layouts for images of different resolutions!
There are third-party guidelines that does not follow Facebook's own though:
Google+Google+ uses an assortment of microformats/meta/schema/OGP+ Pinterest uses OGP + Schema.org for their "Rich Pins" Twitter uses their own white-list-domain limited meta + OGP AKA "Twitter Cards" on the last link in a tweet, e.g.: [3] As of (2015?) Twitter *does* support showing a link-preview of a tweet link, e.g. https://twitter.com/t/status/520758106838818816 (they previously didn't) However, Twitter fails to show a link-preview for many links, resulting in odd link-only cross-posts from Facebook, where presumably the author did see a link-preview (because Facebook looks at far more information for the link-preview than Twitter does) SlackThey call creating link previews “unfurling” a URL. They support oEmbed and OGP (including twitter extensions), as documented in this blog post. ...
prior link preview standardsThere have been a couple of open standards created explicitly for information for link previews.
See http://microformats.org/wiki/link-preview-formats for more prior art research. simple link preview standardh-entry is a useful building block for this. E.g.
For more details towards the development of a simple link preview standard, see: brainstormingfeatured imageBeyond h-entry's existing properties, there may be a need for additional properties to satisfy the same use-cases as documented by the "existing silo support" above. E.g. most commonly, a thumbnail image to put next to a post, or rather as a publisher to provide a thumbnail / representative / featured image for others to display as part of a link-preview. WordPress has good prior art here: http://codex.wordpress.org/Post_Thumbnails:Post Thumbnail, now Featured Image, is an image that is chosen as the representative image for Posts, Pages or Custom Post Types. The display of this image is up to the theme. This is especially useful for "magazine-style" themes where each post has an image.Emphasis and emphasis added. u-featuredThus we can learn from the WordPress's experience and go with their naming of "Featured Image" - although we can simplify that - why limit to an image when some may (and do!) want to feature a video, or an audio playback stream, etc. as demonstrated by the variety of Twitter Cards? Thus we can introduce a "featured" property for this use-case, expected to be used as a "u-featured" property inside an h-entry that is a URL to the asset to feature for that post. Handling of different types is up to the link-preview displaying client. E.g. it could do different things based on implementation wishlistIt seems like an indieweb implementation of a "link preview" feature would need:
Utilities:
See Also |



















