Re: More clarifications on object processing ( LC-1978 LC-1979 LC-1980 LC-1981)

 Dear Dominique Hazael-Massieux ,

The Mobile Web Best Practices Working Group has reviewed the comments you
sent [1] on the Last Call Working Draft [2] of the W3C mobileOK Basic
Tests 1.0 (Fourth Last Call) published on 10 Jun 2008. Thank you for
having taken the time to review the document and to send us comments!

The Working Group's response to your comment is included below, and has
been implemented in the new version of the document available at:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080707r.

Please review it carefully and let us know by email at
public-bpwg-comments@w3.org if you agree with it or not before 5 August
2008. In case of disagreement, you are requested to provide a specific
solution for or a path to a consensus with the Working Group. If such a
consensus cannot be achieved, you will be given the opportunity to raise a
formal objection which will then be reviewed by the Director during the
transition of this document to the next stage in the W3C Recommendation
Track.

Thanks,

For the Mobile Web Best Practices Working Group,
Dominique Hazaël-Massieux
François Daoust
W3C Staff Contacts

 1. http://www.w3.org/mid/1213203871.6545.1.camel@localhost
 2. http://www.w3.org/TR/2008/WD-mobileOK-basic10-tests-20080610/


=====

Your comment on 2.4.6 Included Resources:
> * when analyzing external resources (in ContentFormatSupport,
> PageSizeLimit, ExternalResources), the objects and images that are set
> as fallback of an object that is in an acceptable format shouldn't be
> counted. For instance,
> <object data="myimage.gif"><img src="myimage.png" alt=""/></object>
> shouldn't trigger an error in ContentFormatSupport, the weight of
> myimage.png shouldn't be counted in PageSizeLimit and ExternalResources


Working Group Resolution (LC-1978):
We agree that the "myimage.png" should not trigger a
CONTENT_FORMAT_SUPPORT error, and should not be taken into account in
PAGE_SIZE_LIMIT and EXTERNAL_RESOURCES. This is triggered by the note in
2.4.6 Included Resources:
 "object elements that are accessed in order to test their Content-Type
HTTP header, but do not form part of the ultimate representation of the
resource under test (see 3.15 OBJECTS_OR_SCRIPT ), are not considered to
be included resources".

We agree that the notion of "ultimate representation of the resource"
deserves to be clarified though and the note extended to resources
retrieved by section 3.15.1 Object Element Processing Rule.

On the light of the discussion that followed your other comment (LC-1980)
on the use of the HTTP Content-Type value to taste object element, we
updated the note to specify that only resources retrieved under the 3.15.1
Object Element Processing Rule whose Content-Type is image/gif or
image/jpeg are considered to be Included Resources:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080707r#included_resources

----

Your comment on 2.4.6 Included Resources:
> * similarly, I don't think we want to raise a ContentFormatSupport
> error
> on <object data="myimage.png"><img src="myimage.gif" alt=""
> /></object>
> since this is using correctly the fallback mechanism; while this gets
> accepted by ObjectsOrScript, this would currently raise an error in
> the
> way I read ContentFormatSupport;


Working Group Resolution (LC-1979):
We agree that the example should not raise a FAIL in
CONTENT_FORMAT_SUPPORT, because "myimage.png" does not form part of the
ultimate representation of the resource under test, as noted in 2.4.6
Included Resources.

We clarified the note in 2.4.6 Included Resources as noted in our reply to
your previous comment (LC-1978) on the need to clarify which objects and
images are Included Resources, and which are not.

----

Your comment on 3.16 PAGE_SIZE_LIMIT:
> * 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.


Working Group Resolution (LC-1980):
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.

----

Your comment on 3.16 PAGE_SIZE_LIMIT:
> * if I hit an HTTP redirect, does the size of the page served as the
> redirect page counts in PAGE_SIZE_LIMIT-1 or only
> under PAGE_SIZE_LIMIT-2? I've implemented the latter since I find
> it
> less confusing, but the spec could be clearer about it


Working Group Resolution (LC-1981):
Yes, we agree that the text here deserved to be clarified. We updated the
text consequently:

- Section 3.16 PAGE_SIZE_LIMIT was clarified with regards to the treatment
of HTTP response bodies that are required to retrieve a resource:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080707r#PAGE_SIZE_LIMIT

- Section 2.4.3 HTTP Response was also amended to have the reader refer to
3.16 PAGE_SIZE_LIMIT (resp. 3.6 EXTERNAL_RESOURCES) for details of the
total size (resp. count) the HTTP redirect response body should be added
to:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080707r#http_response

----

Received on Thursday, 31 July 2008 13:15:27 UTC