- From: Francois Daoust <fd@w3.org>
- Date: Mon, 14 Dec 2009 14:33:53 +0100
- To: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
Hi,
The group had a productive F2F last week. I have cleaned and added a bit
of structure to the minutes. Here is a summary and the minutes of the
first day. Other days to follow.
The minutes of day 1/3 are available at:
http://www.w3.org/2009/12/09-bpwg-minutes.html
... and copied as text below.
The group addressed the list of last call comments on Mobile Web
Application Best Practices. Changes brought to the document were deemed
non-substantive and the group expects to request transition to Candidate
Recommendation once the Last Call reviewers have agreed with the group's
replies to their comments.
Next short-term steps:
1. an update of the draft based on the resolutions of the F2F. Adam is
on it.
2. replies to the reviewers based on the resolutions of the F2F. I am on it.
3. Once reviewed by some native English speaker, the replies will be
sent out to the reviewers, who will hopefully agree with the replies by
beginning of January 2010.
Thanks,
Francois.
-----
09 Dec 2009
[2]Agenda
[2]
http://www.w3.org/2005/MWI/BPWG/Group/Meetings/London4/logistics.html#agenda
See also: [3]IRC log
[3] http://www.w3.org/2009/12/09-bpwg-irc
Attendees
Present
Jeff(phone), chaals, DanA, Alan, Jo, François, Adam
Regrets
none
Chair
DanA and Jo
Scribe
Chaals, francois, PhilA, achuter
Contents
The group addressed the [4]list of last call comments on Mobile Web
Application Best Practices. Changes brought to the document are
non-substantive and the group expects to request transition to
Candidate Recommendation once the Last Call reviewers have agreed
with the group's replies to their comments.
* [5]Topics
1. [6]Preface
2. [7]LC-2274, typo
3. [8]LC-2265, non-normative Recommendation
4. [9]LC-2271, cookies
5. [10]LC-2272 and LC-2292, reference to devices APIs
6. [11]LC-2293, JSON parsing
7. [12]LC-2275, duplicate native functionality
8. [13]LC-2299, Canvas and SVG
9. [14]LC-2275, LC-2276, LC-2294, LC-2295, implementers vs.
authors
10. [15]LC-2277, sign-in and sign-out
11. [16]LC-2297, reference to EXI
12. [17]LC-2278, throttle network requests
13. [18]LC-2279, low cache limits on some devices
14. [19]LC-2280, link BPs on cookies
15. [20]LC-2281 and LC-2298, a "reasonable" DOM
16. [21]LC-2282, initiate network requests before JS parsing
begins
17. [22]LC-2283, setting focus
18. [23]LC-2284, tel scheme example
19. [24]LC-2285, disallow scaling
20. [25]LC-2286, devices classification
21. [26]LC-2287, mention of noscript
22. [27]LC-2288, LC-2300, 406 status code
23. [28]LC-2266, non normative appendices
24. [29]LC-2290, reference to widgets effort
25. [30]LC-2291, historical anomaly
26. [31]LC-2273, JSON escaping on the server
27. [32]MWABP Transition to Candidate Recommendation
28. [33]MWABP Exit Criteria
* [34]Summary of Action Items
[4]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/
Minutes of the F2F
* [35]Day 1/3 (this page)
* [36]Day 2/3
* [37]Day 3/3
_________________________________________________________
[35] http://www.w3.org/2009/12/09-bpwg-minutes.html
[36] http://www.w3.org/2009/12/10-bpwg-minutes.html
[37] http://www.w3.org/2009/12/11-bpwg-minutes.html
Preface
<DKA>
[38]http://lists.w3.org/Archives/Public/public-bpwg/2009Dec/0001.htm
l
[38] http://lists.w3.org/Archives/Public/public-bpwg/2009Dec/0001.html
DKA: Today we are trying to get MWABP out the door - if we can't get
agreement, we can drop stuff. Our mantra for today is Art Bartsow's
ICLWI test - "I can live with it"
... (Art is my life guru. I say "what would Barstow do?")
JR: That explains a lot.
<francois> [39]List of last call comments on MWABP
[39]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/
LC-2274, typo
[40]LC-2274
[40]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2274
RESOLUTION: Editorial, accepted.
LC-2265, non-normative Recommendation
[41]LC-2265 - Why should this be a Recommendation
[41]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2265
CMN: The question is really how to show that people do these things.
The answer is, show that each Best Practice is implemented.
DKA: There are previous examples of guidelines going to Rec, and we
plan to follow that pattern
JR: Exit criteria weren't that implementations did everything, but
that everything was used.
Adam: Exit Criteria will matter
DKA: can we note our sincere thanks to Art?
RESOLUTION: We will follow the precedent set by various
Recommendations which are guidelines, and have Exit Criteria which
shows that each Best Practice is implemented and therefore
implementable. Hugs and Kisses from Dan
<jeffs> +1
<DKA> +1
LC-2271, cookies
[42]LC-2271 - cookies as a mobile-specific issue?
[42]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2271
<DKA>
[43]http://lists.w3.org/Archives/Public/public-bpwg/2009Nov/0018.htm
l
[43] http://lists.w3.org/Archives/Public/public-bpwg/2009Nov/0018.html
<jeffs> IMHO the cookies issue is particularly important in a mobile
context as location and other personal information may be available
& thus privacy issues come to the fore
CMN: The best practice points out that the issue here is that it
increases data being shipped, a known problem for mobile in
particular (battery life)
Adam: And it is a known issue that Mobile Operators may interfere
Proposed RESOLUTION: We disagree, following Adam. Note that privacy
issues are considered out of scope.
DKA: disagree with the comment
Adam: Not that we disagree, but that there is no action required.
There are two parts - one is the lack of privacy section (which we
have deliberately not addressed)
FD: We disagree with the claim that there is no mobile-specific
aspect to cookies
<jeffs> +1
<francois> [For clarity, I suggest adding a note that privacy issues
are out of scope somewhere in the Scope section]
Proposed RESOLUTION: We disagree with the claim that there is no
mobile-specific aspect to cookies (the shifting of data is
mobile-specific). We also note that privacy issues are considered
out of Scope - and will add a note to that effect.
<jeffs> +1
<DKA> +1
RESOLUTION: We disagree with the claim that there is no
mobile-specific aspect to cookies (the shifting of data is
mobile-specific). We also note that privacy issues are considered
out of Scope - and will add a note to that effect.
<jeffs> +1
LC-2272 and LC-2292, reference to devices APIs
[44]LC-2272 - BONDI, Widgets and alternative references
[45]LC-2292 (likewise)
[44]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2272
[45]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2292
CMN: This is editorial - it is about what we use as examples
Proposed Resolution: Editorial. We can look for more specific
references...
<jeffs> what about the point in LC-2272: '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.'??
JR: Can we add some explanation that these are current things at the
time of writing, with some references to groups who will do more?
FD: Group will be DAP - they have lots of specs, storage is just one
of them
CMN: Note that Web Apps also has some local storage specs (database
stuff, minimal fileAPI...)
<Jo> PROPOSED RESOLUTION: Add text to 3.1.2.1. stating that work is
in progress to unify these apis and to see the work of WebApps and
Device API WGs
<jeffs> +1
FileSystem in DAP is read/write, and IMHO is a form of local storage
<DKA> +1
<darobin> RB: I don't think that DAP really has any storage spec
(not in the usually understood sense anyway), unless you count File
System or being able to expose how much disk space there is — most
storage is WebApps
<darobin> yes, it is, and we might do localFS — but that's not what
people generally mean by "the storage specs
<darobin> "
RESOLUTION: Add text to 3.1.2.1. stating that work is in progress to
unify these apis and pointing to the work of WebApps and Device API
WGs
Adam: If you have local data that is not committed to the server,
should it have some UI treatment saying it is on the way to the
server?
JR: We have said various things about indicating what is going on,
and for the sake of battery life I don't think we should be making a
recommendation on this
<Jo> PROPOSED RESOLUTION: On LC-2272 resolve no, we think we make
sufficient comment about progress indications elsewhere
<DKA> +1
<adam> +1
<jeffs> +1
<francois> +1
RESOLUTION: On LC-2272 resolve no, we thing we make sufficient
comment about progress indications
LC-2293, JSON parsing
[46]LC-2293 - JSON parsing
[46]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2293
CMN: Not clear what the action required might be
<jeffs> the point is "don't trust"
DKA: The wording "10x" isn't good...
Proposed RESOLUTION: Editorial, but we will remove the "10x"
<jeffs> suggest replace "are approximately x10 slower" with "are
known to be significantly slower"
<Jo> may be considerably slower (or faster)
Proposed RESOLUTION: Editorial, but we will remove the "10x" and say
"considerably"
CMN: Jeff's point that this is untrusted data seems more like the
rationale.
<jeffs> want to push that the point is "don't trust"
DKA: Should we note the availability of native JSON parsers as a
device capability we should be calling out?
JR: Not sure. Native support isn't necessarily faster
<jeffs> just because there is a native JSON parser doesn't mean it
is safer, either
[we are in recess, as we move to a new room]
<francois> Scribe: francois
CMN: Starting again with LC-2293
jeffs: What's in the section is "don't trust incoming JSON data".
adam: that's why we say use JSON parsers which should be protected
against that, as opposed eval.
... I think Robin's point has more to do with the efficiency point.
With a native JSON parsing, the x10 slower performance is not true
anymore.
jeffs: I just want to make sure we do say "don't trust JSON stuff",
do it on the client side.
... We must make sure that the message reads that the client must
deal with JSON strings as if they were containing evil code.
adam: The initial point was more to do with performance. Trust
appears afterwards. This is a compromise which I think is good.
jeffs: I can live with that, but...
DKA: That's it, you said the magic words.
jeffs: I just want to make sure we don't undermine evil
possibilities with JSON exchanges.
<darobin> my point was more about security than performance: native
JSON parsing is faster than eval but will still be slow on large
JSON, but you're not using eval and so it's a lot safer
DKA: is there any way we can strengthen the wording or do you think
what we have is enough?
jeffs: It's about trading security for performance.
adam: I think we already have some careful wording that is strong
about security issues.
... We just need to correct the part that says that JSON parsing is
necessarily slow, in agreement with Robin's comment.
<jeffs> +1
<darobin> +1
PROPOSED RESOLUTION: Re. LC-2293, resolve yes and remove the
parenthetical comment on performance issues with JSON parsers
<adam2> +1
+1
<DKA> +1
RESOLUTION: Re. LC-2293, resolve yes and remove the parenthetical
comment on performance issues with JSON parser
->
[47]http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-200
91006/2294 LC-2294
[47]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2294
adam: ref. the bullet points, I think they are just examples, and
fine as they stand.
<jeffs> +1 to adam's comment
francois: there's a more generic thing here about implementers vs.
authors.
... The section is for authors but these UI notifications are (to
be) handled by the browser.
dka: OK, let's address these issues separately and go back to the
first point in LC-2293
CMN: most points in 3.3 should be left to the browser.
... You should only do these things when you know that the browser
does not adequately alert the user.
DKA: If through testing you determine that the user cannot tell
what's happening behind the scene, you need to do it yourself.
<jeffs> I would recommend the reverse... assume you cannot trust
unless you know the browser takes care of it
adam: 3.3.1.2 should alert about not replicating the functionality.
<jeffs> what item are we on pls? 3.2.1 LC-2293 or beyond?
CMN: The thing is we do expect the browser to do these things. We
can expect some browsers to do it wrong. Only in that later case
should this be handled at the application level.
adam: We have some similar wording in 3.3.3.2.
CMN: I suggest wording in 3.3.3.2 be moved to description text in
3.3
adam: I don't feel strongly about any thing here. I just don't want
to make changes that are not really needed.
... I think the BPs cover what you do at the application level, with
a relatively correct browser.
<jeffs> again, I would comment that one should inform the user
*unless* one is sure that the browser is doing so
<Jo> PROPOSED RESOLUTION: ref LC-2293 resolve no, it's made clear
under 3.3.3.2 that applications should not duplicate native
fundtionality but should be prepared to warn in the admittedly rare
case that the browser doesn't solicit permission
<jeffs> scratch "admittedly rare"
jeffs: I just don't want us to say "browsers are cool"
<chaals> [agree with Jeff]
<Jo> PROPOSED RESOLUTION: ref LC-2293 resolve no, it's made clear
under 3.3.3.2 that applications should not duplicate native
fundtionality but should be prepared to warn in the probably
jo: The problem with that philosophy is as often that we have no
data, we just don't know what browsers do good or bad.
<Jo> rare case that the browser doesn't solicit permission
jeffs: I think my point is that it should be at the application
level that authors handle all these points.
jo: We're not proposing any change to the document here.
... I changed "admittedly rare" to "probably rare".
jeffs: we should not do that kind of statement.
... I don't want to tell users that they can just trust the browser
and let go of any warning.
<Zakim> francois, you wanted to say that we do trust browsers to
have some kind of same-origin policy.
<DKA> +1 to proposed resolution - and to keeping jeffs's suggested
mindset in our back pocket - maybe this is a high level positioning
statement we can make?
<DKA> (and in the mean time let's move on)
<jeffs> +1 to "high level positioning statement"... authors should
*not* default to trust
<adam2> +1
francois: we already put a lot of trust on browsers, e.g. that they
implement some kind of same-origin policy. I don't quite see the
point in commenting they are secure or insecure.
<jeffs> agree
<chaals> [ICLWI now]
DKA: let's agree with the proposed resolution and come back to it
later if we think it's needed.
PROPOSED RESOLUTION: ref LC-2293 resolve no, it's made clear under
3.3.3.2 that applications should not duplicate native functionality.
<jeffs> +1
<adam2> +1
<DKA> +1
<achuter> +1
RESOLUTION: ref LC-2293 resolve no, it's made clear under 3.3.3.2
that applications should not duplicate native functionality.
LC-2275, duplicate native functionality
[48]LC-2275
[48]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2275
<adam2> Response on public-bpwg: "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
<adam2> So I suggest we resolve no.
[I'm not sure that's a "resolve no", as this is already mentioned in
3.3.3.2]
PROPOSED RESOLUTION: ref LC-2275, resolve no as this would
complicate things for authors who would then have to maintain
different variants of their applications for different browsers.
<adam2> +1
<jeffs> +1
+1
RESOLUTION: ref LC-2275, resolve no as this would complicate things
for authors who would then have to maintain different variants of
their applications for different browsers.
LC-2299, Canvas and SVG
[49]LC-2299 - Canvas and SVG
[49]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2299
<jeffs> agree w fixing spelling
<jeffs> disagree with not contrasting
<jeffs> issue is one of using dynamic graphics & how to
differentiate between when SVG is appropriate & when Canvas is
appropriate
adam: The latest version already contains changes that address parts
of the comment.
CMN: do we mean "use one vs the other" or use one or the other
depending on your needs?
adam: This was more to emphasis the existence of these technologies.
CMN: SVG is more implemented in mobile devices. Canvas is not
really. Anyway, as written, it's not a bet practice, it's rather an
interesting thing about the universe.
<jeffs> IMHO the critical issue is to use SVG if you need access to
the DOM & want to make things accessible
jo: I don't think we have anything to say on that topic, having gone
through that discussion 6 times now.
phila: dropping that section would be substantive, meaning another
last call is needed.
<jeffs> I would oppose dropping this section
francois: I was in favor of removing the section before publication.
I still think it should be removed, and agree with Phil that means
another Last Call.
<jeffs> canvas is not accessible, SVG is. canvas does not admit to
DOM manipulation, SVG does. authors need to know this
jeffs: We need to make a statement on what I just typed on IRC.
<chaals> [I think the value of this is using canvas/SVG rather than
other technologies for interactive graphics, but not sure what the
value of the rest is although I don't mind leaving in some simple
waffle about the differences]
jeffs: By stating this, we'll just help authors to make a choice
between two technologies.
adam: I agree with jeffs here.
CMN: yes, but that's really not a best practice, just a series of
facts about SVG and Canvas.
<darobin> I think that the only thing that can be usefully said
within the scope of this specification is that they are
complementary technologies, that authors should consider their
relative merits before committing to one, and should be careful with
canvas's accessibility issues
CMN: The value I see in this is to use SVG/Canvas instead of
Silverlight, Flash, or Shockwave or any other proprietary
technology.
jeffs: the value for me is more to help users making a choice
between two technologies.
<darobin> "Don't use proprietary technology" is a good BP :)
DKA: could we say both in the section? Use natively supported
graphics, and highlight the differences between SVG and Canvas.
<darobin> the problem you're up against is that it's rather
difficult to recommend when to use which. At the extremes it's
clear, but there are plenty of situations in the middle where you
could use either
DKA: If you need scalable, use one of Canvas/SVG.
<jeffs> accessability and DOM access are 2 clear issues
adam: We've tried it, but it's actually not a best practice, it adds
loads of Javascript to your application.
<darobin> if you need accessibility, or indexing of content by
search engines, you're in SVG land
<darobin> at the game-like end of the spectrum, you're where canvas
shines
CMN: I don't see how we can build consensus here in a short time. I
would be in favor of dropping this section and put a note about it.
<jeffs> I would oppose dropping this section
jo: I think the accessibility point is somewhat moot, given that the
document is about exploiting device capabilities.
... The best practice would be "provide an accessible alternative".
DKA: I'm reluctant to drop things from the document that are useful
to readers.
... Could we take that out of the BP list and put it in some "things
you should be aware of if you're a mobile developer" section?
<DKA> PROPOSED RESOLUTION: take the BP on SVG and canvas usage and
make it even more informative in some way - so demote it from being
a BP.
DKA: my proposal would address the points raised by everyone around
the table.
Phil: What are the other BPs that you would then demote?
adam: all of the BPS could then be demoted ;)
<jeffs> I agree w Adam, it would be silly to pick this one out to
"demote"
<jeffs> real developers will increasingly need to decide whether to
use one or the other, we need to give them advice
DKA: I think we're in a position where chaals opposes the BP if it
stays in and jeffs opposes the demotion of the BP.
<jeffs> "consider whether to use..."
CMN: following your resolution would be a good thing. I think 3.5.9
and 3.5.10 are the only BPs that are candidate to be demoted in my
view.
... because they are not actionable.
<jeffs> DKA "the best practice to follow when making this decision
is" is a position which makes sense to me
Phil: I would add section 3.7 Further considerations with current
sections 3.5.9 and 3.5.10.
<DKA> PROPOSED RESOLUTION: move 3.5.10 and 3.5.9 to a "further
considerations" section.
<jeffs> real developers in the real world will increasingly need to
deal with dynamic graphics issues in their work
<adam2> I would prefer to leave as is, but I'm happy to move 3.5.10
and 3.5.9 into "Further Considerations" section.
<adam2> +1
<jeffs> I can live with that
<DKA> "I can live with it."
CMN: all things considered, 3.5.9 could become "Use mobile specific
technologies" and could be actionable.
<DKA> PROPOSED RESOLUTION: move 3.5.10 to a "further considerations"
section.
DKA: OK, let's restrict ourselves to 3.5.10 at this point.
+1
<DKA> +1
<DKA> RESOLUTION: move 3.5.10 to a "further considerations" section.
<adam2> +1
<jeffs> +1
<achuter> +1
RESOLUTION: move 3.5.10 to a "further considerations" section.
<DKA> RESOLUTION: "resolve yes" on LC-2299.
<phila> scribe: PhilA
<scribe> scribeNick:Phila
<jeffs> no, we did *not* resolve "yes" on all of LC-2299
<jeffs> LC-2299 says "don't try to contrast them", & that is the
whole fscking *point*
3.5.9 is unaffected by this btw - it stays where it is
CMN: It seems that 2259 suggests taking 3.5.10 should be removed but
doesn't actually say this explicitly
<jeffs> LC-2299 says "In most cases Canvas is faster" and this is an
empirical question & may not be true in all cases
FD: So Jeffs are you saying we should resolve no? or partial?
Jeffs: We resolved to move the section to a new further
consideration section. LC2299 says we mean element not tag, there
are other bits. We shouldn't agree with the statement that in most
cases canvas is faster
... the 2nd one I disagree with is where the comment says it's flaky
and wrong
<francois> [The note on "in most cases Canvas is faster" was taken
from the draft, FWIW]
Jeffs: I think that contrasting these isthe whole point of thisBP
FD: Text says "if speed is important..."
CMN: Which slants towards using canvas
Adam: I agree that we're resolving partial
Jeffs: I think we've only resolved a part of what's in LC2299
FD: Can we stick to factual things about SVG nad canvas?
... the facts are that canvas is not accessible and SVG is
... SVG you can access and manipulate the DOM and with canvas you
can't
... speed is not a hard fact
Adam: In some browsers you can empirically measure the greater speed
of canvas
jeffs: I agree that we should only be adressing the 2 key facts and
not speed
jeffs: if you want to change canvas you ave to redraw the whole
thing which isn't true in SVG
Adam: I would be sorry to see this go as I find it useful
information
CMN: I can live with removing as much as you want to remove
Jeffs: I can live with a speed part being in although it shouldn't
Adam: We're just talking about moving the text as is and putting it
into a new section
... The wording has been softened since the version you're working
with Jeff
<DKA> PROPOSED RESOLUTION: on the matter of LC-2299, we resolve
partial actually. We will not make any change to the wording though
the BP has moved to "further consideration" section.
<DKA> +1
<jeffs> +1
<adam2> +1
RESOLUTION: on the matter of LC-2299, we resolve partial actually.
We will not make any further change to the wording though the BP has
moved to "further consideration" section.
<adam2> Note, we did change the wording somewhat since LC-2299 and
addressed the typo issues.
<jeffs> +1
<adam2> +1
short break
<DKA> (and Alan)
<DKA> PROPOSED RESOLUTION: rename the document to "Great Practices
for Cool Mobile WebApps"
LC-2275, LC-2276, LC-2294, LC-2295, implementers vs. authors
[50]LC-2275
[51]LC-2276
[52]LC-2294
[53]LC-2295
[50]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2275
[51]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2276
[52]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2294
[53]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2295
<jeffs> tnx
Adam: I think it's the same as one we've already resolved no to.
<DKA> PROPOSED RESOLUTION: LC-2295 identical to LC-2275 so it's the
same.
<DKA> +1
Jo: So let's resolve that it's identical to 2275 (no)
<DKA> PROPOSED RESOLUTION: LC-2295 identical to LC-2275 so it's the
same response (resolved no).
<jeffs> +1
<DKA> +1
Adam: I'm confused about 2276
[54]http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-200
91006/2276?cid=2276
[54]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2276?cid=2276
<DKA> LC-2276
CMN: This throws up the worm 'What do you do to provide an option'
Adam: I think we can just change the word Must to Should
CMN: And the doc isn't normative so that's OK
<DKA> PROPOSED RESOLUTION: Change must to should in 3.3.2.2
<achuter> +1
RESOLUTION: Change must to should in 3.3.2.2
<jeffs> +1
<DKA> LC-2296
CMN: n to 2296
[55]http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-200
91006/2296?cid=2296
[55]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2296?cid=2296
Adam: I agree its a bit dubious
FD: Maybe we should add a note at the top of the doc to say that the
BPs are on top of what is available in the browser
CMN: Something like 'some of this functionality is already covered
by browsers. App developers should be aware of what the browser does
already and complement, not duplicate it.'
<jeffs> "developers should take care to avoid duplicating browser
functionality"??
<chaals> Proposed RESOLUTION: Add to section 3.3 intro: "Note that
where these functionalities are provided by the browser, that is
sufficient, and better than the application providing them"
<jeffs> +1
Adam: I don't think that these BPs are there to replace anything in
the browser. I think it would be ad to try and compensate for any
and all browser deficiencies. It should ensure that the relevant
info is provided for the user
CMN: You can say that 'if these BPs are achieved by the browser
already then your job is done.'
FD: It's really about providing info cf. privacy issues
Jo: I'm not sure about that
... it's probably a good thing for the app to say 'if you say not to
any of these things then the app may not work'
<jeffs> "while developers should take care to avoid duplication of
browser functionality in this area, they should also ensure users
are informed"??
<DKA> +1 to jeffs's suggestion.
<francois> +1 to jeff's suggestion
Alan: There's a thing about browsers being able to change a
stylesheet to change the font size and yet there are loads of sites
that provide buttons to do this in the page
... so you could get to the situation where people didn't know where
to look for alerts on the page (because they haven't got used to
seeing where it is made clear in the browser)
CMN: I'm happy with Jeff's suggestion as well
DKA: I take your point, Alan but I don't think Jeff's suggestion
tells developers ... anything
<adam2> Note that application behaviour should be complimentary to
and in addition to native browser functionality. Developers should
ensure users are informed whilst avoiding duplication of default
browser functionality."
<Jo> PROPSOED RESOLUTION: Add to 3.3 the into text: Where ossible
rely on the browser's native functionality to implement the
confirming featues described in this section
<adam2> +1
<DKA> +1
<francois> +1
<jeffs> +1
RESOLUTION: Add to 3.3 the into text: Where possible rely on the
browser's native functionality to implement the confirming featues
described in this section
<Jo> (modulo correction of typos)
<jeffs> ♡♡♡♡♡♡♡
LC 2296 - we agree. The new intro to 3.3 should cover this (also LC
2276, 2295, 2275, 2294 ...)
RESOLUTION: LC-2296 resolved yes. See new intro to section 3.3
<DKA> ❀
Adam: What about the 'dubious' bit of 2296?
Further to the resolution to agree 'yes' we should remove the
references to the help pages
LC-2277, sign-in and sign-out
[56]LC-2277
[56]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2277?cid=2277
When you allow persistent authentication you must provide a way to
turn it off
CMN: I agree
Adam: I don't disagree
... I fee it's talking about security etc which is out of scope
CMN: No, it's about about being always signed in if you can't sign
out on mobile
... The rationale being for when you lose your phone
Adam: if you provide a sign in you should provide a sign out. What
this comment's about is when you store a secure token you should set
up a way to revoke the token from the server
<jeffs> the "change/invalidation of password" idea makes a lot of
sense to me
FD: I think the comment is already addressed by the text
... but I agree with Charles
<Jo> PROPOSED RESOLUTION: Add to 3.3.4.2 "Provide the user with the
ability to sign out using both the device that automatic sign on is
enabled on and on other devices to that automatic sign on tokens are
revoked.
CMN: What it should say is that it should be revokable (a new workd
AFAIK)
FD: It is a BP to say you should provide a sign out if you do a sign
in
Jo: points to his earlier comment
<Jo> PROPOSED RESOLUTION: Add to 3.3.4.2 "Provide the user with the
ability to sign out using both the device that automatic sign on is
enabled on and on other devices so that automatic sign on tokens are
revoked."
Adam: Do we also want to change the text to say that the token
should be revokable
<jeffs> "Provide the user with the ability to sign out, using either
the device that automatic sign on is enabled on or other devices
which result in tokens being revoked."??
Jo: My point is that if we put it in How to Do it it's a less
substantive change (thank what it means)
DKA: Can you live with it?
CMN: Deep sigh
FD: Isn't the substantive point a bit moot since we've already made
a substantive change (moving a section)
Jo: we changed the emphasis
CMN: This is also a change in emphasis
Adam: If you provide a sign in link you must provide a sign out
option (actually if you're signed in there's a sign out)
... I'd say if you have automatic sign in then your app should have
a sign out link
CMN: This is a clarification, not a substantive change
<jeffs> what about the issue of revocation via other devices? the
"may be stolen" use-case makes sense for the mobile context
PhilA: I have amphorae full of aphoristic emphasis
<jeffs> what about the issue of revocation via other devices? the
"may be stolen" use-case makes sense for the mobile context
<chaals> Proposed RESOLUTION: We agree with the comment, and have
edited the how to do it to match the server case. Adam will also
clarify the "option" in the what it means to ensure it is clear that
it also allows sign out / not automatically signing in.
Adam: On Jeff's point - I think that's covered by the text already
... I think that text has been added since the LC comment
Jeffs: I may be working with an old version
RESOLUTION: We agree with the comment, and have edited the how to do
it to match the server case. Adam will also clarify the "option" in
the what it means to ensure it is clear that it also allows sign out
/ not automatically signing in
<DKA> +1 to chaals
<jeffs> +1
LC-2297, reference to EXI
[57]LC-2297
[57]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2297?cid=2297
DKA: This is about EXI. That's in CR?
FD: Yes, as of yesterday
<jeffs> yes, email went out
CMN: At the time of writing GFlate is more widely supported. Robin's
saying that there is an actual dis-benefit in compressive small
files
<jeffs> very small files do indeed get larger with gzip
CMN: for very small files (< 1K) there is no benefit in compression.
And for most media files (audio, video, png, gifs) etc. compression
can be counter-producvtive are, at best, a waste of time
<jeffs> warning of this possibility makes sense
CMN: I can't think of a video format that benefits from cmpression
... SVG is a specific exception since it does benefit from
compression
... Image formats don't benefit from compression - SVG does
<jeffs> already says "Most images (especially JPEGs) do not benefit
from compression"
<jeffs> perhaps change "images" to "media files"
<darobin> well if you use a video format that you really shouldn't
be using for mobile in the first place it might benefit from
compression, but that's daft
<jeffs> perhaps change "images" to "media files"??
chaals types a lot to my right
<darobin> I would also be careful to s/do not benefit from
compression/do not benefit from additional compression/
<chaals> Proposed RESOLUTION: Adjust 3.4.1 to note (as per FD) that
gzip/DEFLATE are widely supported at time of writing; change images
bullet to note that most formats don't benefit from compression but
SVG does, add bullet that audio and video formats don't, edit bullet
point on small files to note that they generally don't benefit from
compression
<darobin> JPEG and friends are already compressed, compressing twice
almost always increases the file size
<adam2> +1
<darobin> mentioning EXI would be the nice thing to do
<jeffs> could simply change "images" to "media files"...
CMN: I'd e happy to add EXI as a techn to watch
DKA: Agree
CMN: Where supported, EXI is more efficient than compression
<darobin> re changing to "media file", perhaps yes if there's a
<dfn> of it to say it includes images, audio, video
<jeffs> agree
<darobin> EXI can provide better compression with much faster
processing and the matching much lower battery consumption
Jo: BP1 was in limbo for 18 months because it mentioned XHTML Basic
CMN: This is not a normative dependency. Where supported, EXI
does...
<jeffs> could simply change "images" to "media files (like images,
audio, and video)"...
<jeffs> simple is good
CMN: Happy with Jeffs -
... Can we resolve the proposal?
It's getting very editorial
Proposed RESOLUTION: Adjust 3.4.1 to note (as per FD) that
gzip/DEFLATE are widely supported at time of writing; change images
bullet to note that most formats don't benefit from compression but
SVG does, add bullet that audio and video formats don't, edit bullet
point on small files to note that they generally don't benefit from
compression (or editorially equivalent)
RESOLUTION: Adjust 3.4.1 to note (as per FD) that gzip/DEFLATE are
widely supported at time of writing; change images bullet to note
that most formats don't benefit from compression but SVG does, add
bullet that audio and video formats don't, edit bullet point on
small files to note that they generally don't benefit from
compression (or editorially equivalent)
<DKA> +1
<jeffs> +1
<adam2> +1
EXI
CMN: Add a note pointing to EXI
PROPOSED RESOLUTION: Include a pointer to EXI
<jeffs> I think Jo's comment about BP1 is a cautionary note to be
attended to
<francois> [58]Efficient XML Interchange (EXI) Format 1.0
[58] http://www.w3.org/TR/exi/
<Jo> i think that it is too much of a forward looking best practice
and may have transition consequences
<jeffs> I'd suggest leaving EXI comment for another version
<darobin> suggesting to look into it is hardly forward looking :)
DKA: Its not a normative dependency, it won't trip us up
CMN: Will anyone object if we leave it out?
<darobin> I would be tempted to
DKA: I won't object but I don't see a reason to leave it ou
<jeffs> no, just a little worried
DKA: Who cannot live with it being in there?
FD: Push mention on EXI into the new Further Considerations?
<chaals> +1
<adam2> -1 (+1 to dka)
DKA: I don't think this should go into further considerations. It
belongs here because we're talking about compression
... it's just a little informative note saying think about EXI for
the future because it's going to be on your roadmap
FD: Anyone against including EXI
Jo: Me#DKA: Will you formally object?
<jeffs> no, just a little worried
Jo: No
<DKA> PROPOSED RESOLUTION: informative nice note on EXI in
compression section.
<jeffs> +1
<adam2> +1
<DKA> +1
RESOLUTION: informative nice note on EXI in compression section.
LC-2278, throttle network requests
[59]LC-2278
[59]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2278
RESOLUTION: 2278 is editorial and accepted.
<jeffs> +1
LC-2279, low cache limits on some devices
[60]LC-2279
[60]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2279
<jeffs> no to LC-2279
PROPOSED RESOLUTION "No to LC-2279"
<jeffs> +1
AC: Issue is gone now.
RESOLUTION: "No to LC-2279"
LC-2280, link BPs on cookies
[61]LC-2280
[61]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2280
RESOLUTION: 2280 RESOLVED NO.
LC-2281 and LC-2298, a "reasonable" DOM
[62]LC-2281
[63]LC-2298
[62]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2281
[63]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2298
<jeffs> change "below 10Mb" to "as small as is reasonable"??
AC: LC-2281 have addressed this in new draft.
CMN: use "stored" or "loaded" not "visible"
RESOLUTION: 2281 Agree we have reworded document.
RESOLUTION: 2298 Same issue as 2281.
LC-2282, initiate network requests before JS parsing begins
[64]LC-2282
[64]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2282
<jeffs> tricky... what happens when JS processing aimed at deciding
what stylesheets to load?
CMN, for third point, point to existing literature on subject of
optimising startup time.
<jeffs> agree w CMN
JR: Depends much on what the JS processing is supposed to be doing.
FD: Later we do say to put JS at page end.
PROPOSED RESOLUTION 2282: 3.5.1.1 agree, done, ref is updated;
3.5.1.2 thank you; "...initiate any network requests..." is not a
long-term best practice so not accepted, will add pointers to other
resources.
<jeffs> +1
<Jo> PROPOSED RESOLUTION 2282: 3.5.1.1 agree, done, ref is updated;
3.5.1.2 thank you; "...initiate any network requests..."depends too
much on exactly what the JS is doing so hard to generalize, make
reference to BP 3.5.2.2 saying that JS put at bottom of page
<jeffs> +1
<chaals> PROPOSED RESOLUTION 2282: 3.5.1.1 agree, done, ref is
updated; 3.5.1.2 thank you; "...initiate any network
requests..."depends too much on exactly what the JS is doing so hard
to generalize, make reference to BP 3.5.2.2 saying that JS put at
bottom of page and to the fact that there is ongoing research in
this area.
<adam2> +1
<DKA> +1
<jeffs> +1
+1
RESOLUTION 2282: 3.5.1.1 agree, done, ref is updated; 3.5.1.2 thank
you; "...initiate any network requests..."depends too much on
exactly what the JS is doing so hard to generalize, make reference
to BP 3.5.2.2 saying that JS put at bottom of page and to the fact
that there is ongoing research in this area.
<jeffs> +1 already
LC-2283, setting focus
[65]LC-2283
[65]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2283
<jeffs> if memory serves me, this is particularly an issue for blind
users... accessibility
PROPOSED RESOLUTION: 2283 Agree to leave as is.
<jeffs> +1
RESOLUTION: 2283 Agree to leave as is.
LC-2284, tel scheme example
[66]LC-2284
[66]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2284
<DKA> LC-2284
RESOLUTION: 2284 Agree.
LC-2285, disallow scaling
[67]LC-2285
[67]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2285
<Jo> PRPOSED RESOLUTION: Comment already partly addressed in current
ED, in addition remove refcerence to "explicit disallow scaling"
<Jo> PRPOSED RESOLUTION: RE LC-2285 Comment already partly addressed
in current ED, in addition remove refcerence to "explicit disallow
scaling"
<jeffs> +1
<DKA> +1
<jeffs> should we say "to enhance accessibility, avoid explicitly
disallowing scaling up of the page"??
RESOLUTION: RE LC-2285 Comment already partly addressed in current
ED, in addition remove refcerence to "explicit disallow scaling"
LC-2286, devices classification
[68]LC-2286
[68]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2286
CMN: Add a second possible configuration, XHTML support or not, with
or without touch screen.
JR: Example of Ajax or not, and APIs or not.
CMN: Add a second example.
<DKA> LC-2286
PROPOSED RESOLUTION 2286: Add second example with touch screen.
<jeffs> +1
RESOLUTION LC-2286: Add second example with touch screen.
LC-2287, mention of noscript
[69]LC-2287
[69]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2287
<Jo> PROPOSED RESOLUTION: Ref LC-2287 resolve yes add text to how to
do it sating that <noscript> element should be used appropriately
<jeffs> +1
<adam2> +1
<francois> +1
+1
<chaals> +1
RESOLUTION: Ref LC-2287 resolve yes add text to how to do it sating
that <noscript> element should be used appropriately
LC-2288, LC-2300, 406 status code
[70]LC-2288
[71]LC-2300
[70]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2288
[71]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2300
FD: UA string is to be able to look up device in DDR.
<chaals> Proposed RESOLUTION: s/return a 406 Not Acceptable response
along with/return a response with/
<adam2> +1
PROPOSED RESOLUTION 2288: Agree to remove 406 requirement
<adam2> +1
<DKA> +1 "i can live with it"
RESOLUTION LC-2288: Agree to remove 406 requirement
<DKA> LC-2300
RESOLUTION LC-2300: Same issue as LC-2288.
LC-2266, non normative appendices
[72]LC-2266
[72]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2266
<Jo> PROPSOED RESOLUTION: In re 2266 we agree and will delete the
offending non normative words
Jo: proposal for acknowledgement section
<adam2> +1
<DKA> +1
RESOLUTION: In re 2266 we agree and will delete the offending non
normative words
LC-2290, reference to widgets effort
[73]LC-2290
[73]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2290
RESOLUTION: Editorial, we agree and will change accordingly
LC-2291, historical anomaly
[74]LC-2291
[74]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2291
RESOLUTION: Editorial, we agree and will change accordingly
LC-2273, JSON escaping on the server
[75]LC-2273
[75]
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2273
FD: The BP is about the security, not about the processing power, so
we should resolve no
CMN: The comment isn't important to the substance of the Best
Practice
Adam: This is implicit
RESOLUTION: Agree - this is already implicit in the text and we
won't change that.
<DKA> +1
MWABP Transition to Candidate Recommendation
<DKA> PROPOSED RESOLUTION: The group requests transition of MWABP to
CR.
<DKA> PROPOSED RESOLUTION: The group requests transition of MWABP to
CR.
<DKA> PROPOSED RESOLUTION: The group requests transition of MWABP to
CR (pending the changes that Adam makes and pending responses from
commenters).
<DKA> PROPOSED RESOLUTION: The editorial changes resolved today to
MWABP in response to LC comments will not be substantive.
<DKA> PROPOSED RESOLUTION: The editorial changes resolved today to
MWABP in response to LC comments aren't "substantive." Therefore we
will be requesting transition to CR pending commenters' responses.
<DKA> +1
RESOLUTION: The editorial changes resolved today to MWABP in
response to LC comments aren't "substantive." Therefore we will be
requesting transition to CR pending commenters' responses.
MWABP Exit Criteria
<scribe> ScribeNick: DKA
PROPOSED RESOLUTION: Exit criteria for MWABP will be similar to
MWBP: a report indicating at least 2 implementations of each BP (or
something).
<francois> [[ Extract from BP1 CR:
<francois> The Mobile Web Best Practices Working Group expects to
request that the Director advance this document to Proposed
Recommendation once:
<francois> 1. Sufficient reports of implementation experience have
been gathered to demonstrate that the Mobile Web Best Practices are
implementable and are interpreted in a consistent manner. To test
this, the Working Groups expects to evaluate web content (web sites,
pages) that has been created using the Mobile Web Best Practices. To
exit "Candidate Recommendation" for each Best Practice, at least two
web sites/pages which are not solely demonstrations of Best
<francois> Practices implementation should pass the Best Practice.
<francois> 2. An implementation report has been produced indicating
the results of using each best practices for the web sites/pages
considered
<francois> ]]
PROPOSED RESOLUTION: Beer o'clock.
RESOLUTION: We will set exit criteria when we are ready to ask for
CR, but expect to ask for at least two independently sourced
implementations of each BP...
RESOLUTION: Bo'C
+1
<chaals> [adjourned]
Summary of Action Items
[End of minutes]
Received on Monday, 14 December 2009 13:34:27 UTC