- From: Danny Ayers <danny.ayers@gmail.com>
- Date: Wed, 13 Apr 2011 12:01:29 +0200
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Leonard Rosenthol <lrosenth@adobe.com>, public-html@w3.org
On 13 April 2011 11:24, Henri Sivonen <hsivonen@iki.fi> wrote: > On Wed, 2011-04-13 at 10:56 +0200, Danny Ayers wrote: >> On 13 April 2011 09:11, Henri Sivonen <hsivonen@iki.fi> wrote: >> > On Tue, 2011-04-12 at 10:50 +0200, Danny Ayers wrote: >> >> - looking for a hotel, a browser on a mobile device could use the geo >> >> coords stored in the Exif of a photo to direct the user to the actual >> >> location of the photo >> >> - looking at a set of conference photos, the browser could alert the >> >> user: "hey, that's your friend in the photo!" >> > >> > These use cases would require the browser to be able to extract the >> > location or person metadata and to have UI for directing the user to the >> > location of the photo or to alert the users about the people in the >> > photo. >> >> Right. >> >> > Neither use case (as stated) requires exposing this information to >> > author-supplied JavaScript programs through an API. >> >> How else might you do such things? > > By the browser having built-in features that trigger on certain metadata > without any page author-provided JS being involved. > >> Or are you suggesting I expand the >> descriptions to show how the Javascript might operate? (If that's the >> case I'll be happy to oblige once I've had some morning coffee...). > > As far as I can tell, the use cases you included called for browser UI > features--not for an API. I don't think so...the UI parts for directing someone to a hotel or alerting them to something in a photo could be handled by regular DOM/HTML, <canvas> or SVG. The only bit that can't easily be fulfilled right now is access to the metadata. > Frankly, I get a feeling that the API idea is looking for a problem to > solve here. Ok, I can see how it might seem that way, and I do need to come up with some compelling use cases. I anticipate two problems with doing this: firstly, because historically object metadata is hard to access from the browser context, there won't have been /that/ much work done in the area already, it's fairly blue sky. On the other hand, the main thing I'm proposing is a rationalization of what may already be possible (but difficult), so many use cases could already be fulfilled by other means. As an analogy, it is possible to dig a hole using your bare hands or a stick, but to get any decent agriculture going you really need a plough. When the browser encounters an object like an image or a video, it might well have the smarts to be able to display the image or play the video, and the developer can have access to the controls. But as far as the metadata is concerned, the object is an impenetrable black box (unless you jump through custom handler hoops) *even though* the core functionality needed to expose the metadata is probably available. This seems an arbitrary and unnecessary limitation of HTML. Cheers, Danny. -- http://danny.ayers.name
Received on Wednesday, 13 April 2011 10:02:01 UTC