oEmbed v2

[Samin Shams]

oEmbed v1 was written in what, 2008?
I'm I the only one who feels that maybe the authors should start thinking of a version 2 of the specification, taking in all the suggestions given in this group in the past 3 years?

I mean, seeing that the web is now moving into html5 and open standards for media files, maybe a new specification could be written taking that into account. It feels like the authors have given up on keeping this an active community and I'm sure companies like Embed.ly and many consumers such as myself are still very interested in making this a tool as fitting to the web as possible.

Who's with me?

[John Pettitt]

We (http://repost.us) would be very interested in working on this - particularly issues relating to variable size embeds.

John

> --
> You received this message because you are subscribed to the Google Groups "OEmbed" group.
> To post to this group, send email to oem...@googlegroups.com.
> To unsubscribe from this group, send email to oembed+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/oembed?hl=en.

John Pettitt
Email: j...@p.tt

[schuyler]

I'd be interested in:
1) standardizing where/how to include extra metadata
2) a way to describe javascript APIs for media embeds
(play,pause,getTime,seek,onready,...)

/sky (from http://ccnmtl.columbia.edu)

[Sean Creeley]

Embedly would love to participate in this. It will give us the ability
to add an `audio` type that has been missing for ages.

Let me know what your proposed next steps would be.

Thanks for proposing this!

Sean

Co-Founder at Embedly

[Samin Shams]

I'm glad others also feel this need.

I might be off track, but here are some of my musings:

1) An official callback parameter would be nice.

2) The three most used media types on the web are: image, video and
audio.
There are two main ways to display them in a browser: 1) portions of
HTML or Javascript (very particular to the provider); 2) Source files.
Images, ever since Mosaic, have always been embedded as source, and
since all browsers support it, no one felt the need for a workaround
like HTML, Flash, etc. There are however formats such as SVG that are
purely XML and can be inlined in the browser.
Videos and audios have only recently been embedded as source with the
introduction of HTML5. Before that, we had the famous Flash players
and obfuscated sources.
This is the current way to deal with different formats:
http://tmp.qiknr.com/files/media_scenario.png (correct me if this is
in someway wrong and keep in mind that the <video> and <audio> tags in
HTML5 allow fallbacks).


So the question is: how do you specify something that incorporates all
of these variables? Any ideas?

[alex kessinger]

I think it would be cool to be able to define embedable blocks of HTML.

[Brion Vibber]

On Thu, Apr 28, 2011 at 6:25 PM, schuyler <schuy...@gmail.com> wrote:

I'd be interested in:
1) standardizing where/how to include extra metadata
2) a way to describe javascript APIs for media embeds
(play,pause,getTime,seek,onready,...)

I would be very happy to see a clean, well-defined iframe embedding interface with such JavaScript APIs.


The biggest problem I saw using oEmbed for thumbnails and embedding in StatusNet was that we had to scrub HTML for security, making direct HTML embedding for things like videos useless as all the actual code would get lost.

If we can instead get a width, height, and a URL to load via an <iframe>, then we can safely pull it in without a cross-site scripting danger: the iframe's content is isolated.

This also helps with dynamic content which may change over time, or where playback technologies get changed -- if the embedding URL remains stable, its contents could change in the future (say from a Flash embed to a <video>) without cached embedding information going stale.


An embedding API (which can get very good modern cross-browser support using window.postMessage) with start/stop, time updates, etc could allow for arbitrary video sources to be used in tools like universalsubtitles.org (I am not affiliated with them but I have a subtitled video on there, and it's quite fun!)

I would be very interested in implementing a compatible future-oEmbed provider for MediaWiki, which we can then put on Wikimedia Commons and Wikipedia. Clean <iframe> embedding gives us the flexibility to use whatever web technologies we want for the actual playback, without forcing clients to recache embedding information when technologies change.


As a potential consumer of embedded content, MediaWiki-based sites would also benefit greatly from a standard location for copyright licensing metadata.

-- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
Lead Software Architect
Wikimedia Foundation

/sky (from http://ccnmtl.columbia.edu)

On Apr 28, 8:31 pm, Samin Shams <saminsh...@gmail.com> wrote:
> oEmbed v1 was written in what, 2008?
> I'm I the only one who feels that maybe the authors should start thinking of
> a version 2 of the specification, taking in all the suggestions given in
> this group in the past 3 years?
>
> I mean, seeing that the web is now moving into html5 and open standards for
> media files, maybe a new specification could be written taking that into
> account. It feels like the authors have given up on keeping this an active
> community and I'm sure companies like Embed.ly and many consumers such as
> myself are still very interested in making this a tool as fitting to the web
> as possible.
>
> Who's with me?

[Geoff Stearns]

I have some thoughts here that I thought I'd add to this discussion before the spec balloons with new features:

- Embedding random html and javascript is dangerous

- We all agree that using an iframe to sandbox potentially dangerous content from a site is a best practice, especially when dealing with javascript and even Flash objects

- Many providers already provide iframe embeds, some with apis[1]

- Why not encourage best practices and simplify oEmbed at the same time by requiring iframes whenever the content is not an image (and maybe Flash if you feel strongly about that)?

Requiring iframes would also put the responsibility of fallback content on the provider, as well as keep the content fresh in cases where the oEmbed consumer doesn't refresh the data for long periods of time.

I'm all for providing API information in the response, that sounds very helpful assuming it can be done in a universal way to handle all the various API implementations.

[1] YouTube's "experimental" iframe API: http://code.google.com/apis/youtube/iframe_api_reference.html

[schuyler]

I don't think we should be defining javascript APIs in oEmbed -- best
practice APIs for these media are being developed by the HTML5 group
(see e.g. <video> tag API).

The point is to document APIs to legacy flash players, etc. As the
spec says, embedding the 'html' value's content is best done in a
separate <iframe> to protect against such things.

To be more specific, a sample JSON implementing both proposals might
be:
{
"type":"video",
"version":"2.0",
"width":425,"height":344,
"metadata":{
"tags":["foo","bar","baz"],
"description":["This is the description, just like a
dc:description."]
},
"html":"<object width=\"425\" height=\"344\">
<param name=\"movie\" value=\"http://www.youtube.com/v/
M3r2XDceM6A&fs=1&enablejsapi=1\">
</param>
<param name=\"allowFullScreen\" value=\"true\"></param>
<param name=\"allowscriptaccess\" value=\"always\"></param>
<embed src=\"http://www.youtube.com/v/
M3r2XDceM6A&fs=1&enablejsapi=1\"
type=\"application/x-shockwave-flash\" width=\"425\" height=\"344\"
allowscriptaccess=\"always\" allowfullscreen=\"true\"></embed>
</object>",
"javascript_api":{
"call":"object"
"onready_call":"onYouTubePlayerReady",
"duration":"getDuration",
"play":"playVideo",
"pause":"pauseVideo",
"seekable":true,
"seek":"seekTo",
"currentTime":"getCurrentTime"
}
}

For another resource, the ['javascript_api'].call might be
"postMessage" which would work for <iframe> apis.

I think more thought should go into these fields and how they work to
get a balance between accomodating all the different APIs out there,
and simplicity.

cheers,
sky


On Apr 29, 3:10 pm, Brion Vibber <br...@pobox.com> wrote:

> > /sky (fromhttp://ccnmtl.columbia.edu)

[schuyler]

As much as I'd love everyone to move to <iframe> objects and APIs I
think oEmbed's value is in documenting what's out there. Even
YouTube's iframe html embed would require something like this:
"html":"<iframe id="player" type="text/html" width="640" height="390"
src="http://www.youtube.com/embed/u1zgFlCw8Aw?
enablejsapi=1&origin=example.com"
frameborder="0">
<script async="true" src="http://www.youtube.com/player_api"></
script>
"

Note the <script> tag's requirement. Obviously they don't *have* to
do it that way....

Embedders can then decide whether to run the insecure javascript or
only support the API on certain providers or when there's an
iframe.postMessage() api described

cheers,
sky

> >http://tmp.qiknr.com/files/media_scenario.png(correct me if this is

[Brion Vibber]

On Fri, Apr 29, 2011 at 12:56 PM, schuyler <schuy...@gmail.com> wrote:

I don't think we should be defining javascript APIs in oEmbed -- best
practice APIs for these media are being developed by the HTML5 group
(see e.g. <video> tag API).

The point is to document APIs to legacy flash players, etc.  As the
spec says, embedding the 'html' value's content is best done in a
separate <iframe> to protect against such things.

Embedding an arbitrary HTML chunk into an offsite <iframe> isn't trivial; it requires the consuming web app to be able to control a second domain to put that content on. This isn't a huge burden for large sites, but for smaller sites (say, someone's personal blog or a small wiki running on shared hosting) it's not a practical requirement.

Being given a URL from the provider's site is something that anyone can drop into an <iframe> with no extra effort, so it'll work on large consumers, small consumers, and developers' workstations.

For instance we might expose a Wikimedia Commons video like this:

{

  "type":"video",
  "version":"2.0",

  "width":300,
  "height":255,
  "thumbnail_url":"http://upload.wikimedia.org/wikipedia/commons/thumb/f/f7/Barron_Falls_in_Flood.ogv/mid-Barron_Falls_in_Flood.ogv.jpg",

  // Providing an iframe URL means that any consumer can safely embed it
  "iframe": "http://commons.wikimedia.org/wiki/File:Barron_Falls_in_Flood.ogv?withJS=MediaWiki:MwEmbed.js&embedplayer=yes",

  // Fallback content for oembed 1 consumers, which in this case is just the same iframe.
  // Consumers without the ability to run multiple domains can only use this data safely
  // by scrubbing out scripts and plugins, which would break Flash players.
  "html": "<iframe src=\"http://commons.wikimedia.org/wiki/File:Barron_Falls_in_Flood.ogv?withJS=MediaWiki:MwEmbed.js&embedplayer=yes\" width=\"300\" height=\"225\" frameborder=\"0\" ></iframe>",

  // We're going to need standardish ways of doing this.
  "metadata": {
    "source": "http://commons.wikimedia.org/wiki/File:Barron_Falls_in_Flood.ogv",
    "copyright": "http://en.wikipedia.org/wiki/Public_domain",
    "author": "http://commons.wikimedia.org/wiki/User:Lepidlizard"

[alex kessinger]

Concern for embedding random JS, and HTML is warranted, but as others
have suggested I think it could be up to the embedder if they want to
use HTML or not.

If an embedder wants to try, and style content to look like other
content on the site then an iframe wouldn't work.

[Brion Vibber]

On Fri, Apr 29, 2011 at 1:51 PM, alex kessinger <void...@gmail.com> wrote:

Concern for embedding random JS, and HTML is warranted, but as others
have suggested I think it could be up to the embedder if they want to
use HTML or not.

If an embedder wants to try, and style content to look like other
content on the site then an iframe wouldn't work.

*nod* For backwards compatibility with older consumers we'd still need the 'html' chunk, so that choice could be retained.

I think this would only be relevant though when embedding freeform rich text, like an extract of an article or blog entry... In my usage the embedded content is usually an opaque rectangle filled with a photo or video, and any UI elements within it are beyond the surrounding web page's control.

It may be worth thinking about whether the 'rich' content type is sufficiently specced; there's probably a big difference between handling "a chunk of rich text" and something like an interactive map or diagram such as you'll often find on news and educational sites. I expect to be adding more such features to Wikipedia in the future and would love to make them easily embeddable without increasing the security risks for consumer sites, which makes <iframe> embedding ideal.

On the current spec, the 'rich' type requires width and height, which to me points more towards the interactive diagram sort of thing than freeform text, which can't really be assigned a fixed pixel height... iframes of course require an explicit height. (You can dynamically resize an iframe to try to fit its content, but only if you can access the frame content, so it can be pretty tricky cross-site.)

[Daniel Friesen]

Having both the option of using an iframe from a listed url, or
embedding html into an iframe yourself is good. And I know it will
likely be the only option for things like YouTube or other sites that
want to DRM their media or embed flash ads. But where possible I'd
actually like the option of having a list of video sources, with their
format, so that as the embedder I can handle the video player myself.
With the ability to properly do html5 video with fallbacks myself.

"source": [
{ "type": "video/mp4", "src": "http://example.com/video.mp4" },
{ "type": "video/webm", "src": "http://example.com/video.webm" }
]

Naturally as a 3rd option, in addition to html and iframe.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://
daniel.friesen.name]

On Apr 29, 2:22 pm, Brion Vibber <br...@pobox.com> wrote: