W3C home > Mailing lists > Public > public-bpwg-comments@w3.org > January to March 2006

Comments on the Mobile Web Best Practices 1.0 (W3C Working Draft 13 January 2006) document

From: Zev Blut <zb@ubit.com>
Date: Fri, 03 Mar 2006 13:12:54 +0900
To: public-bpwg-comments@w3.org
Message-ID: <op.s5tknsiartshzt@>


I sent this mail out on the Febuary deadline of the 17th, but I must
have made a mistake when answering the archiving approval form.  Just
in case it is not too late here are my comments.


I would like to offer a few comments regarding the Mobile Web Best
Practices document. Below is a list of section numbers of the related
items in the document with my comments and questions.

1.4 Default Delivery Context
There is an entry for screen width, but not height. I think that there
should be some value for a default screen height.

2.2 Input
Discusses the potential lack of back button support, but in section 1.4
the default device supports XHTML-Basic. Is it not reasonable that if
the default is assuming XHTML-Basic then the target default handsets
have back buttons?

5.1.3 Work around deficient implementations
"It is recognized that content providers may need to violate specific
best practices in order to support their intentions on devices that
exhibit deficiencies in implementation. If a device is not known to
have specific limitations then content providers must comply with best

My question is the use of "must comply" is a bit strong, because there
can be cases where developers and the W3C differ in opinion on whether
a certain device has limitations. In areas where interpretations
differ this may prevent the developer from getting the "mobileOK"
mark. Who and or how are agreements going to be made about when a
device is known to have specific limitations?

5.2.1 URIs of Site Entry points
What does the group consider a proper range for short URLs?

5.3.4 Navigation Bars etc.
This is a good idea, but it makes me wonder how possible the one web
vision becomes. If one wants to create a page that can provide an
optimal display, the developer would need to do quite some work or use
a powerful platform. I fear that some developers may give up trying to
get the mobileOK mark if it becomes too difficult.

5.4.5 Non Text Items
The way that current i-mode handsets deal with handsets that cannot
support the object tag differs from this recommendation. This may make
many i-mode sites break the best practices rules. You can refer to the
following link for more detail:


5.4.6 Image Size
[IMAGES_SPECIFY_SIZE] Are there actual examples where not setting the
width and height of an image actually hurts the display of the image
by the browser? I am not so sure how necessary this is, especially
when considering that providing this information increases the size of
the page.

5.4.13 Error Messages
This is also a great idea, but some handsets ignore the developer's
custom HTTP 5xx response and shows a built in error message to the

5.4.14 Cookies
Does this prevent systems that make use of Set-Cookie to determine if
the phone supports cookies from getting the mobileOK mark?

That is all of my comments. Thank you for your time.

Zev Blut
Received on Friday, 3 March 2006 04:13:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:01:49 UTC