W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Draft Minutes: 2 May 2012 f2f meeting

From: Arthur Barstow <art.barstow@nokia.com>
Date: Tue, 08 May 2012 13:11:41 -0400
Message-ID: <4FA953CD.2000209@nokia.com>
To: public-webapps <public-webapps@w3.org>
The Draft minutes from WebApps' May 2 f2f meeting are in 
<http://www.w3.org/2012/05/02-webapps-minutes.html> and are copied below.

If you have any corrections, please send them to this list by May 15.

-Thanks, AB


       [1] http://www.w3.org/

                                - DRAFT -

                          WebApps WG f2f Meeting

02 May 2012



    See also: [3]IRC log

       [3] http://www.w3.org/2012/05/02-webapps-irc


           Arnaud_Braud, Art_Barstow, Charles_McCathieNevile,
           Philippe_LeHegaret, Glenn_Adams, Josh_Soref, Tony_Ross,
           Mike_Smith, Paul_Cotton, Anne_VanKesteren,
           Odin_HortheOmdal, Magnus_Olsson, Adrian_Bateman,
           Kris_Krueger, Bryan_Sullivan, Ryosuke_Niwa,
           Eric_Uhrhane, Yosuke_Funahashi, Soonbo_Han,
           Doug_Schepers, Tantek_Celik, chaals, Ted_OConnor,
           Joshua_Bell, Sam_Weinig, Ojan_Vafai, Jonas_Sicking,
           Dan_Druta, Russell_Berkoff(Samsung), Michael_Nordman,
           ericu, Brad_Hill, Jeff_Hodges, Travis_Leithead,
           Adam_Barth, Eric_Rescorla, Dimitri_Glazkov, krisk

           Art_Barstow, Charles_McCathieNevile

           Josh_Soref, chaals


      * [4]Topics
          1. [5]Introductions
          2. [6]Fullscreen
          3. [7]CORS
          4. [8]D3E/D4
          5. [9]Specs severed from HTML
          6. [10]Server Sent Events
          7. [11]Messaging
          8. [12]Web Sockets
          9. [13]Web Workers
         10. [14]Index DB
         11. [15]Feature Detection
         12. [16]Stabilizing Specifications
         13. [17]Testing
         14. [18]Meetings
         15. [19]Warnings for old DOM Specifications
      * [20]Summary of Action Items

<ArtB> Scribe: Josh_Soref

<ArtB> ScribeNick: timeless

<ArtB> Date: 2 May 2012

<ArtB> [21]CORS Comments from Jeff Hodges


<chaals> [Waiting for the local people to turn up. Meeting
    delayed until 9.45]


    chaals: Thanks for turning up
    ... we could start with fullscreen


    anne: there isn't much
    ... i wasn't sure if the CSS WG wanted to publish it
    ... i don't want to be a part of the CSS WG

    chaals: tantek is part of the CSS WG
    ... part of the work is CSS stuff
    ... you don't need to be part of the group

    tantek: anne and I worked together, that's probably sufficient

    anne: it's also being worked on in a CG

    chaals: it should be published in this WG
    ... we don't have a joint deliverable with the CG

    tantek: that's why i'm asking if we can publish in both

    ArtB: i don't think there's a process that says you can't
    ... CGs can do whatever they want

    tantek: it's a joint WebApps+CSS WG deliverable
    ... but the work is being done in the CG
    ... we'd like to publish in all 3 places

    chaals: taking off my chair hat
    ... opera has a preference that it not be done in lots of
    ... there's a risk that no one really follows it
    ... as a chair of this WG, the deliverable has to be published
    in this WG
    ... what the CG does is neither our problem, nor our interest

    shepazu: CGs cannot work on things that WGs are chartered to do

    tantek: I looked for that, but couldn't find it

    anne: what if the CG was working on it first?

    chaals: it wasn't, the CSS WG did it first

    shepazu: it was never chartered

    tantek: Mozilla worked on it first

    shepazu: we'll have to sort this out

    tantek: last I looked, I didn't find an answer
    ... I still don't think there's an answer
    ... I even pointed Ian Jacobs explicitly to that
    ... I don't see a conflict
    ... I don't see a technical or political reason not to

    shepazu: what's the point in working on it there?
    ... why have a CG to work on it there instead of the WGs?

    tantek: there are multiple reasons
    ... one is broader distribution
    ... another is flexible licensing
    ... we see no reason not to take advantage of that as well

    shepazu: i'm not going to get into that

<Ms2ger> shepazu, why not?

    hober: fullscreen is an interesting part of the web platform

<Ms2ger> shepazu, that's quite an important point

    hober: w3c is organized into things
    ... normally things with overlap fall through the cracks
    ... having it worked on simultaneously sounds great

    paulc: i'm an observer
    ... and just interested in the discussion
    ... are you talking about a simultaneous publication?

<shepazu> Ms2ger, because we have work to do in this expensive
    f2f time, and that's a rathole

    chaals: I believe so

    tantek: i don't see this as a synchronization dependency
    ... but the document, as it live, gets published
    ... it's the same document
    ... there's some w3c legwork

    chaals: from the chair's perspective.
    ... i don't care what the CG does

<Ms2ger> shepazu, so is all this charter nonsense

    chaals: i think there's a question about what the policy should
    be, and as an AC rep Opera has a position on that, but it is a
    question for W3C's administrative setup, not for this working

    paulc: when CGs publish, where do they appear?

    plh: on their website

    paulc: but not in TR space?

    tantek: correct

    paulc: so there are two documents

    tantek: the technical document would be the same
    ... there would be 2 separate URLs
    ... just as anyone could take the w3c document and copy it to

    anne: i'd prefer to publish WD/EDs from the CG

    chaals: do you mean you'd prefer the work to happen in the CG
    ... and this WG to rubberstamp it?

    anne: no
    ... I mean that the ED is the same one as the CG
    ... there's no status to the ED
    ... just a place to comment

    chaals: Administratively, that's not true
    ... there's a question of IPR
    ... the IPR setup of a WG is different from a CG

    anne: Fullscreen is done, so it doesn't matter

    chaals: it matters because it sets precedent

    paulc: it matters in the same way that someone comes into a WG
    ... plumps something down
    ... and it has IPR of someone in the WG
    ... you can't say it doesn't matter

    anne: that was not the question
    ... what about new comments

    paulc: we were talking about the different rules of publishing
    in the WG

    tantek: there were 2 questions
    ... the goal is to be inclusive of feedback, not exclusive
    ... in terms of IPR, i don't think there's anything different
    ... the CSS WG proposed joint WebApps+CSS
    ... i don't think that's a problem for this group
    ... you're ok with joint publication

    chaals: no problem, we're chartered for that
    ... we don't want to do the CSS bits

    tantek: I hope some of that covers the IPR bits

    chaals: to a first order
    ... conclusion: you guys are editing this thing
    ... which we expect to publish soon
    ... and there's a question of do you plan to finish it

    anne: fullscreen is finished

<Ms2ger> Yeah, timeless q+'d me, dunno why

    plh: one different between WG and CG
    ... is that WG moves documents along REC track

    tantek: I believe that's what we committed to by putting it in
    the charter for the two WGs


    chaals: I was going to suggest we do introductions around the
    ... we held off doing that earlier

    krisk: Kris K, Microsoft

    adrianba: Adrian Bateman, Microsoft

    shan: Soonbo Han, LG Electronics

    [Scribe gives up]


<ericu> ericu: Eric Uhrhane, Google

<ojan> ojan: Ojan Vafai, Google

    chaals: we have a spec
    ... it's finished LC
    ... there might be a few outstanding comments
    ... then we're ready to make it final
    ... and maybe start again w/ V2
    ... anne : where are we?

    anne: I think LC is over
    ... there are some comments
    ... i think they're all editorial
    ... and we have a test suite
    ... odinho reminded me this morning
    ... we have one open technical bug
    ... i wontfix'd it
    ... jresche reopened it

    JeffH: apologies for taking so long
    ... i spoke w/ anne a long time ago
    ... face to face

<ArtB> [22]Jeff Hodges CORS LC Comments


    JeffH: i think the spec the way it's architected is technically
    ... but it needs a fair amount of editorial work
    ... what i concentrated on is the security considerations
    section that brad contributed
    ... it was difficult to parse and understand
    ... so i tried to note my thoughts on that
    ... and made concrete suggestions on how to rewrite portions

    chaals: but they're not substantive changes
    ... this would make the spec easier to read

    JeffH: correct

    bradh: a simple CORS request
    ... to most not familiar with the spec
    ... those reading it for the first time
    ... is not very simple
    ... it's based on legacy

    anne: it's simple, because the other is really more complicated

    [ laughter ]

    bradh: i'm not claiming it's hard to use
    ... where the line between hard and simple
    ... seems fairly arbitrary

    anne: simple doesn't have a preflight

    bradh: but why does this have a preflight and why does this not

    sicking: it's not just ones that do CORS

    bradh: it's also non CORS cross-origin

    sicking: it's based on the reality of how web browsers behave

    bradh: i'm wondering if it would be more clear to non browser
    ... to define it as a legacy request

<plh> [23]CORS bugs


    ekr: there's no property of the request
    ... it's just based on what browsers already do

<ekr> I was "Eric Rescorla". handle == "ekr"

    bradh: there's a goal of not adding security footprint
    ... we're just explaining that we're not adding

    anne: we could add some comments/notes

    chaals: it sounds like CORS has a spec
    ... but there needs to be better / clearer explanatory material
    around it
    ... we could put it in the spec
    ... we could have someone write a Primer for CORS
    ... and we could trim the spec down

    bradh: we talked about in WebAppsSec writing down the Primer
    ... the spec is intimidatingly large
    ... lots of browser-eese
    ... but for the average dev
    ... it's incomprehensible

    anne: i don't think they'll actually read it
    ... they'll got to stack overflow
    ... a few have read the spec

    chaals: that's why we're here

    anne: to some extent, that's why we have the Server section
    ... which has helped to some extent
    ... as for "why is this everything the way it is"
    ... most specs don't explain that
    ... the reasons can be very peculiar and very wierd
    ... and it's a lot of work to write that down
    ... for HTML, there's a similar problem
    ... the rationale for the various Quirks is strange
    ... there's a wiki page for Rationale, but it's sparse

    chaals: the reason not to do it
    ... is that you take a spec that's fairly daunting
    ... and then make it even larger
    ... and that doesn't make it better
    ... if WebAppsSpec is volunteering to write a primer
    ... and you have an Editor, i'm not aware we have one in

    bradh: we need to see if we have an editor

    weinig: if anyone tried to understand why everything in the
    HTML5 Parsing spec is
    ... they'd go crazy

    ekr: this provides the correct analytical framework
    ... suppose abarth describes
    ... in W3SP
    ... that you can set the Foo-Bar header in 50% of browsers
    ... and then you have a support request
    ... everytime someone tries to look at security of this problem
    ... it doesn't make sense
    ... i'm not saying we need an explanation for each item

    anne: if it turns out that more headers could be set
    ... we could add them

    bradh: how do you make the decision

    ekr: that's the source of the resistance we're getting
    ... from people like Mark + Tyler
    ... they don't agree with this distinction
    ... it's the claim that we're creating new security problems

    anne: i think their claim is mostly Credentials
    ... not simple-request and preflight
    ... But that we include Credentials and there's a Origin header
    ... and that you open yourself to Confused Deputy

    ekr: the defense that bradh's section offers
    ... is precisely that you could already do that
    ... or "why it's no worse"

    anne: but they disagree with that
    ... because they claim it's not how the web works

    bradh: we need to note that we can't change how the web works
    ... or the whole world

    hober: that's the philosophy of the web platform

    krisk: anne you said the testsuite is done and complete
    ... it seems pretty wide ranging
    ... a bunch of stuff says "use localhost"
    ... seems kind of redundant

    anne: not my problem

    bradh: we have the whole afternoon to work on the test suite
    ... i invite you to come and poke in

    glenn: relating to the use of the Origin header
    ... by a Client HTML5 UA
    ... in Simple
    ... it defines the use / not use
    ... in section 5.1
    ... but i don't see that mentioned in the HTML5 spec
    ... this came up in another forum that's trying to read these
    ... and understand the implications for user agents
    ... that may be based on embedded devices
    ... that may not be based on existing UAs
    ... and may need to have compliance testing

    anne: I think HTML does require it
    ... when it does CORS requests

    glenn: what about the CORS mode of no-cors
    ... because there was no cross-origin attribute

    abarth: in that case, there's no requirement to send it
    ... but no prohibition

    glenn: that's ambiguous

    abarth: whenever you send an http request, there's no

    anne: if the server responds with ACL Allow
    ... then HTML allows it whether or not the Origin was included
    in the request
    ... it's only supposed to be if the Origin is in the request

    abarth: that's not the case when you have caching.

<chaals> scribe: chaals

    glenn: the scenario i am trying to figure out is [scribe missed
    ... is it just a general ambiguity, or a spec issue.

    adam: fetch a x-origin video without origin attribute. then we
    want to drawit onto canvas. Does this tain the canvas. - is
    that your question?

    glenn: Yes. I am also worried about compliance testing for

    adamb: If it isn't cors-fetch it doesn't say

    anne: all fetches are cors-enabled effectively

    adam: you have to implement cors to make HTML5 compliant

    glenn: But HTML doesn't say that

    anne: Hixie doesn't want t require cors for html

    glenn: SO I would have to require impleneting cors and sending
    the origin header myself in a separate profile

    anne: yeah. There is a bug on this.

    adam: There is an IETF spec that defines the origin header, if
    you do implement it.

    ArtB: what is the expectation of the outstanding cors bugs

    anne: think Adam was going to write on caches, defining headers
    depends on xxx being done, bug 14700 is fixed, 16203 is a bug
    on the wrong product.

<Hixie> it's not that i don't want to require cors

<Hixie> it's that we don't even require HTTP

    anne: should discuss 15312.
    ... We have a header called access control headers the UA
    generates and send in preflight saying what headers they want
    to use.

<glenn> see
    [24]https://www.w3.org/Bugs/Public/show_bug.cgi?id=16841 and
    [25]https://www.w3.org/Bugs/Public/show_bug.cgi?id=16574 re:
    origin header

      [24] https://www.w3.org/Bugs/Public/show_bug.cgi?id=16841
      [25] https://www.w3.org/Bugs/Public/show_bug.cgi?id=16574

    anne: cors makes requirements on how these are formatted.
    ... We require them to be lower case and require
    lexicographical order. It isn't a big implementation burden.

    adam: What is julian's complaint?

    anne: HTTP library implemented at the same level and being
    case-insensitive can create confusion. But if you implement
    this in PHP you can easily handle this change from one to the
    other. I don't think we should fix the bug.

    Tony: prefer the way the spec has it now.

    adam: section could require a case-insensitive comparison.

    anne: we do, but can't rely on them

    ekr: sure

    ArtB: So we there are no blocking comments?

    jeff: without some serious work the result of publishing ] a
    complicated spec will be to cause problems.

    anne: we have what we got, and hadn't been reviewed until now.

    chaals: Would prefer to have a split of primer and spec, but I
    am not volunteering to edit

    brad: happy to incorporate jeff's comments.
    ... think it is important to fix those things.
    ... would be good to undertake that work as a specific audience
    spec, if we can find resources.

    jeff: That's why I proposed text...
    ... Brad is volunteering to make the security considerations
    work *in the existing spec*.
    ... There is the other task, of explaining CORS to a wider
    audience who need that.
    ... No known editor is available at this time.

    ArtB: After Brad reflects Jeff's comments, we can go to CR?

    anne: I think so.

<Zakim> timeless, you wanted to ask if the FAQ should really be
    in the spec instead of in a wiki

    Josh: I will send some editorial comments

    timeless: FAQs should be updated live.

    anne: right. That's fine to separate out.

    timeless: think it should be moved out, to a wiki.

    anne: sure. File an editorial bug on the spec.
    ... ditto for use cases.

    chaals: so we need some editorial work, and it can go to CR.
    Who is test facilitator?


      [26] http://w3c-test.org/webappsec/tests/cors/submitted/

    odin: Me. We will be working on that this afternoon in


      [27] http://w3c-test.org/webappsec/tests/cors/submitted/opera/js/


      [28] http://w3c-test.org/webapps/CORS/tests/submissions/Microsoft/

<timeless> scribe: Josh_Soref

<timeless> scribenick: timeless


    chaals: travis + anne, explain it as tersely as you risk
    ... it holds us back from Break

    travis: we've been making steady progress on DOM 3 Events
    ... the goal as i wrote in a mail several months ago
    ... was to take what was there and align it with what's in the
    DOM 4 section
    ... making the DOM 3 section a basis for the DOM 4 spec
    ... we're largely there
    ... only two active bugs remaining
    ... maybe one or zero in the next week
    ... and then we start a LCWD
    ... and then immediately move to CR
    ... after speaking w/ anne, i think we're in good shape to make
    those goals
    ... that's D3E
    ... any questions?
    ... if you haven't read the spec in a while, go back and
    re-read it
    ... there's another spec, currently called "DOM 4 Events" ?
    ... jrossi authored
    ... it contains the next generation of Events
    ... the next Keyboard/Audio
    ... i'm not sure what's in there
    ... we'd like to formally adopt that into the WebApps WG as a
    ... and figure out how we rationalize that w/ DOM 4
    ... the new spec wouldn't cover the Dispatch Model
    ... just define specific events
    ... similar to Progress Events

    anne: I'd suggest calling it UI Events

    weinig: UI Events implies accessibility
    ... the Accessibility people had a UI Events spec

    shepazu: let's not talk about that

    travis: I believe the spec falls into the group's charter

<Ms2ger> Again? :)

    ArtB: is jrossi willing to take the lead?

    travis: I believe he is

<Ms2ger> Leading more than D3E?

    [ Bike shedding about name ]

    travis: that's all i have

    [ Break ]

    [ Back at 10:50 ]

Specs severed from HTML

    chaals: Hixie does technical work on them
    ... and then someone takes that and walks them through the
    process hoops

    ArtB: right now we have 5 specs in progress

Server Sent Events

    ArtB: Server Sent Events just started LC 5 days ago
    ... we talked about it briefly yesterday
    ... the comment deadline is in a few weeks
    ... there's an ACTION that chaals + odinho agreed to for tests


    UNKNOWN_SPEAKER: CR published Yesterday
    ... we noted yesterday that this has the broadest deployment of
    ... but no tests
    ... I sent a call for tests, yesterday
    ... do any of you browser vendors have tests for Post

    adrianba: I think we had some Post Message tests as part of the
    HTML5 WG

    krisk: they might be in CVS there

    ArtB: what's the probability they were using Test Harness?

    krisk: it was pre-Test Harness

    ArtB: could you guys be a Test Facilitator?

    krisk: maybe, there's another person on the team who could
    potentially help

    ArtB: I could follow up with you?

    krisk: Alex

    ArtB: anything else on Messaging?

Web Sockets

    ArtB: we have krisk as the Test Facilitator
    ... maybe krisk can give a brief update

    krisk: sure
    ... anne was talking about yesterday relating to surrogate
    ... there is tests for it
    ... multiple browsers pass
    ... Firefox, IE, Chrome, maybe even Opera
    ... there's a bug
    ... and a proposal to put in replacements

    anne: the unicode replacement character

<anne> [29]https://www.w3.org/Bugs/Public/show_bug.cgi?id=16157

      [29] https://www.w3.org/Bugs/Public/show_bug.cgi?id=16157

    anne: the reason is to get consistency in the platform ... with

<MikeSmith> I don't fined any postmsg tests in the
    [30]http://dev.w3.org/cvsweb/html5/tests/ tree

      [30] http://dev.w3.org/cvsweb/html5/tests/


    ArtB: is that the only bug in the list that you guys consider

    anne: ArrayBuffer / ArrayBufferView is critical too

    chaals: 16708

    anne: 15210
    ... 16703 maybe

    ArtB: so 4/5 of the bugs

<MikeSmith> hober, thanks

    ArtB: is there broad agreement to fix them, and go back to LC?

    [ No, not broad agreement ]

    anne: sicking and Opera agree that it'd be good to change
    isolated surrogates

    sicking: i'm of the opinion to convert to the replacement

    adrianba: what about to the receive side

    anne: how can you receive it

    adrianba: if there's isolated surrogates going from service to

    sicking: you can have malformed UTF8

    anne: that's not UTF8

    sicking: what should happen if that byte sequence is sent from
    server to client

    anne: it depends on what type of decoder you have
    ... which would probably decode to replacement
    ... characters

    sicking: i think different apis would do different things

    anne: sounds like a bug

    sicking: i think we should use replacement there too

    anne: i don't know about that

    adrianba: the spec says to disconnect
    ... and that's what implementations do

    Josh_Soref: and this is tested?

    adrianba: i believe so

    sicking: i believe we should do the same with HTML
    ... and do replacement
    ... there's a question of how many replacement characters

    anne: that's getting defined now
    ... the Encoding document will define it
    ... so the protocol says to disconnect?

    adrianba: yes

    anne: seems like a bug

    adrianba: my proposal is that since we have interop on this now
    ... we could think about loosening this in the future

    anne: what we're talking about here is 16-bit code unit to
    utf-8 conversion
    ... the server could use exactly the same algorithm and never
    yield isolated surrogates
    ... that could only happen if you use a really weird encoder

    adrianba: i'd argue it's the same
    ... people build web sockets
    ... expecting the data is valid
    ... or it doesn't work

    anne: the thing you're talking about
    ... that the server might send from the server to the client
    ... you could never generate it from the client to the server

    adrianba: people working on web sockets
    ... have an expectation of strict error checking
    ... i think if you're going to change that, you should change

    anne: there's a different check for the server and the wire

    sicking: aren't we suggesting to change both?

    anne: yes

    sicking: we should never have malformed utf-8 cause disconnect
    ... we should transparently convert

    adrianba: i'm saying today implementations don't do that

    sicking: i guess i could live with keeping interop in the
    current version
    ... and changing for v2

    anne: how does that work?
    ... maintain a fork of the spec?

    sicking: we've changed implementations in the past
    ... from throwing to not throwing

    anne: do we delay fixing our implementations?

    sicking: as soon as there's a v2 spec, we can point to it and

    anne: it's not the only change

    chaals: ArtB, you are the editor of that spec
    ... who is going to make it a REC
    ... Hixie did the technical work
    ... but in order to make a stable REC, you're the editor
    ... do you see it is worth continuing the argument
    ... or can you, like sicking, live with sending it out and do a

    ArtB: i don't have a firm opinion
    ... on the one hand, we can see who cares
    ... and additional changes
    ... and stop the REC
    ... can we get a show of hands
    ... we get a show of hands?
    ... who thinks we should go ahead
    ... who thinks we should block?

    chaals: Microsoft Guys
    ... in favor of moving on
    ... Opera, hober, Cox in favor of blocking
    ... sicking has a fence post

    sicking: i have a weak preference for changing
    ... but i can't speak for Mozilla

    chaals: doesn't sound like consensus
    ... (pualc's question) who can not live with blocking on this
    ... (pualc's question) who can not live with what we have and
    versioning out?
    ... who is surprised by that result?
    ... w3c process says we should seek consensus
    ... WG resolution is we will block on this issue
    ... so, that gets you off the hook of preparing a TR req

    ArtB: so how do we get the fixes we consider mandatory?
    ... how do we get Hixie to make these changes?

    chaals: given we're forking from Hixie
    ... an editor, as opposed to an author can edit them in
    ... those who have blocked
    ... have an onus to put up the changes
    ... blocking for a future world is not a useful exercise
    ... i suggest if we don't get an explanation of getting the
    changes in a reasonable amount of time
    ... we'll look back less kindly the next time
    ... it makes sense as a change, but doesn't make sense to hold
    the universe forever

<Ms2ger> I object to a fork that contradicts the WHATWG version
    on technical points

    chaals: please make sure you get back

    anne: i think we should just ask Hixie to make the changes

    [ We count 4, not 5 bugs ]

    chaals: anyone want to pick one of the three?

    anne: if you tell Hixie that it's an implementer priority, then
    he fixes them
    ... 16708 is another consistency thing
    ... XHR and Blob have done
    ... the others, i don't know

<timelses> adrianba: we won't be making those changes anytime

    anne: it's too late for IE10
    ... you don't do WebGL
    ... but you have ArrayBuffer?

    adrianba: we have ArrayBuffer
    ... it's not like it's a tiny incremental change to do WebGL

    anne: are you guys participating in Kronus?

    adrianba: no

<plh> s/Kronus/Khronos/

    ArtB: Web Storage

<anne> s/Kronus/Khronos/


    s/ArtB: Web Storage/Topic: Web Storage/

    ArtB: Ms2ger went through this
    ... what's going to block

    krisk: some of the results are wrong
    ... i can't tell who ran them

    plh: you can click on a test to see which UA string ran it

    krisk: we should have the vendors run them

<Ms2ger> I ran the Web Storage tests

    sicking: is there a way i can run these tests right now?

    plh: possibly

<Ms2ger> There are wrong results where the test changed

<Ms2ger> sicking,

      [31] http://w3c-test.org/framework/suite/web-storage-dev/

    sicking: ... on nightly

    [ sicking is looking at Constructor ]

    ArtB: so, storage is our first candidate

    krisk: if we want to implementations pass for Event
    ... i don't think we have two vendors

    anne: doesn't WebKit have them?

<sicking> Ms2ger: file bugs and attach patches and i'll review

    weinig: we have them
    ... if Ms2ger is testing lexical lookup

<Ms2ger> sicking, I've had mayhemer review them

    weinig: we may have some minor things

<sicking> cool

    weinig: i know i didn't do the arguments in alphabetical order
    ... gotta do that
    ... for dictionaries
    ... the are lots of small edge cases
    ... that are part of event constructors
    ... it's good that there are tests
    ... but it seems likely there will be minor bugs
    ... especially spreading out across two specs

<Ms2ger> plh, doesn't work, plinss wontfixed the bug

    krisk: it sounds like some people may pass some of the tests
    ... but we're not really sure

    chaals: the blocker seems to be event constructors
    ... we don't have agreement on the test suite yet

    ArtB: anything else on Storage?

Web Workers

    ArtB: ... another CR just published yesterday
    ... we mentioned we don't have a test facilitator

<plh> ms2ger, do you mind if I clear the tests results?

    ArtB: someone from microsoft did

<Ms2ger> plh, not at all

    ArtB: we might have some, but none for shared-workers

    krisk: yes, alex,

    ArtB: anyone volunteering?
    ... i guess an action item for me to look for someone

<MikeSmith> this room is cold

<MikeSmith> we need a fireplace here

<Ms2ger> sicking, fwiw, bug 740357 is currently blocking me
    from further bugfixes (along with tree closures...)

Index DB

    chaals: We got a charter comment asking for a JS api for SQL
    ... we replied that IndexedDB is the result

    s/Index DB/IndexDB/

    sicking: looking at this list, there is one normative change

<Ms2ger> s/IndexDB/IndexedDB/

    sicking: 16714
    ... that aligns the spec with what everyone has done
    ... i'm editing that into the spec now
    ... 14404
    ... hopefully everyone agrees
    ... but i'd like to clarify on the list that everyone agrees
    ... hopefully everyone agrees it's editorial
    ... We have a problem with ReSpec
    ... which removed a significant chunk of the spec

    chaals: and you claim this is an issue

<Ms2ger> Solution: dump ReSpec

    sicking: this needs to be fixed before we can publish

    chaals: is that editorial?

    sicking: it is
    ... it's preventing us from going to LC

    chaals: beyond you needing to fix it
    ... is it a real problem?

    sicking: no
    ... if we can get those two things changed today, we can
    publish LC
    ... any questions?

    ArtB: last day to publish is May 8, with a CfC, that's
    ... we can get it published this month

    sicking: we have 3 implementations at this point
    ... with a fourth in progress
    ... you've given a fair number of comments

    hober: read through everything
    ... but when we send new comments
    ... it's because we got to a new point

    sicking: the people i'm expecting comments from is Opera

    hober: so far it's things that aren't really defined
    ... and nitpicking, making things easier to read

    chaals: so, LC in Q2, mid may
    ... do you have a test facilitator?

    [ crickets ]

    krisk: Alex Kuang can do it

    ArtB: i'll wait for sicking's green light to start CfC

    jsbell: Joshua Bell, Google

Feature Detection

    adrianba: there are two parts
    ... 1: Dev Education
    ... we're using the resources we have, and I know Opera is
    ... 2: Reviewing features we're adding to specs
    ... for example, Binary Data for Web Sockets
    ... because of the way implementations did other features, it
    was hard to tell if it would work

    chaals: what happened to the API Cookbook plan?
    ... at the extreme end, we could bake them into the Process for
    the group
    ... do we want to go that far
    ... and note it for the next time that we've been here before

    adrianba: yes
    ... it's really expensive when people build sites using browser


    scribe: we spend a lot of money telling people
    ... that assuming you have Feature A means you have Feature B
    ... if we add just Feature B, that causes problems

    chaals: we could block at LC on a requirement to recognize that
    a feature exists

    adrianba: for now, blocking at LC should be ok

    anne: kind of uncomfortable with a blanket requirement

    weinig: there's an issue with browsers that don't implement
    properties on prototypes

    sicking: there's an issue with Dictionaries
    ... if in v2 you specify locale collation as an additional
    parameter in a Dictionary

    anne: it isn't exposed in another way?
    ... you could test it, right?

    sicking: sure, you could, but it's a large chunk
    ... large enough that authors are likely to not do it

<Ms2ger> Modernizr!

    sicking: a lot of the time we do design for this
    ... but sometimes we don't
    ... for collation, we could expose the property
    ... which would enable it to be detected

    anne: is that a problem if it isn't supported?

    weinig: what's the workaround if you don't have it?
    ... you'd do the sorting yourself?
    ... so you'd have two code paths?

    sicking: or you could use munged sortable strings

    weinig: that wouldn't be the locale of the computer

    sicking: no, just a specific locale

    weinig: it seems like dictionaries pose a little problem
    ... but not a huge one

    sicking: one thing developers have asked for is to see if a
    given event is supported from a given element
    ... not all events have an onfoo property
    ... so you can't detect it that way
    ... so the only way to detect it is to sit around and wait for
    the user to start typing

    anne: IME events probably have an interface you can detect

    weinig: it's probably a good strategy to ensure there's a clean
    update path

    rniwa: how do you handle the case where a browse in v.N
    implements API, and it's broken
    ... and they fix it in v.N+1

    sicking: i think the best solution is to have tests earlier

    shepazu: testing is the solution

    chaals: testing minimizes the occurrence of that anyway
    ... but bugs happen
    ... alternatively, if you know of a specific broken
    ... sniff for the particular browser on the particular device
    ... Ice Wind 7 on Android phone
    ... I know thing X is broken
    ... if you claim to be it, we'll do something else with you
    ... there's the other version of sniffing
    ... where you assume that Browser X will never have that
    ... we need to take that site out back and shoot it
    ... the goal is to minimize useragent detection
    ... some significant portion will be done by idiots
    ... and will be done badly
    ... do we need a formal resolution?
    ... my proposed resolution is LUNCH

<paul_irish> regardless of how early testing is introduced,
    developers cannot embed a portion of the conformance testing
    suite into their apps. we need a published technique to feature
    detect localStorage, geolocation, etc etc.

    weinig: a proposed resolution is to be more careful to make it
    easy to feature detect

    chaals: my proposed resolution is Don't do That
    ... We recognize it is a problem for specs
    ... if you can't feature detect reliably
    ... and leave it at that

    adrianba: i'll liase with darobin to make sure it's in his

<adrianba> ACTION: adrianba to liaise with Robin to ensure
    feature detection is part of his API design document [recorded

<trackbot> Created ACTION-661 - Liaise with Robin to ensure
    feature detection is part of his API design document [on Adrian
    Bateman - due 2012-05-09].

    [ Lunch - resume at 1:15 ]

<Ms2ger> paul_irish, the point was to prevent poisoning feature
    detection like Google does with input type=chrome, say

<tantek> paul_irish, speaking of being "on the site", does
    Google have a wiki.google.com equivalent to wiki.mozilla.org?

<Ms2ger> chaals, oh, I thought that was wiki.opera.com ;)

<chaals> s/chaals, oh, I thought that was wiki.opera.com//

Stabilizing Specifications

    [ chaals explains tradeoffs between publishing early or never
    finally publishing

    chaals: I, as a chair, want to get stuff to REC
    ... I, as a AC rep, want to get good specs knowing where we
    want to go
    ... so, Opera can't give too much resources

    anne: the main thing gating getting to REC quickly
    ... is requiring two implementations of everything and an
    exhaustive test suite
    ... so we know what the substantive issues are, and address
    ... and then we publish REC
    ... we still need to work out test suite + interop
    ... we could/should probably do LC every year/two years
    ... no major issues, publish snapshot
    ... the current process document requires a CR
    ... two interoperable is a group Req
    ... we could try to get creative

<MikeSmith> +1 to anne's "Rec snapshot" proposal

    ArtB: the w3 PP

    tantek: So, the Opera sees more value in evolving the spec
    ... how much value do you see in the IPR values from REC

    chaals: as an Opera position, we see value in the IPR thing
    ... how much value is there in getting something out
    ... of something getting into court in the intervening space
    ... if a REC never happens, then it's different
    ... Opera also delivers browsers to companies according to
    ... if we deliver a statement of work saying "we'll deliver up
    to the latest at the delivery date"
    ... marketing and business can't accept an unspecified amount
    of work at a fixed cost
    ... we would like to see how important it is to other people
    ... one measure is, who is going to put up the work

    tantek: if the REC is eventually going to come, that's semi
    equivalent for IPR
    ... re: anne 's comment about skipping implementation and
    calling it a REC
    ... i disagree with that
    ... and think that's one thing that lended a loss of trust in
    W3C RECs
    ... e.g. no browser implemented it, but it's a REC
    ... i'm opposed to something going to REC without interoperable
    Browser implementations
    ... otherwise, leave it in CR
    ... forever

    anne: that doesn't address getting REC, so it doesn't work

    tantek: chaals said it doesn't matter to Opera
    ... per se

    plh: what's the goal of this discussion?
    ... to provide input to AC?

    chaals: no, it's to manage tension between
    ... getting to REC
    ... moving forward with new feature


    scribe: how do we manage the obligation with getting stability
    ... because at the moment, i don't think we do an especially
    good job
    ... getting to REC

    plh: it's perfectly fine to go back to AC and say "given the
    current process, we can't do this"
    ... but we're bounded by the current process


    scribe: it's useful feedback to provide

    plh: it says that "The WG SHOULD be able to provide 2 working
    interoperable implementations of each feature"
    ... it's a SHOULD, because some specifications don't have
    ... like Guideliness


<ArtB> [33]Process Document and Candidate Recommendation

      [33] http://www.w3.org/Consortium/Process-20010719/tr.html#RecsCR

    tantek: isn't that what NOTEs are for?

<ojan> I've said this in person to many of you before, but I
    think we should do something very different from current
    practice. We should always be working on an unversioned "trunk"
    copy of the spec. Every *feature* in the spec is marked one of:
    stable, implementable, unstable. Every X months (e.g. 6 months)
    we fork the spec into three auto-generated copies. 1. The full
    spec, useful for people to bring

<ojan> up IPR issues. 2. A copy of the spec with the unstable
    features stripped. (roughly equivalent to CR, browser vendors
    can implement these features unprefixed) 3. A copy with the
    unstable and implementable features stripped (roughly REC once
    there are 2 implementations + a test suite).

    anne: once you create test suites, you start finding details

    sicking: the main value of having something called a REC
    ... is there are a lot of authors that care about it
    ... that pay attention to things
    ... even if we claim we have interoperable implementations
    ... they're worried because we don't have RECs
    ... the current process is fairly bad
    ... that's why i'm pushing to get more things into REC
    ... so we can point to them
    ... this is a lot harder if authors want market share for those
    implementations as well
    ... the goal for most people in here is to get authors to use
    those specifications
    ... there is an incentive to make REC

<ArtB> [[

<ArtB> The Working Group is not required to show that a
    technical report has two independent and interoperable
    implementations as part of a request to advance to Candidate
    Recommendation. However, the Working Group is encouraged to
    include a report of present and expected implementation as part
    of the request.

<ArtB> ]]

    glenn: is that the thing about CR

    chaals: there's a thing in the process document

    shepazu: tantek raised a point around the value of
    ... there's an expectation that it's interoperable in browsers
    ... jQuery has just joined W3C
    ... would people consider a jQuery implementation of a
    specification as a pragmatic point for interop on our test
    ... i think it does, i'd like to hear from people who think it

<ArtB> [[

    anne: it seems like a bad idea

    glenn: Cox is hear because we want to see interoperable systems
    ... both on the authoring side and on the UA client side
    ... we're investing in W3C membership and time for me and
    ... on the assumption we'll get some value out of that
    ... the value is Final REC and test suites
    ... the process of getting there is long and complicated
    ... we'd like to see it go faster wherever possible
    ... we'd like to volunteer our time, my time

<Ms2ger> Explain why "the value is Final REC"

    glenn: a process which doesn't get us REC + test suites isn't
    worth our time
    ... we do have the ability to define how to get there

<anne> Ms2ger: something with a p

    glenn: but there should be something there

<Zakim> chaals, you wanted to note that guidelines often *do*
    get implementations through the process.

    glenn: improving the output in terms of timeliness and test

    chaals: even guidelines when they go to REC
    ... get implementation

<Ms2ger> (Also, has Cox contributed tests?)

    chaals: trying to get a guideline to REC before Team

<anne> shepazu: the reason jQuery is a bad idea is because you
    can't actually use the specification directly, you'd also need
    to include a library, and given the state of the DOM and
    JavaScript, you probably cannot use the API directly even when
    you go to the length of including said library

    chaals: was given pushback to show that the guideline was
    picked up
    ... demonstrating that people understand how this worked
    ... what we want in a REC is things we don't think are going to
    change much
    ... people writing contracts based on long term things
    ... don't want to discover that in six month's time things have
    changed under them
    ... suck out the stable bits

<glenn> cox has not yet contributed tests, but is prepared to
    accept a shared responsibility in doing so

    chaals: and keep on working the things that aren't stable
    ... we can identify the things that aren't stable
    ... - today
    ... we mark things as TBD
    ... if i take what glenn says, that we want a test suite

<shepazu> anne, fair point, but on the other hand, JQuery works
    across all major browsers, while each browser only works across
    one browser (unless it's WebKit ^_^)

    chaals: it doesn't have to test every tiny detail
    ... we want to know which things are interoperable
    ... if you look at HTML5 as a pile
    ... the spec defines this big mountain
    ... but the implementation status is things not in the spec yet
    ... things in the spec that you can't use anywhere
    ... and a smaller section you can rely on anywhere forever
    ... the <p> will keep on being a <p> for longer than we live

<anne> shepazu: independently implemented features help proving
    a standard is actually well written though

    chaals: you're not going to worry <p> into your web page
    ... some things shaking around, some people might not go there
    ... some people will put it (prefixed things) into my
    production system, because that's the way we do things
    ... stabilizing and saying these things in the edge cases
    aren't stable
    ... seems reasonable
    ... our process seems to be to stabilize every edge case

<shepazu> anne, yes, but I'm not saying that jQuery should be
    the only implementation, just that it should be one of them,
    just as a single browser is one of them

    chaals: and whenever we find an edge case, and deciding we have
    to go back and work on the spec
    ... before everything else

<Ms2ger> anne, or that the QA teams of the respective browsers
    are good enough at reverse engineering

    chaals: we do want to define everything else
    ... where the test suite is less comprehensive
    ... "we ship browsers which are perfect"
    ... at that level, the spec is the same

<Zakim> tantek, you wanted to say that CR satisfies the desire
    for stability for implementers/authors

<anne> Ms2ger: maha

    tantek: i agree with sicking 's point that authors feel like
    they can depend on
    ... i don't think that incentive pushes toward CR
    ... i've found as an educator
    ... someone who does workshops on HTML5
    ... when specs reach CR, authors tend to just depend on them

    anne: CR doesn't work for people who want to reference us

    tantek: i have experience with fulfilling the letter and spirit
    of CR
    ... in CSS2.1
    ... going back, i don't think anyone would want to go back and
    do that level of diligence ever again
    ... the edge cases we were having failures on
    ... we shouldn't have spent years going back and forth

    anne: most of those problems will bite you back

<Ms2ger> tantek, I agree, *that* level of diligence is

    tantek: in practice, we left things undefined
    ... in CSS2.1
    ... i've yet to hear anyone say these things have hurt anyone
    ... i think that's a group wisdom item

<anne> edge cases bite browsers all the time

    plh: i've been in this kind of discussion for 15 years

<anne> and table layout is definitely one of them

    plh: it was the DOM WG that recommended CR phase
    ... DOM1 and DOM2 and DOM3 were produced without much of a
    testsuite either
    ... but there are consequences of doing that
    ... when people talk about a testsuite, there's a lot of
    variation about what they mean by that

<Ms2ger> DOM1 and 2 definitely have test suites

    plh: we want a full test suite

<Ms2ger> We run them on every build

    plh: and we want to spend years writing it
    ... we shipped CSS2.1 with 9,000 tests

<chaals> [/me wonders if it makes a difference whether there is
    an expectation of ongoing work or not...]

    plh: and there are plenty of things that aren't tested,
    especially when you put HTML in the middle

<tantek> anne, do you know of any specific table layout issues
    re: CSS 2.1 that have actually effected authors and/or
    browsers? (citation requested to specific issue)

<tantek> (before CSS2.1 yes - plenty of table layout problems)

<Ms2ger> tantek, seriously?

    plh: at W3C, we're discussing hiring people on Staff to spend
    their entire time on Testing

<tantek> Ms2ger - remember, I said *CSS* table layout

<anne> not having shrink-wrap and such defined is also a major
    problem for new CSS specs

<tantek> not touching HTML legacy table layout

<tantek> that's a much harder problem

<anne> ask e.g. tab

    krisk: i definitely don't want to go back to a model where we
    don't have test suites

<anne> this is about HTML legacy table layout

    krisk: i think that leaves us with ambiguity

<anne> that's what CSS ought to define

    krisk: i think some people like to make test cases on every
    edge case

<anne> as HTML is defined in terms of CSS

<tantek> anne, I'm content with Flexbox's approach to solving
    shrinkwrap etc.

    krisk: and i don't think that helps
    ... i think in WebApps, i think we're on the lean side
    ... Web Messaging is holding the spec up for Event Constructors
    ... i think there's a lot of value in Web Storage interop

<chaals> [/me also still looking for where to get the resources
    to make Recs while technical editors are working on technical
    questions that are still unsolved]

    krisk: but looking at the test suite
    ... there's definitely a level base on pruning tests

    rniwa: keeping trunk spec
    ... and forking for stabilization

<tantek> I don't know of any authors that care about detailed
    description of HTML table layout - so I say it is something we
    can punt on (deprioritize)

<Ms2ger> Note that Web Messaging isn't holding the spec up for
    Event Constructors, but because of the nullable types change to

    rniwa: i think it's ok to
    ... i don't think we can wait for the test suite for every
    ... eventually it'd be nice to test every edge case

<Ms2ger> In particular, an error that was introduced in the

    rniwa: but forking for standardization

<anne> tantek: this is not just about authors, it's about the
    health of the web platform and ease of entry for new players

<tantek> there is much more useful/important things to work on
    in CSS than define legacy HTML table layout - ergo, it will
    likely never get done should never get done because there
    aren't infinite resources in CSS.

<anne> tantek: and about not wasting QA resources * five

    rniwa: we need to agree to put the other test cases in later

<Ms2ger> tantek, [citation needed]

    bryan: any thoughts on the coremob CG
    ... taking pressure off?

<tantek> anne - I sympathize with the ease of entry for new
    players - though it feels like that gets harder every year even
    just for well defined things, nevermind compat.

<tantek> ms2ger w3.org/Style/CSS

    bryan: when we did CoreMob inside WAC

<tantek> see the list of specs there

    bryan: which covered on web standards

<tantek> and priorities

    bryan: HTML and things around it

<chaals> [tantek, IIRC we were using table layout for some
    stuff internally and it caused problems - but should we
    therefore stop CSS going forward, or get them to produce level
    X and keep working to solve that in level X+Y?]

<anne> tantek: it's not made simpler by giving up on defining
    essential parts of the platform

    bryan: things we saw referenced by jQuery
    ... an indication that things were broadly supported
    ... we developed tests to ensure it worked
    ... that was a practical way to us,
    ... to identify what worked
    ... without getting in the way of the platform vendors
    ... when things show up in the platform, we added them to the
    common supported set

<tantek> chaals - anyone (or org) that sees legacy HTML table
    layout as essential for being defined can propose such a
    module. no one in the current CSSWG does, otherwise they would

    bryan: does that help take the pressure off?
    ... or does it solve something eles?

<Zakim> bryan, you wanted to ask if the idea behind the core
    mobile web platform CG (identify the interoperable core and
    shells of interoperable features around it) is a practically

    bryan: or nothing

<tantek> or rather, other things are more important

<tantek> by evidence that other things have been prioritized

    sicking: i agree it's silly to hold Local Storage for Event
    ... we should aim for maximum interop

<Ms2ger> tantek, Mozilla and Opera certainly do

<chaals> [tantek: agree, re "if you want it, do some work".]

    sicking: long term for complete

<Ms2ger> tantek, but it's a very hard problem

    sicking: taking tests that we all agree are non criticl
    ... and moving them somewhere


<tantek> chaals, right, there is no structural barrier, in
    fact, the opposite, there is encouragement / welcoming of such

    scribe: and then show that we have enough to move forward
    ... dislike the idea of making the spec more ambiguous

<Ms2ger> sicking, that claim about holding Web Storage for
    ctors is a lie, as I mentioned earlier

    scribe: if we move the undecided tests somewhere
    ... and then once we've addressed them

<tantek> Ms2ger, over time, the unreliability of legacy HTML
    table layout means authors don't depend on it, means fewer
    sites (as actually used) depend on it, means it's less
    important for browsers etc.

    scribe: move them back

<anne> tantek: maha, you mean like how things went down when I
    worked on some legacy aspects of the CSSOM?

    scribe: a way to mark tests as non critical

    krisk: in spirit, the submission process did that

    sicking: i don't think anyone disagrees

<Ms2ger> tantek, that's nonsense

    sicking: that Event Constructors are normatively required by
    the spec
    ... they're valid tests
    ... i wouldn't like to mark them as No
    ... i'd prefer to move them to a place
    ... "we would like implementations to pass these"
    ... even to claim 100% compat

<anne> tantek: yeah, agree with Ms2ger, that's some kind of
    fallacy people started believing in at some point, but it's not
    actually reality

    sicking: but "they aren't critical enough to block the spec"
    ... it tends to not be too hard to get implementations to fix
    ... once they're in the right part of the release cycle

<tantek> anne - no amount of process can stop a chair or
    specific individual from being out of order or for that matter,
    going against the said/explicit welcoming culture of a wg. I
    for one am still very upset about how you were treated.

    sicking: and once they have tests

    rniwa: they should be normative?

    sicking: the test suite isn't normative
    ... but moving them to say "we don't require 2 passing
    implementations of this test in order to move to REC"

<anne> tantek: in the worst case you get a split web, where
    some set of sites depend on one behavior and others on another;
    in the slightly less worse case you just all have to reverse
    engineer each other

    chaals: if you want stuff
    ... one measure of you wanting stuff
    ... is doing work on it
    ... i'm encouraged to hear glenn say "Cox wants stable RECs"
    ... i'm not saying glenn should write XHR2 or IndexedDB
    ... is what ArtB 's done for the HTML-handoff specs
    ... take stable things and do the finishing process
    ... test suites is another thing
    ... bryan ran away after asking about coremob
    ... i'm quite disappointed about coremob
    ... the principal of looking at what devs care about
    ... and getting stability for that

<Ms2ger> s/principal/principle/

    chaals: if jQuery is shipping it to general developers
    ... then it's probably stable
    ... and the group should try to push that bit to REC
    ... the old model of W3C
    ... was a group would sit down, write a spec, then they'd
    ... for HTML, CSS, SVG, the theory was a bit wooley
    ... the PP was based on that theory
    ... people certainly thought that
    ... if you know people are going to fix edge cases, solve pain
    points, add feature creep
    ... then maybe you know you'll have another version
    ... with more stuff, more bugs, but some old bugs fixed
    ... i'll repeat the question
    ... where do we get the resources of "do the finishing, do the

<Zakim> tantek, you wanted to mention optional/required
    features vs. one or more implementations.

    chaals: people who care about it, measure how much they care by
    how much effort they put up to make it happen

    tantek: sicking mentioned 2-impls and saying that maybe we can
    say 1 impl of an optional feature is sufficient

    shepazu: i'm not a fan of optional features

    tantek: it's a way to make progress

    sicking: we should be strict about what we're not blocking on
    ... in prose people tend to make things easy to get wrong
    ... we should be ok with being off by 2px in CSS
    ... we should be more conservative than jQuery depends on it

    anne: if you do that, we won't get RECs faster

    sicking: Local Storage we could be done

    anne: XHR wouldn't

    sicking: i'm fine with moving the spec where people are failing
    the test

    glenn: on testing

<smaug_> (what is an optional feature o_O)

    glenn: i think it's useful to recognize that the audience for
    the test
    ... is the w3c process
    ... it's only technically for w3c exit requirements
    ... it isn't for establishing compliance
    ... or interop
    ... that isn't its express purpose
    ... it's just to satisfy the process requirement
    ... i can see our scope and target changing over time

<chaals> [There are tradeoffs. By leaving stuff undefined we
    allow legacy complexity to creep in - but we do that by not
    stabilising the spec too, because people just implement against
    "what works". I think it is a judgement issue in the end, so I
    am hoping to get a bit more shared understanding and guidance
    on how to make that call]

    glenn: tests aren't part of the technical deliverables per the
    ... they aren't cast in concrete like a REC
    ... they can change at any time
    ... they can start small and gro


<chaals> shepazu: I think the expectations of the group are
    higher than the process requires, and I think we should be
    driving towards interoperability above the worst possible

<chaals> scribe: chaals

    glenn: We want the bigger picture. Dunno if W3C process is
    ideal - there is no compliance testing for example.

    ArtB: Broad IP commitment is important to Nokia. We're happy to
    look at changes to the process, but we want that to stay. Being
    more selective about test cases for CR makes a lot of sense.
    What's the minimalist/core set - I like that idea and it
    wouldn't stop us adding more test cases to show what still
    needs work and maybe a rev on the spec.
    ... if we apply this to web storage, testing is somewhat
    make-work if everyone has broadly deployed it.
    ... we could just agree that where we have 4 implementations,
    we can make that the core tests

    krisk: agree. The test suite results make it look like web
    storage is unusable, but that isn't reality - people *do* use

    anne: If you look at it from QA because a site is breaking,
    then you see a different picture. Now we have to reverse
    engineer to deal around the lgacy complexity that got allowed
    to creep in.

    krisk: to a certain extent we make the problems for ourselves.
    ... we didn't change the spec to include something nobody will
    implement. There are things that we can punt to v2 but instead
    we slow down by circling where we are.

    shepazu: I think we haven't spent as much time as I would like
    on when we do the testing.
    ... people are implementing early on in the spec process. If we
    want to set tests for stable things early on in development, we
    would have an improved asymptotic approach to interop, that
    would help us in cr as well.
    ... start early, test often.

    sicking: my proposal of moving tests to non-required is to
    avoid habing to build a v2 so soon.
    ... move the tests back in means we can avoid doing double
    versions of specs.

<tantek> [then what's the point of moving the spec forward? if
    not to communicate an expectation of dependability on

    [scribe notes that Anne pointed out again that maintaining two
    versions of a spec has a real cost in complicating the work of
    developing it]

    sicking: to tantek: Very few people are going to use the
    features. They are not optional, they are just less central to
    the core usage - which happens in all specs where some things
    are more important than others.

    tantek: there are two harms I have seen. 1: a new implementor
    gets to a bit that hadn't been done before and discovers that
    you can't implement the spec.
    ... CSS 2 has examples.

    sicking: if CSS2 had a good comprehensive test suite you would
    have moved a large chunk of tests to optional - and then you
    would say "wait, if there are that many optional things maybe
    we don't have the right spec for what matters yet"
    ... nobody doubts event constructors can be implemented. If a
    new implementor comes, they won't get stuck.

    tantek: writing the test often showed that the spec was broken.
    we are improving - but not perfect.

<tantek> ArtB - CSS 2.1 has quite good interop, without a
    certification program ;)

    tantek: 2nd harm. The expectation of someone who reads the spec
    is that it works. If they try it and some things don't work,
    they get disappointed and decide the whole spec is rubbish.


<timeless> rniwa: I like to write tests

<timeless> ... but it's hard for me to figure out which part of
    a spec needs tests

<timeless> ... or has tests

<timeless> ... which part of a spec needs testing

<timeless> ... [Coverage]

<timeless> ... I encourage my colleagues and myself to write

<timeless> ... but i don't have 4 hours to figure out which
    tests test which items

<timeless> ... if i remember correctly, each test has a link to
    the section of the spec

<timeless> ... if we have a tool that could go through the

<timeless> ... the CSS Tool called "Shepard" (by plinns)

<timeless> ... that lets you annotate the CSS spec

<timeless> ... to show you which tests exist for a section

<timeless> ... and to go from the tests to the parts of the

    i/... the CSS/shepazu:

<timeless> plh: In practice, the CSS WG has the highest bar

<timeless> until you put the metadata, they won't accept their

<timeless> s/until/... until/

<anne> I think it would be good if we had an annotation system
    for the specification. If we had that, we could use that to
    annotate tests. Hixie has written such software for the WHATWG.
    I'm sure he's willing to share it and have someone make it
    usable for more than one specification

<timeless> ... this is one of those tradeoffs you have to make

<anne> ^^ is what I'd say if I put myself on the queue

<timeless> ... you saw the w3c test results, it's a modified
    version of Shepard on the w3c server

<tantek_> in case it is helpful:

      [34] http://wiki.csswg.org/test/format

<timeless> ... we're still trying to get upstream changes from

<timeless> ... there are two features that we don't have, that
    he isn't interested in implemented

<timeless> s/implemented/implementing/

<timeless> ... it's written in PHP

<timeless> ... some people donm

<ArtB> [35]A Method for Writing Testable Conformance

      [35] http://www.w3.org/TR/test-methodology/

<timeless> s/donm/don't like php/

<tantek_> in particular, here is the meta data that is
    requested for each test:

<tantek_> <link rel="author" title="NAME_OF_AUTHOR"
    href="mailto:EMAIL OR [36]http://CONTACT_PAGE">

      [36] http://CONTACT_PAGE/

<tantek_> <link rel="help" href="RELEVANT_SPEC_SECTION">

<tantek_> <meta name="flags" content="TOKENS">

<tantek_> <meta name="assert" content="TEST ASSERTION">

<timeless> ... if someone came along w/ a Node.js framework
    based system, we'd take it

<bryan> I've been working on a tool to help spec authors
    identify the distinct testable assertions in their specs. An
    quick/dirty demo version is at

      [37] http://bkaj.net/test/dap/assertions.html.

<timeless> krisk: [=> rniwa ] you could ask the testing list

<timeless> bryan: I've started looking at specs across w3 to
    show how it could be done

<timeless> ... easy ways to navigate from tests to spec

<timeless> ... annotating the spec with metadata

<timeless> ... i talked with darobin about updating ReSpec.js
    to incorporate this

<timeless> ... if you go to the tool

<timeless> ... you can click a spec

<timeless> ... and it pulls out the testable statements

<tantek_> as an spec editor, my first reaction is, this is too
    much work

<timeless> ... one by one

<tantek_> *a

<timeless> ... at the top is the list of testable assertions

<timeless> ... it's useful for structuring tests

<timeless> plh: it's pretty limiting

<timeless> ... some things may not have a MUST

<timeless> bryan: in order to test things

<timeless> ... you need to be rigorous in terms of how you
    describe them

<timeless> ... if it's difficult to pull them out

<timeless> ... i don't think that's easy for the people to
    write the tests

<timeless> ... maybe people need clearer statements to decide
    what to test

<ArtB> ACTION: barstow make sure all of WebApps' new Editors
    are at least aware of
    [38]http://www.w3.org/TR/test-methodology/ recorded in

      [38] http://www.w3.org/TR/test-methodology/

<trackbot> Created ACTION-662 - Make sure all of WebApps' new
    Editors are at least aware of
    [40]http://www.w3.org/TR/test-methodology/ on Arthur Barstow -
    due 2012-05-09].

      [40] http://www.w3.org/TR/test-methodology/

<timeless> rniwa: I agree with your statement

<timeless> ... if we have thousands of tests

<timeless> ... it's had for me to figure out

<timeless> ... at some point it doesn't scale well

<ArtB> ACTION: bryan seriously consider using
    [41]http://www.w3.org/TR/test-methodology/ in Push Events spec
    [recorded in

      [41] http://www.w3.org/TR/test-methodology/

<trackbot> Created ACTION-663 - Seriously consider using
    [43]http://www.w3.org/TR/test-methodology/ in Push Events spec
    [on Bryan Sullivan - due 2012-05-09].

      [43] http://www.w3.org/TR/test-methodology/

<timeless> ... Ideally, as a test author, i'd just like to go
    to one page

<timeless> ... and have it tell me which part of the test needs

<timeless> ... and which part of the section

<timeless> shepazu: and you're writing something to do this?

<timeless> rniwa: it's hard for me to figure out which part of
    the spec to write for

<timeless> ... as is, i'd have to know all tests

<timeless> ... in WebKit, for regression tests, it's easy

<timeless> ... you just have a testcase, because if you had a
    test, we'd have failed and seen and fixed the bug

<timeless> ... but for conformance tests

<timeless> ... it's unclear

<Zakim> tantek, you wanted to say this spec markup just moves
    the problem from one rare resource (test authors) to an even
    *rarer* resource (spec editors)

<timeless> tantek: i don't think putting the burden of explicit
    markup into the spec is a good idea

<timeless> ... i think from the resource perspective, it's the
    complete wrong idea

<timeless> ... you're moving the burden from test authors to
    spec authors

<timeless> ... and spec authors are a rarer resource

<timeless> ... if anything, you should move it the other way,
    or to machines

<timeless> ... there are ways to write better specs

<timeless> ... writing testable assertions

<timeless> ... but writing markup is a mistake

<timeless> ... it should be possible to interpret specs



<timeless> ... it's what MS did for the HTML4 WG in 2002

<timeless> ... we documented how we generated them

<timeless> ... infamously it was claimed there were no testable

<timeless> ... we found plenty

<timeless> ... it was plh who said the CSS WG had strict
    metadata requirements

<tantek_> [45]http://wiki.csswg.org/test/format

      [45] http://wiki.csswg.org/test/format

<MikeSmith> qq?

<timeless> s| [46]http://wiki.csswg.org/test/format|->
    [47]http://wiki.csswg.org/test/format CSS Test Format
    Requirements (metadata)|

      [46] http://wiki.csswg.org/test/format
      [47] http://wiki.csswg.org/test/format

<timeless> ... the requirements are pretty minimal

<timeless> > <link rel="author" title="NAME_OF_AUTHOR"
    href="mailto:EMAIL OR [48]http://CONTACT_PAGE"/>

      [48] http://CONTACT_PAGE/

<timeless> > <link rel="help" href="RELEVANT_SPEC_SECTION"/>

<timeless> tantek: those two lines aren't much effort

<timeless> ... and from that you can generate a lot of stuff

<Zakim> chaals, you wanted to disagree with tantek...

<timeless> chaals: i agree that you don't want to make this
    monstrous pile of work for spec editors

<timeless> ... when i write specs internally, i write "MUST"
    and put a class on it

<timeless> ... using a WYSIWYG editor, that's a trivial

<timeless> ... and just that, it's pretty easy to do

<timeless> ... i find that helpful, as a spec author

<timeless> ... i can say "oh, this says everything, but the bit
    that really matters"

<timeless> ... you need an easy to use extractor

<timeless> ... if i had to spend hours going through the
    markup, i wouldn't do it

<timeless> ... as shepazu says, it isn't busy work

<timeless> ... but i can know my spec is better than what you
    expect from me

<Zakim> bryan, you wanted to note that avoiding authors to
    markup tests is the intent of developing tools that
    automatically do this, and help the authors to better structure

<timeless> bryan: we should shoot for tools that do stuff

<timeless> ... even add markup

<timeless> ... editors need to be ok with their specs being

<timeless> ... i suggested in DAP

<timeless> ... maybe members could support the editors

<timeless> ... who identify testability of a spec

<timeless> ... and actually manually add those things

<timeless> ... so people can focus on different things

<timeless> ... i don't want to add extra work for spec editors

<timeless> [ Spec editors are ... ... delicate flowers ]

<timeless> anne: i mentioned on irc, we should have the whatwg
    annotation system in W3C

<timeless> ... it allows most people to add annotations

<bryan> one other thing I suggested in DAP was that editors
    could have the assistance of members focused on the testability
    of the spec, and add annotations classes etc, working alongside
    the spec editors.

<timeless> ... you can add notes, tests, ...

<tantek_> link?

<timeless> ... this feature isn't implemented, it's stable,
    it's fairly broken, ...

<tantek_> to documentation of whatwg annotation system?

<timeless> ... it's disconnected from the specification

<plh> is it
    cumentation.html ?


<timeless> ... but they're displayed together

<timeless> ... it works broadly

<timeless> ... you can file bugs from it

<timeless> plh: is it documented?

<timeless> anne: i think the code is proprietary from Hixie

<timeless> ... i think he could put it somewhere

<timeless> anne: i don't think there's a complete description



<timeless> The requested URL
    /tests/html5/global-attributes/reftests/style-01.html was not
    found on this server.

<timeless> Additionally, a 404 Not Found error was encountered
    while trying to use an ErrorDocument to handle the request.

<timeless> [ Laughter ]

<tantek_> ms2ger - we're looking at some of your HTML5 tests

<timeless> rniwa: it would be nice if we had a dashboard

<timeless> ... showing how many tests per section of the spec

<timeless> ... showing how many sections we have in a test

<tantek_> or maybe test density

<tantek_> like tests per 1000 characters ;)

<timeless> ... @TPAC, I had trouble observing all the
    information needed for a test

<timeless> ... it'd be nice for a 5 yo. to look at a wiki and
    write a test

<tantek_> +1 on using wikis

<plh> [51]Guidelines for Authoring tests

      [51] http://www.w3.org/html/wg/wiki/Testing/Authoring/

<tantek_> for collaboratively writing / improving tests

<Zakim> chaals, you wanted to channel anne

<timeless> chaals: i wanted to channel anne , but he channeled

<krisk> correct link ->


<timeless> ... we'd like to have a Pony

<timeless> ... free beer at the start of every meeting

<krisk> ..and IE passes this test just fine

<timeless> ... and some tools

<timeless> ... any volunteer to ask Hixie about borrowing his

<timeless> ... rniwa, you look busy

<timeless> rniwa: i'm talking to Hixie now

<krisk> The list is a good spot to ask questions e.g.

<timeless> [ Chrome and Safari both fail the reftest, nightly
    and ie9x64 pass -
    style-01.html ]


<timeless> chaals: anything else we should talk about?

<timeless> ... do we need documentation for test harnesses?

<rniwa> Ian says he can open-source and let anyone use it.

    [sweet. thanks Ian]

<rniwa> who should contact Ian about that?

<timeless> krisk: in my experience, browser vendors create
    better tests when they start implementing features

    [/me wonders how conceptually different it is from Annotea]

<timeless> ... there is wiki information on a bunch of that

<timeless> ... there's someone from korea who came out of the

<timeless> ... if you aren't on the list
<public-webapps-testsuite@w3.org>, it's harder

<timeless> chaals: I suggest we close the topic

<tantek_> www.w3.org/wiki/SpecProd/Restyle

<timeless> tantek: i want to suggest the Spec ReStyle effort at

<timeless> s|www.w3.org/wiki/SpecProd/Restyle|->
    [54]http://www.w3.org/wiki/SpecProd/Restyle Spec ReStyle effort
    at W3|

      [54] http://www.w3.org/wiki/SpecProd/Restyle


<timeless> paulc: I had a simple observation

<timeless> ... the HTML WG is meeting tomorrow and the next day

<timeless> ... and we expect the next opportunity is TPAC in

<timeless> ... as Co-chair at the HTML WG, I proposed we not

<timeless> ... and WebApps is MT and HTML is ThF

<timeless> ... if WebApps wants to go ThF, we could flip that

<timeless> ... but we should be intentional about this

<timeless> ArtB: chaals responding MT and said the same thing

<timeless> paulc: ok, so both WGs can make independent
    decisions about going to TPAC

<timeless> chaals: we've done that explicitly, more or less

<timeless> ... this group has only met @TPAC

<timeless> ... for a number of years

<timeless> ... TPAC has helped, 40-50 people

<timeless> ... TPAC is hard work

<timeless> ... it's the meeting where people are present

<timeless> ... HTML, SVG, CSS, Audio, etc.

<timeless> ... I believe we should keep going there

<timeless> ... it's worth going there

<timeless> ... is there anyone who think we shouldn't go there?

<timeless> ArtB: it's in our charter

<timeless> chaals: we could ignore our charter

<timeless> ... we started talking about it months ago

<timeless> ... how many people will go this year?

<timeless> ArtB: who isn't planning to go?

<timeless> [ Essentially no hands ]

<ArtB> [55]Face-to-face: we will meet during the W3C's annual
    Technical Plenary week

      [55] http://www.w3.org/2012/webapps/charter/

<timeless> chaals: if we did a meeting next time in the US at
    this time of the year

<timeless> ... who is unlikely to go?

<timeless> [ no serious hands ]

<timeless> chaals: if we had a meeting outside the US, who is
    unlikely to go?

<timeless> [ no hands ]

<timeless> chaals: excellent, we'll have a meeting in ...

<timeless> MikeSmith: what i'm looking at now is the HTML5 bug

<timeless> ... that shows the state of my life

<timeless> chaals: is there a better way to do this meeting

<timeless> ... than to do this meeting together?

<timeless> ... other than having widgets as a split

<timeless> shepazu: this was effectively an unconference

<timeless> ... i didn't hear any exceptions

<timeless> chaals: tpac with 60 people in the room could be

<timeless> ArtB: we could say no to observers

<timeless> Josh_Soref: you'll lose the scribe

<timeless> shepazu: that's a big difference

<timeless> adrianba: i'd support beer in the requirements

<timeless> chaals: so, this will be the way we'll work then

<timeless> ArtB: so paulc, when will you make the decision on

<timeless> paulc: the WG has always sent out a we'll go

<timeless> ... and there has never been a respose

<timeless> ... we'll ask tomorrow

<timeless> ... and ask for a response on friday

<timeless> ... i don't know how many of the members here have

<timeless> ... we're trying to get to REC

<timeless> ... there's pressure on W3C to get an HTML5 REC

<timeless> ... using F2F time to get REC makes sense

<timeless> ... we'll see what they say

<timeless> chaals: I apologize to paulc about our unexpected

<timeless> [ The meeting room was extended to 6pm ]

<timeless> [ Break until 4pm ]

Warnings for old DOM Specifications

<ArtB> [56]Msger's Proposals


<ArtB> [57]Bjoern's comments


<smaug_> next TPAC will be on the better side of the world?

<anne> smaug_: France I think

<ArtB> [58]DOM Level 2 Views Warning

      [58] http://www.w3.org/TR/2000/REC-DOM-Level-2-Views-20001113/

<timeless> chaals: warnings for old DOM specifications

<timeless> ... and others

<timeless> ... it is generally believed that, e.g. DOM2 Events

<anne> smaug_: so if by better you mean non-US, yes

<timeless> ... is obsolete

<timeless> ... and probably not the best reference

<smaug_> ok, thanks

<timeless> ... if you're looking for a DOM Events specification

<timeless> ... two questions:

<timeless> ... what should we do

<timeless> ... what should it say?

<timeless> ... for people who look for things to be shifted to

<timeless> ... some people say people look for things that work

<timeless> ... we had a proposal to do this

<timeless> ... we got an email from bjorn

<timeless> s/bjorn/bjoern/

<timeless> ... identifying technicalities

<timeless> ArtB: he objects to

<timeless> ... the pointer to the replacement doc being an ED

<timeless> ... he finds that not acceptable

<timeless> ... if we were to point to a WIP

<timeless> ... it should be a /TR/

<timeless> ... because an ED by definition is constantly

<timeless> ... the rest of his comments were nits about
    specific text

<timeless> adrianba: i can't talk a lot about this

<timeless> ... MS has regulatory requirements around W3 RECs

<timeless> ... a note that suggesting you shouldn't read the
    document would be a problem for us

<timeless> ... however, a note saying the document isn't
    actively being maintained

<timeless> ... with a pointer to something being actively

<timeless> ... would be acceptable

<timeless> paulc: when we discussed this in the HTML WG

<timeless> ... i had a talk with Ian Jacobs

<timeless> ... when they redid the w3 web site

<anne> Example of where this is done today:

      [59] http://www.w3.org/TR/DOM-Level-2-Views/

<timeless> ... they put the oldest specs at the top

<timeless> ... the underlying cause of this

<timeless> ... is that you see the old specs

<adrianba> s/something being/something describing what is/

<timeless> ... I'm working with IanJ to improve this

<timeless> ... in particular, it includes XHTML in the HTML

<timeless> ... one of the underlying causes here

<timeless> ... is that people do this search

<timeless> ... and it fills their screen

<timeless> ... and you don't even see DOM4

<timeless> ... some of us are working on the underlying cause

<timeless> ack

<timeless> s/ack //

<timeless> chaals: there are regulatory problems

<timeless> ... other things

<timeless> ... If you go to DOM0, or DOM4, or DOM3E, or DOM2E

<timeless> ... what we have is "This version, latest version,
    previous version"

<timeless> ... we probably need something more intelligent

<timeless> ... a bit of wordsmithing to do

<timeless> Josh_Soref: adrianba, are these a problem for MS?

<timeless> adrianba: it isn't my problem

<timeless> s/problem/preference/

<timeless> ... my preference is a link to a page that lays out
    the status of the dom specifications

<timeless> ArtB: so, the last sentence could be tweaked

<timeless> ... a pointer to a wiki doc?

<tantek_> how about start with w3.org/wiki/dom ?

<timeless> chaals: DOM4 isn't the only relevant spec

<timeless> ... DOM3E has said it doesn't want to point to DOM4

<tantek_> and here's a stub, feel free to contribute:

      [60] http://www.w3.org/wiki/Dom

<timeless> anne: there was a CfC

<timeless> ... it passed

<timeless> chaals: no, it didn't pass

<timeless> ... no mail from Chairs

<tantek_> oh look, there was a [61]http://www.w3.org/wiki/DOM
    already, now redirected to that.

      [61] http://www.w3.org/wiki/DOM

<timeless> Josh_Soref: adrianba, is this better?

<timeless> adrianba: yes

<timeless> Josh_Soref: my preference is for this, since I don't
    want to bikeshed dom4 => dom5 references when we finish DOM4

<timeless> Josh_Soref: change the last sentence to "Please see
    [wiki/[Category]] for the status of ..."

<timeless> chaals: thank you very much to paulc, Microsoft for

<timeless> [ Applause ]

<timeless> chaals: thanks to Josh_Soref for scribing

<timeless> [ Applause ]

<timeless> chaals: it takes a special person to scribe a two
    day meeting

<timeless> ... where's the beer?

<shepazu> s/special person/special sort of person/

<tantek_> [62]http://www.cafeborrone.com/

      [62] http://www.cafeborrone.com/

<tantek_> 1010 El Camino Real, Menlo Park, CA 94025 |

<timeless> [ Adjourned ]

<timeless> trackbot, end meeting

Summary of Action Items

    [NEW] ACTION: adrianba to liaise with Robin to ensure feature
    detection is part of his API design document [recorded in
    [NEW] ACTION: barstow make sure all of WebApps' new Editors are
    at least aware of [64]http://www.w3.org/TR/test-methodology/
    [recorded in
    [NEW] ACTION: bryan seriously consider using
    [66]http://www.w3.org/TR/test-methodology/ in Push Events spec
    [recorded in

      [64] http://www.w3.org/TR/test-methodology/
      [66] http://www.w3.org/TR/test-methodology/

    [End of minutes]
Received on Tuesday, 8 May 2012 17:12:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:34 UTC