- 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
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 UTC