In the above description, "HTMLMediaType" should read "HTMLMediaElement".

What are the use cases?

Note that we can't remove HTMLMediaElement.canPlayType, at most we'll be adding duplicated functionality elsewhere.

Philip,

Before I present use cases, I will note that HTML5 does not require a conforming UA to support ANY specific MIME type. One finds this rather surprising, but Section 2.2 states the following with respect to HTML MIME Type and XML MIME Type: "Implementations may support only one of these two formats, although supporting both is encouraged." I would have expected language like "MUST support at least one of these two formats, although supporting both is encouraged". A UA that supports neither can still be a conforming (but not very useful) UA.

Going beyond the HTML and XML MIME Types (for HTML5), I note that even if either or both of these types are supported by a conforming UA, then there is no requirement to support any other MIME Type whatsoever. Again, reading 2.2 we find "This specification does not require support of any particular network protocol, style sheet language, scripting language, or any of the DOM specifications beyond those described above." So, from this one can conclude that support for text/css, text/javascript MIME types are not required, nor is protocol support for the "http" or "https" URI schemes required for that matter.

Now, when content is requested from a server by a UA, the server might make use of the HTTP Accept header (or equivalent) in order to make a choice between available resource types to serve out based on what the UA announced as acceptable. However, this choice is made on the server side, and not the client (UA) side. There needs to be a mechanism by which content being presented on a UA can make decisions based on content type (and protocol/scheme) support of the UA as well.

1. What are some use cases for canSupportType(String mimeType)?

* conforming content uses JS to construct (or modify) a DOM, including HTMLImageElement instances, in order to present images; if the image resource to be used is known to be supported by the UA, then the JS will access server 1, otherwise, it will access server 2, a transcoding server, where server 1 and server 2 have no knowledge of each other (so proxying won't work);

* conforming content wishes to generate fall-back content using DOM in case UA does not support a given content type to be presented as embedded content; e.g., the content may wish to create or reference SVG content as embedded content if the UA supports SVG, but generate fallback HTML DOM structure if it does not;

* conforming content wishes to select among alternative fonts to be downloaded depending on the local language context of the user, and uses the CSSFontFaceRule of CSSOM to synthesize the rule based on knowledge of what font formats are supported by the UA, choosing distinct font resources among application/vnd.truetype, application/vnd.opentype, and application/font-tdpfr MIME types according to UA support for specific font types;

etc.

2. What are some use cases for canSupportScheme(String uriScheme)?

* conforming content uses JS to construct (or modify) DOM elements that employ URIs by means of which UA access content; content may need to choose between alternative URIs that employ different schemes in accordance with UA support for the scheme/protocol;

* conforming content being interpreted by a conforming UA on a specialized device, e.g., a mobile handset, television set-top box, or integrated television, etc., may wish to make use of alternative URIs to access content or to control and interact with other entities in accordance to specific device-specific, non-standardized, or proprietary protocols conditionally supported by UA, and, therefore needs to query the UA to determine if it supports the protocol (via the URI scheme), in order to make choices between alternative protocols, content, or behaviors;

3. Determining supported fonts? canSupportFont(String fontName)?

Although I did not mention in my original bug posting, an additional method canSupportFont(String fontName) may be useful as well, in order for content to determine whether it is necessary to download an external font resource or not.

4. Procedural counterparts to declarative vocabulary in SVG (but not HTML)?

The three methods described above, cantSupportType, canSupportScheme, and canSupportFont are procedural counterparts to the declarative requiredFormats, requiredFeatures (sort of), and requiredFonts attributes used in SVG for conditional processing; in the context of greater use of procedural (e.g., JS) content to synthesize/generate/control content/presentation, it is desirable to have procedural counterparts to the features expressed by these SVG attributes.

5. Listing all supported formats, schemes, fonts?

It may also be useful to provide methods that return lists of all supported mime types, schemes, fonts, so as to not require content to guess at what is supported and query each guess. For example, additional methods: String[] supportedTypes, String[] supportedSchemes(), String[] supportedFonts().

6. Where should these methods reside?

On further study, I note there is an interface defined in Section 6.4, namely NavigatorAbilities, which would be an appropriate home, although I would suggest renaming that interface to NavigatorCapabilities. See http://www.differencebetween.net/language/difference-between-ability-and-capability/ for the distinction.

Regards,
Glenn

Checked in as WHATWG revision r5729.
Check-in comment: fix usage of RFC2119 terms
http://html5.org/tools/web-apps-tracker?from=5728&to=5729

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: Rejected
Change Description: no spec change
Rationale:

Please file only one issue per bug.

I don't really understand the use cases for a generic canPlayType(). For images, it's not particularly useful  you can just use PNG or JPEG, everyone supports those. For fonts, just use TrueType, that works everywhere. For schemes, just use HTTP or HTTPS. And so on. If there are specific concrete use cases, please file a bug for each concrete use case, so that they can be examined in detail individually.

mass-moved component to LC1