- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Wed, 13 Apr 2011 13:49:49 +0300
- To: Danny Ayers <danny.ayers@gmail.com>
- Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Leonard Rosenthol <lrosenth@adobe.com>, public-html@w3.org
On Wed, 2011-04-13 at 12:01 +0200, Danny Ayers wrote: > > 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. If the scenario is that someone puts a image with metadata on a server and without the author doing anything else, the browser can alert the user about stuff, then it's about a built-in browser feature that doesn't have expose anything to JS. If the scenario is that someone puts an image with metadata on a server *and* supplies a JavaScript program that uses DOM/HTML, canvas or SVG to alert the user about the metadata, the author controls both the image and the alert mechanism, so the author might as well extract the metadata on the server side (like e.g. Flickr does) and transfer the extracted data to the browser using whatever existing means. The server is a notable part of a Web app. I don't think it is a useful goal to seek to move everything to the browser side. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Wednesday, 13 April 2011 10:50:23 UTC