[minutes] 3 April 2009 - Editorial meeting on the Addendum to the Mobile Web Best Practices working group


We had an editorial meeting on the addendum spec this morning.
We went through the actions that had been created during last week's F2F 
on the topic and closed them.
We started updating sections wording with a view to making things clear 
for readers.

The rough minutes of today's meeting are available at:
... and copied as text below.

Next steps:
- Jo will go continue to update the document in as he already did for 
sections 3.1 to 3.10.
- Another editorial meeting is planned though not scheduled yet in a few 


03 Apr 2009

    See also: [2]IRC log

       [2] http://www.w3.org/2009/04/03-bpwg-irc


           achuter, DKA, jo, jsmanrique, Kai, francois.





    The one and only one topic of the session was to review the changes
    brought to the latest draft of the Addendum to the Mobile Web Best
    Practices document, as agreed during last week's F2F, and to further
    wordsmith the document. Another editorial meeting is needed and
    should be scheduled in a few weeks.

    The following are rough minutes taken during the editorial sessions.

    The document, that was edited in real-time, is available at

       [3] http://docs.google.com/Doc?id=d2vmqg3_0c469pzdh&pli=1


       [4] http://docs.google.com/Doc?id=d2vmqg3_0c469pzdh&pli=1




       [6] http://lists.w3.org/Archives/Public/public-bpwg/2009Apr/0002.html

    Kai: I went through my actions yesterday, mostly done. I suggest
    people have a look at yellow parts in the doc.

    DKA: suggest we go through the actions.


    <trackbot> ACTION-936 -- Kai Scheppe to re-write 1.2 in a more happy
    clappy way -- due 2009-04-03 -- PENDINGREVIEW


       [7] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/936

    Kai: Section 1.2. Make it a happy clappy section.

    DKA: Wasn't there some sentiment that "may not provide as good a
    user experience" is a bit too negative?

    francois: agree with Dan.

    Kai: [going through the section]

    DKA: what about "in order to provide an optimized user experience"?

    Kai: maybe we could just strip the end of the sentence.

    <scribe> ... done. There's a formatting issue, but aside from that,
    looks fine.

    <Kai> Jo, we are talking about 1.2

    <achuter> xxxxxxxxx

    <Kai> [8]http://docs.google.com/Doc?id=d2vmqg3_0c469pzdh&pli=1

       [8] http://docs.google.com/Doc?id=d2vmqg3_0c469pzdh&pli=1

    <Kai> close action-936

    <trackbot> ACTION-936 Re-write 1.2 in a more happy clappy way closed


    <trackbot> ACTION-937 -- Kai Scheppe to correct spelling errors --
    due 2009-04-03 -- PENDINGREVIEW


       [9] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/937

    <Kai> close action-937

    <trackbot> ACTION-937 Correct spelling errors closed


    <trackbot> ACTION-938 -- Kai Scheppe to correct last paragraph of
    1.2 - it doesn't have \"tests\" and Best PRactices should read
    mobileOK Basic Tests -- due 2009-04-03 -- PENDINGREVIEW


      [10] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/938

    <Kai> close action-938

    <trackbot> ACTION-938 Correct last paragraph of 1.2 - it doesn't
    have \"tests\" and Best PRactices should read mobileOK Basic Tests


    <trackbot> ACTION-939 -- Kai Scheppe to replace example in section
    3.4 with an image (as it doesn't print etc.) -- due 2009-04-03 --


      [11] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/939

    <DKA> ACTION-939?

    <trackbot> ACTION-939 -- Kai Scheppe to replace example in section
    3.4 with an image (as it doesn't print etc.) -- due 2009-04-03 --


      [12] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/939

    Kai: ACTION-939, on the background readability.
    ... question: where do we store the image?

    francois: just close to the document. No problem.

    [DKA leaving]

    Kai: question about bibliography.
    ... Reformatted. There are fewer references than before.
    ... Online tools are referenced inline, because they are not
    ... Seems to be the way that it should be done. Is that correct?

    jo: It seems fine to me. The convention is usually that if you are
    referring to a section of a document, you link to the section and
    then add a reference to the doc.

    <Kai> close action-939

    <trackbot> ACTION-939 Replace example in section 3.4 with an image
    (as it doesn't print etc.) closed

    Kai: ok.


    <trackbot> ACTION-940 -- Kai Scheppe to provide a reference to the
    Ishigara Colour Blindness test -- due 2009-04-03 -- PENDINGREVIEW


      [13] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/940

    Kai: I used Wikipedia for the Ishihara Test for Color Blindness

    <Kai> [14]http://www.toledo-bend.com/colorblind/Ishihara.asp

      [14] http://www.toledo-bend.com/colorblind/Ishihara.asp

    jo: that does not seem so right.

    Kai: I can't think of a better way.

    <jo> [ISHiHARA} ^ S. Ishihara, Tests for colour-blindness (Handaya,
    Tokyo, Hongo Harukicho, 1917).

    <jo> [ISHiHARA] S. Ishihara, Tests for colour-blindness (Handaya,
    Tokyo, Hongo Harukicho, 1917).

    jo: The reference is presumably something like what I just pasted.
    This is of no use to anyone, but that's the reference.

    Kai: we're trying to show something, so providing a link looks much
    more useful.

    jo: I don't disagree. (©Jo)

    Kai: there is another view we may take on this. Alan said that a
    test for colour-blindness was maybe not the correct test to consider
    for background readability.
    ... We could simply drop it then.

    jo: if we can't find something more authoritative than Wikipedia,
    then let's drop it, yes.

    kai: any dissent?


    Kai: OK. Gone.

    <Kai> close action-940

    <trackbot> ACTION-940 Provide a reference to the Ishigara Colour
    Blindness test closed


    <trackbot> ACTION-941 -- Kai Scheppe to add a refernce to the
    algorithm for determining contrast -- due 2009-04-03 --


      [15] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/941

    Kai: ACTION-941, contained in the reference to WCAG2.

    <Kai> close action-941

    <trackbot> ACTION-941 Add a refernce to the algorithm for
    determining contrast closed


    <trackbot> ACTION-942 -- Kai Scheppe to drop section 2. And maybe
    insert an explanatory section on the layout of the evaluations (to
    maintain numbering) -- due 2009-04-03 -- PENDINGREVIEW


      [16] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/942

    Kai: I removed former section 2, and added a new one.

    <jsmanrique> what about "relevant context delivery properties"?

    francois: wondering about "device properties". Not anymore limited
    to "device".

    Kai: Jo proposed some text in 3.1: Relevant Delivery Context

    jo: that would be consistent with other documents, yes.

    francois: and it encompasses more than just device. I agree with


      [17] http://www.lighthouse.org/accessibility/effective-color-contrast/

    <achuter> Is good resource for color contrast

    jo: note I went through the document and did a bit of
    ... I've touched a lot of the document, actually.

    kai: ok, will take them into account.
    ... back to topic. Replace "Relevant Device Properties" by "Relevant
    Delivery Context Properties"?

    <jsmanrique> +1

    [general agreement]

    Kai: can I delete the original section 2?

    jo: I don't find 2.1 as being out of scope.

    francois: I was the one who felt it is out of context, because we're
    talking about evaluation procedures, carried by a guy in front of
    his computer, no need for a digital format to express the result.

    jo: ok, how about this?

    <jsmanrique> fine for me

    [jo editing section 2.1]

    jo: I think it's better if we keep it as short as possible in
    general. So I just cut in the flesh of your text, Kai.

    kai: looks fine.

    <Kai> close action-942

    <trackbot> ACTION-942 Drop section 2. And maybe insert an
    explanatory section on the layout of the evaluations (to maintain
    numbering) closed


    <trackbot> ACTION-943 -- Kai Scheppe to rephrase 3.15 ref tables --
    due 2009-04-03 -- PENDINGREVIEW


      [18] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/943

    Kai: About 3.15, I did some rewording around "test"
    ... The examples section is the one that was most updated.
    ... I integrated francois' comment on not endorsing the use of
    tables for layout.

    <jsmanrique> "While tables should never be used for layout
    purposes", what about "must never be used"

    jo: I don't think it says anything different from BP1.0, does it?
    ... It is very hard to say something that is actionable in this

    <jo> --> [19]http://www.w3.org/TR/mobile-bp/#d0e704 DEFICIENCIES

      [19] http://www.w3.org/TR/mobile-bp/#d0e704

    francois: agree with Jo that this doesn't add anything to what's
    already being said in BP1.0

    Kai: ok, we can simply remove it then.

    [agreement to remove current section 3.15]

    Close ACTION-943

    <trackbot> ACTION-943 Rephrase 3.15 ref tables closed


    <trackbot> ACTION-944 -- Kai Scheppe to drop 4. in 3.17 -- due
    2009-04-03 -- PENDINGREVIEW


      [20] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/944

    <Kai> close action-944

    <trackbot> ACTION-944 Drop 4. in 3.17 closed

    Kai: another question on 3.17. That's where we mentioned the "face"

    <Kai> [21]http://www.w3schools.com/TAGS/att_font_face.asp

      [21] http://www.w3schools.com/TAGS/att_font_face.asp

    jo: isn't that a bit moot since the font element is deprecated?

    kai: I think we can remove the bullet point without losing anything.

    jo: let's take it out, then.

    <Kai> close action-944

    <trackbot> ACTION-944 Drop 4. in 3.17 closed

    jo: I think there's some editorial changes that need to be done to
    section 3.17.
    ... It needs to be clarified a bit, in the sense that if you use the
    em element, then the result of it is that it will appear in italic.
    ... so are talking about the direct use of deprecated elements or
    the visible result?

    <jo> <em>Oh!</em>

    kai: using "em" would be the correct way of doing it.

    <Kai> <b<Oh!>/b>

    kai: but using "b" would not be correct.

    jo: what it says is that we're saying use semantic tags. We need to
    be clear that we're not saying don't use them.
    ... We already say this somewhere between mobileOK and BP1.0
    ... So what does it add?

    kai: let's say I use a bold element to express a heading element

    francois: the mobileOK Checker fails for this at two different
    steps: 1. XHTML validation, and 2. STYLE_SHEETS_USE test

    <jsmanrique> [22]http://www.w3.org/TR/mobile-bp/#fonts

      [22] http://www.w3.org/TR/mobile-bp/#fonts

    kai: the Human test part is not checked.

    francois: ok, first bullet point is the machine test, no need to

    [jo rewriting first bullet point to make a reference to mobileOK]

    francois: more generic question on the use of the term "check". It
    does not help assess whether it's good or bad.

    [more rewriting]

    jo: the first bullet is not dependent on CSS. The second bullet is.
    The third bullet can go.

    kai: ok.

    jo: As an editorial point, I tried to stick to "verify" and "assess"
    in changes I made.
    ... The goal is to replace "check" and make it clearer what is good
    or bad.
    ... On the examples part, bold and underline are either the result
    of using semantic elements that render as bold or underline or the
    result of the direct use of using b and u elements.

    kai: it says "expressed", not "rendered"
    ... but please reword.


      [23] http://www.w3.org/TR/html401/struct/text.html#edef-Q


    <trackbot> ACTION-945 -- Kai Scheppe to move 3.18 Note into examples
    -- due 2009-04-03 -- PENDINGREVIEW


      [24] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/945

    kai: moved it to the examples part.

    <Kai> close action-945

    <trackbot> ACTION-945 Move 3.18 Note into examples closed

    francois: already contained in second and third bullets.

    kai: remove?

    francois: yes.


    <trackbot> ACTION-946 -- Kai Scheppe to add bandwidth to device
    properties in 3.30 -- due 2009-04-03 -- PENDINGREVIEW


      [25] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/946

    kai: I added bandwidth. And reworded the second bullet on style
    properties being used somewhere in the Web site.
    ... Looks good?

    <jsmanrique> makes sense for me

    jo: that seems fine.

    <Kai> close action-946

    <trackbot> ACTION-946 Add bandwidth to device properties in 3.30

    <jsmanrique> left 20%

    <jsmanrique> remove 10%

    jo: on the evaluation procedure, what do we mean by "more than

    francois: we should just pick up a number. 10% would be consistent
    with mobileOK (limited to the document)

    jo: it's 10% for warning, 25% for FAIL in mobileOK. We do not talk
    about stylesheets.

    [updating to 25%]

    <jo> compare: #0f0 green

    jo: the last 2 bullet points will have very minimal effect, won't

    <jsmanrique> not sure, but maybe the phone should "translate" green
    to #0f0 and the render it...

    kai: I agree, the effect is very small.

    <jo> border: thin solid black

    <jo> border-style: solid

    kai: I don't remember the exact discussion around "shorthand", but
    there are techniques that can make CSS considerably shorter.

    <jo> border-color: black

    <jsmanrique> that's right

    <jsmanrique> what about providing examples?

    jo: I understand shorthand as using the property without '-'

    kai: I think it referred to something else but don't remember what.

    <Kai> [26]http://www.dustindiaz.com/css-shorthand/

      [26] http://www.dustindiaz.com/css-shorthand/

    francois: we should remove the bullet piont then if we don't
    understand it.

    jo: it doesn't make significant difference in my view.
    ... Besides, shorthand values are harder to read and write because
    you never know the exact ordering and number of values you need to
    put in there.
    ... Probably not a good idea to mention it then.

    kai: ok, removed.

    <Kai> close action-946

    <trackbot> ACTION-946 Add bandwidth to device properties in 3.30


    <trackbot> ACTION-948 -- Kai Scheppe to rephrase 3.34 to not call
    for table layout and propose CSS based solution as in DTAG -- due
    2009-04-03 -- PENDINGREVIEW


      [27] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/948

    kai: I rewrote the section.

    jo: I'm not sure what is the point that you're trying to make here.

    kai: imagine a table with 6 cells, 3 at the top, 3 at the bottom.
    ... now you increase the content of the first cell. You'll have a
    nice layout where cells heights adjust.
    ... I had a discussion with Bert Bos on that, and he said it will be
    fixed in the upcoming version of CSS.

    <DKA> "the conference is restricted at this time"

    <jsmanrique> ok


      [28] http://www.w3.org/TR/mobile-bp/#TABLES_LAYOUT

    francois: I think it all boils down to "what is the use of this
    ... It does not add much to what is already defined in BP1.0

    Kai: you cannot test every possibility using a machine test.

    francois: I agree. And indeed, there's no human test mentioned in

    kai: the question is then, can we limit ourselves to "check if
    tables are used in a fashion that could be achieved using CSS".
    ... Getting back to limitations of this test. I think tables are
    still being used for layout throughout the place.

    jo: I'm not understanding what the problem is, but then it does not
    really matter.

    kai: imagine a grid layout with 3 divs that are next to each other.
    ... [some more explanation]
    ... I feel that I'm beating up a dead horse.

    francois: plus the section basically says there's some CSS solution
    to the CSS limitation.

    Kai: right. It doesn't work in all cases.
    ... But, like I said, let's remove the Limitations of the test part.

    <Kai> close action-948

    <trackbot> ACTION-948 Rephrase 3.34 to not call for table layout and
    propose CSS based solution as in DTAG closed

    [general agreement]


    <trackbot> ACTION-950 -- Kai Scheppe to remove bullet 4 in 3.14 --
    due 2009-04-03 -- PENDINGREVIEW


      [29] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/950

    kai: I removed the bullet.

    Close ACTION-950

    <trackbot> ACTION-950 Remove bullet 4 in 3.14 closed

    <Kai> close action-950

    <trackbot> ACTION-950 Remove bullet 4 in 3.14 closed


    <trackbot> ACTION-951 -- Kai Scheppe to propose some text on 3.30
    ref. *all* CSS for next editorial session -- due 2009-04-03 --


      [30] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/951

    francois: already covered

    <Kai> close action-951

    <trackbot> ACTION-951 Propose some text on 3.30 ref. *all* CSS for
    next editorial session closed


    <trackbot> ACTION-949 -- Kai Scheppe to change access to access keys
    in 3.1 -- due 2009-04-03 -- OPEN


      [31] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/949

    jo: I rewrote it.

    kai: so, done.

    <Kai> close action-949

    <trackbot> ACTION-949 Change access to access keys in 3.1 closed

    ACTION 947?

    <trackbot> Sorry, bad ACTION syntax


    <trackbot> ACTION-947 -- Jo Rabin to send Kai an example of 3 col
    layout where column balance is maintained -- due 2009-04-03 -- OPEN


      [32] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/947

    close ACTION-947

    <trackbot> ACTION-947 Send Kai an example of 3 col layout where
    column balance is maintained closed

    jo: I went through the 10 first procedures, need to go through the
    remaining ones.

    kai: ok. Thanks for doing it.
    ... One suggestion you have is to link to BP and mobileOK where

    jo: yes, appropriate as in not all BPs have corresponding mobileOK
    ... I propose an extra section be added to link to mobileOK tests.

    kai: I thought we had said that we wanted no connection whatsoever
    with mobileOK

    francois: the problem IMO is with the confusion it might create with
    DDC and non DDC.

    kai: I propose we just leave it and don't do anything.

    DKA: +1

    jo: Let me try it and we'll see where that leads.

    kai: OK. I'd like to go through the comments that were made as a
    response to the questionnaire

    francois: I thought all the actions were the result of the comments

    kai: not sure, actually.

    <jo> this is an aut-generated contents list from xml-spec

    <jo> <a name="contents" id="contents">1 </a><a

    <jo> &nbsp;&nbsp;&nbsp;&nbsp;1.1 <a href="#scope">Scope</a><br>

    <jo> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1.1.1 <a
    href="#relationship_to_best_practices">Relationship to Best

    <jo> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1.1.2 <a
    href="#out_of_scope">Out of Scope</a><br>

    <jo> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1.1.3 <a
    href="#beyond_mobileok">Beyond mobileOK</a><br>

    <jo> &nbsp;&nbsp;&nbsp;&nbsp;1.2 <a

    <jo> &nbsp;&nbsp;&nbsp;&nbsp;1.3 <a
    href="#claiming_mobileok_conformance">Claiming mobileOK

    francois: suggest to leave that on the side for the time being, and
    have a look at Jo's changes in the first ten procedures so that he
    doesn't continue in a direction we don't like.

    kai: right, that was my second item, indeed.
    ... on to yellow notes then.
    ... Jo wonders what a site map means

    [explanations exchanged]

    francois: the order of sub-sections in 3.1 does not match that of

    kai: will change 2.2

    [quickly going through procedures]

    kai: on to 3.5. The formatting is not correct either.
    ... and there were more navigation means

    jo: I think Dan's colleague made a clear explanation back in Sophia
    ... Stylus is what I was looking for.

    francois: note a minor problem with order of the sub-sections in 3.5

    jo: updating...

    kai: on to 3.6. and the reference to HTTP.
    ... aren't we just tossing the whole bag of technologies in this

    jo: Yes, we are.
    ... replacing HTTP with XHR support
    ... The evaluation procedure does not look very workable.

    kai: if you make a check for the DDC and make assumptions on the
    capabilities it is supposed to have. And then you are trying to
    improve your content for more capable devices.
    ... So you want to check that content has not been unnecessarily
    dumbed down.
    ... We're just trying to make it measurable.
    ... The easiest idea was to compare to DDC.

    jo: I think it should be easier than that. If there are multiple
    versions available, then ensure they are adapted for the classes of
    devices they target.

    kai: isn't that too general?

    jo: let me try some wording.

    <scribe> [ongoing rewording]

    kai: I understand the point. But what we're trying to say is exploit
    capabilities at a maximum
    ... your suggestion would leave it totally open.
    ... I understand what we're trying to do. But we want it to be

    jo: It needed to be measurable when it was a PASS/FAIL document,
    which it is not anymore.
    ... You want the best fit. That's what I'm trying to propose. The
    text needs to be clarified though.

    <Zakim> DKA, you wanted to note "exploitative" has a negative

    DKA: I don't think we should dump the section.
    ... we've already discussed in the past that "exploitative" has some
    negative sense.

    jo: already gone.

    [discussion about going for a revolution and changing the "Exploit"
    device capabilities BP title]

    kai: I wonder what the group wants out of this document.
    ... We had the initial requirement that evaluation procedures needed
    to be testable. Has this gone?
    ... Jo is proposing a totally correct but untestable statement here.

    jo: I don't think that what you wrote in the first place works

    kai: It does.

    jo: no

    kai: yes

    jo: I think the "exploit device capabilities" piece of advice is
    good, but wishy washy.
    ... Serving the iPhone representation to a device that is not an
    iPhone is wrong, for instance.
    ... So comparing to the DDC is wrong.

    kai: I agree. It's still a test to help check the BP.
    ... let's make a quick poll.

    francois: agree with Jo's wording, but agree as well with your point
    Kai. If we cannot come up with a more detailed evaluation procedure,
    the whole thing is becoming useless.

    [more discussion on the topic]

    francois: next steps on the document?

    kai: jo wants to go on with editorial changes. That's fine by me.
    Then another editorial meeting is needed.

    francois: I agree.

    jo: I will schedule another editorial session, but it's going to
    take a couple of weeks.

    kai: let's aim for 3 hours as well.

    [meeting adjourned]

    [End of minutes]

Received on Friday, 3 April 2009 11:10:02 UTC