<ArtB> Date: 25 April 2013

<smaug> XX :)

<ArtB> Scribe: Josh_Soref

<Ms2ger> ScribeNick: timeless

Introductions

[ Chaals takes the mic around the room and has everyone introduce themselves ]

<smaug> yes

Agenda

ArtB: we preallocated some time slots
... and we listed some topics, that chaals and i wanted to discuss
... we have probably half of the meeting unallocated
... we can try to move potential topics into timeslots
... or if people have suggestions, we can add them
... chaals on the whiteboard is trying to complete the schedule as much as we can
... usually in these meetings, we try to go through the spec status dashboard (PubStatus)
... to make sure everyone is on the same page wrt the status
... a really useful document for non-WG members
... wrt each spec
... it's pretty important to keep those up to date
... anyone have any topics?
... i know Jungkee asked to allocate time for XHR and Progress Events
... he suggested an hour for that
... should we grab the 4:30pm-5:30 slot?

Jungkee: less than 1 hour
... but more than 30mins
... probably start from
... 4pm-4:40?

chaals: let's call that 5pm and if you're good, we get to go home early

ArtB: sounds good to me, i'll leave an extra slot at 5:30
... anyone else have preferences?
... I have a slot for CR Interop status
... the only 4 specs that remain are specs where Hixie is the lead editor
... i'd like to spend some time to give an update on where i think we are on those specs
... SSE, Web Messaging, Sockets, Workers
... - anyone think it will require more than a few minutes?
... above DOM3 was IME

chaals: we had a request from PF WG to talk about IME
... put into a time slot at 3pm
... they can shift that if we need to
... we have a 2:30pm session w/ WebAppSec on CSP
... is 30mins enough to do CSP?

ArtB: i think so

chaals: alright

ArtB: next on the list was AppCache
... sicking registered

chaals: he's w/ arun, they're late

ArtB: should we slot them in?

chaals: i'd avoid slotting them in, as they're not here
... we could put them in the afternoon

ArtB: AppManifest?
... i know SysApps is doing a bunch of work
... how about after XHR?

chaals: we might do it with AppCache

ArtB: ok
... how many SysApps members here?
... quite a few?

chaals: 6 or 7

ArtB: DOM 3 Events?
... i know Travis and Gary are excited to spend time on that

chaals: in the morning?

Travis: that's fine

ArtB: where?

chaals: running up to lunch

ArtB: after IndexedDB?

chaals: if sicking isn't here, we're stuck on IndexedDB

ArtB: dom4, status and plans?
... when we do Dashboard?

chaals: yeah

ArtB: File API?
... hard to do w/ arun

chaals: we could do that last

bryan: do File related APIs as a block?

ArtB: makes sense
... full screen?

chaals: dashboard

ArtB: UI Events?
... Travis update during dashboard?
... dashboard
... URL

chaals: dashboard

israelh: on fullscreen

chaals: dashboard lets you have some time
... if we need more, we schedule time
... admin, chartering, misc
... when do you want to do that?

ArtB: tomorrow morning?

chaals: people won't be there in the morning

ArtB: after the break in the morning?

chaals: sure

ArtB: WebIDL?

plh: i have a few things to say

ArtB: tomorrow after testing?

<smaug> heycam|away should participate WebIDL discussion

plh: perfect

chaals: heycam would be better w/ afternoon
... bounce something somewhere
... AppCache to early tomorrow moring

Daniel_Austin: couple of stragglers

eric: Eric from Google

sicking: Jonas Sicking

israelh: can we do AppCache

chaals: ok, we'll do AppCache first thing this morning
... AppCache and Manifests and IndexedDB and DOM3 events
... plenty of entertainment

ArtB: not sure we need an hour for IndexedDB
... any other hot topics?
... we have Testing for Tomorrow morning
... 10am-11 tomorrow morning

bryan: we'll talk about AppCache w/ Manifest
... what about WebIntents / WebActivities?

ArtB: we can hit it during the dashboard

bryan: it'd be good to hear more than a moment's talk about it...

ArtB: anyone have more to say about WebIntents?
... let's take are of it during the dashboard

Dashboard / PubStatus

ArtB: CORS is first
... we have WebAppSec coming over to talk about CSP
... they can give us a quick update on CORS CR
... anyone have concerns on CORS?
... next: Clipboard APIs and events
... halford published a new update on that
... quite a bit of discussion
... i suspect an LC is a few months away at least
... anyone else on clipboard?
... we'll skip dimitri's web components, he has an hour this afternoon
... dom4, lachlan hunt is the editor of record
... he's an invited expert
... he left opera this last winter
... dom4 that anne is doing has involved
... it includes a rough specification of futures
... i don't think lachlan has moved it into his spec

Travis: no

ArtB: we could rathole on this
... anyone willing to step up and help lachlan

chaals: lachlan may be busy
... anyone wants to put their hand up and help...
... rathole on futures, i think we should take
... coordination w/ TC39
... WebIDL stuff

ArtB: anything that depends on dom4/futures is going to run into a problem

glenn_: HTML5

chaals: not our spec

ArtB: certainly not the only spec

chaals: probably the highest priority
... know someone who wants to be famous, and hairless
... we'd appreciate names, addresses, ...

glenn_: why not send an email to the list soliciting editors?

chaals: we will

<ArtB> ACTION: barstow work with Chaals on a call for editor help for DOM4 [recorded in http://www.w3.org/2013/04/25-webapps-minutes.html#action01]

<trackbot> Created ACTION-675 - Work with Chaals on a call for editor help for DOM4 [on Arthur Barstow - due 2013-05-02].

chaals: but please raise your hand to get the mic, so the people on the phone can hear

ArtB: DOM Parsing and Serialization

Travis: extremely stable spec
... one open bug to update Status of document
... to say it's a mirror of Ms2ger 's document
... i don't believe we have any tests yet
... i believe next step is
... make update, fix bug
... propose LC
... and start working on test suite

chaals: test facilitator?

Travis: TBD

Ms2ger: I have some tests

ArtB: can you take an action to work on that bug?

Travis:

chaals: estimate of LC schedule?

<ArtB> ACTION: travis resolve last bug for DOM P&S and notify Art so a CfC for LC can be started [recorded in http://www.w3.org/2013/04/25-webapps-minutes.html#action02]

<trackbot> Created ACTION-676 - Resolve last bug for DOM P&S and notify Art so a CfC for LC can be started [on Travis Leithead - due 2013-05-02].

Travis: a week or two to issue CfC

chaals: you've got a week
... File API is running behind schedule

ArtB: we allocated that

chaals: this afternoon

ArtB: Fullscreen?

israelh: a couple things we found
... there's a reference to the FullScreen Event
... that's talked about in the Spec
... but isn't part of the IDL
... everyone does implement on onevent handler
... but it isn't in the document
... the only thing is
... do we need a dependency between Screen Orientation and Fullscreen?
... putting part of spec w/ what others have done
... and other is should there be a relationship w/ screen orientation

ArtB: we had a few people join us

alec_flett: indexeddb

joshua_bell: joshua bell, google

ArtB: there's an active thread on israelh 's question
... screen orientation is israelh 's
... fullscreen is tantek and anne
... chaals said asking the chairs is not the right thing
... ask the room

israelh: it was a question for the room
... is there an objection to adding the idl definitions to the spec
... Mozilla and Chrome do it

chaals: seems logical

israelh: do we need the editor here?

ArtB: it's tricky since anne and tantek aren't members
... tantek is a member of CSS, and it's a joint deliverable w/ them
... Gamepad
... i haven't gotten updates from scott/ted on it
... any data on implementation status

smaug: ted landed a patch to gecko
... and has been fixing bugs in the spec
... it's changing

chaals: implementation status beyond gecko?

smaug: gecko has some support in nightlies
... and chrome has some
... but i don't know if it's the same, as the spec is changing

chaals: testing?
... do you know more than we do?

smaug: no

ArtB: next is Web Components, IndexedDB
... Java Bindings

Travis: who has the action for that?
... heycam?

chaals: yes

ArtB: should we push to NOTE?

Travis: i'd like to
... i don't think anyone would object

<ArtB> ACTION: barstow start a CfC to move Java bindinings for WebIDL to WG Note [recorded in http://www.w3.org/2013/04/25-webapps-minutes.html#action03]

<trackbot> Created ACTION-677 - Start a CfC to move Java bindinings for WebIDL to WG Note [on Arthur Barstow - due 2013-05-02].

ArtB: pointer lock

smaug: non fullscreen pointer lock is supported in nightlies
... and i think in Aurora
... and i think in Chrome
... i think they're pretty close

ArtB: action on chaals / i to chase vincent on getting to LC
... does the spec look pretty good, or are there major issues?

smaug: i think there are issues
... on how permissions are handled
... i think there are bugs open

chaals: yeah, action on us to chase vincent
... progress we have scheduled
... and push
... Quota Management, whose fault is that?

<ArtB> ACTION: barstow ask Vincent about next step for PointerLock (e.g. what needs to be done to go LC) [recorded in http://www.w3.org/2013/04/25-webapps-minutes.html#action04]

<trackbot> Created ACTION-678 - Ask Vincent about next step for PointerLock (e.g. what needs to be done to go LC) [on Arthur Barstow - due 2013-05-02].

eric: as far as i know, Kinuko isn't going to be here
... no status

chaals: action us to chase that
... Selectors API
... it's a REC, we're done
... *woohoo*

<ArtB> ACTION: barstow ask Kinuko about status and plans for Quota Mangement API [recorded in http://www.w3.org/2013/04/25-webapps-minutes.html#action05]

<trackbot> Created ACTION-679 - Ask Kinuko about status and plans for Quota Mangement API [on Arthur Barstow - due 2013-05-02].

chaals: Selectors API Level 2?

Travis: i'd love to hear an implementation report
... i know IE has pieces of it - matchesSelector()

[ Silence ]

Travis: ok

ArtB: we can take an action to ask lachy

<ArtB> ACTION: barstow ask Lachlan if he has some impl data re Selectors API v2 [recorded in http://www.w3.org/2013/04/25-webapps-minutes.html#action06]

<trackbot> Created ACTION-680 - Ask Lachlan if he has some impl data re Selectors API v2 [on Arthur Barstow - due 2013-05-02].

MikeSmith: Web Components has arrived

tantek: and a couple of github observers

Matt_Todd: Matt Todd [Github]

Corey_Johnson: Corey Johnson [Github]

ArtB: SSE
... entered CR last december
... tina has run interop
... once bugs are fixed
... that spec should be able to do interop testing for CR
... tina has a column for IE
... it appears, that it's not implemented?
... should we remove that column?

adrianba: we don't have anything to say about any plans
... you should remove the column

ArtB: ok, i'll tell tina
... anything else on SSE?
... Shadow DOM, dglazkov will take mic later
... Screen Orientation, we spoke earlier
... - mounir isn't here

chaals: i was especting tobie to point out
... there's functionality that's important to tablet/game developers

<ArtB> ACTION: barstow ask Tina to remove the IE column from the SSE implementation report [recorded in http://www.w3.org/2013/04/25-webapps-minutes.html#action07]

chaals: about specifying/holding that isn't in spec

<trackbot> Created ACTION-681 - Ask Tina to remove the IE column from the SSE implementation report [on Arthur Barstow - due 2013-05-02].

israelh: one question, related to fullscreen
... what are expectations around browser?
... should browser be in full screen at that point?
... or should it be something that
... maybe it's... when you go fullscreen

chaals: my understanding is that the browser isn't expected to fullscreen itself
... the thing you fullscreen goes fullscreen
... it's unclear what happens if you fullscreen something in a fullscreened thing

israelh: part of it is
... there's a jarring experience
... when the browser is taking a portion of the screen
... and you navigate to a web page
... and it forces the screen orientation to switch
... in a tablet, everything is flipped around
... is there a ratio when this would kick in
... it's very different than just happened to navigate to the page
... frame around it happens to be mostly fullscreen
... and a page that requests to go full screen
... like input

chaals: don't see any reason why you'd put that into
... that you'd count a ratio
... authors can create nice experiences or crazy jarry
... useful to do what they want to do
... you'll get horrendous experiences
... that seems to be a minimal
... thing we don't want to specify
... and b lets people do what they want

israelh: more of a potential interop
... would be great to say
... we agree it doesn't really matter
... doesn't matter on size of screen
... maybe there's a suggestion, as a note
... for certain sizes

tantek_: key thing is
... to capture there might be an issue between interaction of these two apis
... i'd invite people to submit user scenario
... where user goes through some number of steps
... altering orientation / entering fullscreen
... and gets confused
... if that happens, we can document that
... as informative advice for apps to avoid
... sound reasonable?

israelh: yes

chaals: not expected to be finished this week
... anyone have update on testing/implementation status?
... Streams API
... mounir?

MikeSmith: what happened to other guy?

ArtB: Feras is Streams

adrianba: i understand there's a discussion of Streams on the list
... i need to have a look at that
... we're using the Stream API in MSE
... i understand there was some discussion of it in WebCrypto earlier this week

israelh: yes

adrianba: we've implemented this
... it's possible there could be more discussion in the File discussion

ArtB: any other implementations of Streams API?

MikeSmith: google's working on one
... or, i have some reason to believe they may be working on one
... perhaps someone who works for Google could comment?

darobin: i think @FakeAlexRussell

chaals: URL will be in Admin
... Manifest format, we have w/ AppCache
... Web Components - give dglazkov
... WebIDL - we have scheduled
... Web Intents?

bryan: just wondering if those involved would be present
... to have an update
... on status / convergence of Intents/Activities

ArtB: DAP was what was driving this
... my understanding is it isn't active

<mounir> sicking might have updates for you guys

chaals: does Firefox OS have any skin in this game

sicking: we had meetings w/ Google on Intents/Activities
... and sent a report to the list
... nothing has happened since
... we need to experiment with implementations to figure out what experiences are good
... and then figure out apis to do that
... we can't do apis until we figure out experiences

bryan: we have at least Beta/Aurora of activities?

sicking: we have soon to be shipping implementations of Activities in a very narrow scenario
... only on mobile-small screen
... only for Apps
... to be Activity Handlers
... it doesn't work on desktop
... it doesn't allow pages to be handlers
... we need to solve those issues

chaals: why doesn't?

sicking: UX issues are different
... on mobile you only have one app running at a time
... on desktop you have multiple displayed apps

chaals: you turned it off?

sicking: we could do the existing behavior, but it would be bad

bryan: to move that forward?
... it's a joint TF of DAP/WebApps
... it'd be great to get other eyes around those user interface issues
... could we have those issues on a wiki?
... something to understand what that UX is and provide input
... i understood it as an area
... that would involve Protocol / Content Handler capabilities?

sicking: too many unknowns

ArtB: my assumption is that if it's important to someone, they'll put resources to drive it forward

chaals: except DOM4

ArtB: Web Messaging
... i think we have agreement on a set of tests
... Alex said he'd run interop testing on IE + Opera

krisk: Kris K, Microsoft
... from our private testing, we know two browsers pass each test across the board
... should discuss how we should submit them
... we should be able to move to REC
... if browser vendors could click the links

ArtB: you're talking about all submitted tests?

krisk: all in Mercurial Approved
... there's the move from Mercurial to Github

chaals: ready to declare victory

ArtB: would be nice to get a WebKit status
... anyone want to run the tests?

chaals: I've got a webkit browser

ArtB: anyone i could get from Mozilla to run through the tests?

sicking: probably
... i don't know

ArtB: i'll talk to smaug
... that's great
... so we could move to PR real soon

krisk: correct

ArtB: Web Sockets
... similar
... we have agreed on a set of tests from Opera+Microsoft
... krisk ?

krisk: Ms2ger also submitted tests
... we have a lot of tests now, >500 total
... bad news, we have 4 tests that only pass in one browser
... bummer
... handful of tests that i believe are just broken
... either fix or remove
... that's where it's at
... we should wait until tomorrow

ArtB: Web Storage?
... PR
... blocking REC is normative reference issues
... Workers
... i would have said we had an approved test suite
... and then simon said wait wait
... he's adding tests
... he feels test suite isn't 100%
... i assume he'll add those tests in several weeks
... testing in May/June?

krisk: simon last fall agreed to take on test suite
... and he added shared workers tests
... i think there's more work to do

ArtB: shared workers wasn't broadly implemented last fall?

Travis: i think there are at least two implementations

ArtB: i have an action to push simon to complete his contributions

chaals: XHR is scheduled

[ Break ]

garykac: UI events aren't on PubStatus

ArtB: Pointer Events has a dependency on UI Events
... i meant to ask about getting a FPWD
... are we ready to publish that?

garykac: we should talk about that today

Travis: i'll add it to pubstatus

garykac: for a number of months, it's in a good state
... i'm concerned about keyboard events
... there's an event that specifies locale

s//[ Break ]/

ArtB: is there a bugzilla component?
... i'll check that
... should we start a CfC?

garykac: sounds good

<ArtB> ACTION: barstow start a CfC for FPWD of UI Events (and make sure it has a Bugzilla component) [recorded in http://www.w3.org/2013/04/25-webapps-minutes.html#action08]

<trackbot> Created ACTION-682 - Start a CfC for FPWD of UI Events (and make sure it has a Bugzilla component) [on Arthur Barstow - due 2013-05-02].

chaals: anything else we've forgotten?

ArtB: next up is AppCache/App Manifest

[ Break ]

<plh> Presen+ plh

App Manifest

sicking: as you may or may not know
... there's a SysApps WG in W3C
... totally different from WebApps
... one of the things we're working on is creating an App Platform similar to Widgets
... same UCs
... but different set of solutions
... something we'd like is get input from this WG
... we'd like to make something based on the web
... not just use the same JS APIs
... and Markup language
... but also have the same Design principles

<ArtB> ACTION: barstow work with Alex and Chaals re interop data for Web Messaging [recorded in http://www.w3.org/2013/04/25-webapps-minutes.html#action09]

<trackbot> Created ACTION-683 - Work with Alex and Chaals re interop data for Web Messaging [on Arthur Barstow - due 2013-05-02].

sicking: the companies in SysApps are from a different background
... we'd like to
... um, eh
... we have a Manifest specification

<JonathanJ> http://manifest.sysapps.org/

sicking: and a Runtime specification

<JonathanJ> http://runtime.sysapps.org/

sicking: the latest EDs of the specs
... the specs are living in Github and we use Github to track issues
... we're proposing
... to create a joint deliverable w/ this WG
... at the very least for the Manifest specification
... we think there are a lot of uses for Manifest specification
... outside of the SysApps
... it solves the same UCs
... similar to what apple's meta tags
... if the User bookmarks this to the homescreen
... the name of the icon, the icon
... it's similar to AppCache
... things to startup
... this Manifest ties together existing pieces
... there's app specific things (permissions)
... we could remove that, and move them into other specifications
... we'd like to standardize this so we could have `bookmark to homepage`
... and so you could build other experiences
... Chrome has Miniature tabs
... FirefoxOS has app tabs
... when the user says `make this into an app tab`, you could grab info from the manifest
... use icons and appcache info from the manifest
... there's a lot that isn't app specific
... want to create richer experience for web sites
... without having to make an app

<tantek_> Aside: Firefox's mini tabs are called "Pinned Tabs": http://support.mozilla.org/en-US/kb/pinned-tabs-keep-favorite-websites-open

sicking: we believe this is already chartered
... based on work already done by widgets
... this is the feature set we're trying to solve
... this integrates nicely w/ AppCache

hober: i wanted to quickly +1 the UCs
... for a standard manifest format
... extending beyond the non web sandbox of sysapps

<tantek_> "Pinned Tabs allow you to always keep your favorite web apps like Facebook, Gmail and Twitter open and just a click away." - from cited URL.

hober: and not all browsers are participating there

chaals: i believe this is chartered, because i wrote this into the charter
... back when we said yeah
... and i sayoud no
... so welcome back

sicking: we always wanted to do this

ArtB: chaals is right that
... the manifest draft on the screen is within scope
... but it is not identified as a joint deliverable with sysapps
... it makes sense to collaborate

<JonathanJ> http://www.w3.org/wiki/System_Applications_WG:_Manifest

ArtB: maybe Yves / plh could give feedback
... can we discuss on public-webapps w/o explicitly updating the charter?
... we know in the past
... adding new deliverables to WebApps has raised issues for members because of the IP commitment
... in this case, i think it's ok
... because it looks like what we have
... if we go down this path, we'd need a CfC
... so far, i've heard hober say it's reasonable
... we haven't heard anyone else
... anyone else

chaals: Yandex would like to make it a joint deliverable

bryan: we'd support it being a joint deliverable
... the needs of web apps and installable are overlapped

ArtB: seeing no other feedback
... maybe, we'll craft a CfC
... use current draft as our guide
... sicking asked about permissions

<lyle> lyle: we'd support it being a joint deliverable (4D)

<chaals> ACTION: chaals to make a CfC for joint work with sysapps on webapp manifests [recorded in http://www.w3.org/2013/04/25-webapps-minutes.html#action10]

<trackbot> Created ACTION-684 - Make a CfC for joint work with sysapps on webapp manifests [on Charles McCathie Nevile - due 2013-05-02].

ArtB: we could use the CfC to gauge whether that's too far

plh: why joint deliverable?
... maybe darobin or MikeSmith could

ArtB: this isn't AppCache

MikeSmith: as someone who has to deal w/ administrative hassle of joint deliverables
... please don't make me do it
... i don't see it getting us more IP

chaals: other alternative is to move the spec into this group
... it's on our list of deliverables

sicking: i'm fine w/ moving it from SysApps to this group
... in SysApps, we'd have to define extensions, but we'd have to do that anyway
... it's a question we haven't raised in the SysApps WG, but we'd have to raise it
... it's an option

ArtB: so that's a CfC to make WebApps sole owner?

chaals: we don't need a CfC
... imagine a chair of SysApps was around
... how do you feel about the idea?

wonsuk: i think that in case of SysApps WG
... we already made a decision to propose a TF w/ WebApps
... in aspect of SysApps WG there are no objection
... not sure how can we make a TF
... do we need to make a different mailing list?
... and wiki page

chaals: this is the thing
... if we make a joint TF, there's a lot of admin to do
... the suggestion is to JUST do Manifest in WebApps
... and SysApps says we've given it away
... but do you think that would be something the SysApps group might be happy with?

wonsuk: i think so

ArtB: anyone have any issues with that?

[ None ]

ArtB: working assumption is WebApps will work on this
... is marcosc in WebApps?

Yves: yes

sicking: a more controversial proposal
... the same thing, but for runtime spec
... for same reasons
... we have the runtime spec
... which defines concept of apps, small api for interacting
... i don't think we'd want to move that to WebApps
... i think it would be interesting to do as a joint Deliverable
... i can imagine people don't like that

chaals: you'd have to talk to MikeSmith

hober: i'd rather not do that

ArtB: i'd expect there'd be other objections from Members

sicking: it seems to me that it falls under the same widget charter
... but
... i understand
... this is why i brought it up separately and after
... but i'd still like more webby input

chaals: so you're recruiting people to do sysapps
... work
... and then dropping the actual work

sicking: you say that, as if it's a bad thing

[ laughter ]

chaals: i think the current charter would permit it
... if you just do it, you might surface objections
... the current charter doesn't say we'll do joint work
... if we try to do that, you'll provide a nice opportunity to give their opinion on the distribution of resources

sicking: i'll drop the subject

AppCache

sicking: i sent a proposal to webapps@
... about a very different AppCache than what we currently have
... based on discussion over years

<ArtB> Jonas' AppCache proposal

sicking: i received input, not a lot, but more than i could keep up w/
... two questions
... 1. is this group still interested in this?
... 2. which implementations would be interested in doing this?
... which implementations want to do an updated appcache
... which would be interested
... there's also separate work in github on a NavigationController, which is a different way of solving the problem
... my intent was to have both, with an interaction between the two
... the second question is
... should we have a declarative format at all
... or only a Script based (NavigationController)
... there's work to fix the performance
... there's some concept of a manifest
... it's a big question
... A. who's interested in working on something like the New AppCache?
... B. if we do new AppCache, entirely Script based, or something declarative?

chaals: we want to do something
... the stuff we're pushing to implement is likely to be script based
... but it seems like it'd be nice to have a declarative backing
... a lot of UCs aren't amazingly complicated
... making a declarative approach available makes it easier

israelh: i think a declarative approach should continue to be supported
... if only for backwards compat w/ simple sites
... a scripting approach is needed
... the ability to allow those interact
... it's just about how to define them

sicking: MS's input on this is sort of needed
... the way the script based thing is heading, it doesn't have a declarative part at all
... if it's something that's important to you guys, i'd urge you to voice that opinion
... i believe declarative is important
... i have a concern that declarative solves so few UCs that it isn't useful

israelh: there are things in the issues outlined
... that we have resolved w/ proprietary tags
... that were requested by internal properties
... like caching master entry
... you create a relationship, but don't cache master entry
... we already have a large property that actually uses this
... IndexedDB and AppCache to work offline
... it goes back to what scenarios
... there are scenarios in which this does work
... maybe they aren't as interesting anymore
... but they're existing apps
... i keep hearing about wild UCs
... we need to be specific about what UCs aren't solved by this
... that are solved by something else

adrianba: we've talked for a while about the issues
... can we evolve our way to a solution
... or do we do something new?
... i think doing something new is
... the approach that sicking is suggesting
... and something we should embrace
... the one question i had was
... whether we should look at something entirely separate from what's there currently
... it wasn't clear whether the proposal would ignore the manifest attribute
... that was the old approach, and we're doing something separate
... i was thinking we'd have similar entrypoints
... but the format and rules would be different
... discuss pros/cons of that

sicking: my vision w/ this proposal
... was to enable supporting back compat
... enable web sites to support the old format
... and take advantage of browsers supporting the new format
... invent a new attribute that links to the new manifest
... apps could list both attributes
... or only new or only old
... it is definitely a
... replacement, but enabling websites/implementations to have a transition
... and to keep supporting the old stuff for as long as useful

chaals: it's said that AppCache perfectly supports its UCs
... "and that's the problem"
... it's important to lay out the UCs that we're trying to deal w/
... we set out UCs
... some of this isn't pure offline stuff
... it's optimization of the network
... most of the network in Russia is crappy
... that's important to work with
... here are UCs we'd like to enable
... we've all got ideas in our head

sicking: paul backus, of zynga started a thread
... i got feedback from others
... it'd be useful to list UCs
... and how this proposal solves the UCs
... and include sample manifests
... i'm planning on writing that up
... which hopefully will help
... i still think we have the large question of
... should we do this declarative solution
... script base solves everything
... it may have perf issues
... but they're probably solvable
... we should spend time looking at UCs
... and see how it matches them

adrianba: 3 points
... 1. we talked about this a bunch
... we've all experienced problems w/ the original appcache proposal
... we want to fix it
... this is a great starting point
... we should write it more formally
... we'd be happy to help w/ that
... part of that should be gathering together those UCs
... it's a great suggestion to take UCs and show examples of how to satisfy
... gathering into a document would be great
... 2. probably some charter work to do to make it possible
... we started that work at TPAC
... given this is
... different enough from the current AppCache
... and we aren't talking about modifying AppCache
... i'm less concerned about talking w/ HTML WG
... 3. we made some substantial engineering investments in supporting the original appcache
... manage caches, keep those files, know when to purge them
... we don't want to do that again
... we'd like to see how much we can make work w/ this
... that might impose constraints

israelh: in the past
... when we tried to make progress w/ the existing manifest
... there was controversy about UCs
... it was offline only
... being open
... about transactional boundaries
... are issues we'll have to figure out
... to make it map to the engine we have now

chaals: there's a nice seat next to arun

sicking: i have this naive hope
... it sounds one of the things the existing AppCache did
... the transactional approach
... to go from one to another
... it's hard to say at this stage
... at mozilla, we don't have that problem
... our existing impl is so crappy
... that we have to rewrite it anyway

[ laughter ]

sicking: the way it goes away, we're happy
... it's not entirely by accident
... the intent is that we can use the same manifest i was talking about before
... they use the same linking mechanism
... icon:, name:, cache:
... that would work much better than the current Manifest specification
... that links to separate items

chaals: i put a note to myself to talk about this for Chartering discussion
... when you say help
... you were going to offer an editor

adrianba: ...

ArtB: i heard a need for UCs
... sicking, does that response address UCs?
... do we need volunteers?

sicking: there's work to be done
... i'll send the UCs we had in mind
... there's more work
... this is the main case where the existing AppCache fell down
... i think this is the way to prove/disprove that the declarative proposal will work

ArtB: we could ask paul to contribute
... anyone else willing to contribute UCs?

adrianba: yes

ArtB: chaals, i saw you raise your hand

sicking: i can't be the editor

ArtB: nice to know we have interest in doing things
... we can ask for leads, or helpers

chaals: we could perhaps get a helper
... not sure about a lead
... the people i'm thinking of

adrianba: i don't think we're in a position to make a commitment
... want to help
... w/ formal writing down of UCs
... to make sure we capture those
... we have some of that written down
... transcribing it isn't much extra work
... getting things from MS about what worked/failed
... capturing that
... we think this is going in the right direction

ArtB: makes sense

marcosc: hello

ArtB: we have an action that marcosc will be editing appcache?

marcosc: no

[ break ]

Indexed DB

jsbell: on the agenda was going over open bugs
... and LC tracking
... let's do LC tracking first

<ArtB> http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html Indexed DB ED

<jsbell> Disposition of Comments

s/http:/-> http://

jsbell: lots of green
... most aren't normative changes
... but we should probably do another LC

chaals: TBD here?

eliot: i should probably change TBD to something more appropriate
... that was placeholder text from a table shepazu used
... there's no response from those people
... i could change TBD to NA/blank

chaals: limit of time for response

<ArtB> ACTION: eliot update IDB LC comment tracking document to replace "TBD" with something more descriptive [recorded in http://www.w3.org/2013/04/25-webapps-minutes.html#action11]

chaals: don't wait forever

<trackbot> Created ACTION-685 - Update IDB LC comment tracking document to replace "TBD" with something more descriptive [on Eliot Graff - due 2013-05-02].

jsbell: seeing a few nods for going to another LC

chaals: seems reasonable

israelh: one of the questions we have
... it seems a lot of the comments we made
... have been integrated into implementations
... i haven't heard of new implementations
... i haven't heard of things that will invalidate
... are things discussed in email
... that we haven't brought back to the spec
... i'm wondering about the Process
... does moving forward/going back to LC?

sicking: i'm fine w/ not going back to LC

<marcosc> Zakim: ack me

sicking: not terribly knowledgeable about formalism

chaals: going back to LC
... it's more of a hygiene thing
... put it up for 3 weeks
... only the changes are fairly open

<inserted> chaals: you probably won't have comments anyway

chaals: it gives you hygiene for Patent Policy
... and it takes 3 weeks for ArtB / myself to organize the next step anyway

lyle: is there any interest in indexedDB including webSql
... a jdbc remote database call

[ laughter ]

israelh: that's why i want this to move forward
... we've gone through a lot of things in the WG
... we've identified things we've chosen not to do in V1
... likely to stir up again in LC
... things we'll have the same answers to
... implementations are really close
... let's keep moving forward
... my inclination is to move forward
... and then get to v2
... for new things

<Zakim> marcos, you wanted to volunteer?

chaals: i agree we don't want to open the thing up widely
... the LC is "this is version1"
... we're showing you the spec we're pushing to REC
... if people say "you forgot to boil the ocean"
... the response will be "out of scope"
... we'll make that very clear if we go to LC
... we say "you're not getting websql" or anything else into

ArtB: i have a feeling trying to convince director that there haven't been changes to invalidate review
... +1 a new LC
... concerted effort to get those comments addressed quickly
... don't let it drag on for months
... as a chair, you learn not to allow them to drag on

israelh: scope it, that'd be awesome
... don't allow for repetition of previously presented comments

chaals: absolutely
... resolution
... we'll put up 3 week LC

<ArtB> IDB Open Bugs

chaals: this is a review of the changes
... we don't take on new work
... we'll do more in v2
... what's your testing story?

sicking: i don't think we have two implementations that implement everything
... IE is lacking Arrays

<marcosc> +q

sicking: Chrome is lacking Blob
... Firefox impl is perfect

chaals: that's what they said about AppCache

jsbell: no sync api impls

marcosc: i was going to ask about sync api

<smaug> drop the sync API ?

marcosc: will that be dropped in LC?

sicking: there's no way it'll survive
... it's listed as AT-RISK
... maybe we could drop before LC
... we have a mostly working impl

jsbell: +1 to dropping

<smaug> +1 dropping

israelh: +1 for dropping

ArtB: what's the plan for the bugs?

eliot: those 3 bugs were submitted after the official LC period
... not sure how that applies
... one is in DoC
... the other two came later

ArtB: if we publish a new LC, we should consider these

eliot: i'll add to DoC

jsbell: 21801
... i filed as i was making a bug fix to our impl
... i think it's non-controversial
... looking for eyeballs

<Ms2ger> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21801

jsbell: 21555

<Ms2ger> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21555

jsbell: this came out of discussion on ML/other bug
... to match new features of WebIDL
... try to avoid webIDL `any`
... using webIDL `unions`
... this looks like webIDL doesn't support attribute returning js array
... comments from heycam suggesting webIDL spec additions to address

sicking: i don't think we need to depend on webIDL
... we can use prose

jsbell: yes, we can do that, seeing nodding
... 17681
... was in DoC
... it's been resolved, reopened, resolved, reopened
... when spec was written, it listed a list of exceptions for arrays w/ tabular format
... the spec wasn't written in new format
... of step-wise
... i've removed the tables
... but the spec doesn't specify order
... and the opera tests showed different behaviors
... sicking and i talked about picking an ordering or picking some implementation
... israelh has an objection

israelh: from our perspective
... we don't see this as adding value to the web developer
... the pattern we see is that they'll catch the exception
... they're not going to look at the details of the exception

<Ms2ger> Should we replace all exceptions by plain Errors?

israelh: either move forward or not care
... don't see reason to expend resources
... even if the spec had it

sicking: i think israelh addressed my question
... specwise it's easy to give a global order
... if it supports A, B, C, you check for A, B, then C
... i don't think it matters
... i still would like to see a defined order

israelh: i think it'd be silly
... to not be spec compliant just because of error order

sicking: you aren't compliant because of arrays

israelh: yes, but that's useful because it addresses a UC
... but exception order?
... what UCs does it help

adrianba: different between not implementing a feature
... and here
... we're saying "multiple things are wrong here"

<Ms2ger> I wonder how much time it would take to implement a consistent order, and how much time has already been wasted on objections

adrianba: in the end, the operation isn't going to complete
... i don't think it matters to web developers
... knowing there are multiple things wrong
... you're told about one, and stop

chaals: if we accept your position
... actual order in which you burst into flames, break down, and explode
... we'll get a comment from a web dev explaining why we're ruining his business, his life, and his relationship
... how many of those will we get?

sicking: not a hill i will die on
... people will do crazy stuff
... things may work in one impl and not another
... fine w/ punting and leaving undefined here

<Ms2ger> Might as well do it now

adrianba: maybe we'll get impl experience
... about whether or not this is a problem
... in CR

lyle: if we don't get a recommendation of the order, then implementers will never get in sync
... can we get a recommendation list
... and say we'd like people to align to this

chaals: i don't see that as a solution
... you set up an expectation for developers
... then they'll see it was a sales pitch
... we just tell them don't trigger multiple failures

israelh: exceptions are things that you're not going to deal w/ in most cases
... DataErrorException or CloningProblem
... things i'll overcome: errors
... failed to commit to database
... that i need to retry
... the error model is robust enough

lyle: i disagre
... if you deal w/ errors in a different order
... how you handle an error is very important to an application
... we can chat over lunch

israelh: the errors are so different

<arun> Objections were cited about moving the API to Futures

<jsbell> as out of scope for V1 Last Call

<smaug> ArtB: how long lunch you'll have?

<smaug> s/samug/smaug/

<smaug> k

<ArtB> ArtB: I will block on starting a CfC for LC of IDB until I get a Go message from Joshua, Israel and Jonas

<Ms2ger> Enjoy lunch

DOM3 Events - Status Update

<ArtB> DOM 3 Events Bugs

Travis: please don't raise any concerns or questions

<ArtB> Open Issues

Travis: we did a LC

<ArtB> http://www.w3.org/2008/webapps/wiki/DOM3Events#Last_Call_Comments -> LC Comment Tracking for D3E

Travis: and we now have implementers working on the last bits
... the new action is the Keyboard events
... mozilla has given us a bunch of bugs
... related to specific issues in the spec
... hey, you need a key value for a given thing
... we have 25 of these bugs

<ArtB> ( 26 open D3E bugs open ATM)

Travis: garykac and i have reviewed them all
... a lot of them are editorial fixups
... fixing explanatory stuff in the spec
... then we have to work on tests
... we ported tests to github
... we have 20 or so tests
... that look at event model/propagation - supported by 100% of browsers
... what's missing is tests on key combinations
... where we're getting bugs
... our effort in the next several months is work on places where we need to beef up tests in these cases
... from mozilla and hopefully google
... for future requests, we've spun up the UI Events document
... which is taking open requests for new features
... that's the status
... we'll need multiple months to get the spec prose updated
... reissue, a 3rd LC
... we'll try to keep the LC period short (3-4 weeks)
... and work on getting tests identified and approved
... by next TPAC we could propose CR

<smaug> only 3rd last call and the spec is 10+ years old :)

Travis: which i've said for years and years

chaals: you can copy that from last year's TPAC

ArtB: we can blame shepazu

garykac: we talked/worked during lunch
... concerned that the editorial comment come down to
... "this spec is unclear" in a bunch of points
... a lot of that will require adding additional information
... we'd like to have the minutiae encoded in the tests
... and we can't get this spec signed off on w/o this being encoded in the tests
... there's talk that this is blocking IME
... the messy part is DOM keyboard stuff
... a lot of DOM keyboard could be extracted out
... keyboard events will take at least until the end of the year

smaug: I will talk to masayuki if he can help with key event tests while implementing that stuff to Gecko

chaals: we're beginning to suspect that keyboard events are tricky, after 10 years on it
... i don't have a great position on this (splitting it out)
... dom2 did this

garykac: was it a separate doc, or did they put it as dom3 keyboard?

chaals: they did it as `something they'll do later`
... now it's `later`
... what are we better off doing
... if we can get the rest of the spec out, w/o key events
... we're not forcing people to do specs
... we do them when it's painful
... keyboard events are clearly painful around the web
... what do people think?

Travis: if they've been blocked on D3E for years, a few months isn't a big deal
... keyboard events are in much better place now, than when DOM2 was wrapping up
... whichever path
... is about accelerating the spec
... we want to get it all done
... i don't think keyboard is blocking any more than the rest

glenn_: from my perspective, there's no point in publishing D3E w/o keyboard
... it's the thing missing from DOM events for a long time
... i'd have to object

chaals: other takers?
... i lean to not splitting it out
... keep pain in front of us

garykac: i got the impression that people are afraid of the spec
... i got the impression minor changes aren't going in
... i'm fine w/ them staying in as long as we're making progress
... concerned that there's concern it's collapsing under its own weight
... but i think it's getting close
... just dotting i's, crossing t's
... right now, if you implemented, it wouldn't be cross browser

ArtB: are you two editing the spec right now?

Travis: right now, it's just me
... but i don't see why i couldn't add garykac

ArtB: i see 26 bugs

Travis: a lot are `just add this keyboard code`

garykac: i'm volunteering to edit
... to add keyboard codes, and fix English

weinig: Sam Weinig, Apple

chaals: hearing "we'll be done by some TPAC"

garykac: we need to get our testing situation in order
... w/o that, we don't have confidence in order

chaals: so, "Testcases are accepted, welcome, and wanted"

ArtB: we have Alex Kuang from Microsoft as test facilitator

krisk: there's room for more tests

garykac: i'd imagine signing up for tests

ArtB: does 75% sound fine for coverage?

garykac: for keyboard, closer to 5%
... other parts probably have test coverage

krisk: we set up test facilitators so that editors wouldn't do everything

Travis: garykac, do you want to replace alex?

garykac: that's fine

krisk: i love your passion

Web Components

dglazkov: wanted to give a quick update
... since the last
... delta or absolute?
... Absolute first
... we wrote an explaner a long time ago
... turned it into a Doc for this WG a while ago
... this turned into 4 specs
... Shadow DOM, XX2, XX3, XX4
... there's a risk of a fifth spec

<ArtB> Web Components Explainer/Intro

dglazkov: the goal was never to have HTML Templates as its own spec
... it's an extension spec

chaals: that would be in Plan 2014

darobin: we could just fold it directly into html

dglazkov: i'm really happy about that
... it never seemed like a separate feature
... there were several issues about Parsing
... they have been ironed out since our last conversation

MikeSmith: what was the resolution on XML parsing?

dglazkov: there's graceful fallback mode

MikeSmith: the feature works in xml

<ArtB> HTML Templates

MikeSmith: cool

<ArtB> Shadow DOM

dglazkov: next is Shadow DOM
... mozilla has a lot of questions
... that's great
... next is to work w/ CSS WG
... on integration, w/ Selectors
... there's value for other specs too
... scope relative selectors
... - which were vastly underspecified
... recently we had existential questions
... Element, Shadow DOM, Declarative
... I plan to resume work on Shadow DOM - RSN
... Shadow DOM has a nice test suite

<dglazkov> http://www.w3c-test.org/webapps/ShadowDOM/tests/submissions/Google/

dglazkov: as tests were written, we discovered bugs and fixed it
... as the spec is updated, we plan to update the tests too
... we're failing several tests right now

sicking: a big concern we have
... is using selectors for insertion points is too damn slow
... does webkit deal w/ it right now?
... and you handle all possible dynamic modifications?

dglazkov: yes, and the test suite tests for that
... the problem of combinatorial expansion is prohibitive
... but it tests every selector

<ArtB> Custom Elements

dglazkov: Custom Elements let you define your own platform objects
... the problem w/ this, is that it operates in a space shared by several other specs, WebIDL, DOM, HTML, _and_ TC39
... that space is irregular, it involved fixing bugs in all of those specs
... huge thanks to Mozilla, and especially bz
... in guiding me, and helping me to understand how to do this

<ArtB> ACTION: barstow update Pubstatus of D3E to reflect Gary's participation in Editing and Testing [recorded in http://www.w3.org/2013/04/25-webapps-minutes.html#action12]

<trackbot> Created ACTION-686 - Update Pubstatus of D3E to reflect Gary's participation in Editing and Testing [on Arthur Barstow - due 2013-05-02].

dglazkov: it's fairly well settled at least for imperative
... Declarative syntax of custom elements is still up in the air
... i don't expect it to be this way for much longer
... we have an idea
... and now that imperative is fairly solid
... we've ironed out this for ECMAScript 6

chaals: you have this ironed out?

dglazkov: yes, you can feed it a Class
... next step, is to issue a draft

ArtB: i'll start a CfC

dglazkov: tross is not here

<ArtB> ACTION: barstow start a CfC to publish FPWD of Custom Elements [recorded in http://www.w3.org/2013/04/25-webapps-minutes.html#action13]

<trackbot> Created ACTION-687 - Start a CfC to publish FPWD of Custom Elements [on Arthur Barstow - due 2013-05-02].

dglazkov: he contributed to the discussion
... on synchronicity

<ArtB> HTML Imports

dglazkov: HTML Imports, another huge patch on html
... which is how custom elements declarative syntax will integrate
... i have an early draft
... it's probably ready to do FPWD
... its lifespan is intertwined w/ Custom Elements

ArtB: any objections to FPWD of HTML Imports?

MikeSmith: decorator?

<ArtB> ACTION: barstow start CfC for FPWD of HTML Imports [recorded in http://www.w3.org/2013/04/25-webapps-minutes.html#action14]

<trackbot> Created ACTION-688 - Start CfC for FPWD of HTML Imports [on Arthur Barstow - due 2013-05-02].

dglazkov: yes

MikeSmith: there's no spec?

dglazkov: yes
... we're walking around a large structure
... i figured we'd start walking, and see what we can see from there
... if you look at the explainer, they're the most hand-wavy part
... web developers were saying wouldn't it be nice
... it's really cool, but very dangerous
... you're running script on selector
... everyone who's done this before
... MS and Mozilla/hixie
... have said it's very dangerous
... if people want it, we might consider it
... i have no plans at this point

ArtB: the explainer is a nice document
... do you see a need to update it?

dglazkov: it has been updated
... we need to publish another version
... it used to be forward looking

<ArtB> ACTION: barstow start CfC to publish new WD of the Web Components Explainer [recorded in http://www.w3.org/2013/04/25-webapps-minutes.html#action15]

<trackbot> Created ACTION-689 - Start CfC to publish new WD of the Web Components Explainer [on Arthur Barstow - due 2013-05-02].

dglazkov: the process is working

hober: thanks for the status update
... wonder if you want to take time to look at open issues
... and maybe get ideas

chaals: we have time

dglazkov: i'm bug-happy
... i file bugs on my specs
... 186 bugs
... best way to look at it is a tree

<ArtB> Web Components Bugs

<dglazkov> Dependency tree for dglazkov 's work

chaals: given 15 minutes
... where would you like input?

dglazkov: shadow dom -- document fragment
... callbacks in custom elements
... double checking that we've got it right
... there's another session w/ WebAppSec on isolation/security

chaals: anyone have this swapped into their brains?

[ Silence ]

dglazkov: Custom Elements

chaals: take 5 minutes to do a walk through
... i'm happy to take a long break

<ArtB> Custom Elements

[ dglazkov walks through Custom Elements ]

dglazkov: it lets an author provide a native like object
... DOM objects are magical
... they seem to have Constructors
... but you can't subclass
... you can't new things
... it gives you something that seems like a DOM object
... this spec doesn't refer to es6
... the idea is that the construct() internal method is overwritten
... in Registering Custom Elements
... an element definition is registered w/ the document
... and you get back a constructor
... generated for you by the browser
... it hooks the magic into the thing
... you don't have to worry about how it works
... when this object is instantiated by browser (parsing, construct node, adopt node)
... JS isn't run
... as a consolation prize for developers
... we have a ready-callback
... roughly at mutation time
... if i need to initiate things
... i do it during this callback
... we'll add, an insertion-callback and a removal-callback
... to be notified when a document is in/out of the document
... you don't want a Clock to be running when it's outside of the document
... lots of cool things
... making sure we don't break invariants
... of HTML/SVG
... we do this thing where you can instantiate anything that inherits from Element
... but in reality, only things that inherit from HTMLElement/SVGElement
... we actually swizzle- prototypes
... there's a quantum of time
... you define your own element, put it in a tree
... later on, it becomes
... we ensure that the prototype chain
... the top of the chain doesn't change
... so it never has to modify past the ...
... ElementRegistrationOptions looks suspiciously like a function
... this would be a Class once ES6 arrives
... right now you can pass any object

ArtB: you said something about Implementation Status?

dglazkov: it's early
... Mozilla has some code, Blink has some code, WebKit has some code
... none is runnable

weinig: i'm still curious, years later
... why is it necessary to inherit from existing browser specified objects
... what benefit do you get over composition
... i know we've been over this before
... but i don't think it's been sufficiently explained

dglazkov: the basic goal
... Custom Elements explains how DOM Elements are born
... you could build <video>, <audio> elements
... it doesn't build another layer of the platform
... it tries to explain how it works
... we tried not to add another layer
... just explain a layer

weinig: is there a benefit to subclassing <p> ?
... usually subclassing, is for when you want to
... if you override something that's custom
... -- sometimes you can't inherit

dglazkov: the key is to inherit from Element
... and we allow that

weinig: i think you want to limit yourself

dglazkov: why?

weinig: the future is big
... take the limited thing, iterate on that
... we don't have to do everything at once

dglazkov: i think the spec is fine
... i think we could limit it to HTMLElement

weinig: looking for UCs
... i know mozilla is doing this
... are there cases where inheriting from <video> makes sense?
... We wanted to solve this
... to make some things not a blocker
... we didn't want to leave us stuck
... we could limit to only inheriting to objects speced as inheritable
... start from that direction
... so you could go forward
... and say, now Hixie has added inheritable to X object

dglazkov: this is interesting
... this is similar to events
... whether an event stops at shadow dom
... that's an interesting idea

weinig: it would reduce the complexity of the spec
... these specs are very dense
... when we started this
... the idea was that XBL2 was very complex
... and we didn't want that

dglazkov: Shadow DOM is the guts of XBL2
... i just made sure it was bullet proof
... by the time you tried to address all the bits in XBL2
... it would be larger
... i just made the guts of XBL2 real
... when you make something real -- solidify
... make it more concrete
... Custom Elements is a really small spec
... it's the complexity of explaining the life cycle
... it doesn't matter if it's <hr>, <div>, <button>
... they have the same lifecycle

<Zakim> MikeSmith, you wanted to ask about the <decorator> spec

chaals: he already asked about that

ArtB: anything chaals and i can do to help?

dglazkov: i'm very happy w/ what you guys have done

ArtB: so you don't want us to get involved?
... is everything happening on public-webapps?

dglazkov: G+ is writeonly (updates)
... public-webapps, and some threads on public-style

ArtB: thanks

chaals: thanks

[ Applause ]

[ Break until 2:30pm ]

Web Components Security Model

<bhill2> I hope the topic is Web Components Security Model, rather than CSP

<arun> +1

dglazkov: welcome security people

[ Applause ]

dglazkov: i have a few goodies for you
... and some are baddies
... i'm the guy trying to drive Web Components

<ArtB> Daniel Buchner re CSP and Web Components

dglazkov: i have some questions
... tactical, and philosophical
... we have this "CSP" thing
... we invented a new syntax for Custom Elements
... the ability to build your own custom DOM elements
... let's go to the explainer
... go to custom elements
... it has a new element
... i call it "<element>"
... one of the things we have there is the ability to have an initialization script in a custom element
... it runs once, when the element is registered
... this lets me add methods to the prototype for this thing built for me
... this is subject to change
... someone pointed out "dude, this is bad"
... i said "i dunno"
... they said "look CSP"
... it's not technically <script>
... and TC39 people convinced me it's a normal script

<ArtB> Custom Element using script example

dglazkov: does this need to have <script src> to be CSP-ok ?
... the idea is to put styles, script, markup in one place
... you might load it in one place
... separating it out seems bad
... they want their Taco
... folded into one place

barth: when this script executes
... it executes in what context?

dglazkov: we experimented during our youth
... i think it will execute in normal context

dveditz: is that chunk embedded in the main file?
... loaded in a separate file?

dglazkov: could have it both ways

dveditz: we're talking about a "script-nonce"
... concern is if your element can do that
... then something that could inject into that page
... script-nonce could be a solution
... maybe not
... if they're loaded externally, are they loaded how?

dglazkov: HTML Imports
... they're loaded into a non-executable process

dveditz: loaded through a new tag?

dglazkov: <link rel>

dveditz: so we could invent special rules
... so we could have that supply a nonce
... by default we'll consider that bad, and come up w/ a fix

dglazkov: relating to what barth said
... what if this did execute in a separate script context?
... what if you could have dom elements born somewhere else
... to provide some isolation
... i have no idea how this would work
... if you import this using an external other document
... you get their own document
... but they somehow appear as DOM in the main tree
... and of course, there are issues w/ read / style information
... but it's an interesting problem
... there's lots of code to provide `like` and `plus`
... most of that code has bugs

bhill2: i agree w/ that concern
... that's one of the reasons i wanted to bring our group over
... those other buttons are implemented w/ <script src>
... the most popular of those widgets provide a single point of failure
... Facebook like/google analytic
... a bug in Facebook Connect nuked a quarter of the Internet for a couple hours
... not sure how to do that either

dglazkov: an abstraction is Shadow DOM
... i think that may help
... we may be able to do something really interesting
... i'm excited about solving this problem
... i had discussions w/ Caja

chaals: spanish for Bank

dglazkov: sounds like a lot of people interested in solving this
... i don't see a path
... i spoke w/ barth and he said give up now

barth: yes

dglazkov: we have abstractions, it'd be a shame if we didn't use them
... i'd really appreciate if i could meet with you guys later
... have a brainstorm
... we don't have much time here-now

bhill2: we'd welcome you and others to chat w/ us tomorrow
... we have time

dglazkov: i can give you a brief intro, perhaps an hour of your time (tomrrow)

ArtB: our meeting ends tomorrow at noon

bhill2: we're working on tests in the afternoon

CORS

ArtB: interested in a quick status

bhill2: we have a reasonably complete test suite for CORS
... odin has issued a call on it
... we're running into issues w/ servers swallowing headers
... we're working on a new status 308
... there's a new RFC, it's being implemented in Firefox
... it may be AT-RISK, not enough implementers
... we're at CR
... time on agenda to go into more detail

ArtB: anything else?
... at 3pm, we have another group

wonsuk: we will have a discussion about CSP?

CSP

bhill2: we have very few tests
... we have an invited expert who has written some tests, but not in the standard format
... we don't have a test suite that maps to individual points in the spec

ArtB: are you meeting at TPAC?

bhill2: that question is next on our agenda after this joint meeting

ArtB: thanks for coming

[WebAppSec leaves]

<ArtB> ArtB: thanks Brad, Adam, Daniel, All

<smaug> does anyone have links to the tpac minutes about IME

IME with PF

[ Introductions ]

MikeSmith: the Google Chrome team in Japan
... identified UCs
... if you're using Bing/Google Suggest
... where, as you type, the web app is taking your key events to give you some suggestions
... which might be things stored associated w/ your account

<adrianba> https://dvcs.w3.org/hg/ime-api/raw-file/default/use-cases/Overview.html#suggest

MikeSmith: terms you've searched before
... which is cool if you are typing w/ a language where you don't have an OS/Platform using an IME
... what happens often in Desktop and Mobile
... the OS IME will pop up a candidate window of completions
... if you've never typed in Japanese
... what you first type into, in a buffer
... sometimes in Roman, some use Hiragana
... then there's a second step to turn things into XXZ
... the problem is that the candidates appear right on top of the page suggestions
... so to see the page suggestions, you need to scroll the page
... we said "wouldn't it be cool"
... if you could while constructing games
... if you could make your own IME in your app
... and you could tell the OS IME to go away completely
... that second UC ended up to be one that a lot of people don't think is super important
... at the last F2F, mjs said there was no UC for an IME in JS
... but we do have a positioning UC
... i can't speak to Google's priorities
... or schedule
... the primary UC is positioning

chaals: apart from Chrome, what's the implementation status?

MikeSmith: no one has implemented this
... kochi started this by sending a message for Blink
... saying he intends to implement
... and i understand he has a looks-good-to-me

chaals: Yandex, our primary market is Russian
... our users normally use a Russian keyboard
... we have UCs
... we have various IMEs that we build in JS in our various products
... so you can type in on a keyboard
... and we'll give Russian and English suggestions
... so you don't have to switch keyboards
... you can type a string of consontants
... and hit return
... and it will come out
... спасибо
... хорошо

Travis: microsoft had a chance to review the document

<Travis> Microsoft proposal: https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEProposal.html

Travis: quite a while ago
... and submitted feedback to the list
... a quick overview
... it took the ED
... proposed changes
... to have the suggestions window in the right place
... and functionality to retrieve suggestion candidates
... and some optimization suggestions
... and some feedback around ...

Janina: thanks
... to give you a high level overview
... those who are also in HTML
... a number of folks in PF are interested in Rich Text Editing
... Russian, Korean, Chinese, etc.
... we think the UCs
... should take in more UCs than the ones you've laid out
... and i'll ask jcraig from apple to lay out some others
... not everyone in PF thinks they want to work on it
... but there's a significant amount of interest to move forward
... thank you for the time.

MikeSmith: part of this is getting feature parity with other runtimes
... Flash gives you the ability to interact w/ the platform
... IMEs

jcraig: James Craig, Apple
... it's good you guys are working on this
... especially setEclusionRectange
... i think MS pointed out
... custom text editing is problematic
... for a lot of reasons beyond Pin-Yin and Romanji
... when you do things in a custom Canvas style text editor
... and you do it in WebGL
... it'll prevent certain things from working
... it'll prevent screen readers from working
... prevent dragon dictate
... -- which has "change this `word` to this `word`"
... if this is something specific to Canvas
... very specific to CJK input methods
... we think this should work along the lines in SetCarat for Canvas
... if it's intended for more than that
... then this isn't nearly enough
... we need range link
... set value for range
... figure out where the caret should be
... popup view
... get info about shape, position for suggestions
... if we're considering doing custom rich text editing
... more to be considered
... no way to do it in html
... there are ways to do it in every platform
... Google Docs has a completely custom view
... there's no way to do what they're doing in content editable
... they have no choice but to do custom views

<MikeSmith> is that Dominic Manzonni?

jcraig: we have no choice but to make it accessible to people w/ a variety of needs
... CJK, screen readers, magnification

Travis: to point out
... i shouldn't be speaking on behalf of the editors
... it doesn't appear the direction they're taking
... is to support custom rich text editing experiences
... seems like they're scoping that out
... more like supporting what system apis can do w/ regular text entry/text input
... MS has a strong view
... that you shouldn't use Canvas for rich text editing
... we understand it's being done that way, but it's a shame
... we'd rather spend effort to work on contentEditable

Dominic: not clear if it makes sense to compare ContentEditable w/ Canvas
... i looked at ACE
... Web Mirror
... a bunch of terminal emulators
... a bunch of text editors
... not a single one has focus in the native HTML input control
... everything uses an offscreen contentEditable

<sicking> +q

Dominic: sometimes an offscreen text area
... to capture typed text, and text pasted from the clipboard

<MikeSmith> fyi for the record, from the associated use-case document: https://dvcs.w3.org/hg/ime-api/raw-file/default/use-cases/Overview.html#editor

Dominic: an offscreen contentEditable is the only way to capture rich text
... the method to render is Canvas, SVG, etc.
... some support multiple
... these are widely prevelant
... it's important to support IMEs, accessibility for custom text editor components

<MikeSmith> https://dvcs.w3.org/hg/ime-api/raw-file/default/use-cases/Overview.html#custom-ime

jcraig: good to know they're phasing out canvas
... that's what i saw in the FPWD
... for a combo box where you need an exclusion rectangle
... we have ARIA rectangles
... if you're using standard markup controls
... with ARIA
... our main concern is
... if we're going for the simple case, it can be covered w/ existing technologies
... if we're going for Custom Text editors, we need much more

sicking: one of the problems we're trying to tackle as we're going to mobile
... is how we do keyboards in mobile
... they're dramatically different from desktop
... and there's lots of research
... and we want to enable people to build custom keyboards
... the only realistic solution i see is contentEditable
... i don't blame people for not using contentEditable
... it's completely unusable
... even google can't build a decent editor using it
... i'd encourage people that want to enable editing on the web
... help work on contentEditable
... we'd need lots more for Canvas to work
... each browser has a dramatically different implementation for contentEditable
... you have to write 4 different contentEditable implementations

<cyns> +1

sicking: if we specified it, we'd do much more for editing on the web
... than Canvas/SVG editing

<Zakim> MikeSmith, you wanted to ask about what CodeMirror, Cloud9, ACE are using

MikeSmith: i'm ignorant about how it's used in actual editors
... i know Cloud9 started out as BeSpin
... which was Canvas, but now they're doing them the right way
... we can excise Canvas from the UC document, it's gone, i checked
... there's a Canvas example in the spec
... we can remove that
... i don't think it's necessary anymore
... it was needed 2 years ago
... but are CodeMirror/Cloud9 legitimate?

<ArtB> ACTION: smith ask the IME Editors to remove Canvas examples (e.g. images) [recorded in http://www.w3.org/2013/04/25-webapps-minutes.html#action16]

<trackbot> Created ACTION-690 - Ask the IME Editors to remove Canvas examples (e.g. images) [on Michael[tm] Smith - due 2013-05-02].

Dominic: CodeMirror and ACE
... they do not use Canvas
... what you see visually is not the content of the focused contentEditable
... there's a separate visible contentEditable
... if you wrote js
... what the user sees is not what's being edited

MikeSmith: so they're not accessible?

Dominic: they're not

MikeSmith: we can't do that
... i wish kochi was here
... i can take that feedback back

chaals: so... strikes me
... you have a contentEditable where stuff is going on
... if you can look at that point
... you can do the work that the editor is doing
... when it takes the real interaction
... it strikes me that it would be feasible to make it work
... it might not be pleasant

jcraig: prior to my work on A11Y
... i worked on a contenteditable wiki server
... these are usually used for capturing selection, paste, dictation
... there's never any time when the entire document content is in the region
... it's usually an empty region
... the changes aren't reconcilable with the business logic
... being able to translate back in a consistent way

chaals: you'd need to replicate the business logic
... double procssing

<Zakim> jcraig, you wanted to say that the business logic for each web app is different, even the expected editing behavior per app would not be achievable with contenteditable

<MikeSmith> ACTION: Michael[tm] Smith to take back PFWG feedback to the IME API editor (Kochi) and propose we excise the mentions of DOM-based editor use-case in the use-case document, and the specific mentions of <canvas> in the actual spec [recorded in http://www.w3.org/2013/04/25-webapps-minutes.html#action17]

<trackbot> Created ACTION-691 - Smith to take back PFWG feedback to the IME API editor (Kochi) and propose we excise the mentions of DOM-based editor use-case in the use-case document, and the specific mentions of <canvas> in the actual spec [on Michael[tm] Smith - due 2013-05-02].

jcraig: keyboard behavior may act differently in a ToC
... if you're on a link
... the business logic is only known by the web app
... it isn't known by contentEditable

Dominic: i'm very much in favor of improving contentEditable
... but
... and we need to do that
... i've been playing around with it on the side
... you can get a fair amount of accessibility at a fair level
... but to me, they seem
... to mention one
... to scare everyone
... you can take a hidden contentEditable
... it's invisible, but you can position it whereever
... you can get the screen magnifier to follow it everywhere
... we're exploring that
... it's hard to get a short term solution
... for screen readers, to only care about one line of text
... it's possible to keep that line up to date
... but it's really difficult hacks
... we really need these apis
... we may need hundreds of apis
... ---
... any text like editor
... for IMEs, a11y, browser extensions
... think about what you could need

cyns: curious if a better editor would solve your needs

<Zakim> MikeSmith, you wanted to talk about use cases

MikeSmith: i'd like to make a concrete proposal
... we have a UC document
... this document is fairly minimal
... from what i'm hearing

<MikeSmith> https://dvcs.w3.org/hg/ime-api/raw-file/default/use-cases/Overview.html

MikeSmith: we need to remove a couple of UCs
... they aren't going to survive
... they won't get implemented
... the editors who've been working on this
... this is their first experience working in w3c
... their first experience w/ objections and getting implementations
... i need to help them understand it's unlikely to go forward on this
... there are 5 UCs

<cyns> my comment was "would a better editor plus and extensibility model for that editor meet your needs?"

MikeSmith: 1 - DOM based editor
... 5 - Web based app providing an IME
... 2 - Suggest
... 3 - to turn off IME (gaming that doesn't require text input)
... 4 - informational, like Flash -- talking to IME
... i think we need to remove 1 and 5
... and have spec focus on the middle 3
... can Travis speak to the doc?

Travis: there might be
... what you suggests sounds reasonable
... maybe we can add some

MikeSmith: and then see what survived in the spec
... we were focused on 5

chaals: we'd have a problem w/ removing 1 and 5
... comment was
... w/ IME spec, the goal is where the text gets dropped into whatever is taking text
... once you've started entering text, what do you do w/ it then?
... afaict, the IME has no influence there
... not a problem solved/broken, that's after the IME is done
... i understand that concern, it's important for editing APIs/contentEditable
... i don't think it crosses over w/ the IME API itself

Travis: what we've heard from A11y
... this is really good feedback
... it may have landed on the wrong group
... MS is interested in working on contentEditable
... we've sent a couple of messages to the list to generate ideas
... cases that are broken, trying to work up a solution

<Zakim> jcraig, you wanted to address use case 5

jcraig: re Travis
... Dominic and rich and ...
... contentEditable provides the equivalent of Wordpad
... not necessarily in a consistent form
... if it catches up
... there will always be a chase
... there will always be a legitimate UC for an engineer to decide contentEditable isn't good enough
... separate from IME, WebApps should consider direct access for text editing
... re overriding system IME
... and letting web app draw out completely
... i'd encourage you to allow it to

<ArtB> UC #5 [custom-ime] Enable a Web application to provide its own IME

jcraig: allow the screen reader to access the ime
... indicate particular character
... chaals, i heard you say once a candidate is inserted
... but during an insertion, characters may be inserted/removed as you continue typing
... maybe not in DOM, but in native input

chaals: if you take over system ime, you'd probably want to support talking to system ime
... and that's important
... and we should be aware of
... people are going to give them this IME, and they're going to make stuff that's broken and crap
... that's what freedom is for
... i'd encourage you guys to comment on the IME stuff
... file comments, keep talking to us
... about things you see potential concerns
... we aren't very good at A11y
... we put on a good dinner

jcraig: thanks for having us here

chaals: the editing case, isn't just the IME
... it's a much more constrained set of issues

jcraig: the IME is a subset
... of the larger issue

Travis: in a lot of editors, we get a temporary text area, where you're doing text input
... and finessing things
... and then that text gets reintegrated
... and that squirreled away text editing system isn't accessible

jcraig: not to screen readers, and only to Zoom and IME / dictation, w/ severe hacks

chaals: if your custom IME were talking to your system IME
... screen readers would be picking it up from the IME?
... you'd have to implement this well
... not automatic

jcraig: another example
... customized UI, visual UI
... vision impairments or cognitive impairments
... turn it off completely, that's something the UA should be able to override
... no you can't render you own ime

Dominic: i don't want to take the view that we shouldn't be doing this because it's incomplete
... one potential step forward
... if we wanted to get as much through for the IME UC
... take setCurrentRectangle
... it's minimally defined to provide the minimal needed for an IME
... let's define this in a more comprehensive way
... to provide info about the caret
... that an a11y agent would need
... we know a11y apis need this
... rather than a rectangle
... we need more when it's a selection
... could we extend the api a bit

chaals: we've run out of time
... thank you very much
... we encourage you to keep on providing comments
... i heard a requirement that the user must be able to turn off the app provided IME
... an a11y requirement

jcraig: i'd have to look, but that seems likely

chaals: we should anticipate
... giving people freedom to do crazy stuff
... they're likely to create problems
... "if you do this, the world will break"
... "so please don't"
... "here's the things it'd be helpful to avoid"

File API

arun: Arun, your friendly File API editor
... perhaps some things we should talk about in this meeting

<ArtB> File API ED

arun: what it would take to get File API to LC
... there's also a Mozilla proposal for a File System API
... it went out this morning

<ArtB> File API Bugs

arun: you can blame sicking for that
... there are 3 problems w/ the File API
... 1. thinking of the File API w/ new tech, like Futures
... that shouldn't be gating to LC
... we could do that in another draft
... perhaps the File object itself works in the futures API model
... that may be a candidate for another draft
... there are already things shipping with this
... 2. read chaining
... adrianba isn't here
... if you spawn multiple reads off a load event
... the firing of a loadend event can confuse the read
... i'm willing to look at that
... i think it's fairly simple to get it right
... - how to suppress loadend
... 3. blob urls are used across the platform
... for everything
... blob url lifetime issues aren't nailed down
... ms impl has slightly different syntax to automatically revoke blob urls
... to simplify developer's code
... so developers don't have to call revoke()
... the current proposal doesn't thrill anyone
... -- those are the three gating factors
... before LC
... questions?

[ silence ]

sicking: we sent well ahead of time this morning
... an email to the ML

[ laughter ]

sicking: which may surprise all of you
... that we've reconsidered our staunch disapproval of file system apis
... mozilla has always said no
... arguing Indexed DB solves existing UCs
... but others can be solved other ways
... two things

<ArtB> Mozilla's 25-Apr-2013 File system API proposal

sicking: 1. no one has solved these things that indexed db can't solve
... -- two things
... -- file system url has lots of nice properties
... -- you know which url you can access directly from the file system
... -- file system api supports in place editing
... -- predictable and persistent
... we have support for indexed DB
... but it hasn't gotten traction
... i wrote a blog about file system
... saying what it supports, what you think it does, but actually doesn't
... we got 3 pieces of feedback
... file systems as a concept is nice and understandable thing
... nice for web to have such an api
... easier to use than indexed db
... second: file system urls are nice
... third: we don't really like the current file system
... so we took another file system we already had
... we had discussions w/ people months ago
... which led to a counter proposal from apple
... and some people from mozilla and apple met up
... which led to this proposal
... no one has committed to implementing this proposal
... it's a few hours old
... we're interested in implementing it, if others are interested
... alternatively, we could try to solve these UCs using indexed db
... so far no one has
... interested in hearing what other people are thinking
... in particular apple

chaals: welcome to the 21st century

Travis: is this virtualized or real?

sicking: exactly the feature set that google is exposing to web pages
... it's a sandbox
... we wouldn't recommend any implementations implement on top of a file system
... we're intending to implement on top of a database
... possibly indexed db
... not intended to be mapped onto the underlying file system

Travis: what's the security boundary of the sandbox?
... who can access it?
... can you get file handles and share them through postMessage?

sicking: the intent is it's the same as indexed DB
... each origin has its own set of databases
... each origin has its own file system
... you can get file objects from the file system
... you could postMessage them
... file handle represents an open file
... we haven't proposed that you could pass those
... in theory, it might be possible
... something we could look at
... but not a pillar of this proposal

chaals: you don't allow sharing a real file between an app and another app
... or not?

sicking: that's what i'm saying

chaals: i take back what i'm saying

darobin: in sicking 's defense
... if there's a standardized way of storing content
... it means another app could talk to the UA
... so you could have a system wide way of an app discovering others files

chaals: if you had an OS not entirely based on your browser
... most of your apps couldn't share the files w/ the file system api
... that seems like you're losing a lot of the value of a file system
... this is just indexed db?

sicking: this is just indexed db
... many ways to envision the sharing between the file system api and the user
... in firefox os, we're doing something which lets the web page get access to the user's pictures folder
... and then it's mapped to the backend filesystem
... we have a way of addressing security
... not necessarily a good way
... we have a crappy solution involving signing and unwebby things
... it's what google tried to do
... where you guys were trying to back the sandbox file system and had issues

EricU: our sandbox file system, the files are backed by real files
... the directories are backed by a database
... the filenames are obfuscated
... flie extensions don't bleed to the file system
... the file system api allows you to get access to photos
... it's a great way to write web apps to access those things
... but it isn't something you want to expose to the drive by web
... you don't want a web page to write an executable to the photos directory
... we don't have a security solution
... we only allow for apps and extensions, presumably installed w/ informed consent

bryan: two suggestions
... have you considered, certainly domain-specific, origin-specific
... have you considered making a non-private portion
... for low risk data?
... and let the app decide what it wants to put there

sicking: we're looking at data sharing between apps
... and presumably something between web pages
... i don't think that's limited to file systems
... data sharing between apps
... is an interesting question, but orthogonal

bryan: the sharing of a file handle between applications
... i want to give this only application

sicking: same answer

chaals: take your point about exposing random access files to drive by web
... want to be careful
... but w/ those provisos

<bryan> it would be good to provide an option to create an open/shareable file space, or sharing of file handle with a specific app

chaals: a file system that doesn't let you use files
... of which there are a few deployed around the world
... is kind of missing something

sicking: looking forward to your counterproposal

chaals: opera sent it 6 years ago

sicking: it didn't get traction for a reason

chaals: it's like google's proposal
... for some value of trust, you can get at the file system

arun: it's different

chaals: it's 3 years older

darobin: designing a file system isn't rocket science
... it's security/sharing that's the problem
... sharing between apps
... sharing between web sites
... it's the super cookie from hell
... nothing prevents this api from accessing a real file system
... but the default should be virtual
... accessing the real/more should be outside for later

chaals: you can build this on top of a real file system

darobin: when we played with ideas like this in dap
... the basic api was virtualized
... and another api exposed the real file system
... which would allow whatever

arun: can i go back and talk about file api
... adrianba returned

[off the record ]

arun: the hard work is to find a technical solution for blob-uri lifetime management
... it might take ages

ArtB: ages is?

arun: not very long

sicking: in geological times

adrianba: there's a minor issue w/ events that get fired for rechaining
... the lifetime of blogs and revoking them is something we've talked about for a pretty long time
... lots of nuance to it
... part of the issue to resolve is what degree of interop do we need?
... how similar do we have to be
... if we have to be identical
... we probably can't solve it
... people's networks stacks work differently
... did you talk about same origin?

arun: no

adrianba: one of the properties of a blob uri created through createObjectURL()
... is that you can only dereference it in the same-origin
... there's been a request to relax it
... relying on the fact that the string itself shouldn't be guessable
... it would have to be passed, it wouldn't be predictable
... i'm open to exploring this possibility
... but in discussions we've had today
... we've always parked the discussion wrt origin
... we've always had this property that they had an origin constraint
... relaxing it isn't something i'd want to do lightly
... and i think we've made implementation optimizations
... removing it from the spec is easy
... changing our implementation is much more work
... my fear is we make interop much worse for a period of time
... it might be an IE thing
... but we've been working on it for a while, but that's been in the spec for a long time
... changing it before LC
... hopefully the final LC

arun: right now, there's no change made to the origin policy
... i think most UCs can be addressed w/o relaxing that
... so unless someone has a strong reason, i see no reason to change that
... and if that helps get to interop, that's fine

sicking: i'm a little split
... on one hand
... i have been convinced it's a silly restriction
... but
... this is essentially adding a new feature
... anytime you add a new feature, it decreases interop
... it's a feature that's harder to test for
... it seems like a feature we can live w/o for v1
... it's a scary thing to add for v2
... since it's relaxing for security
... but it's probably fine
... but if some site announces to the world any blob they generate
... and we relax
... but it's probably fine
... to do for a second version
... on File System
... mozilla's interested in implementing

EricU: i certainly agree with mozilla's arguments on the file system
... they're familiar since i said them three years ago
... but we've already got one
... it was designed by committee
... we've already got it
... we've already shipped it
... people are using it
... especially in our apps
... but also in web pages
... it doesn't use futures
... were i to design it today, it would probably look closer to sicking 's
... locking is very nice
... we don't have locking or flush
... but we didn't want to add more w/o interest in implementing
... we think it's good for the web to have a standard api
... and we want something implemented in all browsers
... but we already implemented one
... if mozilla and others implement
... i'd expect we'll implement
... but we'd be last

chaals: no, we're behind you

hober: similar thing
... you posted to the mailing list a couple of hours ago
... i'll commit to expressing an opinion soon

chaals: meetings with futures implemented

hober: yes, i'm returning a DOMFuture

chaals: arun thinks we're at a wrap

ArtB: anyone think we should move everything to futures?
... i'm not hearing support

arun: i'm willing to do a separate draft for Futures
... to not cramp this

ArtB: how much more hashing out do you need?

arun: rechaining is pretty straightforward
... tricky, but not as hard as bloburi
... bloburi, i'll have to talk more

adrianba: we'll have to talk more

ArtB: how long?

arun: i have a proposal, i'd like to see if it's ok
... if i get buy in, it won't take long
... but that hasn't historically happened

ArtB: have you put it to the list?

arun: not yet

chaals: we've run out of coffee

<chaals> heycam, can you call in for 10 min?

<heycam> yes

chaals: i'd suggest we get heycam in for a update w/ WebIDL

ArtB: wonsuk, can we do XHR and Progress to tomorrow?

wonsuk: ok

chaals: Progress has been pushed off until tomorrow
... we'll implement it with futures

WebIDL

chaals: heycam, welcome to webapps

heycam: i haven't done much on WebIDL in the last couple of months
... i've got a thousand unread emails in the folder
... i don't think there's much to get v1
... with its issues closed
... i split the spec into v1 and v2
... v2 was for new features
... i recon it'd only take a few weeks to get v1 ready for republication again
... once i've closed off all the issues

chaals: any likelihood of having a couple of weeks to do solid work
... in the next six months

heycam: i kind of plan to get back to solving some of these issues starting in a few weeks
... kinda scary after a few months of inaction
... starting say mid-May
... saying this puts more pressure on me

chaals: so, in 2 weeks
... you start work
... and end of May, i visit you

heycam: i'd like to look at the ML to see what needs to be done
... on the ML, there's been a lot of discussion of broader issues of IDL languages
... those things don't need to be solved immediately
... for v1
... those are conversations i've been ignoring recently
... i think they shouldn't hold up progress on WebIDL
... but in the future, we may look at them

chaals: but you're reasonably optimistic that before the end of June that we could have this kicking along and getting to REC
... i'm imagining a LC in late May
... and that draft is likely to be pretty solid, and don
... from there, we aren't expecting piles of changes

heycam: the spec, what's on TR
... implementations have been improved since it was published
... and have sent feedback
... whether there are other implementations around to help it go past CR
... i imagine a LC and then CR
... i'm wondering if there are enough implementations to progress the spec
... and also test suites

chaals: a key question is
... what's an implementation of WebIDL?
... lots of ways you can use it
... you can put it in browsers
... but other kinds of implementations are potential more interesting than having it in a browser

heycam: we talked about how to come up w/ a test suite
... a tentative plan was to select features from specifications that are relatively stable
... which covers the features of WebIDL
... and write tests for the WebIDL parts of those
... Node.type and test if it's a number in js
... i'm not sure if any work was done on that
... not sure if tests were written
... i know Travis had his hand up
... our goal for getting to PR
... is to demonstrate two interoperable implementations

chaals: to convince the director that this works interoperably

Travis: to convince the director, we convince him that there are two implementations that meet this
... we need a test suite
... i as test XX
... compose a test suite
... to demonstrate
... pieces from various specs
... snippets from various specs
... two aspects
... does a UA support webIDL
... and do blocks in specs conform
... the test suite has code to test webidl blocks
... there's a webidl harness
... and there's tests to confirm that valid input produces good output
... and to confirm that invalid input produces bad output
... we don't have tests against browsers
... i unfortunately have made as much progress as you

plh: i thought idlharness.js could prove that all the things in the spec are well implemented in UAs

heycam: yes

plh: the problem w/ that so far
... is that idlharness isn't complete
... darobin wrote an updated parser for WebIDL
... not sure how much changes by heycam affect that
... but we don't have something that takes the output of the parser to generate tests
... as part of the testing effort mentioned in HTML F2F
... we want to develop infrastructure
... we have an item to finish idlharness
... deadline was before end of year

heycam: what sort of things does it test currently?

plh: idlharness will take some webidl
... and generate testharness.js
... based on it
... in navigation timing test suite
... you'll see idlharness
... it takes the webidl from navigation timing
... and generates js based on that

<smaug> http://mxr.mozilla.org/mozilla-central/source/dom/imptests/webapps/DOMCore/tests/approved/test_interfaces.html?force=1 seems to use idlharness.js

plh: to make sure the assumptions we can make based on the webidl

heycam: it can't rely on functionality of particular methods

plh: i don't know

heycam: what coverage do we get from that idl harness?
... that means we don't have to write explicit tests
... it could generate tests for some things
... but for some functionality
... you'd need to do by hand, based on what the methods/properties do
... to see if they convert arguments correctly

darobin: we can't cover everything
... it tests a lot of interesting things
... it catches bugs
... there isn't a single implementation that passes
... it uses the updated parser
... i gets up to date web idl
... a few things we haven't implemented support for yet
... some things you can't know w/o reaching inside the implementation
... you can test everything that's surfaced

heycam: would you want to use the output of this as the basis of the browser test suite?

darobin: yes

glenn_: in editing of CSS OM
... i created a preprocessor that
... allows taking webidl definitions of apis
... putting them in separate idl files
... i use darobin 's earlier webidl parser
... which validates them according to that syntax
... and inserts them into an html file
... that creates the Anolis version of the document
... and for tests of CSS OM, we've written tests that test what's required by the webidl
... two things
... 1. verify validity of webidl used in the spec
... 2. verify implementation of things using it

heycam: yes

chaals: can't we use the validator as an implementation?

plh: that's possible

chaals: we need to show that this stuff actually works
... and is widely implemented
... if the group looks at this stuff and says it's implemented all over this place, and it works
... then for some definition, it's considered interoperability.
... open question if we let that go as v1

<darobin> idlharness.js

chaals: to get it out the door
... and fix bugs we find later

ArtB: in terms of validators, don't we have two?
... darobin 's and dom's?

sicking: we have our own webidl parser

Travis: IE has one too

krisk: i concur

ArtB: can you look at the exit criteria and see if we've met it with these imeplementations

plh: two parts
... one is syntax
... one is bindings
... IE+Mozilla can convince "yes we have"
... but you may not convince the Director that you have the ES bindings right

Travis: idl harness takes webidl syntax as input
... and the output is testcases
... does it convert null into "null"

<plh> http://w3c-test.org/webperf/tests/approved/UserTiming/idlharness.html

<darobin> [heycam: here's an example http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/tests/submissions/Ms2ger/interfaces.html]

plh: it generates tests based on webidl
... is it a function

sicking: you can't possibly write tests that call when you call X and it expects a string
... that it behaves the same way with "foo", {valueOf:function(){return "foo"}
... those can't be tested automatically

plh: you can at least check the signature

ArtB: look at Web Storage
... what does Storage.clear() do for a test

sicking: do you ensure that clear("xxxx") behaves the same as clear() ?
... or removeItem("42") behaves the same as removeItem(41+1)

plh: we may have to test some manually
... the goal is to prove this construction is properly implemented

sicking: if we can for each webidl construct
... two implementation
... that all properties are present
... but we'd have to hand write coercion testing

Travis: i think there will be a small change in the testing plan
... the harness can test some pieces

heycam: getAttribute make it easy to write some tests
... but you can't automatically generate
... but the right plan is
... identify testable w/ JS bindings
... identify which things idlharness can cover
... and then write the less

chaals: and Travis, you'll get it by TPAC?

Travis: i'll coordinate w/ darobin and plh
... we'll work on what additional functionality needs to be put into the harness

chaals: and then work and ship it
... thanks heycam

[ Adjourned until tomorrow ]

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/ArtB, anything interesting today?//
Succeeded: s/Ms2ger: no, we're just going to do some work.//
Succeeded: s/Not that I hear anything//
Succeeded: s/--Ms2ger//
Succeeded: s/So we're the only attendees?//
Succeeded: s/Was that you?//
Succeeded: s/yup//
Succeeded: s/Seems to be a bit of noise on the line :)//
Succeeded: s/PF WG/PF WG to talk about IME/
Succeeded: s/3:30pm/3pm/
Succeeded: s/That's something//
FAILED: s/did you hear now something :)//
Succeeded: s/did you hear now something :)//
Succeeded: i|w3|topic: Dashboard / PubStatus
Succeeded: s|s///||
Succeeded: s/did you hear now something/XX/
Succeeded: s/Alpha/Aurora/
Succeeded: s/scribenick: timeless//
Succeeded: s/scribe: Josh_Soref//
Succeeded: s/yes/yeS/
Succeeded: s/yes//
Succeeded: s/yeS/yes/
Succeeded: s/tod/tod [Github]/
Succeeded: s/inerop/interop/
Succeeded: s/arond/around/
Succeeded: s/russel/russell/
Succeeded: s/fake_alex_russell/@FakeAlexRussell/
WARNING: Bad s/// command: s//[ Break ]/
Succeeded: s/corry_johnson: corry johson/Corey_Johnson: Corey_Johnson/
Succeeded: s/mat_tod: mat tod/Matt_Todd: Matt Todd/
Succeeded: s/Corey_Johnson: Corey_Johnson/Corey_Johnson: Corey Johnson/
Succeeded: s/i/you/
Succeeded: s/Eve/Yves/
Succeeded: s/->//
Succeeded: s/http/-> http/
Succeeded: s/R/r/
Succeeded: s/->//
WARNING: Bad s/// command: s/http:/-> http://
Succeeded: s/https/-> https/
Succeeded: s/html/html Disposition of Comments/
Succeeded: i/gives you/chaals: you probably won't have comments anyway
Succeeded: s/->//
Succeeded: s/https/-> https/
Succeeded: s/ii/i/
FAILED: s/samug/smaug/
Succeeded: s/IDL/IDB/
Succeeded: s/->//
Succeeded: s/https/-> https/
Succeeded: s/->//
Succeeded: s/http/-> http/
Succeeded: s/->//
Succeeded: s/http/-> http/
FAILED: s/HTML, _and_ TC39//
Succeeded: s|s/HTML, _and_ TC39/||
Succeeded: s/HTML/HTML, _and_ TC39/
Succeeded: s|https://bugs.webkit.org/showdependencytree.cgi?id=52962&hide_resolved=1||
Succeeded: s/http/-> http/
Succeeded: s/=1/=1 Dependency tree for dglazkov 's work/
Succeeded: s/S/s/
Succeeded: s/ie/ies/
Succeeded: s/dglazkov:/.../
Succeeded: s/Topic: CSP/Topic: Web Components Security Model/
Succeeded: s/wseltzer/scribe/
Succeeded: s/XXXX/IME with PF/
Succeeded: s/cont/count/
Succeeded: s/thank/... thank/
Succeeded: s/../.../
Succeeded: s/htlm/html/
Succeeded: s/lbe/ble/
Succeeded: s/XXXX/a contenteditable wiki server/
Succeeded: s/should override/should be able to override/
Succeeded: s/vision impairments/vision impairments or cognitive impairments/
Succeeded: s/giving/... giving/
Succeeded: s/ou/you/
Succeeded: s/File API/File system API/
Succeeded: s/sciense/science/
Succeeded: s/S/s/
Succeeded: s/(early July)//
Succeeded: s/analis/Anolis/
Succeeded: s|[idlharness.js is here: https://github.com/w3c/testharness.js]|-> https://github.com/w3c/testharness.js idlharness.js|
Succeeded: s/write/right/
Succeeded: s/Topic: Charter Discussion//
Found Scribe: Josh_Soref
Found ScribeNick: timeless
Present: Art_Barstow Charles_McCathieNevile Josh_Soref Yves_Lafon Bin_Hu Tyler_Barton Israel_Hilerio eliot adrianba Glenn_Adams Wonsuk_Lee Laszlo_Gombos aizu Olli_Pettay Ms2ger Jonghong_Jeon MikeSmith YosukeFunahashi Jungkee_Song Jae Chung Travis_Leithead hober Bryan_Sullivan Philippe_Le_Hegaret Jonas_Sicking Eric_Uhrhane dglazkov tantek Jeff Travis Lyle plh krisk David_Grogan Daniel_Austin Alec_Flett Corey_Johnson(GitHub) Matt_Todd(GitHub) Joshua_Bell Lyle_Troxell(4D) Arnaud_Braud Lyle_Troxell Arun_Ranganathan Gary_Kacmarcik Jin_Peng Sam_Weinig Robin_Berjon Daniel_Veditz Brad_Hill Wendy_Seltzer David_Rogers Adam_Barth eliot_graff Mark_Sadecki Cameron_McCormack_(heycam)
Agenda: http://www.w3.org/wiki/Webapps/April2013Meeting
Found Date: 25 Apr 2013
Guessing minutes URL: http://www.w3.org/2013/04/25-webapps-minutes.html
People with action items: about ask barstow cfc chaals comment d3e document e.g. eliot for idb lc michael needs next of pointerlock pubstatus smith start step tina tm tracking travis update vincent what