- From: <bugzilla@jessica.w3.org>
- Date: Wed, 17 Nov 2010 19:07:08 +0000
- To: public-html-bugzilla@w3.org
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