W3C home > Mailing lists > Public > public-bpwg@w3.org > May 2008

mobileOK Basic - Wrong definition of included resources for CONTENT_FORMAT_SUPPORT

From: Francois Daoust <fd@w3.org>
Date: Wed, 21 May 2008 17:05:43 +0200
Message-ID: <48343A47.2070006@w3.org>
To: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>

The problem
-----------
I was re-reading the doc to check the correctness of the algorithms we 
updated, when I stumbled upon the following: as a consequence of the 
resolution we've made for ISSUE-234 to count untyped objects in overall 
page weight, the definition of "Included resources" [1] became slightly 
wrong for the CONTENT_FORMAT_SUPPORT test.


Why?
----
The definition includes a note that says:
"For nested object elements, count only the number of objects that need 
to be assessed as discussed in 3.15 OBJECTS_OR_SCRIPT"

The OBJECT_OR_SCRIPT section [2] defines how objects elements are to be 
processed, and in particular now includes objects that don't define the 
type attribute. To be clear, objects without type attributes are now 
part of the "Included resources" (those on the way to finding a valid 
object, that is, not all of them).

"Included resources" are in turn used in:
- CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE [3]
- CONTENT_FORMAT_SUPPORT and VALID_MARKUP [4]
- EXTERNAL_RESOURCES [5]
- PAGE_SIZE_LIMIT [6]

Depending on the actual content type of the resource pointed to by an 
object without type attribute, the browser may or may not use that 
resource to render the page. In practice, if it's "image/gif" or 
"image/jpeg", it will. If it's something else, it won't.

Assuredly, we want to count such objects in PAGE_SIZE_LIMIT and 
EXTERNAL_RESOURCES, that's why we had the resolution!

But for CONTENT_FORMAT_SUPPORT, this raises a problem:
  "For each included resource (see 2.4.6 Included Resources):
	If the response specifies an Internet media type that is not 
"text/css", "image/jpeg" or "image/gif", FAIL"

Now, since an object without type attribute may well be a PNG image, the 
test is to FAIL on the following:
	<object data="test.png" width="50" height="50">
	  <object data="test.gif" width="50" height="50" />
	</object>
The outermost <object> is without type and returns a PNG image, but the 
fallback is a GIF image, so this should be mobileOK. It's not because 
the first object is now part of the definition of the "Included resources"

(The same applies for the first CHARACTER_ENCODING_SUPPORT, but only 
WARNs are raised, so and that's not really a big deal if we return too 
many WARNs because the encoding is not good...)


Possible solution
-----------------
Well, I don't say that will make things crystal clear for readers, but 
the solution I can think of is to define two levels of "Included resources":
a) the same definition as above: all the resources that the browser has 
to _download_ to render the page
b) all the resources that the browser has to _parse_ to render the page. 
b) is obviously a subset of a).

a) would be used in:
  - EXTERNAL_RESOURCES
  - PAGE_SIZE_LIMIT
  (- and possibly CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE)
b) would be used in:
  - CONTENT_FORMAT_SUPPORT and VALID_MARKUP
  (- and CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE if a) is 
not used for that)


References
----------
[1] 
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080506#included_resources
[2] 
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080506#OBJECTS_OR_SCRIPT
[3] 
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080506#CHARACTER_ENCODING_SUPPORT
[4] 
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080506#CONTENT_FORMAT_SUPPORT
[5] 
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080506#EXTERNAL_RESOURCES
[6] 
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/080506#PAGE_SIZE_LIMIT


Side note on the algorithms
---------------------------
As a side note, the updated OBJECTS_OR_SCRIPTS and PAGE_SIZE_LIMIT 
algorithms look correct to me.

Francois.
Received on Wednesday, 21 May 2008 15:06:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:42:58 UTC