IRC log of webapps on 2013-11-11

Timestamps are in UTC.

00:58:31 [RRSAgent]
RRSAgent has joined #webapps
00:58:31 [RRSAgent]
logging to
00:58:44 [ArtB]
RRSAgent, this meeting spans midnight
00:59:02 [ArtB]
Meeting: WebApps F2F Meeting @ TPAC 2013
00:59:15 [ArtB]
00:59:24 [dom]
dom has joined #webapps
01:04:28 [a12u]
a12u has joined #webapps
01:06:10 [a12u]
a12u has joined #webapps
01:06:19 [edoyle]
edoyle has joined #webapps
01:09:32 [dopi]
dopi has joined #webapps
01:09:41 [dom]
dom has joined #webapps
01:10:42 [nkic]
nkic has joined #webapps
01:11:59 [kennyluck_]
kennyluck_ has joined #webapps
01:12:37 [myakura]
myakura has joined #webapps
01:14:31 [Yudong]
Yudong has joined #webapps
01:15:17 [Yang]
Yang has joined #webapps
01:15:46 [dom_]
dom_ has joined #webapps
01:16:45 [yuka_o_]
yuka_o_ has joined #webapps
01:16:59 [nsakai2__]
nsakai2__ has joined #webapps
01:18:22 [cyril]
cyril has joined #webapps
01:19:56 [richt]
richt has joined #webapps
01:20:38 [richt_]
richt_ has joined #webapps
01:22:51 [ArtB]
Chair: Art, Chaals
01:22:59 [ArtB]
Present+ Art_Barstow
01:23:12 [richt__]
richt__ has joined #webapps
01:23:42 [aizu]
Present+ aizu
01:23:52 [ArtB]
RRSAgent, make minutes
01:23:52 [RRSAgent]
I have made the request to generate ArtB
01:23:58 [ArtB]
RRSAgent, make log Public
01:24:46 [Arno]
Present+ Arnaud_Braud
01:24:50 [mete]
Present+ Mete_Balci
01:24:51 [rsleevi]
rsleevi has joined #webapps
01:24:56 [ArtB]
Present+ Chaals_Nevile
01:24:57 [wayneCarr]
wayneCarr has joined #webapps
01:25:35 [ArtB]
zakim, call shenzhen
01:25:35 [Zakim]
ok, ArtB; the call is being made
01:25:37 [Zakim]
IA_WebApps()7:00PM has now started
01:25:38 [Zakim]
01:26:17 [ArtB]
zakim, who's here?
01:26:17 [Zakim]
On the phone I see Shenzhen
01:26:18 [Zakim]
On IRC I see wayneCarr, rsleevi, richt__, richt_, richt, cyril, nsakai2__, yuka_o_, dom, Yang, myakura, kennyluck, nkic, edoyle, a12u, RRSAgent, glenn, mete, lmclister, byungjung,
01:26:18 [Zakim]
... tomoyuki, Zakim, Arno, denis, aizu, ArtB, Lachy, lgombos_, skddc
01:26:35 [Zakim]
+ +1.503.264.aaaa
01:26:42 [Zakim]
- +1.503.264.aaaa
01:27:00 [Zakim]
01:27:01 [Zakim]
IA_WebApps()7:00PM has ended
01:27:01 [Zakim]
Attendees were Shenzhen, +1.503.264.aaaa
01:27:08 [tomoyuki]
+Present Tomoyuki_Shimizu
01:27:30 [jungkees]
jungkees has joined #webapps
01:27:33 [tomoyuki]
-Present Tomoyuki_Shimizu
01:27:42 [jungkees]
Present+ Jungkee_Song
01:27:47 [aboyet]
aboyet has joined #webapps
01:28:53 [adrianba]
adrianba has joined #webapps
01:29:06 [josh_]
josh_ has joined #webapps
01:29:15 [shepazu]
shepazu has joined #webapps
01:29:18 [Zakim]
IA_WebApps()7:00PM has now started
01:29:25 [Zakim]
01:29:56 [Zakim]
+ +1.503.264.aaaa
01:30:35 [plh]
plh has joined #webapps
01:30:41 [ArtB]
RRSAgent, make minutes
01:30:41 [RRSAgent]
I have made the request to generate ArtB
01:30:56 [mastahyeti]
mastahyeti has joined #webapps
01:31:45 [Eliot]
Eliot has joined #webapps
01:32:24 [Yudong]
Yudong has joined #webapps
01:32:25 [ArtB]
ScribeNick: heycam
01:32:35 [ArtB]
Scribe: Cameron
01:33:00 [Travis_MSFT]
Travis_MSFT has joined #webapps
01:33:01 [dennisdmac]
dennisdmac has joined #webapps
01:33:02 [dezell]
dezell has joined #webapps
01:33:10 [heycam]
Topic: Agenda bashing
01:33:11 [sangrae]
sangrae has joined #webapps
01:33:20 [heycam]
chaals: we have a couple of items already fixed
01:33:27 [heycam]
... at 1:30 the Indie UI people will come and talk to us
01:33:28 [sgalineau]
sgalineau has joined #webapps
01:33:32 [heycam]
... they sent us a new proposal
01:33:36 [heycam]
... they'll talk about that
01:33:36 [xiaoqian]
xiaoqian has joined #webapps
01:33:45 [heycam]
... at 5:00pm we have a couple of things locked in
01:33:52 [heycam]
... there's also a pile of topics we want
01:33:56 [heycam]
... DOM 3 Events, File API, ....
01:34:01 [shepazu]
01:34:08 [heycam]
... we have a couple of requests to have Streams/XHR discussions after lunch, not between 2 and 2:30
01:34:12 [heycam]
... I suggest we push them later
01:34:17 [heycam]
... any preferences for discussing any topics?
01:34:17 [jin]
jin has joined #webapps
01:34:32 [heycam]
shepazu: I think for people who aren't native English speakers, we're on IRC
01:34:39 [heycam]
... anyone need help getting started with that?
01:34:50 [heycam]
... IRC is helpful as the scribe types what everyone is saying
01:34:53 [heycam]
... find me and I can help you
01:35:02 [sgalinea_]
sgalinea_ has joined #webapps
01:35:10 [Daniel_Austin]
Daniel_Austin has joined #WebApps
01:35:13 [paulc]
paulc has joined #webapps
01:35:20 [dopi_]
dopi_ has joined #webapps
01:35:33 [Zakim]
01:35:44 [sgalinea_]
sgalinea_ has joined #webapps
01:35:48 [heycam]
chaals: so Streams and XHR, between those two do we want an hour?
01:35:54 [heycam]
... half an hour each?
01:35:58 [csjung]
csjung has joined #webapps
01:36:06 [chaals]
chaals has joined #webapps
01:36:06 [heycam]
... jungkee does that sound right?
01:36:17 [heycam]
jungkee: I also want to join Sys Apps for service worker introduction, which will happen this afternoon
01:36:22 [bryan]
bryan has joined #webapps
01:36:24 [heycam]
... I don't really know what time that will be
01:36:38 [bryan]
present+ Bryan_Sullivan
01:36:44 [heycam]
... I'll speak to the SysApps chairs to organise a time
01:36:47 [heycam]
... so I'm OK with that
01:36:49 [yuer]
yuer has joined #webapps
01:36:54 [heycam]
... can I talk about Progress Events at the same time?
01:36:56 [heycam]
chaals: yes
01:37:03 [heycam]
... do we want to talk about URLs?
01:37:20 [Kevin_li]
Kevin_li has joined #webapps
01:37:25 [heycam]
... next, Interop and Testing issues
01:37:28 [heycam]
... tomorrow afternoon
01:37:46 [heycam]
ArtB: I can't get to the page right now; we have I think about 6 specs that are in CR right now
01:37:50 [heycam]
... including Progress Events
01:37:55 [heycam]
... for each of those I'd like to get a sense of where we're going with those
01:37:56 [btoews]
btoews has joined #webapps
01:38:01 [heycam]
... who's interested in helping, what are the issues
01:38:07 [heycam]
... that's a bit different from the block set aside for tomorrow afternoon
01:38:18 [heycam]
... jgraham agreed to split that session into the test framework we use, reviewing tests
01:38:22 [heycam]
... and the second half creating tests
01:38:31 [heycam]
... for today's agenda, interop and testing, I think I'd rather do that tomorrow morning
01:38:39 [heycam]
chaals: we can more or less randomly distribute the rest of the topics
01:38:43 [heycam]
... unless someone has a preference
01:38:49 [heycam]
... so let's just put them in in the order they appear
01:39:01 [heycam]
... we have DOM 3 Events, File APIs, IME API, Quota API
01:39:08 [Zeke]
Zeke has joined #webapps
01:39:10 [heycam]
... Streams/XHR we've already git
01:39:10 [heycam]
... and UI Events
01:39:21 [Zakim]
01:39:27 [heycam]
Travis_MSFT: I think we can probably combine the discussion on DOM 3 Events with UI Events
01:39:28 [heycam]
... so don't need separate blocks for those
01:39:44 [heycam]
chaals: should we just do that first?
01:40:00 [heycam]
... first we'll go through all of our specs
01:40:16 [wangxz]
wangxz has joined #webapps
01:40:16 [heycam]
... for a status update; then we'll deal with the specs that need discussion
01:40:16 [heycam]
... first will be DOM 3 Events & UI
01:40:16 [heycam]
ArtB: that OK Gary?
01:40:32 [heycam]
gary: sounds fine
01:40:33 [heycam]
Travis_MSFT: can we do that in the afternoon? I want to attend WebRTC in the morning
01:40:59 [sgalineau]
sgalineau has joined #webapps
01:41:09 [DayangShen]
DayangShen has joined #webapps
01:42:46 [paulc]
Time difference between Shenzhen and Eastern Time is currently + 13 hours.
01:44:04 [Dayang]
Dayang has joined #webapps
01:44:23 [heycam]
sicking: if we can do it early he could call in. 11:30.
01:44:23 [heycam]
chaals: IME at 12?
01:44:23 [heycam]
ArtB: we need Mike Smith for that
01:44:23 [heycam]
chaals: let's put it provisionally at 12
01:44:23 [heycam]
gary: he's busy in the Testing thing
01:44:23 [heycam]
ArtB: Quota API at 14:30
01:44:25 [heycam]
... will we do the File System API at the same time as File API?
01:44:26 [rniwa]
rniwa has joined #webapps
01:44:27 [heycam]
sicking: yes
01:44:31 [heycam]
hober: Mike is fine for that time
01:44:42 [lmcliste_]
lmcliste_ has joined #webapps
01:44:53 [ArtB]
zakim, who's here?
01:44:54 [Zakim]
On the phone I see +1.503.264.aaaa, [IPcaller]
01:44:54 [Zakim]
On IRC I see lmcliste_, rniwa, Dayang, sgalineau, wangxz, Zeke, btoews, Kevin_li, yuer, bryan, chaals, csjung, sgalinea_, dopi_, paulc, Daniel_Austin, jin, xiaoqian, sangrae,
01:44:54 [Zakim]
... dezell, dennisdmac, Travis_MSFT, Yudong, Eliot, plh, shepazu, josh_
01:45:14 [Zakim]
- +1.503.264.aaaa
01:45:32 [ArtB]
zakim, call shenzhen
01:45:32 [Zakim]
ok, ArtB; the call is being made
01:45:34 [Zakim]
01:45:34 [Zakim]
01:45:34 [Zakim]
01:46:36 [Marcus_Altman__]
Marcus_Altman__ has joined #webapps
01:46:43 [Zakim]
01:46:58 [Zakim]
01:46:59 [Zakim]
01:46:59 [Zakim]
01:47:08 [Zakim]
+ +1.503.264.aabb
01:47:53 [shepazu]
/me can people on the phone hear us?
01:48:27 [wangxz_]
wangxz_ has joined #webapps
01:48:36 [wayneCarr]
heard nothing before
01:48:41 [heycam]
Topic: PubStatus
01:48:44 [wayneCarr]
can hear now but not understand
01:48:51 [heycam]
chaals: we'll go through each of the specs we work on
01:49:05 [ArtB]
01:49:11 [heycam]
... the first spec is AppCache NG
01:49:12 [zqzhang__]
zqzhang__ has joined #webapps
01:49:26 [heycam]
... we have a proposal from Jonas
01:49:35 [heycam]
... and we have Service Workers that Alex is working on somewhere
01:49:48 [heycam]
... do we know what his plan is?
01:49:58 [heycam]
ArtB: jungkee you said Alex was going to go through it at SysApps?
01:50:03 [heycam]
... can we get him to present here?
01:50:36 [wxz]
wxz has joined #webapps
01:50:37 [heycam]
jungkees: SysApps WG is working on some runtime design and speccing etc.
01:50:55 [heycam]
... and now a concept like Google's Event Page has been proposed at the last F2F
01:51:03 [heycam]
... after that, Marcos from Mozilla proposed we align our efforts with Service Workers
01:51:17 [heycam]
... since that covers basically the same requirements and use cases
01:51:18 [heycam]
... making the application offline
01:51:18 [heycam]
... so that's the bottom line
01:51:32 [heycam]
... the co-chair of SysApps invited Alex Russell to introduce his Service Worker work this afternoon
01:51:37 [TatsuyaIgarashi]
TatsuyaIgarashi has joined #webapps
01:51:47 [heycam]
... I heard that Alex has a meeting with the TAG this morning
01:51:47 [heycam]
... not sure about the schedule
01:51:58 [joshpeek]
joshpeek has joined #webapps
01:52:02 [heycam]
chaals: we have an open session at 3pm
01:52:02 [heycam]
... can we do that together with Sys Apps then?
01:52:17 [heycam]
jungkees: I think that'd be really nice
01:52:17 [heycam]
... SysApps are also talking about an application model
01:52:55 [kochi_tpac]
kochi_tpac has joined #webapps
01:52:58 [YANG_]
YANG_ has joined #webapps
01:53:14 [btoews]
btoews has left #webapps
01:53:35 [btoews]
btoews has joined #webapps
01:55:47 [heycam]
jungkee: SysApps' charter was for application manifests, etc. like on FirefoxOS
01:55:47 [heycam]
jungkee: IMO they are two different ways of implementing the same goals
01:55:47 [heycam]
... for offline webapps
01:56:02 [heycam]
... so at some point we need to talk about that together
01:56:15 [ken_]
ken_ has joined #webapps
01:56:16 [heycam]
chaals: let's hope to do that at 3pm
01:56:16 [heycam]
... next items is CORS
01:56:16 [heycam]
... we don't have Anne
01:56:16 [heycam]
ArtB: I talked to Wendy a bit about this
01:56:16 [heycam]
... Brad is trying to organise a call with the Director
01:56:30 [heycam]
... the sticking point will be normative references
01:56:30 [heycam]
... one of which is to the Fetch spec
01:56:30 [heycam]
... not sure how that will be resolved
01:56:30 [heycam]
... hopefully PR will be published by the end of this month
01:56:30 [heycam]
chaals: next, Clipboard APIs and events
01:56:44 [heycam]
... we don't have Hallvord
01:56:56 [Zakim]
- +1.503.264.aabb
01:57:35 [ArtB]
ACTION: dimitri reply to Ryosuke's comments re Custom Element as part of LC comments
01:57:35 [trackbot]
Created ACTION-700 - Reply to ryosuke's comments re custom element as part of lc comments [on Dimitri Glazkov - due 2013-11-18].
01:59:19 [Zakim]
01:59:39 [ArtB]
ACTION: barstow start a CfC to publish LCWD of DOM Parsing and Serialization
01:59:39 [trackbot]
Created ACTION-701 - Start a cfc to publish lcwd of dom parsing and serialization [on Arthur Barstow - due 2013-11-18].
02:00:24 [heycam]
chaals: it's in work still?
02:00:24 [heycam]
ArtB: on Oct 17 Hallvord sent a status email
02:00:24 [heycam]
... requesting developer feedback
02:00:24 [heycam]
... nearly right to go to LC, still some bugs open
02:00:24 [heycam]
... only Firefox implements the whole spec, some partial implementations
02:00:24 [heycam]
... an action for Chaals and I to chase those bugs down
02:00:25 [heycam]
chaals: custom elements in in LC
02:00:25 [heycam]
... comments due by 21st
02:00:25 [heycam]
travis: generally do we have any Web Components discussions planned?
02:00:26 [heycam]
rniwa: we have sent some comments
02:00:26 [heycam]
.. for Custom elements about declarative syntax
02:00:26 [heycam]
... we have an issue with the register function taking a prototype
02:00:27 [heycam]
... there's no guarantee that the prototype is an HTML element
02:00:28 [heycam]
... you could inherit from random HTML elements which also could be a concern
02:00:28 [heycam]
... I'd like some time to talk about these issues
02:00:28 [heycam]
chaals: we don't have Dmitry here
02:00:28 [heycam]
... next, DOM Parsing & Serialization
02:00:28 [heycam]
travis: I havent' seen any activity in about a year
02:00:28 [heycam]
... maybe we should just consider moving it along to LC/CR and see if it brings up any feedback?
02:00:29 [heycam]
ArtB: do you want to fix this one bug before LC?
02:00:29 [heycam]
travis: I think it's already fixed in the Living Standard version
02:00:29 [heycam]
... I just need to do the work
02:00:30 [heycam]
... LC next week maybe?
02:00:30 [heycam]
chaals: CfC for LC next week
02:00:30 [heycam]
paulcotton: to go back to DOM 3, are you having a meeting with the Indie UI people?
02:00:31 [heycam]
... there's an overlap between the Indie & PF consistuency
02:00:36 [apps]
apps has joined #webapps
02:00:37 [heycam]
... they've asked for an agenda item in HTML on the relationship between DOM 3, DOM 4 and UI Events
02:00:37 [heycam]
... I wonder if it might make sense to bundle that with the Indie UI item this afternoon
02:00:37 [heycam]
gary: I don't mind covering that
02:00:39 [heycam]
... I won't be around on Thursday
02:00:44 [heycam]
... so definitely on Monday/Tuesday
02:00:51 [heycam]
chaals: I think it is a 2 min discussion
02:00:57 [heycam]
shepazu: 15-30 mins
02:01:10 [heycam]
... I don't think there's a 2 min discussion. it'll take 5 mins to get settled in etc.
02:01:19 [heycam]
... there'll be information shared on both sides
02:01:23 [jj]
jj has joined #webapps
02:01:25 [heycam]
ArtB: we have D3E right after Indie UI
02:01:28 [heycam]
... we can go right into that
02:01:32 [heycam]
chaals: we hope it'll fit in to the agenda
02:01:39 [heycam]
... File API we will discuss after the break
02:01:43 [heycam]
... next: Full Screen API
02:01:48 [heycam]
... do we know anything about that?
02:01:54 [heycam]
... no Tantek
02:02:13 [heycam]
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
02:02:24 [heycam]
... Game Pad, we don't have Scott/Ted in the room
02:02:37 [heycam]
ArtB: the WG members know I attempted to get status in advance for this meeting
02:02:47 [heycam]
... Ted did reply that the spec is being implemented by at least Gecko
02:02:52 [heycam]
... is there interest from other vendors?
02:02:57 [heycam]
... I know Scott works for Google
02:03:05 [heycam]
... any idea about interest in implementation in Chrome? IE, WebKit?
02:03:18 [heycam]
... do you WebKit guys have something like the Chrome Status page?
02:03:26 [heycam]
rniwa: we don't plan to implement Gamepad
02:03:50 [heycam]
... 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
02:04:08 [heycam]
ArtB: one reason for having this conversation is about process
02:04:26 [heycam]
... chaals has been working on getting testing/requirements done earlier in the W3C Process
02:04:30 [Zakim]
02:04:34 [heycam]
... I'm just trying to get a sense on this one
02:04:34 [heycam]
... sounds like it might be iffy moving forwards
02:04:51 [heycam]
adrianba: so we've looked at the spec
02:04:51 [heycam]
... it doesn't necessarily map to the way we think about gamepad
02:05:00 [droh___]
droh___ has joined #webapps
02:05:07 [heycam]
... I know we've thought about how some of the aspects of gamepad, and the buttons etc., mesh with something like DOM Events
02:05:23 [heycam]
... so we don't have any plans for this specific API
02:05:24 [heycam]
... it's an area we've been thinking about
02:05:24 [heycam]
... i don't have anything else right now
02:05:40 [heycam]
gary: one comment to add, from the DOM 3 perspective, looking at the keyboard events
02:05:56 [heycam]
... we assumed some sort of gamepad api would take over for joystick buttons etc.
02:05:57 [heycam]
shepazu: an earlier draft did consider it
02:07:25 [YANG]
YANG has joined #webapps
02:09:09 [heycam]
adrianba: I wasn't suggesting for DOM 3, since we want to get that done
02:09:09 [heycam]
... there's some thinking around multiple users using a common application,
02:09:09 [heycam]
... and if there's more than one keyboard device provided, you might want to take presses from different places
02:09:10 [heycam]
... gamepad takes a simpler model
02:09:10 [heycam]
gary: with buttons, we wanted that to happen
02:09:10 [heycam]
... e.g. click events to fire for buttons
02:09:11 [heycam]
... a recent change in DOM 3 click and dblclick events are fired only for the primary button
02:09:11 [heycam]
... so that doesn't work for gamepad, with a dozen buttons
02:09:11 [heycam]
... that's another area where DOM 3 isn't going to work for gamepad inputs
02:09:12 [heycam]
chaals: HTML Imports
02:09:12 [heycam]
... Dmitry says the essence might go into HTML
02:09:12 [heycam]
... IndexedDB we'll talk about tomorrow
02:09:12 [heycam]
... IME later today
02:09:12 [heycam]
... Pointer Lock, we're in LC
02:09:18 [heycam]
... if you have a comment on that spec, please make it
02:09:24 [heycam]
... well before the end of this month
02:09:33 [heycam]
... do we know impl status for that?
02:09:42 [heycam]
ArtB: I don't have a link to the latest effort
02:09:50 [heycam]
chaals: progress events we'll come back to
02:09:52 [heycam]
... Push API
02:10:01 [heycam]
... Bryan Sullivan?
02:10:13 [heycam]
bryan: the status is accurate
02:10:17 [heycam]
... Art asked a question on the list
02:10:20 [naka]
naka has joined #webapps
02:10:28 [heycam]
... I don't know that we have anybody specifically signed up to be a test facilitator
02:10:31 [heycam]
... afaik no tests have been created yet
02:10:40 [heycam]
... afaik Mozilla is still working on an implementation, for Firefox OS?
02:10:46 [heycam]
... the PAG has done their report
02:10:56 [heycam]
... I think the spec has been pretty stable, for several months now, no outstanding bugs
02:10:59 [heycam]
... not much traffic on the list
02:11:05 [heycam]
... just trying to get through the PAG phase
02:11:20 [heycam]
... and the PAG report was that the exclusions didn't read upon the spec
02:11:31 [heycam]
sicking: there's two challenges
02:11:52 [heycam]
... the first is that the first spec we did, that the PAG looked at, is significantly different from the current draft
02:11:53 [heycam]
... don't know if that's important
02:12:35 [heycam]
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
02:12:35 [heycam]
... whether that happens or not...
02:12:35 [heycam]
... I think the PAG actually looked at the spec as it is now
02:12:58 [TatsuyaIgarashi]
TatsuyaIgarashi has joined #webapps
02:14:59 [naka]
naka has joined #webapps
02:15:07 [jcraig]
jcraig has joined #webapps
02:16:15 [paulc]
02:16:48 [bryan]
scribenick: bryan
02:17:08 [ArtB]
Scribe+ Bryan
02:17:19 [bryan]
topic: SSE status
02:17:21 [bryan]
topic for tomorrow
02:17:35 [bryan]
Shadow DOM, working...
02:17:54 [AndroUser2]
AndroUser2 has joined #webapps
02:18:13 [bryan]
chaals: Screen Orientation API, TAG has issues with it...
02:18:45 [jeff_]
jeff_ has joined #webapps
02:19:06 [bryan]
... 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
02:19:39 [bryan]
... Web IDL, an hour this afternoon
02:19:44 [jjj]
jjj has joined #webapps
02:20:32 [bryan]
... Web Manifest, a work of webapps and sysapps. Marcos indicated there is some research to do. A joint meeting will be planned.
02:21:30 [bryan]
... Web Storage, at REC. Hixie is making changes to his version. Any interest in the next version?
02:22:27 [bryan]
... taking an errata approach, we are required to note them but bothering to do something is another decision
02:23:05 [bryan]
topic: Charter Status
02:23:39 [adrianba]
02:23:41 [bryan]
chaals: charter expires in 6 months. proposed changes is to remove stuff.
02:23:59 [bryan]
artb: no proposed additions at this time.
02:24:02 [jeff_]
Doug, can we get a link to the Charter?
02:24:13 [heycam]
@@ [continuing on Push API after "I think the PAG actually looked at the spec as it is now"] ... not the initial spec
02:24:13 [heycam]
bryan: that's correct
02:24:13 [heycam]
... the spec as it stands now is considerably simpler than it was at FPWD
02:24:13 [heycam]
chaals: the assumption is the risk of further exclusion is reduced
02:24:13 [heycam]
sicking: the other challenge is, while we're defining an API, it's actually undefined how to fire a callback
02:24:13 [heycam]
... the best idea we have is to use service workers
02:24:14 [heycam]
... seems like it's going to be hard to get to Rec without Service Workers
02:24:14 [heycam]
bryan: it also depends on DOM 4
02:24:14 [heycam]
... the events are based on Promises
02:24:15 [heycam]
travis: Promises definition is moving to the ES spec
02:24:15 [heycam]
... so might be slightly easier to depend on there
02:24:15 [heycam]
shepazu: I think it was accepted into the next draft of ES6 @@ [end of previous discussion on Push API]
02:24:32 [shepazu]
02:24:32 [bryan]
adrianba: can we just ask for an extension?
02:24:46 [ArtB]
02:24:57 [shepazu]
02:24:58 [adrianba]
ack me
02:25:31 [bryan]
chaals: we may have some work per results from the supergroup discussion underway in AC
02:25:52 [shepazu]
02:26:13 [bryan]
... any other items we want to fold back in?
02:26:16 [jeff_]
02:27:07 [naka_]
naka_ has joined #webapps
02:27:48 [bryan]
... we could request an extension if it will make life easier, but a proper charter is better and not that hard
02:28:29 [bryan]
shepazu: suggest to push the boundaries re what is allowed in the charter for a supergroup
02:29:15 [bryan]
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
02:29:58 [bryan]
... 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
02:30:03 [ken]
ken has joined #webapps
02:30:11 [jeff_]
02:31:02 [jjj]
jjj has joined #webapps
02:31:39 [bryan]
jgraham: tomorrow afternoon there will be a session on testing; with agenda (1) reviewing - this group has a large backlog
02:31:47 [bryan]
... (2) writing tests
02:32:57 [bryan]
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
02:33:17 [bryan]
... discussion should include what are the deliverables in the 14-15 timeframe
02:33:45 [bryan]
chaals: our pubstatus wiki page gives that info; including this in the charter is trivial but a first approximation
02:33:59 [plh3]
plh3 has joined #webapps
02:34:07 [bryan]
... we have some guesses in the charter but unsuccessful in having actuality match the charter
02:34:50 [bryan]
jeff: to provide at least a guess is good
02:34:56 [AndroUser]
AndroUser has joined #webapps
02:35:39 [bryan]
paulc: selectors API Level 1 is in DOM4?
02:35:46 [bryan]
chaals: no
02:35:59 [bryan]
paulc: can someone explain the relationship?
02:36:17 [kinuko]
kinuko has joined #webapps
02:36:45 [bryan]
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
02:36:51 [jjj_]
jjj_ has joined #webapps
02:37:01 [bryan]
paulc: the pubstatus page says something else
02:37:12 [bryan]
artb: the table has old info
02:37:19 [kochi__]
kochi__ has joined #webapps
02:37:30 [bryan]
paulc: to Jeff's point, that was confusing
02:37:36 [YANG]
YANG has joined #webapps
02:38:18 [jjj_]
jjj_ has joined #webapps
02:38:40 [jjj___]
jjj___ has joined #webapps
02:40:08 [YANG_]
YANG_ has joined #webapps
02:40:38 [jjj_]
jjj_ has joined #webapps
02:41:45 [richt]
richt has joined #webapps
02:43:00 [myakura_]
myakura_ has joined #webapps
02:47:08 [Dayang]
Dayang has joined #webapps
02:50:49 [ArtB]
RRSAgent, make minutes
02:50:49 [RRSAgent]
I have made the request to generate ArtB
02:53:01 [Jiki_M]
Jiki_M has joined #webapps
02:54:19 [ArtB]
Present+ Jonas_Sicking, Cameron_McCormack, Adam_Boyet, Adrian_Bateman, Daniel_Austin, Ed_OConnor, Elit_Graff, Gary_Kacmarcik, James_Graham, Ryosuke_Niwa, Travis_Leithead, Paul_cotton
02:57:06 [Marcus_Altman_]
Marcus_Altman_ has joined #webapps
02:59:38 [btoews]
btoews has joined #webapps
03:02:35 [csjung]
csjung has joined #webapps
03:04:55 [denis]
denis has joined #webapps
03:07:59 [droh__]
droh__ has joined #webapps
03:13:29 [Arno]
Arno has joined #webapps
03:16:17 [csjung]
csjung has joined #webapps
03:18:24 [mete]
mete has joined #webapps
03:20:09 [nkic]
nkic has joined #webapps
03:22:08 [edoyle]
edoyle has joined #webapps
03:23:04 [byungjung]
byungjung has joined #webapps
03:23:06 [LeiWANG]
LeiWANG has joined #webapps
03:23:21 [ken]
ken has joined #webapps
03:23:54 [dezell]
dezell has joined #webapps
03:24:24 [zlei__]
zlei__ has joined #webapps
03:25:16 [byungjung]
byungjung has left #webapps
03:25:20 [yuka_o_]
yuka_o_ has joined #webapps
03:27:08 [ArtB]
RRSAgent, make minutes
03:27:08 [RRSAgent]
I have made the request to generate ArtB
03:27:19 [jjj]
jjj has joined #webapps
03:27:56 [jjj__]
jjj__ has joined #webapps
03:28:23 [JonathanJ]
JonathanJ has joined #webapps
03:28:38 [byungjung]
byungjung has joined #webapps
03:28:47 [jjj__]
jjj__ has joined #webapps
03:29:42 [rniwa]
rniwa has joined #webapps
03:29:56 [jjj__]
jjj__ has joined #webapps
03:30:00 [ArtB]
Present+ Xiaoqian_Wu
03:30:08 [richt]
richt has joined #webapps
03:30:10 [Dayang]
Dayang has joined #webapps
03:30:11 [AndroUser2]
AndroUser2 has joined #webapps
03:30:27 [richt]
richt has joined #webapps
03:30:30 [jungkees_]
jungkees_ has joined #webapps
03:30:39 [jungkees_]
Present+ Jungkee_Song
03:30:49 [myakura]
myakura has joined #webapps
03:32:08 [ArtB]
Present+ Robin_Berjon
03:32:23 [zac]
zac has joined #webapps
03:32:44 [darobin]
darobin has joined #webapps
03:32:52 [a12u]
a12u has joined #webapps
03:33:06 [Daniel_Austin]
Daniel_Austin has joined #WebApps
03:33:11 [bryan]
bryan has joined #webapps
03:33:11 [Dayang]
Dayang has joined #webapps
03:33:17 [ArtB]
scribenick: bryan
03:33:50 [aizu]
aizu has joined #webapps
03:34:03 [jin]
jin has joined #webapps
03:34:12 [Yudong]
Yudong has joined #webapps
03:34:13 [aboyet]
aboyet has joined #webapps
03:34:20 [jjj_]
jjj_ has joined #webapps
03:34:58 [igarashi]
igarashi has joined #webapps
03:35:00 [kennyluck]
kennyluck has joined #webapps
03:35:08 [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
03:35:10 [lmcliste_]
lmcliste_ has joined #webapps
03:35:34 [bryan]
... last minute changes are relatively small so expect that to be implemented quickly
03:35:55 [zqzhang__]
zqzhang__ has joined #webapps
03:35:56 [bryan]
... sync API is not implemented by more than one
03:36:31 [bryan]
... expect a short CR; no test suite yet, but can contribute FF test suite
03:36:55 [bryan]
darobin: think there is a test suite, for at least part of it
03:36:58 [xiaoqian]
xiaoqian has left #webapps
03:37:09 [xiaoqian]
xiaoqian has joined #webapps
03:37:25 [bryan]
jgraham: the test suite there is almost all for blob; half of the spec
03:38:45 [bryan]
chaals: File System APIs...
03:38:55 [paul]
paul has joined #webapps
03:39:25 [richt]
richt has joined #webapps
03:39:29 [bryan]
sicking: that is more controversial; two proposals (google & mozilla); we have not reached out for other implementers
03:39:39 [bryan]
... same status mostly as last TPAC
03:39:59 [YANG]
YANG has joined #webapps
03:40:05 [bryan]
... difference in the APIs is mainly in syntax
03:40:21 [bryan]
... the mozilla one is smaller and uses promises
03:40:51 [jeff]
jeff has joined #webapps
03:41:01 [bryan]
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
03:41:28 [bryan]
... looking at the google API, the notion of a directory entry is only missing the interface to a picker for that purpose
03:41:33 [abarsto]
abarsto has joined #webapps
03:41:50 [bryan]
sicking: both support the idea, but the syntax for bringing up the picker is considered out of scope
03:43:02 [bryan]
... input-type = multiple files is supported by both, but the use case may not be fully supported
03:43:46 [bryan]
adrianba: do you plan to use promises for filesystem as well?
03:44:31 [bryan]
sicking: we should deprecate file reader after implementation, and add this to the filesystem API using streams tied into promises
03:44:42 [Yudong_]
Yudong_ has joined #webapps
03:45:04 [bryan]
... expect this to be a difficult discussion; once we have streams it should be trivial to add
03:45:37 [Zakim]
03:45:52 [ArtB]
zakim, dial shenzhen
03:45:52 [Zakim]
ok, ArtB; the call is being made
03:45:54 [Zakim]
03:45:57 [darobin]
Zakim, who's here?
03:45:57 [Zakim]
On the phone I see Shenzhen (muted), [IPcaller]
03:45:57 [bryan]
aaa: chrome allows apps to recursively select files in directories; is mozilla interested in that?
03:45:58 [Zakim]
On IRC I see Yudong_, ArtB, jeff, YANG, richt, paul, xiaoqian, zqzhang__, lmcliste_, kennyluck, igarashi, jjj_, aboyet, Yudong, jin, aizu, Dayang, bryan, Daniel_Austin, a12u,
03:45:58 [Zakim]
... darobin, zac, myakura, jungkees_, AndroUser2, rniwa, byungjung, JonathanJ
03:46:40 [bryan]
... directory enumeration to filesystem:
03:46:48 [sangrae]
sangrae has joined #webapps
03:47:25 [kinuko]
kinuko has joined #webapps
03:47:26 [zac]
zac has left #webapps
03:47:45 [ArtB]
03:47:52 [bryan]
sicking: the goal is to have the filesystem protocol supported the same across implementations
03:48:03 [rniwa]
ArtB: i think so.
03:48:07 [zac]
zac has joined #webapps
03:48:20 [bryan]
chaals: any input from the room on directions this should go; what people would like to see implemented
03:49:10 [bryan]
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
03:49:14 [plh]
plh has joined #webapps
03:49:20 [bryan]
... highest priority is the read-only structure
03:49:41 [Rayberg]
Rayberg has joined #webapps
03:50:22 [bryan]
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
03:50:53 [TatsuyaIgarashi]
TatsuyaIgarashi has joined #webapps
03:51:27 [bryan]
... a feature that is unclear re implementation is inline editing of files
03:52:31 [bryan]
chaals: other things is the ability to share files between apps; using IndexedDB that may be hard; external filesystem based sharing raises security concerns
03:52:59 [bryan]
... any other plans or uses of filesystem APIs?
03:53:45 [ArtB]
Bryan: re Web and TV, need to store large files
03:53:49 [ArtB]
… e.g. videos
03:54:07 [ArtB]
… one way is file system skin over IDB
03:54:14 [ArtB]
… this is an important UC for us
03:54:30 [ArtB]
… Want to build a media library
03:54:35 [AndroUser2]
AndroUser2 has joined #webapps
03:54:44 [ArtB]
Jonas: have you tried storing large files in IDB?
03:54:49 [zac1]
zac1 has joined #webapps
03:54:50 [ArtB]
… think perf will not be good
03:55:07 [ArtB]
Daniel: thinks SysApps is doing related work in Phase 2
03:55:17 [zac1]
zac1 has left #webapps
03:55:22 [Travis]
Travis has joined #webapps
03:55:32 [kochix]
kochix has joined #webapps
03:55:41 [bryan]
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
03:55:56 [hoyang]
hoyang has joined #webapps
03:55:57 [ArtB]
Arun's spec is
03:56:06 [bryan]
sicking: the performance is expected to be good even for large files
03:56:46 [bryan]
xxx(paypal): the media storage API in sysapps is intended to support the use case for media
03:56:58 [hoyang]
hoyang has left #webapps
03:57:03 [bryan]
(missed question)
03:57:39 [hoyang]
hoyang has joined #webapps
03:57:57 [bryan]
topic: IME
03:58:54 [xiaoqian]
03:59:06 [Daniel_Austin]
xxx(paypal) = Daniel_Austin
03:59:09 [richt]
richt has joined #webapps
03:59:31 [nkic]
nkic has left #webapps
03:59:39 [nkic]
nkic has joined #webapps
04:00:19 [nkic]
nkic has joined #webapps
04:00:30 [garykac]
garykac has joined #webapps
04:00:31 [bryan]
kochi: current status is 3rd WD aug 15
04:01:06 [bryan]
... (showing example onf contenteditable with IME)
04:01:31 [jjj]
jjj has joined #webapps
04:02:14 [ArtB]
Present+ Takayoshi_Kochi, Kinuko_Yasuda
04:02:40 [bryan]
... issues with implementation include that the suggestions UI (system window) conflicts with the UI of the text being edited
04:02:52 [richt]
richt has joined #webapps
04:03:41 [richt]
richt has joined #webapps
04:03:56 [lmcliste_]
lmcliste_ has joined #webapps
04:05:06 [bryan]
... (discussing more changes from latest ED on slide)
04:06:40 [bryan]
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 suggestions
04:07:36 [MikeSmith]
04:07:46 [MikeSmith]
04:08:08 [bryan]
... 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
04:08:50 [bryan]
kochi: canvas-based editor may make sense to split out
04:09:14 [bryan]
(question missed)
04:10:00 [Yudong]
Yudong has joined #webapps
04:10:08 [YANG]
YANG has joined #webapps
04:10:45 [bryan]
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
04:10:53 [richt]
richt has joined #webapps
04:11:28 [bryan]
vvv: we would like one solution, and not have unique APIs for different device use cases; this will be hard for developers otherwise
04:11:54 [ArtB]
q+ chaals
04:11:56 [wayneCarr]
wayneCarr has joined #webapps
04:12:01 [bryan]
... also please explain the use case for enable/disable editing
04:12:07 [richt]
richt has joined #webapps
04:12:39 [bryan]
kochi: a single API may be not useful for all platforms
04:13:49 [igarashi]
igarashi has joined #webapps
04:14:07 [ArtB]
q- chaals
04:14:13 [ArtB]
q- jeff_
04:14:24 [bryan]
... 2nd question re enable/disable; if some extend capabilities beyond what contenteditable provides, it gets complicated to support that with IME
04:14:58 [xiaoqian]
04:15:47 [bryan]
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
04:16:36 [bryan]
kochi: we would like to see a unified API to get notice about blocking events and get window region info
04:16:40 [xiaoqian]
s/(question missed)/What are use cases for enableEditingEvents and disableEditingEvents?/
04:17:26 [bryan]
... for devs who want to optimize for desktop vs mobile, we need ways to customize for different platforms
04:18:45 [ArtB]
zakim, who's here?
04:18:45 [Zakim]
On the phone I see Shenzhen, [IPcaller]
04:18:46 [Zakim]
On IRC I see igarashi, richt, YANG, jjj, garykac, nkic, hoyang, kochix, Travis, AndroUser2, TatsuyaIgarashi, Rayberg, plh, kinuko, sangrae, ArtB, paul, xiaoqian, zqzhang__,
04:18:46 [Zakim]
... kennyluck, aboyet, jin, aizu, Dayang, bryan, Daniel_Austin, a12u, darobin
04:18:52 [bryan]
travis: there are not a lot of standards on how on-screen keyboards work
04:19:04 [Yudong]
Yudong has joined #webapps
04:19:25 [bryan]
... not sure if addressing that falls under IME APIs, but this sounds like a good space to establish standards
04:19:39 [rniwa]
ArtB: thanks for the url!
04:19:53 [rniwa]
MikeSmith: thanks for the url!
04:20:02 [bryan]
kochi: for getting to last call, we may split the spec into UI-related issues, and the editing issues
04:21:26 [bryan]
... we have also had discussion on events; composition events and locale; beforeinput event and order of events
04:21:29 [TatsuyaIgarashi]
TatsuyaIgarashi has joined #webapps
04:21:49 [richt]
richt has joined #webapps
04:22:02 [bryan]
... for future items; writing tests will start once the API is complete
04:22:08 [richt]
richt has joined #webapps
04:22:32 [Daniel_Austin]
Daniel_Austin has joined #WebApps
04:23:10 [bryan]
... 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
04:23:56 [bryan]
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
04:24:34 [bryan]
... 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 that
04:25:06 [bryan]
kochi: so you mean providing IME by the platform and providing IME for specific webapps is different
04:25:55 [bryan]
chaals: that seams reasonable; the accessibility folks are concerned about webapps getting this wrong, whereas the system may do a better job
04:26:24 [bryan]
kochi: we see some use cases e.g. web chat apps that may want to have their own IME
04:27:15 [bryan]
chaals: for our use cases for russian and english etc, we can see the power of the webapp IME
04:27:37 [bryan]
kochi: that's all the input for today
04:27:45 [MikeSmith]
04:28:25 [wayneCarr]
wayneCarr has joined #webapps
04:28:34 [bryan]
rniwa: are you proposing the events issues be addressed in the DOM events?
04:28:47 [bryan]
travis: we should discuss that in the DOM discussion
04:30:01 [richt]
richt has joined #webapps
04:30:05 [bryan]
chaals: the sense seems to be to separate the parts of the spec
04:30:57 [ArtB]
RRSAgent, make minutes
04:30:57 [RRSAgent]
I have made the request to generate ArtB
04:31:11 [ken]
ken has joined #webapps
04:31:38 [Zakim]
04:31:51 [Zakim]
04:33:46 [jjj_]
jjj_ has joined #webapps
04:33:51 [Zakim]
04:34:27 [TatsuyaIgarashi]
TatsuyaIgarashi has joined #webapps
04:38:20 [rniwa]
rniwa has joined #webapps
04:38:31 [jjj]
jjj has joined #webapps
04:39:13 [kinuko]
kinuko has joined #webapps
04:40:31 [kinuko]
kinuko has joined #webapps
04:41:52 [jjj__]
jjj__ has joined #webapps
04:42:31 [jjj___]
jjj___ has joined #webapps
04:43:14 [jjj__]
jjj__ has joined #webapps
04:45:30 [jjj_]
jjj_ has joined #webapps
04:52:50 [jjj]
jjj has joined #webapps
04:53:41 [jjj]
jjj has joined #webapps
04:55:21 [AndroUser2]
AndroUser2 has joined #webapps
04:55:52 [jjj__]
jjj__ has joined #webapps
05:04:12 [Wayne_Carr]
Wayne_Carr has joined #webapps
05:05:42 [btoews]
btoews has joined #webapps
05:06:58 [jjj]
jjj has joined #webapps
05:11:08 [jjj_]
jjj_ has joined #webapps
05:20:12 [sgalineau]
sgalineau has joined #webapps
05:21:19 [sgalineau]
sgalineau has joined #webapps
05:21:43 [YANG]
YANG has joined #webapps
05:26:59 [mete]
mete has joined #webapps
05:31:23 [jcraig]
Zakim, passcode?
05:31:23 [Zakim]
the conference code is 9274 (tel:+1.617.761.6200, jcraig
05:31:55 [xiaoqian]
xiaoqian has joined #webapps
05:32:34 [abarsto]
abarsto has joined #webapps
05:32:54 [ken]
ken has joined #webapps
05:33:23 [Yudong]
Yudong has joined #webapps
05:33:27 [mnot]
mnot has joined #webapps
05:33:38 [Zakim]
05:34:13 [kinuko]
kinuko has joined #webapps
05:34:18 [chaals]
chaals has joined #webapps
05:34:21 [ken]
ken has joined #webapps
05:34:21 [abarsto]
abarsto has joined #webapps
05:35:10 [YANG]
YANG has joined #webapps
05:35:50 [jjj]
jjj has joined #webapps
05:35:57 [a12u]
a12u has joined #webapps
05:36:01 [btoews]
btoews has joined #webapps
05:36:35 [richardschwerdtfeger]
richardschwerdtfeger has joined #webapps
05:36:39 [jjj]
jjj has joined #webapps
05:36:58 [Zakim]
05:37:27 [bin_lee]
bin_lee has joined #webapps
05:38:13 [myakura]
myakura has joined #webapps
05:38:18 [kinuko]
kinuko has joined #webapps
05:38:33 [dom]
dom has joined #webapps
05:38:33 [richardschwerdtfeger]
I can't really hear anything either
05:39:05 [kennyluck]
kennyluck has joined #webapps
05:39:09 [aizu]
aizu has joined #webapps
05:39:15 [abarsto]
scribenick: ArtB
05:39:20 [abarsto]
Scribe+ ArtB
05:39:21 [rniwa]
rniwa has joined #webapps
05:39:24 [plh]
plh has joined #webapps
05:39:31 [abarsto]
Topic: Joint Meeting with IndieUI WG
05:39:38 [adrianba]
adrianba has joined #webapps
05:40:04 [aboyet]
aboyet has joined #webapps
05:40:14 [abarsto]
ArtB: notes, new people include Jania, Michael Cooper, RichS (phone), and some others
05:40:22 [byungjung]
byungjung has joined #webapps
05:40:23 [MichaelC]
MichaelC has joined #webapps
05:40:38 [abarsto]
CN: introduces the Indie UI people
05:40:45 [abarsto]
… basic topic is IndieUI spec
05:40:52 [abarsto]
… was rewritten last week
05:41:12 [abarsto]
Jania: thanks for meeting with us
05:41:19 [Arno]
Arno has joined #webapps
05:41:21 [abarsto]
… we want to share Early in our spec dev
05:41:25 [jcraig]
05:41:35 [abarsto]
… perhaps WebApps will take some of this over at some point
05:41:42 [abarsto]
… User Prefs is one spec
05:41:49 [abarsto]
… called "User Context"
05:41:56 [annevk]
annevk has joined #webapps
05:41:56 [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. "
05:41:57 [abarsto]
… now looking at using Media Queries
05:42:12 [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 WebApps."
05:42:25 [abarsto]
JC: I posted some things into IRC
05:42:38 [Ryladog]
Ryladog has joined #webapps
05:42:41 [abarsto]
Scribenick: abarsto
05:42:43 [csjung]
csjung has joined #webapps
05:42:44 [garykac]
garykac has joined #webapps
05:42:52 [abarsto]
… some overlaps with CSS WG and WebApps
05:43:02 [Travis]
Travis has joined #webapps
05:43:18 [lmcliste_]
lmcliste_ has joined #webapps
05:43:33 [abarsto]
… there is a new privacy model
05:43:38 [abarsto]
… limit set of MQ features
05:44:13 [masatakayakura]
masatakayakura has joined #webapps
05:44:14 [denis]
denis has joined #webapps
05:44:19 [abarsto]
… want to customize UX
05:44:25 [abarsto]
… for some web sites
05:44:35 [abarsto]
… want to use MQ syntax if it fits in
05:44:40 [annevk]
jcraig: enums should use hyphens
05:44:45 [annevk]
jcraig: or just be words
05:44:59 [igarashi]
igarashi has joined #webapps
05:44:59 [annevk]
jcraig: e.g. "arraybuffer", not "arrayBuffer"
05:45:13 [ken_]
ken_ has joined #webapps
05:45:36 [jcraig]
05:45:47 [kochi5]
kochi5 has joined #webapps
05:45:56 [Zakim]
05:46:06 [abarsto]
zakim, dial shenzhen
05:46:06 [Zakim]
ok, abarsto; the call is being made
05:46:08 [Zakim]
05:46:24 [LeiWANG]
LeiWANG has joined #webapps
05:46:28 [cyril]
cyril has joined #webapps
05:47:05 [jin]
jin has joined #webapps
05:47:14 [abarsto]
JC: <scribe misses pretty much all of what James says; needs help scribing>
05:47:39 [edoyle]
edoyle has joined #webapps
05:48:18 [cyns]
cyns has joined #webapps
05:48:24 [jcraig]
If you're asking me anything, please scribe, b/c I cannot hear the phone.
05:48:29 [abarsto]
JS: we met with CSS WG today
05:48:39 [abarsto]
… they will look at our spec and give us feedback
05:48:56 [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.
05:49:01 [abarsto]
Gary: re D3E, wondering about fingerprinting and keyboard layout
05:49:07 [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.
05:49:16 [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.
05:49:22 [abarsto]
… we need to support customized keyboards
05:49:25 [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 settings.
05:49:29 [abarsto]
… need some UX for that
05:49:44 [abarsto]
… We should talk with you in the D3E context
05:50:01 [abarsto]
CN: not sure this effectively solves the fingerprinting prob
05:50:18 [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."
05:50:23 [abarsto]
… my concern is that you have uninformed and no consent
05:50:30 [abarsto]
… forces user to give consent
05:50:33 [jcraig]
A restricted @media block never prompts the user unless both the @media block and an included selector matches.
05:50:41 [jcraig]
For example:L
05:50:57 [abarsto]
Katie: under privacy laws, have to give consent
05:51:07 [abarsto]
… on what can be done with fingerprint info
05:51:14 [abarsto]
… otherwise, can get legal suits
05:51:30 [abarsto]
CN: not sure international laws re fingerprinting will work
05:51:37 [jcraig]
@media (subtitles) { .videoCaptions { display: block; /* custom rendered captions */ } }
05:51:56 [abarsto]
… the tech approach of using MQ for detailed browser sniffing
05:52:01 [abarsto]
… MQ can do the job
05:52:10 [bryan]
bryan has joined #webapps
05:52:12 [abarsto]
… Don't think anyone is saying no, don't use that
05:52:22 [abarsto]
… but I am skeptical about the privacy story
05:52:26 [kochix]
kochix has joined #webapps
05:52:34 [abarsto]
Ryosuke: agree with Chaals
05:52:45 [abarsto]
… can't rely on the laws to save us here
05:53:03 [abarsto]
Gary: if we expose this in any way, you won't be satisfied?
05:53:06 [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…
05:53:21 [abarsto]
… not sure it is quite so clear
05:53:27 [abarsto]
… is there an impasse here
05:53:39 [abarsto]
… not sure where we go with this
05:53:46 [abarsto]
CN: not about acceptable or not
05:54:00 [abarsto]
… but saying it will protect your privacy is overselling
05:54:03 [jcraig]
The other aspect about this that I'd like to bring to the WG's attention is currently a todo in the draft:
05:54:10 [abarsto]
… don't see it as an impasse
05:54:22 [abarsto]
… but if the privacy system doesn't protect privacy
05:54:28 [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 as:
05:54:28 [jcraig]
<meta name="userMediaSettings" content="Used to enable captions and display them in your preferred font size and color.">
05:54:39 [abarsto]
… need to recognize their are implications of providing more info
05:54:40 [jcraig]
Justification string would be included in the user prompt.
05:54:54 [abarsto]
CN: I'm not saying `don't do this`
05:54:59 [jcraig]
We think this is broader in scope than just this MQ proposal.
05:55:05 [abarsto]
… but *I* am unconvinced
05:55:08 [annevk]
05:55:17 [annevk]
We already lost the fingerprinting battle
05:55:18 [abarsto]
… privacy protection is sufficient
05:55:20 [annevk]
05:55:23 [annevk]
It's called etag
05:55:42 [abarsto]
CN: encourage you to take this to Privacy Interest Group
05:55:43 [kennyluck]
kennyluck has joined #webapps
05:55:53 [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.
05:56:06 [abarsto]
AvK: I think we already lost the fingerprinting battle
05:56:31 [abarsto]
… don't think we can win this
05:56:38 [abarsto]
Travis: but we should try
05:56:40 [AndroUser]
AndroUser has joined #webapps
05:57:17 [Eliot]
Eliot has joined #webapps
05:57:18 [abarsto]
CN: agree fundamentally the fingerprinting battle is lost
05:57:33 [abarsto]
… this could minmize the fingerprinting
05:57:36 [Yudong]
Yudong has joined #webapps
05:57:55 [abarsto]
… agree with Travis and this approach can help minimize exposure
05:58:06 [abarsto]
… but there will always be some unprotection
05:58:20 [abarsto]
Katie: technology is not the way privacy is protected currently
05:58:23 [darobin]
darobin has joined #webapps
05:58:26 [abarsto]
… at some point that may change
05:58:38 [jcraig]
WG, do you agree the "justification" string idea may be useful for Location sharing as well as this idea?
05:58:53 [abarsto]
… If some org doesn't do what they said they will do, there can be
05:58:58 [abarsto]
… reprucussions
05:59:23 [abarsto]
CN: this could be reasonably protective in some countries
05:59:46 [abarsto]
… in some countries there aren't good laws
06:00:09 [abarsto]
Gary: if there a bunch of MQs, is there going to be just one dialog?
06:00:16 [Marcus_Altman]
Marcus_Altman has joined #webapps
06:00:16 [abarsto]
… or some choice?
06:00:21 [abarsto]
… is that all in scope
06:00:28 [abarsto]
JS: I don't think we have worked that out
06:00:39 [abarsto]
… but I don't think we want to overburden the user
06:00:51 [abarsto]
CN: I would expect that to be an impl detail for the browsers
06:01:04 [abarsto]
JC: if there are many MQs, I expect just one dialog
06:01:07 [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 as:
06:01:08 [jcraig]
<meta name="userMediaSettings" content="Used to enable captions and display them in your preferred font size and color.">
06:01:12 [abarsto]
… take a look at the ToC
06:01:13 [jcraig]
06:01:32 [abarsto]
… there are diff categories
06:01:53 [masatakayakura]
masatakayakura has joined #webapps
06:02:37 [jungkees_]
jungkees_ has joined #webapps
06:02:41 [abarsto]
CN: if user changes devices or device state often (e.g. sound on/off)
06:02:49 [ken]
ken has joined #webapps
06:02:58 [abarsto]
… don't want to constrain the browser
06:03:12 [dezell]
dezell has joined #webapps
06:03:19 [abarsto]
… Good impls will decide to make it easy for user
06:03:20 [jcraig]
For example, matchMedia('(subtitles)') and matchMedia('(subtitle-type: cc)') would only prompt the user once, because the media feature types are related.
06:03:27 [ken]
ken has joined #webapps
06:03:28 [abarsto]
… or to provide power control to the user
06:03:37 [jcraig]
specifics of prompt will be UA implementation details
06:03:38 [droh__]
droh__ has joined #webapps
06:03:38 [abarsto]
… but I don't think the spec should constrain the options
06:04:05 [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.
06:04:09 [Stone]
Stone has joined #webapps
06:04:35 [zqzhang__]
zqzhang__ has joined #webapps
06:04:36 [abarsto]
JC: <something about location data; scribed missed comment>
06:04:57 [jcraig]
the "justification" string idea could be used in Location prompts as well.
06:05:01 [abarsto]
Cynthina: IE uses vendor prefix for MQ and high constrast
06:05:05 [abarsto]
… setting part of OS
06:05:21 [abarsto]
… UA can use that setting
06:05:24 [jcraig]
So the site can specify to the user why it wants to use this information
06:05:29 [abarsto]
… simple from authoring perspective
06:05:47 [abarsto]
CN: I haven't heard anyone say `no, this approach is not sound`
06:05:57 [jcraig]
-ms-high-contrast values are *very* specific to Microsoft's implementation
06:05:59 [jjj]
jjj has joined #webapps
06:06:02 [abarsto]
JS: summary … go ahead; nuance the privacy story
06:06:09 [abarsto]
… tell the story correctly
06:06:15 [abarsto]
… go talk to PING
06:06:48 [jcraig]
and I think -ms-high-contrast can generalized into media features for contrast-increased, user-color, and user-background-color.
06:06:49 [kinuko]
kinuko has joined #webapps
06:06:50 [abarsto]
Ryoskue: re the requests, different syntax than in DOM spec
06:07:11 [jcraig]
06:07:14 [abarsto]
… would be good to consolidate the events that are now in diff specs
06:07:32 [Yudong]
Yudong has joined #webapps
06:07:37 [abarsto]
CN: re the events stuff, yes, we need serious coordination
06:07:56 [darobin]
darobin has joined #webapps
06:08:17 [abarsto]
Jania: I accept the request to coordinate with the events
06:08:26 [abarsto]
… we are hoping to get to LC by EoYear
06:08:51 [abarsto]
James: did you mean UIEvents spec or Context spec?
06:09:10 [abarsto]
CN: we should have a separate discussion about events
06:09:24 [abarsto]
Gary: keyboard layout is another coordination point
06:09:30 [abarsto]
… I should be the contact point
06:09:35 [jcraig]
Or something else related to "Events", IRC log is limited and phone call is unintelligible
06:09:40 [abarsto]
CN: James, that's Gary you should talk to
06:10:09 [abarsto]
Topic: DOM 3 Events & UI Events
06:10:24 [nkic]
nkic has joined #webapps
06:10:29 [ijongcheol]
ijongcheol has joined #webapps
06:10:31 [Daniel_Austin_]
Daniel_Austin_ has joined #WebApps
06:10:40 [annevk]
(For the record, it's done here: )
06:11:17 [Daniel_Austin_]
lol @abarsto
06:11:33 [myakura]
myakura has joined #webapps
06:12:05 [abarsto]
CN: < a bit of a digression on why D3E is done in one WG and DOM4 done in a separate group >
06:12:09 [YANG_]
YANG_ has joined #webapps
06:12:10 [richt]
richt has joined #webapps
06:12:11 [dyang]
dyang has joined #webapps
06:12:53 [Rayberg]
Rayberg has joined #webapps
06:13:07 [dennisdmac]
dennisdmac has joined #webapps
06:13:14 [abarsto]
Rich: what about the device specific events?
06:13:28 [abarsto]
CN: we are about to talk about DOM 3 Events now
06:13:44 [Zakim]
06:14:00 [adrianba]
ScribeNick: adrianba
06:14:08 [adrianba]
TOPIC: D3E and UI Events
06:14:21 [adrianba]
gary: we have another LCWD for DOM3 Events
06:14:29 [adrianba]
... we think this is really the last one
06:14:40 [abarsto]
RRSAgent, make minutes
06:14:40 [RRSAgent]
I have made the request to generate abarsto
06:14:44 [adrianba]
... we just released a WD a week or two ago
06:14:45 [abarsto]
Scribe+ Adrian
06:14:54 [adrianba]
... expect to have another LCWD in dec or jan
06:14:56 [AndroUser2]
AndroUser2 has joined #webapps
06:15:02 [adrianba]
... we have made a bunch of changes we'd like people to review
06:15:06 [naka]
naka has joined #webapps
06:15:08 [lmclist__]
lmclist__ has joined #webapps
06:15:09 [adrianba]
... so that we have a good LCWD draft
06:15:14 [adrianba]
... want to summarise the changes
06:15:30 [adrianba]
... not to discuss but so you know where to read if you have comments
06:15:40 [adrianba]
... we took the deprecated stuff and put it into an appendix
06:15:49 [taocai]
taocai has joined #webapps
06:15:51 [adrianba]
... examples don't use deprecated stuff
06:15:53 [abarsto]
D3E bugs:
06:15:57 [adrianba]
... for example char went away
06:16:06 [adrianba]
... locale got removed from D3E
06:16:18 [adrianba]
... currently a BCP47 string which is too general
06:16:23 [annevk]
I'm confused. Isn't char implemented?
06:16:31 [adrianba]
... need to think about this so we move it into UIEvents to do later
06:16:46 [adrianba]
... this is the first version that talks about beforeinput and input
06:16:59 [adrianba]
... we rely on them as a replacement for keypress event
06:17:08 [adrianba]
... keypress is deprecated event
06:17:12 [hoyang]
hoyang has joined #webapps
06:17:20 [darobin_]
darobin_ has joined #webapps
06:17:21 [Eliot]
Eliot has joined #webapps
06:17:24 [adrianba]
... beforeinput is fired, then DOM is updated, then input is fired
06:17:38 [adrianba]
... click and double-click suggested all buttons should fire click and double-click
06:17:44 [adrianba]
... this is only for primary button
06:17:54 [adrianba]
... on composition events we spent time on order of firing events
06:18:00 [kinuko]
kinuko has joined #webapps
06:18:03 [adrianba]
... composition events relative to input events
06:18:17 [adrianba]
... dead keys are handled like small IMEs with composition events
06:18:29 [adrianba]
... earlier versions had special handling for dead key values
06:18:42 [adrianba]
... tried to specify event ordering - little more formal than before
06:18:52 [adrianba]
... the last thing is the relationship with DOM 2 Events
06:19:03 [adrianba]
... DOM2 had unspecified keycode attribute
06:19:13 [adrianba]
... in general DOM3 is an improvement, superset of DOM2
06:19:20 [adrianba]
... but it isn't for some key character information
06:19:40 [adrianba]
... previously you could tell which physical key was pressed - cannot do this with key event in DOM3
06:19:51 [adrianba]
... code attribute in UI Events will handle this scenario
06:20:08 [adrianba]
... if we want DOM3 to be full superset then we should consider moving code into DOM3
06:20:18 [adrianba]
... if people have thoughts on that they should let us know
06:20:22 [chaals]
chaals has joined #webapps
06:20:28 [adrianba]
... i think we should move it in but others want to avoid delays
06:20:38 [adrianba]
... biggest concern is lack of test coverage
06:20:45 [adrianba]
... that is an area of focus now
06:21:31 [richardschwerdtfeger]
06:21:32 [adrianba]
annevk: question about legacy stuff
06:21:46 [adrianba]
... do you think you can get it removed from chrome?
06:21:52 [adrianba]
gary: which legacy stuff?
06:22:03 [adrianba]
annevk: the things you're proposing to remove
06:22:26 [richardschwerdtfeger]
I will ask my question here:
06:22:28 [adrianba]
gary: you're wondering when we're likely to get rid of keychar and keycode?
06:22:44 [adrianba]
... they will live as long as web sites need them to be around - we need a good spec to replace them
06:22:53 [adrianba]
... don't see them going away soon
06:23:03 [adrianba]
... i don't have a timeframe on that
06:23:18 [richardschwerdtfeger]
rich: Why is there a MouseEvent Constructor in UIEvents and not with the MouseEvent in DOM3?
06:23:38 [annevk]
garykac: so that seems kinda contrary to how we define many features
06:23:50 [annevk]
garykac: basically, if a user agent needs to implement in order to be competitive, we should define how it works
06:24:09 [adrianba]
gary: i think people were trying to finish DOM3 and other new stuff went into UI Events
06:24:26 [xiaoqian]
zakim, ack richardschwerdtfeger
06:24:26 [Zakim]
I see no one on the speaker queue
06:24:31 [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
06:24:31 [adrianba]
... i think we should merge but this would delay DOM3
06:24:41 [kochix_]
kochix_ has joined #webapps
06:24:54 [adrianba]
richardschwerdtfeger: the problem with this is we don't know what to refer to - is one going to go away
06:25:25 [annevk]
(Referring to this as DOM3 is hugely confusing btw. We should really name both "UI Events".)
06:25:25 [adrianba]
chaals: when figuring this out for SVG you don't know which spec to rely on
06:25:37 [adrianba]
gary: we have an appendix telling you the old way and saying don't do this
06:25:41 [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?
06:25:53 [adrianba]
... but this is a good example of why moving things from UI Events into D3E would help
06:25:56 [tao]
tao has joined #webapps
06:26:16 [adrianba]
... for the constructor I don't think there is a big risk - we could move them into D3E
06:26:24 [richardschwerdtfeger]
Rich: I agree with Adrian
06:26:46 [jjj_]
jjj_ has joined #webapps
06:27:06 [adrianba]
Travis: if we can get things in and stabilise them then that sounds good
06:27:07 [richardschwerdtfeger]
adrian: you stated: but this is a good example of why moving things from UI Events into D3E would help
06:27:13 [richardschwerdtfeger]
Rich: I agreed
06:27:19 [adrianba]
chaals: the question was about constructors and code attribute
06:27:28 [adrianba]
annevk: that suggestion has been made for ages
06:27:38 [annevk]
garykac: name it UI Events too then!
06:27:42 [adrianba]
heycam: i think one of the problems with the question which version do we reference from SVG
06:27:44 [annevk]
garykac: backport the name
06:27:49 [adrianba]
... it really doesn't matter
06:27:53 [richardschwerdtfeger]
Rich: SVG2 is going to last call at the end of the year. we need something that is clear
06:27:56 [adrianba]
... we don't rely on the constructor
06:28:04 [adrianba]
... so whichever you care about
06:28:06 [adrianba]
06:28:21 [adrianba]
... so reference the latest one and consider earlier ones if you want
06:28:44 [adrianba]
chaals: known issue at W3C of having specs out of sync
06:29:01 [adrianba]
... sounds like the sensible thing is to look at the modern spec and use it as your working reference
06:29:15 [adrianba]
... if you run into trouble you can consider process hoops for changing reference
06:29:29 [richardschwerdtfeger]
Rich: what is "modern"?
06:29:35 [adrianba]
... but now it is more common to publish Rec based on draft spec if the part you depend on is stable enough
06:30:06 [adrianba]
gary: considering UI Events was primary given constructors and code attribute
06:30:21 [adrianba]
... it was a dumping ground for feautures we didn't think would make it into D3E
06:30:28 [adrianba]
... we would only have a couple of small things left
06:30:33 [chaals]
[UIEvents is more modern than DOM3, DOM4 is more modern again, If I got it right...]
06:30:34 [richardschwerdtfeger]
Rich: but keyboard events is now fully specified in UI events separate from the DOM3 spec.
06:30:56 [adrianba]
chaals: questions on D3E or UI Events?
06:31:17 [adrianba]
06:31:20 [adrianba]
06:31:36 [adrianba]
kinuko: quota api status
06:31:38 [yang]
yang has joined #webapps
06:31:44 [adrianba]
... just published new WD beginning of this month
06:31:49 [adrianba]
... API is still very small
06:32:14 [adrianba]
... two apis - query current usage status and to request new quota for application
06:32:24 [adrianba]
... in the new draft they are both promises
06:32:30 [adrianba]
... previously callback based
06:32:40 [adrianba]
... also added quota storage change events
06:32:42 [garykac]
richardschwerdtfeger: keyboard events are not fully specified in UI Events. Only the additional KeyboardEvent info live there at the moment.
06:32:49 [adrianba]
... so apps can watch how usage is increased
06:32:53 [myakura]
06:33:06 [adrianba]
... new draft has changes that lose compat from old version
06:33:14 [richardschwerdtfeger]
We need to reference the actual event interface definition
06:33:15 [shepazu]
shepazu has joined #webapps
06:33:21 [adrianba]
... we wanted to make it work better with other promise based apis
06:33:33 [adrianba]
... including imagined ones like service worker
06:33:54 [garykac]
Once we move |code| into DOM3, then DOM3 will have a complete KeyboardEvent specification
06:33:59 [adrianba]
... previous api was only implemented by chrome - would like to get more support from other browser vendors on new version
06:34:15 [adrianba]
... think this api is very important for mobile web apps using local storage
06:34:19 [richardschwerdtfeger] and
06:34:27 [richardschwerdtfeger]
so it is defined in two different places
06:34:31 [adrianba]
... for web apps and user to agree on how much data can be stored on local device
06:34:43 [adrianba]
... should be addressed in unified way not in each storage api
06:34:48 [adrianba]
... would appreciate comments
06:35:03 [adrianba]
chaals: obvious question is to implementors
06:35:15 [plh]
plh has joined #webapps
06:35:32 [adrianba]
sicking: mozilla are very interested in implementing this - doesn't mean we are fully happy with api
06:35:45 [adrianba]
... looks great so far but need the person actually implementing to review
06:35:47 [richardschwerdtfeger]
rich: which this?
06:35:51 [ken]
ken has joined #webapps
06:35:51 [adrianba]
chaals: does that mean you have someone on this?
06:35:57 [adrianba]
sicking: not yet
06:36:29 [ken]
ken has joined #webapps
06:36:32 [sgalineau]
sgalineau has joined #webapps
06:36:56 [adrianba]
chaals: no current plans or comments from others?
06:37:01 [adrianba]
... probably two implementations at some point
06:37:14 [adrianba]
... sounds like we will get comments and presumably the spec will move forward
06:37:25 [sgalineau]
sgalineau has joined #webapps
06:37:37 [adrianba]
Travis: haven't looked at the spec in detail
06:38:05 [adrianba]
... most browsers will have a quota management experience, not sure about the API, i know in IE the browser will prompt me
06:38:07 [adrianba]
06:38:24 [adrianba]
annevk: one comment on the IDL - it uses array that is going away
06:38:34 [adrianba]
... seems like some of this will need to change - not sure how
06:38:49 [paul]
paul has joined #webapps
06:38:54 [adrianba]
... what travis said sort of makes sense - pretty hard to ask the user about amount of space
06:39:00 [adrianba]
... platforms we compete with don't do this
06:39:14 [adrianba]
... seems like we should strive for this if we want to compete with native platforms
06:39:29 [adrianba]
... for example heuristics about how often the app or site is used
06:39:46 [adrianba]
chaals: Flash apps annoy me because they ask me to allocate memory all the time
06:40:05 [adrianba]
... agree with anne that the implementation is going to be combination of talking to the user and doing things for the user
06:40:29 [adrianba]
... 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
06:40:34 [adrianba]
... basic idea seems okay
06:40:45 [adrianba]
... perhaps browser can grant request without the user
06:40:51 [adrianba]
... [some examples given]
06:41:05 [adrianba]
... does seem like makes sense and important to compete with other platforms
06:41:10 [heycam`]
heycam` has joined #webapps
06:41:13 [adrianba]
kinuko: this API defines two types of storage
06:41:20 [adrianba]
... temporary and persistent
06:41:31 [adrianba]
... temp can probably be used without prompt but could be deleted
06:41:38 [adrianba]
... slightly different experience to native apps
06:41:55 [adrianba]
... for web apps people might visit site and then never return
06:42:04 [adrianba]
... browsers need a way to know to delete data if they want
06:42:06 [annevk]
06:42:24 [adrianba]
sicking: to answer a couple of questions
06:42:28 [annevk]
q+ to suggest bookmarking could be used as a hint for persistence
06:42:39 [adrianba]
... our goal is to prompt users as little as possible for current apis
06:42:39 [abarsto]
RRSAgent, make minutes
06:42:39 [RRSAgent]
I have made the request to generate abarsto
06:42:59 [adrianba]
... we have temporary storage and because we're doing apps thing
06:43:15 [adrianba]
... for apps installed or bookmarked or whatever we can provide persistent storage
06:43:22 [adrianba]
... blown away when user uninstalls
06:43:34 [adrianba]
... what travis said about prompting is what we did in firefox so far
06:43:51 [adrianba]
... devs don't have to worry but bad that many developers want to manage when prompts come up
06:44:06 [abarsto]
Present+ Anne_van_Kesteren, Alex_Russell, Richard_Tibbett, Mark_Nottingham
06:44:07 [adrianba]
... they want to forewarn users to let them know why they get a prompt
06:44:23 [adrianba]
... have thought about ability to put quota manager in automatic mode
06:44:34 [adrianba]
... whether that should be default behaviour i don't know
06:44:44 [adrianba]
... that's not in draft - only thing i think might be missing
06:44:55 [annevk]
06:45:10 [richardschwerdtfeger]
richardschwerdtfeger has left #webapps
06:45:24 [Zakim]
06:46:01 [adrianba]
sicking: being able to say that persistent storage doesn't deny when hitting quota then the browser just prompts
06:46:08 [adrianba]
... adds complexity for implementation
06:46:28 [naka_]
naka_ has joined #webapps
06:46:40 [adrianba]
kinuko: we thought about this and tried to implement but suspending execution of storage api while showing prompts tended to make things very complicated
06:46:51 [adrianba]
... also cannot predict when prompts will be shown
06:46:55 [annevk]
q+ to ask what's the story for Chrome OS?
06:47:06 [adrianba]
... we share same experience but this is why we excluded this option
06:47:34 [adrianba]
kinuko: if we did this in an automatic way do you mean we wouldn't need api?
06:47:45 [adrianba]
sicking: this would be an additional piece of the api
06:48:01 [Yudong]
Yudong has joined #webapps
06:48:06 [adrianba]
chaals: this would be an addition to make browser keep prompting when anyone else would be denied
06:48:16 [adrianba]
... worth thinking about but can see issues in practice
06:48:25 [adrianba]
sicking: that behaviour is in gecko right now
06:48:32 [adrianba]
... was default behaviour in indexed db
06:48:50 [adrianba]
... we would keep prompting - eventually if you keep saying yes then we give you whatever you want
06:49:02 [adrianba]
... developers were not in control of when prompts happen which was bad
06:49:11 [adrianba]
chaals: not sure how bad it was
06:49:18 [adrianba]
... not in control of when you run out of memory
06:49:35 [adrianba]
kinuko: spec doesn't explicitly say when to show prompt
06:49:40 [adrianba]
... in chrome we don't show every time
06:49:50 [ken]
ken has joined #webapps
06:49:52 [garykac]
garykac has joined #webapps
06:49:57 [adrianba]
... might be session based
06:50:08 [adrianba]
... not sure if it should be more specifically speced - left to implementations
06:50:09 [adrianba]
06:50:24 [lmcliste_]
lmcliste_ has joined #webapps
06:50:34 [xiaoqian]
zakim, ack annevk
06:50:34 [Zakim]
annevk, you wanted to ask what's the story for Chrome OS?
06:50:35 [Zakim]
I see no one on the speaker queue
06:50:35 [adrianba]
annevk: could imagine model where every web page gets 100MB of temp space
06:50:44 [adrianba]
... browser might drop this
06:50:54 [adrianba]
... if you bookmark something then you get persistent storage
06:51:12 [adrianba]
... site might advocate to the user to bookmark to make it part of the user's ecosystem
06:51:25 [adrianba]
... seems hard to prompt user for 100MB -what does this mean?
06:51:32 [adrianba]
... how did you solve this in chrome os?
06:51:55 [adrianba]
kinuko: we don't really solve the problem - we have two types of apps
06:51:59 [adrianba]
... installed and linked
06:52:04 [Tomoyuki1]
Tomoyuki1 has joined #webapps
06:52:10 [slightlyoff]
abarsto: I have no slides. was informed I'd be leading this only this morning
06:52:10 [adrianba]
... app can say it wants storage and is prompted during installation
06:52:33 [adrianba]
... we build many important apps as installed packaged apps
06:52:37 [tao]
tao has joined #webapps
06:52:41 [adrianba]
sicking: we do similar in firefox os
06:52:44 [slightlyoff]
abarsto: but if you have the projector, might be useful to have this document up on screen:
06:53:14 [adrianba]
chaals: there are some apps that i want to store lots of data even though i only use them every 6 months
06:53:35 [richt]
richt has joined #webapps
06:53:38 [adrianba]
... not sure how to solve that automatically or by asking users questions they understand
06:54:02 [adrianba]
chaals: we are expecting sysapps in 5 mins - suggest 5 min break
06:54:15 [adrianba]
chaals: let's have a break
06:54:30 [richt]
richt has joined #webapps
06:54:38 [abarsto]
… that's a *5* min break!
06:55:05 [ijongcheol]
ijongcheol has joined #webapps
06:55:31 [ken_]
ken_ has joined #webapps
06:56:27 [johnny__]
johnny__ has joined #webapps
06:56:58 [cwdoh]
cwdoh has joined #webapps
06:58:19 [byungjung]
byungjung has joined #webapps
06:58:22 [csjung]
csjung has joined #webapps
06:58:31 [Toshiya_]
Toshiya_ has joined #webapps
06:58:38 [kennyluck]
kennyluck has joined #webapps
06:58:52 [saki]
saki has joined #webapps
06:58:56 [Tomoyuki]
Tomoyuki has joined #webapps
06:59:10 [johnny_]
johnny_ has joined #webapps
06:59:45 [nsakai2]
nsakai2 has joined #webapps
07:00:18 [wonsuk]
wonsuk has joined #webapps
07:01:05 [jungkees]
jungkees has joined #webapps
07:01:36 [johnny_]
johnny_ has joined #webapps
07:02:06 [hoyang]
hoyang has joined #webapps
07:02:46 [denis]
denis has joined #webapps
07:02:52 [abarsto]
zakim, who's here?
07:02:52 [Zakim]
On the phone I see Shenzhen
07:02:54 [Zakim]
On IRC I see denis, hoyang, johnny_, jungkees, wonsuk, nsakai2, Tomoyuki, saki, kennyluck, Toshiya_, csjung, byungjung, cwdoh, ken_, tao, garykac, heycam`, paul, sgalineau, plh,
07:02:54 [Zakim]
... shepazu, yang, jjj_, kochix_, chaals, kinuko, Eliot, darobin_
07:02:57 [Travis]
scripe: Travis
07:03:02 [Travis]
scribeNick: Travis
07:03:13 [Travis]
Topic: ServiceWorkers
07:03:42 [jinsong]
jinsong has joined #webapps
07:03:51 [naka]
naka has joined #webapps
07:03:51 [btoews]
btoews has joined #webapps
07:03:51 [Travis]
Alex: Will provide brief explainer of Service Workers
07:04:03 [dyang]
dyang has joined #webapps
07:04:04 [richt]
richt has joined #webapps
07:04:23 [richt]
richt has joined #webapps
07:04:33 [Travis]
... attempt to provide background scripting to manage stuff that is hard to capture/handle.
07:04:48 [virginie]
virginie has joined #webapps
07:04:51 [JonathanJ]
JonathanJ has joined #webapps
07:04:51 [Travis]
... offline bootstrapping is hard--Service Workers can address this concern
07:04:54 [lmcliste_]
lmcliste_ has joined #webapps
07:05:10 [Travis]
... they are like shared workers, but lifetime is versioned.
07:05:25 [nkic]
nkic has joined #webapps
07:05:26 [Travis]
... like background extensions in Chrome
07:05:28 [Mohammed_]
Mohammed_ has joined #webapps
07:05:47 [ijongcheol]
ijongcheol has joined #webapps
07:05:58 [Travis]
... general idea is core of the system is to register a script that can run with a url pattern
07:06:10 [JonathanJ]
rrsagent, draft minutes
07:06:11 [RRSAgent]
I have made the request to generate JonathanJ
07:06:12 [Travis]
... handle events in an async way.
07:06:13 [Anders]
Anders has joined #webapps
07:06:26 [Travis]
... no synchronous APIs (unlike shared workers)
07:06:41 [Travis]
... status-- happening in github
07:06:54 [Travis]
... intent is to bring the work to Web Apps WG
07:07:13 [Travis]
... since webapps wanted to handle the offline use case, service workers should be a good fit.
07:07:22 [Travis]
... Chrome is prototyping to see if it's suitable
07:07:33 [ito]
ito has joined #webapps
07:07:38 [shepazu]
07:07:44 [Travis]
Ryu: what are the use cases?
07:07:57 [Travis]
Alex: primary use case is offline problem
07:07:59 [cwdoh]
cwdoh has joined #webapps
07:08:40 [Travis]
... didn't scale well
07:09:02 [Travis]
... appcache didn't quite work for all the scnearios that apps needed.
07:09:28 [Travis]
... had to either use IDB or local storage, but these aren't well suited for URL management and fetching.
07:10:00 [Travis]
... you want to have hierarchy or list of caches to independently manage.
07:10:14 [sho]
sho has joined #webapps
07:10:21 [Travis]
... other use cases: alarms API, push notifications, data sync in background (less fleshed out)
07:10:25 [kkubota2_]
kkubota2_ has joined #webapps
07:10:26 [dka]
dka has joined #webapps
07:10:48 [Travis]
... there was a name change, but not so far along on the details of those use cases
07:10:55 [xiaoqian]
zakim, ack shepazu
07:10:55 [Zakim]
I see no one on the speaker queue
07:10:57 [chaals]
ack sh
07:11:00 [Travis]
shepazu: Does it persist from navigation to navigation?
07:11:05 [johnny]
johnny has joined #webapps
07:11:10 [mizuman_]
mizuman_ has joined #webapps
07:11:22 [Travis]
... one use case may go beyond offline, and provide animations, or persistent audio?
07:11:23 [naka]
naka has joined #webapps
07:11:26 [edoyle]
edoyle has joined #webapps
07:11:28 [Dong-Young_Lee]
Dong-Young_Lee has joined #webapps
07:11:39 [Travis]
.. have you thought about using it like a proxy between page loads?
07:11:51 [Travis]
Alex: no visual component (just background execution context)
07:12:00 [Travis]
... it can coordinate between pages, etc.
07:12:02 [ijongcheol]
ijongcheol has joined #webapps
07:12:13 [boryung]
boryung has joined #webapps
07:12:20 [Travis]
... to smoothly move from online -> offline world, you need to bootstrap the service worker.
07:12:33 [Travis]
... first need to install the service worker.
07:12:44 [zqzhang]
zqzhang has joined #webapps
07:12:47 [Travis]
... after that you get the next doc installed under the service worker.
07:13:11 [Travis]
... there will just be one instance of the service worker (not multiple)
07:13:24 [igarashi]
igarashi has joined #webapps
07:13:31 [cwdoh_]
cwdoh_ has joined #webapps
07:13:42 [Travis]
shepazu: CSS resources? How would it work with it?
07:13:44 [adrianba]
07:13:46 [Travis]
Alex: not sure.
07:13:47 [adrianba]
07:13:58 [Travis]
... CSS is local to a single running doc.
07:14:11 [Travis]
... but without rendering, not sure how it would integrate.
07:14:30 [chaals]
07:14:34 [mounir_]
mounir_ has joined #webapps
07:14:34 [bryan]
07:14:37 [abarsto]
q- adrianb
07:14:44 [johnny]
johnny has joined #webapps
07:14:55 [Travis]
adrianba: If the app is listening for fetching... does this have perf implications on network requests?
07:15:05 [Travis]
Alex: Still trying to get data on this.
07:15:11 [Ruinan]
Ruinan has joined #webapps
07:15:23 [Travis]
... the async nature makes this feel a lot like Node.js authoring.
07:15:39 [Travis]
... fetch event can only respond with promises.
07:16:08 [johnny_]
johnny_ has joined #webapps
07:16:27 [Travis]
... a storm of requests will block based on the service worker being a single thread.
07:16:57 [Travis]
Daniel (ebay): What are the security implications, threats, and countermeasures you are planning?
07:17:20 [Travis]
Alex: Jonas has helped look into the security issues.
07:17:31 [Travis]
... biggest impacting problem is...
07:18:52 [Travis_]
Travis_ has joined #webapps
07:19:25 [Travis_]
Alex: We welcome any review.
07:19:46 [Travis_]
Daniel (ebay): what is the physically security of a local-stored service worker?
07:20:14 [Yudong]
Yudong has joined #webapps
07:20:18 [gwm]
gwm has joined #webapps
07:20:21 [thinker]
thinker has joined #webapps
07:20:26 [Travis_]
Alex: Service worker is backed by HTTP cache-like thing. Code itself is stored as per browser's code storage permission model.
07:20:32 [annevk]
HTTP cache is dead, long live HTTP cache /cc mnot
07:20:41 [krijnh]
krijnh has joined #webapps
07:20:41 [johnny]
johnny has joined #webapps
07:20:54 [Travis_]
... should be comperable to the browser's local security model. Not sure there's more security layers to add on top of that.
07:21:15 [abarsto]
07:21:15 [Travis_]
... It's a cache-wide problem, not just for service-worker
07:21:20 [abarsto]
q- chaals
07:21:36 [Travis_]
chaals: When a CSS page refers to other pages @import.
07:21:42 [Travis_]
... how are these managed?
07:21:58 [johnny_]
johnny_ has joined #webapps
07:22:18 [Travis_]
Alex: Initial service worker kicks in.
07:22:30 [Travis_]
... initial CSS goes to the service worker...
07:22:42 [Travis_]
... sub-downloads hit the sevice worker serially as they come in.
07:23:05 [richt]
richt has joined #webapps
07:23:07 [Travis_]
... like the service worker is a virutal networking layer. It sees the fully-formed request.
07:23:12 [abarsto]
q- bryan
07:23:14 [johnny]
johnny has joined #webapps
07:23:20 [abarsto]
07:23:36 [chaals]
q+ plh
07:23:46 [Travis_]
Bryan: Says you can defer loading.
07:23:49 [richt]
richt has joined #webapps
07:23:54 [Travis_]
... Tell me more?
07:24:09 [ijongcheol]
ijongcheol has joined #webapps
07:24:11 [Travis_]
Alex: The service worker will see all requests once it's set up.
07:24:29 [Travis_]
... non-http requests are not speced to be handled.
07:24:42 [Travis_]
chaals: not data:
07:25:05 [cwdoh]
cwdoh has joined #webapps
07:25:07 [Travis_]
bryan: <clarifying behavoir>
07:25:14 [Travis_]
... does it interact with XHR?
07:25:14 [Yudong]
Yudong has joined #webapps
07:25:17 [Travis_]
Alex: yes
07:25:29 [richt]
richt has joined #webapps
07:25:30 [Travis_]
... think about this like Mod.Proxy for the browser.
07:25:50 [annevk]
Come on, someone ask something tricky
07:25:54 [annevk]
Like how this works with sync XHR
07:25:55 [tao]
tao has joined #webapps
07:25:59 [annevk]
(it doesn't)
07:25:59 [Travis_]
... XHR requests eventually filter through to service worker
07:26:15 [slightlyoff]
annevk: wait, I thought you said "hard"
07:26:19 [Travis_]
bryan: For offline: you should be able to package server code in the client
07:26:43 [johnny_]
johnny_ has joined #webapps
07:26:46 [Travis_]
Alex: yes, but the patterns for app construction in flux.
07:27:16 [mnot]
07:27:19 [Travis_]
... today we think of server requests first, but with service workers, alternative scenarios are enabled.
07:27:37 [abarsto]
07:27:42 [abarsto]
q- plh
07:27:45 [Travis_]
... we're not defining the cannonical way of doing offline.
07:27:48 [chaals]
q+ rich
07:27:59 [Travis_]
plh: Is there a use case for the web app to know what is offline?
07:28:29 [ken]
ken has joined #webapps
07:28:33 [Travis_]
Alex: yes, it's specifically designed into the system.
07:29:06 [Travis_]
... so that when you're offline, you can have a pre-populated set of data (part of the installation model)
07:29:24 [abarsto]
q- mnot
07:29:37 [Travis_]
Mark: Service worker will not go to the browser's cache?
07:29:55 [Travis_]
... you could create your own cache?
07:30:13 [richt]
richt has joined #webapps
07:30:21 [Travis_]
Alex: If you hit the network, you still go through the normal network, including the http cache
07:30:41 [Travis_]
... it's only a detail that service worker updates themselves work around this.
07:30:59 [aboyet]
aboyet has joined #webapps
07:31:18 [Travis_]
... otherwise, its the burden/logic of the service worker to handle any other case like fallback to missing live info.
07:31:39 [Travis_]
Mark: there is lots of flexibility. Coolness.
07:31:41 [abarsto]
q- rich
07:31:42 [heycam`]
07:31:55 [Travis_]
Richt: Sounds like 4 things merged into one.
07:32:07 [Travis_]
... seems like you've invented http primitives.
07:32:16 [Travis_]
... could we use that outside of service workers?
07:32:19 [naka_]
naka_ has joined #webapps
07:32:26 [MikeSmith]
RRSAgent, make minutes
07:32:26 [RRSAgent]
I have made the request to generate MikeSmith
07:32:37 [Travis_]
Alex: goal is to enable offline and than abstract it out.
07:32:52 [Travis_]
... we're trying to make sure we're aligned with Anne's Fetch algorithm.
07:32:52 [jehoochen]
jehoochen has joined #webapps
07:33:16 [Travis_]
... so we may also be able to expose caches objects... but these are secondary goals.
07:33:25 [Travis_]
... primarily it needs to solve the main use case, first.
07:33:49 [MikeSmith]
i/We welcome any review/scribe: Travis_/
07:33:53 [Travis_]
heycam`: How does the service worker determine to fallback to the network?
07:33:55 [MikeSmith]
RRSAgent, make minutes
07:33:55 [RRSAgent]
I have made the request to generate MikeSmith
07:34:11 [Travis_]
Alex: Service worker can't include XHR (because of it's sync-option)
07:34:33 [Travis_]
... the service worker allows you to connect requests with responses arbitrarily.
07:35:10 [Travis_]
heycam`: Are you forced to use fetch, or can you do something else?
07:35:15 [Travis_]
Alex: just ignore the request.
07:35:28 [slightlyoff]
Travis_: yeah, explicitly, don't call e.respondWith()
07:35:34 [Travis_]
heycam`: Seems like many new scenarios come out of this...
07:35:47 [MikeSmith]
q+ to ask about the plan is to create a WebIDL interface definition for ServiceWorker or more broadly an actual spec of ServiceWorker
07:35:50 [mnot]
07:36:04 [israelh]
israelh has joined #WebApps
07:36:04 [Travis_]
Alex: yes.
07:36:17 [denis]
denis has joined #webapps
07:36:18 [ken]
ken has joined #webapps
07:36:23 [abarsto]
q- heycam`
07:36:33 [israelh]
israelh has joined #webapps
07:36:39 [Travis_]
Jonas: Allows a lot of combinations of scenarios. You don't have to respone 1:1 with each request now.
07:36:50 [Travis_]
... can do server-side templating.
07:36:53 [bryan]
07:37:04 [Travis_]
MikeSmith: Notices we don't have a spec???!!!!
07:37:04 [abarsto]
q- MikeSmith
07:37:13 [dennisdmac]
dennisdmac has joined #webapps
07:37:15 [annevk]
slightlyoff: so what is the idea for sync XHR again?
07:37:23 [Travis_]
... Expected a WebIDL????!!!!
07:37:26 [slightlyoff]
annevk: sync is only sync from the perspective of the document
07:37:30 [annevk]
oh MikeSmith <3
07:37:38 [Travis_]
chaals: Already covered :0)
07:37:47 [efullea_]
efullea_ has joined #webapps
07:37:58 [Travis_]
Alex: I'll get the spec together after we get through the existing github bugs
07:38:05 [tao]
tao has joined #webapps
07:38:08 [abarsto]
q- mnot
07:38:09 [annevk]
slightlyoff: I guess, but if the SW messages the document and awaits a reply, it's dead
07:38:22 [btoews]
btoews has joined #webapps
07:38:41 [Travis_]
mnot: How do you minimize duplication between http-cache and synthetic caches. Also resource management: do you prompt the user.
07:38:54 [heycam`]
07:39:09 [Travis_]
Alex: On duplication. Could be cheap.
07:39:24 [hoyang]
hoyang has joined #webapps
07:39:42 [adrianba_]
adrianba_ has joined #webapps
07:39:58 [Travis_]
... on the storage level, you can have more persistent info that doesn't get cache-evicted.
07:40:09 [Travis_]
... on storage limits, we don't have this solved.
07:40:53 [Travis_]
... there's no distinction for some storage technologies for persistent vs. not (it's all just file-system)
07:41:05 [Travis_]
... and other open issues. Working on fleshing these out.
07:41:19 [cwdoh]
cwdoh has joined #webapps
07:41:41 [thinker]
q+ What does make service worker better than a wrapper of XHR in the content?
07:41:41 [Travis_]
mnot: de-dup in http-caches. This could solve it. I really like the way this is going. It's coolness.
07:41:44 [abarsto]
q- bryan
07:41:46 [Soonho]
Soonho has joined #webapps
07:41:50 [Travis_]
bryan: Service workers can't use XHR?
07:41:59 [Travis_]
bryan: what else can't they use?
07:42:01 [thinker]
07:42:22 [Travis_]
Alex: It's limited to much fewer things you think (all sync stuff is blocked)
07:42:44 [Travis_]
avk: why not just remove the sync-bit?
07:42:57 [xiaoqian]
07:43:05 [Travis_]
Alex: we could entertain that. We didn't go that direction.
07:43:53 [Travis_]
Alex: think about a worker with all sync-stuff removed (with importScript as the exception)
07:44:03 [Travis_]
bryan: So, it can't be used to build offline apps?
07:44:23 [Travis_]
Alex: No.
07:44:43 [Travis_]
... You can handle request in any way you like, you can postMessage, you can manage storage locations, etc.
07:44:46 [MikeSmith]
07:45:05 [Travis_]
chaals: the app can still use XHR, of course. It's just not in service worker.
07:45:07 [heycam`]
07:45:18 [thinker]
07:45:26 [Tomoyuki1]
Tomoyuki1 has joined #webapps
07:45:37 [Travis_]
heycam`: Can you stream a response back from the service worker?
07:45:43 [Travis_]
Alex: No answer to that now.
07:45:49 [MikeSmith]
audible sigh from slightlyoff
07:45:55 [Travis_]
... Seems like we need something like Streams...??
07:46:10 [Zakim]
07:46:11 [Zakim]
IA_WebApps()7:00PM has ended
07:46:11 [Zakim]
Attendees were +1.503.264.aaaa, [IPcaller], Shenzhen, +1.503.264.aabb, James_Craig, Rich_Schwerdtfeger
07:46:13 [MikeSmith]
RRSAgent, make minutes
07:46:13 [RRSAgent]
I have made the request to generate MikeSmith
07:46:16 [annevk]
Weird to say no to XHR based on a theoretical fetch API but say this here slightlyoff
07:46:27 [Travis_]
Ted: [muted]
07:46:58 [Travis_]
... Fetch vs. XHR: XHR is platform for http-requests. Fetch is the way for how the network requests stuff.
07:46:58 [richt]
richt has joined #webapps
07:47:08 [Travis_]
Alex: XHR != fetch
07:47:09 [Zeke]
Zeke has joined #webapps
07:47:28 [Travis_]
Ted: seems like a terrible approach to have both.
07:47:39 [slightlyoff]
07:47:42 [slightlyoff]
was about to say that = )
07:47:52 [cwdoh_]
cwdoh_ has joined #webapps
07:47:52 [richt_]
richt_ has joined #webapps
07:48:00 [ken]
ken has joined #webapps
07:48:04 [Travis_]
Jonas: XHR doesn't have a great way to represent requests (not just response) and stuff for CORS.
07:48:26 [adrianba]
adrianba has joined #webapps
07:48:35 [richt]
richt has joined #webapps
07:48:36 [Travis_]
paul: How does service worker work "upwords"?
07:49:03 [abarsto]
07:49:04 [Marcus_Altman]
Marcus_Altman has joined #webapps
07:49:05 [Travis_]
Alex: whichever core capabilities are plumbed into it. For example other services that could be put into it.
07:49:29 [Travis_]
... Alarms, etc., another service layer for the web. For things that don't need UI.
07:50:02 [dayang]
dayang has joined #webapps
07:50:17 [Mohammed_]
Mohammed_ has left #webapps
07:50:28 [JonathanJ]
rrsagent, draft minutes
07:50:28 [RRSAgent]
I have made the request to generate JonathanJ
07:50:38 [richt]
richt has joined #webapps
07:50:42 [Toshiya]
Toshiya has joined #webapps
07:50:46 [mizuman]
mizuman has joined #webapps
07:51:13 [saki]
saki has joined #webapps
07:51:43 [ijongcheol]
ijongcheol has joined #webapps
07:55:16 [johnny]
johnny has joined #webapps
07:56:27 [tao]
tao has joined #webapps
07:57:37 [ijongcheol]
ijongcheol has joined #webapps
07:57:44 [johnny_]
johnny_ has joined #webapps
07:58:43 [jjj]
jjj has joined #webapps
08:00:39 [johnny__]
johnny__ has joined #webapps
08:01:54 [hoyang]
hoyang has joined #webapps
08:05:48 [Tomoyuki]
Tomoyuki has joined #webapps
08:06:32 [Tomoyuki1]
Tomoyuki1 has joined #webapps
08:07:10 [csjung]
csjung has joined #webapps
08:08:31 [ijongcheol]
ijongcheol has joined #webapps
08:09:53 [nkic]
nkic has joined #webapps
08:10:40 [kinuko]
kinuko has joined #webapps
08:12:22 [aizu]
aizu has joined #webapps
08:12:30 [denis_]
denis_ has joined #webapps
08:13:25 [Tomoyuki]
Tomoyuki has joined #webapps
08:14:30 [minami]
minami has joined #webapps
08:15:37 [btoews]
btoews has joined #webapps
08:15:50 [byungjung]
byungjung has joined #webapps
08:16:24 [saki]
saki has joined #webapps
08:17:01 [Toshiya]
Toshiya has joined #webapps
08:17:35 [AndroUser2]
AndroUser2 has joined #webapps
08:18:06 [Toshiya_]
Toshiya_ has joined #webapps
08:19:00 [Toshiya]
Toshiya has joined #webapps
08:19:08 [ken]
ken has joined #webapps
08:19:20 [myakura]
myakura has joined #webapps
08:19:26 [a12u]
a12u has joined #webapps
08:19:38 [Marcus_Altman]
Marcus_Altman has joined #webapps
08:19:46 [paul]
paul has joined #webapps
08:19:54 [abarsto]
RRSAgent, make minutes
08:19:54 [RRSAgent]
I have made the request to generate abarsto
08:19:56 [ijongcheol]
ijongcheol has joined #webapps
08:20:30 [dennisdmac]
dennisdmac has joined #webapps
08:20:34 [Toshiya]
Toshiya has joined #webapps
08:20:54 [bryan]
bryan has joined #webapps
08:21:10 [Toshiya__]
Toshiya__ has joined #webapps
08:21:23 [Tomoyuki]
Tomoyuki has left #webapps
08:21:24 [Travis_]
Scribe: Travis_
08:21:29 [heycam`]
heycam` has joined #webapps
08:21:30 [Travis_]
ScribeNick: Travis_
08:21:32 [Jirka]
Jirka has joined #webapps
08:21:34 [nikos]
nikos has joined #webapps
08:21:46 [aizu]
aizu has joined #webapps
08:21:52 [saki_]
saki_ has joined #webapps
08:21:55 [satakagi]
satakagi has joined #webapps
08:22:09 [dyang]
dyang has joined #webapps
08:22:32 [btoews]
btoews has joined #webapps
08:22:33 [hoyang]
hoyang has joined #webapps
08:22:36 [Toshiya_]
Toshiya_ has joined #webapps
08:22:41 [saki__]
saki__ has joined #webapps
08:22:48 [Travis__]
Travis__ has joined #webapps
08:22:53 [mete]
mete has joined #webapps
08:23:08 [Travis]
Travis has joined #webapps
08:23:15 [Travis]
Topic: Streams
08:23:30 [Toshiya_]
Toshiya_ has joined #webapps
08:23:31 [abarsto] -> WD published 5-Oct-2013
08:23:32 [Travis]
08:23:46 [saki___]
saki___ has joined #webapps
08:23:52 [jungkees]
jungkees has joined #webapps
08:23:59 [Daniel_Austin]
Daniel_Austin has joined #WebApps
08:24:05 [mizuman]
mizuman has joined #webapps
08:24:16 [Travis]
Topic: XHR and Progress Events
08:24:23 [aboyet]
aboyet has joined #webapps
08:24:58 [jungkees]
08:25:08 [dezell]
dezell has joined #webapps
08:25:23 [darobin]
darobin has joined #webapps
08:25:32 [naka]
naka has joined #webapps
08:25:32 [Travis]
jungkees: looking at XHR1
08:25:38 [Travis]
... in spec history section
08:25:52 [Lachy]
Lachy has joined #webapps
08:25:58 [Travis]
... some features left out of the living standard...
08:26:16 [Travis]
... fetching data uris and anonymous flag
08:26:20 [ijongche_]
ijongche_ has joined #webapps
08:26:35 [Travis]
... some behaviors are not compatible
08:26:48 [edoyle]
edoyle has joined #webapps
08:26:57 [jungkees]
08:27:07 [johnny]
johnny has joined #webapps
08:27:21 [Travis]
jungkees: looking at test cases in W3C test repo
08:27:29 [Travis]
... current status of browser implementation
08:27:35 [myakura]
08:27:37 [Travis]
... covers 95%+ of spec
08:27:42 [tobie]
tobie has joined #webapps
08:27:45 [Travis]
... compat numbers are 50-60%
08:27:58 [Travis]
... now filing bugs with relevant implementations
08:28:05 [Travis]
... path to interop and CR.
08:28:09 [Toshiya]
Toshiya has joined #webapps
08:28:12 [Travis]
... this is our current status.
08:28:33 [Toshiya]
Toshiya has joined #webapps
08:28:42 [Travis]
... we have ~11 issues in bug list.
08:28:44 [_nikos_office]
_nikos_office has joined #webapps
08:28:54 [dong]
dong has joined #webapps
08:28:54 [Travis]
... only 1/2 are issues we need to solve for L1 XHR spec
08:29:07 [Travis]
... (1 or 2) not 1/2
08:29:12 [AndroUser2]
AndroUser2 has joined #webapps
08:29:14 [richt]
richt has joined #webapps
08:29:30 [Travis]
jungkees: One of these 21650:
08:29:57 [dopi]
dopi has joined #webapps
08:30:06 [Travis]
... xhr has a limitation in responseType==document
08:30:16 [yang]
yang has joined #webapps
08:30:21 [Travis]
... other issues are related to bleeding edge features that can be handled in next version.
08:30:28 [bryan]
08:30:34 [Travis]
Art: are you marking the bugs for v1 and v2?
08:30:49 [jinsh]
jinsh has joined #webapps
08:31:08 [AndroUser]
AndroUser has joined #webapps
08:31:10 [Travis]
jungkees: having an issue with the alignment with the fetch spec.
08:31:31 [Travis]
... need to discuss how to handle referencing the fetch spec in the W3C spec.
08:31:41 [Travis]
... not sure how to deal with that.
08:31:55 [Travis]
chaals: not a technical issue, just a doc/process spec.
08:32:14 [Travis]
jungkees: we are referencing WHATWG at the moment.
08:32:22 [Travis]
... we should be ready for LC soon.
08:32:29 [mizuman_]
mizuman_ has joined #webapps
08:32:46 [Travis]
... during LC we can resolve the issue with responseType==document and focus on browser interop and bugs.
08:32:53 [Travis]
chaals: what are the implementation plans.
08:33:38 [Travis]
jungkees: some interop differences: one browser fires "progress" other's don't.
08:34:07 [Travis]
... there are some subtle differences.
08:34:33 [Travis]
abarsto: Are there any tests for v2 (in the list of test from the w3c site)
08:34:37 [Travis]
08:35:03 [Travis]
jungkees: All of the tests are based on the living standard. We will see which will drop for the v1 spec.
08:36:33 [Travis]
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?
08:37:34 [kevin-li]
kevin-li has joined #webapps
08:39:02 [Travis_]
Travis_ has joined #webapps
08:39:07 [Eliot]
Robin: We can identify the best and brightest tests.
08:39:22 [kinuko]
kinuko has joined #webapps
08:39:36 [rniwa]
rniwa has joined #webapps
08:39:48 [Travis_]
Robin: Might be worth looking into library code (jQuery) to prioritize bugs to fix.
08:40:17 [JonathanJ]
JonathanJ has joined #webapps
08:40:19 [Travis_]
abarsto: Will Robin/James work with jungkees to help get these tests prepared?
08:40:52 [abarsto]
s/help get these tests/prepared/help identify those tests that are mandatory for CR/
08:41:01 [Travis_]
adrianba: To Robin on the question of interop bugs worked around in jQuery: is the 'we' the working group?
08:41:18 [Travis_]
Robin: I think they're likely working around real problems.
08:41:33 [Travis_]
... if this delays the spec a little while, then OK.
08:41:59 [richt]
richt has joined #webapps
08:42:05 [Travis_]
adrianba: still trying to understand the priority. I think this is about having a good spec.
08:42:25 [Travis_]
... these tests don't need to be fixed at the same rate as implementations move forward.
08:42:46 [JonathanJ1]
JonathanJ1 has joined #webapps
08:42:58 [abarsto]
q+ Paul
08:43:06 [Travis_]
... 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.
08:43:36 [dka]
dka has joined #webapps
08:43:52 [Travis_]
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.
08:44:28 [Travis_]
... without resolving this, XHR authors may have to work around bugs.
08:44:40 [Travis_]
chaals: there are different authors for the spec.
08:45:08 [Daniel_Austin]
q+ Daniel_Austin
08:45:21 [Travis_]
... implementers are one categories. Authors want to look at the spec and write to that.
08:45:46 [Travis_]
... may be nice to have the spec speak to the reliability of certain features in the spec.
08:46:36 [abarsto]
q+ James
08:46:44 [annevk]
08:46:49 [annevk]
(need bigger O)
08:46:53 [abarsto]
q- Paul
08:47:00 [Travis_]
... it's nice to have the next version coming so that we can look forward to it's more specific requirements.
08:47:06 [virginie]
virginie has joined #webapps
08:47:40 [AndroUser2]
AndroUser2 has joined #webapps
08:47:50 [Travis_]
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.
08:48:00 [abarsto]
q- Daniel_Austin
08:48:26 [hober]
annevk: o_O
08:48:34 [Travis_]
Daniel (ebay): Since XHR came out, it's not just browser user agents, but having a reliable spec is good.
08:48:55 [Travis_]
jgraham: post re-writing the spec to be more vague is a really bad idea.
08:49:12 [naka_]
naka_ has joined #webapps
08:49:17 [plh]
plh has joined #webapps
08:50:36 [annevk]
hober: nice
08:50:43 [xiaoqian]
q- James
08:51:03 [adrianba]
08:51:10 [adrianba]
08:51:18 [annevk]
darobin: could just remove the conformance section
08:51:24 [annevk]
darobin: would also make it shorter
08:51:44 [richt]
richt has joined #webapps
08:52:04 [hober]
annevk darobin: we could start using other RFC 2119 terms like "UAs MIGHT AS WELL ..."
08:52:26 [annevk]
08:52:39 [Toshiya]
Toshiya has joined #webapps
08:52:40 [saki]
saki has joined #webapps
08:52:52 [darobin]
hober: I think you mean RFC 6919
08:53:00 [dong]
dong has joined #webapps
08:53:06 [Travis_]
jgraham: The right way of solving the problem is to use a test suite to show authors how reliable and interoperable is the spec.
08:53:14 [AndroUser2]
AndroUser2 has joined #webapps
08:53:18 [Travis_]
... I don't think the right solution is to change the spec.
08:53:21 [Travis_]
adrianba: I agree.
08:53:22 [kennyluck]
kennyluck has joined #webapps
08:53:28 [Daniel_Austin]
RFC 6919
08:53:29 [annevk]
"MUST (BUT WE KNOW YOU WON'T)" hahaha, forgot about that RFC
08:53:29 [xiaoqian]
08:53:43 [xiaoqian]
ack adrianba
08:53:49 [Travis_]
... it seems odd to update the spec according to where implementations are at some moment in time.
08:53:59 [Travis_]
... via MUST to SHOULD update.
08:54:08 [Marcus_Altman___]
Marcus_Altman___ has joined #webapps
08:54:32 [Travis_]
chaals: well, we shouldn't change must to should just to squeak out of a process requirements.
08:54:37 [annevk]
abarsto: but it's his favorite proposal
08:54:41 [annevk]
abarsto: he makes it at least once a year
08:54:47 [Travis_]
... going from test->spec can be challenging.
08:55:10 [Travis_]
jgraham: historically we've done a poor job of having a test suite.
08:55:24 [Travis_]
... we need to work on test suite results and how we present them.
08:55:48 [Travis_]
... as implementation run the tests we can gather the data more reliably.
08:56:11 [Travis_]
adrianba: we have some places where we want to correlate this data, like in Web Platform Docs.
08:57:15 [Travis_]
chaals: my basic goal is to get what is needed now, and not wait while we develop our test suites and tools.
08:57:17 [nkic_]
nkic_ has joined #webapps
08:57:30 [Travis_]
jungkees: Initial intention was to exclude features not running well across the board.
08:57:56 [Travis_]
... our findings uncovered that some things are running fine in 2 of the browsers.
08:58:22 [Travis_]
... the core editors found that these are the pimitives of the fetching of resources.
08:58:28 [saki_]
saki_ has joined #webapps
08:58:37 [Travis_]
... we want to keep going with current set of features.
08:58:37 [abarsto]
08:58:50 [Travis_]
chaals: What happens now? LC and long wait?
08:59:07 [Travis_]
jungkees: and working on test suites until CR exit. Want to start LC now.
08:59:27 [Toshiya]
Toshiya has joined #webapps
08:59:50 [Travis_]
... we don't see too many issues in the spec itself, but want to focus on solving implementation gaps.
09:00:15 [Travis_]
... perhaps Q2 of next year we can review the bugs to see how browser interop is improving.
09:00:35 [Travis_]
... interop will improve, libraries will be easier to maintain, etc.
09:00:42 [Travis_]
... that's our current viewpoint.
09:01:23 [richt]
richt has joined #webapps
09:01:45 [Travis_]
paulc: Q on original stats: only 50% of the results give consistent results... at least 2 browsers pass each of them?
09:02:02 [igarashi_]
igarashi_ has joined #webapps
09:02:57 [Travis_]
chaals: what is the intersection for at least two implementations?
09:03:55 [Travis_]
israelh: how do we prioritize? Put my high priority tests together, then the bugs that don't impact most sites, this could work.
09:04:13 [xiaoqian]
RRSAgent, make minutes
09:04:13 [RRSAgent]
I have made the request to generate xiaoqian
09:04:28 [Travis_]
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.
09:04:45 [satakagi]
satakagi has joined #webapps
09:04:49 [Travis_]
jungkees: Given major implementations, pass ratio is much higher (than 50%).
09:05:09 [Travis_]
... we've tested three major tests: blink, gecko, trident.
09:05:30 [dong]
dong has joined #webapps
09:05:40 [Travis_]
paulc: my personal opinion: we'll never get a spec published if we expect 100% interop.
09:06:05 [Travis_]
... if this spec is to goto CR, what is the exit criteria.
09:06:34 [Travis_]
... the WG needs to define what it believes is necessary.
09:06:54 [Daniel_Austin]
+1 to Paul's comments
09:07:16 [ijongcheol]
ijongcheol has joined #webapps
09:07:20 [jungkees]
09:07:28 [Travis_]
chaals: how much progress are we making on progress events?
09:07:38 [Travis_]
jungkees: Looking at progress events test results.
09:08:34 [AndroUser2]
AndroUser2 has joined #webapps
09:08:56 [Travis_]
... waiting on bug fixes for Blink to improve the test results.
09:10:09 [Travis_]
... if we do have concensus, we need to try to get it on the list.
09:10:17 [abarsto]
ACTION: barstow start CfC to publish PR of Progress Events
09:10:18 [trackbot]
Created ACTION-702 - Start cfc to publish pr of progress events [on Arthur Barstow - due 2013-11-18].
09:10:57 [Travis_]
jungkees: We _could_ add more examples to the spec from other use-cases.
09:11:09 [Travis_]
... if not required I'd prefer not to.
09:11:16 [ijongche_]
ijongche_ has joined #webapps
09:11:23 [abarsto]
ACTION: barstow work with AvK and Jungkee re the Attribution of the Progress Events spec
09:11:23 [trackbot]
Created ACTION-703 - Work with avk and jungkee re the attribution of the progress events spec [on Arthur Barstow - due 2013-11-18].
09:11:50 [nsakai2]
nsakai2 has joined #webapps
09:11:51 [israelh]
israelh has joined #webapps
09:12:13 [richt]
richt has joined #webapps
09:12:44 [birtles]
birtles has joined #webapps
09:12:47 [Travis_]
Topic: WebIDL
09:12:47 [dong]
dong has joined #webapps
09:13:19 [richt]
richt has joined #webapps
09:13:25 [Travis_]
heycam`: Test suite progress?
09:13:26 [krit]
krit has joined #webapps
09:13:59 [Travis_]
... I started working on tests for webidl v1. These have been reviewed.
09:14:12 [Travis_]
... I now need to revise tests that have issues.
09:14:45 [Travis_]
... I thought I did a fairly complete job, but it would be good to hear from the people who did the reviews.
09:15:10 [Travis_]
abarsto: 5 reviewers did 20%.
09:15:46 [richt]
richt has joined #webapps
09:16:06 [Travis_]
abarsto: what are we going to consider implementations?
09:16:13 [denis]
denis has joined #webapps
09:16:27 [ijongcheol]
ijongcheol has joined #webapps
09:17:05 [Toshiya_]
Toshiya_ has joined #webapps
09:17:30 [Travis_]
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.
09:18:57 [Travis_]
heycam`: The tests use features that are available in other specs.
09:19:24 [abarsto]
q+ Is Dom's webidl checker considered an implementation re CR exit criteria?
09:20:10 [Travis_]
jonas: two things I know that are programmatic.
09:20:14 [AndroUser2]
AndroUser2 has joined #webapps
09:20:18 [Travis_]
... arrays - people wonder what this means.
09:20:40 [Travis_]
heycam`: generally, people are not happy with array-ness.
09:21:44 [Travis_]
... one test used messageport arrayness, but managed to convince hixie to change it.
09:21:57 [denis_]
denis_ has joined #webapps
09:22:01 [Travis_]
jonas: my proposal was to just use JS arrays or frozen arrays.
09:22:03 [ijongcheol]
ijongcheol has joined #webapps
09:22:24 [Travis_]
... nodelist and other live-lists may just stay as host-objects.
09:22:38 [Travis_]
... we shouldn't add more ways of replicating those behaviors.
09:22:56 [Travis_]
... otherwise, we should just use iterable objects (ES6 syntax)
09:23:06 [annevk]
NodeList can still be an iterable
09:23:11 [nikos]
nikos has joined #webapps
09:23:21 [Travis_]
heycam`: to defend [] syntax: to handle nodelist-like objects.
09:23:34 [xiaoqian]
09:23:36 [Travis_]
... if we don't like that concept, than it doesn't make sense to allow/expose it.
09:24:13 [dong]
dong has joined #webapps
09:24:21 [richt_]
richt_ has joined #webapps
09:24:24 [Travis_]
heycam`: There's still a bunch of new things to align with ES6 features (iterables, proper classes)
09:24:39 [annevk]
For NodeList we can add @@iterator from ES6
09:25:19 [Travis_]
heycam`: At the Mozilla summit a few things were discussed: JS-IDL, what's left to finish.
09:25:34 [Travis_]
... for JSIDL - I don't really have the time to re-write for that.
09:25:39 [MikeSmith]
RRSAgent, make minutes
09:25:39 [RRSAgent]
I have made the request to generate MikeSmith
09:25:51 [Travis_]
... better use of my time to find/fix the major problems wrong with WebIDL.
09:25:57 [kinuko]
kinuko has joined #webapps
09:26:00 [Travis_]
... seven items were discussed
09:26:13 [Travis_]
... 1 - typearray, promises, etc., stuff that moves in ES6
09:26:33 [Travis_]
... 2 - no custom exception objects; building it in.
09:26:51 [MikeSmith]
i/jungkees: looking at XHR1/scribe: Travis/
09:26:53 [Travis_]
... 3 - proper ES classes, maybe replace interface with class
09:26:57 [MikeSmith]
RRSAgent, make minutes
09:26:57 [RRSAgent]
I have made the request to generate MikeSmith
09:27:11 [Travis_]
... 4 - deprecating indexed and named properties and stuff that required proxies.
09:27:18 [AndroUser2]
AndroUser2 has joined #webapps
09:27:25 [Travis_]
... 5 - fixing array-ness
09:27:31 [Travis_]
... and other stuff.
09:27:49 [Travis_]
... with some new focus time, I can get after these.
09:27:59 [Travis_]
chaals: done by Christmas.
09:28:20 [richt]
richt has joined #webapps
09:28:21 [Travis_]
... ?
09:28:30 [Travis_]
heycam`: Any other high-priority items to finish?
09:28:35 [dennisdmac]
dennisdmac has joined #webapps
09:29:05 [Travis_]
jonas; can we get rid of overloading?
09:29:19 [Travis_]
... with union types why do we need it?
09:29:33 [xiaoqian]
09:29:33 [Travis_]
... other than drawImage?
09:29:38 [ijongcheol]
ijongcheol has joined #webapps
09:29:44 [Travis_]
Alex: WebGL?
09:30:09 [MikeSmith]
i/We can identify the best and brightest tests/scribe: Travis_/
09:30:17 [MikeSmith]
RRSAgent, make minutes
09:30:17 [RRSAgent]
I have made the request to generate MikeSmith
09:30:29 [Travis_]
heycam`: overloading is the most complex part of the spec. It would be nice to remove it...
09:31:03 [Travis_]
abarsto: heycam` can you draft up a message on what's next?
09:31:11 [mounir_]
mounir_ has joined #webapps
09:31:12 [richt_]
richt_ has joined #webapps
09:31:26 [Travis_]
heycam`: need to update the list of "what's new" to aggregate into the history of the spec.
09:31:50 [adrianba]
WebSocket API uses overloading for send()
09:32:00 [Travis_]
... Do we want to hold up v1 of the spec on some of the larger issues?
09:33:58 [Travis_]
Travis: I don't want to implement stuff that's going to change.
09:34:17 [Travis_]
heycam`: If you stick to the spec + bugs + list of things I mentioned, you should be safe.
09:34:58 [abarsto]
RRSAgent, make minutes
09:34:58 [RRSAgent]
I have made the request to generate abarsto
09:35:10 [richt]
richt has joined #webapps
09:35:37 [abarsto]
Present+ Dirk_Schulze, Rik_Cabanier
09:35:43 [hoyang1]
hoyang1 has joined #webapps
09:35:49 [cwdoh]
cwdoh has joined #webapps
09:35:52 [bryan]
bryan has joined #webapps
09:36:00 [hoyang1]
hoyang1 has joined #webapps
09:36:33 [chaals]
scribeNick: chaals
09:36:36 [chaals]
Scribe+ chaals
09:36:47 [hoyang2]
hoyang2 has joined #webapps
09:36:54 [cabanier]
cabanier has joined #webapps
09:36:59 [chaals]
Topic: Readonly/ writeable interfaces
09:37:18 [chaals]
DS: We have interfaces for SVG / CSS DOM - there is readonly and writeable versions.
09:37:40 [chaals]
… readonly has no setters, attributes are readonly. Writeable have setters, and attributes are not readonly
09:38:14 [chaals]
DS: Can't do that in WebIDL. Had a short discussion on the issue. 2 possibilities; inherited structure, or have 2 interfaces.
09:38:33 [chaals]
… for nihersited structure, the writeable version would inherit from the readonly version.
09:38:57 [chaals]
Travis: Do you need the interfaceto swap between readonly/writeable, or is a given object always going to be one or the other?
09:38:59 [cwdoh]
cwdoh has joined #webapps
09:39:05 [chaals]
… We had objects that changes in IE
09:39:18 [chaals]
DS: The interface doesn't change between readonly / writeable.
09:39:31 [ijongcheol]
ijongcheol has joined #webapps
09:39:58 [krit]
09:39:59 [kinuko]
kinuko has joined #webapps
09:40:17 [chaals]
JG: Readonly is not user-modifiable, but the values may be changed?
09:40:20 [chaals]
DS: Correct.
09:40:50 [chaals]
DS: DOMRect is writeable, DOMrectReadonly isn't, so writeable inherits from it.
09:41:05 [chaals]
… which means that things inherited do weird stuff @@
09:41:26 [chaals]
… solution could be to rename rDOMRectReadonly so people don't think it is always readonly.
09:41:36 [xiaoqian]
q+ heycam`
09:41:51 [chaals]
… other solution is use typedef and different interfaces and specify if you have a readonly or writeable version
09:42:07 [xiaoqian]
q- heycam`
09:42:08 [chaals]
Cam: renaming sounds sensible, compared to duplicating interfaces
09:42:19 [cwdoh_]
cwdoh_ has joined #webapps
09:42:22 [chaals]
JG: View has another meaning - arrayBufferView is writeable.
09:42:31 [chaals]
…bad choice of colours
09:42:53 [chaals]
DS: The iidea of calling it that was so people wouldn't get bad ideas.
09:43:00 [chaals]
JG: but confusing is bad.
09:43:09 [chaals]
DS: Right. Whey we are discussing.
09:43:46 [chaals]
AvK: Instanceof doesn't work with cross-@@ and isn't good practice accoring to JS spec editor.
09:43:59 [chaals]
Dino: It's all good.
09:44:28 [chaals]
Travis: Can you give some use cases for DOMRect for context?
09:44:30 [taocai]
taocai has left #webapps
09:44:31 [kinuko1]
kinuko1 has joined #webapps
09:44:39 [chaals]
DS: SVG DOM is a bit complicated.
09:44:42 [myakura]
MikeSmith, there was nobody in the room who could talk about current state of Stream proposals. so we moved on to XHR/PE
09:44:44 [krit]
09:44:47 [btoews]
btoews has joined #webapps
09:44:49 [krit]
var e
09:45:01 [chaals]
… you have different attributes. a rect in SVG is one element, you can test its attributes.
09:45:04 [krit]
09:45:12 [chaals]
… e.g. the x property.
09:45:13 [krit]
e.x.animVal baseVal
09:45:46 [chaals]
… these are different kinds of objects. BaseVal stay set, animVal includes current value under current animation.
09:45:56 [chaals]
… other examples in CSS Object model
09:46:05 [chaals]
Cam: Also clientRect….
09:46:22 [chaals]
… maybe not a great example, could return a plain object.
09:46:31 [chaals]
DS: Think that was the use case I was thinking of.
09:47:04 [chaals]
Cam: Want to avoid a proliferation of rectangle objects. We have SVG rectangles, clientRect, and maybe more APIs that want rectangles.
09:47:19 [chaals]
… would be goo to have a single (or dual) rectangle interface.
09:47:25 [chaals]
Travis: How does SVG do it today?
09:47:38 [chaals]
Cam: With a single interface and a flag to say if it is readonly or not.
09:48:10 [chaals]
… it's writeable in the intereface and setting it when the reaonly flag is set will throw.
09:48:51 [chaals]
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 writeable.
09:49:21 [chaals]
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.
09:49:32 [chaals]
… Not hugely pretty, but would allow people to check @@@
09:49:59 [chaals]
DS: Would not share anything with the inherited classes. Also, there are multiple interfaces like this in SVG.
09:50:13 [chaals]
… that are currently incompatible with WebIDL.
09:50:16 [richt]
richt has joined #webapps
09:50:29 [chaals]
Cam: Not that you cannot express this in the SVG spec, can add process. But people don't love it.
09:50:41 [chaals]
DS: People objected and said it is not possible… but is implementable.
09:50:43 [richt_]
richt_ has joined #webapps
09:51:10 [chaals]
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.
09:51:43 [chaals]
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.
09:52:01 [chaals]
DS: So we need to define a getter separately for the defined class?
09:52:13 [kinuko1]
kinuko1 has joined #webapps
09:52:15 [chaals]
JS: 2 qusestions. What do we write in WebIDL, what can you do in Javascript?
09:52:28 [chaals]
… in JS you need a property on the derived intereface with a getter and a setter
09:52:31 [nkic]
nkic has joined #webapps
09:52:47 [chaals]
Cam: Not a huge burden. But WebIDL has a features where you an avoid having the extra getter.
09:52:57 [chaals]
DS: So, should we continue with the inherited part?
09:53:07 [chaals]
… and whatcolour should we paint it?
09:53:17 [chaals]
… not "readonly", "not View"...
09:53:35 [chaals]
[we drop the naming issue]
09:53:59 [chaals]
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.
09:54:06 [chaals]
… so yes. Use it.
09:54:34 [chaals]
DS: Thought the question is whether to have a heirarchy of DOMRect, not just for getters specifically.
09:54:42 [chaals]
09:54:47 [chaals]
Cam: Seems sensible
09:54:56 [chaals]
AvK: Is clientRect live?
09:54:57 [chaals]
09:55:16 [chaals]
AvK: So they seem two different things. If one is live and another not, they are not so related.
09:55:33 [chaals]
DS: The ability to make something live doesn't force it to be live, so I don't think there is a real difference.
09:55:42 [richt__]
richt__ has joined #webapps
09:56:00 [chaals]
AvK: For static object you don't need to use getters, because you're not returning internal state. That would be much more sane.
09:56:10 [chaals]
DS: DOMRect only has values...@@@@
09:56:25 [slightlyoff]
annevk: just "property"
09:56:29 [chaals]
AvK: You can define objects in two ways - getter/setter or (not)
09:56:39 [chaals]
… That alternative might be better.
09:56:39 [lmcliste_]
lmcliste_ has joined #webapps
09:56:43 [xiaoqian]
s/[we drop the naming issue]/Let's not name it now./
09:56:43 [annevk]
slightlyoff: k
09:56:46 [ijongcheol]
ijongcheol has joined #webapps
09:57:02 [chaals]
Travis: Starting to sound like arrayness problems for WebIDL - arrays that are sometimes static, or maybe not...
09:57:04 [annevk]
slightlyoff: so how do you distinguish that from a getter/setter property?
09:57:17 [slightlyoff]
09:57:29 [chaals]
… 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 not?
09:57:32 [chaals]
… if it works...
09:57:43 [chaals]
Cam: But we want to get rid of arrays with internal flags too.
09:58:11 [edoyle]
edoyle has joined #webapps
09:58:12 [chaals]
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.
09:58:18 [chaals]
Cam: Think we do.
09:58:34 [chaals]
DS: I have no problem with it, but there were objections from e.g. Webapps
09:58:49 [chaals]
JS: Wasthere objection to a subclass that is writeable?
09:58:51 [chaals]
DS: No
09:59:00 [chaals]
JS: So we could move forward on that
09:59:03 [chaals]
Travis: WfM
09:59:16 [chaals]
AvK: If we don't need getters, we should avoid using them.
09:59:22 [chaals]
… have a data property instead.
09:59:24 [richt]
richt has joined #webapps
09:59:30 [chaals]
DS: Don't have dictionaries
09:59:34 [chaals]
AvK: Doesn't matter
09:59:41 [chaals]
Cam: That would be the WebIDL way to do this.
10:00:06 [chaals]
… If we make a @@@@@ for an unchanging object, you can use the dictionary version to get.
10:00:17 [chaals]
… We don't want to have a new version changing values all the time.
10:00:29 [xiaoqian]
ack slightlyoff
10:01:02 [chaals]
Alex: By default WebIDL uses getters/setters, whereas javascript uses properties. Seems Anne was saying start with the obvious thing from ajvascript.
10:01:30 [chaals]
… not clear that the base class and then setting a flag to force readonly, is a good way. Not natural in Javascript.
10:01:43 [xiaoqian]
10:01:50 [chaals]
… Concerned that there is a performance argument I would like to understand
10:02:19 [johnny]
johnny has joined #webapps
10:02:20 [Lachy]
Lachy has joined #webapps
10:02:33 [chaals]
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.
10:02:58 [chaals]
… for that you have tohave an accessor. DOM attributes are that way, but makes sense that the workd is oriented to getters/setters.
10:03:10 [Daniel_Austin]
+1 readonly descends from readable/writeable
10:03:16 [chaals]
AR: But the single point of truth being the object seems like a broken assumption
10:03:34 [chaals]
JS: Problem is talking about a wide range of objects - lots of different behaviours.
10:03:36 [mizuman]
mizuman has joined #webapps
10:03:42 [slightlyoff]
s/the object/something behind the object/
10:03:52 [chaals]
… many objects returning would not make sense with data properties.
10:04:12 [chaals]
… seems in many cases but not all getters make sense. Maybe not as often as we use them.
10:04:37 [chaals]
… Exception objects are one of the few objects with properties, and had getters. That'sthe pattern, but people don't use them much.
10:04:59 [chaals]
… If we can return dictionary objects, inertia is why we keep using interfaces everywhere.
10:05:31 [chaals]
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.
10:05:40 [chaals]
… Makes sense to use a data property...
10:06:22 [chaals]
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.
10:06:48 [chaals]
Cam: If functions that implement getters/setters have access to other properties...
10:06:53 [chaals]
Alex: What are they?
10:07:00 [dsinger]
dsinger has joined #webapps
10:07:02 [chaals]
Cam, Alex: @@@
10:07:04 [cabanier]
cabanier has joined #webapps
10:07:19 [chaals]
[scribe missed this]
10:07:56 [chaals]
Ryo: You can do something as if ther is a private state and getters/setters use that.
10:08:00 [johnny_]
johnny_ has joined #webapps
10:08:10 [chaals]
… so they aren't all that rettible. So there are elements where it makes sense.
10:08:36 [chaals]
Alex: Sure. But to implement a class for this I would only have getters/setters as an exceptional process.
10:08:43 [chaals]
… would support @@@@@@@
10:09:05 [slightlyoff]
...adding properties to itnerfaces in WebIDL
10:09:12 [chaals]
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.
10:09:27 [shan]
shan has joined #webapps
10:09:28 [chaals]
… depends on the APIs you are talking about which makes more sense.
10:09:46 [richt_]
richt_ has joined #webapps
10:10:27 [chaals]
[should we keep going...?]
10:11:14 [chaals]
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.
10:11:34 [chaals]
… Don't know for the specific case of Rectangles.
10:12:05 [chaals]
Cam: Think the proposal was to have both the dictionary and the data properties.
10:12:15 [chaals]
[scribe may have recorded that backwards]
10:12:43 [kurosawa_]
kurosawa_ has joined #webapps
10:12:44 [heycam`]
both the dictionary and the interfaces
10:12:54 [xiaoqian]
RRSAgent, make minutes
10:12:54 [RRSAgent]
I have made the request to generate xiaoqian
10:13:23 [tobie]
tobie has joined #webapps
10:13:27 [mete]
mete has left #webapps
10:13:40 [chaals]
10:13:56 [aboyet]
aboyet has left #webapps
10:14:02 [Toshiya]
Toshiya has joined #webapps
10:14:23 [mizuman]
mizuman has joined #webapps
10:14:33 [saki]
saki has joined #webapps
10:16:28 [AndroUser2]
AndroUser2 has joined #webapps
10:16:44 [ken]
ken has joined #webapps
10:17:46 [glenn]
glenn has joined #webapps
10:20:57 [AndroUser2]
AndroUser2 has joined #webapps
10:22:35 [richt]
richt has joined #webapps
10:23:10 [richt_]
richt_ has joined #webapps
10:29:06 [richt__]
richt__ has joined #webapps
10:30:04 [dka]
dka has joined #webapps
10:31:37 [glenn]
glenn has joined #webapps
10:44:21 [darobin]
darobin has joined #webapps
11:24:59 [mizuman]
mizuman has joined #webapps
11:27:16 [ken]
ken has joined #webapps
11:30:03 [myakura]
myakura has joined #webapps
11:34:11 [skddc]
skddc has joined #webapps
11:37:43 [skddc_]
skddc_ has joined #webapps
11:40:37 [AndroUser2]
AndroUser2 has joined #webapps
11:49:48 [AndroUser2]
AndroUser2 has joined #webapps
12:03:16 [johnny]
johnny has joined #webapps
12:17:24 [marcosc]
marcosc has joined #webapps
12:32:31 [Zakim]
Zakim has left #webapps
12:33:56 [smaug]
smaug has joined #webapps
13:00:32 [marcosc]
marcosc has joined #webapps
13:14:28 [hoyang]
hoyang has joined #webapps
13:15:55 [smaug]
smaug has joined #webapps
13:16:25 [Toshiya]
Toshiya has joined #webapps
13:17:14 [hoyang]
hoyang has joined #webapps
13:31:15 [marcosc]
marcosc has joined #webapps
13:48:52 [smaug]
smaug has joined #webapps
13:51:44 [cwdoh]
cwdoh has joined #webapps
13:59:51 [marcosc]
marcosc has joined #webapps
14:04:05 [davidb]
davidb has joined #webapps
14:04:27 [stakagi]
stakagi has joined #webapps
14:04:33 [hoyang]
hoyang has joined #webapps
14:17:28 [karl]
karl has joined #webapps
14:19:57 [cwdoh]
cwdoh has joined #webapps
14:20:49 [ijongcheol]
ijongcheol has joined #webapps
14:28:20 [cwdoh_]
cwdoh_ has joined #webapps
14:29:21 [denis]
denis has joined #webapps
14:33:00 [marcosc]
marcosc has joined #webapps
14:37:28 [rniwa]
rniwa has joined #webapps
14:42:36 [cwdoh]
cwdoh has joined #webapps
14:47:38 [lgombos_]
lgombos_ has joined #webapps
14:53:52 [Toshiya]
Toshiya has joined #webapps
14:56:27 [ken]
ken has joined #webapps
15:14:50 [ken]
ken has joined #webapps
15:29:42 [fjh]
fjh has joined #webapps
15:48:53 [dsinger]
dsinger has joined #webapps
15:53:49 [cwdoh]
cwdoh has joined #webapps
16:03:48 [karl]
karl has joined #webapps
16:14:22 [myakura]
myakura has joined #webapps
16:27:19 [karl]
karl has joined #webapps
16:30:36 [lmcliste_]
lmcliste_ has joined #webapps
16:42:16 [jsbell]
jsbell has joined #webapps
16:47:08 [smaug]
smaug has joined #webapps
17:12:04 [lmcliste_]
lmcliste_ has joined #webapps
17:33:24 [jcraig]
jcraig has joined #webapps
18:15:23 [fjh]
fjh has joined #webapps
18:35:19 [Lachy]
Lachy has joined #webapps
18:50:07 [lgombos]
lgombos has joined #webapps
19:09:25 [myakura]
myakura has joined #webapps
19:32:55 [lgombos]
lgombos has joined #webapps
19:39:44 [davidb]
davidb has joined #webapps
19:45:26 [jcraig]
jcraig has joined #webapps
19:59:28 [glenn_]
glenn_ has joined #webapps
20:13:56 [ken]
ken has joined #webapps
20:14:02 [myakura]
myakura has joined #webapps
20:36:08 [lgombos_]
lgombos_ has joined #webapps
20:52:00 [lgombos]
lgombos has joined #webapps
21:14:26 [myakura]
myakura has joined #webapps
21:42:04 [ken]
ken has joined #webapps
22:11:00 [edoyle]
edoyle has joined #webapps
22:14:51 [myakura]
myakura has joined #webapps
22:23:26 [fjh]
fjh has joined #webapps
22:24:35 [ken]
ken has joined #webapps
22:36:19 [myakura]
myakura has joined #webapps
22:57:30 [marcosc]
marcosc has joined #webapps
23:08:08 [lgombos]
lgombos has joined #webapps
23:42:34 [marcosc]
marcosc has joined #webapps
23:44:49 [lgombos_]
lgombos_ has joined #webapps
23:49:54 [darobin]
darobin has joined #webapps
23:56:01 [johnny]
johnny has joined #webapps
00:06:39 [glenn]
glenn has joined #webapps
00:11:47 [myakura]
myakura has joined #webapps
00:11:50 [johnny_]
johnny_ has joined #webapps
00:12:56 [darobin]
darobin has joined #webapps
00:15:27 [yang]
yang has joined #webapps
00:18:44 [kennyluck]
kennyluck has joined #webapps
00:21:28 [masatakayakura]
masatakayakura has joined #webapps
00:22:46 [marcosc]
marcosc has joined #webapps
00:25:37 [darobin]
darobin has joined #webapps
00:28:16 [glenn]
glenn has joined #webapps
00:33:59 [Lachy]
Lachy has joined #webapps
00:35:12 [sgalineau]
sgalineau has joined #webapps
00:35:21 [cwdoh]
cwdoh has joined #webapps
00:36:35 [glenn_]
glenn_ has joined #webapps
00:38:28 [tao]
tao has joined #webapps
00:41:19 [cwdoh]
cwdoh has joined #webapps
00:42:29 [tcai]
tcai has joined #webapps
00:42:46 [Takahiro_]
Takahiro_ has joined #webapps
00:42:50 [Marcus_Altman___]
Marcus_Altman___ has joined #webapps
00:43:47 [glenn]
glenn has joined #webapps
00:44:48 [Arno]
Arno has joined #webapps
00:45:22 [nkic]
nkic has joined #webapps
00:47:14 [abarsto]
abarsto has joined #webapps
00:48:42 [Lachy]
Lachy has joined #webapps
00:49:40 [dsinger]
dsinger has joined #webapps
00:52:27 [mete]
mete has joined #webapps
00:52:39 [dom]
dom has joined #webapps
00:53:01 [dsinger_]
dsinger_ has joined #webapps
00:55:18 [johnny]
johnny has joined #webapps
00:55:37 [dsinger_]
dsinger_ has left #webapps
00:55:42 [ArtB]
RRSAgent, bye
00:55:42 [RRSAgent]
I see 4 open action items saved in :
00:55:42 [RRSAgent]
ACTION: dimitri reply to Ryosuke's comments re Custom Element as part of LC comments [1]
00:55:42 [RRSAgent]
recorded in
00:55:42 [RRSAgent]
ACTION: barstow start a CfC to publish LCWD of DOM Parsing and Serialization [2]
00:55:42 [RRSAgent]
recorded in
00:55:42 [RRSAgent]
ACTION: barstow start CfC to publish PR of Progress Events [3]
00:55:42 [RRSAgent]
recorded in
00:55:42 [RRSAgent]
ACTION: barstow work with AvK and Jungkee re the Attribution of the Progress Events spec [4]
00:55:42 [RRSAgent]
recorded in