Belated comments on MWABP

Dear all,

I am sorry for the lateness of these comments. This is my review and not that of DAP (even though it is done as an action item within DAP). Here are some assorted notes:


1.3.2: "Web Widgets Effort" that would be the "W3C Widgets effort", or perhaps the "W3C Widgets family of specifications" (as WebApps call them).

1.5: "The implicit reference to XML suggested by the names is commonly accepted to be an historical anomaly." It's historical for sure, but it's not really an anomaly: it really corresponded to what people were thinking of at the time.

3.1.2.1: Storage has been split from HTML5, and there are several parallel local storage efforts in WebApps. In general it would be good to be more precise: "BONDI [BONDI], HTML5 [HTML5], and Opera Widgets [OPERA]" isn't very helpful. For instance, are you thinking of the BONDI address book interface? Or the file system interface? The calendar API? They can all store local data.

3.2.1.2: Note that some browsers now ship with native JSON parsing.

3.3: "Browsers may have access to information such as: • Pictures, music, and video clips; • Contacts, calendar (PIM data); • Call history; • System data (battery, coverage, roaming, location); • Media recording (record audio/video clip, get new picture); • Device context (e.g. location, connectivity, profile setting)."

I am not aware that there are any plans to grant browsers access to such information gratuitously. They may be granted within web runtimes, but even then with clear restrictions. In general this seems to address implementers more than authors.

3.3.1: Also seems to be more for implementers than authors. This information should be provided in a consistent manner by the UI, not the app. The BP I expected here is the one in 3.3.2.

3.3.3: Again, implementer-orientated. I think that it would be more useful to have separate documents for authors and implementers. Also, the notion that putting notices about usage of a user's personal information in help pages implements a best practice is somewhat dubious. It's hard to find users accessing help pages on a desktop, I don't believe anyone ever does on a mobile (in fact, I'm not sure where I'd find such things).

3.4.1.2 This should also mention that EXI has been registered as an HTTP content coding, and can be used. It has the substantial advantage that in most configurations it is smaller while also requiring fewer cycles to decode.

"For very small files (e.g. <1k) the negative impact of processing may outweigh any small transport gains." Note that for very small files, gzip will render them larger anyway.

3.4.11.1: "Keep the DOM size below 10MB to avoid browser crashes." Providing numbers without telling people how to measure them doesn't help a lot.

3.5.10 "Consider Use of Canvas Tag". I think you mean the "canvas Element" (the same mistake is made several times).

"graphic primatives" -> primitives

"""
SVG is well-suited for graphics that must be scalable and whose components need to be modified (e.g. panning and zooming a map) whereas Canvas is best suited for cases where a static bitmap is sufficient (e.g. drawing a scatter-chart, visual effects, reflections etc).

In most cases Canvas is faster and should be preferred if it meets requirements.
"""

These arguments are all sort of flaky, and sort of wrong. I'd recommend that users look into these options, but not try to contrast them — that's the topic of a Web Graphics Best Practices document.

3.6.4.2: Returning a bland 406 is rude (and hard to understand for users). If a 406, then it ought to be a 406 with a human readable payload explaining why the error is being produced.


Thanks for your work, and best of luck with LC!

-- 
Robin Berjon - http://berjon.com/

Received on Wednesday, 18 November 2009 13:21:28 UTC