- From: Eric U <ericu@google.com>
- Date: Wed, 2 Nov 2011 09:02:13 -0700
- 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 UTC