This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In short -------- Some XSLT stylesheets directly parse the origin HTML code in search of objects (and/or images) to apply a given test on them. But the Object Element Processing Rule is not implemented in XSLT, and tests thus sometimes include objects that should not be tested. Affected tests -------------- OBJECTS_OR_SCRIPT IMAGES_SPECIFY_SIZE IMAGE_MAPS Description ----------- We should not have templates of the form "html:object", because we have no way to tell whether the matched object is or is not an Included Resource. The closest check to that we have is to ensure that the object is listed under <objects> in the moki, but that does not entail that _this_ particular instance of the object is an Included Resource. Take the following (simplified version of ObjectsOrScriptTest/4): <object data="w3c.gif" type="image/gif" width="127" height="78">W3C</object> <object data="t.gif" type="image/gif" width="1" height="1"> <object data="w3c.gif" type="image/gif"> </object> </object> Since the first object is rendered, there will be an entry for "w3c.gif" in the <objects> section. But the second use of "w3c.gif" is not an Included Resource. The checker still returns a FAIL: <result name="OBJECTS_OR_SCRIPT-6" outcome="FAIL"> <info>FAIL: The content of the object element consists only of white space</info> <code><object data="w3c.gif" type="image/png"> </object></code> </result> Possible solutions ------------------ 1. make sure the objects/images sections in the moki contain all the necessary information to be able to parse these parts directly. This solution would be cleaner in the sense that we'd only have the Object Element Processing Rule defined once (in the Java code), and not duplicated in both the Java code and the XSLT stylesheets. But that means: a) images would have to be duplicated in <images>, or some subsection referencing the different instances of the images within the page has to be added (objects are already duplicated AFAICT, but that may not be so clean. At least, it's not the most compact way we could think of, but given that the presence of objects is likely to be the exception to the rule, that is not such a big deal) b) attributes should be added to the objectInfo/imageInfo elements so that we don't have to parse the HTML code again, to note that the object/image is empty, that it does not define width and height attributes, ... 2. implement the Object Element Processing Rule in XSLT (Dom had started implementing the algorithm for EXTERNAL_RESOURCES and PAGE_SIZE_LIMIT, but I removed it since it was not necessary anymore for these tests) I guess the solution is less elegant, but easier to implement. I'm assigning the bug to myself and start implementing solution 2. unless someone objects...
I reintroduced some functions around Included Resources in includedResources.xsl and used them for the tests that (really) apply on Included Resources: GRAPHICS_FOR_SPACING IMAGE_MAPS IMAGES_SPECIFY_SIZE I added a few more tests in the process: GRAPHICS_FOR_SPACING 5 check that only Included Resources are taken into account IMAGES_SPECIFY_SIZE 11 check that only Included Resources are taken into account IMAGES_SPECIFY_SIZE 12 check that Included Resources are taken into account indeed IMAGES_SPECIFY_SIZE 13 check that the code works when the same object is defined twice and completed: IMAGE_MAPS 4 more complete case that includes an input element in a fallback of an Included Resource (it should be taken into account, because that part applies in an "absolute" form on all input elements)
The OBJECTS_OR_SCRIPT test was applied to all objects that appeared in the retrieved resources of the moki. This matched the Object Element Processing Rule almost perfectly except when the same object was defined twice within the page, see the example in the test suite: OBJECTS_OR_SCRIPT 4 I updated the ObjectsOrScriptTest.xsl stylesheet to only process resources that match the Object Element Processing Rule. The bug should thus now be fixed for good.