RE: On the way to v1.0: some new tests/bugs/fixes/questions

Hi,

We have made a partial commit that fixes some of your reported bugs. But
there are also some bugs that need some clarification.

>
>New bugs
>--------
>- ObjectsOrScript: the checker applies some of the tests to more than
>just "Included Resources": OBJECTS_OR_SCRIPT-5 and OBJECTS_OR_SCRIPT-9
>are applied to all objects, whereas OBJECTS_OR_SCRIPT-6,
>OBJECTS_OR_SCRIPT-8, and OBJECTS_OR_SCRIPT-10 seem not to be
>   see tests OBJECTS_OR_SCRIPT 4 and OBJECTS_OR_SCRIPT 5
>

Tests OBJECTS_OR_SCRIPT 4 and OBJECTS_OR_SCRIPT 5 aren't on CVS so we
couldn't check exactly where is the problem.


>- ImagesSpecifySize: the checker checks all images, even those that are
>not "Included Resources"
>   see tests OBJECTS_OR_SCRIPT 4 and OBJECTS_OR_SCRIPT 5

Only images considered "Included Resources" are now checked.

>- ExternalResources: caching directives are not taken into account (an
>image is counted only once, even if it's served with a no cache
directive)
>

Caching directives are not taken into account. 

>- StyleSheetsUse: STYLE_SHEETS_USE-4 is applied to each style element.
>   see test STYLE_SHEETS_USE 9
>   I interpret "If all styles are restricted to presentation media
types
>other than "handheld" or "all" by means of @media at-rules, warn" as
>being global, i.e. when all styles are taken together, if there are all
>restricted to presentation media other than "handheld" or "all" by
means
>of @media at-rules, warn.
>   In short, the following (defined in the same page) should not
trigger
>any WARN IMO, because the first style element contains some style rule
>that applies to all presentations:
>    <style type="text/css">body { color:green; }</style>
>    <style type="text/css">@media tv { body { color: red; } }</style>
>

When we implemented this test we interpreted that each stylesheet should
be checked individually. Let me move this issue to Jo.

>- StyleSheetsUse: STYLE_SHEETS_USE-4 is applied on style elements
>restricted to a media type different from "handheld" or "all" va the
>media attribute.
>   see test STYLE_SHEETS_USE 10
>   In short, the following (stupid) code should not trigger any WARN
>IMO, because the style is already restricted via the media attribute:
>    <style type="text/css" media="tv">@media tv { body { color: red; }
>}</style>
>

We're currently working on this, it's already fixed for stylesheets
included by the style tag (although not commited yet) but not for linked
styles (included by link tag)

>- ContentFormatSupport: the CSS parser crashes when the external
>stylesheet referenced by the page is the XHTML page
>   see test CONTENT_FORMAT_SUPPORT 18
>

It crashed when trying to check an CSS resource that was actually
another type of document. Now the exception is catched and ignored.


>- ContentFormatSupport: there is no info on the validity of objects
>within the moki. There is thus no way to check that an image defined as
>an object is a valid GIF/JPEG image.
>   see test CONTENT_FORMAT_SUPPORT 20
>

Added in moki document an "imageInfo" block to each object that is an
image. The "imageInfo" block has the same structure as the respective
"imageInfo" block existing for images.

>- Using the checker without a running Internet connection has some
weird
>consequences.
>   run OBJECTS_OR_SCRIPT 1 without an Internet connection.
>   The code defines a dummy URI at example.org when javascript links
are
>detected. I'm not sure why. What is sure is that without an
>up-and-running Internet Connection, example.org cannot be resolved, and
>this yields the following error message:
>   <test name="LINK_TARGET_FORMAT" outcome="FAIL">
>    <result name="LINK_TARGET_FORMAT-1" outcome="WARN">
>     <info>WARN: The linked resource
>http://example.org/#javascript%3Aalert%28%27javascript%3A+scripting%27%
29%3
>B
>is in a format ("") that may not be appropriate for a mobile
device</info>
>    </result>
>    <result name="HTTP_RESPONSE-1" outcome="FAIL">
>     <info>FAIL: The request to the resource
>http://example.org/#javascript%3Aalert%28%27javascript%3A+scripting%27%
29%3
>B
>does not result in a valid HTTP response (because of network-level
>error, DNS resolution error, or non-HTTP response) </info>
>    </result>
>   </test>
>   -> Can we get rid of this hack somehow?
>

We couldn't reproduce this error. 

Regards,
Miguel and Abel

Received on Thursday, 17 July 2008 11:01:31 UTC