[whatwg] media resources: addressing media fragments through URIs spec

On Mon, Jul 5, 2010 at 4:23 AM, timeless <timeless at gmail.com> wrote:
> On Sun, Jul 4, 2010 at 4:19 PM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
>> Note that I do understand the need and am trying to explain how it can
>> be made to work. Also I am trying to show that what might look as the
>> simplest approach won't work and why.
>
> It doesn't have to be made to work that way, which is the point that
> the others were trying to make.
>
> http://www.w3.org/TR/REC-html40/struct/objects.html#adef-src-IMG
> src = uri [CT] ? ? This attribute specifies the location of the image
> resource. Examples of widely recognized image formats include GIF,
> JPEG, and PNG.
>
> Nothing in the definition here says "the img tag only allows mime
> types of image/*"
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-src
>
> "The src attribute must be present, and must contain a valid non-empty
> URL potentially surrounded by spaces referencing a non-interactive,
> optionally animated, image resource that is neither paged nor
> scripted.
>
> Images can thus be static bitmaps (e.g. PNGs, GIFs, JPEGs),
> single-page vector documents (single-page PDFs, XML files with an SVG
> root element), animated bitmaps (APNGs, animated GIFs), animated
> vector graphics (XML files with an SVG root element that use
> declarative SMIL animation), and so forth. However, this also
> precludes SVG files with script, multipage PDF files, interactive MNG
> files, HTML documents, plain text documents, and so forth."
>
> While there is text in the html5 definition which precludes scripts,
> it too doesn't explicitly limit the range to image/*, and in fact I
> believe since the PDF mime type is application/pdf, it's safe to say
> that browsers do render things which are not image/*.
>
> In testing, although Chrome, Safari, Opera, and Minefield (after bug
> 276431) support image/svg+xml today none support application/svg+xml.
> However, as Safari supports application/pdf, the cat's out of the bag
> on non image/ mime types.
>
> http://www.webwizardry.net/~timeless/svg/276431.html
>
>> All of the image formats that you are pointing out have an image mime
>> type.
>
> I should have listed PDF which doesn't, mia culpa -- It is in the
> HTML5 specification as a suggestion as noted above in this reply.
>
>> I am merely pointing out that to support ogg theora browsers
>> would need to support a video mime type in an <img> element.
>
> You didn't point that out, you suggested that instead servers would
> have to do content conversions.
>
>> I don't see that as the intention of the <img> element, in particular since
>> <img> elements do not have transport controls and the like.
>
> html5: "An img element represents an image.", that's all the proposal
> wants, an image, a non interactive image (possibly animated), and it's
> possible to decode an ogg video in a way which achieves this.
>
>> Otherwise, why did we create a <video> element in the first place.
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video
>
> html5: "A video element is used for playing videos or movies."
> "User agents should provide controls to enable or disable the display
> of closed captions, audio description tracks, and other additional
> data associated with the video stream, though such features should,
> again, not interfere with the page's normal rendering.
>
> User agents may allow users to view the video content in manners more
> suitable to the user (e.g. full-screen or in an independent resizable
> window). As for the other user interface features, controls to enable
> this should not interfere with the page's normal rendering unless the
> user agent is exposing a user interface. In such an independent
> context, however, user agents may make full user interfaces visible,
> with, e.g., play, pause, seeking, and volume controls, even if the
> controls attribute is absent."
>
> Video offers video controls, the suggestions which you were presented
> were clearly instances where people just wanted animated frames
> without such controls.
>
>> So, I am just pointing out that with current <img> element
>> implementations and with the existing intentions of <img> elements (as
>> opposed to <video> elements), using a segment of Ogg Theora video as
>> defined through a media fragment URI will not work as an image
>> resource and will also not work as a video resource.
>
> In order to support media fragments, media fragment support would have
> to be implemented. This is obvious to everyone. Similarly, adding
> support for ogg in <img> would require adding support for ogg in
> <img>, just as adding support for svg in <img> requires adding support
> for svg in <img>. Of note, since SVG is already supported by most
> browsers, the incremental cost of adding svg support in <img> is
> relatively low (as seen demonstrated by
> <https://bugzilla.mozilla.org/show_bug.cgi?id=276431> which adds it to
> Gecko).
>
> This is in contrast with the cost of adding media fragment support,
> which is essentially entirely new code. But once it's there, the cost
> of letting it work in an <img> tag would not be very high.
>
> Again, I'm not saying it should be done, but you've chosen to ignore
> how it could work and until your last reply suggested an alternative
> which was not the intent of the person who made the proposal while
> ignoring what seemed like a perfectly clear proposal. Again, I'm not
> endorsing it.


I've not ignored anything. I have given my advice to the best of my
knowledge and a recommendation how to solve the use case in a
different technical manner than proposed, since in my opinion the
proposed solution is harder to implement. I am not the one making the
decisions here though - I can only provide input. You are free to
ignore my input and implement video support in the <img> element. I
just had to point out that a media fragment URI that is using "#" will
not return an image mime type, which was what the original question
seemed to imply.

Regards,
Silvia.

Received on Sunday, 4 July 2010 16:46:02 UTC