Re: More clarifications on object processing

[cc public bpwg - don't think this has been aired there]

OK, thinking about this a bit more ... and following off-line discussion 
with the esteemed Francois Daoust ...

... I have a new proposal on 3.15.1 Object Processing Rule which takes 
into account the point made by Abel on the checker list

http://lists.w3.org/Archives/Public/public-mobileok-checker/2008Jul/0010.html

also please see

http://lists.w3.org/Archives/Public/public-bpwg-comments/2008JulSep/0000.html

for a more complete list of proposed changes that are relevant to this.


Also I have spotted that 3.13 NO_FRAMES could do with clarification in 
this context too and that 3.7 GRAPHICS_FOR_SPACING and 3.9 
IMAGES_RESIZING and IMAGES_SPECIFY_SIZE need clarification ref handling 
of the type attribute.


===

NO_FRAMES

Proposed Text

If the document contains a frame , frameset or iframe element, FAIL

Current Text

If the document contains a frame , frameset or iframe element or it 
contains an object element which when retrieved has an Internet media 
type that starts with "text/", "application/xhtml+xml" or 
"application/vnd.wap.xhtml+xml", FAIL


===

make 3.7 and 3.9 consistent

3.7 GRAPHICS_FOR_SPACING

...

For each img element and object element which when retrieved has an 
Internet media type that starts with "image/":

...

3.9 IMAGES_RESIZING and IMAGES_SPECIFY_SIZE

current text:

...

For each img element and object element whose type attribute starts with 
"image/":

...

proposed text:


For each img element and object element which when retrieved has an 
Internet media type that starts with "image/":



===
3.15.1 Object Element Processing Rule

Proposed Text

For each object element that has no object element ancestor in this 
context (excepting the context node itself):

 If there is no type attribute, warn

 If the object element is empty, warn

 If the content of the object element consists only of white space, FAIL

 Retrieve the referenced resource (ignoring the type attribute)

 If the content type of the retrieved object is not "image/jpeg" or 
"image/gif", warn

  For each img element that has no object element ancestor in this context:

   If the content type of the img element is not "image/jpeg" or 
"image/gif", FAIL

  Reapply this rule using the current object element as the context

 Note

 A warning is issued when the content type is not compatible with the 
Default Delivery Context because some user agents do not take into 
account the type attribute of object elements and this may cause the 
user agent to retrieve very large incompatible objects with consequences 
to performance and cost.

 Note

 A 406 status on retrieval of a resource referenced by an object element 
does not constitute a FAIL.


[also make corresponding change to 2.4.3 HTTP Response]


Current Text

For each object element that has no object element ancestor in this 
context (excepting the context node itself):

 Retrieve the object (ignoring the type attribute)

 If the content type of the retrieved object is not "image/jpeg" or 
"image/gif"

  If the object element is empty, warn

  If the content of the object element consists only of white space, FAIL

  For each img element that has no object element ancestor in this context:

   If the content type of the img element is not "image/jpeg" or 
"image/gif", FAIL

  Reapply this rule using the current object element as the context




On 02/07/2008 16:32, Jo Rabin wrote:
> 
> Francois I don't object to this approach but did point out this self 
> same apparent inconsistency in the draft before the last last call. The 
> reason, as discussed, for this apparent inconsistency is that we are not 
> modelling any particular User Agent, we are giving the content provider 
> the best chance of a pass. If we are to reverse that earlier decision 
> then I think we need to be clear as to why and what consequences that 
> has for PASS/FAIL.
> 
> If anything, my preference would be to have an additional WARN if the 
> retrieved content type does not match the advertised type, including not 
> advertising a type, and leave it at that.
> 
> Jo
>

Received on Thursday, 3 July 2008 13:50:11 UTC