See also: IRC log
<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? :)
<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 ]
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> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1666.html -> Storage quota API
ArtB: -- Robin had put together a rough outline
ArtB: API Design - 16
... Stream API proposal (from Microsoft, that Adrian sent to the list)
... -- and File API
... Stream API and File API - 10
ArtB: Index DB - 5
<bryan> Proposal for discussion of server-sent events extension for connectionless push support: 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 -- 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
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 ]
DRAFT ACTION: Barstow work with Doug
<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 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
... 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
... 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
... 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
... 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
... 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)
... 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
... and will move to Rec when Media Queries advances to PR
... Widget Updates
[ Break until 10:30a ]
<dom> glazou has joined #webapps
<Ms2ger> Not 11 either, apparently
[ We're about to resume ]
ArtB: we have 3 or 4 WGs
... ask that observers make room around the table for WG members
[ ArtB introduces ]
<dbaron> [joint meeting of Web Apps, Web App Security, Web Fonts, and CSS]
[ ArtB introduces the groups who have dependencies on CORS ]
vladimir: It started with the
development of the Web Open Font Spec
... when same origin was selected
... but the comment was made that it isn't specific to Web Font
... and it was suggested to make the Same Origin specification be made on a link specific basis
... The requirement was marked as at-risk
... and moved toward CSS
<anne> same-origin policy
<anne> From-Origin header
<ArtB> From-Origin spec: 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
... 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?
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
Marcos: do you have specs that use it?
<chaals> http://www.w3.org/TR/cors/#cors-api-specification-advice -> advice on using CORS in other specs
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
... 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
... 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
... is whether an embedded resource
dbaron: the argument jonas made is that every time we tried to make that distinction, we've failed
tab: right, can we say "embedding
... because we've failed each and every time we've tried
... 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
... the non visual elements are easily maskable
vladimir: the way i understand
... 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
... 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
... 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
... are both CORS and From-Origin is in where?
ArtB: CORS is a joint from
... From-Origin is in WebApps only
... I saw Brad walk in
clilley: follow up, where are the
issue lists for these specss?
BradL: CoChairing Web Apps Sec
... 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: 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
... 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: 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
... 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?
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
... 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
... 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
... 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
... 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
... 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
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
... 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
... 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
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 ]
<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)
<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
<heycam> s/Topic: animations [cont'd]//
<Ms2ger> The Return of the Josh
<Ms2ger> dom, I hear you're needed
<MikeSmith> ArtB, http://dvcs.w3.org/hg/ime-api/raw-file/tip/Overview.html
s/present +stpeter/present+ stpeter/
<stpeter> Josh_Soref: thanks
<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
... 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
... 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
... 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
... 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
... 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.
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
... 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
... 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 ]
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
jgraham: this is a short term
... 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
... 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
... 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
... 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
... I agree those will happen
<tantek> without UX being nailed first, intents is pretty much doomed
jgraham: the way that the api is
... 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.
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
MarkV: Part of the reason we're interested
scribe: Comcast and Cable
... and Webinos have proposals
... It's in the charter of DAP currently
... it may be more appropriate here
... 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
... 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
... 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 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
... 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
... 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
... 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
... 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
darobin: the general process of
... 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
... 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 ]
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
... 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
<anne> euh used to be called "Mutation Events"
ArtB: from the perspective of the
... 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
... 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"
<dom> s/the dom/the DOM/
<MikeSmith> rniwa, http://dvcs.w3.org/hg/ime-api/raw-file/tip/Overview.html
RESOLUTION: add "monitoring changes to the DOM and how they happen" to the charter"
<rniwa> MikeSmith: thanks
anne: basically everyone is
focusing on XHR2
... I don't think that it makes sense to maintain version 1
... the effort far exceeds any imaginable benefit
... no one is focused on getting it finished
adrianba: I agree with anne on
this specific case
... I'd like to avoid setting a precedent
... but for this case, I think it makes sense to stop working on level 1
sicking: I don't have a specific
... but I would kind of like to see it shipped
... if we could do that in a short order
anne: Last summer, summer of
... 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: 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
... 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)
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
... the problem is you don't have implementations or people willing to do testing
anne: comments still come
... for instance defining Garbage Collection
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
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
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
... 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
<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
... as someone from the SVG WG, i'd like to see this in the group that works on DOM
ACTION shepazu to ask the SVG WG for editors
<trackbot> Created ACTION-630 - Ask the SVG WG for editors [on Doug Schepers - due 2011-11-07].
RESOLUTION: Add Parsing and Serialization to Charter
ArtB: I know Aryeh was working on
... 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
... 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
... and I had a generic item related to work mode
MikeSmith: I was hoping ifette was going to be here
MikeSmith: if you type on a computer in Japanese/Chinese, and to some extent Koreans
scribe: You type in Latin, and
then you press a (compose) key to convert the text into a final
... 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: http://dvcs.w3.org/hg/ime-api/raw-file/tip/Overview.html
chaals: given two google
... 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
... 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
scribe: we have a team from the
... it's important for affected usrers
shepazu: this isn't a place for technical feedback
<darobin> +1 to having IME
sicking: that's fine
chaals: is there an objection to adding this to the charter?
sicking: before we were talking about seeing use cases before the 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
... historically it takes a long time to get our charter added
scribe: there's a 4 week AC
... 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
chaals: with an action on chairs
to put it before the group
shepazu: i'd rather it be in the
... 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
... 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
chaals: if you're willing to do
... 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 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].
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
... [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
AB: 14474 been discussed quite a
... 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.
??: 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.
ArtB: outstanding issue is comment from JR:
<stpeter> Julian's comment was 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.
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"
... 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.
MJS: prefer in the case of doubt
that we are clear we follow the process, rather than beng
... 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
CMN: Anyone object moving through to CR, and claiming the change is not actually one that would materially affect a review?
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 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 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
... 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
... 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 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.
<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
... 1. issue 123
... - by anne
<ArtB> AB: here is the IRC log from Oct 25 (Art, Doug and Olli): 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
... 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/
... 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
... as editor of the DOM3 spec, I don't think I was informed of this
Marcos: let's do it now!
shepazu: we don't make decisions
in ... [cut off]
... one of the reasons that they haven't been successful in the past
... is that they weren't fine grained
anne: so you have to make them more complex?
shepazu: i didn't say complex, i said precise
mjs: if we make them sufficiently precise, you might as well use feature detection
jgraham: what's the technical reason for this
<smaug> jgraham: there is no good way to feature detect events
anne: if event objects are forced to be exposed by webidl
mjs: it's better if events ....
<smaug> that is event objects, not event types
<anne> burn the witch!
mjs: it's better to burn feature strings to the ground
weinig: historically, in our implementation, we have not been very good at keeping feature strings matching our implementation
alexr: i want to second that
shepazu: i'm not going to fight
... 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
... 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
... 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 ]
<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,  which I reported. "
anne: mozilla already removed EventException
sicking: we have not removed
... 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
... 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
... 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
... i don't think there's a normative way to detect this
heycam: number 2, it's not
... 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
... 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
... 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: 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
... 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 http://www.w3.org/TR/DOM-Level-2-Events/ecma-script-binding.html.
Marcos: it defines how to
... and i can generate tests from it
shepazu: we have 2 passing
... 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
... 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
... 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
... 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
... 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
... 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
... what's the comparison in times between WebIDL and D3E?
dom: processwise, if D3E depends
... then D3E can't go to REC without WebIDL done
... we have special rules for HTML
shepazu: that's not in the
... 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
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
... 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
jeff: smaugN900 's answer answers my question
jgraham: since WebIDL defines a
... 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
... 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
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/
... 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
... 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
... initEvent, things that are not defined
chaals: things that are not defined is not a contradiction
sicking: i'm not worried about
... just things that it does say which contradicts what it actually does say
Marcos: we can't just do levels/errate
<smaugN900> (I think I.ve missed what is wrong with initEvent)
chaals: option 1: we go forward
with the spec, making the 3 changes outlined in the 3
... 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
... 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
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?
ArtB: Web Application Packaging v2
Marcos: I don't remember
... 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
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/I think// Succeeded: s/12/13/ Succeeded: s/Zakim: [IPcaller] is Olli_Pettay// Succeeded: s|/me thanks Ms2ger || FAILED: s|!/me thanks Ms2ger !!|| Succeeded: s/s!!!// Succeeded: s/me thanks Ms2ger// Succeeded: s/me thanks Ms2ger// Succeeded: s|!/ !!|| Succeeded: s/s|||// Succeeded: s|/|| Succeeded: s/Josh/Josh_Soref/ Succeeded: s/Jonas Sicking/Jonas_Sicking/ Succeeded: s/macie/weinig/ FAILED: s/Josh_Soref: I'm not macie, Sam Weinig// Succeeded: s/Josh_Soref: it's ok// Succeeded: s/Sever/Server/ Succeeded: s/and anne-xxx-something-else// FAILED: s/to cover cross cross origin/to cover cross origin and opting in to credentials exchange/ Succeeded: s|s/Josh_Soref: I'm not macie, Sam Weinig//|| Succeeded: s/update had/Warp had/ Succeeded: s/Warp/WARP/ Succeeded: s/CORS was selected/same origin was selected/ Succeeded: s/issu/issue/ Succeeded: s/artb: yes// Succeeded: s/clilly/clilley/ Succeeded: s/needs ot/needs to/ Succeeded: s/time/type/ Succeeded: s/... for images/sicking: for images/ Succeeded: s/Form-Origin/From-Origin/ Succeeded: s/F-O is in Sec only/From-Origin is in WebApps only/ FAILED: s/Adam:/Adam Barth:/ Succeeded: s/and/and sub resources come from/ Succeeded: s/dom/daniel/ Succeeded: s/daniel/glazou/ FAILED: s/..../.../ FAILED: s|s/..../.../|| FAILED: s|s/..../.../|| FAILED: s/Topic: animations [cont'd]// FAILED: s/present+WayneCarr/present+ WayneCarr/ FAILED: s/present +stpeter/present+ stpeter/ FAILED: s/Josh_Soref: thanks// FAILED: s|s/present+WayneCarr/present+ WayneCarr|| Succeeded: s/meeting/Workshop/ Succeeded: s/spec/specs/ FAILED: s/2./2.0/ FAILED: s/nasgar/nascar/ Succeeded: s/3/2/ Succeeded: s/sub/third/ FAILED: s/jgraham/jhawkins/ FAILED: s/jgraham/jhawkins/ FAILED: s/MarkV/mav/ Succeeded: s/object/Object/ FAILED: s/managing/monitoring/ FAILED: s/the dom/the DOM/ FAILED: s/makes/makes one/ FAILED: s/../.../ FAILED: s/messy/AC/ FAILED: s|/msg anne|| FAILED: s/Koreans/Korean/ FAILED: s/sb ad/s bad/ FAILED: s/numebrs/numbers/ FAILED: s/usrers/users/ FAILED: s/added/updated/ FAILED: s/mjs/weinig/ FAILED: s/yes// FAILED: s/SOunds/Sounds/ FAILED: s/taht/tat/ FAILED: s/tat/that/ FAILED: s/don;t/don't/ FAILED: s/ths/this/ FAILED: s/deliver that/we get the server hosted by W3C/ FAILED: s/123/123, which contradicts DOM4's statement that no new feature strings should be minted/ FAILED: s/this i/this is/ FAILED: s/alexr/slightlyoff/ FAILED: s/shanec/shepazu/ FAILED: s/recommendations do you have/requirements are there in the spec/ FAILED: s/that is ok// FAILED: s/.. getting/... getting/ FAILED: s/admin/event/ FAILED: s/wouldn't/is only used outside/ FAILED: s/../.../ FAILED: s/errate/errata/ FAILED: s/3 4/3 ... 4/ Found Scribe: Art Found Scribe: Josh_Soref Inferring ScribeNick: Josh_Soref Found Scribe: chaals Inferring ScribeNick: chaals Found Scribe: JonathanJ Found Scribe: Josh_Soref Inferring ScribeNick: Josh_Soref Scribes: Art, Josh_Soref, chaals, JonathanJ ScribeNicks: Josh_Soref, chaals WARNING: Replacing list of attendees. Old list: +1.408.988.aaaa Olli_Pettay tpac New list: tpac Default Present: tpac 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 Agenda: http://www.w3.org/2008/webapps/wiki/TPAC2011#Agenda_Monday.2C_October_31 Got date from IRC log name: 31 Oct 2011 Guessing minutes URL: http://www.w3.org/2011/10/31-webapps-minutes.html People with action items: art barstow kris WARNING: Possible internal error: join/leave lines remaining: <dom> glazou has joined #webapps <smaug> #whatwg: AryehGregor "Microsoft Corp. has joined the HTML Editing APIs Community Group" WARNING: Possible internal error: join/leave lines remaining: <dom> glazou has joined #webapps <smaug> #whatwg: AryehGregor "Microsoft Corp. has joined the HTML Editing APIs Community Group"[End of scribe.perl diagnostic output]