13:28:08 RRSAgent has joined #bpwg 13:28:08 logging to http://www.w3.org/2009/05/12-bpwg-irc 13:28:10 RRSAgent, make logs public 13:28:10 Zakim has joined #bpwg 13:28:12 Zakim, this will be BPWG 13:28:12 ok, trackbot; I see MWI_BPWG()9:30AM scheduled to start in 2 minutes 13:28:13 Meeting: Mobile Web Best Practices Working Group Teleconference 13:28:13 Date: 12 May 2009 13:28:26 tomhume has joined #bpwg 13:28:46 zakim, what is the code? 13:28:46 the conference code is 2794 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), tomhume 13:29:20 yeliz has joined #bpwg 13:29:21 MWI_BPWG()9:30AM has now started 13:29:27 +??P22 13:29:33 zakim, ??P22 is me 13:29:33 +tomhume; got it 13:29:58 Regrets: jeffs, kai, abel, miguel 13:30:00 Chair: jo 13:30:18 +jo 13:30:27 Agenda: http://lists.w3.org/Archives/Public/public-bpwg/2009May/0012.html 13:30:57 zakim, who is here? 13:30:57 On the phone I see tomhume, jo 13:30:58 On IRC I see yeliz, tomhume, Zakim, RRSAgent, jo, francois, trackbot 13:31:00 +Francois 13:31:33 EdC has joined #bpwg 13:32:27 +??P26 13:32:38 rob has joined #bpwg 13:32:46 + +41.31.972.aaaa 13:32:54 cgi-irc has joined #bpwg 13:33:06 zakim, code 13:33:06 I don't understand 'code', adam 13:33:11 zakim, code? 13:33:11 the conference code is 2794 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), adam 13:33:11 zakim, code? 13:33:13 the conference code is 2794 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), francois 13:33:21 +rob 13:33:28 zakim, ??P26 is Bruce_Lawson 13:33:28 +Bruce_Lawson; got it 13:33:35 zakim, aaaa is EdC 13:33:35 +EdC; got it 13:33:37 zakim, aaaa is EdC 13:33:37 sorry, jo, I do not recognize a party named 'aaaa' 13:33:47 +adam 13:33:51 brucel has joined #bpwg 13:34:23 zakim, Bruce_Lawson is really BruceL 13:34:23 +BruceL; got it 13:35:09 Scribe: Tom 13:35:12 Scribenick: tomhume 13:36:02 Topic: FYI - lang attribute back in XHTML Basic 1.1 13:36:35 SeanP has joined #bpwg 13:37:25 francois: Not much to say on this, except we were talking about this a few months ago and the XHTMLWG integrated the lang attribute into XHTML Basic 1.1. The second edition is a "proposed edit recommendation edition", close to replacing the first edition. When it's done we can update the DTD in the mobileOK checker to have the LANG attribute back. 13:37:46 ... This is good news in that we're consistent with the I18N group. 13:37:52 jo: is there a DTD we could use if we want to? 13:37:59 -> http://www.w3.org/TR/2009/PER-xhtml-basic-20090507/ XHTML Basic 1.1 PER 13:38:21 francois: there's a schema for those who prefer it. 13:38:44 -> http://www.w3.org/TR/2009/PER-xhtml-basic-20090507/#a_dtd DTD in the spec 13:39:09 +SeanP 13:39:13 ... this section contains links to the actual files - the version associated with the document and that evolving over time. 13:39:22 jo: when should we edit the checker? 13:39:35 francois: wait for the document to become a recommendation, and then update the checker 13:40:00 jo: do we refer to a specific version in the checker? 13:40:37 francois: we're not talking about editions in the document 13:40:47 jo: we don't say anything specific at all, if we're talking about mobileOK basic 13:41:13 francois: all we have is a link to XHTML Basic 1.1, the dated version of the first edition. This will link to the new edition. 13:42:23 ... mobileOK basic targets the first edition. We don't say anything specific about DTDs, and I don't think we need to do anything to clarify this. We could an erratum to the spec if we need to, to explain what we mean by the XHTML Basic 1.1 DTD... that it follows the evolution of XHTML Basic 1.1 recommendation (or not). 13:42:46 jo: but it's not an erratum, it's a clarification... 13:43:01 +[IPcaller] 13:43:17 zakim, +[IPcaller] is yeliz 13:43:17 sorry, yeliz, I do not recognize a party named '+[IPcaller]' 13:43:29 zakim, IPcaller is yeliz 13:43:29 +yeliz; got it 13:43:38 zakim, mute yeliz 13:43:38 yeliz should now be muted 13:43:44 francois: if moving to the new DTD is a normative change (I think it's a correction of something wrong), we can't just produce an erratum. If we feel it's a useful clarification we can add an erratum - that's the only way to add such comments. 13:44:10 ... let's wait for XHTML Basic to become a recommendation. 13:45:02 PROPOSED RESOLUTION: Add an erratum to mobileOK Basic Tests, at the right time, to point to the edited version of XHTML Basic 1.1 including the lang attribute 13:45:15 agree 13:45:17 +1 13:45:18 +1 13:45:20 RESOLUTION: Add an erratum to mobileOK Basic Tests, at the right time, to point to the edited version of XHTML Basic 1.1 including the lang attribute 13:45:25 +1 13:45:32 jo: francois, can you enact this pls? 13:45:54 ACTION: daoust to enact the resolution on XHTML Basic 1.1 revision - when it reaches rec 13:45:55 Created ACTION-959 - Enact the resolution on XHTML Basic 1.1 revision - when it reaches rec [on François Daoust - due 2009-05-19]. 13:46:02 +1 13:46:14 Topic: MWABP - new draft out. Feedback needed. Next steps? 13:46:32 -> http://www.w3.org/TR/2009/WD-mwabp-20090507/ new draft of MWABP 13:46:34 zakim, who is making noise? 13:46:45 jo, listening for 10 seconds I heard sound from the following: jo (19%), adam (5%) 13:47:14 jo: we've had no feedback on this document as yet. 13:47:56 adam: I've had some feedback on appcache, an HTML5 feature for caching web apps locally. It'd be good to have a BP on this subject and discuss what form this should take. It's very HTML5-specific, that's all the feedback I've had so far. 13:47:59 What about the pending feedback from François and myself? 13:48:06 jo: How do you tell that feature is present? 13:48:19 adam: It's supported based on the target platform. Good question. 13:48:42 jo: do we want to discuss the merits of the proposal on this call, or shall we gather some of these to discuss in a more consolidated way once we've had feedback? The latter, I suggest 13:48:44 adam: agree 13:49:10 ISSUE: Should we have a BP on appcache? 13:49:10 Created ISSUE-297 - Should we have a BP on appcache? ; please complete additional details at http://www.w3.org/2005/MWI/BPWG/Group/track/issues/297/edit . 13:50:15 q+ 13:50:28 adam: re pending feedback from eduardo... the outstanding issue is with 3.6.1 and 3.6.2. Agree with your comments, as they're formulated right now they're a bit mickey mouse and don't reflect reality. Not sure how to make them better - best solution might be to make the language more woolly, talk about preferring server-side XXX. Or if you have specific things you'd like to see in there, feel free to propose them. 13:50:30 ack edc 13:50:37 edc: I suggest you write a proposal and I'll comment on it again. 13:50:47 ... The other issue is on sprites. 13:51:06 -> http://www.w3.org/TR/2009/WD-mwabp-20090507/#d1e8981 3.4.6 CSS Sprites 13:51:15 ACTION: adam to write a proposal in answer to EdC's comments on 3.6.1 and 3.6.2 13:51:15 Created ACTION-960 - Write a proposal in answer to EdC's comments on 3.6.1 and 3.6.2 [on Adam Connors - due 2009-05-19]. 13:51:19 jsmanrique has joined #bpwg 13:51:56 adam: barring opinions from others, I don't have any more I can extract through inspection. 3.4.6 and 3.4.7 are the sections; the issue is technical and advanced, they're dependent on device support - we have proposed icons to represent the fact that you need certain features in the browser for them to make sense as recommendations. There's a general issue of whether they make sense as recommendations, or if they're "advanced tweaks" 13:52:53 edc: I'm reminded of multipart-mixed. if its supported (blackberry and openwave browsers should be ok, safari has lousy support for it), then it solves all your problems with icons and provides greater benefits. I wonder what kind of best practice we want to put into this document. 13:53:04 adam: can someone take an action to investigate multipart-mixed? 13:53:34 ack tom 13:54:16 ACTION: Tom to investiagate multipart-mixed in the context of 3.4.6 and 3.4.7 of MWABP 13:54:16 Created ACTION-961 - Investiagate multipart-mixed in the context of 3.4.6 and 3.4.7 of MWABP [on Tom Hume - due 2009-05-19]. 13:55:36 francois: I sent a comment about the security stuff (2.1 - do not execute untrusted Javascript). Final paragraph needs rewriting. 13:55:39 -> http://www.w3.org/TR/2009/WD-mwabp-20090507/#d1e542 3.2.1 JSON 13:56:17 ... again, it's how to find a balance between best practice and what's acceptable. it makes sense in 99% of cases, there's 1% where security can be impacted. 13:56:23 ... so maybe it's not a good idea there. 13:57:23 adam: one option would be to remove that paragraph. Or we could reword this paragraph to ensure that correct escaping is used with eval(), and that this might even then not be secure. 13:57:33 francois: it's about not having access to sensitive data when you do it. 13:57:50 adam: I'll have a crack at rewording and send to the list. 13:57:59 jo: wouldn't it be better for the sake of simplicity to remove the paragraph? 13:58:03 francois: I'd prefer it removed 13:58:35 PROPOSED RESOLUTION: Remove second para of 3.2.1.2 and make no reference to efficiency 13:58:39 +1 13:58:44 +1 13:58:47 +1 13:58:59 RESOLUTION: Remove second para of 3.2.1.2 and make no reference to efficiency 13:58:59 +1 13:59:20 RESOLUTION: Remove second para of 3.2.1.2 and make no reference to efficiency 13:59:20 +1 14:00:21 +1 14:00:30 francois: one thing I can do is to write a post on the BPWG blog to trigger reactions. 14:00:51 ACTION: Francois to reach out for comments on MWABP via the BPBlog 14:00:51 Created ACTION-962 - Reach out for comments on MWABP via the BPBlog [on François Daoust - due 2009-05-19]. 14:01:06 ... could you reach your respective developer communities too? I suspect we won't get much feedback, it's a working draft and not a last call (last calls tend to trigger reactions) 14:01:23 jo: any idea of groups we should particularly outreach to? 14:01:26 brucel has joined #bpwg 14:01:45 Suggestion: if anybody blogs, try to participate in the Carnival of the mobilists: http://mobili.st. 14:02:26 adam: feels like a dearth of feedback. Been pushing hard at work for this. 14:02:48 ... I'm inclined to sit on it for a week or two whilst I make outstanding changes and wait for feedback internally. That draft can be our LC candidate. 14:02:55 jo: so LC will be end this month/early june 14:03:09 Topic: Mobile/Accessibility document - EOWG decision? 14:03:13 zakim, unmute yeliz 14:03:13 yeliz should no longer be muted 14:03:36 yeliz: as far as I know there hasn't been any agreement to proceed with the publication of the draft. 14:03:44 jo: any action required from our side? 14:04:03 francois: i've not checked emails of the education/outreach group. We took a resolution 2 weeks ago to publish the draft as soon as they're ok with it. 14:04:16 jo: so we've prior approved it... we can go ahead when ready. 14:04:32 Topic: Addendum to BP - next editorial session? 14:04:46 jo: I'm the blocker here, haven't added some further comments. We'll need an editorial session following that. 14:04:51 zakim, mute yeliz 14:04:51 yeliz should now be muted 14:06:00 RRSAgent, draft minutes 14:06:00 I have made the request to generate http://www.w3.org/2009/05/12-bpwg-minutes.html francois 14:07:29 zakim, who is making noise? 14:07:32 jo: it'll be a couple of weeks before I get a chance to do more on this. 14:07:39 Topic: CT - Abstract 14:07:41 francois, listening for 10 seconds I heard sound from the following: jo (59%), BruceL (37%) 14:08:17 zakim, mute brucel 14:08:17 BruceL should now be muted 14:08:44 brucel has joined #bpwg 14:08:52 +1 14:09:05 jo has joined #bpwg 14:09:49 bruce test 14:10:16 jo: on action 929, appreciate your input here Eduardo - I do have some comments. Apologies for not replying. 14:10:23 ... would rather make them on-list than now. 14:10:37 Let us defer then. 14:10:51 ... so let's defer that discussion. Apologies for not making progress, it'll be another couple of weeks before I can address it. 14:10:55 ... anything else on CT from anyone? 14:11:10 Topic: CT - Heuristics - mobileOptimized 14:11:44 jo: the problem with recommending specific vendor things is obvious, but if they're prevalent in the marketplace it's equally problematic not to mention them. 14:12:58 ed: MS has faced the problem of having devices that are more capable and less capable and having several ways of viewing pages - fit to screen, view as is, try to do something clever, etc. - and they realised there was a need to let developers state explicitly that the content was optimised, there's no need to try and do something clever with it, it will display OK on mobile, etc.... so ignore the default browser settings and do what the content provider intended. 14:13:29 ... so it's been there for some time. It's documented in the MS mobile windows site. Its importance is that it's a rare indication that HTML content has been developed for mobile. 14:13:52 does the metatag say *which* mobile browser/phone its already optimised for? 14:14:12 ... usually all the rules we've examined have had to do with content types, markers, which were almost-exclusively used by mobile devices and not by PC browsers... and this is the only indication in HTML content that is unambiguously indicative that this is HTML content optimised for smartphones. 14:14:44 q? 14:14:51 ... It is attached to windows mobile devices, whatever their market-share is at present. 14:14:53 zakim, unmute brucel 14:14:53 BruceL should no longer be muted 14:15:20 bruce: does it say which browser/phone the content is optimised for? Or that I as a developer am certain this is lean and mean? I'm not sure what the tag means. 14:15:29 ed: it's an indication that is meant for internet explorer 14:15:33 -> http://msdn.microsoft.com/en-us/library/ms890014.aspx Layout meta tag in MSDN 14:15:43 [[ Web developers use the MOBILEOPTIMIZED meta tag to control the Internet Explorer Mobile layout ]] 14:15:44 ... it'll be ignored by any other browser. 14:16:02 bruce: so are we saying if this tag exists it must be obeyed and no transformation must be done by any browser... or not by IE? 14:16:12 jo: it is conclusive evidence that the site has been created for mobile 14:16:33 q+ to wonder if it's evidence the site is made-for-mobile or made-for-mobile-IE? 14:17:15 jo: the question it raises to me is that if we see evidence in the markup that specific devices are being targeted... is it equally conclusive evidence that its' ready for the device we're targeting to? 14:17:29 ... if you want to show evidence your markup is targeting mobile there are lots of other ways of doing it. 14:17:44 bruce: i agree with you that we shouldn't crown any vendor-specific marker. 14:18:09 I agree with Bruce as well 14:18:36 ed: there are lots of other ways of doing it. i'd like to know what they are, given that we're restricting them. 14:19:12 ... this is the only markup I know that will work for HTML (as opposed to XHTML, WML, etc) 14:19:22 jo: you could use rel="handheld" with a self-referential link 14:19:41 q? 14:19:48 ... my preference is that vendor-specific things irrespective of whether the device belongs to that vendor is a dangerous path. 14:19:55 ack tomhume 14:19:55 tomhume, you wanted to wonder if it's evidence the site is made-for-mobile or made-for-mobile-IE? 14:19:58 ack tom 14:20:36 I'm not against vendor-specific stuff per se, and IE can obey its own metatags, but noone else should be bound by them 14:20:49 tom: Agree, this is saying IE Mobile shouldn't transform, but not sure that this could be extended to other browsers not transforming. 14:20:58 I agree that we should avoid vendor markup 14:21:28 PORPOSED RESOLUTION: Adopt the MS specific as mandatory evidence of mobile content 14:21:36 -1 14:21:41 0 14:21:42 -1 14:21:45 0 14:21:45 -1 14:21:47 -1 14:21:58 -1 14:22:01 -`1 14:22:27 Topic: CT - Heuristics - rel="stylesheet" 14:22:35 -> http://lists.w3.org/Archives/Public/public-bpwg/2009May/0011.html EdC's email 14:24:42 ed: this relates to XHTML stylesheets. You can, with some transcoders, mark stylesheets and control how much is filtered out by transcoders. The proposal is "if you see the XHTML stylesheet which is marked as mobile-ready, in principle they shouldn't be taken out". External stylesheets marked as "all" mean "good for every device". Here the point is that there are some browsers (newer ones especially) that will not consider ALT stylesheets but take desktop and ALL 14:25:03 ... since ALL covers both categories (mobile and full web), the second part of the proposal is to say "ALL means ALL" and it shouldn't be touched. 14:25:10 q+ to wonder about what should not be touched 14:25:29 ack fr 14:25:29 francois, you wanted to wonder about what should not be touched 14:25:45 francois: what should not be touched? The XHTML content, the HTML, the CSS? 14:25:47 ed: the CSS 14:26:32 francois: it only makes sense if you don't touch the XHTML. In many cases you could make changes in the HTML, then CSS changes are required... as you change the structure of the HTML page some directives are no longer valid and don't make sense. If you change the HTML you may need to change the CSS - not that CT proxies necessarily do this properly... 14:27:05 ... so we can't prevent it in the guidelines. 14:27:22 jo: this sounds like the discussion on the transformability or otherwise of images. is there a parallel worth considering? 14:27:47 ed: you might have XHTML which does links without native for handheld/desktop stylesheets. You might change the HTML but not stylesheets. 14:27:52 cgi-irc has joined #bpwg 14:27:55 Francois is correct; if you change the markup, you probably will need to change the CSS 14:28:00 jo: sean/rob? any comment? 14:28:21 q+ 14:28:38 ack edc 14:28:42 sean: agree with francois. If the markup is changed, good chance you need to change the CSS too. 14:28:54 ed: if you don't change the XHTML, does it make sense to change the CSS? No. 14:29:28 jo: this is even more similar to "if there's a no-transform on the HTML, does this have implications to included parts". We decided not, on images. Does the same argument apply here? 14:29:42 ed: The same would apply but here we're explicitly saying "yes, if it's for a mobile device". 14:29:43 q+ 14:29:53 ack s 14:30:11 sean: if you have a no-transform or some other content type, it should apply to the CSS. 14:30:17 q+ to say seems sensible to either transform both HTML and CSS together or change neither 14:30:20 jo: a derived no-transform rather than an explicit one. 14:30:30 ack rob 14:30:30 rob, you wanted to say seems sensible to either transform both HTML and CSS together or change neither 14:30:34 I need more time to think thru after the explanations ... 14:30:43 rob: agree with ed and sean. typically you'd change both HTML and CSS or neither. can't see any reason to just change CSS. 14:31:30 PROPSOED RESOLUTION: If the HTML is being treated as "no transform" then external stylesheets retrieves as a consequence of retrieving the HTML should be treated the same 14:31:49 q+ 14:31:59 ack f 14:32:45 PROPOSED RESOLUTION: If the HTML is being treated transparently then external stylesheets retrieved as a consequence of retrieving the HTML should be treated the same 14:32:57 q+ to wonder if we argued against "derived transformation" as it imposed a page model on HTTP where none existed before. 14:33:08 ack tom 14:33:08 tomhume, you wanted to wonder if we argued against "derived transformation" as it imposed a page model on HTTP where none existed before. 14:33:31 q+ 14:33:40 ack edc 14:34:06 ed: at the time, we were imposing that model on a specific feature (the no-transform directive). Here we're not saying it's linked to that... 14:34:11 q+ 14:34:16 ack f 14:35:12 q+ 14:35:30 francois: i'm confused... I can see examples where we might want to change CSS (e.g. absolute positions of resources). 14:35:52 ... we're talking about external stylesheets in general, not handheld ones. 14:36:01 jo: what about recursively referenced stylesheets? 14:36:20 ed: ALL or "handheld" would be the one to work on 14:36:22 ack edc 14:36:30 jo: how far should this go? 14:36:36 ed: as far as the recursion goes. 14:36:55 jo: what about stylesheets that are referenced from "all" or "handheld" - do they inherit properties? 14:37:00 ed: logically, yes. 14:37:39 s/from "all"/from stylesheets that are themselves references as "all" 14:38:32 jo: I'd like us not to take a resolution on this without considering our previous decision. There are caching implications here too, and indefinite numbers of recursively referenced stylesheets. 14:38:46 +1 14:38:52 +1 14:38:55 +1 14:38:58 q+ 14:38:59 +1 14:39:06 It does sound like we need to think about this a bit. 14:39:08 ack fr 14:40:06 I think that is correct. 14:40:08 francois: another question on handheld and all. One part is about having the "link alternate"... we agreed not to have "all" mentioned in the list of mandatory heuristics (for reasons I can't remember). 14:40:54 ... The same reasons should apply here as well. 14:41:03 ... we should dig into the archives. 14:41:08 Is there also a recursion problem with alternate links? 14:43:59 ISSUE: with reference to Eduardo's point about linked stylesheets, http://lists.w3.org/Archives/Public/public-bpwg/2009May/0011.html, we need to review in the light of an earlier decision on images and possibly aslo in light of a recursion problem with link rel="alternate" (per discussion of meeting on 12th May) 14:43:59 Created ISSUE-298 - With reference to Eduardo's point about linked stylesheets, http://lists.w3.org/Archives/Public/public-bpwg/2009May/0011.html, we need to review in the light of an earlier decision on images and possibly aslo in light of a recursion problem with link rel="alternate" (per discussion of meeting on 12th May) ; please complete additional details at http://www.w3.org/2005/MWI/BPWG/Group/track/issues/298/edit . 14:44:42 Topic: AOB 14:44:45 jo: anything? 14:45:05 nah 14:45:20 no from me as well 14:45:53 Bye, kisses all 14:45:56 -tomhume 14:45:57 [bye] 14:45:58 -SeanP 14:46:00 -yeliz 14:46:00 -rob 14:46:00 bye 14:46:02 -adam 14:46:08 -EdC 14:46:09 -Francois 14:46:14 -jo 14:46:26 rob has left #bpwg 14:46:33 -BruceL 14:46:34 MWI_BPWG()9:30AM has ended 14:46:35 Attendees were tomhume, jo, Francois, +41.31.972.aaaa, rob, EdC, adam, BruceL, SeanP, yeliz 14:47:00 RRSAgent, draft minutes 14:47:00 I have made the request to generate http://www.w3.org/2009/05/12-bpwg-minutes.html francois 14:50:53 bye 15:37:17 brucel has left #bpwg 16:43:54 jo_ has joined #bpwg 16:52:08 rrsagent, pointer? 16:52:08 See http://www.w3.org/2009/05/12-bpwg-irc#T16-52-08 16:52:42 jo has left #bpwg 17:01:22 Zakim has left #bpwg