- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Thu, 22 Jul 2010 09:58:43 +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
(re-sending, sorry for the previous mis-sent)
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.
> 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?
>
Good points, I've removed the MediaList interface and amended the text
to read:
If the user selects files of whose MIME types match image/*,
sound/*, or video/* (on the filesystem or via a successful media
capture), the relevant files in the files attribute [HTML5] must
implement the MediaFile interface.
> 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.
So, you're suggesting an asynchronous MediaFile.getFormatData() rather
than the MediaFile.format attribute? I can see the value of not loading
up data into memory ever time, but this will make access to these data
rather more painful for developers; that may be an acceptable price to
pay.
Dom
Received on Thursday, 22 July 2010 07:58:51 UTC