W3C home > Mailing lists > Public > public-bpwg@w3.org > May 2009

[minutes] 12 May 2009 Teleconference

From: Francois Daoust <fd@w3.org>
Date: Tue, 12 May 2009 17:27:45 +0200
Message-ID: <4A099571.6000806@w3.org>
To: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
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]
Received on Tuesday, 12 May 2009 15:28:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:00 UTC