mobileOK basic issues

Hi,

Four issues have been raised on mobileOK Basic since it was published as
Candidate Recommendation, and while there are other blocking factors
preventing that spec to advance further in the Recommendation track, we
need to find resolutions on these issues:
http://www.w3.org/2005/MWI/BPWG/Group/track/products/4

Below comes a summary of the issue, the various proposals made, and a
proposed resolution based on my estimation of the current consensus. I'm
proposing this to be put on the agenda this coming Thursday.

ISSUE-230: OBJECTS_AND_SCRIPTS needs to address <object> with
multiple children
        Our current parsing algorithm in mobileOK basic assumes that an
        <object> element can contain at most another <object> element as
        a direct child; it is not so, and thus our algorithm doesn't
        allow to evaluate documents that use such a construct.
        
        There is a proposed alternative algorithm (suggested by Jo and
        Sean) that takes these cases into account, and seems to reflect
        the group original intent, i.e. to make sure that proper
        fallbacks are offered on non-supported <object> elements.
        
        There are 3 options on the table:
        1. Ignore the bug in our current algorithm as it affects only a
        limited number of real documents (and leave it for the next
        version mobileOK basic)
        2. Use the new proposed algorithm
        3. remove object parsing from mobileOK basis on the basis that
        it is too complex
        
        My feeling is that proposal #2 is probably the best road.
http://www.w3.org/2005/MWI/BPWG/Group/track/issues/230

ISSUE-231: MINIMIZE should take into account whitespace in CSS
        The current test associated with the MINIMIZE Best Practice only
        considers white space and comments included in the markup, not
        in the style sheet. The proposal (from Sean) is to include the
        extraneous white space in style sheets in our calculations.
        
        2 options:
        1. we include CSS white space in the test
        2. we leave that for a next version of mobileOK basic
        
        Given that mobileOK basic 1.0 isn't specifically broken with the
        current test, and to avoid having too many substantive changes
        in the document, I would suggest we go with option #2.
http://www.w3.org/2005/MWI/BPWG/Group/track/issues/231

ISSUE-234: Should Objects Tasted count towards the overall page weight
        We count the cost of redirect pages in our calculation of
        maximum page size allowed, but we don't count the bytes possibly
        requested by a browser when dealing with objects it can't
        handle. Jo suggested we should.
        
        After some experimentation, it appears that most browsers won't
        download an object whose type attribute is set to a media type
        they don't recognize, and most will if the type attribute is not
        set. So we ought to count unrecognized objects whose type
        attribute is not set.
        
        Again, two options:
        1. we add that algorithm in our calculation of PAGE_SIZE_LIMIT
        2. we keep it for the next version of mobileOK basic (in the
        basis that the test is not broken)
        
        It's not clear that there is any consensus on the topic - I
        would personally opt for option #2 again because that's what has
        been picked for the two previous ones. (more seriously, because
        I think mobileOK basic needs more to be finished than perfect)
http://www.w3.org/2005/MWI/BPWG/Group/track/issues/234

ISSUE-240:
        The test that requires a page to be valid to its declared DTD is
        problematic for checkers, since it requires support for
        SGML-validation (for HTML 4.x and ancestors) and it requires
        downloading DTD from unknown locations when the referenced DTD
        isn't a well-known one. 
        
        Two proposals have been made (see a pattern here?):
        1. We remove the test for validity to the declared DTD (on the
        basis that it doesn't add anything directly relevant to the goal
        of mobileOK basic)
        2. We replace it to have it effective only when the declared DTD
        matches a well-known DTD (with an explicit list of DTDs)
        
        There seems to be a mild preference for #2; for sake of not
        having to dwelve in the details of SYSTEM ID, PUBLIC ID,
        equivalent URIs of well-known DTDs, I would personally suggest
        #1 (shocking!).
http://www.w3.org/2005/MWI/BPWG/Group/track/issues/240

Dom

Received on Monday, 14 April 2008 15:17:08 UTC