W3C home > Mailing lists > Public > public-bpwg@w3.org > December 2008

Re: MWABP - a few comments (mostly editorial)

From: Yeliz Yesilada <yesilady@cs.man.ac.uk>
Date: Thu, 4 Dec 2008 13:09:36 +0000
Message-Id: <EAB1C369-BA73-4E1D-A654-C3546E2C48CA@cs.man.ac.uk>
To: MWI BPWG Public <public-bpwg@w3.org>, Adam Connors <adamconnors@google.com>

Hi Adam,

Some comments/suggestions are below:

Abstract:
- Would it be useful to also explicitly highlight that "readers are  
not expected to be familiar with MWBP 1"?

Section 1.2:
- I am not sure if this section is very useful. It looks like this  
section is not very different from the Table of Contents or are you  
planning to add more explanation/definition to this section?

Section 1.4 & some other sections...
- You refer to BP1 in a lot of places but they are not linked to BP1.  
I think it would be good to add links to BP1. It would also be good  
to add a short parag. to BP1 to refer to this document (of-course  
it's better to do this one BP2 is stable).

3. Best Practice Statements
- It would be good to present/explain the principles earlier on in  
the document to show the overall structure of this document. All BPs  
are categorised based on these principles (e.g., personalization) so  
it might be useful to explain them earlier on to set the context.

3.1
- In MWBP, for each BP there is a section that says "What to test"  
which is quite useful for differentiating the BPs that can be  
automatically tested from the ones that cannot be. I wonder if it  
will be useful to add "What to test" for each BP here.

3.1.1.2
This section suggests that using Cookies is a good idea. However, BP1  
suggests not to rely on Cookies. Would it be useful to say something  
about that here?

3.2
The second paragraph here talks about HTTPS and its drawbacks on  
mobile devices. Is there any reason why not include this as a  
separate BP (a BP that mainly focuses on HTTPs)?

3.4.5
This gives a specific example. I think it would be better to remove  
that specific reference as it's better to have a BP which is vendor- 
neutral.

Regards,
Yeliz.

On 28 Nov 2008, at 16:23, Francois Daoust wrote:

>
> Hi Adam,
>
> A few comments on the draft.
>
>
> A couple of comments
> -----
> 3.4.15 Use a Cookieless Domain for Static Content
>  I am wondering: cannot this be achieved with paths as well,  
> restricting the validity of cookies depending on the path of the  
> resources?
>
>
> 3.5.8 Separate Rarely Used Functionality:
>  Do we really want to recommend the use of an "embedded frame"?  
> Does it work on many mobile devices?
>
>
> Overall editorial comment
> -----
> References and cross-references are either missing, incorrect, or  
> do not follow the "usual" pattern, e.g.:
>  1.4: "amplify on the recommendations of the Mobile Web Best  
> Practices (BP1)"
>  1.4.2: "Web Widgets [REF]"
>  1.5: "[DIP]" targets the Mobile Web Best Practices 1.0 specification.
>  3.1.1.2: no link around "3.5.10 Ensure Consistency Between Desktop  
> and Mobile"
>  3.1.1.2: direct link to the Offline Webapps specification
> ... and "how to do it" sections sometimes reference techniques or  
> other specs where a link would be much useful.
>
>
> Typos and editorial comments by section
> (end up with "?" when I'm unsure whether I'm right)
> -----
> 1.5.1: "Ubiquitous Web A*a*pplications" -> "Ubiquitous Web  
> Applications"
>
> 3.1.1.2 ECMAScript Variables:
>   the notion of "pageload" and "across views" may be difficult to  
> grasp.
>
> 3.1.1.2 Cookies:
>   the paragraph does not say that cookies may not be supported or  
> may be turned off. It's only mentioned between parentheses in the  
> following paragraph on Personalized URL. Start with "When supported  
> and active"?
>
> 3.1.1.2 Personalized URL: "After first redirect the user [...] to  
> identify them[...]". -> "After first redirect *users* [...] to  
> identify them[...]"
>
> 3.1.2.2 The use of bold around "should not" in a Rec to be makes it  
> look normative. Normative statements are already misunderstood by  
> everyone, we should probably not insist with fake ones ;-)
>
> 3.2.1.2 "intial" -> "initial"
>
> 3.2.2.1 "signifcant" -> "significant"
>
> 3.2.2.2 "it will not execute" -> actually it will, but will loop on  
> the first statement. "the sensitive content of the datafeed will  
> not execute"?
>
> 3.2.2.2 "same-origin security model" -> "same-origin policy"?
>
> 3.2.3.2 "Safe EVAL" -> any reference to a definition or ways to do  
> that?
>
> 3.3.3 The (already long) title only talks about personal  
> information whereas the BP also talks about device information.
>
> 3.4.3.2 "Consider the following issues" -> "Consider the following  
> possibilities" ?
>
> 3.4.6.1 "fewer, large requests" -> "fewer, larger requests"
>
> 3.4.8.2 "using css positioning and clipping" -> "use CSS  
> positioning and clipping" (and ref)
>
> 3.5.6.2 As mentioned during the call, I do not see why "User Agent  
> Profile" is specifically mentioned here in the sense that DDR or  
> any other means that make the server aware of the device  
> capabilities would also fit the bill.
>
> 3.5.8.2 "On demain" -> "On demand"
>
> 3.6.2.2 "intial" -> "initial"
>
> Francois.
>
Received on Thursday, 4 December 2008 13:10:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:42:59 UTC