W3C home > Mailing lists > Public > public-bpwg@w3.org > April 2008

RE: mobileOK basic issues

From: Miguel Garcia <miguel.garcia@fundacionctic.org>
Date: Thu, 17 Apr 2008 11:37:00 +0200
Message-ID: <09700B613C4DD84FA9F2FEA521882819034F0781@ayalga.fundacionctic.org>
To: <public-bpwg@w3.org>
Cc: "Dominique Hazael-Massieux" <dom@w3.org>

Hi, 

>-----Mensaje original-----
>>De: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] En
>>nombre de Dominique Hazael-Massieux
>>Enviado el: lunes, 14 de abril de 2008 17:15
>>Para: public-bpwg
>>Asunto: 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 &lt;object&gt; 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
>>
I'm not sure which option should be the best. I'm undecided between 1
and 2. Option 1 is the 'easy' one, just publish mobileOK basic with a
known little bug but it leaves a bad taste in my mouth. I think Sean's
proposed algorithm is a bit complicated (I need to read it 3 times until
I understand it) but a good starting point that just need some
refinement. So I will vote option 2.

I wonder if browsers support this kind of object nesting. Could any one
confirm this or should we check it before making an agreement?

>>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
>>
I agree that option 2 (leave for next version) is the optimal choice so
in next version we could take into account white space and also other
posible options (as check usage of short hand properties) to minize CSS
code.

 
>>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
>>
This issue will only have a big impact in PAGE_SIZE_LIMT if there are a
lot of objects and in 'real life' also depending on browser behavior (if
it uses a HEAD or GET request). Adding a HEAD request (which could be
1Kb more or less?) to PAGE_SIZE_LIMIT shouldn't make any difference.
I pick option #2

>>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
>>
If we remove the requiment of validity against declared DTD we should
also remove the other validity checks (XHTML Basic 1.1 and MP 1.2)
because we could lead to this scenario. Imagine there is a great request
for adding a new XHTML element (tag) so a new XHMTL Basic 1.2 or MP 1.3
is released. Any web page using this new element won't be Basic 1.1 nor
MP 1.2 grammar valid (remember we removed validity against declared DTD)
so any developer which seek MobileOK Basic conformance must stick to old
grammars or use hacks.

I propose a new algorithm to check grammar validity. 

-- start of proposed algorithm
If the document is not an _XHTML_ document or it is not well-formed,
FAIL

If the document does not declare a public DTD from one well-known
standards organization (W3C,OMA,others...?), FAIL

If the document fails to validate according to its given DOCTYPE:
	If ( regardless of its stated DOCTYPE) the document does not
validate 	against the XHTML Basic 1.1 DTD:
		If ( regardless of its stated DOCTYPE) it does not
validate 		against the XHTML-MP 1.2 DTD, FAIL
-- end of proposed algorithm

Note that in my proposed algorithm the web page must be XHMTL based so
there is no need for SGML-validation. Not sure if there are enough
mobile web browsers that support XHTML to add this requiment.


Miguel
Received on Thursday, 17 April 2008 09:37:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:42:58 UTC