10:27:31 RRSAgent has joined #bpwg 10:27:31 logging to http://www.w3.org/2009/12/09-bpwg-irc 10:27:33 RRSAgent, make logs public 10:27:33 Zakim has joined #bpwg 10:27:35 Zakim, this will be BPWG 10:27:35 ok, trackbot; I see MWI_BPWG(F2F)4:30AM scheduled to start 57 minutes ago 10:27:36 Meeting: Mobile Web Best Practices Working Group Teleconference 10:27:36 Date: 09 December 2009 10:27:46 zakim, code? 10:27:46 the conference code is 2794 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), francois 10:30:29 MWI_BPWG(F2F)4:30AM has now started 10:30:36 + +1.585.278.aaaa 10:30:54 zakim, aaaa is me 10:30:54 +jeffs; got it 10:32:15 + +0163567aabb 10:32:43 zakim, aabb is Vodafone 10:32:43 +Vodafone; got it 10:33:04 zakim, Vodafone has DKA, francois, chaals 10:33:04 +DKA, francois, chaals; got it 10:34:20 Agenda: http://www.w3.org/2005/MWI/BPWG/Group/Meetings/London4/logistics.html#agenda 10:39:54 zakim, who is on the call? 10:39:54 On the phone I see jeffs, Vodafone 10:39:55 Vodafone has DKA, francois, chaals 10:42:01 Still waiting on Jo, Phil and Adam... 10:46:19 zakim, Vodafone also has achuter 10:46:19 +achuter; got it 10:59:06 zakim, Vodafone also has jo, adam 10:59:06 +jo, adam; got it 10:59:19 zakim, who is on the call? 10:59:19 On the phone I see jeffs, Vodafone 10:59:20 Vodafone has DKA, francois, chaals, achuter, jo, adam 11:02:21 chaals- has joined #bpwg 11:03:48 Scribe: Chaals 11:03:59 ScribeNick: chaals- 11:04:53 zakim, who is on the call? 11:04:53 On the phone I see jeffs, Vodafone 11:04:54 Vodafone has DKA, francois, chaals, achuter, jo, adam 11:05:09 ScribeNick: chaals 11:05:18 trackbot, start meeting 11:05:20 RRSAgent, make logs public 11:05:22 Zakim, this will be BPWG 11:05:22 ok, trackbot, I see MWI_BPWG(F2F)4:30AM already started 11:05:23 Meeting: Mobile Web Best Practices Working Group Teleconference 11:05:23 Date: 09 December 2009 11:05:34 RRSAgent, draft minutes 11:05:34 I have made the request to generate http://www.w3.org/2009/12/09-bpwg-minutes.html chaals 11:06:36 Chair: DanC and Jo 11:07:47 Present: Jeff(phone), chaals, DanA, Alan, Jo, François, Adam 11:08:22 s/DanC/DanA/ 11:08:49 rrsagent, this meeting crosses midnight 11:08:49 I'm logging. I don't understand 'this meeting crosses midnight', chaals. Try /msg RRSAgent help 11:09:24 rrsagent, this meeting spans midnight 11:10:36 PROPOSED RESOLUTION: promote mwabp to CR. We are done. Pop the champagne. 11:10:44 +1 11:10:46 Jo has joined #bpwg 11:11:03 (perhaps that is premature) 11:11:24 DKA a bit early, as usual 11:12:17 s/PROPOSED RESOLUTION: promote mwabp to CR. We are done. Pop the champagne.// 11:12:25 http://lists.w3.org/Archives/Public/public-bpwg/2009Dec/0001.html 11:12:28 s/(perhaps that is premature)// 11:12:42 s/DKA a bit early, as usual// 11:14:04 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" 11:14:46 ... (Art is my life guru. I say "what would Barstow do?") 11:14:51 JR: That explains a lot. 11:15:09 -> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/ List of last call comments on MWABP 11:17:31 -> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2274 editorial 11:17:39 RESOLUTION: Editorial, accepted. 11:18:45 -> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2265 Why should this be a Recommendation 11:19:39 CMN: The question is really how to show that people do these things. The answer is, show that each Best Practice is implemented. 11:20:00 DKA: There are previous examples of guidelines going to Rec, and we plan to follow that pattern 11:20:25 JR: Exit criteria weren't that implementations did everything, but that everything was used. 11:20:53 Adam: Exit Criteria will matter 11:21:09 DKA: can we add kisses and hugs for Art? 11:21:58 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 11:22:09 s/add kisses and hugs for/note our sincere thanks to/ 11:22:10 +1 11:22:15 +1 11:23:51 -> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2271 cookies as a mobile-specific issue? 11:24:12 http://lists.w3.org/Archives/Public/public-bpwg/2009Nov/0018.html 11:25:10 IMHO the cookies issue is particularly important in a mobile context as location information may be available & thus privacy issues come to the fore 11:26:40 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) 11:26:41 s/location information/location and other personal information/ 11:27:12 cgi-irc has joined #bpwg 11:27:25 Adam: And it is a known issue that Mobile Operators may interfere 11:28:53 Proposed RESOLUTION: We disagree, following Adam. Note that privacy issues are considered out of scope. 11:29:27 DKA: disagree with the comment 11:30:27 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) 11:30:57 FD: We disagree with the claim that there is no mobile-specific aspect to cookies 11:31:08 +1 11:32:31 [For clarity, I suggest adding a note that privacy issues are out of scope somewhere in the Scope section] 11:33:11 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. 11:33:23 +1 11:33:35 +1 11:33:46 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. 11:33:53 +1 11:34:30 -> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2272 BONDI, Widgets and alternative references 11:35:14 achuter has joined #bpwg 11:36:05 And 11:36:13 -> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2292 (likewise) 11:36:35 CMN: This is editorial - it is about what we use as examples 11:38:29 RESOLUTION: Editorial. We can look for more specific references... 11:38:56 -> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2293 JSON parsing 11:39:47 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.'?? 11:39:58 darobin has joined #bpwg 11:40:32 s/RESOLUTION/Proposed Resolution/ 11:40:37 rrsagent, draft minutes 11:40:37 I have made the request to generate http://www.w3.org/2009/12/09-bpwg-minutes.html chaals 11:41:10 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? 11:41:25 FD: Group will be DAP - they have lots of specs, storage is just one of them 11:41:50 CMN: Note that Web Apps also has some local storage specs (database stuff, minimal fileAPI...) 11:43:30 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 11:43:51 +1 11:44:34 FileSystem in DAP is read/write, and IMHO is a form of local storage 11:44:46 +1 11:44:47 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 11:45:21 yes, it is, and we might do localFS — but that's not what people generally mean by "the storage specs 11:45:23 " 11:45:31 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 11:45:57 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? 11:46:13 s/-> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2293 JSON parsing// 11:46:40 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 11:47:08 PROPSOED RESOLUTION: On LC-2272 resolve no, we thing we make sufficient comment about progress indications 11:48:00 PROPOSED RESOLUTION: On LC-2272 resolve no, we think we make sufficient comment about progress indications elsewhere 11:48:07 +1 11:48:10 +1 11:48:12 +1 11:48:15 +1 11:48:21 s/PROPSOED RESOLUTION: On LC-2272 resolve no, we thing we make sufficient comment about progress indications// 11:48:28 RESOLUTION: On LC-2272 resolve no, we thing we make sufficient comment about progress indications 11:48:37 -> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2293 JSON parsing 11:49:11 CMN: Not clear what the action required might be 11:49:42 the point is "don't trust" 11:50:39 DKA: The wording "10x" isn't good... 11:51:04 Proposed RESOLUTION: Editorial, but we will remove the "10x" 11:51:17 suggest replace "are approximately x10 slower" with "are known to be significantly slower" 11:51:37 may be considerably slower (or faster) 11:51:57 Proposed RESOLUTION: Editorial, but we will remove the "10x" and say "considerably" 11:52:13 CMN: Jeff's point that this is untrusted data seems more like the rationale. 11:52:22 want to push that the point is "don't trust" 11:52:38 DKA: Should we note the availability of native JSON parsers as a device capability we should be calling out? 11:52:52 JR: Not sure. Native support isn't necessarily faster 11:53:00 just because there is a native JSON parser doesn't mean it is safer, either 11:54:04 [we are in recess, as we move to a new room] 11:56:44 -Vodafone 11:56:49 -jeffs 11:56:51 MWI_BPWG(F2F)4:30AM has ended 11:56:52 Attendees were +1.585.278.aaaa, jeffs, +0163567aabb, DKA, francois, chaals, achuter, jo, adam 12:03:54 MWI_BPWG(F2F)4:30AM has now started 12:04:01 +Vodafone 12:06:49 francois has joined #bpwg 12:07:23 cgi-irc has joined #bpwg 12:12:59 RRSAgent, draft minutes 12:12:59 I have made the request to generate http://www.w3.org/2009/12/09-bpwg-minutes.html francois 12:13:17 phila has joined #bpwg 12:14:33 DKA has joined #bpwg 12:15:00 achuter has joined #bpwg 12:15:31 Scribe: francois 12:16:14 +jeffs 12:18:25 CMN: Starting again with LC-2293 12:18:55 jeffs: What's in the section is "don't trust incoming JSON data". 12:19:30 adam: that's why we say use JSON parsers which should be protected against that, as opposed eval. 12:20:00 ... 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. 12:20:23 chaals has joined #bpwg 12:20:43 rrsagent, draft minutes 12:20:43 I have made the request to generate http://www.w3.org/2009/12/09-bpwg-minutes.html chaals 12:21:15 jeffs: I just want to make sure we do say "don't trust JSON stuff", do it on the client side. 12:22:23 ... We must make sure that the message reads that the client must deal with JSON strings as if they were containing evil code. 12:23:03 Jo has joined #bpwg 12:23:07 adam: The initial point was more to do with performance. Trust appears afterwards. This is a compromise which I think is good. 12:23:46 jeffs: I can live with that, but... 12:23:55 DKA: That's it, you said the magic words. 12:24:29 jeffs: I just want to make sure we don't undermine evil possibilities with JSON exchanges. 12:24:41 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 12:25:11 DKA: is there any way we can strengthen the wording or do you think what we have is enough? 12:25:28 jeffs: It's about trading security for performance. 12:26:14 adam: I think we already have some careful wording that is strong about security issues. 12:26:38 ... We just need to correct the part that says that JSON parsing is necessarily slow, in agreement with Robin's comment. 12:26:48 +1 12:26:52 +1 12:27:10 PROPOSED RESOLUTION: Re. LC-2293, resolve yes and remove the parenthetical comment on performance issues with JSON parsers 12:27:12 +1 12:27:25 +1 12:27:30 +1 12:27:33 RESOLUTION: Re. LC-2293, resolve yes and remove the parenthetical comment on performance issues with JSON parser 12:28:35 -> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2294 LC-2294 12:31:06 adam: ref. the bullet points, I think they are just examples, and fine as they stand. 12:31:21 +1 to francois' comment 12:31:38 s/francois'/adam's 12:32:07 francois: there's a more generic thing here about implementers vs. authors. 12:32:42 ... The section is for authors but these UI notifications are (to be) handled by the browser. 12:34:25 dka: OK, let's address these issues separately and go back to the first point in LC-2293 12:35:28 CMN: most points in 3.3 should be left to the browser. 12:35:59 ... You should only do these things when you know that the browser does not adequately alert the user. 12:36:39 DKA: If through testing you determine that the user cannot tell what's happening behind the scene, you need to do it yourself. 12:37:42 I would recommend the reverse... assume you cannot trust unless you know the browser takes care of it 12:37:43 adam: 3.3.1.2 should alert about not replicating the functionality. 12:39:56 what item are we on pls? 3.2.1 LC-2293 or beyond? 12:40:25 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. 12:40:38 adam: We have some similar wording in 3.3.3.2. 12:41:33 CMN: I suggest wording in 3.3.3.2 be moved to description text in 3.3 12:42:35 adam: I don't feel strongly about any thing here. I just don't want to make changes that are not really needed. 12:43:23 adam: I think the BPs cover what you do at the application level, with a relatively correct browser. 12:44:48 again, I would comment that one should inform the user *unless* one is sure that the browser is doing so 12:45:08 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 12:45:24 scratch "admittedly rare" 12:47:01 jeffs: I just don't want us to say "browsers are cool" 12:47:06 [agree with Jeff] 12:47:44 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 12:47:45 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. 12:47:46 rare case that the browser doesn't solicit permission 12:48:19 jeffs: I think my point is that it should be at the application level that authors handle all these points. 12:48:41 jo: We're not proposing any change to the document here. 12:49:10 ... I changed "admittedly rare" to "probably rare". 12:49:29 jeffs: we should not do that kind of statement. 12:50:02 q+ to say that we do trust browsers to have some kind of same-origin policy. 12:50:57 jeffs: I don't want to tell users that they can just trust the browser and let go of any warning. 12:51:17 ack f 12:51:17 francois, you wanted to say that we do trust browsers to have some kind of same-origin policy. 12:51:53 +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? 12:52:04 (and in the mean time let's move on) 12:52:31 +1 to "high level positioning statement"... authors should *not* default to trust 12:52:36 +1 12:52:49 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. 12:52:55 agree 12:52:57 [ICLWI now[ 12:53:15 s/[/]/ 12:53:19 DKA: let's agree with the proposed resolution and come back to it later if we think it's needed. 12:53:53 PROPOSED RESOLUTION: ref LC-2293 resolve no, it's made clear under 3.3.3.2 that applications should not duplicate native functionality. 12:54:00 +1 12:54:01 +1 12:54:04 +1 12:54:10 +1 12:54:32 RESOLUTION: ref LC-2293 resolve no, it's made clear under 3.3.3.2 that applications should not duplicate native functionality. 12:55:06 -Vodafone 12:55:14 -jeffs 12:55:15 MWI_BPWG(F2F)4:30AM has ended 12:55:15 Attendees were Vodafone, jeffs 12:55:40 MWI_BPWG(F2F)4:30AM has now started 12:55:47 +jeffs 12:57:01 LC2275 12:57:06 zakim, code? 12:57:06 the conference code is 2794 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), Jo 12:57:12 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 12:57:21 So I suggest we resolve no. 12:57:22 -> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2275 LC-2275 12:57:38 +Vodafone 12:58:47 [I'm not sure that's a "resolve no", as this is already mentioned in 3.3.3.2] 13:01:40 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. 13:01:48 +1 13:02:12 +1 13:03:08 +1 13:05:07 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. 13:05:55 -> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2299 LC-2299 on Canvas and SVG 13:06:18 agree w fixing spelling 13:06:34 disagree with not contrasting 13:08:05 issue is oneof using dynamic graphics & how to differentiate between when SVG is appropriate & when Canvas is appropriate 13:08:19 s/oneof/one of/ 13:10:03 -Vodafone 13:10:41 zakim, who is on the call? 13:10:41 On the phone I see jeffs 13:10:49 -jeffs 13:10:51 MWI_BPWG(F2F)4:30AM has ended 13:10:51 Attendees were jeffs, Vodafone 13:11:10 zakim, code? 13:11:10 the conference code is 2794 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), DKA 13:11:33 adam: The latest version already contains changes that address parts of the comment. 13:11:39 MWI_BPWG(F2F)4:30AM has now started 13:11:42 +Vodafone 13:11:47 +jeffs 13:12:00 CMN: do we mean "use one vs the other" or use one or the other depending on your needs? 13:12:20 adam: This was more to emphasis the existence of these technologies. 13:13:11 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. 13:13:22 IMHO the critical issue is to use SVG if you need access to the DOM & want to make things accessible 13:13:36 jo: I don't think we have anything to say on that topic, having gone through that discussion 6 times now. 13:14:10 phila: dropping that section would be substantive, meaning another last call is needed. 13:14:25 I would oppose dropping this section 13:15:24 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. 13:15:25 canvas is not accessible, SVG is. canvas does not admit to DOM manipulation, SVG does. authors need to know this 13:16:01 jeffs: We need to make a statement on what I just typed on IRC. 13:16:27 [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] 13:16:33 ... By stating this, we'll just help authors to make a choice between two technologies. 13:16:51 adam: I agree with jeffs here. 13:17:19 CMN: yes, but that's really not a best practice, just a series of facts about SVG and Canvas. 13:17:36 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 13:18:29 ... The value I see in this is to use SVG/Canvas instead of Silverlight, Flash, or Shockwave or any other proprietary technology. 13:19:07 jeffs: the value for me is more to help users making a choice between two technologies. 13:19:15 "Don't use proprietary technology" is a good BP :) 13:19:59 DKA: could we say both in the section? Use natively supported graphics, and highlight the differences between SVG and Canvas. 13:20:27 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 13:20:50 ... If you need scalable, use one of Canvas/SVG. 13:20:53 accessability and DOM access are 2 clear issues 13:21:16 adam: We've tried it, but it's actually not a best practice, it adds loads of Javascript to your application. 13:21:35 if you need accessibility, or indexing of content by search engines, you're in SVG land 13:22:10 at the game-like end of the spectrum, you're where canvas shines 13:22:13 CMN: I don't see how we can build consensus here. I would be in favor of dropping this section and put a note about it. 13:22:27 I would oppose dropping this section 13:22:32 s/here/here in a short time/ 13:23:19 jo: I think the accessibility point is somewhat moot, given that the document is about exploiting device capabilities. 13:23:36 ... The best practice would be "provide an accessible alternative". 13:24:18 DKA: I'm reluctant to drop things from the document that are useful to readers. 13:24:46 ... 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? 13:25:08 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. 13:26:12 DKA: my proposal would address the points raised by everyone around the table. 13:26:30 Phil: What are the other BPs that you would then demote? 13:26:42 adam: all of the BPS could then be demoted ;) 13:27:00 I agree w Adam, it would be silly to pick this one out to "demote" 13:27:36 real developers will increasingly need to decide whether to use one or the other, we need to give them advice 13:28:06 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. 13:28:38 "consider whether to use..." 13:28:53 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. 13:29:07 ... because they are not actionable. 13:29:47 DKA "the best practice to follow when making this decision is" is a position which makes sense to me 13:29:54 Phil: I would add section 3.7 Further considerations with current sections 3.5.9 and 3.5.10. 13:30:14 PROPOSED RESOLUTION: move 3.5.10 and 3.5.9 to a "further considerations" section. 13:31:55 real developers in the real world will increasingly need to deal with dynamic graphics issues in their work 13:32:10 I would prefer to leave as is, but I'm happy to move 3.5.10 and 3.5.9 into "Further Considerations" section. 13:32:16 +1 13:32:18 I can live with that 13:32:43 "I can live with it." 13:33:32 CMN: all things considered, 3.5.9 could become "Use mobile specific technologies" and could be actionable. 13:33:38 PROPOSED RESOLUTION: move 3.5.10 to a "further considerations" section. 13:33:42 DKA: OK, let's restrict ourselves to 3.5.10 at this point. 13:33:51 +1 13:33:53 +1 13:33:54 RESOLUTION: move 3.5.10 to a "further considerations" section. 13:33:55 +1 13:33:56 +1 13:34:03 +1 13:34:06 RESOLUTION: move 3.5.10 to a "further considerations" section. 13:34:33 RESOLUTION: "resolve yes" on LC-2299. 13:34:44 scribe: PhilA 13:34:51 scribeNick:Phila 13:35:05 no, we did *not* resolve "yes" on all of LC-2299 13:36:22 LC-2299 says "don't try to contrast them", & that is the whole fscking *point* 13:36:25 3.5.9 is unaffected by this btw - it stays where it is 13:37:03 CMN: It seems that 2259 suggests taking 3.5.10 should be removed but doesn't actually say this explicitly 13:37:25 LC-2299 says "In most cases Canvas is faster" and this is an empirical question & may not be true in all cases 13:37:30 FD: So Jeffs are you saying we should resolve no? or partial? 13:38:29 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 13:38:47 ... the 2nd one I disagree with is where the comment says it's flaky and wrong 13:38:48 [The note on "in most cases Canvas is faster" was taken from the draft, FWIW] 13:39:05 ... I think that contrasting these isthe whole point of thisBP 13:39:27 FD: Text says "if speed is important..." 13:39:35 CMN: Which slants towards using canvas 13:39:47 Adam: I agree that we're resolving partial 13:40:14 Jeffs:I think we've only resolved a part of what's in LC2299 13:40:26 FD: Can we stick to factual things about SVG nad canvas? 13:40:46 ... the facts are that canvas is not accessilble nad SVG is 13:40:59 ... SVG you can access and manipulate the DOm and with canvas you can't 13:41:09 ... speed is not a hard fact 13:41:23 Adam: In some browsers you can empirically measure the greater speed of canvas 13:41:41 jeffs: I agree that we should only be adressing the 2 key facts and not speed 13:41:43 s/accessilble and/accessible and/ 13:41:49 s/DOm/DOM/ 13:42:16 ... if you want to change canvas you ave to redraw the whole thing which isn't true in SVG 13:42:48 Adam: I would be sorry to see this go as I find it useful information 13:43:00 CMN: I can libe with removing as much as you want to remove 13:43:16 Jeffs: I can live with a speed part being in although it shouldn't 13:43:21 s/libe/live/ 13:43:35 Adam: We're just talking about moving the text as is and putting it into a new section 13:43:47 rrsagent, draft minutes 13:43:47 I have made the request to generate http://www.w3.org/2009/12/09-bpwg-minutes.html phila 13:45:05 Adam: The wording has been softened since the version you're working with Jeff 13:45:22 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. 13:45:25 +1 13:45:32 +1 13:45:46 +1 13:45:52 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. 13:47:29 Note, we did change the wording somewhat since LC-2299 and addressed the typo issues. 13:47:34 s/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./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. 13:47:52 +1 13:48:39 +1 13:48:53 rrsagent, draft minutes 13:48:53 I have made the request to generate http://www.w3.org/2009/12/09-bpwg-minutes.html phila 13:48:59 short break 13:49:30 -jeffs 14:13:23 (and Alan) 14:14:43 PROPOSED RESOLUTION: rename the document to "Great Practices for Cool Mobile WebApps" 14:15:47 LC-2295 14:15:51 Next LC 2295 http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2295?cid=2295 14:15:57 tnx 14:16:12 Adam: I think it's the same as one we've already resolved no to. 14:16:29 +jeffs 14:16:34 PROPOSED RESOLUTION: LC-2295 identical to LC-2275 so it's the same. 14:16:38 +1 14:16:46 Jo: So let's resolve that it's identical to 2275 (no) 14:17:03 PROPOSED RESOLUTION: LC-2295 identical to LC-2275 so it's the same response (resolved no). 14:17:11 +1 14:17:14 +1 14:17:37 Adam: I'm confused about 2276 http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2276?cid=2276 14:18:35 LC-2276 14:19:11 CMN: This throws up the worm 'What do you do to provide an option' 14:19:26 Adam: I think we can just change the word Must to Should 14:19:33 CMN: And the doc isn't normative so that's OK 14:19:45 PROPOSED RESOLUTION: Change must to should in 3.3.2.2 14:19:57 +1 14:20:01 RESOLUTION: Change must to should in 3.3.2.2 14:20:06 +1 14:20:23 LC-2296 14:20:39 CMN: n to 2296 http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2296?cid=2296 14:21:09 Adam: I agree its a bit duious 14:21:33 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 14:22:39 CMN: Something like 'some of this functionality is already covered by browsers. App develoeprs should be aware of what the browser does already and complement, not duplicate it.' 14:22:44 s/duious/dubious/ 14:22:55 s/duious/dubious/ 14:23:10 s/develoeprs/developers/ 14:23:36 "developers should take care to avoid duplicating browser functionality"?? 14:24:14 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" 14:24:25 +1 14:27:16 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 14:27:40 CMN: You can say that 'if these BPs are achieved by the browser already then your job is done.' 14:27:53 FD: It's really about providing info cf. privacy issues 14:28:00 Jo: I;m not sure about that 14:28:18 s/I;m/I'm/ 14:28:32 Jo: 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' 14:28:37 "while developers should take care to avoid duplication of browser functionality in this area, they should also ensure users are informed"?? 14:29:11 rrsagent, draft minutes 14:29:11 I have made the request to generate http://www.w3.org/2009/12/09-bpwg-minutes.html phila 14:29:41 +1 to jeffs's suggestion. 14:30:13 +1 to jeff's suggestion 14:31:03 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 14:31:32 ... 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) 14:31:44 CMN: I'm happy with Jeff's suggestion as well 14:32:14 DKA: I take your point, Alan but I don't think Jeff's suggestion tells developers ... anything 14:32:19 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." 14:32:24 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 14:32:34 +1 14:32:36 +1 14:33:11 +1 14:33:14 +1 14:33:18 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 14:33:31 s/ossible/possible/ 14:33:37 (modulo correction of typos) 14:33:51 s/features/features 14:34:34 ♡♡♡♡♡♡♡ 14:34:43 LC 2296 - we agree. The new intro to 3.3 should cover this (also LC 2276, 2295, 2275, 2294 ...) 14:35:10 RESOLUTION: LC-2296 resolved yes. See new intro to section 3.3 14:35:22 ❀ 14:35:22 Adam: What about the 'dubious' bit of 2296? 14:36:05 LC-2277 14:36:40 LC-2277 http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2277?cid=2277 14:36:48 Jo_ has joined #bpwg 14:36:55 Hang on, we're going back to 2296 14:37:16 Further to the resolution to agree 'yes' we should remove the references to the help pages 14:38:40 Back to 2277 14:38:58 When you allow persistent authentication you must provide a way to turn it off 14:39:04 CMN: I agree 14:39:09 Adam: I don't disagree 14:39:26 Adam: I fee it's talking about security etc which is out of scope 14:39:42 CMN: No, it's about about being always signed in if you can't sign out on mobile 14:39:53 CMN: The rationale being for when you lose your phone 14:40:25 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 14:40:36 the "change/invalidation of password" idea makes a lot of sense to me 14:41:01 FD: I think the comment is already addressed by the text 14:41:10 ... but I agree with Charles 14:41:28 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. 14:41:30 CMN: What it should say is that it should be revokable (a new workd AFAIK) 14:42:02 FD: It is a BP to say you should provide a sign out if you do a sign in 14:42:09 Jo: points to his earlier comment 14:42:36 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." 14:42:38 Adam; Do we also want to change the text to say that the token should be revokable 14:42:49 s/Adam;/Adam:/ 14:43:15 "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."?? 14:43:34 Jo: My point is that if we put it in How to Do it it's a less substantive change (thank what it means) 14:43:40 DKA: Can you live with it? 14:43:45 CMN: Deep sigh 14:44:30 FD: Isn't the substantive point a bit moot since we've already made a substantive change (moving a section) 14:44:52 Jo: we changed the amphasis 14:45:01 s/amphasis/emphasis/ 14:45:01 CMN: This is also a change in emphasis 14:45:34 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) 14:45:54 Adam: I'd say if you have automatic sign in then your app should have a sign out link 14:46:04 CMN: This is a clarification, not a substantive change 14:46:34 what about the issue of revocation via other devices? the "may be stolen" use-case makes sense for the mobile context 14:46:40 PhilA: I have amphorae full of aphoristic emphasis 14:47:45 what about the issue of revocation via other devices? the "may be stolen" use-case makes sense for the mobile context 14:47:54 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. 14:48:12 Adam: On Jeff's point - I think that's covered by the text already 14:48:37 ... I think that text has been added since the LC comment 14:48:45 Jeffs: I may be working with an old version 14:48:56 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 14:49:00 +1 to chaals 14:49:05 LC-2297 14:49:07 +1 14:49:25 LC-2297 http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2297?cid=2297 14:50:02 DKA: This is about EXI. That's in CR? 14:50:06 FD: Yes, as of yesterday 14:50:18 yes, email went out 14:50:46 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 14:51:22 very small files do indeed get larger with gzip 14:51:37 ... 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 14:51:43 warning of this possibillity makes sense 14:52:02 CMN: I can't think of a video format that benefits from cmpression 14:52:14 ... SVG is a specific exception since it does benefit from compression 14:52:15 s/possibillity/possibility/ 14:52:37 CMN: Image formats don't benefit from compression - SVG does 14:52:59 already says "Most images (especially JPEGs) do not benefit from compression" 14:53:13 perhaps change "images" to "media files" 14:53:23 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 14:53:44 perhaps change "images" to "media files"?? 14:53:50 chaals types a lot to my right 14:54:31 I would also be careful to s/do not benefit from compression/do not benefit from additional compression/ 14:54:42 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 14:54:55 JPEG and friends are already compressed, compressing twice almost always increases the file size 14:55:04 +1 14:55:30 mentioning EXI would be the nice thing to do 14:55:43 could simply change "images" to "media files"... 14:56:00 CMN: I'd e happy to add EXI as a techn to watch 14:56:11 DKA: Agree 14:56:29 CMN: Where supported, EXI is more efficient than compression 14:56:32 re changing to "media file", perhaps yes if there's a of it to say it includes images, audio, video 14:56:40 agree 14:57:17 EXI can provide better compression with much faster processing and the matching much lower battery consumption 14:57:23 Jo: BP1 was in limbo for 18 months because it mentioned XHTML Basic 14:57:39 CMN: This is not a normative dependency. Where supported, EXI does... 14:58:08 could simply change "images" to "media files (like images, audio, and video)"... 14:58:23 simple is good 14:58:28 CMN: Happy with Jeffs - 14:58:43 CMN: Can we resolve the proposal? 14:59:05 It's getting very editorial 14:59:34 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) 14:59:57 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) 14:59:58 +1 15:00:00 +1 15:00:02 +1 15:00:04 EXI 15:00:10 CMN: Add a note pointing to EXI 15:00:41 PROPOSED RESOLUTION: Include a pointer to EXI 15:00:42 I think Jo's comment about BP1 is a cautionary note to be attended to 15:00:48 -> http://www.w3.org/TR/exi/ Efficient XML Interchange (EXI) Format 1.0 15:00:50 i think that it is too much of a forward looking b est practice and may have transition consequences 15:01:16 s/b est/best 15:01:17 I'd suggest leaving EXI comment for another version 15:02:00 suggesting to look into it is hardly forward looking :) 15:02:33 DKA: Its not a normative dependency, it won't trip us up 15:03:00 CMN: Will anyone object if we leave it out? 15:03:14 I would be tempted to 15:03:15 DKA: I won't object but I don't see a reason to leave it ou 15:03:18 no, just a little worried 15:03:27 DKA: Who cannot live with it being in there? 15:03:54 FD: Push mention on EXI into the new Further Considerations? 15:04:02 +1 15:04:17 -1 (+1 to dka) 15:04:26 DKA: I don't think this should go into further considerations. It belongs here because we're talking about compression 15:04:48 ... it's just a little informative note saying think about EXI for the future because it's going to be on your roadmap 15:04:56 FD: Anyone against including EXI 15:05:04 Jo: Me#DKA: Will you formally object? 15:05:07 no, just a little worried 15:05:09 Jo: No 15:05:17 PROPOSED RESOLUTION: informative nice note on EXI in compression section. 15:05:26 +1 15:05:29 +1 15:05:29 +1 15:05:35 RESOLUTION: informative nice note on EXI in compression section. 15:05:43 LC-2278 15:05:47 rrsagent, draft minutes 15:05:47 I have made the request to generate http://www.w3.org/2009/12/09-bpwg-minutes.html phila 15:06:11 scribenick: achuter 15:06:43 scribe: achuter 15:07:00 phila has left #bpwg 15:07:27 RESOLUTION: 2278 is editorial and accepted. 15:07:39 +1 15:08:30 LC-2279 15:08:47 no to LC-2279 15:11:18 PROPOSED RESOLUTION "No to LC-2279" 15:11:43 +1 15:11:44 AC: Issue is gone now. 15:12:16 RESOLUTION 2280 RESOLVED NO. 15:12:41 RESOLUTION "No to LC-2279" 15:14:30 LC-2281? 15:15:01 change "below 10Mb" to "as small as is reasonable"?? 15:15:03 AC: LC-2281 have addressed this in new draft. 15:15:57 CMN: use "stored" or "loaded" not "visible" 15:16:43 RESOLUTION 2281 Agree we have reworded document. 15:17:13 RESOLUTION 2298 Same issue as 2281. 15:18:30 tricky... what happens when JS processing aimed at deciding what stylesheets to load? 15:19:30 CMN, for third point, point to existing literature on subject of optimising startup time. 15:19:42 agree w CMN 15:19:52 about LC-2282. 15:21:15 JR: Depends much on what the JS processing is supposed to be doing. 15:21:30 FD: Later we do say to put JS at page end. 15:23:47 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. 15:24:01 +1 15:25:49 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 15:26:01 +1 15:27:05 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. 15:27:18 +1 15:28:00 +1 15:28:06 +1 15:28:24 +1 15:28:58 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. 15:29:10 +1 already 15:30:23 LC-2283 15:31:19 if memory serves me, this is particularly an issue for blink users... accessability 15:31:28 s/blink/blind/ 15:33:33 if memory serves me, this is particularly an issue for blind users... accessibility 15:33:51 PROPOSED RESOLUTION: 2283 Agree to leave as is. 15:33:55 +1 15:34:03 RESOLUTION: 2283 Agree to leave as is. 15:34:26 LC-2284 15:34:29 RESOLUTION: 2284 Agree . 15:35:30 RESOLUTION: 2299 Already addressed. 15:36:47 PRPOSED RESOLUTION: Comment already partly addressed in current ED, in addition remove refcerence to "explicit disallow scaling" 15:37:12 PRPOSED RESOLUTION: RE LC-2285 Comment already partly addressed in current ED, in addition remove refcerence to "explicit disallow scaling" 15:37:21 +1 15:37:32 +1 15:38:16 should we say "to enhance accessibility, avoid explicitly disallowing scaling up of the page"?? 15:38:41 CMN: Add a second possible configuration, XHTML support or not, with or without touch screen. 15:39:09 JR: Example of Ajax or not, and APIs or not. 15:39:37 CMN: Add a second example. 15:40:47 LC-2286 15:41:07 PROPOSED RESOLUTION 2286: Add second example with touch screen. 15:41:17 +1 15:41:25 RESOLUTION LC-2286: Add second example with touch screen. 15:43:35 PROPOSED RESOLUTION: Ref LC-2287 resolve yes add text to how to do it sating that