W3C home > Mailing lists > Public > public-bpwg-comments@w3.org > April to June 2008

Re: More clarifications on object processing

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Thu, 12 Jun 2008 17:56:58 +0200
To: Francois Daoust <fd@w3.org>
Cc: public-bpwg-comments <public-bpwg-comments@w3.org>
Message-Id: <1213286218.6766.56.camel@localhost>

Le jeudi 12 juin 2008 à 17:37 +0200, Francois Daoust a écrit :
> Dominique Hazael-Massieux wrote:
> > * 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
> 
> Part to clarify:
>   "object means "object" and "img" in the note on objects to include in 
> 2.4.6 Included Resources"

Yes, I agree that replacing "object elements" with "object and img
elements" in the note under 2.4.6 should suffice to clarify the
situation.

In the said note (copied below):
> "Note: 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 ), "

.... it would be nice if "form[ing] part of the ultimate representation"
was actually defined (in 3.15.1, most probably).

> > * 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; 
> 
> Part to clarify:
>   "ultimate representation of the resource under test"
> 
> [Side note:
> The Accept header precises that only image/gif and image/jpeg are supported.
> Is it still correct to send a PNG image even with a fallback mechanism?
> I think it is, I'm raising the point in case it's not...]

(that's actually the gist of my comment, I think :)

>  From the note above, since "myimage.png" does "not form part of the 
> ultimate representation of the resource under test", the test should not 
> apply on "myimage.png".

That is true, indeed; but this reiterates the need for clarifying
"ultimate representation of the resource under test" (as you note). 


> > * 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.
> 
> Part to clarify:
>   The note on how to select objects at the beginning of 
> EXTERNAL_RESOURCES and PAGE_SIZE_LIMIT
> 
> It may deserve clarification, but this restriction applies to the set of 
> "objects retrieved under the 3.15.1 Object Element Processing Rule". An 
> object with an "image/png" type won't be retrieved by the Object Element 
> Processing Rule, so "myimage.gif" won't be counted.

I think there is a risk of confusion on the meaning of "type" here:
 * there is the actual Content-Type under which the image is served (and
which is authoritative)
 * and there is the type attribute on the <object> element, which serves
as a hint to browsers to determine whether they need to bother
downloading the referenced image

Assuming that myimage.gif is indeed a GIF image (and served as such in
HTTP), but that the hint given in the type attribute is wrong (set to
image/png), my reading of the current algorithm is that myimage.gif
would be counted in the PAGE_SIZE_LIMIT and EXTERNAL_RESOURCES since
3.15.1 says to include GIF and JPEG images "irrespective of whether the
type attribute is specified".

I think that a GIF image embedded in an object with a type attribute set
to "image/png" wouldn't actually be part of the ultimate representation
of the document; the current algorithm suggests that it would.

> > * 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
> 
> Part to clarify:
>   2.4.3 HTTP_RESPONSE
>   3.16 PAGE_SIZE_LIMIT
> 
> Suggestion:
>   In 2.4.3 HTTP_RESPONSE, precise the total to which the size of the 
> response should be included (I propose the second as well)
>   In 3.16 PAGE_SIZE_LIMIT, link back to 2.4.3 HTTP_RESPONSE to precise 
> what we mean by "the size of the document" and "the size of the response 
> body". This would be consistent with 3.6 EXTERNAL_RESOURCES that 
> includes such a link.

Agreed.

Dom
Received on Thursday, 12 June 2008 15:58:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:09:09 UTC