Responses to MWABP LC comments from Marc Wilson.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Responses to MWABP LC comments from Marc Wilson.

Adam Connors
Hi Marc,

Thanks for the detailed comments. Ultimately we'll make formal resolutions on each and do our best to answer your points in the document. In the meantime though I was asked to make initial responses directly (and on the mailing) list to stimulate some discussion.
Note that these are just my thoughts / opinions -- we'll use this email (and any follow-up responses you might want to send) as the basis for discussion on our next call.

(Nb also, a few other people have open issues on the LC list for MWABP which will get the same treatment, I'm just starting here because you have so far made the most comments).


thanks,

Adam.

3.1.1.1
Cookies being disabled by devices isn't a mobile specific issue as it
also applies to desktop. New devices Android, iPhone, Nokia s60 and
beyond, Palm, etc.. all ship with cookies enabled by default.
Maybe it is covered elsewhere but there is no mention of privacy
issues sending data back to the server via cookies, only the network
concern. With access to very sensitive data like location this might
be worth flagging for mobile.

I agree that many of the issues around cookies and mobile seem less
relevant with newer devices, but the additional complexity of the MNO
interfering with requests probably means it's worth still calling this out.

Regards security, yes, we had some comments on this in earlier drafts
of the document but ultimately cut them since security is such a tricky
issue to engage with. The issue of location, for example, doesn't just
apply with cookies... Would you go so far as recommending that all
requests containing location information should be encrypted ? That might
be overkill in some scenarios.

I have to admit we've slightly chickened out here in the absence of any
concrete recommendations that we all felt comfortable making.



3.1.2.1
Given that HTML5 is now drafting specs for a Web Storage and Web
Database that is shipping in iPhone 3.x and Android 2.x it seems odd
to me to mention Bondi and Opera widgets in this context, especially
given the focus of this document is for applications in a browser.
The second point of "making updates locally at first" should be
supplemented with a need to add UI treatment to make it clear to the
user that their data is uncommitted.

We have another comment on these references so we'll look into it. The goal
is not to make this document dependent on any particular technology, hence
the smorgasbord of references.

I agree on the "uncommitted" comment and think we should add a sentence
to cover this.

3.2.1.2
One way to be able to eval() untrusted data is to perform the JSON
escaping on the server where the processing power is less constrained
than on the client since we are downloading the data anyway
(presumably).

That's kind of what I meant, "ensure that user-generated content is
correctly escaped", I'll add "on the server" to the end of this sentence.

3.3.1.1
nit: double period at the end of first sentence

Fixed

3.3.1.2
AFAIK some devices will provide UI indications in their status bar of
network activity, with a spinner or mobile data flow indicators. While
informing users of background network usage may be desirable, it might
be overkill to have 3 separate indicators. Maybe you could suggest to
provide UI on devices where the browser does not do it natively

I'd be concerned this would just complicate things -- you'd then wonder
whether you had to produce a different variant of your application for different
browsers, which we know no-one will ever really do for this kind of thing... (or
at least, I wouldn't). I hope the phrasing "an icon is usually sufficient" is suitably
relaxed that no-one will take this as a strong recommendation to implement features
that might not be necessary in some scenarios.

3.3.2.2
"must" seems a bit strong here. Some applications that inherently
require network access (think IM, mapping, etc..) will not be usable
with no network access, so providing such an option should not be
mandatory.

Agreed. I'll change must to should. (Must has rather specific meanings in
w3c anyway which are best avoided in this context).

3.3.4
Consider adding something along the lines of
"If devices persist authentication tokens then the server MUST
invalidate them if the user changes or resets their password"
This is especially important with mobile devices that are often
lost/stolen and provides a user with a way to after the fact lock the
phone out of web applications it had previously been authorised for.

This is a good point. I think we should add something along these lines.


3.4.4.2
One suggestion to add here is to prioritise your network requests and
throttle the number of connections in order to ensure that high
priority requests are not blocked or slowed by lower priority
requests, if they are unable to be batched.

Good point. I think we should add that to the list of suggestions.

3.4.5.1
This is a dangerous recommendation when even modern browsers like
mobile safari on iPhone have a limited browser cache entry size of
25kb uncompressed. It is a good recommendation but relies partially on
the assumption that the caching of a single large resource is no worse
than multiple single resources.

You mean because a document > 25kb won't get cached... Is that still an issue
on iPhone... The 25kb thing I thought was just a pathological screw-up in very
first versions and had been resolved now...

I wouldn't want to put in a warning in response to a bug in a specific handset, though
I think a "within reason" comment could be called for.

3.4.10
Although this is a different point to 3.1.1 they are related and maybe
should be merged, colocated or reference each other

We had it like this in an earlier draft and decided to call out separately since the
intent of the recommendation is sufficiently different.

3.4.11
I don't like this recommendation.
What does "reasonable" mean? What about "manageable"?
What is a 10Mb DOM?
How should people measure it?
Why was this value chosen? (Recent high end browser handle much larger DOMs)

This number came from the people who built a certain well known mobile
Web email-client based on their iphone / android testing... I agree that this BP is
hard to act on for all the reasons you raise however, so I think we should tighten
up the language here.

If you have any suggestions for how to improve this BP that would be much
appreciated.

It is unclear what the recommendation to "Clip content and separate
content onto separate pages" means.
Are you saying to make top level URL changes to download new pages
(and parse new JS)? If you are I think that is a bad recommendation as
the latency hit is quite bad.
Typically a better solution is to rather than hide non visible DOM
elements, to instead remove these elements from the DOM altogether and
recreate them as needed.

The intent of "clip content" was kind of what you describe: e.g. If a user has 3000 emails
don't try to display them all on the screen, display the first 10, and a link to dynamically load
the next 10... We should tidy up the language here to avoid this confusion.

3.5.1.1
App Cache link should now point to: http://www.w3.org/TR/html5/offline.html

Will do.

3.5.1.2
I like these recommendations. Good stuff.

One thing you could add is to initiate any network requests before JS
parsing begins, so that the network request is in flight while the
parse occurs. This can work well for applications that require fresh,
rather than, cached data to be useful as it parallelises the network
request and JS parse.

Good point.

3.5.4
The tone of this recommendation is odd. I agree that the user
shouldn't be warped away from their current view but there are cases
where programatically setting the focus is very desirable if the next
user action is expected to be character input and setting the focus in
these cases should be recommended.

Agreed. The thing that this BP warns against is quite pathological, and it
inadvertently might discourage people from changing focus in legitimate
use-cases.


3.5.6.2
Maybe a mention of the format of the number used in the tel: URI
A best practice is to use a full international number prefixed by +
and a country code.
This is recommended in the RFC so it isn't necessary to include it
here, but it is currently quite common for people to use tel: URIs
with only local numbers that don't work in a different calling prefix
or different country.

Yep, for convenience I think this is worth calling out in this doc since it
would be an easy mistake to make.

3.5.11.2
Setting minimum-scale=1.0,maximum-scale=1.0 has accessibility impacts
as it usually makes it impossible to manually zoom into the screen,
which can be useful for visually impaired users.

Good point. Will remove.

3.6.3.2
Class 2 and 3 are very similar, the difference being the advanced APIs
available in class 3. For example, the iPhone v2.0 browser was class 2
and v3.0 is class 3 by your classification. Typically these
differences don't require different variants, the class 3 device just
has a richer and faster experience. A more useful axis is touch screen
v non touch screen.

Fair point. We'll have to discuss. These 3 classes started out WML/XHTML/AJAX
but we shunted them up since WML isn't very relevant to a doc on Web Application
BPs... Agree that the distinction between 2/3 is not very relevant at this point in time.

Perhaps we should just have two device classes in this example.

3.6.4
There was no mention of <noscript>. Is this deliberate?

3.6.4.2
Are we really recommending to send the user back a HTTP error code
that essentially provides no information to the user as to why their
request is "Not Acceptable". I understand this may be the 'correct'
behaviour, but the UX it results in is hideous.

Both good questions, I can't remember the outcome. We'll discuss in the group.





thanks, please get back to me with any follow-up questions / clarifications / or if you have
a suggestion for 3.4.11 (or any other BPs for that matter).

Regards,

Adam.



Reply | Threaded
Open this post in threaded view
|

Re: Responses to MWABP LC comments from Marc Wilson.

Marc Wilson-3
On Fri, Nov 20, 2009 at 12:19 PM, Adam Connors <[hidden email]> wrote:

> Hi Marc,
>
> Thanks for the detailed comments. Ultimately we'll make formal resolutions
> on each and do our best to answer your points in the document. In the
> meantime though I was asked to make initial responses directly (and on the
> mailing) list to stimulate some discussion.
>
> Note that these are just my thoughts / opinions -- we'll use this email (and
> any follow-up responses you might want to send) as the basis for discussion
> on our next call.
>
> (Nb also, a few other people have open issues on the LC list for MWABP which
> will get the same treatment, I'm just starting here because you have so far
> made the most comments).
>
>
>
> thanks,
>
> Adam.
>
> 3.1.1.1
> Cookies being disabled by devices isn't a mobile specific issue as it
> also applies to desktop. New devices Android, iPhone, Nokia s60 and
> beyond, Palm, etc.. all ship with cookies enabled by default.
>
> Maybe it is covered elsewhere but there is no mention of privacy
> issues sending data back to the server via cookies, only the network
> concern. With access to very sensitive data like location this might
> be worth flagging for mobile.
>
>
> I agree that many of the issues around cookies and mobile seem less
> relevant with newer devices, but the additional complexity of the MNO
> interfering with requests probably means it's worth still calling this out.
>
>
> Regards security, yes, we had some comments on this in earlier drafts
> of the document but ultimately cut them since security is such a tricky
> issue to engage with. The issue of location, for example, doesn't just
>
> apply with cookies... Would you go so far as recommending that all
> requests containing location information should be encrypted ? That might
> be overkill in some scenarios.
>
> I have to admit we've slightly chickened out here in the absence of any
>
> concrete recommendations that we all felt comfortable making.
>
>
> 3.1.2.1
> Given that HTML5 is now drafting specs for a Web Storage and Web
> Database that is shipping in iPhone 3.x and Android 2.x it seems odd
>
> to me to mention Bondi and Opera widgets in this context, especially
> given the focus of this document is for applications in a browser.
> The second point of "making updates locally at first" should be
> supplemented with a need to add UI treatment to make it clear to the
>
> user that their data is uncommitted.
>
> We have another comment on these references so we'll look into it. The goal
> is not to make this document dependent on any particular technology, hence
>
> the smorgasbord of references.
>
> I agree on the "uncommitted" comment and think we should add a sentence
> to cover this.
>
> 3.2.1.2
> One way to be able to eval() untrusted data is to perform the JSON
>
> escaping on the server where the processing power is less constrained
> than on the client since we are downloading the data anyway
> (presumably).
>
> That's kind of what I meant, "ensure that user-generated content is
>
> correctly escaped", I'll add "on the server" to the end of this sentence.
>
> 3.3.1.1
>
> nit: double period at the end of first sentence
>
> Fixed
>
>
> 3.3.1.2
> AFAIK some devices will provide UI indications in their status bar of
> network activity, with a spinner or mobile data flow indicators. While
> informing users of background network usage may be desirable, it might
>
> be overkill to have 3 separate indicators. Maybe you could suggest to
> provide UI on devices where the browser does not do it natively
>
> I'd be concerned this would just complicate things -- you'd then wonder
>
> whether you had to produce a different variant of your application for
> different
> browsers, which we know no-one will ever really do for this kind of thing...
> (or
> at least, I wouldn't). I hope the phrasing "an icon is usually sufficient"
> is suitably
>
> relaxed that no-one will take this as a strong recommendation to implement
> features
> that might not be necessary in some scenarios.
>
>
> 3.3.2.2
> "must" seems a bit strong here. Some applications that inherently
> require network access (think IM, mapping, etc..) will not be usable
> with no network access, so providing such an option should not be
>
> mandatory.
>
> Agreed. I'll change must to should. (Must has rather specific meanings in
>
> w3c anyway which are best avoided in this context).
>
> 3.3.4
> Consider adding something along the lines of
>
> "If devices persist authentication tokens then the server MUST
> invalidate them if the user changes or resets their password"
> This is especially important with mobile devices that are often
> lost/stolen and provides a user with a way to after the fact lock the
>
> phone out of web applications it had previously been authorised for.
>
> This is a good point. I think we should add something along these lines.
>
>
>
> 3.4.4.2
> One suggestion to add here is to prioritise your network requests and
> throttle the number of connections in order to ensure that high
> priority requests are not blocked or slowed by lower priority
>
> requests, if they are unable to be batched.
>
> Good point. I think we should add that to the list of suggestions.
>
>
> 3.4.5.1
> This is a dangerous recommendation when even modern browsers like
> mobile safari on iPhone have a limited browser cache entry size of
> 25kb uncompressed. It is a good recommendation but relies partially on
>
> the assumption that the caching of a single large resource is no worse
> than multiple single resources.
>
> You mean because a document > 25kb won't get cached... Is that still an
> issue
>
> on iPhone... The 25kb thing I thought was just a pathological screw-up in
> very
> first versions and had been resolved now...

I haven't been able to find a definitive source, but
http://rambleon.org/2009/09/05/iphone-caching-redux/
seems to indicate that it might not be an issue on iPhone any more.
If I get time I'll do some investigation of my own.

> I wouldn't want to put in a warning in response to a bug in a specific
> handset, though
>
> I think a "within reason" comment could be called for.
>
> 3.4.10
> Although this is a different point to 3.1.1 they are related and maybe
> should be merged, colocated or reference each other
>
> We had it like this in an earlier draft and decided to call out separately
> since the
>
> intent of the recommendation is sufficiently different.
>
>
> 3.4.11
> I don't like this recommendation.
> What does "reasonable" mean? What about "manageable"?
> What is a 10Mb DOM?
> How should people measure it?
> Why was this value chosen? (Recent high end browser handle much larger DOMs)
>
>
> This number came from the people who built a certain well known mobile
>
> Web email-client based on their iphone / android testing... I agree that
> this BP is
> hard to act on for all the reasons you raise however, so I think we should
> tighten
> up the language here.
>
> If you have any suggestions for how to improve this BP that would be much
>
> appreciated.

Maybe rather than a size in bytes, a metric in terms a number of DOM
elements is more understandable. It may not capture the full memory
footprint, but it is something easily understandable and calculable.

>
> It is unclear what the recommendation to "Clip content and separate
> content onto separate pages" means.
> Are you saying to make top level URL changes to download new pages
> (and parse new JS)? If you are I think that is a bad recommendation as
>
> the latency hit is quite bad.
> Typically a better solution is to rather than hide non visible DOM
> elements, to instead remove these elements from the DOM altogether and
> recreate them as needed.
>
> The intent of "clip content" was kind of what you describe: e.g. If a user
> has 3000 emails
>
> don't try to display them all on the screen, display the first 10, and a
> link to dynamically load
> the next 10... We should tidy up the language here to avoid this confusion.
>
>
> 3.5.1.1
> App Cache link should now point to: http://www.w3.org/TR/html5/offline.html
>
> Will do.
>
>
> 3.5.1.2
> I like these recommendations. Good stuff.
>
> One thing you could add is to initiate any network requests before JS
> parsing begins, so that the network request is in flight while the
> parse occurs. This can work well for applications that require fresh,
>
> rather than, cached data to be useful as it parallelises the network
> request and JS parse.
>
> Good point.
>
>
> 3.5.4
> The tone of this recommendation is odd. I agree that the user
> shouldn't be warped away from their current view but there are cases
> where programatically setting the focus is very desirable if the next
>
> user action is expected to be character input and setting the focus in
> these cases should be recommended.
>
> Agreed. The thing that this BP warns against is quite pathological, and it
>
> inadvertently might discourage people from changing focus in legitimate
> use-cases.
>
>
>
> 3.5.6.2
> Maybe a mention of the format of the number used in the tel: URI
> A best practice is to use a full international number prefixed by +
> and a country code.
> This is recommended in the RFC so it isn't necessary to include it
>
> here, but it is currently quite common for people to use tel: URIs
> with only local numbers that don't work in a different calling prefix
> or different country.
>
> Yep, for convenience I think this is worth calling out in this doc since it
>
> would be an easy mistake to make.
>
>
> 3.5.11.2
> Setting minimum-scale=1.0,maximum-scale=1.0 has accessibility impacts
> as it usually makes it impossible to manually zoom into the screen,
> which can be useful for visually impaired users.
>
> Good point. Will remove.
>
>
> 3.6.3.2
> Class 2 and 3 are very similar, the difference being the advanced APIs
> available in class 3. For example, the iPhone v2.0 browser was class 2
> and v3.0 is class 3 by your classification. Typically these
>
> differences don't require different variants, the class 3 device just
> has a richer and faster experience. A more useful axis is touch screen
> v non touch screen.
>
> Fair point. We'll have to discuss. These 3 classes started out
> WML/XHTML/AJAX
>
> but we shunted them up since WML isn't very relevant to a doc on Web
> Application
> BPs... Agree that the distinction between 2/3 is not very relevant at this
> point in time.
>
> Perhaps we should just have two device classes in this example.
>
>
>
> 3.6.4
> There was no mention of <noscript>. Is this deliberate?
>
> 3.6.4.2
> Are we really recommending to send the user back a HTTP error code
> that essentially provides no information to the user as to why their
>
> request is "Not Acceptable". I understand this may be the 'correct'
> behaviour, but the UX it results in is hideous.
>
> Both good questions, I can't remember the outcome. We'll discuss in the
> group.
>
>
>
>
>
> thanks, please get back to me with any follow-up questions / clarifications
> / or if you have
> a suggestion for 3.4.11 (or any other BPs for that matter).
>
>
> Regards,
>
> Adam.
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Responses to MWABP LC comments from Marc Wilson.

Adam Connors
Thanks Marc,

The text of this section has now been tightened up to be more explicit without referring to any specific numbers because a) They'll quickly go out of date; b) We have no easy way of  describing how to check them... Hopefully the new version will answer your concerns. I'll send you a link as soon as the updated version is published.

Regards,

Adam.

On Mon, Nov 23, 2009 at 12:38 PM, Marc Wilson <[hidden email]> wrote:
On Fri, Nov 20, 2009 at 12:19 PM, Adam Connors <[hidden email]> wrote:
> Hi Marc,
>
> Thanks for the detailed comments. Ultimately we'll make formal resolutions
> on each and do our best to answer your points in the document. In the
> meantime though I was asked to make initial responses directly (and on the
> mailing) list to stimulate some discussion.
>
> Note that these are just my thoughts / opinions -- we'll use this email (and
> any follow-up responses you might want to send) as the basis for discussion
> on our next call.
>
> (Nb also, a few other people have open issues on the LC list for MWABP which
> will get the same treatment, I'm just starting here because you have so far
> made the most comments).
>
>
>
> thanks,
>
> Adam.
>
> 3.1.1.1
> Cookies being disabled by devices isn't a mobile specific issue as it
> also applies to desktop. New devices Android, iPhone, Nokia s60 and
> beyond, Palm, etc.. all ship with cookies enabled by default.
>
> Maybe it is covered elsewhere but there is no mention of privacy
> issues sending data back to the server via cookies, only the network
> concern. With access to very sensitive data like location this might
> be worth flagging for mobile.
>
>
> I agree that many of the issues around cookies and mobile seem less
> relevant with newer devices, but the additional complexity of the MNO
> interfering with requests probably means it's worth still calling this out.
>
>
> Regards security, yes, we had some comments on this in earlier drafts
> of the document but ultimately cut them since security is such a tricky
> issue to engage with. The issue of location, for example, doesn't just
>
> apply with cookies... Would you go so far as recommending that all
> requests containing location information should be encrypted ? That might
> be overkill in some scenarios.
>
> I have to admit we've slightly chickened out here in the absence of any
>
> concrete recommendations that we all felt comfortable making.
>
>
> 3.1.2.1
> Given that HTML5 is now drafting specs for a Web Storage and Web
> Database that is shipping in iPhone 3.x and Android 2.x it seems odd
>
> to me to mention Bondi and Opera widgets in this context, especially
> given the focus of this document is for applications in a browser.
> The second point of "making updates locally at first" should be
> supplemented with a need to add UI treatment to make it clear to the
>
> user that their data is uncommitted.
>
> We have another comment on these references so we'll look into it. The goal
> is not to make this document dependent on any particular technology, hence
>
> the smorgasbord of references.
>
> I agree on the "uncommitted" comment and think we should add a sentence
> to cover this.
>
> 3.2.1.2
> One way to be able to eval() untrusted data is to perform the JSON
>
> escaping on the server where the processing power is less constrained
> than on the client since we are downloading the data anyway
> (presumably).
>
> That's kind of what I meant, "ensure that user-generated content is
>
> correctly escaped", I'll add "on the server" to the end of this sentence.
>
> 3.3.1.1
>
> nit: double period at the end of first sentence
>
> Fixed
>
>
> 3.3.1.2
> AFAIK some devices will provide UI indications in their status bar of
> network activity, with a spinner or mobile data flow indicators. While
> informing users of background network usage may be desirable, it might
>
> be overkill to have 3 separate indicators. Maybe you could suggest to
> provide UI on devices where the browser does not do it natively
>
> I'd be concerned this would just complicate things -- you'd then wonder
>
> whether you had to produce a different variant of your application for
> different
> browsers, which we know no-one will ever really do for this kind of thing...
> (or
> at least, I wouldn't). I hope the phrasing "an icon is usually sufficient"
> is suitably
>
> relaxed that no-one will take this as a strong recommendation to implement
> features
> that might not be necessary in some scenarios.
>
>
> 3.3.2.2
> "must" seems a bit strong here. Some applications that inherently
> require network access (think IM, mapping, etc..) will not be usable
> with no network access, so providing such an option should not be
>
> mandatory.
>
> Agreed. I'll change must to should. (Must has rather specific meanings in
>
> w3c anyway which are best avoided in this context).
>
> 3.3.4
> Consider adding something along the lines of
>
> "If devices persist authentication tokens then the server MUST
> invalidate them if the user changes or resets their password"
> This is especially important with mobile devices that are often
> lost/stolen and provides a user with a way to after the fact lock the
>
> phone out of web applications it had previously been authorised for.
>
> This is a good point. I think we should add something along these lines.
>
>
>
> 3.4.4.2
> One suggestion to add here is to prioritise your network requests and
> throttle the number of connections in order to ensure that high
> priority requests are not blocked or slowed by lower priority
>
> requests, if they are unable to be batched.
>
> Good point. I think we should add that to the list of suggestions.
>
>
> 3.4.5.1
> This is a dangerous recommendation when even modern browsers like
> mobile safari on iPhone have a limited browser cache entry size of
> 25kb uncompressed. It is a good recommendation but relies partially on
>
> the assumption that the caching of a single large resource is no worse
> than multiple single resources.
>
> You mean because a document > 25kb won't get cached... Is that still an
> issue
>
> on iPhone... The 25kb thing I thought was just a pathological screw-up in
> very
> first versions and had been resolved now...

I haven't been able to find a definitive source, but
http://rambleon.org/2009/09/05/iphone-caching-redux/
seems to indicate that it might not be an issue on iPhone any more.
If I get time I'll do some investigation of my own.

> I wouldn't want to put in a warning in response to a bug in a specific
> handset, though
>
> I think a "within reason" comment could be called for.
>
> 3.4.10
> Although this is a different point to 3.1.1 they are related and maybe
> should be merged, colocated or reference each other
>
> We had it like this in an earlier draft and decided to call out separately
> since the
>
> intent of the recommendation is sufficiently different.
>
>
> 3.4.11
> I don't like this recommendation.
> What does "reasonable" mean? What about "manageable"?
> What is a 10Mb DOM?
> How should people measure it?
> Why was this value chosen? (Recent high end browser handle much larger DOMs)
>
>
> This number came from the people who built a certain well known mobile
>
> Web email-client based on their iphone / android testing... I agree that
> this BP is
> hard to act on for all the reasons you raise however, so I think we should
> tighten
> up the language here.
>
> If you have any suggestions for how to improve this BP that would be much
>
> appreciated.

Maybe rather than a size in bytes, a metric in terms a number of DOM
elements is more understandable. It may not capture the full memory
footprint, but it is something easily understandable and calculable.

>
> It is unclear what the recommendation to "Clip content and separate
> content onto separate pages" means.
> Are you saying to make top level URL changes to download new pages
> (and parse new JS)? If you are I think that is a bad recommendation as
>
> the latency hit is quite bad.
> Typically a better solution is to rather than hide non visible DOM
> elements, to instead remove these elements from the DOM altogether and
> recreate them as needed.
>
> The intent of "clip content" was kind of what you describe: e.g. If a user
> has 3000 emails
>
> don't try to display them all on the screen, display the first 10, and a
> link to dynamically load
> the next 10... We should tidy up the language here to avoid this confusion.
>
>
> 3.5.1.1
> App Cache link should now point to: http://www.w3.org/TR/html5/offline.html
>
> Will do.
>
>
> 3.5.1.2
> I like these recommendations. Good stuff.
>
> One thing you could add is to initiate any network requests before JS
> parsing begins, so that the network request is in flight while the
> parse occurs. This can work well for applications that require fresh,
>
> rather than, cached data to be useful as it parallelises the network
> request and JS parse.
>
> Good point.
>
>
> 3.5.4
> The tone of this recommendation is odd. I agree that the user
> shouldn't be warped away from their current view but there are cases
> where programatically setting the focus is very desirable if the next
>
> user action is expected to be character input and setting the focus in
> these cases should be recommended.
>
> Agreed. The thing that this BP warns against is quite pathological, and it
>
> inadvertently might discourage people from changing focus in legitimate
> use-cases.
>
>
>
> 3.5.6.2
> Maybe a mention of the format of the number used in the tel: URI
> A best practice is to use a full international number prefixed by +
> and a country code.
> This is recommended in the RFC so it isn't necessary to include it
>
> here, but it is currently quite common for people to use tel: URIs
> with only local numbers that don't work in a different calling prefix
> or different country.
>
> Yep, for convenience I think this is worth calling out in this doc since it
>
> would be an easy mistake to make.
>
>
> 3.5.11.2
> Setting minimum-scale=1.0,maximum-scale=1.0 has accessibility impacts
> as it usually makes it impossible to manually zoom into the screen,
> which can be useful for visually impaired users.
>
> Good point. Will remove.
>
>
> 3.6.3.2
> Class 2 and 3 are very similar, the difference being the advanced APIs
> available in class 3. For example, the iPhone v2.0 browser was class 2
> and v3.0 is class 3 by your classification. Typically these
>
> differences don't require different variants, the class 3 device just
> has a richer and faster experience. A more useful axis is touch screen
> v non touch screen.
>
> Fair point. We'll have to discuss. These 3 classes started out
> WML/XHTML/AJAX
>
> but we shunted them up since WML isn't very relevant to a doc on Web
> Application
> BPs... Agree that the distinction between 2/3 is not very relevant at this
> point in time.
>
> Perhaps we should just have two device classes in this example.
>
>
>
> 3.6.4
> There was no mention of <noscript>. Is this deliberate?
>
> 3.6.4.2
> Are we really recommending to send the user back a HTTP error code
> that essentially provides no information to the user as to why their
>
> request is "Not Acceptable". I understand this may be the 'correct'
> behaviour, but the UX it results in is hideous.
>
> Both good questions, I can't remember the outcome. We'll discuss in the
> group.
>
>
>
>
>
> thanks, please get back to me with any follow-up questions / clarifications
> / or if you have
> a suggestion for 3.4.11 (or any other BPs for that matter).
>
>
> Regards,
>
> Adam.
>
>
>