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

Re: Draft Minutes: 31 October 2011 f2f meeting

From: Eric U <ericu@google.com>
Date: Wed, 2 Nov 2011 09:02:13 -0700
Message-ID: <CAHvSExczj6BUfmJDmRBbLA5NeoLwJTwazDZFdSVZ7s+vu4WgmQ@mail.gmail.com>
To: Arthur Barstow <art.barstow@nokia.com>
Cc: public-webapps <public-webapps@w3.org>
On Tue, Nov 1, 2011 at 7:05 AM, Arthur Barstow <art.barstow@nokia.com> wrote:
> The DRAFT minutes from the October 31 f2f meeting are in the following
> document and copied below:
>
> http://www.w3.org/2011/10/31-webapps-minutes.html
>
> 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.
>
> -AB
>
>   [1]W3C
>
>      [1] http://www.w3.org/
>
>                               - DRAFT -
>
>                         WebApps f2f Meeeting
>
> 31 Oct 2011
>
>   [2]Agenda
>
>      [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
>
> Attendees
>
>   Present
>          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
>
>   Regrets
>   Chair
>          Art_Barstow, Charles_McCathieNevile
>
>   Scribe
>          Art, Josh_Soref, chaals, JonathanJ
>
> Contents
>
>     * [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
>   tomorrow
>   ... 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 ...
>
>   <chaals>
>   [24]http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/16
>   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
>
>   <Ms2ger>
>   [25]http://dvcs.w3.org/hg/webapps/raw-file/b941da0491a8/api-design/O
>   verview.html
>
>     [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
>   list)
>   ... -- and File API
>   ... Stream API and File API - 10
>
>   <Ms2ger>
>   [26]http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/05
>   77.html?
>
>     [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/05
>   77.html
>
>     [27]
> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0577.html
>
>   /
>
>   ArtB: proposal by bryan to add a slot for server sent event
>   extensions
>   ... Server Sent Event Extensions - 4
>
>   [ Scribe takes a break while ArtB resequences things on screen
>   unsaved in Wiki TPAC2011 ]
>
>   [ ArtB commits Schedule to Wiki --
>   [28]http://www.w3.org/2008/webapps/wiki/TPAC2011#Agenda_Monday.2C_Oc
>   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
>   [30]http://www.w3.org/2011/10/31-webapps-minutes.html#action01]
>
>   <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
>   stuff
>
>   chaals: we expect it to change
>
>   <smaug>  (ah, sicking is talking)
>
>   jonas: we have plans
>
>   macie: apple has plans

This was actually Jonas and Maciej saying that Mozilla and Apple have
no plans to implement FileSystem, but that they do like FileWriter,
IIRC.

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

Anne spoke for Opera, not Apple.

>   <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]
>
> CORS
>
>   [ 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
>
>     [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
>   Foundation).
>
>   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
>   algoritm
>   ... that's a bug in the fonts spec, it doesn't reference the fetch
>   algorithm
>
>   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?
>
>   <chaals>
>   [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
>   variables
>   ... 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
>   embedder
>   ... 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
>   channel
>   ... 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
>   data
>   ... 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
>   embedding/reading
>   ... 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
>   it
>
>   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
>   From-Origin
>   ... 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
>   through
>   ... 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&compone
>   nt=Access+Control&longdesc_type=allwordssubstr&longdesc=&bug_file_lo
>   c_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordss
>   ubstr&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
>
>     [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
>   important
>
>   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
>   resources
>   ... 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
>   protocols
>   ... 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
>   http
>   ... 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
>
>   s/..../.../
>
>   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
>   mentioned
>
>   <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
>
>     [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//
>
> Charter/Rechartering
>
>   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
>   shortly)
>
>   [ 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
>   group?
>
>   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
>   interested
>   ... 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.
>
>   s/2./2.0/
>
>   scribe: people do use things offline and do want to install them
>   offline
>   ... it comes back to, i hope we have a coherent discussion on
>   Saturday
>   ... 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
>   ways
>   ... 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
>   chartering
>   ... 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
>   Widgets
>
>   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
>   group.
>
>   jgraham: relating to device interaction
>   ... I agree those will happen
>
>   <tantek>  without UX being nailed first, intents is pretty much
>   doomed
>
>   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
>   not.
>
>   <ifette>  s/jgraham/jhawkins/
>
>   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
>
>   s/MarkV/mav/
>
>   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
>   Apps
>   ... 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
>   similar
>
>   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
>   charter?
>   ... 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
>   charter?
>
>   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
>   Apps
>   ... we would likely to formally object
>
>   RESOLUTION: No objection to adding Web Intents to the Web Apps
>   Charter
>
> 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
>   formed
>   ... 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
>
>     [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"
>
> Charter/XHR
>
>   <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
>   done
>   ... 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
>   tests
>
>   <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
>   implementation
>
>   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
>
>   s/../.../
>
>   scribe: but since XHR1 and XHR2 define events [or similar?]
>   differently
>   ... 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
>   work?
>   ... 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
>
> Charter/Editing
>
>   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
>   item?
>
>   <smaug>  #whatwg: AryehGregor "Microsoft Corp. has joined the HTML
>   Editing APIs Community Group"
>
>   chaals: I am proposing that we reject Editing APIs under similar
>   circumstances
>   ... 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
>   there
>
>   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
>
> Charter/IME
>
>   MikeSmith: if you type on a computer in Japanese/Chinese, and to
>   some extent Koreans
>
>   s/Koreans/Korean/
>
>   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
>   browser
>   ... 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
>   IMEs
>   ... 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
>
>     [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
>   do
>   ... 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
>   access
>
>   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
>   xterm
>
>   <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
>
>   s/numebrs/numbers/
>
>   scribe: we have a team from the tokyo office
>   ... it's important for affected usrers
>
>   s/usrers/users/
>
>   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
>   charter
>
>   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
>
>   s/added/updated/
>
>   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
>   now
>   ... 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
>
>   s/mjs/weinig/
>
>   s/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
>   [44]http://www.w3.org/2011/10/31-webapps-minutes.html#action02]
>
>   <trackbot>  Created ACTION-633 - Should XHR1 be published as a WG
>   Note? [on Arthur Barstow - due 2011-11-07].
>
> Websockets
>
>   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
>   directions...
>
>   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 -
>   Alexey...
>   ... 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
>   opinion.
>
>   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:
>
>   <krisk>
>   [45]http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/02
>   44.html
>
>     [45]
> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0244.html
>
>   <stpeter>  Julian's comment was
>   [46]http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/00
>   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
>   URI
>
>   <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
>   appropriate.
>
>   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
>   [47]http://www.w3.org/2011/10/31-webapps-minutes.html#action03]
>
>   <trackbot>  Created ACTION-634 - Start a CfC to publish a CR of
>   WebSockets API (after Hixie closes 14474) [on Arthur Barstow - due
>   2011-11-07].
>
>   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
>   [48]http://www.w3.org/2011/10/31-webapps-minutes.html#action04]
>
>   <trackbot>  Created ACTION-635 - Work with Chaals and the Team re
>   infrastructure to test WebSockets API [on Arthur Barstow - due
>   2011-11-07].
>
>   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
>   them...
>
>   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
>   process...
>
>   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
>   happen.
>
>   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
>   submission.
>
>   <scribe>  ACTION: Kris to propose a framework for running testing.
>   [recorded in
>   [49]http://www.w3.org/2011/10/31-webapps-minutes.html#action05]
>
>   <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
>   protocol.
>
> 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
>
>   <ArtB>
>   [50]http://lists.w3.org/Archives/Public/www-dom/2011OctDec/0108.html
>
>     [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
>
>     [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
>   says
>   ... it could
>
>   shepazu: one could argue that what DOM4 says is violating what DOM3
>   says
>
>   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
>   feature
>   ... 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
>
>   s/alexr/slightlyoff/
>
>   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
>   elements
>
>   [ 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
>   LC
>   ... 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
>   them
>
>   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 ]
>
>   s/shanec/shepazu/
>
>   <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.
>   [$1\47]"
>
>   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
>   implementations
>
>   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
>   spec/
>
>   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
>   .
>
>     [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
>   features
>
>   Marcos: the implementers at the table, saying we don't like how it's
>   written
>   ... we want it in WebIDL
>
>   shepazu: does everyone agree that it's more important to have it in
>   WebIDL?
>
>   <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
>   items
>
>   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
>   webidl
>   ... 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
>   webidl
>   ... 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
>   WebIDL?
>
>   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
>
>   s/../.../
>
>   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
>
>   s/errate/errata/
>
>   <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
>
> D3E
>
>   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
>   [54]http://www.w3.org/2011/10/31-webapps-minutes.html#action01]
>   [NEW] ACTION: barstow should XHR1 be published as a WG Note?
>   [recorded in
>   [55]http://www.w3.org/2011/10/31-webapps-minutes.html#action02]
>   [NEW] ACTION: barstow start a CfC to publish a CR of WebSockets API
>   (after Hixie closes 14474) [recorded in
>   [56]http://www.w3.org/2011/10/31-webapps-minutes.html#action03]
>   [NEW] ACTION: barstow work with Chaals and the Team re
>   infrastructure to test WebSockets API [recorded in
>   [57]http://www.w3.org/2011/10/31-webapps-minutes.html#action04]
>   [NEW] ACTION: Kris to propose a framework for running testing.
>   [recorded in
>   [58]http://www.w3.org/2011/10/31-webapps-minutes.html#action05]
>
>   [End of minutes]
>
>
>
>
>
Received on Wednesday, 2 November 2011 16:03:12 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:48 GMT