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

[timeless]

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.