Draft minutes: 11 November 2013

The Draft minutes from WebApps' November 11 f2f meeting [Agenda] are at 
the following and copied below:


Corrections, comments, etc., are welcome.

Thanks very much to the various scribes.


[Agenda] <http://www.w3.org/wiki/Webapps/November2013Meeting>


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

                                - DRAFT -

                     WebApps F2F Meeting @ TPAC 2013

11 Nov 2013


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

    See also: [3]IRC log

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


           +1.503.264.aaaa, [IPcaller], Shenzhen, +1.503.264.aabb,
           James_Craig, Rich_Schwerdtfeger, Art_Barstow, aizu,
           Arnaud_Braud, Mete_Balci, Chaals_Nevile, Jungkee_Song,
           Bryan_Sullivan, Jonas_Sicking, Cameron_McCormack,
           Adam_Boyet, Adrian_Bateman, Daniel_Austin, Ed_OConnor,
           Elit_Graff, Gary_Kacmarcik, James_Graham, Ryosuke_Niwa,
           Travis_Leithead, Paul_cotton, Xiaoqian_Wu, Robin_Berjon,
           Takayoshi_Kochi, Kinuko_Yasuda, Anne_van_Kesteren,
           Alex_Russell, Richard_Tibbett, Mark_Nottingham,
           Dirk_Schulze, Rik_Cabanier

           Art, Chaals

           Cameron, Travis_, Travis


      * [4]Topics
          1. [5]Agenda bashing
          2. [6]PubStatus
          3. [7]SSE status
          4. [8]Charter Status
          5. [9]IME
          6. [10]Joint Meeting with IndieUI WG
          7. [11]DOM 3 Events & UI Events
          8. [12]D3E and UI Events
          9. [13]Quota API
         10. [14]ServiceWorkers
         11. [15]Streams
         12. [16]XHR and Progress Events
         13. [17]WebIDL
         14. [18]Readonly/ writeable interfaces
      * [19]Summary of Action Items

    <tomoyuki> +Present Tomoyuki_Shimizu

    <tomoyuki> -Present Tomoyuki_Shimizu

    <ArtB> ScribeNick: heycam

    <ArtB> Scribe: Cameron

Agenda bashing

    chaals: we have a couple of items already fixed
    ... at 1:30 the Indie UI people will come and talk to us
    ... they sent us a new proposal
    ... they'll talk about that
    ... at 5:00pm we have a couple of things locked in
    ... there's also a pile of topics we want
    ... DOM 3 Events, File API, ....
    ... we have a couple of requests to have Streams/XHR
    discussions after lunch, not between 2 and 2:30
    ... I suggest we push them later
    ... any preferences for discussing any topics?

    shepazu: I think for people who aren't native English speakers,
    we're on IRC
    ... anyone need help getting started with that?
    ... IRC is helpful as the scribe types what everyone is saying
    ... find me and I can help you

    chaals: so Streams and XHR, between those two do we want an
    ... half an hour each?
    ... jungkee does that sound right?

    jungkee: I also want to join Sys Apps for service worker
    introduction, which will happen this afternoon
    ... I don't really know what time that will be
    ... I'll speak to the SysApps chairs to organise a time
    ... so I'm OK with that
    ... can I talk about Progress Events at the same time?

    chaals: yes
    ... do we want to talk about URLs?
    ... next, Interop and Testing issues
    ... tomorrow afternoon

    ArtB: I can't get to the page right now; we have I think about
    6 specs that are in CR right now
    ... including Progress Events
    ... for each of those I'd like to get a sense of where we're
    going with those
    ... who's interested in helping, what are the issues
    ... that's a bit different from the block set aside for
    tomorrow afternoon
    ... jgraham agreed to split that session into the test
    framework we use, reviewing tests
    ... and the second half creating tests
    ... for today's agenda, interop and testing, I think I'd rather
    do that tomorrow morning

    chaals: we can more or less randomly distribute the rest of the
    ... unless someone has a preference
    ... so let's just put them in in the order they appear
    ... we have DOM 3 Events, File APIs, IME API, Quota API
    ... Streams/XHR we've already git
    ... and UI Events

    Travis_MSFT: I think we can probably combine the discussion on
    DOM 3 Events with UI Events
    ... so don't need separate blocks for those

    chaals: should we just do that first?
    ... first we'll go through all of our specs
    ... for a status update; then we'll deal with the specs that
    need discussion
    ... first will be DOM 3 Events & UI

    ArtB: that OK Gary?

    gary: sounds fine

    Travis_MSFT: can we do that in the afternoon? I want to attend
    WebRTC in the morning

    <paulc> Time difference between Shenzhen and Eastern Time is
    currently + 13 hours.

    sicking: if we can do it early he could call in. 11:30.

    chaals: IME at 12?

    ArtB: we need Mike Smith for that

    chaals: let's put it provisionally at 12

    gary: he's busy in the Testing thing

    ArtB: Quota API at 14:30
    ... will we do the File System API at the same time as File

    sicking: yes

    hober: Mike is fine for that time

    <shepazu> /me can people on the phone hear us?

    <wayneCarr> heard nothing before


    <wayneCarr> can hear now but not understand

    chaals: we'll go through each of the specs we work on

    <ArtB> [20]http://www.w3.org/2008/webapps/wiki/PubStatus

      [20] http://www.w3.org/2008/webapps/wiki/PubStatus

    chaals: the first spec is AppCache NG
    ... we have a proposal from Jonas
    ... and we have Service Workers that Alex is working on
    ... do we know what his plan is?

    ArtB: jungkee you said Alex was going to go through it at
    ... can we get him to present here?

    jungkees: SysApps WG is working on some runtime design and
    speccing etc.
    ... and now a concept like Google's Event Page has been
    proposed at the last F2F
    ... after that, Marcos from Mozilla proposed we align our
    efforts with Service Workers
    ... since that covers basically the same requirements and use
    ... making the application offline
    ... so that's the bottom line
    ... the co-chair of SysApps invited Alex Russell to introduce
    his Service Worker work this afternoon
    ... I heard that Alex has a meeting with the TAG this morning
    ... not sure about the schedule

    chaals: we have an open session at 3pm
    ... can we do that together with Sys Apps then?

    jungkees: I think that'd be really nice
    ... SysApps are also talking about an application model

    jungkee: SysApps' charter was for application manifests, etc.
    like on FirefoxOS
    ... IMO they are two different ways of implementing the same
    ... for offline webapps
    ... so at some point we need to talk about that together

    chaals: let's hope to do that at 3pm
    ... next items is CORS
    ... we don't have Anne

    ArtB: I talked to Wendy a bit about this
    ... Brad is trying to organise a call with the Director
    ... the sticking point will be normative references
    ... one of which is to the Fetch spec
    ... not sure how that will be resolved
    ... hopefully PR will be published by the end of this month

    chaals: next, Clipboard APIs and events
    ... we don't have Hallvord

    <ArtB> ACTION: dimitri reply to Ryosuke's comments re Custom
    Element as part of LC comments [recorded in

    <trackbot> Created ACTION-700 - Reply to ryosuke's comments re
    custom element as part of lc comments [on Dimitri Glazkov - due

    <ArtB> ACTION: barstow start a CfC to publish LCWD of DOM
    Parsing and Serialization [recorded in

    <trackbot> Created ACTION-701 - Start a cfc to publish lcwd of
    dom parsing and serialization [on Arthur Barstow - due

    chaals: it's in work still?

    ArtB: on Oct 17 Hallvord sent a status email
    ... requesting developer feedback
    ... nearly right to go to LC, still some bugs open
    ... only Firefox implements the whole spec, some partial
    ... an action for Chaals and I to chase those bugs down

    chaals: custom elements in in LC
    ... comments due by 21st

    travis: generally do we have any Web Components discussions

    rniwa: we have sent some comments
    ... for Custom elements about declarative syntax
    ... we have an issue with the register function taking a
    ... there's no guarantee that the prototype is an HTML element
    ... you could inherit from random HTML elements which also
    could be a concern
    ... I'd like some time to talk about these issues

    chaals: we don't have Dmitry here
    ... next, DOM Parsing & Serialization

    travis: I havent' seen any activity in about a year
    ... maybe we should just consider moving it along to LC/CR and
    see if it brings up any feedback?

    ArtB: do you want to fix this one bug before LC?

    travis: I think it's already fixed in the Living Standard
    ... I just need to do the work
    ... LC next week maybe?

    chaals: CfC for LC next week

    paulcotton: to go back to DOM 3, are you having a meeting with
    the Indie UI people?
    ... there's an overlap between the Indie & PF consistuency
    ... they've asked for an agenda item in HTML on the
    relationship between DOM 3, DOM 4 and UI Events
    ... I wonder if it might make sense to bundle that with the
    Indie UI item this afternoon

    gary: I don't mind covering that
    ... I won't be around on Thursday
    ... so definitely on Monday/Tuesday

    chaals: I think it is a 2 min discussion

    shepazu: 15-30 mins
    ... I don't think there's a 2 min discussion. it'll take 5 mins
    to get settled in etc.
    ... there'll be information shared on both sides

    ArtB: we have D3E right after Indie UI
    ... we can go right into that

    chaals: we hope it'll fit in to the agenda
    ... File API we will discuss after the break
    ... next: Full Screen API
    ... do we know anything about that?
    ... no Tantek

    ArtB: if anyone is willing to work on the W3C's version of
    Anne's Full Screen spec let me or Chaals know about it
    ... Game Pad, we don't have Scott/Ted in the room
    ... the WG members know I attempted to get status in advance
    for this meeting
    ... Ted did reply that the spec is being implemented by at
    least Gecko
    ... is there interest from other vendors?
    ... I know Scott works for Google
    ... any idea about interest in implementation in Chrome? IE,
    ... do you WebKit guys have something like the Chrome Status

    rniwa: we don't plan to implement Gamepad
    ... I think there was some suggestion in the past in the WebKit
    community, but I don't think we have a plan or a proposal to

    ArtB: one reason for having this conversation is about process
    ... chaals has been working on getting testing/requirements
    done earlier in the W3C Process
    ... I'm just trying to get a sense on this one
    ... sounds like it might be iffy moving forwards

    adrianba: so we've looked at the spec
    ... it doesn't necessarily map to the way we think about
    ... I know we've thought about how some of the aspects of
    gamepad, and the buttons etc., mesh with something like DOM
    ... so we don't have any plans for this specific API
    ... it's an area we've been thinking about
    ... i don't have anything else right now

    gary: one comment to add, from the DOM 3 perspective, looking
    at the keyboard events
    ... we assumed some sort of gamepad api would take over for
    joystick buttons etc.

    shepazu: an earlier draft did consider it

    adrianba: I wasn't suggesting for DOM 3, since we want to get
    that done
    ... there's some thinking around multiple users using a common
    ... and if there's more than one keyboard device provided, you
    might want to take presses from different places
    ... gamepad takes a simpler model

    gary: with buttons, we wanted that to happen
    ... e.g. click events to fire for buttons
    ... a recent change in DOM 3 click and dblclick events are
    fired only for the primary button
    ... so that doesn't work for gamepad, with a dozen buttons
    ... that's another area where DOM 3 isn't going to work for
    gamepad inputs

    chaals: HTML Imports
    ... Dmitry says the essence might go into HTML
    ... IndexedDB we'll talk about tomorrow
    ... IME later today
    ... Pointer Lock, we're in LC
    ... if you have a comment on that spec, please make it
    ... well before the end of this month
    ... do we know impl status for that?

    ArtB: I don't have a link to the latest effort

    chaals: progress events we'll come back to
    ... Push API
    ... Bryan Sullivan?

    bryan: the status is accurate
    ... Art asked a question on the list
    ... I don't know that we have anybody specifically signed up to
    be a test facilitator
    ... afaik no tests have been created yet
    ... afaik Mozilla is still working on an implementation, for
    Firefox OS?
    ... the PAG has done their report
    ... I think the spec has been pretty stable, for several months
    now, no outstanding bugs
    ... not much traffic on the list
    ... just trying to get through the PAG phase
    ... and the PAG report was that the exclusions didn't read upon
    the spec

    sicking: there's two challenges
    ... the first is that the first spec we did, that the PAG
    looked at, is significantly different from the current draft
    ... don't know if that's important

    chaals: the general principle is, if you change the spec
    between FPWD and LCWD, when you CfE again at last call, people
    may exclude patents against the new bits of work
    ... whether that happens or not...
    ... I think the PAG actually looked at the spec as it is now

    <paulc> test

    <bryan> scribenick: bryan

    <ArtB> Scribe+ Bryan

SSE status

    topic for tomorrow

    Shadow DOM, working...

    chaals: Screen Orientation API, TAG has issues with it...
    ... URL spec, chaals is editor and no change in 6 months. not a
    massive lot ot work to do, but some horrible edge cases.
    co-editor welcome. expect help on URLs from IETF
    ... Web IDL, an hour this afternoon
    ... Web Manifest, a work of webapps and sysapps. Marcos
    indicated there is some research to do. A joint meeting will be
    ... Web Storage, at REC. Hixie is making changes to his
    version. Any interest in the next version?
    ... taking an errata approach, we are required to note them but
    bothering to do something is another decision

Charter Status

    chaals: charter expires in 6 months. proposed changes is to
    remove stuff.

    artb: no proposed additions at this time.

    <jeff_> Doug, can we get a link to the Charter?

    <heycam> @@ [continuing on Push API after "I think the PAG
    actually looked at the spec as it is now"] ... not the initial

    <heycam> bryan: that's correct

    <heycam> ... the spec as it stands now is considerably simpler
    than it was at FPWD

    <heycam> chaals: the assumption is the risk of further
    exclusion is reduced

    <heycam> sicking: the other challenge is, while we're defining
    an API, it's actually undefined how to fire a callback

    <heycam> ... the best idea we have is to use service workers

    <heycam> ... seems like it's going to be hard to get to Rec
    without Service Workers

    <heycam> bryan: it also depends on DOM 4

    <heycam> ... the events are based on Promises

    <heycam> travis: Promises definition is moving to the ES spec

    <heycam> ... so might be slightly easier to depend on there

    <heycam> shepazu: I think it was accepted into the next draft
    of ES6 @@ [end of previous discussion on Push API]

    adrianba: can we just ask for an extension?

    <ArtB> [23]http://www.w3.org/wiki/Webapps/Charter

      [23] http://www.w3.org/wiki/Webapps/Charter

    <shepazu> [24]http://www.w3.org/2010/webapps/charter/

      [24] http://www.w3.org/2010/webapps/charter/

    chaals: we may have some work per results from the supergroup
    discussion underway in AC

    <shepazu> oops, [25]http://www.w3.org/2012/webapps/charter/

      [25] http://www.w3.org/2012/webapps/charter/

    chaals: any other items we want to fold back in?
    ... we could request an extension if it will make life easier,
    but a proper charter is better and not that hard

    shepazu: suggest to push the boundaries re what is allowed in
    the charter for a supergroup

    chaals: that work started last week and we don't know what will
    result. another issue raised was the doc license; should we
    follow HTML example, or wait for theirs to complete
    ... if we push for open doc license earlier its unclear what
    would happen - W3C and members need to decide what they would
    like on this

    jgraham: tomorrow afternoon there will be a session on testing;
    with agenda (1) reviewing - this group has a large backlog
    ... (2) writing tests

    jeff: back on the charter; did not see too many deliverable
    with dates much beyond today; if we send a charter like that to
    the AC we may get pushback on where are the deliverables
    ... discussion should include what are the deliverables in the
    14-15 timeframe

    chaals: our pubstatus wiki page gives that info; including this
    in the charter is trivial but a first approximation
    ... we have some guesses in the charter but unsuccessful in
    having actuality match the charter

    jeff: to provide at least a guess is good

    paulc: selectors API Level 1 is in DOM4?

    chaals: no

    paulc: can someone explain the relationship?

    chaals: Selectors Level 1 is REC; we were working on Selectors
    Level 2 and since DOM4 is doing that we are assuming it will be
    done there

    paulc: the pubstatus page says something else

    artb: the table has old info

    paulc: to Jeff's point, that was confusing

    <ArtB> scribenick: bryan

    sicking: should be able to move to CR on File API soon, all
    issues have been addressed. Implemented in Firefox and (blink,
    ?webkit, IE
    ... last minute changes are relatively small so expect that to
    be implemented quickly
    ... sync API is not implemented by more than one
    ... expect a short CR; no test suite yet, but can contribute FF
    test suite

    darobin: think there is a test suite, for at least part of it

    jgraham: the test suite there is almost all for blob; half of
    the spec

    chaals: File System APIs...

    sicking: that is more controversial; two proposals (google &
    mozilla); we have not reached out for other implementers
    ... same status mostly as last TPAC
    ... difference in the APIs is mainly in syntax
    ... the mozilla one is smaller and uses promises

    adrianba: one use case we are interested in; being able to pick
    a folder or a set of files/folders e.g. for upload - access to
    a structure that allows tht
    ... looking at the google API, the notion of a directory entry
    is only missing the interface to a picker for that purpose

    sicking: both support the idea, but the syntax for bringing up
    the picker is considered out of scope
    ... input-type = multiple files is supported by both, but the
    use case may not be fully supported

    adrianba: do you plan to use promises for filesystem as well?

    sicking: we should deprecate file reader after implementation,
    and add this to the filesystem API using streams tied into
    ... expect this to be a difficult discussion; once we have
    streams it should be trivial to add

    kinuko chrome allows apps to recursively select files in
    directories; is mozilla interested in that?

    scribe: directory enumeration to filesystem:

    sicking: the goal is to have the filesystem protocol supported
    the same across implementations

    <rniwa> ArtB: i think so.

    chaals: any input from the room on directions this should go;
    what people would like to see implemented

    adrianba: seems we want to move this to promises, and expect
    revisiting async path APIs; seems difficult to see us
    implementing something that does not use the promises pattern
    ... highest priority is the read-only structure

    sicking: an alternative approach not discussed much so far is
    to add this to the IndexedDB; the feature set diffs is very
    small, mostly around the fileysystem scheme, and inline editing
    of files
    ... a feature that is unclear re implementation is inline
    editing of files

    chaals: other things is the ability to share files between
    apps; using IndexedDB that may be hard; external filesystem
    based sharing raises security concerns
    ... any other plans or uses of filesystem APIs?

    <ArtB> Bryan: re Web and TV, need to store large files

    <ArtB> … e.g. videos

    <ArtB> … one way is file system skin over IDB

    <ArtB> … this is an important UC for us

    <ArtB> … Want to build a media library

    <ArtB> Jonas: have you tried storing large files in IDB?

    <ArtB> … think perf will not be good

    <ArtB> Daniel: thinks SysApps is doing related work in Phase 2

    bryan: we still see the use case coming from web & TV re
    performance and scale as a key goal, but have not yet tested it

    <ArtB> Arun's spec is

      [26] http://w3c.github.io/filesystem-api/Overview.html

    sicking: the performance is expected to be good even for large

    Daniel: the media storage API in sysapps is intended to support
    the use case for media

    (missed question)


    <Daniel_Austin> xxx(paypal) = Daniel_Austin

    kochi: current status is 3rd WD aug 15
    ... (showing example onf contenteditable with IME)
    ... issues with implementation include that the suggestions UI
    (system window) conflicts with the UI of the text being edited
    ... (discussing more changes from latest ED on slide)

    travis: we are pleased that the changes have been moved into
    the spec; some open questions about the UI overlap issue -
    would like to avoid issues for IMEs and google's search


      [27] https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEProposal.html

    travis: also for handling IME for custom editors, we are
    skeptical of the use cases. it's been suggested that we split
    that out into a different REC track docs, and get closure on
    the rest first

    kochi: canvas-based editor may make sense to split out

    What are use cases for enableEditingEvents and

    kochi: this spec was drafted in the age of windows desktop -
    though the current API seems desktop-oriented, use in mobiles
    should address the difference between use of on-screen keyboard
    and real keyboard

    rniwa: we would like one solution, and not have unique APIs for
    different device use cases; this will be hard for developers
    ... also please explain the use case for enable/disable editing

    kochi: a single API may be not useful for all platforms
    ... 2nd question re enable/disable; if some extend capabilities
    beyond what contenteditable provides, it gets complicated to
    support that with IME

    chaals: chair hat off; re the UI blocking issue, it makes sense
    that an onscreen keyboard taking the UI space is the same issue
    as the IME suggestions blocking concern; two solutions for that
    may seem annoying

    kochi: we would like to see a unified API to get notice about
    blocking events and get window region info
    ... for devs who want to optimize for desktop vs mobile, we
    need ways to customize for different platforms

    travis: there are not a lot of standards on how on-screen
    keyboards work
    ... not sure if addressing that falls under IME APIs, but this
    sounds like a good space to establish standards

    <rniwa> ArtB: thanks for the url!

    <rniwa> MikeSmith: thanks for the url!

    kochi: for getting to last call, we may split the spec into
    UI-related issues, and the editing issues
    ... we have also had discussion on events; composition events
    and locale; beforeinput event and order of events
    ... for future items; writing tests will start once the API is
    ... API for providing IME for webapps; it makes sense to split
    this out; having an IME for webapps to invoke makes sense;
    chrome provides this through a browser extension

    sicking: our keyboard API addresses a very different use case;
    it does not allow a webapp to build its own IME, rather for an
    app to be the IME for other web pages
    ... there are some APIs on some platforms that allow apps to
    act as IMEs, in the web platform we had to build a new API for

    kochi: so you mean providing IME by the platform and providing
    IME for specific webapps is different

    chaals: that seams reasonable; the accessibility folks are
    concerned about webapps getting this wrong, whereas the system
    may do a better job

    kochi: we see some use cases e.g. web chat apps that may want
    to have their own IME

    chaals: for our use cases for russian and english etc, we can
    see the power of the webapp IME

    kochi: that's all the input for today

    rniwa: are you proposing the events issues be addressed in the
    DOM events?

    travis: we should discuss that in the DOM discussion

    chaals: the sense seems to be to separate the parts of the spec

    <richardschwerdtfeger> I can't really hear anything either

    <abarsto> scribenick: ArtB

    <abarsto> Scribe+ ArtB

Joint Meeting with IndieUI WG

    <abarsto> ArtB: notes, new people include Jania, Michael
    Cooper, RichS (phone), and some others

    <abarsto> CN: introduces the Indie UI people

    <abarsto> … basic topic is IndieUI spec

    <abarsto> … was rewritten last week

    <abarsto> Jania: thanks for meeting with us

    <abarsto> … we want to share Early in our spec dev


      [28] https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html#intro

    <abarsto> … perhaps WebApps will take some of this over at some

    <abarsto> … User Prefs is one spec

    <abarsto> … called "User Context"

    <jcraig> From intro: "The specification below adds several new
    "Media Features" to detect user settings, using existing syntax
    defined in the CSS3 Media Queries specification, and provides
    an access control extension to the MediaQueryList interface
    defined in the CSSOM View Model. "

    <abarsto> … now looking at using Media Queries

    <jcraig> "Because this approach relies so heavily on features
    that overlap with work maintained by the CSS Working Group and
    Web Applications Working Group, it is likely that portions or
    all of this specification may move under the purview these
    other groups. At a minimum, the IndieUI Working Group requests
    guidance and a collaborative working relationship with CSS and

    <abarsto> JC: I posted some things into IRC

    <abarsto> Scribenick: abarsto

    … some overlaps with CSS WG and WebApps

    … there is a new privacy model

    … limit set of MQ features

    … want to customize UX

    … for some web sites

    … want to use MQ syntax if it fits in

    <annevk> jcraig: enums should use hyphens

    <annevk> jcraig: or just be words

    <annevk> jcraig: e.g. "arraybuffer", not "arrayBuffer"


      [29] https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html#example-restricted-call-to-matchmedia

    JC: <scribe misses pretty much all of what James says; needs
    help scribing>

    <jcraig> If you're asking me anything, please scribe, b/c I
    cannot hear the phone.

    JS: we met with CSS WG today

    … they will look at our spec and give us feedback

    <jcraig> When the author first attempts to check the 'matches'
    property of the query, the user agent will determine that this
    is a restricted setting, and immediately return false, so the
    first call to this function on the initial page load will never
    result in audio descriptions being enabled.

    Gary: re D3E, wondering about fingerprinting and keyboard

    <jcraig> Note: The immediate return is critical to prevent
    blocking threads, as well as eliminating potential abuse by
    fingerprinting scripts attempting to determine uniqueness using
    execution time of the synchronous call to mql.matches.

    <jcraig> However, at the same time, the user will be prompted
    to decide whether or not to share their media alternative
    settings with the requesting web site.

    … we need to support customized keyboards

    <jcraig> The web author can register for a change listener on
    this media query list, and the event handler will be called
    asynchronously when the user agrees to share their media

    … need some UX for that

    … We should talk with you in the D3E context

    CN: not sure this effectively solves the fingerprinting prob

    <jcraig> When the user prompted, matchMedia returns false (or
    default value) immediately, and only provides the updated match
    asynchronously through matchMedia().addEventListener or
    subsequent requests to matchMedia().matches (e.g. on page
    reload) so there is never any detectable difference between
    "No" and "You don't need to know."

    … my concern is that you have uninformed and no consent

    … forces user to give consent

    <jcraig> A restricted @media block never prompts the user
    unless both the @media block and an included selector matches.

    <jcraig> For example:L

    Katie: under privacy laws, have to give consent

    … on what can be done with fingerprint info

    … otherwise, can get legal suits

    CN: not sure international laws re fingerprinting will work

    <jcraig> @media (subtitles) { .videoCaptions { display: block;
    /* custom rendered captions */ } }

    … the tech approach of using MQ for detailed browser sniffing

    … MQ can do the job

    … Don't think anyone is saying no, don't use that

    … but I am skeptical about the privacy story

    Ryosuke: agree with Chaals

    … can't rely on the laws to save us here

    Gary: if we expose this in any way, you won't be satisfied?

    <jcraig> When we spoke with CSS, they agreed that some of these
    media features made sense, but the privacy/restriction model
    may be outside the scope of CSS WG. We think its within the
    scope of WebApps…

    … not sure it is quite so clear

    … is there an impasse here

    … not sure where we go with this

    CN: not about acceptable or not

    … but saying it will protect your privacy is overselling

    <jcraig> The other aspect about this that I'd like to bring to
    the WG's attention is currently a todo in the draft:

    … don't see it as an impasse

    … but if the privacy system doesn't protect privacy

    <jcraig> Add justification interface on a per-category setting
    (possibly meta tag or a partial interface on document).
    Justification string may be defined by an new JavaScript
    interface, or perhaps by a meta tag in the document head, such

    <jcraig> <meta name="userMediaSettings" content="Used to enable
    captions and display them in your preferred font size and

    … need to recognize their are implications of providing more

    <jcraig> Justification string would be included in the user

    CN: I'm not saying `don't do this`

    <jcraig> We think this is broader in scope than just this MQ

    … but *I* am unconvinced

    <annevk> baaaah

    <annevk> We already lost the fingerprinting battle

    … privacy protection is sufficient

    <annevk> With HTTP

    <annevk> It's called etag

    CN: encourage you to take this to Privacy Interest Group

    <jcraig> For example, there is currently no way for a site to
    explain to the user, when prompted, why it's requesting
    Location data. Map sites are obvious, but others not as much.

    AvK: I think we already lost the fingerprinting battle

    … don't think we can win this

    Travis: but we should try

    CN: agree fundamentally the fingerprinting battle is lost

    … this could minmize the fingerprinting

    … agree with Travis and this approach can help minimize

    … but there will always be some unprotection

    Katie: technology is not the way privacy is protected currently

    … at some point that may change

    <jcraig> WG, do you agree the "justification" string idea may
    be useful for Location sharing as well as this idea?

    … If some org doesn't do what they said they will do, there can

    … reprucussions

    CN: this could be reasonably protective in some countries

    … in some countries there aren't good laws

    Gary: if there a bunch of MQs, is there going to be just one

    … or some choice?

    … is that all in scope

    JS: I don't think we have worked that out

    … but I don't think we want to overburden the user

    CN: I would expect that to be an impl detail for the browsers

    JC: if there are many MQs, I expect just one dialog

    <jcraig> Add justification interface on a per-category setting
    (possibly meta tag or a partial interface on document).
    Justification string may be defined by an new JavaScript
    interface, or perhaps by a meta tag in the document head, such

    <jcraig> <meta name="userMediaSettings" content="Used to enable
    captions and display them in your preferred font size and

    … take a look at the ToC


      [30] https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html#toc

    … there are diff categories

    CN: if user changes devices or device state often (e.g. sound

    … don't want to constrain the browser

    … Good impls will decide to make it easy for user

    <jcraig> For example, matchMedia('(subtitles)') and
    matchMedia('(subtitle-type: cc)') would only prompt the user
    once, because the media feature types are related.

    … or to provide power control to the user

    <jcraig> specifics of prompt will be UA implementation details

    … but I don't think the spec should constrain the options

    <jcraig> For example, there is currently no way for a site to
    explain to the user, when prompted, why it's requesting
    Location data. Map sites are obvious, but others not as much.

    JC: <something about location data; scribed missed comment>

    <jcraig> the "justification" string idea could be used in
    Location prompts as well.

    Cynthina: IE uses vendor prefix for MQ and high constrast

    … setting part of OS

    … UA can use that setting

    <jcraig> So the site can specify to the user why it wants to
    use this information

    … simple from authoring perspective

    CN: I haven't heard anyone say `no, this approach is not sound`

    <jcraig> -ms-high-contrast values are *very* specific to
    Microsoft's implementation

    JS: summary … go ahead; nuance the privacy story

    … tell the story correctly

    … go talk to PING

    <jcraig> and I think -ms-high-contrast can generalized into
    media features for contrast-increased, user-color, and

    Ryosuke: re the requests, different syntax than in DOM spec

    … would be good to consolidate the events that are now in diff

    CN: re the events stuff, yes, we need serious coordination

    Jania: I accept the request to coordinate with the events

    … we are hoping to get to LC by EoYear

    James: did you mean UIEvents spec or Context spec?

    CN: we should have a separate discussion about events

    Gary: keyboard layout is another coordination point

    … I should be the contact point

    <jcraig> Or something else related to "Events", IRC log is
    limited and phone call is unintelligible

    CN: James, that's Gary you should talk to

DOM 3 Events & UI Events

    <annevk> (For the record, it's done here:
    [31]http://dom.spec.whatwg.org/ )

      [31] http://dom.spec.whatwg.org/

    <Daniel_Austin_> lol @abarsto

    CN: < a bit of a digression on why D3E is done in one WG and
    DOM4 done in a separate group >

    Rich: what about the device specific events?

    CN: we are about to talk about DOM 3 Events now

    <adrianba> ScribeNick: adrianba

D3E and UI Events

    gary: we have another LCWD for DOM3 Events
    ... we think this is really the last one
    ... we just released a WD a week or two ago

    <abarsto> Scribe+ Adrian

    gary: expect to have another LCWD in dec or jan
    ... we have made a bunch of changes we'd like people to review
    ... so that we have a good LCWD draft
    ... want to summarise the changes
    ... not to discuss but so you know where to read if you have
    ... we took the deprecated stuff and put it into an appendix
    ... examples don't use deprecated stuff

    <abarsto> D3E bugs:

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

    gary: for example char went away
    ... locale got removed from D3E
    ... currently a BCP47 string which is too general

    <annevk> I'm confused. Isn't char implemented?

    gary: need to think about this so we move it into UIEvents to
    do later
    ... this is the first version that talks about beforeinput and
    ... we rely on them as a replacement for keypress event
    ... keypress is deprecated event
    ... beforeinput is fired, then DOM is updated, then input is
    ... click and double-click suggested all buttons should fire
    click and double-click
    ... this is only for primary button
    ... on composition events we spent time on order of firing
    ... composition events relative to input events
    ... dead keys are handled like small IMEs with composition
    ... earlier versions had special handling for dead key values
    ... tried to specify event ordering - little more formal than
    ... the last thing is the relationship with DOM 2 Events
    ... DOM2 had unspecified keycode attribute
    ... in general DOM3 is an improvement, superset of DOM2
    ... but it isn't for some key character information
    ... previously you could tell which physical key was pressed -
    cannot do this with key event in DOM3
    ... code attribute in UI Events will handle this scenario
    ... if we want DOM3 to be full superset then we should consider
    moving code into DOM3
    ... if people have thoughts on that they should let us know
    ... i think we should move it in but others want to avoid
    ... biggest concern is lack of test coverage
    ... that is an area of focus now

    annevk: question about legacy stuff
    ... do you think you can get it removed from chrome?

    gary: which legacy stuff?

    annevk: the things you're proposing to remove

    <richardschwerdtfeger> I will ask my question here:

    gary: you're wondering when we're likely to get rid of keychar
    and keycode?
    ... they will live as long as web sites need them to be around
    - we need a good spec to replace them
    ... don't see them going away soon
    ... i don't have a timeframe on that

    <richardschwerdtfeger> rich: Why is there a MouseEvent
    Constructor in UIEvents and not with the MouseEvent in DOM3?

    <annevk> garykac: so that seems kinda contrary to how we define
    many features

    <annevk> garykac: basically, if a user agent needs to implement
    in order to be competitive, we should define how it works

    gary: i think people were trying to finish DOM3 and other new
    stuff went into UI Events

    <annevk> garykac: not defining how the web works is bad for
    newcomers, and we've had that situation for these events for a
    long time

    gary: i think we should merge but this would delay DOM3

    richardschwerdtfeger: the problem with this is we don't know
    what to refer to - is one going to go away

    <annevk> (Referring to this as DOM3 is hugely confusing btw. We
    should really name both "UI Events".)

    chaals: when figuring this out for SVG you don't know which
    spec to rely on

    gary: we have an appendix telling you the old way and saying
    don't do this

    <richardschwerdtfeger> Rich: In SVG2 we are trying to know what
    to refer to with respect to events as they are defined in two
    separate places. What should we reference for mouse events?

    gary: but this is a good example of why moving things from UI
    Events into D3E would help
    ... for the constructor I don't think there is a big risk - we
    could move them into D3E

    <richardschwerdtfeger> Rich: I agree with Adrian

    Travis: if we can get things in and stabilise them then that
    sounds good

    <richardschwerdtfeger> adrian: you stated: but this is a good
    example of why moving things from UI Events into D3E would help

    <richardschwerdtfeger> Rich: I agreed

    chaals: the question was about constructors and code attribute

    annevk: that suggestion has been made for ages

    <annevk> garykac: name it UI Events too then!

    heycam: i think one of the problems with the question which
    version do we reference from SVG

    <annevk> garykac: backport the name

    heycam: it really doesn't matter

    <richardschwerdtfeger> Rich: SVG2 is going to last call at the
    end of the year. we need something that is clear

    heycam: we don't rely on the constructor
    ... so whichever you care about
    ... so reference the latest one and consider earlier ones if
    you want

    chaals: known issue at W3C of having specs out of sync
    ... sounds like the sensible thing is to look at the modern
    spec and use it as your working reference
    ... if you run into trouble you can consider process hoops for
    changing reference

    <richardschwerdtfeger> Rich: what is "modern"?

    chaals: but now it is more common to publish Rec based on draft
    spec if the part you depend on is stable enough

    gary: considering UI Events was primary given constructors and
    code attribute
    ... it was a dumping ground for feautures we didn't think would
    make it into D3E
    ... we would only have a couple of small things left

    <chaals> [UIEvents is more modern than DOM3, DOM4 is more
    modern again, If I got it right...]

    <richardschwerdtfeger> Rich: but keyboard events is now fully
    specified in UI events separate from the DOM3 spec.

    chaals: questions on D3E or UI Events?

Quota API

    kinuko: quota api status
    ... just published new WD beginning of this month
    ... API is still very small
    ... two apis - query current usage status and to request new
    quota for application
    ... in the new draft they are both promises
    ... previously callback based
    ... also added quota storage change events

    <garykac> richardschwerdtfeger: keyboard events are not fully
    specified in UI Events. Only the additional KeyboardEvent info
    live there at the moment.

    kinuko: so apps can watch how usage is increased

    <myakura> [33]http://www.w3.org/TR/quota-api/

      [33] http://www.w3.org/TR/quota-api/

    <scribe> ... new draft has changes that lose compat from old

    <richardschwerdtfeger> We need to reference the actual event
    interface definition

    UNKNOWN_SPEAKER: we wanted to make it work better with other
    promise based apis
    ... including imagined ones like service worker

    <garykac> Once we move |code| into DOM3, then DOM3 will have a
    complete KeyboardEvent specification

    UNKNOWN_SPEAKER: previous api was only implemented by chrome -
    would like to get more support from other browser vendors on
    new version
    ... think this api is very important for mobile web apps using
    local storage

    nts and

      [34] http://www.w3.org/TR/DOM-Level-3-Events/#events-keyboardevents
      [35] https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm#keyboard-event-interface

    <richardschwerdtfeger> so it is defined in two different places

    UNKNOWN_SPEAKER: for web apps and user to agree on how much
    data can be stored on local device
    ... should be addressed in unified way not in each storage api
    ... would appreciate comments

    chaals: obvious question is to implementors

    sicking: mozilla are very interested in implementing this -
    doesn't mean we are fully happy with api
    ... looks great so far but need the person actually
    implementing to review

    <richardschwerdtfeger> rich: which this?

    chaals: does that mean you have someone on this?

    sicking: not yet

    chaals: no current plans or comments from others?
    ... probably two implementations at some point
    ... sounds like we will get comments and presumably the spec
    will move forward

    Travis: haven't looked at the spec in detail
    ... most browsers will have a quota management experience, not
    sure about the API, i know in IE the browser will prompt me

    annevk: one comment on the IDL - it uses array that is going
    ... seems like some of this will need to change - not sure how
    ... what travis said sort of makes sense - pretty hard to ask
    the user about amount of space
    ... platforms we compete with don't do this
    ... seems like we should strive for this if we want to compete
    with native platforms
    ... for example heuristics about how often the app or site is

    chaals: Flash apps annoy me because they ask me to allocate
    memory all the time
    ... agree with anne that the implementation is going to be
    combination of talking to the user and doing things for the
    ... overspecifying is probably not going to be helpful but
    being able to request more memory for an app seems like an okay
    thing to do
    ... basic idea seems okay
    ... perhaps browser can grant request without the user
    ... [some examples given]
    ... does seem like makes sense and important to compete with
    other platforms

    kinuko: this API defines two types of storage
    ... temporary and persistent
    ... temp can probably be used without prompt but could be
    ... slightly different experience to native apps
    ... for web apps people might visit site and then never return
    ... browsers need a way to know to delete data if they want

    sicking: to answer a couple of questions
    ... our goal is to prompt users as little as possible for
    current apis
    ... we have temporary storage and because we're doing apps
    ... for apps installed or bookmarked or whatever we can provide
    persistent storage
    ... blown away when user uninstalls
    ... what travis said about prompting is what we did in firefox
    so far
    ... devs don't have to worry but bad that many developers want
    to manage when prompts come up
    ... they want to forewarn users to let them know why they get a
    ... have thought about ability to put quota manager in
    automatic mode
    ... whether that should be default behaviour i don't know
    ... that's not in draft - only thing i think might be missing
    ... being able to say that persistent storage doesn't deny when
    hitting quota then the browser just prompts
    ... adds complexity for implementation

    kinuko: we thought about this and tried to implement but
    suspending execution of storage api while showing prompts
    tended to make things very complicated
    ... also cannot predict when prompts will be shown
    ... we share same experience but this is why we excluded this
    ... if we did this in an automatic way do you mean we wouldn't
    need api?

    sicking: this would be an additional piece of the api

    chaals: this would be an addition to make browser keep
    prompting when anyone else would be denied
    ... worth thinking about but can see issues in practice

    sicking: that behaviour is in gecko right now
    ... was default behaviour in indexed db
    ... we would keep prompting - eventually if you keep saying yes
    then we give you whatever you want
    ... developers were not in control of when prompts happen which
    was bad

    chaals: not sure how bad it was
    ... not in control of when you run out of memory

    kinuko: spec doesn't explicitly say when to show prompt
    ... in chrome we don't show every time
    ... might be session based
    ... not sure if it should be more specifically speced - left to

    <Zakim> annevk, you wanted to ask what's the story for Chrome

    annevk: could imagine model where every web page gets 100MB of
    temp space
    ... browser might drop this
    ... if you bookmark something then you get persistent storage
    ... site might advocate to the user to bookmark to make it part
    of the user's ecosystem
    ... seems hard to prompt user for 100MB -what does this mean?
    ... how did you solve this in chrome os?

    kinuko: we don't really solve the problem - we have two types
    of apps
    ... installed and linked

    <slightlyoff> abarsto: I have no slides. was informed I'd be
    leading this only this morning

    kinuko: app can say it wants storage and is prompted during
    ... we build many important apps as installed packaged apps

    sicking: we do similar in firefox os

    <slightlyoff> abarsto: but if you have the projector, might be
    useful to have this document up on screen:

      [36] https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md

    chaals: there are some apps that i want to store lots of data
    even though i only use them every 6 months
    ... not sure how to solve that automatically or by asking users
    questions they understand
    ... we are expecting sysapps in 5 mins - suggest 5 min break
    ... let's have a break

    <abarsto> … that's a *5* min break!

    <Travis> scripe: Travis

    <Travis> scribeNick: Travis


    Alex: Will provide brief explainer of Service Workers
    ... attempt to provide background scripting to manage stuff
    that is hard to capture/handle.
    ... offline bootstrapping is hard--Service Workers can address
    this concern
    ... they are like shared workers, but lifetime is versioned.
    ... like background extensions in Chrome
    ... general idea is core of the system is to register a script
    that can run with a url pattern
    ... handle events in an async way.
    ... no synchronous APIs (unlike shared workers)
    ... status-- happening in github
    ... intent is to bring the work to Web Apps WG
    ... since webapps wanted to handle the offline use case,
    service workers should be a good fit.
    ... Chrome is prototyping to see if it's suitable

    Ryu: what are the use cases?

    Alex: primary use case is offline problem
    ... didn't scale well
    ... appcache didn't quite work for all the scnearios that apps
    ... had to either use IDB or local storage, but these aren't
    well suited for URL management and fetching.
    ... you want to have hierarchy or list of caches to
    independently manage.
    ... other use cases: alarms API, push notifications, data sync
    in background (less fleshed out)
    ... there was a name change, but not so far along on the
    details of those use cases

    shepazu: Does it persist from navigation to navigation?
    ... one use case may go beyond offline, and provide animations,
    or persistent audio?
    ... have you thought about using it like a proxy between page

    Alex: no visual component (just background execution context)
    ... it can coordinate between pages, etc.
    ... to smoothly move from online -> offline world, you need to
    bootstrap the service worker.
    ... first need to install the service worker.
    ... after that you get the next doc installed under the service
    ... there will just be one instance of the service worker (not

    shepazu: CSS resources? How would it work with it?

    Alex: not sure.
    ... CSS is local to a single running doc.
    ... but without rendering, not sure how it would integrate.

    adrianba: If the app is listening for fetching... does this
    have perf implications on network requests?

    Alex: Still trying to get data on this.
    ... the async nature makes this feel a lot like Node.js
    ... fetch event can only respond with promises.
    ... a storm of requests will block based on the service worker
    being a single thread.

    Daniel (ebay): What are the security implications, threats, and
    countermeasures you are planning?

    Alex: Jonas has helped look into the security issues.
    ... biggest impacting problem is...

    <inserted> scribe: Travis_

    Alex: We welcome any review.

    Daniel (ebay): what is the physically security of a
    local-stored service worker?

    Alex: Service worker is backed by HTTP cache-like thing. Code
    itself is stored as per browser's code storage permission

    <annevk> HTTP cache is dead, long live HTTP cache /cc mnot

    Alex: should be comperable to the browser's local security
    model. Not sure there's more security layers to add on top of
    ... It's a cache-wide problem, not just for service-worker

    chaals: When a CSS page refers to other pages @import.
    ... how are these managed?

    Alex: Initial service worker kicks in.
    ... initial CSS goes to the service worker...
    ... sub-downloads hit the sevice worker serially as they come
    ... like the service worker is a virutal networking layer. It
    sees the fully-formed request.

    Bryan: Says you can defer loading.
    ... Tell me more?

    Alex: The service worker will see all requests once it's set
    ... non-http requests are not speced to be handled.

    chaals: not data:

    bryan: <clarifying behavoir>
    ... does it interact with XHR?

    Alex: yes
    ... think about this like Mod.Proxy for the browser.

    <annevk> Come on, someone ask something tricky

    <annevk> Like how this works with sync XHR

    <annevk> (it doesn't)

    Alex: XHR requests eventually filter through to service worker

    <slightlyoff> annevk: wait, I thought you said "hard"

    bryan: For offline: you should be able to package server code
    in the client

    Alex: yes, but the patterns for app construction in flux.
    ... today we think of server requests first, but with service
    workers, alternative scenarios are enabled.
    ... we're not defining the cannonical way of doing offline.

    plh: Is there a use case for the web app to know what is

    Alex: yes, it's specifically designed into the system.
    ... so that when you're offline, you can have a pre-populated
    set of data (part of the installation model)

    Mark: Service worker will not go to the browser's cache?
    ... you could create your own cache?

    Alex: If you hit the network, you still go through the normal
    network, including the http cache
    ... it's only a detail that service worker updates themselves
    work around this.
    ... otherwise, its the burden/logic of the service worker to
    handle any other case like fallback to missing live info.

    Mark: there is lots of flexibility. Coolness.

    Richt: Sounds like 4 things merged into one.
    ... seems like you've invented http primitives.
    ... could we use that outside of service workers?

    Alex: goal is to enable offline and than abstract it out.
    ... we're trying to make sure we're aligned with Anne's Fetch
    ... so we may also be able to expose caches objects... but
    these are secondary goals.
    ... primarily it needs to solve the main use case, first.

    heycam`: How does the service worker determine to fallback to
    the network?

    Alex: Service worker can't include XHR (because of it's
    ... the service worker allows you to connect requests with
    responses arbitrarily.

    heycam`: Are you forced to use fetch, or can you do something

    Alex: just ignore the request.

    <slightlyoff> Travis_: yeah, explicitly, don't call

    heycam`: Seems like many new scenarios come out of this...

    Alex: yes.

    Jonas: Allows a lot of combinations of scenarios. You don't
    have to respone 1:1 with each request now.
    ... can do server-side templating.

    MikeSmith: Notices we don't have a spec???!!!!

    <annevk> slightlyoff: so what is the idea for sync XHR again?

    MikeSmith: Expected a WebIDL????!!!!

    <slightlyoff> annevk: sync is only sync from the perspective of
    the document

    <annevk> oh MikeSmith <3

    chaals: Already covered :0)

    Alex: I'll get the spec together after we get through the
    existing github bugs

    <annevk> slightlyoff: I guess, but if the SW messages the
    document and awaits a reply, it's dead

    mnot: How do you minimize duplication between http-cache and
    synthetic caches. Also resource management: do you prompt the

    Alex: On duplication. Could be cheap.
    ... on the storage level, you can have more persistent info
    that doesn't get cache-evicted.
    ... on storage limits, we don't have this solved.
    ... there's no distinction for some storage technologies for
    persistent vs. not (it's all just file-system)
    ... and other open issues. Working on fleshing these out.

    mnot: de-dup in http-caches. This could solve it. I really like
    the way this is going. It's coolness.

    bryan: Service workers can't use XHR?
    ... what else can't they use?

    Alex: It's limited to much fewer things you think (all sync
    stuff is blocked)

    avk: why not just remove the sync-bit?

    Alex: we could entertain that. We didn't go that direction.
    ... think about a worker with all sync-stuff removed (with
    importScript as the exception)

    bryan: So, it can't be used to build offline apps?

    Alex: No.
    ... You can handle request in any way you like, you can
    postMessage, you can manage storage locations, etc.

    chaals: the app can still use XHR, of course. It's just not in
    service worker.

    heycam`: Can you stream a response back from the service

    Alex: No answer to that now.

    <MikeSmith> audible sigh from slightlyoff

    Alex: Seems like we need something like Streams...??

    <annevk> Weird to say no to XHR based on a theoretical fetch
    API but say this here slightlyoff

    Ted: [muted]
    ... Fetch vs. XHR: XHR is platform for http-requests. Fetch is
    the way for how the network requests stuff.

    Alex: XHR != fetch

    Ted: seems like a terrible approach to have both.

    <slightlyoff> yes!

    <slightlyoff> was about to say that = )

    Jonas: XHR doesn't have a great way to represent requests (not
    just response) and stuff for CORS.

    paul: How does service worker work "upwords"?

    Alex: whichever core capabilities are plumbed into it. For
    example other services that could be put into it.
    ... Alarms, etc., another service layer for the web. For things
    that don't need UI.

    <scribe> Scribe: Travis_

    <scribe> ScribeNick: Travis_


    <abarsto> [37]http://www.w3.org/TR/streams-api/ -> WD published

      [37] http://www.w3.org/TR/streams-api/

    <Travis> <crickets>

XHR and Progress Events


      [38] https://dvcs.w3.org/hg/xhr/raw-file/tip/xhr-1/Overview.html

    <inserted> scribe: Travis

    jungkees: looking at XHR1
    ... in spec history section
    ... some features left out of the living standard...
    ... fetching data uris and anonymous flag
    ... some behaviors are not compatible

    <jungkees> jungkees.github.io/XMLHttpRequest-test

    jungkees: looking at test cases in W3C test repo
    ... current status of browser implementation

    <myakura> [39]http://jungkees.github.io/XMLHttpRequest-test/

      [39] http://jungkees.github.io/XMLHttpRequest-test/

    jungkees: covers 95%+ of spec
    ... compat numbers are 50-60%
    ... now filing bugs with relevant implementations
    ... path to interop and CR.
    ... this is our current status.
    ... we have ~11 issues in bug list.
    ... only 1/2 are issues we need to solve for L1 XHR spec
    ... (1 or 2) not 1/2
    ... One of these 21650:
    ... xhr has a limitation in responseType==document
    ... other issues are related to bleeding edge features that can
    be handled in next version.

    <bryan> quit

    Art: are you marking the bugs for v1 and v2?

    jungkees: having an issue with the alignment with the fetch
    ... need to discuss how to handle referencing the fetch spec in
    the W3C spec.
    ... not sure how to deal with that.

    chaals: not a technical issue, just a doc/process spec.

    jungkees: we are referencing WHATWG at the moment.
    ... we should be ready for LC soon.
    ... during LC we can resolve the issue with
    responseType==document and focus on browser interop and bugs.

    chaals: what are the implementation plans.

    jungkees: some interop differences: one browser fires
    "progress" other's don't.
    ... there are some subtle differences.

    abarsto: Are there any tests for v2 (in the list of test from
    the w3c site)


    jungkees: All of the tests are based on the living standard. We
    will see which will drop for the v1 spec.

    adrianba: On why don't browsers fix these bugs: these are the
    set of "interop" issues we talk about for a long time. Do these
    interop issues really matter to web compat?

    <inserted> scribe: Travis_

    <Eliot> Robin: We can identify the best and brightest tests.

    Robin: Might be worth looking into library code (jQuery) to
    prioritize bugs to fix.

    abarsto: Will Robin/James work with jungkees to help get these
    tests prepared?

    <abarsto> s/help get these tests/prepared/help identify those
    tests that are mandatory for CR/

    adrianba: To Robin on the question of interop bugs worked
    around in jQuery: is the 'we' the working group?

    Robin: I think they're likely working around real problems.
    ... if this delays the spec a little while, then OK.

    adrianba: still trying to understand the priority. I think this
    is about having a good spec.
    ... these tests don't need to be fixed at the same rate as
    implementations move forward.
    ... I think we can look at the spec at a high-level and say
    that it's "implementable" and not have to hold up CR.

    jungkees: The core editors came to the conclusions that the
    issues shown in test cases must be resolved because they are a
    major part of the Fetch behavior.
    ... without resolving this, XHR authors may have to work around

    chaals: there are different authors for the spec.
    ... implementers are one categories. Authors want to look at
    the spec and write to that.
    ... may be nice to have the spec speak to the reliability of
    certain features in the spec.

    <annevk> o_O

    <annevk> (need bigger O)

    chaals: it's nice to have the next version coming so that we
    can look forward to it's more specific requirements.

    paul: I think robin is saying that web devs have seen issues,
    and that we can use libraries to find what the pain points are.

    <hober> annevk: o_O

    Daniel (ebay): Since XHR came out, it's not just browser user
    agents, but having a reliable spec is good.

    jgraham: post re-writing the spec to be more vague is a really
    bad idea.

    <annevk> hober: nice

    <annevk> darobin: could just remove the conformance section

    <annevk> darobin: would also make it shorter

    <hober> annevk darobin: we could start using other RFC 2119
    terms like "UAs MIGHT AS WELL ..."


    <darobin> hober: I think you mean RFC 6919

      [40] https://www.rfc-editor.org/rfc/rfc6919.txt

    jgraham: The right way of solving the problem is to use a test
    suite to show authors how reliable and interoperable is the
    ... I don't think the right solution is to change the spec.

    adrianba: I agree.

    <Daniel_Austin> RFC 6919

    <annevk> "MUST (BUT WE KNOW YOU WON'T)" hahaha, forgot about
    that RFC

    adrianba: it seems odd to update the spec according to where
    implementations are at some moment in time.
    ... via MUST to SHOULD update.

    chaals: well, we shouldn't change must to should just to squeak
    out of a process requirements.

    <annevk> abarsto: but it's his favorite proposal

    <annevk> abarsto: he makes it at least once a year

    chaals: going from test->spec can be challenging.

    jgraham: historically we've done a poor job of having a test
    ... we need to work on test suite results and how we present
    ... as implementation run the tests we can gather the data more

    adrianba: we have some places where we want to correlate this
    data, like in Web Platform Docs.

    chaals: my basic goal is to get what is needed now, and not
    wait while we develop our test suites and tools.

    jungkees: Initial intention was to exclude features not running
    well across the board.
    ... our findings uncovered that some things are running fine in
    2 of the browsers.
    ... the core editors found that these are the pimitives of the
    fetching of resources.
    ... we want to keep going with current set of features.

    chaals: What happens now? LC and long wait?

    jungkees: and working on test suites until CR exit. Want to
    start LC now.
    ... we don't see too many issues in the spec itself, but want
    to focus on solving implementation gaps.
    ... perhaps Q2 of next year we can review the bugs to see how
    browser interop is improving.
    ... interop will improve, libraries will be easier to maintain,
    ... that's our current viewpoint.

    paulc: Q on original stats: only 50% of the results give
    consistent results... at least 2 browsers pass each of them?

    chaals: what is the intersection for at least two

    israelh: how do we prioritize? Put my high priority tests
    together, then the bugs that don't impact most sites, this
    could work.

    chaals: We could take the spec to the director and show that
    there are some places with dragons, so beware, but we need
    better coverage than we have now.

    jungkees: Given major implementations, pass ratio is much
    higher (than 50%).
    ... we've tested three major tests: blink, gecko, trident.

    paulc: my personal opinion: we'll never get a spec published if
    we expect 100% interop.
    ... if this spec is to goto CR, what is the exit criteria.
    ... the WG needs to define what it believes is necessary.

    <Daniel_Austin> +1 to Paul's comments


      [41] http://www.w3.org/wiki/Webapps/Interop/ProgressEvents

    chaals: how much progress are we making on progress events?

    jungkees: Looking at progress events test results.
    ... waiting on bug fixes for Blink to improve the test results.
    ... if we do have concensus, we need to try to get it on the

    <abarsto> ACTION: barstow start CfC to publish PR of Progress
    Events [recorded in

    <trackbot> Created ACTION-702 - Start cfc to publish pr of
    progress events [on Arthur Barstow - due 2013-11-18].

    jungkees: We _could_ add more examples to the spec from other
    ... if not required I'd prefer not to.

    <abarsto> ACTION: barstow work with AvK and Jungkee re the
    Attribution of the Progress Events spec [recorded in

    <trackbot> Created ACTION-703 - Work with avk and jungkee re
    the attribution of the progress events spec [on Arthur Barstow
    - due 2013-11-18].


    heycam`: Test suite progress?

    scribe: I started working on tests for webidl v1. These have
    been reviewed.
    ... I now need to revise tests that have issues.
    ... I thought I did a fairly complete job, but it would be good
    to hear from the people who did the reviews.

    abarsto: 5 reviewers did 20%.
    ... what are we going to consider implementations?

    plh: I recall two levels of implementations--first to find
    implementations (in other specs) of each feature, and 2nd to
    build up the test suite.

    heycam`: The tests use features that are available in other

    jonas: two things I know that are programmatic.
    ... arrays - people wonder what this means.

    heycam`: generally, people are not happy with array-ness.

    scribe: one test used messageport arrayness, but managed to
    convince hixie to change it.

    jonas: my proposal was to just use JS arrays or frozen arrays.
    ... nodelist and other live-lists may just stay as
    ... we shouldn't add more ways of replicating those behaviors.
    ... otherwise, we should just use iterable objects (ES6 syntax)

    <annevk> NodeList can still be an iterable

    heycam`: to defend [] syntax: to handle nodelist-like objects.

    scribe: if we don't like that concept, than it doesn't make
    sense to allow/expose it.

    heycam`: There's still a bunch of new things to align with ES6
    features (iterables, proper classes)

    <annevk> For NodeList we can add @@iterator from ES6

    heycam`: At the Mozilla summit a few things were discussed:
    JS-IDL, what's left to finish.

    scribe: for JSIDL - I don't really have the time to re-write
    for that.
    ... better use of my time to find/fix the major problems wrong
    with WebIDL.
    ... seven items were discussed
    ... 1 - typearray, promises, etc., stuff that moves in ES6
    ... 2 - no custom exception objects; building it in.
    ... 3 - proper ES classes, maybe replace interface with class
    ... 4 - deprecating indexed and named properties and stuff that
    required proxies.
    ... 5 - fixing array-ness
    ... and other stuff.
    ... with some new focus time, I can get after these.

    chaals: done by Christmas.
    ... ?

    heycam`: Any other high-priority items to finish?

    jonas: can we get rid of overloading?
    ... with union types why do we need it?
    ... other than drawImage?

    Alex: WebGL?

    heycam`: overloading is the most complex part of the spec. It
    would be nice to remove it...

    abarsto: heycam` can you draft up a message on what's next?

    heycam`: need to update the list of "what's new" to aggregate
    into the history of the spec.

    <adrianba> WebSocket API uses overloading for send()

    scribe: Do we want to hold up v1 of the spec on some of the
    larger issues?

    Travis: I don't want to implement stuff that's going to change.

    heycam`: If you stick to the spec + bugs + list of things I
    mentioned, you should be safe.

    <chaals> scribeNick: chaals

    Scribe+ chaals

Readonly/ writeable interfaces

    DS: We have interfaces for SVG / CSS DOM - there is readonly
    and writeable versions.

    … readonly has no setters, attributes are readonly. Writeable
    have setters, and attributes are not readonly

    DS: Can't do that in WebIDL. Had a short discussion on the
    issue. 2 possibilities; inherited structure, or have 2

    … for nihersited structure, the writeable version would inherit
    from the readonly version.

    Travis: Do you need the interfaceto swap between
    readonly/writeable, or is a given object always going to be one
    or the other?

    … We had objects that changes in IE

    DS: The interface doesn't change between readonly / writeable.

    <krit> [44]http://dev.w3.org/fxtf/geometry/#DOMRect

      [44] http://dev.w3.org/fxtf/geometry/#DOMRect

    JG: Readonly is not user-modifiable, but the values may be

    DS: Correct.
    ... DOMRect is writeable, DOMrectReadonly isn't, so writeable
    inherits from it.

    … which means that things inherited do weird stuff @@

    … solution could be to rename rDOMRectReadonly so people don't
    think it is always readonly.

    … other solution is use typedef and different interfaces and
    specify if you have a readonly or writeable version

    Cam: renaming sounds sensible, compared to duplicating

    JG: View has another meaning - arrayBufferView is writeable.

    …bad choice of colours

    DS: The iidea of calling it that was so people wouldn't get bad

    JG: but confusing is bad.

    DS: Right. Whey we are discussing.

    AvK: Instanceof doesn't work with cross-@@ and isn't good
    practice accoring to JS spec editor.

    Dino: It's all good.

    Travis: Can you give some use cases for DOMRect for context?

    DS: SVG DOM is a bit complicated.

    <myakura> MikeSmith, there was nobody in the room who could
    talk about current state of Stream proposals. so we moved on to

    <krit> <rect>

    <krit> var e

    … you have different attributes. a rect in SVG is one element,
    you can test its attributes.

    <krit> e.x

    … e.g. the x property.

    <krit> e.x.animVal baseVal

    … these are different kinds of objects. BaseVal stay set,
    animVal includes current value under current animation.

    … other examples in CSS Object model

    Cam: Also clientRect….

    … maybe not a great example, could return a plain object.

    DS: Think that was the use case I was thinking of.

    Cam: Want to avoid a proliferation of rectangle objects. We
    have SVG rectangles, clientRect, and maybe more APIs that want

    … would be goo to have a single (or dual) rectangle interface.

    Travis: How does SVG do it today?

    Cam: With a single interface and a flag to say if it is
    readonly or not.

    … it's writeable in the intereface and setting it when the
    reaonly flag is set will throw.

    Travis: Saying readonly is to say when you never want to allow
    writing to something. Think in this case it would be OK to have
    2 rectangles (which is better than dozens) - one readonly, one

    JG: Sort of what I was going to ask. Where you have
    DOMRectAbstract and the 2 types of rectangle inherit from it
    but you never pass one directly.

    … Not hugely pretty, but would allow people to check @@@

    DS: Would not share anything with the inherited classes. Also,
    there are multiple interfaces like this in SVG.

    … that are currently incompatible with WebIDL.

    Cam: Not that you cannot express this in the SVG spec, can add
    process. But people don't love it.

    DS: People objected and said it is not possible… but is

    Cam: Thinks what they said was it is impossible to have a base
    class with getter/setter, and a derived class that has the
    getter and no setter.

    JS: Trying to do that in JS, it isn't possible - this is a
    limitation of javascript. So the base has to have a getter and
    the derived class a getter/settter.

    DS: So we need to define a getter separately for the defined

    JS: 2 qusestions. What do we write in WebIDL, what can you do
    in Javascript?

    … in JS you need a property on the derived intereface with a
    getter and a setter

    Cam: Not a huge burden. But WebIDL has a features where you an
    avoid having the extra getter.

    DS: So, should we continue with the inherited part?

    … and whatcolour should we paint it?

    … not "readonly", "not View"...

    Let's not name it now.

    JS: If inherit describes a property re-using the getter from
    the base class it sounds like a feature created to solve this
    problem, and seemingly it does.

    … so yes. Use it.

    Cam: Thought the question is whether to have a heirarchy of
    DOMRect, not just for getters specifically.
    ... Seems sensible

    AvK: Is clientRect live?


    AvK: So they seem two different things. If one is live and
    another not, they are not so related.

    DS: The ability to make something live doesn't force it to be
    live, so I don't think there is a real difference.

    AvK: For static object you don't need to use getters, because
    you're not returning internal state. That would be much more

    DS: DOMRect only has values...@@@@

    <slightlyoff> annevk: just "property"

    AvK: You can define objects in two ways - getter/setter or

    … That alternative might be better.

    <annevk> slightlyoff: k

    Travis: Starting to sound like arrayness problems for WebIDL -
    arrays that are sometimes static, or maybe not...

    <annevk> slightlyoff: so how do you distinguish that from a
    getter/setter property?

    … if we were ok doing that in WebIDL for arrays, seems OK to
    have an object that has a flag to describe if it is readonly or

    … if it works...

    Cam: But we want to get rid of arrays with internal flags too.

    Travis: Agree, but for the SVG stuff, I don't think there is a
    problem except that we want to consolidate everything of the
    same kinds.

    Cam: Think we do.

    DS: I have no problem with it, but there were objections from
    e.g. Webapps

    JS: Wasthere objection to a subclass that is writeable?

    DS: No

    JS: So we could move forward on that

    Travis: WfM

    AvK: If we don't need getters, we should avoid using them.

    … have a data property instead.

    DS: Don't have dictionaries

    AvK: Doesn't matter

    Cam: That would be the WebIDL way to do this.

    … If we make a @@@@@ for an unchanging object, you can use the
    dictionary version to get.

    … We don't want to have a new version changing values all the

    Alex: By default WebIDL uses getters/setters, whereas
    javascript uses properties. Seems Anne was saying start with
    the obvious thing from javascript.

    … not clear that the base class and then setting a flag to
    force readonly, is a good way. Not natural in Javascript.

    … Concerned that there is a performance argument I would like
    to understand

    Trav: Getter argument is that the platform should not update a
    data value from underneath the JS code. If the value of a
    property is 5, it shouldn't change to 6 without you knowing.

    … for that you have tohave an accessor. DOM attributes are that
    way, but makes sense that the workd is oriented to

    <Daniel_Austin> +1 readonly descends from readable/writeable

    AR: But the single point of truth being something behind the
    object seems like a broken assumption

    JS: Problem is talking about a wide range of objects - lots of
    different behaviours.

    … many objects returning would not make sense with data

    … seems in many cases but not all getters make sense. Maybe not
    as often as we use them.

    … Exception objects are one of the few objects with properties,
    and had getters. That'sthe pattern, but people don't use them

    … If we can return dictionary objects, inertia is why we keep
    using interfaces everywhere.

    Cam: With objects, you use a different construct to get data
    properties instead of accessors. You can't have a data property
    without devolving to prose.

    … Makes sense to use a data property...

    Alex: What's behind the curtain. If there is an IDL that claims
    to say what there is in JS, that doesn't seem to hold. But if
    there is a value where JS isn't privy to it, that would not be
    a fair assumption.

    Cam: If functions that implement getters/setters have access to
    other properties...

    Alex: What are they?

    Cam, Alex: @@@

    [scribe missed this]

    Ryo: You can do something as if ther is a private state and
    getters/setters use that.

    … so they aren't all that rettible. So there are elements where
    it makes sense.

    Alex: Sure. But to implement a class for this I would only have
    getters/setters as an exceptional process.

    … would support @@@@@@@

    <slightlyoff> ...adding properties to itnerfaces in WebIDL

    Cam: For these objects, data properties are more liekly to make
    sense that things in the DOM that need to do computation or
    return non-simple values.

    … depends on the APIs you are talking about which makes more

    [should we keep going...?]

    JS: Seems like if we are going with getters and setters,
    inheritance is the way to go, but think we're not looking
    closely enough at using data properties instead.

    … Don't know for the specific case of Rectangles.

    Cam: Think the proposal was to have both the dictionary and the
    data properties.

    [scribe may have recorded that backwards]

Summary of Action Items

    [NEW] ACTION: barstow start a CfC to publish LCWD of DOM
    Parsing and Serialization [recorded in
    [NEW] ACTION: barstow start CfC to publish PR of Progress
    Events [recorded in
    [NEW] ACTION: barstow work with AvK and Jungkee re the
    Attribution of the Progress Events spec [recorded in
    [NEW] ACTION: dimitri reply to Ryosuke's comments re Custom
    Element as part of LC comments [recorded in

    [End of minutes]

Received on Wednesday, 13 November 2013 09:11:40 UTC