- From: Danny Ayers <danny.ayers@gmail.com>
- Date: Wed, 13 Apr 2011 15:31:14 +0200
- To: Philip Jägenstedt <philipj@opera.com>
- Cc: public-html@w3.org
On 13 April 2011 14:15, Philip Jägenstedt <philipj@opera.com> wrote: > Things like that are necessary for rendering the document at all. A more > reasonable comparison would be exposing the TOC and other embedded metadata > to scripts. (Nitpick: browsers generally don't support PDF as such, it's > handled by plugins.) Right, I hadn't had quite enough coffee... > There are many things about media resources that the UA knows but does not > expose to scripts, which could be considered metadata. Examples: > > * the size in bytes of the resource > * the type of the resource: JPEG/PNG/Ogg/WebM/WAVE/etc > * the sample format and sample rate of audio tracks > * the pixel format and color space of video tracks > * the frame rate of video tracks (if it is known to be constant) Yep, absolutely. I find it odd we don't have a consistent API for accessing such data. > I agree with Henri that the server is well suited to extracting data like > this. Sure, but why shouldn't client-side extraction it be an option for the developer? An open-ended name-value kind of API for exposing arbitrary metadata > immediately falls back to having to standardize the names and values. But the HTML5 group doesn't have to standardize them. It's fairly easy to imagine specifications in line with RDF that rely on URI-named properties, likewise folksonomy-style ad hoc conventions are possible. > Something like <http://www.w3.org/TR/mediaont-api-1.0/> might be a better > approach, even though I don't think that API is suitable for implementation > in browsers as-is. That spec does have it's good points, but I personally think a much simpler API would get more use. Cheers, Danny. -- http://danny.ayers.name
Received on Wednesday, 13 April 2011 13:31:42 UTC