Edit comment LC-1980 for Mobile Web Best Practices Working Group

Previous: LC-1979 Next: LC-1981

Comment LC-1980: Comment Shortname:; Commenter: Dominique Hazael-Massieux <dom@w3.org>; Message-id:; Section of the document concerned:

or; Refinement of the section concerned:; Status:
assigned to; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
* I don't think "myimage.gif" should be counted as external
resources/page size limit in the following instance:
<object data="myimage.gif" type="image/png">Hello</object> - the current
text says to "include those objects whose content type is either
"image/jpeg" or "image/gif" irrespective of whether the type attribute
is specified.", but it's not clear why.; Related issues: (space separated ids); WG Notes: Propose to resolve "partial" Since there is no consistency out there in the way such objects are handled by mobile browsers, propose to resolve as "partial": 1/ the Content-Type is still being used instead of the "type" attribute to ensure we won't return a fail in situations that work fine on actual browsers. 2/ a warning was added to warn the user when the Content-Type returned by a resource does not match the one listed in the type attribute of the underlying object element; Resolution: We understand that point, but note that there is not a real consistency in the way such objects are handled by mobile browsers in practice. Some browsers download all the objects and use the HTTP Content-Type header irrespective of the presence of the type attribute, while other browsers follow the type attribute and only download objects that match values of the HTTP Accept header. We think Content Providers should "benefit" (or rather should not be "punished") for this lack of consistency in mobile browsers, and decided, in the interest of returning fewer FAIL messages: 1/ to stick to the HTTP Content-Type header to determine whether an object is rendered or the fallback mechanism has to be used. 2/ to stick to our decision not to count objects that define a type attribute not set to image/gif or image/jpeg in PAGE_SIZE_LIMIT and EXTERNAL_RESOURCES. However, since we recognize that the corresponding behavior among mobile browsers is not consistent, that it is a bad practice to have a type attribute that does not match the Content-Type of the underlying resource and that it is a good practice to define the type attribute, we also introduced two additional warning messages: "If there is no type attribute, warn" "If the Internet media type of the retrieved resource, as indicated by its Content-Type HTTP header does not match that stated in the type attribute, warn" We note that our decision introduces a slight inconsistency in the way objects are treated by the specification: on the one hand, section 3.15.1 Object Element Processing Rule says that the Object must be retrieved so that the HTTP Content-Type header may be parsed, on the other hand, section 3.16 PAGE_SIZE_LIMIT (resp. 3.6 EXTERNAL_RESOURCES) says that an object defined with a type attribute set to image/png does not count as a retrieved resource (provided its actual Content-Type is not image/gif or image/jpeg). We think that it is needed though for the above mentioned reasons.; (Please make sure the resolution is adapted for public consumption)