Draft minutes: 25 April 2013 f2f meeting

The Draft minutes from WebApps' April 25 f2f meeting are at the 
following and copied below:

<http://www.w3.org/2013/04/25-webapps-minutes.html>

If you have corrections, comments, etc., please reply by May 2.

Thanks very much to Josh Soref for once again being an excellent Scribe!

-AB

    [1]W3C

       [1] http://www.w3.org/

                                - DRAFT -

                     Web Applications WG f2f Meeting

25 Apr 2013

    [2]Agenda

       [2] http://www.w3.org/wiki/Webapps/April2013Meeting

    See also: [3]IRC log

       [3] http://www.w3.org/2013/04/25-webapps-irc

Attendees

    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)

    Regrets
    Chair
           Art, Charles

    Scribe
           Josh_Soref

Contents

      * [4]Topics
          1. [5]Introductions
          2. [6]Agenda
          3. [7]Dashboard / PubStatus
          4. [8]App Manifest
          5. [9]AppCache
          6. [10]Indexed DB
          7. [11]DOM3 Events - Status Update
          8. [12]Web Components
          9. [13]Web Components Security Model
         10. [14]CORS
         11. [15]CSP
         12. [16]IME with PF
         13. [17]File API
         14. [18]WebIDL
      * [19]Summary of Action Items
      __________________________________________________________

    <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
    [20]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
    [21]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
    [22]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
    [23]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
    [24]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
    [25]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
    [26]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
    [27]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
    [28]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> [29]http://manifest.sysapps.org/

      [29] http://manifest.sysapps.org/

    sicking: and a Runtime specification

    <JonathanJ> [30]http://runtime.sysapps.org/

      [30] 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":
    [31]http://support.mozilla.org/en-US/kb/pinned-tabs-keep-favori
    te-websites-open

      [31] 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>
    [32]http://www.w3.org/wiki/System_Applications_WG:_Manifest

      [32] 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
    [33]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> [34]Jonas' AppCache proposal

      [34] http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0977.html

    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>
    [35]http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html
    Indexed DB ED

      [35] http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html

    <jsbell> [36]Disposition of Comments

      [36] https://dvcs.w3.org/hg/IndexedDB/raw-file/tip/IndexedDB%20Disposition%20of%20Comments.html

    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
    [37]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> [38]IDB Open Bugs

      [38] https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=Indexed%20Database%20API&resolution=---&list_id=8909

    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>
    [39]https://www.w3.org/Bugs/Public/show_bug.cgi?id=21801

      [39] https://www.w3.org/Bugs/Public/show_bug.cgi?id=21801

    jsbell: 21555

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

      [40] 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> [41]DOM 3 Events Bugs

      [41] https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=DOM3%20Events&resolution=---

    Travis: please don't raise any concerns or questions

    <ArtB> [42]Open Issues

      [42] http://www.w3.org/2008/webapps/track/products/2

    Travis: we did a LC

    <ArtB>
    [43]http://www.w3.org/2008/webapps/wiki/DOM3Events#Last_Call_Co
    mments -> LC Comment Tracking for D3E

      [43] http://www.w3.org/2008/webapps/wiki/DOM3Events#Last_Call_Comments

    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> [44]Web Components Explainer/Intro

      [44] http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html

    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> [45]HTML Templates

      [45] http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html

    MikeSmith: cool

    <ArtB> [46]Shadow DOM

      [46] http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html

    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>
    [47]http://www.w3c-test.org/webapps/ShadowDOM/tests/submissions
    /Google/

      [47] 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> [48]Custom Elements

      [48] https://dvcs.w3.org/hg/webcomponents/raw-file/default/spec/custom/index.html

    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
    [49]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
    [50]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> [51]HTML Imports

      [51] https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/imports/index.html

    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
    [52]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
    [53]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> [54]Web Components Bugs

      [54] https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=Component%20Model&resolution=---&list_id=8922

    <dglazkov> [55]Dependency tree for dglazkov 's work

      [55] http://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14972&hide_resolved=1

    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> [56]Custom Elements

      [56] https://dvcs.w3.org/hg/webcomponents/raw-file/default/spec/custom/index.html

    [ 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> [57]Daniel Buchner re CSP and Web Components

      [57] http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0089.html

    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> [58]Custom Element using script example

      [58] https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html#custom-element-section

    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>
    [59]https://dvcs.w3.org/hg/ime-api/raw-file/default/use-cases/O
    verview.html#suggest

      [59] 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:
    [60]https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEPr
    oposal.html

      [60] 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:
    [61]https://dvcs.w3.org/hg/ime-api/raw-file/default/use-cases/O
    verview.html#editor

      [61] 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>
    [62]https://dvcs.w3.org/hg/ime-api/raw-file/default/use-cases/O
    verview.html#custom-ime

      [62] 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
    [63]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
    [64]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>
    [65]https://dvcs.w3.org/hg/ime-api/raw-file/default/use-cases/O
    verview.html

      [65] 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> [66]UC #5 [custom-ime] Enable a Web application to
    provide its own IME

      [66] https://dvcs.w3.org/hg/ime-api/raw-file/default/use-cases/Overview.html#custom-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> [67]File API ED

      [67] http://dev.w3.org/2006/webapi/FileAPI/

    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> [68]File API Bugs

      [68] https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=File%20API&resolution=---

    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> [69]Mozilla's 25-Apr-2013 File system API proposal

      [69] http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0382.html

    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>
    [70]http://mxr.mozilla.org/mozilla-central/source/dom/imptests/
    webapps/DOMCore/tests/approved/test_interfaces.html?force=1
    seems to use idlharness.js

      [70] http://mxr.mozilla.org/mozilla-central/source/dom/imptests/webapps/DOMCore/tests/approved/test_interfaces.html?force=1

    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> [71]idlharness.js

      [71] https://github.com/w3c/testharness.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>
    [72]http://w3c-test.org/webperf/tests/approved/UserTiming/idlha
    rness.html

      [72] http://w3c-test.org/webperf/tests/approved/UserTiming/idlharness.html

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

      [73] 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 ]

Summary of Action Items

    [NEW] ACTION: barstow ask Kinuko about status and plans for
    Quota Mangement API [recorded in
    [74]http://www.w3.org/2013/04/25-webapps-minutes.html#action05]
    [NEW] ACTION: barstow ask Lachlan if he has some impl data re
    Selectors API v2 [recorded in
    [75]http://www.w3.org/2013/04/25-webapps-minutes.html#action06]
    [NEW] ACTION: barstow ask Tina to remove the IE column from the
    SSE implementation report [recorded in
    [76]http://www.w3.org/2013/04/25-webapps-minutes.html#action07]
    [NEW] ACTION: barstow ask Vincent about next step for
    PointerLock (e.g. what needs to be done to go LC) [recorded in
    [77]http://www.w3.org/2013/04/25-webapps-minutes.html#action04]
    [NEW] ACTION: barstow start a CfC for FPWD of UI Events (and
    make sure it has a Bugzilla component) [recorded in
    [78]http://www.w3.org/2013/04/25-webapps-minutes.html#action08]
    [NEW] ACTION: barstow start a CfC to move Java bindinings for
    WebIDL to WG Note [recorded in
    [79]http://www.w3.org/2013/04/25-webapps-minutes.html#action03]
    [NEW] ACTION: barstow start a CfC to publish FPWD of Custom
    Elements [recorded in
    [80]http://www.w3.org/2013/04/25-webapps-minutes.html#action13]
    [NEW] ACTION: barstow start CfC for FPWD of HTML Imports
    [recorded in
    [81]http://www.w3.org/2013/04/25-webapps-minutes.html#action14]
    [NEW] ACTION: barstow start CfC to publish new WD of the Web
    Components Explainer [recorded in
    [82]http://www.w3.org/2013/04/25-webapps-minutes.html#action15]
    [NEW] ACTION: barstow update Pubstatus of D3E to reflect Gary's
    participation in Editing and Testing [recorded in
    [83]http://www.w3.org/2013/04/25-webapps-minutes.html#action12]
    [NEW] ACTION: barstow work with Alex and Chaals re interop data
    for Web Messaging [recorded in
    [84]http://www.w3.org/2013/04/25-webapps-minutes.html#action09]
    [NEW] ACTION: barstow work with Chaals on a call for editor
    help for DOM4 [recorded in
    [85]http://www.w3.org/2013/04/25-webapps-minutes.html#action01]
    [NEW] ACTION: chaals to make a CfC for joint work with sysapps
    on webapp manifests [recorded in
    [86]http://www.w3.org/2013/04/25-webapps-minutes.html#action10]
    [NEW] ACTION: eliot update IDB LC comment tracking document to
    replace "TBD" with something more descriptive [recorded in
    [87]http://www.w3.org/2013/04/25-webapps-minutes.html#action11]
    [NEW] 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
    [88]http://www.w3.org/2013/04/25-webapps-minutes.html#action17]
    [NEW] ACTION: smith ask the IME Editors to remove Canvas
    examples (e.g. images) [recorded in
    [89]http://www.w3.org/2013/04/25-webapps-minutes.html#action16]
    [NEW] ACTION: travis resolve last bug for DOM P&S and notify
    Art so a CfC for LC can be started [recorded in
    [90]http://www.w3.org/2013/04/25-webapps-minutes.html#action02]

    [End of minutes]

Received on Friday, 26 April 2013 04:44:31 UTC