This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was was cloned from bug 11984 as part of operation LATER convergence. Originally filed: 2011-02-05 00:08:00 +0000 ================================================================================ #0 contributor@whatwg.org 2011-02-05 00:08:06 +0000 -------------------------------------------------------------------------------- Specification: http://www.whatwg.org/specs/web-apps/current-work/complete/video.html Section: http://www.whatwg.org/specs/web-apps/current-work/#loading-the-media-resource Comment: Simplify <video> for implementors and authors by ignoring the Content-Type HTTP header Posted from: 85.227.154.141 by simonp@opera.com ================================================================================ #1 Simon Pieters 2011-02-05 00:18:13 +0000 -------------------------------------------------------------------------------- Rationale The current state of implementations is a mess, as summarized by Ian Hickson (http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-August/028291.html ): "Microsoft's position is, as far as I can tell, that there's no point looking at the Content-Type header, [...]" "Safari does crazy things right now that we won't go into; [...]" "Chrome right now sniffs like IE, [...]" "Opera does what the spec suggests. [...]" "Mozilla respects the Content-Type religiously, [...]" The currently specified handling of Content-Type has concrete negative side-effects for both implementors and authors, outlined in the following sections. Rather than continuing to maintain this mess, we should jump directly to the most sane of the likely outcomes, which is to always ignore Content-Type for <video>. Issues for Implementors * Because application/octet-stream is special-cased in canPlayType, the same code path cannot be used for canPlayType as for checking Content-Type and <source type>. * In the resource fetch algorithm, if the resource is transferred using many HTTP byte range requests, it's unclear if Content-Type should be checked on the first request, or on every request. Either would be problematic: - Checking it only once is inconsistent because on subsequent requests, Content-Type may have changed, but this would be ignored. - Checking it for every request could amount to very many times during the playback of a long video. If the underlying media framework must be queried each time, it could be time-consuming. Introducing caching to work around it increases the risk of bugs. * In order to be compatible with what is sent in Content-Type, implementations must support several synonymous MIME types. This is exposed via canPlayType, where there was no legacy to consider originally, creating unnecessary room for incompatibilities. For example, Firefox supports 4 different MIME types for WAVE, Opera supports 3 and Chrome supports 2. (http://wiki.whatwg.org/wiki/Video_type_parameters#Browser_Support ) Issues for Authors * Because of the way application/octet-stream is special-cased, the result of canPlayType is subtly different from how Content-Type and <source type> are treated, which is confusing. For example, canPlayType("application/octet-stream") returns "", while canPlayType("application/octet-stream;") returns "maybe". Yet, using either value in Content-Type should cause the user agent to use sniffing to determine the resource type and try decoding it. * Many servers are not configured to serve the correct Content-Type for audio and video types: - Authors who are not aware of the requirements on Content-Type will go through time-consuming debugging before eventually learning how to configure their server. - Authors who cannot control what Content-Type HTTP header is sent by their server will be unable to use <video> at all. Details * Remove all mention of application/octet-stream from the <video> section, especially: - The special-casing of application/octet-stream from the canPlayType method. * Remove all mention of Content-Type from the <video> section, especially: - The following case from the resource fetch algorithm: "If the media resource is found to have Content-Type metadata that, when parsed as a MIME type (including any codecs described by the codecs parameter, if the parameter is defined for that type), represents a type that the user agent knows it cannot render (even if the actual media data is in a supported format)" Impact Positive Effects * The behavior of <video> with respect to Content-Type is aligned with how e.g. <img> already works. * No more time is spent maintaining an unstable situation on which it is very unlikely implementations will converge. * Implementations of <video> are simplified. * The incentive for supporting many different equivalent MIME types in canPlayType and <source type> is removed, as they come only from legacy Content-Type issues. * Some legacy MIME types, such as audio/x-pn-wav, can likely be removed from implementations of canPlayType. * Using <video> becomes simpler for authors. Negative Effects * Video will always play in a <video> context but may fail in a top-level browsing content, depending on the Content-Type and what sniffing is used. (This is already the situation for images.) * Content-Type as the definitive mechanism for type information in HTTP is undermined even further. Conformance Classes Changes User Agents Risks * Failure to standardize sniffing of video types may result in poor interoperability. This is already the case, as the spec currently requires sniffing after checking Content-Type. However, the risk does increases somewhat when more implementations switch to always sniffing. Note: Work on standardized sniffing for audio and video types has already begun in Media Type Sniffing. http://tools.ietf.org/html/draft-ietf-websec-mime-sniff-01 (Note: This bug is basically foolip's CP for ISSUE-145 (http://www.w3.org/html/wg/wiki/ChangeProposals/NoVideoContentType ). However, I think his CP is not appropriate as a CP for ISSUE-145 since it makes a substantive change while the original bug was about an editorial issue. Therefore I think it is more appropriate for foolip's CP to be a separate bug, hence this bug.) ================================================================================ #2 Ian 'Hixie' Hickson 2011-02-05 01:31:54 +0000 -------------------------------------------------------------------------------- EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: Concurred with reporter's comments. ================================================================================ #3 contributor@whatwg.org 2011-02-05 01:32:11 +0000 -------------------------------------------------------------------------------- Checked in as WHATWG revision r5836. Check-in comment: Bring the spec more in line with what the browsers do for video (largely, ignoring Content-Type). This will probably be tweaked further once Adam's draft has a section dedicated to sniffing media container formats. http://html5.org/tools/web-apps-tracker?from=5835&to=5836 ================================================================================ #4 Adam Barth 2011-02-05 02:09:54 +0000 -------------------------------------------------------------------------------- I've updated http://tools.ietf.org/html/draft-ietf-websec-mime-sniff to include a hook for sniffing video specifically. Please let me know if you need other hooks in that document. ================================================================================ #5 Julian Reschke 2011-02-05 10:43:27 +0000 -------------------------------------------------------------------------------- I believe this should be reverted, see <http://lists.w3.org/Archives/Public/public-html/2011Feb/0114.html>. ================================================================================ #6 Adrian Bateman [MSFT] 2011-02-14 20:46:28 +0000 -------------------------------------------------------------------------------- Microsoft's position: IE9 RC strictly obeys the Content-Type returned to media elements. We believe this behaviour matches the latest Firefox 4 Beta. Based on feedback from developers and also following the "state of implementations" thread highlighted by Simon above, we changed the implementation of media elements between IE9 Beta and IE9 RC. While it required extra work in our browser engine to respect the Content-Type in this way, it turned out that this was less work than supporting a robust future-proof content-sniffing approach. Consequently we disagree that this change simplifies things for implementers and we request that the change be reverted. Currently, we do not support media playback for content with the application/octet-stream content type. The working group should consider application/octet-stream support as a separate issue. ================================================================================ #7 Philip Jägenstedt 2011-02-14 21:45:27 +0000 -------------------------------------------------------------------------------- (In reply to comment #6) > Microsoft's position: IE9 RC strictly obeys the Content-Type returned to media > elements. We believe this behaviour matches the latest Firefox 4 Beta. Based on > feedback from developers and also following the "state of implementations" > thread highlighted by Simon above, we changed the implementation of media > elements between IE9 Beta and IE9 RC. While it required extra work in our > browser engine to respect the Content-Type in this way, it turned out that this > was less work than supporting a robust future-proof content-sniffing approach. > Consequently we disagree that this change simplifies things for implementers > and we request that the change be reverted. > > Currently, we do not support media playback for content with the > application/octet-stream content type. The working group should consider > application/octet-stream support as a separate issue. Uh, just when all browser vendors seemed to be OK with ditching Content-Type... What about file:, ftp: and other protocols that don't have any equivalent of Content-Type? What about when Content-Type is missing from a HTTP respsonse? By reverting this change we'd be bringing back application/octet-stream which you don't support. Wouldn't it be better to agree on something and change the spec to that than to bring back something which doesn't match any browser and never will? ================================================================================ #8 Chris Double 2011-02-14 23:26:44 +0000 -------------------------------------------------------------------------------- (In reply to comment #7) > > Uh, just when all browser vendors seemed to be OK with ditching Content-Type... > Firefox currently doesn't sniff and respects the Content-Type. We don't plan to change this behavior at this stage. What I'd like to see is further work and testing on the content sniffing algorithm before any decision is made to change. > What about file:, ftp: and other protocols that don't have any equivalent of > Content-Type? What about when Content-Type is missing from a HTTP respsonse? We have an internal mapping from file extension to content type for these purposes. > By reverting this change we'd be bringing back application/octet-stream which > you don't support. Wouldn't it be better to agree on something and change the > spec to that than to bring back something which doesn't match any browser and > never will? I'd also like the application/octet-stream issue to be dealt with separately as per Microsoft's request. ================================================================================ #9 Sam Ruby 2011-02-15 00:16:52 +0000 -------------------------------------------------------------------------------- (In reply to comment #6) > Currently, we do not support media playback for content with the > application/octet-stream content type. The working group should consider > application/octet-stream support as a separate issue. Please file a separate bug report on this. ================================================================================ #10 David Singer 2011-02-15 03:25:54 +0000 -------------------------------------------------------------------------------- Content-type has decreasing utility; it fails to handle files that conform to more than one standard (one file can simultaneously be valid as video/3gpp, video/mp4, and video/3gpp2, for example). Many users cannot configure their web servers to return correct content-types (it's not under their control). A a declared attribute in the markup, type has utility. As a guess from the file-extension by the web server, the utility is marginal at best; the UA can and usually does do better at deducing what the correct type of a file is. Given that you have to be prepared, at the UA, to disbelieve what you're told, or adjust it, we question whether tangling the web server's guess into the UA behavior makes life any simpler or more interoperable. ================================================================================ #11 Philip Jägenstedt 2011-02-15 08:47:02 +0000 -------------------------------------------------------------------------------- (In reply to comment #8) > (In reply to comment #7) > > > > Uh, just when all browser vendors seemed to be OK with ditching Content-Type... > > > > Firefox currently doesn't sniff and respects the Content-Type. We don't plan to > change this behavior at this stage. What I'd like to see is further work and > testing on the content sniffing algorithm before any decision is made to > change. I've discussed this with Robert O'Callahan, see <http://krijnhoetmer.nl/irc-logs/whatwg/20110127#l-831>. I'm not surprised that you're not a fan of the idea, though. Should I take this that you'd consider dropping Content-Type if the solution gets spec'd, tested and shipped in another browser? > > What about file:, ftp: and other protocols that don't have any equivalent of > > Content-Type? What about when Content-Type is missing from a HTTP respsonse? > > We have an internal mapping from file extension to content type for these > purposes. Even for missing HTTP Content-Type? How about Content-Type: application/octet-stream? > > By reverting this change we'd be bringing back application/octet-stream which > > you don't support. Wouldn't it be better to agree on something and change the > > spec to that than to bring back something which doesn't match any browser and > > never will? > > I'd also like the application/octet-stream issue to be dealt with separately as > per Microsoft's request. Would that be ISSUE-145, or the issue of whether or not to play HTTP resources with Content-Type: application/octet-stream ? ================================================================================ #12 Maciej Stachowiak 2011-02-17 11:17:27 +0000 -------------------------------------------------------------------------------- Since Microsoft and Mozilla do not implement the behavior resulting from this bug, and seem unwilling to do so, it may be a good idea to revert the change for now, pending further discussion. I say this even though Apple would somewhat prefer the behavior of ignoring Content-Type. Reopening bug based on new information from Mozilla and Microsoft reps. ================================================================================ #13 Philip Jägenstedt 2011-02-17 11:57:07 +0000 -------------------------------------------------------------------------------- (In reply to comment #12) > Since Microsoft and Mozilla do not implement the behavior resulting from this > bug, and seem unwilling to do so, it may be a good idea to revert the change > for now, pending further discussion. I say this even though Apple would > somewhat prefer the behavior of ignoring Content-Type. Reopening bug based on > new information from Mozilla and Microsoft reps. They also don't implement the behavior that would result from reverting this bug, and seem unwilling to do so. Unless we can all agree to implement some specific behavior, I'd prefer to handle this as an ISSUE, to force everyone to make very specific suggestions for what the spec should be. ================================================================================ #14 Julian Reschke 2011-02-17 12:06:16 +0000 -------------------------------------------------------------------------------- (In reply to comment #13) > They also don't implement the behavior that would result from reverting this > bug, and seem unwilling to do so. Well, not all of it. Sam's advise was to have a separate bug for that. > Unless we can all agree to implement some specific behavior, I'd prefer to > handle this as an ISSUE, to force everyone to make very specific suggestions > for what the spec should be. Once the change in the spec is undone, you are of course free to escalate to an issue. ================================================================================ #15 Sam Ruby 2011-02-17 14:16:20 +0000 -------------------------------------------------------------------------------- (In reply to comment #14) > (In reply to comment #13) > > They also don't implement the behavior that would result from reverting this > > bug, and seem unwilling to do so. > > Well, not all of it. Sam's advise was to have a separate bug for that. +1 > > Unless we can all agree to implement some specific behavior, I'd prefer to > > handle this as an ISSUE, to force everyone to make very specific suggestions > > for what the spec should be. > > Once the change in the spec is undone, you are of course free to escalate to an > issue. +1 ================================================================================ #16 Philip Jägenstedt 2011-02-17 15:24:54 +0000 -------------------------------------------------------------------------------- Well, I'm hoping this will be closed as FIXED without reversion and that those who disagree with that raise it as an ISSUE, but either way the end result would be the same process. ================================================================================ #17 Julian Reschke 2011-02-17 17:00:57 +0000 -------------------------------------------------------------------------------- (In reply to comment #12) > Since Microsoft and Mozilla do not implement the behavior resulting from this > bug, and seem unwilling to do so, it may be a good idea to revert the change > for now, pending further discussion. I say this even though Apple would > somewhat prefer the behavior of ignoring Content-Type. Reopening bug based on > new information from Mozilla and Microsoft reps. "may be a good idea" is kind of fuzzy. Can we please have an official statement from the chairs? (asking because <http://www.w3.org/Bugs/Public/show_bug.cgi?id=11984#c16> indicates there's still confusion) ================================================================================ #18 Philip Jägenstedt 2011-02-23 10:12:19 +0000 -------------------------------------------------------------------------------- (In reply to comment #17) > (In reply to comment #12) > > Since Microsoft and Mozilla do not implement the behavior resulting from this > > bug, and seem unwilling to do so, it may be a good idea to revert the change > > for now, pending further discussion. I say this even though Apple would > > somewhat prefer the behavior of ignoring Content-Type. Reopening bug based on > > new information from Mozilla and Microsoft reps. > > "may be a good idea" is kind of fuzzy. Can we please have an official statement > from the chairs? (asking because > <http://www.w3.org/Bugs/Public/show_bug.cgi?id=11984#c16> indicates there's > still confusion) There is no confusion, just plain old disagreement. Normally when a bug report is filed and the editor agrees and fixes it, it is those who disagree that escalate the bug to an issue. I don't see why we should do anything differently here, especially given that no one is willing to implement the previous state either. ================================================================================ #19 Julian Reschke 2011-02-23 10:25:15 +0000 -------------------------------------------------------------------------------- (In reply to comment #18) > There is no confusion, just plain old disagreement. Normally when a bug report > is filed and the editor agrees and fixes it, it is those who disagree that > escalate the bug to an issue. I don't see why we should do anything differently > here, especially given that no one is willing to implement the previous state > either. The bug has been reopened (by one of the WG chairs), so it's not in a state where it can be escalated. As far as I can tell, the WG waits for the editor to either undo the change, or to close the bug again. ================================================================================ #20 contributor@whatwg.org 2011-03-01 00:19:04 +0000 -------------------------------------------------------------------------------- Checked in as WHATWG revision r5921. Check-in comment: revert r5836 per http://lists.w3.org/Archives/Public/public-html/2011Mar/0002.html http://html5.org/tools/web-apps-tracker?from=5920&to=5921 ================================================================================ #21 Philip Jägenstedt 2011-03-01 08:02:12 +0000 -------------------------------------------------------------------------------- At this point it would be most helpful if implementors at Mozilla and Microsoft stepped forward to specify exactly what they *are* willing to implement. As an example of what is missing: do you also intend to respect the codecs parameter when given in Content-Type? ================================================================================ #22 Philip Jägenstedt 2011-03-03 22:27:09 +0000 -------------------------------------------------------------------------------- OK, new suggestion: * In most cases, including at least audio/* and video/*, trust the Content-Type header and try decoding it as such. This is stricter than the current spec, which requires sniffing after inspecting Content-Type. * Sniff for the set of Content-Type values that are usually incorrect defaults, like text/plain and application/octet-stream. The table in <http://tools.ietf.org/html/draft-ietf-websec-mime-sniff-02#section-3> looks relevant to this. * Ignore the codecs parameter in the Content-Type header completely, since codec setup cannot be done without inspecting the data anyway. * Get rid of all special-casing of application/octet-type in canPlayType. Pros: * Fixes the biggest problem of Content-Type, namely that videos served as text/plain or application/octet-stream don't play. * Respects Content-Type in cases where second guessing likely isn't useful, like audio/* and video/*. * Would work the same in a <video> context and in a top-level browsing context. * Formats that are not reliably sniffable don't have to be added to the sniffing table, they just wouldn't work when served as application/octet-stream. * Browsers that sniff to support existing content (e.g. Safari) would likely see less breakage than if moving to strict handling like Firefox/IE. * It's still possible to move to "always sniff" from here without much damage being left behind. Cons: * Inconsistent with how <img> works. * Requires considering both Content-Type and the data to determine what demuxer to plug, rather than just one or the other. * The codecs parameter would have an effect in canPlayType but not in Content-Type. In practice the codecs parameter isn't sent in Content-Type, so it's not the end of the world. ================================================================================ #23 Adrian Bateman [MSFT] 2011-03-04 20:12:33 +0000 -------------------------------------------------------------------------------- (In reply to comment #22) > OK, new suggestion: > > * In most cases, including at least audio/* and video/*, trust the Content-Type > header and try decoding it as such. This is stricter than the current spec, > which requires sniffing after inspecting Content-Type. > * Sniff for the set of Content-Type values that are usually incorrect defaults, > like text/plain and application/octet-stream. The table in > <http://tools.ietf.org/html/draft-ietf-websec-mime-sniff-02#section-3> looks > relevant to this. > * Ignore the codecs parameter in the Content-Type header completely, since > codec setup cannot be done without inspecting the data anyway. > * Get rid of all special-casing of application/octet-type in canPlayType. We think we can live with this being what is in the spec. Unfortunately, were too late to make changes in IE9 (we announced when we shipped the release candidate that we would be shipping the final release shortly) and as usual I cant make predictions about when we will adopt things in future releases but this seems like a reasonable compromise to work towards. As you mention, there would be an inconsistency between handling of the codecs parameter between canPlayType compared to playing but this is something we think is necessary (for example to be able to choose between high and basic profile H.264 streams). ================================================================================ #24 Philip Jägenstedt 2011-03-05 13:11:06 +0000 -------------------------------------------------------------------------------- A few of the things in <http://www.w3.org/html/wg/wiki/ChangeProposals/NoVideoContentType#Negative_Effects> are not solved by my new suggestion, so I'd consider not fixing these cons: * The incentive for supporting many different equivalent MIME types in canPlayType and <source type> is removed, as they come only from legacy Content-Type issues. * Some legacy MIME types, such as audio/x-pn-wav, can likely be removed from implementations of canPlayType. This is damage we'll have to live with unless we always sniff, it might be OK if implementors exercise some contraint in which MIME types they add support for. WAVE might be a lost case, though. ================================================================================ #25 Yuhong Bao 2011-03-06 07:34:33 +0000 -------------------------------------------------------------------------------- Yea, I remember having to work with Roy Schestowitz of Techrights to fix the Content-Type when they began using the <video> tag, as one example. ================================================================================ #26 Adrian Bateman [MSFT] 2011-03-07 17:24:52 +0000 -------------------------------------------------------------------------------- (In reply to comment #24) > A few of the things in > <http://www.w3.org/html/wg/wiki/ChangeProposals/NoVideoContentType#Negative_Effects> > are not solved by my new suggestion, so I'd consider not fixing these cons: > > * The incentive for supporting many different equivalent MIME types in > canPlayType and <source type> is removed, as they come only from legacy > Content-Type issues. > > * Some legacy MIME types, such as audio/x-pn-wav, can likely be removed from > implementations of canPlayType. > > This is damage we'll have to live with unless we always sniff, it might be OK > if implementors exercise some contraint in which MIME types they add support > for. WAVE might be a lost case, though. I didn't really understand these two points. I'm sure I'm just missing some background info. Please could you elaborate? ================================================================================ #27 Philip Jägenstedt 2011-03-07 19:56:07 +0000 -------------------------------------------------------------------------------- (In reply to comment #26) > (In reply to comment #24) > > A few of the things in > > <http://www.w3.org/html/wg/wiki/ChangeProposals/NoVideoContentType#Negative_Effects> > > are not solved by my new suggestion, so I'd consider not fixing these cons: > > > > * The incentive for supporting many different equivalent MIME types in > > canPlayType and <source type> is removed, as they come only from legacy > > Content-Type issues. > > > > * Some legacy MIME types, such as audio/x-pn-wav, can likely be removed from > > implementations of canPlayType. > > > > This is damage we'll have to live with unless we always sniff, it might be OK > > if implementors exercise some contraint in which MIME types they add support > > for. WAVE might be a lost case, though. > > I didn't really understand these two points. I'm sure I'm just missing some > background info. Please could you elaborate? It relates to this point from "Issues for Implementors": * In order to be compatible with what is sent in Content-Type, implementations must support several synonymous MIME types. This is exposed via canPlayType, where there was no legacy to consider originally, creating unnecessary room for incompatibilities. For example, Firefox supports 4 different MIME types for WAVE, Opera supports 3 and Chrome supports 2. (source: <http://wiki.whatwg.org/wiki/Video_type_parameters#Browser_Support>) If Content-Type was always ignored, this pollution of canPlayType would not happen. Actually, we could perhaps fix it in my new proposal as well by adding this point: * Content-Type is normalized to allow for synonyms like audio/wave and audio/wav that are necessary for compat, but via canPlayType only the canonical form is exposed, so only one would return "maybe"/"probably". I don't think it's actually worth the complexity though, I just consider it a con relative to ignoring Content-Type. ================================================================================ #28 Adrian Bateman [MSFT] 2011-03-07 20:15:04 +0000 -------------------------------------------------------------------------------- (In reply to comment #27) > I don't think it's actually worth the complexity though, I just consider it a > con relative to ignoring Content-Type. Thanks for the explanation. I agree - I don't think it's worth trying to fix here either. ================================================================================ #30 Ian 'Hixie' Hickson 2011-10-26 20:48:19 +0000 -------------------------------------------------------------------------------- So what is the spec supposed to say, at this point? ================================================================================ #31 Philip Jägenstedt 2011-10-27 08:26:34 +0000 -------------------------------------------------------------------------------- (In reply to comment #30) > So what is the spec supposed to say, at this point? Everyone disagrees on that. I think it should just point to http://tools.ietf.org/html/draft-ietf-websec-mime-sniff-03#section-8 so that sniffing always takes precedence. ================================================================================ #32 Ian 'Hixie' Hickson 2011-11-02 18:56:05 +0000 -------------------------------------------------------------------------------- If browser vendors disagree on what should happen, then I think I will go back to strict adherence to the HTTP specs, and then let the market figure it out. Once browsers converge on a particular behaviour, or once there is agreement on what they should converge on, I will update the spec to match it. You are welcome to try to use the escalation process to make a decision sooner, but of course if it doesn't match what finally gets implemented, it doesn't much matter what that decision is either. :-) ================================================================================ #33 Philip Jägenstedt 2011-11-03 09:36:20 +0000 -------------------------------------------------------------------------------- (In reply to comment #32) > If browser vendors disagree on what should happen, then I think I will go back > to strict adherence to the HTTP specs, and then let the market figure it out. > Once browsers converge on a particular behaviour, or once there is agreement on > what they should converge on, I will update the spec to match it. If we know that browsers are implementing it differently, then I'd much prefer if the spec made it explicitly undefined and noted that it will be spec'd at some later point, rather than picking sides up front. ================================================================================ #34 Ian 'Hixie' Hickson 2011-11-03 16:29:23 +0000 -------------------------------------------------------------------------------- I can certainly put a warning in the spec. ================================================================================ #35 contributor@whatwg.org 2011-11-12 00:22:31 +0000 -------------------------------------------------------------------------------- Checked in as WHATWG revision r6826. Check-in comment: Add warnings about media elements and track and how to determine the type and how we don't know what hte solution is. http://html5.org/tools/web-apps-tracker?from=6825&to=6826 ================================================================================ #36 Ian 'Hixie' Hickson 2011-11-12 00:30:26 +0000 -------------------------------------------------------------------------------- I've put a warning in the spec. Marking this LATER for now; once browser vendors have converged on a behaviour or desired behaviour I'll revisit this. (See comment 32.) ================================================================================