- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Mon, 26 Mar 2012 15:03:10 +0200
- To: public-mobileok-checker <public-mobileok-checker@w3.org>
So, why do I want a new checker? The current checker verifies tests that were derived from the Mobile Web Best Practices which for all intent and purposes where finished in July 2007, that is before the arrival of the 1st iPhone, which I think is fair to say changed completely the way people have been using and developing for the Mobile Web. While the Best Practices themselves are for the most part still relevant, their derivation in mobileOK are based on the so called "default delivery context", an abstract mobile browser that is years behind what current browsers do (no support for PNG, JavaScript, Media Queries, etc). So, the output of the current checker has some useful parts, but most of them are drowned under the noise created by the outdated ones. In terms of the software base, the overall architecture of the tool is not necessarily bad (if not very efficient): * the code is split between a library and a front-end (both in Java) * the library does it checks with separate layers for: - retrieving resources, parsing them (recursively as needed) - deriving facts about the retrieved resources (size, validity, http status, etc) into an XML structure (called moki) - analyzing these facts (via XSLT style sheets) into a final XML structure that reports the mobileOK analysis of the checked document We know that the library has been re-used in a number of other projects; I'm not clear whether the integration is done at the Java level, or via the produced XML output. I don't know (yet?) if that re-use is sufficient to justify ensuring some form of compatibility or not. One of its big weaknesses that would have to be fixed is the way it parses resources: because of the "default delivery context" assumption, it behaves as a very dumb-down browser (e.g. only downloading type='handset' stylesheets, or downloading all background images quoted in a stylesheet no matter whether it is actually downloaded by a real browser, not downloading scripts, etc). As I'll develop in a separate message, I think the only good way to fix this is to use an actual Web browser to do the parsing/retrieving. Dom
Received on Monday, 26 March 2012 13:07:33 UTC