W3C home > Mailing lists > Public > public-bpwg@w3.org > March 2009

Comments on Addendum to Mobile Web Best Practices

From: Francois Daoust <fd@w3.org>
Date: Thu, 05 Mar 2009 14:45:38 +0100
Message-ID: <49AFD782.1060406@w3.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:00 UTC