[Bug 11327] media.canPlayType() should be generalized

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11327

--- Comment #3 from Glenn Adams <glenn@skynav.com> 2010-11-17 19:07:08 UTC ---
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

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 17 November 2010 19:07:11 UTC