- From: Francois Daoust <fd@w3.org>
- Date: Thu, 05 Mar 2009 14:45:38 +0100
- To: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
Hi Kai, Here are a few additional comments to the ones Alan already made: - a few global comments - a few comments on the content itself - a few typos/editorial comments Francois. ===== General ===== - There is a margin problem when <p> are used within <dd>. The "Evaluation procedure" title sometimes looks more linked to the above section than to the section's content. - Some examples do not tell whether they are good or bad examples, e.g. in 3.17 Fonts, 3.18 Graphics for Spacing, 3.21 Navbar. While it may seem obvious, I think we should be consistent and use "Good example"/"Bad example" each time it's necessary as in 3.22 Navigation for instance. - As already mentioned, the References section and references in the text should be polished according to the manual of style: http://www.w3.org/2001/06/manual/#References ===== Comments on content ===== 1.2 Relationship to mobileOK Basic Tests. ----- About the second paragraph: in addition to Alan's comment, I find it slightly too negative. I read it as saying "mobileOK is useless for anything different than the DDC". I'd prefer a more positive view where mobileOK and DDC are a solid base and where additional work is required to further enhance user experience on more advanced devices. Actually, what I have in mind is exactly the abstract of the mobileOK spec :) http://www.w3.org/TR/mobileOK-basic10-tests/#abstract 2.1 Evaluation scope ----- I probably missed something. I don't understand the purpose of this section, or rather I don't understand how it affects the rest of the document. In particular, why would it be needed to express the scope of evaluation using URI patterns to run the evaluation procedures? 3.3 Avoid Free text ----- What is an <input type=""> element? The default value for the type attribute is "text", but it only applies when the attribute is not defined. Having an empty value is not valid, AFAICT. 3.4 Background Image readability ----- A reference to the Ishihara Test for Color Blindness would be useful (still applies if we end up with different test(s) of course) 3.9 Clarity ----- Add a reference to a definition of the Fogg test? 3.15 Deficiencies ----- The example seems to say that using tables for layout is good except for a few devices. While I understand there may be a couple of cases where CSS doesn't give you what you want, I don't think we should recommend or use that as an example. 3.17 Fonts ----- About "4. Check the presence of the *face* element and if only one font has been defined". What is a "face" element? Do you mean *font*? 3.18 Graphics for Spacing ----- The note catches the eye, but I don't really understand why it needs to be there. I would remove the note, the examples already mention small images. 3.26 Page Title ----- I don't understand the purpose of the second check "Check that the title does not repeat unchanged across more than 3 pages". What is it supposed to cover? 3.30 Style Sheets Size ----- As mentioned on the call, I'd add "bandwidth" to the list of Relevant Device Capabilities (well, ok, that's not really a device capability, but I note it's already in 3.25 Page Size Usable anyway). 3.34 Tables layout ----- I'm not sure I understand exactly what is behind "a grid layout that auto adjusts vertically". I understand CSS cannot be used to make each and every author's dream come true, but I'm a bit wary about the conclusion. Using tables for layout is still a bad idea, and CSS limitations may be overcome by a bit of Javascript instead. See, e.g.: http://developer.yahoo.com/yui/grids/ http://randysimons.com/pagina_129_NL.xhtml It has the double benefit that it can degrade gracefully and remain accessible (with the cost of requiring Javascript support and a few additional KB to render the page). In short, I'm not in favor of "It must be recognized therefore that some layouts can currently only be achieved using tables" ===== Typos/Editorial comments ===== 3.1 Access keys ----- missing ":" after "in any of three ways" 3.7 Central Meaning ----- About the evaluation procedure, the double negation in "Check if none of the main content of the web page is visible without scrolling" makes it hard to read. -> "Make sure part of the main content of the Web page is visible without scrolling" 3.12 Control Labeling ----- "a persons name" -> "a person's name" 3.14 Cookies ----- "funcionality" -> "functionality" 3.15 Deficiencies ----- "Rather the test" -> "The test is rather" 4.22 Navigation ----- That should be "*3.22* Navigation" 3.23 Non-text alternatives ----- The formatting of the evaluation procedure looks weird since the first check is not in the <ul> 3.28 Scrolling ----- "loose" -> "lose" 3.30 Style Sheets size ----- "Check if are" -> "Check if there are" 3.33 Tab Order ----- "Sumbit" -> "Submit" 3.36 Testing ----- - "if this content been tested" -> "if this content *has* been tested" - "beenn" -> "been" - W3C Checker -> W3C mobileOK Checker (but we may want to be more generic here, e.g. "with *a* mobileOK Checker")
Received on Thursday, 5 March 2009 13:46:17 UTC