On Mon, Jul 5, 2010 at 4:23 AM, timeless <timel...@gmail.com> wrote: > On Sun, Jul 4, 2010 at 4:19 PM, Silvia Pfeiffer > <silviapfeiff...@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.