W3C home > Mailing lists > Public > public-html@w3.org > July 2010

Re: HTML Media Capture draft from Device APIs and Policy Working Group

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Thu, 22 Jul 2010 09:54:47 +0200
To: Jonas Sicking <jonas@sicking.cc>
Cc: Henri Sivonen <hsivonen@iki.fi>, "public-html@w3.org WG" <public-html@w3.org>, public-device-apis@w3.org
Message-ID: <1279785287.2282.991.camel@localhost>
Le mercredi 21 juillet 2010 à 11:18 -0700, Jonas Sicking a écrit :
> The MediaList interface is unnecessary. The Files returned from the
> FileList interface can implement the MediaFile. Compare to how
> NodeList interface always returns Node objects, but that those Node
> objects often also implement Element or TextNode.

Good point, I've removed the MediaList interface, and amended the spec
to read:

> It's good that the 'capture' mime parameter is defined to be a hint
> and isn't required to affect behavior in any way. It's still unclear
> that it is really needed. A good browser UI should likely *always*
> display buttons for attaching a file or capturing a new image or video
> using a camera. That is what we are long term hoping to do for firefox
> since the vast majority of pages don't have an @accept attribute at
> all. If an implementation want to be conservative and not always
> display a button for capture, triggering off of @accept containing a
> "image/..." mimetype seems reasonable.
> 
> Why is MediaFile defined to only be implemented on Files captured
> using a device? Why not also allow it to be implemented by files that
> reside on the users file system?
> 
> It's probably a good idea to make the FormatData accessor
> asynchronous. Otherwise implementations are required to read all such
> data into memory every time a MediaFile is instantiated.
> 
> / Jonas
> 
> 
Received on Thursday, 22 July 2010 07:54:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:10 GMT