- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Tue, 01 Nov 2011 07:05:00 -0700
- To: public-webapps <public-webapps@w3.org>
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
anne: I think apple's position is more in line with the last two
<weinig> Josh_Soref: I'm not weinig, Sam Weinig
eric: File Saver ...
ArtB: From Origin header ...
... what's the implementation status?
anne: I don't think anyone has implemented it
ArtB: Progress Events ...
anne: I think the main thing blocking implementations is Constructor
... I guess WebKit has that
... it's fairly simple (just properties/methods) since dispatch is
covered in other specs
jonas: we haven't started on constructors, since it's non trivial
... probably somewhat soon, but next year
anne: similar for us
... it's easier but not a priority
ArtB: Selectors
... it's blocked by WebIDL
Josh_Soref: is WebIDL going to be a topic
ArtB: there's a slot available and heycam is sitting next to you :)
... Server Sent Events
... when I left Boston, we were down to 0 bugs
anne: it doesn't cover Cross Origin
...
... It's going to get another argument in the constructor to cover
cross origin
ArtB: the main thing is that changes are coming, so it doesn't make
sense to go to LC
... WebIDL
... it had LC2
<chaals> s/to cover cross cross origin/to cover cross origin and
opting in to credentials exchange/
heycam: there are some non controversial issues
... and then a question of whether it should be less non JS specific
ArtB: we have a slot for tomorrow at 4
<anne> EventSource will get the same cross-origin story as
XMLHttpRequest basically
<anne> is what I said
<anne> and everyone is on board, change just needs to be made (well
everyone that voiced an opinion)
ArtB: PostMessage
... Web Workers
... Marcos: widgets...?
... widget interface is blocked by webidl and webstorage
... i think W3 Team has agreed on changes to pub reqs re:HTML5
... WARP had been stalled ... PAG has been active recently, and
there's reason to believe that the PAG will conclude relatively soon
[ Marcos gives a summary ]
dom: is there an eta for the report?
Marcos: shortly after TPAC, it needs a bit of clean up
chaals: there is a draft
ArtB: DigSig (for Widgets)
... that spec is in PR, it's blocked by XML Sec PAG
... Widget URI moved back to WD in September
Marcos: trying to align it with File API... responding as a fake
http server
... hopefully it'll have fairly similar behavior
... and move to LC
ArtB: View Mode media feature is in PR
... and will move to Rec when Media Queries advances to PR
... Widget Updates
[ Break until 10:30a ]
<Ms2ger> 10:30
<dom> glazou has joined #webapps
<Ms2ger> Not 11 either, apparently
[ We're about to resume ]
ArtB: we have 3 or 4 WGs here
... ask that observers make room around the table for WG members
[ ArtB introduces ]
<dbaron> [joint meeting of Web Apps, Web App Security, Web Fonts,
and CSS]
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 Tuesday, 1 November 2011 14:05:41 UTC