- From: Zev Blut <zb@ubit.com>
- Date: Fri, 03 Mar 2006 13:12:54 +0900
- To: public-bpwg-comments@w3.org
Hello, 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 practices" 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: http://www.nttdocomo.co.jp/english/p_s/i/tag/object.html 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 user. 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