[minutes] BPWG F2F - Day 1/3

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

[minutes] BPWG F2F - Day 1/3

Francois Daoust
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]