- 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>
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