W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Draft Minutes: 31 October 2011 f2f meeting

From: Arthur Barstow <art.barstow@nokia.com>
Date: Tue, 01 Nov 2011 07:05:00 -0700
Message-ID: <4EAFFC8C.8050301@nokia.com>
To: public-webapps <public-webapps@w3.org>
The DRAFT minutes from the October 31 f2f meeting are in the following 
document and copied below:


I believe Chaals may do some tidying.

If there are any important (i.e. non-editorial) additions, corrections, 
etc., that need to be made, please respond to this e-mail.



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

                                - DRAFT -

                          WebApps f2f Meeeting

31 Oct 2011


       [2] http://www.w3.org/2008/webapps/wiki/TPAC2011#Agenda_Monday.2C_October_31

    See also: [3]IRC log

       [3] http://www.w3.org/2011/10/31-webapps-irc


           Art, Charles, chaals, Dom, Cameron, JonathanJ, Laszlo_Gombos,
           Eliot, Graff, Sam, Weinig, Jacob, Rossi, anne, Josh_Soref,
           pererik, Kris, Krueger, magnus, shepazu, SungOk_You, Dowan,
           Bryan_Sullivan, Jonathan_Jeon, Marcos, Robin, Jonas_Sicking,
           israelh, DanielAppelquist, mjs, dcooney, stpeter, manyoung,
           adrianba, WayneCarr, darin, Soonho_Lee, Jeff, ifette, spoussa

           Art_Barstow, Charles_McCathieNevile

           Art, Josh_Soref, chaals, JonathanJ


      * [4]Topics
          1. [5]Spec status and plans
          2. [6]CORS
          3. [7]animations [cont'd]
          4. [8]Charter, re-chartering and scope
          5. [9]Charter/Rechartering
          6. [10]Charter/Web Intents
          7. [11]Charter/Merge DAP into Web Apps
          8. [12]Charter/Web Notifications
          9. [13]Charter/DOM Mutations
         10. [14]Charter/XHR
         11. [15]Charter/Parsing and Serialization
         12. [16]Charter/Editing
         13. [17]Charter/IME
         14. [18]Websockets
         15. [19]DOM3 Events, DOM4
         16. [20]Widgets v2
         17. [21]D3E
         18. [22]Widgets v2
      * [23]Summary of Action Items

    <anne>  hey chaals

    <anne>  long time

    <Ms2ger>  Hai :)

    <Ms2ger>  anne, look over your shoulder, perhaps? :)

    <anne>  maybe if you're a woman and working here

    <anne>  at the Marriott that is

    <dom>  nice way to hide yourself!

    <ArtB>  Scribe: Art

    <Ms2ger>  Just you? :)

    <krisk>  +present

    <Josh_Soref>  Scribe: Josh_Soref

    ArtB: the way we've run these big tpac meetings is to try to get as
    much flexibility to the topics in the meeting room
    ... we have a very large list of identified topics that we (i and
    the group) have identified
    ... given this, we can use some time to determine what to talk about
    ... it's hard for me to determine how much time the things i've
    allocated for today will take
    ... it's possible we'll have holes, and we can either take breaks or
    pull in topics from tomorrow
    ... we want to be flexible and be able to hash out big issues
    ... let's start by looking at potential topics for tomorrow
    ... is there a lot of interest on talking about these things, and if
    so, when do we want to talk about them
    ... what we did last year was count how many people are interested
    (show of hands)
    ... testing - 11
    ... joint meetings w/ other WGs
    ... -- that people want to shoehorn
    ... Joint Meetings - 0
    ... XBL2 ... has been a deliverable for 5 years or so... there was a
    thread, "is it dead?"
    ... XBL2 - 13
    ... DOM Mutations ...

    [ not dominique mutations -- laughter ]

    <anne>  dom.clone()

    ArtB: ... and there's the admn ...
    ... DOM Mutations - 11
    ... XHR1 ... there was a notion (by anne ) should we give up on XHR1
    and just spec XHR2
    ... do we want a time slot for that?

    [ no one expresses interest ]

    anne: not even me, i think we can just do it in a few minutes

    ArtB: let's do it during the pubstatus time slot today
    ... XHR1 - 0
    ... DOM Parsing and Serialization
    ... do we want to formally add it to webapps when we recharter?

    heycam: is there a slot for DOM4?

    [ DOM4 would be in generic chartering ]

    scribe: DOM Parsing and Serialization - 0

    ArtB: is aryeh here?
    ... HTML Editing API - 0

    [ to be done in chartering ]

    ArtB: is Ian F here?
    ... Storage Quota - 0
    ... API Design ...

    66.html ->  Storage quota API

      [24] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1666.html

    ArtB: -- Robin had put together a rough outline


      [25] http://dvcs.w3.org/hg/webapps/raw-file/b941da0491a8/api-design/Overview.html

    ArtB: API Design - 16
    ... Stream API proposal (from Microsoft, that Adrian sent to the
    ... -- and File API
    ... Stream API and File API - 10


      [26] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0577.html?

    ArtB: Index DB - 5

    <bryan>  Proposal for discussion of server-sent events extension for
    connectionless push support:

      [27] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0577.html


    ArtB: proposal by bryan to add a slot for server sent event
    ... Server Sent Event Extensions - 4

    [ Scribe takes a break while ArtB resequences things on screen
    unsaved in Wiki TPAC2011 ]

    [ ArtB commits Schedule to Wiki --
    tober_31 ]

      [28] http://www.w3.org/2008/webapps/wiki/TPAC2011#Agenda_Monday.2C_October_31

    anne: I need to leave, but we should talk about CORS

    ArtB: CORS has been important... so important that a WG has been
    made for it

Spec status and plans

    ArtB: Web Application Security Working Group

    [ Scribe takes a break while anne outlines the history of the
    creation of that group with a dose of skepticism ]

    <chaals>  Josh_Soref: There are a couple of community groups created
    to edit a spec, so maybe stuff gets done in community groups and
    webapps gets used to handle formal publishing for it.

    [ ArtB reviews pub status ]

    ArtB: do we need to add an Errata to DOM Core?

    [ Chatter about Element Traversal and DOM4 ]

    <Marcos>  +nvbalaji

    DRAFT ACTION: Barstow work with Doug

    <anne>  [29]http://www.w3.org/TR/web-forms-2/

      [29] http://www.w3.org/TR/web-forms-2/

    <anne>  ^ same thing

    <chaals>  AvK/Shepazu: Element traversal to point towards DOM4 as
    where the future work gets done (e.g. errata)

    <chaals>  ACTION: Art to talk to Doug about the traversal from
    Element Traversal to DOM4 [recorded in

    <trackbot>  Created ACTION-628 - Talk to Doug about the traversal
    from Element Traversal to DOM4 [on Arthur Barstow - due 2011-11-07].

    Eric: File APIs and Directory
    ... there are some bigger and smaller changes coming
    ... implementation status is not up to date
    ... chrome only, but it's more implemented

    ArtB: can any other implementers speak about Writer and Directories
    and systems?

    chaals: we have an implementation because we internally use it
    ... we want to get it done
    ... right now we ship our own

    <smaug>  Isn't it still unclear whether we need the whole Directories

    chaals: we expect it to change

    <smaug>  (ah, sicking is talking)

    jonas: we have plans

    macie: apple has plans

    anne: I think apple's position is more in line with the last two

    <weinig>  Josh_Soref: I'm not weinig, Sam Weinig

    eric: File Saver ...

    ArtB: From Origin header ...
    ... what's the implementation status?

    anne: I don't think anyone has implemented it

    ArtB: Progress Events ...

    anne: I think the main thing blocking implementations is Constructor
    ... I guess WebKit has that
    ... it's fairly simple (just properties/methods) since dispatch is
    covered in other specs

    jonas: we haven't started on constructors, since it's non trivial
    ... probably somewhat soon, but next year

    anne: similar for us
    ... it's easier but not a priority

    ArtB: Selectors
    ... it's blocked by WebIDL

    Josh_Soref: is WebIDL going to be a topic

    ArtB: there's a slot available and heycam is sitting next to you :)
    ... Server Sent Events
    ... when I left Boston, we were down to 0 bugs

    anne: it doesn't cover Cross Origin
    ... It's going to get another argument in the constructor to cover
    cross origin

    ArtB: the main thing is that changes are coming, so it doesn't make
    sense to go to LC
    ... WebIDL
    ... it had LC2

    <chaals>  s/to cover cross cross origin/to cover cross origin and
    opting in to credentials exchange/

    heycam: there are some non controversial issues
    ... and then a question of whether it should be less non JS specific

    ArtB: we have a slot for tomorrow at 4

    <anne>  EventSource will get the same cross-origin story as
    XMLHttpRequest basically

    <anne>  is what I said

    <anne>  and everyone is on board, change just needs to be made (well
    everyone that voiced an opinion)

    ArtB: PostMessage
    ... Web Workers
    ... Marcos: widgets...?
    ... widget interface is blocked by webidl and webstorage
    ... i think W3 Team has agreed on changes to pub reqs re:HTML5
    ... WARP had been stalled ... PAG has been active recently, and
    there's reason to believe that the PAG will conclude relatively soon

    [ Marcos gives a summary ]

    dom: is there an eta for the report?

    Marcos: shortly after TPAC, it needs a bit of clean up

    chaals: there is a draft

    ArtB: DigSig (for Widgets)
    ... that spec is in PR, it's blocked by XML Sec PAG
    ... Widget URI moved back to WD in September

    Marcos: trying to align it with File API... responding as a fake
    http server
    ... hopefully it'll have fairly similar behavior
    ... and move to LC

    ArtB: View Mode media feature is in PR
    ... and will move to Rec when Media Queries advances to PR
    ... Widget Updates

    [ Break until 10:30a ]

    <Ms2ger>  10:30

    <dom>  glazou has joined #webapps

    <Ms2ger>  Not 11 either, apparently

    [ We're about to resume ]

    ArtB: we have 3 or 4 WGs here
    ... ask that observers make room around the table for WG members

    [ ArtB introduces ]

    <dbaron>  [joint meeting of Web Apps, Web App Security, Web Fonts,
    and CSS]


    [ ArtB introduces the groups who have dependencies on CORS ]

    vladimir: It started with the development of the Web Open Font Spec
    ... when same origin was selected
    ... but the comment was made that it isn't specific to Web Font
    ... and it was suggested to make the Same Origin specification be
    made on a link specific basis
    ... The requirement was marked as at-risk
    ... and moved toward CSS

    <anne>  same-origin policy

    <anne>  From-Origin header

    <ArtB>  From-Origin spec:

      [31] http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html

    vladimir: CSS needs to decide which to use to relax the restriction

    jdaggett_: I'm the editor of the CSS Fonts Spec
    ... the spec today says fonts are same-origin by default with CORS
    to relax it
    ... the question is what's the mechanism
    ... should it be From-Origin
    ... and people who put a font on their server
    ... should people use CORS to relax it?
    ... there's a fundamental issue
    ... From-Origin/CORS
    ... If I say "allow all origins" (with CORS) and "from-origin same"
    ... how do they mesh together?

    anne: From-Origin would Win

    <tcelik>  greetings (CSSWG member, representative from Mozilla

    anne: From-Origin integrates with the fetch algorithm

    tab: From- would stop it first

    anne: yes, CORS would just see a fault and couldn't do anything to
    unfault it
    ... everything that fetches should be defined in terms of the fetch
    ... that's a bug in the fonts spec, it doesn't reference the fetch

    clilley: could you provide text?

    anne: the CORS specification requires specific invocation of the
    request algorithm

    jdaggett_: so any spec with a same-origin restriction needs to have
    specific text?

    anne: yes

    clilley: the host language has to invoke the fetch algorithm in
    order to trigger it

    anne: the specification [CORS] specifically lists the text to
    trigger invocation

    shepazu: Maybe we should have a FAQ somewhere for how to integration

    weinig: Section 8 of CORS has this text

    <ArtB>  [32]http://dev.w3.org/2006/waf/access-control/

      [32] http://dev.w3.org/2006/waf/access-control/

    Marcos: do you have specs that use it?

    [33]http://www.w3.org/TR/cors/#cors-api-specification-advice ->
    advice on using CORS in other specs

      [33] http://www.w3.org/TR/cors/#cors-api-specification-advice

    anne: HTML and XHR

    <dbaron>  (should we move back to the main topic?)

    anne: it is quite intricate
    ... since there are credentials and other things
    ... if you have a model that sends credentials by default

    <glazou>  ArtB: let's focus back on main topic please

    anne: and you want to do something else
    ... XHR uses a withCredentials attribute
    ... HTMLxxx has something else

    jdaggett_: that isn't the most important topic

    tab: you have a paragraph that says anyone wanting to use CORS
    ... must specifically reference the algorithm and set particular
    ... what would be helpful is specific example text

    ACTION tab to write proposed text

    <trackbot>  Sorry, couldn't find user - tab

    anne: we have two specifications which do things differently because
    it's rather different for different environments

    sicking: one of the issues specifically about fonts
    ... is the whole thing about whether it makes sense about embedable
    ... and there's the question about exposing the resource to the
    ... Can we skip the embedding and just make it readable to the world
    ... Any time we've tried to expose a resource without letting the
    page see the resource, we've failed
    ... e.g. with images we leaked image dimensions to the web page
    ... with WebGL, we accidentally leaked pixel data through a timing
    ... it's possible you can leak other data from transparency
    ... with fonts it's even more likely since you can get information
    from timing
    ... can we say that fonts are inherently non private and we can
    share with anyone on the web?

    florian: the answer is that in general fonts do not contain private
    ... it seems that people believe that in some edge cases they do
    ... the font itself doesn't contain private data, but the presence
    does indicate that the product exists
    ... it doesn't seem necessary to restrict by default

    clilley: i agree in general
    ... a WOFF font can contain licensee and licensor
    ... it's not quite private
    ... but that's leakable
    ... i believe that form-origin is appropriate

    dbaron: one other case with private data
    ... is font-subset
    ... which is common with EOT
    ... and it's likely we'll get that for WOFF
    ... and if you subset for WOFF specifically to a page
    ... then you leak the contents of the page

    tab: the distinction on the table
    ... is whether an embedded resource
    ... embedding-vs-reading

    dbaron: the argument jonas made is that every time we tried to make
    that distinction, we've failed

    tab: right, can we say "embedding means reading"
    ... because we've failed each and every time we've tried

    weinig: leaking licensee/licensors...
    ... while i understand that we leak some info
    ... how would we leak licensee/licensor?

    clilley: that only happens if you don't make the distinction between
    reading and embedding
    ... there is an extension for firefox that enables that through an
    internal api

    weinig: is that available to webcontent?

    clilley: it isn't available to web content (only chrome)

    weinig: you obviously could mask some things
    ... the non visual elements are easily maskable

    vladimir: the way i understand tab's argument
    ... is that each time we make the distinction between
    ... is that it's easier to not do it
    ... i don't see why embedding-origin is the simple approach

    mjs: a couple of people have claimed that reading/embedding
    distinctions have always failed
    ... i bet none of you would make all images world readable
    ... the fact is that there is still a distinction
    ... when it's too easy, we usually consider it a security bug
    ... and try to fix it
    ... it's true that it's hard to maintain that distinction
    ... i think people are wrongly trying to make the claim that there
    is no distinction

    <anne>  and also for new ones such as video

    jdaggett_: we're not in the same case as images
    ... this is a new resource type
    ... we can define a behavior
    ... with fonts, there are any number of ways
    ... you can't do the type of tainting with canvas
    ... with fonts, you can infer character set, or metrics, or ...
    ... trying to analyze all of the apis is too hard
    ... back to what jonas said
    ... if we define that all cases are readable
    ... maybe we make it by default origin restriction

    clilley: the claim is made that for fonts that we don't make the
    distinction for embedding-reading

    dbaron: i probably made the claim too strongly

    clilley: and i interpreted this for fonts that we shouldn't be doing

    sicking: for browser vendors, the pain is addressing security issues
    ... instead of working on features

    <dbaron>  dbaron: ... and instead of saying it always failed, should
    have said it either always failed or led to lots of pain trying to
    prevent it from failing

    sicking: for images, we now have an api where we have to add this
    tainting thing
    ... if we had CORS on images from the beginning
    ... we'd probably have more mashupable
    ... we don't because 3rd parties can't get this stuff easily
    ... we won't expose license info for similar reasons
    ... if sites can opt into with shared by default
    ... if people have to make a decision by adding cors headers
    ... then they'll actively make the decision
    ... then they'll go through a security review
    ... if they don't have to go through a security review (putting up
    CORS), they won't think about it

    ArtB: anne are you coming up with additional constraints?
    ... is this more UC clarification?

    anne: there's nothing that needs to be changed in CORS or
    ... the question is if Fonts should work like Images or XHR
    ... and i stopped caring a long time ago

    tab: so john, make a decision

    clilley: where are we in the process
    ... are both CORS and From-Origin is in where?

    ArtB: CORS is a joint from Sec+WebApps
    ... From-Origin is in WebApps only
    ... I saw Brad walk in

    clilley: follow up, where are the issue lists for these specss?
    ... pointer?

    BradL: CoChairing Web Apps Sec WG
    ... Web Apps Sec is co delivering it with Web Apps to drive it
    ... to keep IPR grants
    ... there are some small issues
    ... including Best Practices
    ... additionally our tracker has some other small issues
    ... which we may move to bugzilla
    ... the primary issue before REC is a test suite

    <ArtB>  CORS: bugs:

      [34] http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=WebAppsWG&component=Access+Control&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_statu

    BradL: anne is working on it
    ... we're new so we'll be Workshop with Staff

    clilley: and for F-O?

    BradL: that's not in our charter

    <Zakim>  Josh_Soref, you wanted to ask where it is

    <ArtB>  From-Origin: [35]http://www.w3.org/TR/from-origin/

      [35] http://www.w3.org/TR/from-origin/

    vladimir: from everything i've heard so far, we seem to lean to
    same-origin with CORS
    ... and third resources come from my question was the same as
    clilley's - already answered

    chaals: we seem to be leaning that way
    ... How many people Same Origin by default
    ... Same-Origin - 25
    ... Against Same-Origin - 8

    clilley: follow on question ...

    chaals: is this a strong Objection, if we resolved to use Same
    Origin, would you argue, or can you live with it?
    ... if you can't live with that decision, justify why we should
    continue arguing

    Bert: for Fonts, i really like the restriction to be on a higher
    level than the protocol
    ... something that isn't http
    ... for animations

    tab: i don't believe this is restricted to any protocol

    [ jdagget points out to tab that CORS is http ]

    [ and clilley explains that you can reference ftp resources ]

    Adam: that's a general problem with CORS everywhere
    ... when we introduce other protocols
    ... we'll demand that they support CORS

    <dbaron>  (Adam == Adam Barth)

    tab: and patch ftp

    Bert: How about email?

    anne: how do you envision?

    Bert: anything with a url must have a

    anne: so emails include fonts?

    Bert: yes

    anne: then they're same origin

    Bert: what about bittorrent?

    <Ms2ger>  s/Adam:/Adam Barth:/

    vladimir: if you want to make it available across origins, then you
    could do it?

    mjs: email messages might have a same-origin problem
    ... the main resource comes from mid: and cid:

    sicking: any protocol that people are starting to more actively use
    ... people are going to have to deal with cross origin issues
    ... anyone that wants to seriously start doing web deployment over
    other protocols will have to define how this works

    Bert: the protocol is not important, it's the resource that's

    sicking: we've defined domains
    ... and said that everything in a domain is owned by the same person
    ... every other protocol will have to define something like that

    Bert: that's a hack

    clilley: I agree that specific protocols saying

    <anne>  the web is a hack. film at 11

    clilley: that cids of a mid are the same as the mid
    ... that's not the question
    ... is there an objection

    mjs: if the spec says that embedding fonts in email never works, i'd
    have to object

    chaals: embedding stuff in email is a real thing
    ... it happens in Opera
    ... we have questions around that
    ... with images, do they automatically render?
    ... do you run JS from another source?
    ... the issue of clilley/Bert
    ... is do we make a protocol agnostic work
    ... but we live on HTTP
    ... we don't object to people expanding things to other protocols
    ... i agree with mjs
    ... if we say you're not allowed to embed things except in http
    ... that would be beyond what is reasonable for a spec
    ... (this is a personal position)
    ... clilley's question is
    ... do we have someone who objects to that proposal
    ... of us focusing on http
    ... to Bert's objection
    ... that we have a hack, and forcing others to work with us

    dom: people send newsletters in html
    ... and they rely on w3c of sending fonts in emails

    Florian: using http
    ... implicitly prevents other protocols from using it cross-origin

    jdaggett_: the wording is that cross origin is not allowed
    ... unless explicitly relaxed using CORS

    <anne>  I do think it should be defined for things that are fetched
    within a "browsing context" which is more than HTTP

    clilley: in the context of this question
    ... sure email is a case
    ... it would be possible to resolve cid: in CORS

    sicking: it's a good idea to say if it's HTTP use CORS
    ... but for other protocols, fall back to their protocol for
    addressing this issue

    Florian: if you're using HTTP then use CORS
    ... and saying if you're not HTTP then use the CORS equivalent
    ... is going too far

    glazou: this is a problem
    ... because we don't know if there's an equivalent for other
    ... we don't know their schedules
    ... this isn't reasonable

    anne: what do you propose instead?

    glazou: the w3c has dealt in the past
    ... with protocols that do not belong to the web strictly
    ... we can deal with them later

    vladimir: i don't think this should hold us

    jdaggett_: Florian's point is that he wants to restrict it to Only
    ... the wording now is 'same-origin' and leaves it at that

    Florian: do not speak about restrictions for not http

    anne: there are 3 cases
    ... same-origin


    scribe: cross origin where the api fetching has http origin
    ... the scheme is not http and there's a cross origin for the other

    Florian: in the spec we're talking about
    ... we say 'for http do this, cross origin use CORS'
    ... we leave it up in the air
    ... for a later version or another group/spec

    chaals: Is there any reason to continue?
    ... Are there objections to
    ... saying that we define this for the first two cases anne

    <anne>  I would object to making the decision in a synchronous manner

    chaals: and for the third case, we leave it as "if you're using
    another protocol, you figure it out"

    anne: i don't want us to make synchronous decisions

    <hober>  anne++

    chaals: i agree
    ... but for the sake of getting out of the room
    ... Is there anyone who can not live with Florian's suggestion?

    [ No one ]

    <anne>  shepazu, just wanted to clarify as there's more than WebApps
    in this room

    chaals: is there anyone who can not live with a policy of by default
    we use Same-Origin
    ... for fonts

    <anne>  shepazu, no need for tss sounds

    chaals: and you use CORS

    [ No objection ]

    chaals: we're out of time
    ... thanks very much

    [ Applause ]

    <Ms2ger>  s|s/..../.../|

    <shepazu>  (anne, I don't feel it's useful to keep bringing up the
    decision policy when it's well established, and since any decision
    will *always* be subject to later discussion, in any group in W3C
    I've been in)

    <Ms2ger>  s|s/..../.../||

animations [cont'd]

    <Bert>  Sorry

    <smaug>  Josh_Soref: so is the agenda for tomorrow somewhere?

    <smaug>  I'd like to know when MutationObserver will be discussed

    <smaug>  if it will be discussed

    <Ms2ger>  [36]http://www.w3.org/2008/webapps/wiki/TPAC2011

      [36] http://www.w3.org/2008/webapps/wiki/TPAC2011

    <heycam>  s/Topic: animations [cont'd]//

    <Ms2ger>  The Return of the Josh

    <Ms2ger>  dom, I hear you're needed

Charter, re-chartering and scope

    <MikeSmith>  ArtB,

      [37] http://dvcs.w3.org/hg/ime-api/raw-file/tip/Overview.html

    s/present+WayneCarr/present+ WayneCarr

    s/present +stpeter/present+ stpeter/

    <stpeter>  Josh_Soref: thanks

    s/Josh_Soref: thanks//


    ArtB: Items
    ... WebIntents

    <Ms2ger>  s|s/present+WayneCarr/present+ WayneCarr|

    ArtB: -- where should it be, DAP/WebApps

    chaals: Can we push Widgets to the top of the stack (TAG will start

    [ Introductions ]

    <Ms2ger>  shepazu: Doug Schepers, Microsoft

    <Ms2ger>  ... er, W3C

    ArtB: welcome everyone
    ... dan you wanted to say something about widgets?

    DanA: no... not really
    ... there's a meeting on Saturday on Offline Applications
    ... which I'm coordinating

    ArtB: this morning we did PubStatus
    ... we also have on the agenda a block of time from 5-6pm tonight
    titled web application packaging v2

    chaals: What i really wanted to do
    ... it seems the widget work we charter for and did is done / about
    to be done
    ... as DanA said, there is this workshop coming up
    ... we have widgets
    ... appcache
    ... installable widgets
    ... offline apps
    ... If we go to do a version 2, is that something we'd do in this

    mjs: preferably not

    shepazu: in the early days of this group
    ... it was a shotgun approach
    ... i think we started focusing on apis
    ... we had the experience of only some of the people focusing on
    widgets work
    ... it doesn't seem like a good fit

    sicking: from mozilla's point
    ... i think what's interesting is ... packaging
    ... if that's not in the same group, that's ok

    shepazu: we're talking about the scope of this group, Web Apps
    ... there may be another group working on installable web apps

    sicking: are we talking about moving all of the widgets stuff?

    Marcos: we wouldn't move any of the stuff here, since it's all
    effectively done
    ... we could move or keep any future work
    ... i'm happy to go wherever the discussion is
    ... since we put in 5 years on the spec
    ... from an ipr perspective, i'm happy with where it is
    ... but moving it to another group would enable us to see who's
    ... so we don't just have Marcos on a mailing list emailing himself

    DanA: thanks for the invite
    ... one of the things i wanted to say
    ... is that one of my hopes for the workshop on Saturday
    ... is to clarify things for offline/appcache/widgets
    ... and for things outside w3
    ... which have prominense
    ... I don't think what will come out will be widgets2.


    scribe: people do use things offline and do want to install them
    ... it comes back to, i hope we have a coherent discussion on
    ... and out of that comes a mandate for doing work in this space

    chaals: sicking asked if this was just packaging
    ... my answer is no
    ... packaging is important
    ... but a key is looking at applications and how they work
    ... one of the thing for widgets is to let them work in more weblike
    ... we want appcache based things to work more like widgets
    ... appcache is at its basics packaging
    ... like Marcos, we don't really care whether it happens here, or
    somewhere else
    ... there is a question, because we're at w3c
    ... because we deal with objections/strong objections relating to
    ... if there's some clear thing we should know

    bryan: to underscore what DanA said
    ... we have similar views
    ... we see widgets as a base for web applications
    ... we see some challenges
    ... for how it works with the web
    ... in terms of security model
    ... it's broader than packaging
    ... than any specific api
    ... it's more about how they fit into the overall web architecture

    shepazu: i'd like to limit the scope to Web Apps Charter
    ... I'm proposing that the next charter from Web Apps not include

    chaals: when PAG is done, they should move to REC

    shepazu: do we delay the chartering of Web Apps until they're done?

    Marcos: we just adjust the text to say that Widgets is scope limited
    to the current deliverables being delivered

    DanA: i'd like to wait until after the Workshop

    [ ArtB does a time check ]

Charter/Web Intents

    jgraham: Web Intents
    ... is based on Android Intents
    ... it allows a site to talk about how they handle actions
    ... and allows client sites to ask about an action
    ... and lets the user pair them
    ... picking the service the user wants to use
    ... It's a solution to the "nasgar problem"
    ... -- Share with 40 items

    <heycam>  s/nasgar/nascar/

    jgraham: this is a short term communication ipc
    ... it was in the scope of DAPI

    plh: Web Intents is also in the scope of DAP

    darobin: It was deliberately put into the DAP charter
    ... it wasn't listed as Web Intents

    plh: is that WG working on it?

    darobin: I proposed doing it in DAP because we're already chartered
    to do it

    plh: what about Joint?

    darobin: I'm always worried about joint deliverables

    MikeSmith: what's the value of Joint?
    ... except additional process?

    plh: you get more patent commitments since you have commitments from
    members of both groups

    sicking: in my experience

    <MikeSmith>  tantek, likely nothing about UX, just about whether to
    take up the technology in the WebApps WG

    sicking: I would see the problem of discussions getting split up
    across 3 mailing lists
    ... unless we add a third mailing list

    dom: getting a sub mailing list is trivial
    ... the difficult part is getting people to subscribe to it
    ... the other thing is that web intents relates to discovery
    ... and DAP already has that in its charter

    ifette: part of the important consideration
    ... it may be in DAP's charter
    ... being in a charter may be expedient
    ... but it may not be the right solution
    ... we've talked about Web Intents as a possible solution for
    Permissions problems
    ... there's a lot of tie in potentially between Web Intents and
    other work in this WG
    ... I think this group already has the relevant members
    ... it's nice, I appreciate that DAP did outreach

    <tantek>  MikeSmith - without UX being the focus/driver, I'd suggest
    not bothering with taking up any such technology in any working

    jgraham: relating to device interaction
    ... I agree those will happen

    <tantek>  without UX being nailed first, intents is pretty much

    jgraham: the way that the api is written
    ... is so generic

    <tantek>  or we can all repeat the lessons learned by OpenID trying
    to solve the NASCAR problem (where UX was also neglected)

    <chaals>  ... that it doesn't matter whether it ties to the device or

    <ifette>  s/jgraham/jhawkins/


    dom: I think the fact that DAP is pushing quite heavily on service
    and discovery
    ... means that we want to be involved

    MarkV: Mark V.. Comcast

    <mav>  [38]http://www.w3.org/2009/dap/wiki/ServiceDiscoveryComparison

      [38] http://www.w3.org/2009/dap/wiki/ServiceDiscoveryComparison

    MarkV: Part of the reason we're interested


    scribe: Comcast and Cable Labs
    ... and Webinos have proposals
    ... It's in the charter of DAP currently
    ... it may be more appropriate here

    chaals: +1
    ... literally
    ... we have a proposal for discovery
    ... I'm speaking for Opera
    ... a lot of the people who need to be in the discussion are in DAP
    ... a joint deliverable has a little bit of value
    ... a wider IPR commitment
    ... more pain from split discussion

    <tantek>  How about a CG instead?

    chaals: more lists is hell
    ... there's a proposal of merging DAP and Web Apps
    ... it's part of our position

    [ amusing proposal and laughter ]

    chaals: We would lean towards
    ... DAP *was* a pretty dysfunctional, pointless, stupid thing, 2
    years ago
    ... it is no longer

    jhawkins: Web Intents and Discovery are similar, but they are not
    the same

    mjs: As a point of information
    ... Apple is unlikely to ever join DAP
    ... because of IPR concerns and others
    ... we are somewhat interested in Web Intents
    ... and would try to comment if it were in Web Apps or joint in Web
    ... we would not if it were solely in DAP

    shepazu: I'm hearing concrete reasons to have it in both
    ... that sort of supports having it as Joint

    darin: Darin, Google
    ... we work together with Apple
    ... it's fairly important that we be in the group with Apple talking
    about Web Intents

    chaals: two things
    ... permissions
    ... permissions as we all know is a flaming ungodly mess
    ... it comes up in web apps
    ... it comes up with almost everything that DAP does
    ... DAP will fail in everything if it isn't solved
    ... If Google and Apple are working together with everything
    ... why does it matter?
    ... Apple can have Google present the point

    darin: it's much easier if things are only in one room
    ... we are developing Web Intents with Mozilla
    ... it would be nice if everyone was in one room
    ... trying to maintain the conversation in different WGs is probably

    shepazu: both groups do all their work in the public
    ... web apps is a public mailing list the everyone can subscribe to

    ifette: the same argument could be made for whatwg

    [ shepazu and darin share the mic to talk about mailing lists /
    where work is ]

    dom: what darin is saying is that if the work was only in DAP
    ... then since apple couldn't be in DAP
    ... that it would require someone to do work to share with apple

    sicking: any outcome where all the parties can't be at the table is
    a failure

    [ ArtB time check ]

    ArtB: Would anyone object to a joint deliverable?

    ifette: capital O object?
    ... I think it would be better if it was a single list, a single WG
    ... I don't think we'd Object, but we have a preference against
    ... If DAP folks don't object to doing work in web apps, why don't
    we do the work here?

    shepazu: to clarify, you don't want it to be a joint deliverable?

    darin: DAP folks don't mind to do work in web apps
    ... so why not do work in web apps?

    chaals: just as ifette won't formally object to a Joint deliverable
    ... we would rather that the work happen in DAP
    ... it's not DAP saying we should merge the group
    ... it was darobin tossing up the idea

    darobin: i'm not even sure myself it's a good idea

    dom: one way is to go back to DAP
    ... maybe there are people in DAP who would want to be involved but
    can't join Web Apps

    ArtB: I'd like to move on to the next topic

    jhawkins: I've made a proposal
    ... that we upload the docs
    ... and get a thread started
    ... it sounds like it's not going to be in dap specifically
    ... it could be a joint effort
    ... it could move to a third mailing list
    ... after the fact

    chaals: as a way of moving forward
    ... Web Apps is not chartered to do that
    ... if DAP does the work and uses Web Apps

    ifette: No. no

    chaals: you want to wait until chartering?

    shepazu: do people object to adding Web Intents to the Web Apps
    ... we can always decide on Joint later
    ... I ask the chairs to make that call

    ArtB: Does anyone object to adding Web Intents to the Web Apps

    Suresh: Suresh, RIM
    ... so, trying to understand...
    ... what are the implications on the DAP charter?

    shepazu: we're just talking in this WG about this charter

    heycam: in terms of initial discussions before chartering
    discussions are made
    ... we've discussed things before the decision was made
    ... as we did for Editing

    [ Time check, 5 mins to 2pm ]

    weinig: How would it be added?

    shepazu: how it would be added would be a deliverable, discussed on
    the list

    mav: if that's concluded, i would ask that the same thing happen for
    discovery api
    ... because there's a lot of overlap

    chaals: +1
    ... we would be upset if one happens in DAP and one happens in Web
    ... we would likely to formally object

    RESOLUTION: No objection to adding Web Intents to the Web Apps

Charter/Merge DAP into Web Apps

    darobin: the general process of W3C
    ... is that we put things in DAP
    ... people say it sucks
    ... two years later, we try to move them to Web Apps
    ... i'm not sure it's a good idea
    ... but i just wanted to throw the idea out there

    [ Beep ]

    ifette: There's not enmity with DAP
    ... for the things that we work on, we want to make sure we have all
    the browser vendors there
    ... I know Microsoft joined, and that's great
    ... but we heard Apple won't
    ... For us, we need all the browsers to give input
    ... if we don't get that, there's not much point

    ArtB: Would any of the Web Apps members object to us merging DAP
    into Web Apps?

    chaals: Personal objections?

    Personal objections - 9

    chaals: are any of those Formal Objections?

    [ There were two Objections likely ]

Charter/Web Notifications

    ArtB: what anne wanted to discuss was taking the deliverables from
    Web Notifications
    ... and closing Web Notifications

    shepazu: I'd like to here why

    anne: the rationale would be that it's very hard to move it forward
    within the scope of Web Notifications
    ... the editor is overworked
    ... it's a very small group, I think 6 people
    ... not enough to pay attention

    ArtB: I should have noted that before the Web Notification WG was
    ... some members opposed in Member Confidential way to it being
    added to the Web Apps WG
    ... I remind people that they were Member Confidential

    shepazu: speaking as staff contact, I don't think it's that easy to
    find editors here

    anne: I could use chair time

    Marcos: can we take a poll of who would implement the spec?

    ArtB: who is actually interested in implementing this spec?
    ... Google, Apple, Opera, Mozilla

    adrianba: I didn't commit, because often we don't talk about things
    we're going to do, until we do them
    ... and when we do say we're interesting, that isn't a binding
    commitment either

    shepazu: i'd like to repeat that we tried before, and i don't think
    it will work
    ... this time

    chaals: Opera would be happy with it being here
    ... but we expect it to fail again

    ArtB: The chairs tend to think that if we made the proposal to add
    it to the charter
    ... that it would fail due to a formal objection

    chaals: we will put up the proposal to merging Web Notifications
    subject to Web Notifications being amenable

Charter/DOM Mutations

    <anne>  euh used to be called "Mutation Events"

    ArtB: from the perspective of the current charter
    ... There was a deliverable of "ADMN"
    ... there was a thread from adam klein
    ... from the charter perspective, how do we move forward
    ... is this a new specification, or do we add to dom4?

    anne: do we have to specify where it goes in the charter?
    ... as long as we say we're going to do it

    shepazu: I don't think that's a requirement
    ... we just need to clarify that we will do that work

    heycam: do we need a specific name in the charter?

    chaals: we need "managing changes to the dom and how they happen"

    <heycam>  s/managing/monitoring/

    <dom>  s/the dom/the DOM/

    <MikeSmith>  rniwa,

      [39] http://dvcs.w3.org/hg/ime-api/raw-file/tip/Overview.html

    RESOLUTION: add "monitoring changes to the DOM and how they happen"
    to the charter"


    <rniwa>  MikeSmith: thanks

    anne: basically everyone is focusing on XHR2
    ... I don't think that it makes sense to maintain version 1
    ... the effort far exceeds any imaginable benefit
    ... no one is focused on getting it finished

    adrianba: I agree with anne on this specific case
    ... I'd like to avoid setting a precedent
    ... but for this case, I think it makes sense to stop working on
    level 1

    sicking: I don't have a specific preference
    ... but I would kind of like to see it shipped
    ... if we could do that in a short order

    anne: Last summer, summer of 2010
    ... I wrote the spec, I wrote the test suite
    ... and no one followed up, none of the implementers

    chaals: like adrianba, I think it's a bad precedent
    ... to not ship specifications, that are already implemented and
    ... anne works on a lot of things, Opera would much rather he work
    on XHR2, than level 1
    ... as chair,
    ... does someone feel like we all do, and feel like finishing it?

    Marcos: why don't we just drop the '2' from XHR spec?

    chaals: there is an XHR1, it's probably pretty much done
    ... I don't see much point in playing a numbers game

    [ What prevents us from it being done? ]

    anne: lack of implementers trying to pass the test suite
    ... it is not done, it just requires maintenance costs

    Marcos: why is XHR2 dependent on XHR1

    anne: XHR2 isn't dependent on XHR1

    Marcos: so kill it!

    <dom>  but are there other specs depending on XHR1?

    <dom>  we should probably check before taking such a decision

    shepazu: is the test suite complete?

    anne: the test suite is pretty much complete

    shepazu: why aren't people passing the tests?

    adrianba: i think there are people that are passing all the tests
    ... i think the changes that are required to pass the tests are
    probably not high priorities to the vendors
    ... since the web kind of works

    shepazu: if we can't get two implementations to pass the test
    ... then we remove that requirement from the charter

    chaals: does anyone object such that they're willing to do the work

    shepazu: i'm willing to review the work necessary

    anne: i'd object to a watered down version of the spec

    Marcos: i would object to having a spec with duplicate text
    ... on the grounds of having confusion

    shepazu: that's the situation we're in now

    Marcos: that's a process problem

    <darin>  is this the test suite:
    [40]http://tc.labs.opera.com/apis/XMLHttpRequest/testrunner.htm ?

      [40] http://tc.labs.opera.com/apis/XMLHttpRequest/testrunner.htm

    <anne>  My main point is that a specification should be complete and
    not leave out all kinds of requirements

    chaals: we have a deliverable
    ... that is of risk of being taken further

    <anne>  darin, yeah, one of the copies

    chaals: and having objections raised later

    <anne>  not sure if my harness works a 100%, been a while

    <darin>  anne, ok... looks like chrome and firefox fail a lot of

    <anne>  yeah, mostly edge cases

    chaals: it seems clear that we don't have anyone who is going to
    finish the spec
    ... with the possible exception of shepazu
    ... so are we happy to make the spec...

    ifette: "if the spec got finished, would all the browsers care, and
    go back, and become fully compliant? if not, then it doesn't seem
    worth doing"

    sicking: it's at the point where all that needs to happen is

    dom: to implement XHR2, XHR1 needs to be done

    mjs: I don't have a strong opinion about carrying forward
    ... but i'd rather a strong opinion to not have it in limbo

    adrianba: I agree with mjs
    ... the value of completing an XHR1
    ... that describes currently implementations with whatever vagueness
    is necessary
    ... getting that to REC is when the IPR obligations kick in

    chaals: that's important
    ... how many organizations in this room make browsers?
    ... because it's more than 5

    <Ms2ger>  [ Amaya ]

    chaals: Nokia makes, RIM, W3C (Amaya)

    s/makes/makes one/

    scribe: there is some value to other future vendors
    ... there is some value
    ... if we include XHR1 as a deliverable, not that it does not have
    an active editor, and may be abandoned
    ... does anyone object?

    mjs: I'd object to keeping it in limbo

    anne: I'd end up maintaining it

    shepazu: If i don't do it in 6 months, I won't do it

    chaals: does anyone object to just dropping it?

    bryan: does that mean XHR2 will never be finished?

    chaals: no, it means the things that need to be done in XHR1 won't
    be done until we finish the XHR2 spec

    PaulK: how much of XHR1 is just a subset of XHR2?

    [ Everything ]

    scribe: I don't understand this talk
    ... the problem is you don't have implementations or people willing
    to do testing

    anne: comments still come in
    ... for instance defining Garbage Collection


    scribe: but since XHR1 and XHR2 define events [or similar?]
    ... then editing it isn't that simple
    ... just because there's a CR version listed on the W3C page
    ... doesn't mean it's the latest version
    ... the latest version is the editor's draft

    mjs: for almost XHR's history, there have been two versions
    ... one to spec the original behavior
    ... and one to define the new cool features
    ... everyone interested was interested in the latter
    ... in retrospect, maybe this was a mistake

    chaals: mjs maintains his objection, shepazu withdrew his

    dom: one thing to check, is to see if anyone has a normative
    dependency on XHR1

    chaals: issues like that I expect to come out during chartering

    dom: chartering is a messy process

    <dom>  s/messy/AC/

    ACTION chaals to make sure that the webapps process is taking to the
    attention of the Chairs

    <trackbot>  Created ACTION-629 - Make sure that the webapps process
    is taking to the attention of the Chairs [on Charles McCathieNevile
    - due 2011-11-07].

    RESOLUTION: Drop XHR1 from our deliverables

Charter/Parsing and Serialization

    <Ms2ger>  Hi

    chaals: is there any objection to adding this to our charter?

    <Ms2ger>  Sorry, my connection is spotty

    chaals: does anyone object? does anyone propose that we add the
    ... does Ms2ger plan to do the work?

    <Ms2ger>  It doesn't matter to me, but I don't plan to put a lot of
    time in W3C-specific stuff

    <Ms2ger>  The spec is in the public domain, if someone wants to push
    it at the W3C, that's fine with me

    shepazu: is it our policy that we only add specs that we have
    editors for?

    chaals: we don't have that policy

    <Ms2ger>  I plan to keep doing the technical editing, but it's rather
    low-priority for me

    chaals: we tend to try to have an editor

    <tantek>  Ms2ger - what do you think of placing the spec in a
    Community Group? w3.org/community

    ArtB: we have some new stuff, web intents
    ... preferably we'd have at least two vendors interested in
    implementing it

    sicking: i don't think we'll have a shortage of implementations
    ... of course that was the case with XHR1

    <Ms2ger>  tantek, don't feel like spending time on that

    <weinig>  /msg anne

    chaals: and look at how useful that was

    s|/msg anne||

    <tantek>  Ms2ger - I sympathize.

    ArtB: i don't object adding it

    chaals: my preference is not to add stuff without an editor

    shepazu: i think this specification would be of particular interest
    to the SVG WG
    ... as someone from the SVG WG, i'd like to see this in the group
    that works on DOM

    ACTION shepazu to ask the SVG WG for editors

    <trackbot>  Created ACTION-630 - Ask the SVG WG for editors [on Doug
    Schepers - due 2011-11-07].

    RESOLUTION: Add Parsing and Serialization to Charter


    ArtB: I know Aryeh was working on Editing
    ... but he didn't make a commitment
    ... do we let him continue working in the CG
    ... do we pick it up now, pick it up later?

    ryosuke: i'd like to see it in the charter

    ArtB: aryeh felt that having it in a CG to do work forward
    ... but he didn't object to this WG finalizing it

    chaals: in the absence of someone driving it in Web Apps
    ... I think it would be a bad idea
    ... especially without the resources

    Josh_Soref: How is this any different from the previous charter

    <smaug>  #whatwg: AryehGregor "Microsoft Corp. has joined the HTML
    Editing APIs Community Group"

    chaals: I am proposing that we reject Editing APIs under similar
    ... given that there is a CG
    ... I feel we should let them alone given they already have a CG and
    we aren't likely to add much

    ryosuke: there's a difference in complexity
    ... Editing is much more complicated
    ... I think it will take a couple of years before it's ready

    adrianba: Microsoft just joined the CG with the intent of helping it

    chaals: does anyone propose that we move editing into the WG?

    RESOLUTION: We will not move Editing into this WG

    ArtB: MikeSmith asked me to add IME
    ... and I had a generic item related to work mode

    MikeSmith: I was hoping ifette was going to be here


    MikeSmith: if you type on a computer in Japanese/Chinese, and to
    some extent Koreans


    scribe: You type in Latin, and then you press a (compose) key to
    convert the text into a final character
    ... There are times when you're using a web application that you
    want the web application to be aware that you're using an IME
    ... The use case is when you want to do completion
    ... The IME is a platform level application running alongside the
    ... The browser would need to have access to the system IME
    ... and expose it to web applications
    ... web applications do not have access today to the system IME

    MikeSmith: it's very hard to explain this to people unfamiliar with
    ... a video showing this demoing web suggested autocomplete
    ... it's pretty simple, but it isn't self explanatory

    <ArtB>   IME spec:

      [41] http://dvcs.w3.org/hg/ime-api/raw-file/tip/Overview.html

    chaals: given two google editors
    ... is google proposing that it go into web apps?

    ryosuke: yes, we'd like it to be in this WG
    ... if you're using Google Docs, then a web browser doesn't know
    that you're editing
    ... and thus can't enable IME

    <Zakim>  Josh_Soref, you wanted to note that IMEs are incredibly
    buggy, crash prone and such exposure is a security hazard

    ryosuke: Google would like to simplify this so that IME can be
    turned on and off

    <dom>  Josh_Soref: IME are incredibly buggy, crash prone, and such
    exposure is a security hazard

    <heycam>  Josh_Soref: I'd like to note that I've worked on Mozilla
    for>10 yrs, one thing I looked at was crashes

    <heycam>  ... got lots from X11 IME

    <heycam>  ... more recently I worked at Nokia on Maemo, we had an
    IME, not shipped, but we had it

    <heycam>  ... it also wasn't particualrly wonderful

    <heycam>  ... more recently we had some great crashes frmo a web
    based IME in windows, from mozilla

    <heycam>  ... the IME is actually cloud based

    <heycam>  ... when their cloud went down, everyone using that IME
    started crashing

    <heycam>  ... any time we expose system level things to the web, it
    hasn't had experience with bad inputs

    <heycam>  ... nobody thinks you'll get bad input, and that'sb ad

    <heycam>  s/sb ad/s bad/

    mjs: one thing i'd like to see more clearly explained
    ... is the specific use cases for this api
    ... I don't have the experience that Josh_Soref does
    ... but i don't know there's much need
    ... it sounds like there's a work around
    ... the main downside is that it's inconvenient, or a hack
    ... that doesn't seem like a big deal

    ifette: i think there's a lot of reasons for adding the IME api
    ... if you look at google instant
    ... having access to the list
    ... having access to state makes it better
    ... gives a chance to give better results
    ... better services

    mjs: I think it would be good if someone could give a list of use
    cases where someone could do things you couldn't do today
    ... from skimming the document, i couldn't figure out what you could
    ... that you couldn't do otherwise

    chaals: is that an objection?
    ... an objection until you get further information?

    mjs: i think it would be better for the WG to have more information

    ryosuke: could we add the item to the charter

    chaals: we could add the item, we could talk about it before or
    after, we could add it next time

    ArtB: can someone take an ACTION to address mjs

    ifette: we can certainly come up with that list of use cases
    ... I can make sure we to get someone from our organization to
    provide this use case
    ... If we're going to kill editing, we're going to need to get

    shepazu: we're not going to kill editing

    <Zakim>  Josh_Soref, you wanted to talk about passwords in Mameo5

    <heycam>  Josh_Soref: the other thing is that for Maemo 5 there was a
    time when the input method would warn everything you type into the

    <heycam>  ... including when you typed ssh passwords

    <heycam>  ... whatever random letters you type into the browser

    <heycam>  ... the solution was that IMEs were turned off entirely

    <heycam>  ... having access as a web page to things that I might
    type, e.g. if I'm on a form, all the completion things in the forsm
    -- I think Opera did a good job with the wand -- otherwise all your
    form information and CC numebrs would automatically be filled in

    ifette: we all agree there are potential security considerations to
    take into account


    scribe: we have a team from the tokyo office
    ... it's important for affected usrers


    shepazu: this isn't a place for technical feedback

    <darobin>  +1 to having IME

    sicking: that's fine

    chaals: is there an objection to adding this to the charter?

    sicking: before we were talking about seeing use cases before the

    chaals: you could cut it out during chartering

    sicking: i'd like to see use cases before committing to it
    ... if the use cases are editing and canvas

    ArtB: i think the charter is good until spring
    ... historically it takes a long time to get our charter added


    scribe: there's a 4 week AC review
    ... we need several weeks for WG discussion
    ... the earliest to the AC would be Jan or Feb

    chaals: is there any objection to not putting this in the charter
    ... given we would put it before the WG before the end of the year

    <dom>  shepazu, adding a link to
    [42]http://www.w3.org/2010/webapps/charter/ from
    [43]http://www.w3.org/2008/webapps/charter/ would be useful

      [42] http://www.w3.org/2010/webapps/charter/
      [43] http://www.w3.org/2008/webapps/charter/

    chaals: with an action on chairs to put it before the group
    ... ?

    shepazu: i'd rather it be in the Charter proposal
    ... given that it could be cut later

    mjs: i'd object
    ... i'd like to be informed enough about this
    ... it seems like that wouldn't take a lot of time

    adrianba: I agree with mjs

    ifette: there's so much time to object
    ... if you look over the use cases
    ... there's plenty of time to object
    ... I could list use cases
    ... there is a large class of users who are not well served by a
    number of sites
    ... everyone who is objecting
    ... yes, we could have done a better job of preparing our case
    ... but the objectors aren't affected

    mjs: i believe people should be required to present their case

    chaals: like mjs, i object the implications

    <weinig>  yes



    chaals: if you're willing to do the legwork
    ... it seems like we have 2 1/2 objections
    ... so it seems like you should do the legwork
    ... the concrete path forward is that we expect you to further
    motivate this proposal
    ... if you're prepared to put in the legwork
    ... around mid december
    ... so you give us material
    ... i'll take an action for Dec 1

    [ No Objections ]

    ACTION ifette to talk to people at google to get more support for
    the proposal

    <trackbot>  Created ACTION-631 - Talk to people at google to get more
    support for the proposal [on Ian Fette - due 2011-11-07].

    ACTION chaals to put IME in Charter on the discussion for Dec 1

    <trackbot>  Created ACTION-632 - Put IME in Charter on the discussion
    for Dec 1 [on Charles McCathieNevile - due 2011-11-07].

    <chaals>  Scribe: chaals

    <ArtB>  ACTION: barstow should XHR1 be published as a WG Note?
    [recorded in

    <trackbot>  Created ACTION-633 - Should XHR1 be published as a WG
    Note? [on Arthur Barstow - due 2011-11-07].


    AB: We're late, and may cut into the next item. Peter will update on
    protocol and IETF side, we'll look at other topics, testing, future

    PSA: Co-director of applications at IETF
    ... [quick explanation of IETF structure]
    ... HyBi WG is a group in my area. Between IETF/W3C we have had IETF
    doing protocols, W3C doing APIs. (generally)
    ... Hybi has been formalising web socket protocol, Hixie - Ifette -
    ... and extensions, sub-protocols, and so on
    ... Current status is sockets protocol has been approved after last
    call, is in queue to be published as RFC.
    ... Think we ha good coordination with W3C on the API.
    ... Think we want to try to coordinate better from IETF.
    ... Extensions - multiplexing, compression, are topics people have
    talked about.
    ... will come forward in the next few months. Also looking at
    sub-protocols - I come from Jabber/XMPP, and we want to have a
    sub-protocol to replace long polling, there are others.
    ... Once the API is finished I think we will get a lot of experience
    in the next few years, I foresee a cleanup version.

    IF: Maybe a few months...

    PSA: Maybe. I think we will need one at some point, anyway.

    AB: Last call for WS API ended about a week ago

    IH: 2 bugs closed, only 2 left.

    AB: First looks like editorial

    IH: Yep.

    AB: 14474 been discussed quite a bit, no?
    ... we could talk about it today. Julian submitted a comment, not
    exactly an objection. Some URL processing got deleted from spec,
    added to API - hixie can elaborate on that. We need to figure out
    whether it pushes us back to last call, along with closing the
    outstanding bug.

    JS: Sounds like MS is agreeing with 14474 - curious if google has

    IF: If browser sends close frame, and server has meesages in flight
    before it closes - do those messages get delivered?
    ... want to avoid half-duplex connections in protocol - one side can
    send but not receive. THe protocol doesn't address what happens
    here. Either answer would be OK (dump the messages or deliver them)

    JS: And messages in buffer etc...

    IF: Right. We just need to agree on what we decide.

    ??: COmments are in the bug, agree we should just decide one way -
    don't have two versions.

    IF: Agree.

    ??: We are in violent agreement.

    AB: Hixie, do you have what you need to close it?
    ... would that necessitate a last call?

    IF: Think it is a clarification not a change.

    ABate: agreed

    ArtB: outstanding issue is comment from JR:


      [45] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0244.html

    <stpeter>  Julian's comment was
    84.html ?

      [46] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0084.html

    [Robin waltzes in 30 minutes late]

    AB: Is this some kind of showstopper? Is the change substantive
    enough to go back to last call?

    IF: Original text was algorithmic parsing of URI. Got taken out of
    processing, but added into API spec. Question is whether a clear
    description of how to parse a URL is substantive

    MJS: SOunds like a good change, sounds substantive.

    <Josh_Soref>  s/SOunds/Sounds/

    IF: Didn't change behaviour, it is like a clarification of parsing a

    <stpeter>  Julian's message was "I just noted that as of yesterday,
    the API spec contains the custom URI

    <stpeter>  ... parsing algorithm that we removed from the protocol
    spec a long time ago."

    IF: doesn't change the browser, just trying to be clear on corner
    cases. Intent is to specify what browsers do, not change anything.

    MJS: reads "substantive change" from process...
    ... personally it sounds like a good change.

    CMN: Would you have expected to parse a URI differently? If not I
    don't think it is a substantive change.

    MJS: If you change the text, you might introduce a change.

    IF: If you did a review it seems that you would have read it in one
    place or the other. Doesn't seem like an actual change

    AvK: At best it is a 3-week difference. Do we need to argue one way
    or another?

    DS: Process is to get good reviw, and resolve difference of opinion.
    If people don't think there was harm, I don't think that the process
    requirement is active.

    MJS: Last call is for people outside the WG. The fact taht people
    here like it doesn't matter, it gives a fair opportunity to comment
    for people outside the WG.

    DS: Right. In this case it got moved from one place to another.

    <Josh_Soref>  +1 to MJS's note

    MJS: Sure, but it went from one organisation to another.

    <Josh_Soref>  s/taht/tat/

    <Josh_Soref>  s/tat/that/

    MJS: prefer in the case of doubt that we are clear we follow the
    process, rather than beng sloppy.
    ... being only a few weeks difference, it sounds like it won't
    change anyone's plans

    ABate: Sounds like no consensus to move to CR, another last call is

    RB: Operative word is reasonable, I don;t think there is reasonable
    doubt it would change anyone's review.

    DS: Think ths call is up to the chairs

    <Josh_Soref>  s/don;t/don't/

    <Josh_Soref>  s/ths/this/

    CMN: Anyone object moving through to CR, and claiming the change is
    not actually one that would materially affect a review?

    [no objection]

    RESOLUTION: We don't need to return to Last Call.

    <ArtB>  ACTION: barstow start a CfC to publish a CR of WebSockets API
    (after Hixie closes 14474) [recorded in

    <trackbot>  Created ACTION-634 - Start a CfC to publish a CR of
    WebSockets API (after Hixie closes 14474) [on Arthur Barstow - due

    ABate: Shipping implementation of WS we also submitted some test
    cases. To test, you need a websocket server - we have a temporary
    server hosted.
    ... getting that hosted by W3C and letting others build test that
    run on the server side seems essential. Can W3C / systems team
    figure out how we deliver that?

    <ArtB>  ACTION: barstow work with Chaals and the Team re
    infrastructure to test WebSockets API [recorded in

    <trackbot>  Created ACTION-635 - Work with Chaals and the Team re
    infrastructure to test WebSockets API [on Arthur Barstow - due

    s/deliver that/we get the server hosted by W3C/

    IF: You mean a server you could run internally?
    ... we have a python thing you could install and run.

    ABate: No firm criteria, people want to test the browser without
    having to run something locally, would be helpful if it could be
    hosted as well as people having to set up their own.
    ... Our current server is open source but we don't care much. Key
    thing is being able to support a server within W3C that people can
    write tests for.

    JG: Absolute requirement that we can run it internally.
    ... Also running on W3C server is fine. Think the security makes
    this a reasonably hard problem to solve because it has to be secure
    - pywebsocket is known not to be secure.

    DS: We'd have to check with systems team of course, I can ask

    DHM: Asked systems team. Main thing is to have something that we
    don't have a lot of maintenance for. I was imagining running a
    node.js server with sockets, limiting the maintenance required. That
    could fly, but we need a concrete thing to run and to check.

    ABate: So how do we move forward? We're not sur what we could
    propose, you're not sure what will be proposed...

    DHM: Need something open source, ideally something with maintenance

    ABate: Not sure we have that right now in a way that allows 3rd
    party submissions...

    <smaug>  uh, websocket CR o_O

    CMN: If someone has something, let's look at it and see whether it
    works for us.

    DS: Yeah, explain how to run it.

    KK: Right. People will test this - so if it isn't being run it isn't
    any good.

    IF: Yes, we need something we can run locally, but don't object to
    something running hosted.
    ... if we can run it, presumably it could be run externally too.

    JG: If running it externally turns out to be difficult, we could do
    without that.

    IF: Think we could figure that problem out. Let's try to make it

    JG: Right. make a decision on a framework so people can write tests
    sooner rather than later.

    IF: Don't hear disagreement, but not sure we will resolve right now
    which framework we'll use. Someone needs to come up with a

    <scribe>  ACTION: Kris to propose a framework for running testing.
    [recorded in

    <trackbot>  Created ACTION-636 - Propose a framework for running
    testing. [on Kris Krueger - due 2011-11-07].

    AB: Adrian, do you want to talk about future direction?

    ABate: not really.

    PSA: Seen proposed extensions for multiplexing and compression,
    heard number of people say this would be useful, so expect to see
    those but nothing concrete here.

    SW: Do you imagine it would be a non-backwards-compatibile change?

    IF: Imagine an extension that is negotiated - non-multiplexing
    client could talk to a multi-plexing server, althugh the server
    might refuse to answer as policy rather than protocol

    SW: Server could serve both ways?

    IF: Yes. Client sends handshake with capability, server can accept a
    connection that works, or reject it, without changing the base

DOM3 Events, DOM4

    <Josh_Soref>  Scribe: JonathanJ

    <Josh_Soref>  Scribe: Josh_Soref

    ArtB: Status of DOM3 Events
    ... a CFC for Candidate was made 3 weeks ago
    ... and ended
    ... with Ms2ger Objecting
    ... Ms2ger had 3 objections in his email


      [50] http://lists.w3.org/Archives/Public/www-dom/2011OctDec/0108.html

    shepazu: ...
    ... 1. issue 123
    ... - by anne

    <ArtB>  AB: here is the IRC log from Oct 25 (Art, Doug and Olli):

      [51] http://krijnhoetmer.nl/irc-logs/webapps/20111025

    <heycam>  s/123/123, which contradicts DOM4's statement that no new
    feature strings should be minted/

    shepazu: svg uses feature strings

    mjs: there's the whole substantial discussion about feature strings
    being a good or bad idea
    ... as far as the DOM spec's view of feature strings
    ... it only supports a fixed, non extensible set of strings
    ... if another spec wants to say that it modifies what that spec
    ... it could

    shepazu: one could argue that what DOM4 says is violating what DOM3

    jrossi2: I agree that this i

    s/this i/this is/

    scribe: strange
    ... i gave personal feedback against removing this from the platform

    anne: among most people, feature strings seem to be a bad idea
    ... you can claim to support a feature by claiming to support a
    ... but not actually support a feature
    ... a feature can be composed of multiple parts
    ... and you can only implement some of them
    ... whereas feature detection is robust against this

    chaals: I agree that feature strings as used by DOM are a failure
    ... i'm not so sure that the DOM spec should throw out the ability
    to define them

    <smaug>  there is no robust feature detection for events

    [ scribe lost the correct wording and used robust instead ]

    scribe: and even if DOM throws these functions out and washes its
    hands of it
    ... it doesn't ...
    ... "you MUST not" is a whole nother ball of wax

    anne: as a group, we agree that we shouldn't do this
    ... but, where else would we put it

    [ scribe is not catching full text, sorry ]

    shepazu: i don't think we made this RESOLUTION
    ... as editor of the DOM3 spec, I don't think I was informed of this

    Marcos: let's do it now!

    shepazu: we don't make decisions in ... [cut off]
    ... one of the reasons that they haven't been successful in the past
    ... is that they weren't fine grained

    anne: so you have to make them more complex?

    shepazu: i didn't say complex, i said precise

    mjs: if we make them sufficiently precise, you might as well use
    feature detection

    jgraham: what's the technical reason for this

    <smaug>  jgraham: there is no good way to feature detect events

    anne: if event objects are forced to be exposed by webidl

    mjs: it's better if events ....

    <smaug>  that is event objects, not event types

    <anne>  burn the witch!

    mjs: it's better to burn feature strings to the ground

    weinig: historically, in our implementation, we have not been very
    good at keeping feature strings matching our implementation

    alexr: i want to second that


    shepazu: i'm not going to fight the issue
    ... we can remove them
    ... jrossi2 : you have the implementation of this

    jrossi2: I don't know that it harms the implementation
    ... the extended implementation
    ... we've seen some compat issues, in terms of consumers
    ... i think jQuery uses it

    anne: i do not, and never have proposed, support removing older

    [ the dom4 spec just freezes the old list ]

    mjs: to get out of this philosophical issue of whether dom4 can tell
    what other specs say
    ... we could define the functions to return true for a specific list
    of strings
    ... [ which effectively removes any relation of the feature to the
    function ]

    jrossi2: it could be marked as AT-RISK
    ... and discussed on the list

    anne: it seems easier to remove

    shepazu: no, that would require another LC

    mjs: you can remove features marked as AT-RISK without going back to
    ... it sounds like there's sufficient resistance to this feature
    ... to prevent this group from formally going to CR
    ... because the group doesn't support the feature

    shepazu: I'm fine with removing them if jacob is fine with removing

    jrossi2: if that's considered a substantial change which would force
    us to go to LC, then i'd object

    shanec: Issue 2

    [ shepazu reads from the objections ]


    <ArtB>   Issue 2 is "Second (issue 179), it ignores the consensus
    about using DOMException instead of custom exception types like
    EventException, as noted in WebIDL, [$1\47] which I reported.

    anne: mozilla already removed EventException

    sicking: we have not removed it
    ... we were planning on it

    heycam: window.EventException does not exist in my nightly build

    jrossi2: the new exception type was brought up prior to the LC
    ... before the consensus of how to move forward
    ... and we found them useful
    ... since then the feedback that our resolution was incompatible
    with that
    ... was after the LC

    anne: that was on a call with few members
    ... and I sent comments on them
    ... and they were not addressed for months

    chaals: can we stop arguing about process, unless we have a formal
    objection on process

    anne: i think it matters on how we develop drafts

    chaals: yes it matters, and in particular, the chairs allowed the
    editors to screw up
    ... the question is whether there's a technical reason to fix what
    came out of the process

    sicking: if the D3E spec is specifying an exception type which we
    don't implement
    ... i'd object to that
    ... i'd imagine that other implementations feel that way

    jrossi2: there's already some implementations implementing it

    <smaugN900>  we did implement that exception type

    jrossi2: there are at least 2 interoperable impls

    <smaugN900>  but we moved to dom 4 exceptions

    jrossi2: DOM4 is free to evolve that idea

    sicking: i'm not convinced if 2 browsers have implemented it
    ... what matters is what all browsers can implement

    jrossi2: i think that web developers care about previously shipped

    mjs: if we agree to remove it later
    ... over time
    ... then codifying it will make it harder
    ... because people will complain that browsers are incompatible

    <smaugN900>  also, I thought it was agreed that D3E will use dom4
    exception type.

    heycam: given that D3E is not using WebIDL
    ... i don't think there's a normative way to detect this

    anne: constants

    heycam: number 2, it's not useful
    ... it's unlikely that users would .name = eventexception
    ... i wonder if content use this
    ... and checking that code relies on it

    [ scribe repeats what smaugN900 said for the room ]

    anne: there's a desire to get D3E to REC
    ... people working on D3E want to get to things to REC and generally
    agree with the direction it's going
    ... but some are concerned about time target

    jrossi2: shepazu do you recall us changing?

    shepazu: i don't care at this point
    ... it doesn't matter, it shouldn't affect anything
    ... except possibly script libraries

    <ArtB>  Jacob, here is the IRC log from the call I had with Doug and
    Olli: [52]http://krijnhoetmer.nl/irc-logs/webapps/20111025

      [52] http://krijnhoetmer.nl/irc-logs/webapps/20111025

    sicking: which browsers have shipped this, and for how long?

    anne: only one that ...

    weinig: I think WebKit has been shipping it for many many years

    jrossi2: I think WebKit and IE and I thought Opera had passed the
    test case

    shepazu: the final thing is WebIDL
    ... i'd like to have heycam speak to how long before WebIDL is
    stable.. i.e. to REC

    heycam: how many recommendations do you have?
    ... to get to rec, you need test suites, and passing implementations

    shepazu: regarding normative, instead of informative
    ... i'd suggest we go to CR
    ... and if WebIDL makes faster progress

    <heycam>  s/recommendations do you have/requirements are there in the

    shepazu: I don't want to make D3E gate on WebIDL

    jgraham: regarding testing
    ... some things have a tendency to rely on WebIDL

    anne: how can you not define the binding to JS and still test it?

    <smaugN900>  (I think there are still quite a few open webidl spec
    bugs. and more coming when it is being implemented.)

    shepazu: i think we should try to go with what we have
    ... and see how far we go
    ... i think a snapshot is useful
    ... there are plenty of test suites that do not use webidl

    jgraham: there's not a great tradition of test suites

    anne: those specs defined a binding

    Marcos: i want to second just about everything that anne is saying
    ... webidl defines a bunch of stuff

    <heycam>  Presumably Anne is thinking of something like

      [53] http://www.w3.org/TR/DOM-Level-2-Events/ecma-script-binding.html.

    Marcos: it defines how to implement everything
    ... and i can generate tests from it

    shepazu: we have 2 passing implementations
    ... is it less useful to have D3E actually out there
    ... pushing forward on the keyboard model
    ... i think it's much more useful to have a keyboard model than some
    actual architecture astronaut

    Marcos: it's rhetorical
    ... what's the aim of the spec

    shepazu: by going to CR, we can get more implementations of those

    Marcos: the implementers at the table, saying we don't like how it's
    ... we want it in WebIDL

    shepazu: does everyone agree that it's more important to have it in

    <smaugN900>  marcos: really?

    chaals: who thinks we should not go forward before D3E normatively
    references WebIDL

    mjs: scanning over the normative idl in the spec
    ... and non-normatively in webidl
    ... they seem to define different behaviors
    ... that makes me uncomfortable

    jrossi2: that's a great bug to file

    chaals: who thinks we should go forward with this without making
    webidl a normative requirement
    ... jrossi2 and shepazu against, and everyone else with an opinion
    of waiting on webidl
    ... which was a fairly broad collection

    shepazu: as a point of order

    <smaugN900>  that is ok

    shepazu: i believe we have 2 implementations passing most of the

    s/that is ok//

    scribe: and i believe in short order that we will have 2
    implementations for all

    sicking: i think all of the time that when all of the vendors have
    said we will not go forward
    ... that we have not gone forward
    ... i can't think of any times when even one has said no that we've
    moved forward

    mjs: in general, we don't move to CR without support

    chaals: i think the general sense has been that we want to move
    forward with specs that everyone will implement
    ... i think getting D3E to REC would be useful
    ... getting another spec that isn't finished
    ... would be bad

    s/.. getting/... getting/

    chaals: i agree with mjs, i don't see a requirement that this group
    be consistent in its processes
    ... i would object to any formal requirement that everything be
    agreed by everybody
    ... i think it's a good rule of thumb
    ... as chair, the job is to get consensus
    ... and it seems we don't have a consensus to go forward without
    ... sometimes we need to acknowledge that we are not that good at
    achieving our goals

    jeff: is there a plan to get webidl as normative?

    chaals: one of the things is waiting until WebIDL is done

    shepazu: we have an informative WebIDL reference
    ... it's just a matter of making it normative

    <smaugN900>  does that mean that we give up with D3E and move to D4E?

    shepazu: and then waiting for WebIDL to be `done`

    heycam: how much done do you need?
    ... what's the comparison in times between WebIDL and D3E?

    dom: processwise, if D3E depends on WebIDL
    ... then D3E can't go to REC without WebIDL done
    ... we have special rules for HTML

    shepazu: that's not in the process documentation
    ... it's a policy
    ... it's somewhat of a catch-22
    ... at what level of webidl implementations can we have to get it to
    move forward

    <dom>  [the policy enacts a director decision, so it's as powerful as
    the process document afaik ]

    shepazu: i'm fine with making changes to the admin exceptions

    <heycam>  s/admin/event/

    shepazu: i'd like a bounded requirements on the specifications
    ... it sounds like we're going back to LC

    anne: some of these issues were raised pretty early on
    ... as in March

    shepazu: that's not very early on

    jeff: what does the dependency on webidl look like?
    ... i didn't get an answer

    chaals: i think the answer we got
    ... is that if we make it dependent on webidl
    ... we don't have an expectation that webidl is racing along to
    ... shepazu suggests there are a small number of issues before D3E
    can go to CR
    ... if it is held up by WebIDL, then that could be a very long wait
    in CR
    ... we may ask the Director to wave the convention
    ... we're going to put WebIDL specs through to REC
    ... because we need specs out there to get WebIDL done
    ... although he generally doesn't want to use that authority
    ... an exception has been granted for HTML5

    anne: what's being missed by your comment

    <smaugN900>  (so assuming webidl is stable late next year, D3E could
    be rec in 2014)

    anne: is that currently it doesn't define JS bindings

    <smaugN900>  er 2013

    anne: WebIDL defines a language and the binding from that language
    to javascript

    jeff: smaugN900 's answer answers my question

    jgraham: since WebIDL defines a semantic
    ... and since browsers implement in terms of WebIDL
    ... it seems like not claiming to rely on WebIDL is a lie

    heycam: the number of most recent LC comments was 15
    ... and most are pretty simple
    ... the comments could be resolved in a month or two

    mjs: so less than a year to get to CR?

    heycam: so LC if we make normative changes
    ... and then 3 months and then CR

    mjs: so, optimistically?

    heycam: the big time bit is moving from CR to REC
    ... it's getting implementations

    sicking: are there specifications that use "all" of the features of

    mjs: for each webidl feature, is there at least one spec using it?

    Josh_Soref: is there at least one W3 spec for each WebIDL feature?

    heycam: there is a feature which we'd probably drop that wouldn't

    s/wouldn't/is only used outside/

    chaals: if we take the RESOLUTION that we make those changes and
    send it back to LC
    ... and send it through with the statement that D3E would be LC
    specifically scoped to those changes

    sicking: does that include deprecating the EventException interface?

    chaals: yes, all three changes

    anne: i guess it's ok
    ... but there are various minor comments raised
    ... and i'm not sure how they were addressed relating to DOM4
    ... initEvent


    scribe: there's something which is prohibited, although jackal said
    it might be allowed if you interpret the spec in an interesting way

    ojan: my general experience w/ D3E
    ... is that the push to get it to REC has generally trumped
    technical issues
    ... it's hard to retroactively make it good
    ... i'd rather consider it a sunk cost
    ... and just look toward DOM4

    shepazu: are you talking about new features, or the way things are
    actually specified currently
    ... i know i said i wasn't adding new features

    ojan: not adding new features is totally ok

    chaals: so you're supporting anne in not being certain about other
    little things

    <smaugN900>  (DOM4Events, not just DOM4)

    Marcos: i've also tried implementing things from D3E
    ... and i've had to fall back to DOM4
    ... there's good bits in the spec, but i think it's overreaching
    ... the stuff that anne 's done in DOM4
    ... he's make the event dispatch really clear
    ... the mouse/keyboard stuff is great
    ... the web is going to be underpinned by DOM4 and WebIDL

    chaals: if as chairs

    <smaugN900>  if event dispatch is not clear in D3E, please file a bug

    chaals: we proposed to make an LC with only the new changes
    ... are there people who would object

    mjs: i would object because i don't think the process supports that

    chaals: there's precedent

    shepazu: it doesn't disallow it

    chaals: i don't want a question, just a technical objection

    sicking: are there things where D3E is in direct opposition to what
    DOM4 says?

    shepazu: in D3E we tried to match what implementations did

    anne: but you didn't

    jrossi2: the initEvent is the only other thing i've ever seen

    anne: if you create an event, what does event.type return?

    chaals: we should leave it undefined until DOM4

    sicking: i don't want to run into issues doing DOM4 because it
    conflicts we things D3E says

    shepazu: D3E is generally a subset of DOM4

    anne: there are some contradictions
    ... initEvent, things that are not defined

    chaals: things that are not defined is not a contradiction

    sicking: i'm not worried about undefined
    ... just things that it does say which contradicts what it actually
    does say

    Marcos: we can't just do levels/errate


    <smaugN900>  (I think I.ve missed what is wrong with initEvent)

    chaals: option 1: we go forward with the spec, making the 3 changes
    outlined in the 3 issues
    ... and moving forward based on that
    ... restricting the LC scope to that
    ... there are 3 4 objections

    s/3 4/3 ... 4/

    chaals: are there objections to:
    ... we will go through and open an LC with an open scope
    ... and with an explicit plan that we will
    ... that any further LC will be restricted
    ... and we expect to move forward
    ... are there objections - One open LC and one further limited to
    issued raised in that LC
    ... there is precedent to that, not in this group, but in others

    mjs: i'm dubious, but i don't object

    chaals: does anyone expect that they're going to keep saying "no,
    no, no"

    Marcos: it's not a bad spec
    ... it's just there's too much conflict between two specs

    <smaugN900>  what are the conflicts

    chaals: i'm going to table that question

    <smaugN900>  one exception type

Widgets v2


    AlexRussel: there is a v3/v4 tension

    jrossi2: there's a lot in D3E events which is not really for DOM4

    AlexRussel: and there's a question of dropping D3E

    ArtB: looking at the Agenda
    ... is this the 9-11 slot?

    shepazu: you mean when i'm @WebEvents?

    ArtB: how about 10?

Widgets v2

    ArtB: Web Application Packaging v2

    Marcos: I don't remember proposing tihs
    ... i'm not going to waste people's time here
    ... given the workshop on saturday
    ... i think that will determine if we'll have a v2
    ... i'm happy to listen to requirements
    ... thanks everyone

    ArtB: any other comments?

    Josh_Soref: i'm unhappy with the day being Saturday

    [ Adjourned ]

    RRSAgent: make minutes

    trackbot: end telcon

Summary of Action Items

    [NEW] ACTION: Art to talk to Doug about the traversal from Element
    Traversal to DOM4 [recorded in
    [NEW] ACTION: barstow should XHR1 be published as a WG Note?
    [recorded in
    [NEW] ACTION: barstow start a CfC to publish a CR of WebSockets API
    (after Hixie closes 14474) [recorded in
    [NEW] ACTION: barstow work with Chaals and the Team re
    infrastructure to test WebSockets API [recorded in
    [NEW] ACTION: Kris to propose a framework for running testing.
    [recorded in

    [End of minutes]
Received on Tuesday, 1 November 2011 14:05:41 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:36 UTC