- From: Tom Hume <tom.hume@futureplatforms.com>
- Date: Tue, 12 May 2009 23:34:04 +0100
- To: Luca Passani <passani@eunet.no>
- Cc: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
> "tom: Agree, this is saying IE Mobile shouldn't transform, but not sure that > this could be extended to other browsers not transforming." > But it certainly can be extended to transcoders to let them know they should > not transcode. There's an explanation of what this tag is for here: http://blogs.msdn.com/iemobile/archive/2006/08/03/Detecting_IE_Mobile.aspx It's a hint to IE to turn off layout optimisations for mobile devices. I don't think it follows that content designed specifically for mobile IE can automatically be considered ready for consumption on *all* other mobile devices. If I access a site designed for mobile IE using a Series 40 browser, it may be helpful to me for transformation to take place (subject to the no-transform being respected and headers only being altered if the user has specifically asked for them to be, etc etc). IMHO it's also a poor heuristic for determining mobile-readiness, given that it's proprietary to a single vendor, and other more prevalent mechanisms exist. Tom Of course, I am no longer expecting you to acknowledge > self-evidence, Tom. Do you still go around claiming that you represent > developers of some sort? > > "<SeanP> I agree that we should avoid vendor markup" > > of course. Sean, I deeply admire your perseverance. > > "<jo> PORPOSED RESOLUTION: Adopt the MS specific <meta > name="MobileOptimized" content="NNN"> as mandatory evidence of mobile > content > <jo> -1" > > So much for .Mobi standing by the side of developers, Jo. > > Luca > > Francois Daoust wrote: >> >> Hi, >> >> The minutes of today's call are available at: >> http://www.w3.org/2009/05/12-bpwg-minutes.html >> ... and copied as text below. >> >> Resolutions taken during the call: >> - 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 >> - on MWABP, remove second para of 3.2.1.2 and make no reference to >> efficiency >> >> Francois. >> >> >> ----- >> 12 May 2009 >> >> [2]Agenda >> >> [2] http://lists.w3.org/Archives/Public/public-bpwg/2009May/0012.html >> >> See also: [3]IRC log >> >> [3] http://www.w3.org/2009/05/12-bpwg-irc >> >> Attendees >> >> Present >> tomhume, jo, Francois, rob, EdC, adam, BruceL, SeanP, yeliz >> >> Regrets >> jeffs, kai, abel, miguel, nacho >> >> Chair >> jo >> >> Scribe >> Tom >> >> Contents >> >> * [4]Topics >> 1. [5]FYI - lang attribute back in XHTML Basic 1.1 >> 2. [6]MWABP - new draft out. Feedback needed. Next steps? >> 3. [7]Mobile/Accessibility document - EOWG decision? >> 4. [8]Addendum to BP - next editorial session? >> 5. [9]CT - Abstract >> 6. [10]CT - Heuristics - mobileOptimized >> 7. [11]CT - Heuristics - rel="stylesheet" >> 8. [12]AOB >> * [13]Summary of Action Items >> _________________________________________________________ >> >> FYI - lang attribute back in XHTML Basic 1.1 >> >> 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. >> ... This is good news in that we're consistent with the I18N group. >> >> jo: is there a DTD we could use if we want to? >> >> <francois> [14]XHTML Basic 1.1 PER >> >> [14] http://www.w3.org/TR/2009/PER-xhtml-basic-20090507/ >> >> francois: there's a schema for those who prefer it. >> >> <francois> [15]DTD in the spec >> >> [15] http://www.w3.org/TR/2009/PER-xhtml-basic-20090507/#a_dtd >> >> francois: this section contains links to the actual files - the >> version associated with the document and that evolving over time. >> >> jo: when should we edit the checker? >> >> francois: wait for the document to become a recommendation, and then >> update the checker >> >> jo: do we refer to a specific version in the checker? >> >> francois: we're not talking about editions in the document >> >> jo: we don't say anything specific at all, if we're talking about >> mobileOK basic >> >> 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. >> ... 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). >> >> jo: but it's not an erratum, it's a clarification... >> >> 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. >> ... let's wait for XHTML Basic to become a recommendation. >> >> <jo> 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 >> >> <brucel> agree >> >> <rob> +1 >> >> <francois> +1 >> >> 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 >> >> <EdC> +1 >> >> jo: francois, can you enact this pls? >> >> <jo> ACTION: daoust to enact the resolution on XHTML Basic 1.1 >> revision - when it reaches rec [recorded in >> [16]http://www.w3.org/2009/05/12-bpwg-minutes.html#action01] >> >> <trackbot> Created ACTION-959 - Enact the resolution on XHTML Basic >> 1.1 revision - when it reaches rec [on François Daoust - due >> 2009-05-19]. >> >> <yeliz> +1 >> >> MWABP - new draft out. Feedback needed. Next steps? >> >> <francois> [17]new draft of MWABP >> >> [17] http://www.w3.org/TR/2009/WD-mwabp-20090507/ >> >> jo: we've had no feedback on this document as yet. >> >> 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. >> >> <EdC> What about the pending feedback from Francois and myself? >> >> jo: How do you tell that feature is present? >> >> adam: It's supported based on the target platform. Good question. >> >> 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 >> >> adam: agree >> >> <jo> ISSUE: Should we have a BP on appcache? >> >> <trackbot> Created ISSUE-297 - Should we have a BP on appcache? ; >> please complete additional details at >> [18]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/297/edit . >> >> [18] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/297/edit >> >> 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. >> >> edc: I suggest you write a proposal and I'll comment on it again. >> ... The other issue is on sprites. >> >> <francois> [19]3.4.6 CSS Sprites >> >> [19] http://www.w3.org/TR/2009/WD-mwabp-20090507/#d1e8981 >> >> <jo> ACTION: adam to write a proposal in answer to EdC's comments on >> 3.6.1 and 3.6.2 [recorded in >> [20]http://www.w3.org/2009/05/12-bpwg-minutes.html#action02] >> >> <trackbot> 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]. >> >> 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" >> >> 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. >> >> adam: can someone take an action to investigate multipart-mixed? >> >> <jo> ACTION: Tom to investiagate multipart-mixed in the context of >> 3.4.6 and 3.4.7 of MWABP [recorded in >> [21]http://www.w3.org/2009/05/12-bpwg-minutes.html#action03] >> >> <trackbot> 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]. >> >> francois: I sent a comment about the security stuff (2.1 - do not >> execute untrusted Javascript). Final paragraph needs rewriting. >> >> <francois> [22]3.2.1 JSON >> >> [22] http://www.w3.org/TR/2009/WD-mwabp-20090507/#d1e542 >> >> francois: 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. >> ... so maybe it's not a good idea there. >> >> 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. >> >> francois: it's about not having access to sensitive data when you do >> it. >> >> adam: I'll have a crack at rewording and send to the list. >> >> jo: wouldn't it be better for the sake of simplicity to remove the >> paragraph? >> >> francois: I'd prefer it removed >> >> <jo> PROPOSED RESOLUTION: Remove second para of 3.2.1.2 and make no >> reference to efficiency >> >> +1 >> >> <rob> +1 >> >> <yeliz> +1 >> >> RESOLUTION: Remove second para of 3.2.1.2 and make no reference to >> efficiency >> >> <francois> +1 >> >> RESOLUTION: Remove second para of 3.2.1.2 and make no reference to >> efficiency >> >> <adam> +1 >> >> <EdC> +1 >> >> francois: one thing I can do is to write a post on the BPWG blog to >> trigger reactions. >> >> <jo> ACTION: Francois to reach out for comments on MWABP via the >> BPBlog [recorded in >> [23]http://www.w3.org/2009/05/12-bpwg-minutes.html#action04] >> >> <trackbot> Created ACTION-962 - Reach out for comments on MWABP via >> the BPBlog [on François Daoust - due 2009-05-19]. >> >> francois: 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) >> >> jo: any idea of groups we should particularly outreach to? >> >> <EdC> Suggestion: if anybody blogs, try to participate in the >> Carnival of the mobilists: [24]http://mobili.st. >> >> [24] http://mobili.st/ >> >> adam: feels like a dearth of feedback. Been pushing hard at work for >> this. >> ... 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. >> >> jo: so LC will be end this month/early june >> >> Mobile/Accessibility document - EOWG decision? >> >> yeliz: as far as I know there hasn't been any agreement to proceed >> with the publication of the draft. >> >> jo: any action required from our side? >> >> 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. >> >> jo: so we've prior approved it... we can go ahead when ready. >> >> Addendum to BP - next editorial session? >> >> jo: I'm the blocker here, haven't added some further comments. We'll >> need an editorial session following that. >> ... it'll be a couple of weeks before I get a chance to do more on >> this. >> >> CT - Abstract >> >> <adam> +1 >> >> <brucel> bruce test >> >> jo: on action 929, appreciate your input here Eduardo - I do have >> some comments. Apologies for not replying. >> ... would rather make them on-list than now. >> >> <EdC> Let us defer then. >> >> jo: so let's defer that discussion. Apologies for not making >> progress, it'll be another couple of weeks before I can address it. >> ... anything else on CT from anyone? >> >> CT - Heuristics - mobileOptimized >> >> 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. >> >> 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. >> ... 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. >> >> <brucel> does the metatag say *which* mobile browser/phone its >> already optimised for? >> >> ed: 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. >> ... It is attached to windows mobile devices, whatever their >> market-share is at present. >> >> 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. >> >> ed: it's an indication that is meant for internet explorer >> >> <francois> [25]Layout meta tag in MSDN >> >> [25] http://msdn.microsoft.com/en-us/library/ms890014.aspx >> >> <francois> [[ Web developers use the MOBILEOPTIMIZED meta tag to >> control the Internet Explorer Mobile layout ]] >> >> ed: it'll be ignored by any other browser. >> >> 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? >> >> jo: it is conclusive evidence that the site has been created for >> mobile >> ... 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? >> ... if you want to show evidence your markup is targeting mobile >> there are lots of other ways of doing it. >> >> bruce: i agree with you that we shouldn't crown any vendor-specific >> marker. >> >> <yeliz> I agree with Bruce as well >> >> ed: there are lots of other ways of doing it. i'd like to know what >> they are, given that we're restricting them. >> ... this is the only markup I know that will work for HTML (as >> opposed to XHTML, WML, etc) >> >> jo: you could use rel="handheld" with a self-referential link >> ... my preference is that vendor-specific things irrespective of >> whether the device belongs to that vendor is a dangerous path. >> >> <Zakim> tomhume, you wanted to wonder if it's evidence the site is >> made-for-mobile or made-for-mobile-IE? >> >> <brucel> I'm not against vendor-specific stuff per se, and IE can >> obey its own metatags, but noone else should be bound by them >> >> tom: Agree, this is saying IE Mobile shouldn't transform, but not >> sure that this could be extended to other browsers not transforming. >> >> <SeanP> I agree that we should avoid vendor markup >> >> <jo> PORPOSED RESOLUTION: Adopt the MS specific <meta >> name="MobileOptimized" content="NNN"> as mandatory evidence of >> mobile content >> >> <jo> -1 >> >> <rob> 0 >> >> -1 >> >> <EdC> 0 >> >> <francois> -1 >> >> <SeanP> -1 >> >> <yeliz> -1 >> >> <brucel> -`1 >> >> CT - Heuristics - rel="stylesheet" >> >> <francois> [26]EdC's email >> >> [26] http://lists.w3.org/Archives/Public/public-bpwg/2009May/0011.html >> >> 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 >> ... 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. >> >> <Zakim> francois, you wanted to wonder about what should not be >> touched >> >> francois: what should not be touched? The XHTML content, the HTML, >> the CSS? >> >> ed: the CSS >> >> 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... >> ... so we can't prevent it in the guidelines. >> >> jo: this sounds like the discussion on the transformability or >> otherwise of images. is there a parallel worth considering? >> >> ed: you might have XHTML which does links without native for >> handheld/desktop stylesheets. You might change the HTML but not >> stylesheets. >> >> <SeanP> Francois is correct; if you change the markup, you probably >> will need to change the CSS >> >> jo: sean/rob? any comment? >> >> sean: agree with francois. If the markup is changed, good chance you >> need to change the CSS too. >> >> ed: if you don't change the XHTML, does it make sense to change the >> CSS? No. >> >> 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? >> >> ed: The same would apply but here we're explicitly saying "yes, if >> it's for a mobile device". >> >> sean: if you have a no-transform or some other content type, it >> should apply to the CSS. >> >> jo: a derived no-transform rather than an explicit one. >> >> <Zakim> rob, you wanted to say seems sensible to either transform >> both HTML and CSS together or change neither >> >> <brucel> I need more time to think thru after the explanations ... >> >> 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. >> >> <jo> 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 >> >> <jo> 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 >> >> <Zakim> tomhume, you wanted to wonder if we argued against "derived >> transformation" as it imposed a page model on HTTP where none >> existed before. >> >> 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... >> >> francois: i'm confused... I can see examples where we might want to >> change CSS (e.g. absolute positions of resources). >> ... we're talking about external stylesheets in general, not >> handheld ones. >> >> jo: what about recursively referenced stylesheets? >> >> ed: ALL or "handheld" would be the one to work on >> >> jo: how far should this go? >> >> ed: as far as the recursion goes. >> >> jo: what about stylesheets that are referenced from stylesheets that >> are themselves references as "all" or "handheld" - do they inherit >> properties? >> >> ed: logically, yes. >> >> 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. >> >> +1 >> >> <francois> +1 >> >> <brucel> +1 >> >> <yeliz> +1 >> >> <SeanP> It does sound like we need to think about this a bit. >> >> <SeanP> I think that is correct. >> >> 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). >> ... The same reasons should apply here as well. >> ... we should dig into the archives. >> >> <EdC> Is there also a recursion problem with alternate links? >> >> <jo> ISSUE: with reference to Eduardo's point about linked >> stylesheets, >> [27]http://lists.w3.org/Archives/Public/public-bpwg/2009May/0011.htm >> l, 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) >> >> [27] http://lists.w3.org/Archives/Public/public-bpwg/2009May/0011.html >> >> <trackbot> Created ISSUE-298 - With reference to Eduardo's point >> about linked stylesheets, >> [28]http://lists.w3.org/Archives/Public/public-bpwg/2009May/0011.htm >> l, 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 >> [29]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/298/edit . >> >> [28] http://lists.w3.org/Archives/Public/public-bpwg/2009May/0011.html >> [29] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/298/edit >> >> AOB >> >> jo: anything? >> >> <brucel> nah >> >> <yeliz> no from me as well >> >> <brucel> Bye, kisses all >> >> <jo> [bye] >> >> <EdC> bye >> >> Summary of Action Items >> >> [NEW] ACTION: adam to write a proposal in answer to EdC's comments >> on 3.6.1 and 3.6.2 [recorded in >> [30]http://www.w3.org/2009/05/12-bpwg-minutes.html#action02] >> [NEW] ACTION: daoust to enact the resolution on XHTML Basic 1.1 >> revision - when it reaches rec [recorded in >> [31]http://www.w3.org/2009/05/12-bpwg-minutes.html#action01] >> [NEW] ACTION: Francois to reach out for comments on MWABP via the >> BPBlog [recorded in >> [32]http://www.w3.org/2009/05/12-bpwg-minutes.html#action04] >> [NEW] ACTION: Tom to investiagate multipart-mixed in the context of >> 3.4.6 and 3.4.7 of MWABP [recorded in >> [33]http://www.w3.org/2009/05/12-bpwg-minutes.html#action03] >> >> [End of minutes] >> >> > > > -- Future Platforms: hungry and foolish since 2000 work: Tom.Hume@futureplatforms.com play: tomhume.org
Received on Tuesday, 12 May 2009 22:35:00 UTC