/irc-logs / w3c / #webapps / 2014-04-11 / end

Options:

1. # Session Start: Fri Apr 11 00:00:01 2014
2. # Session Ident: #webapps
3. # [00:00] <jsbell> Handy IndexedDB "v2" links:
4. # [00:00] <jsbell> http://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures
5. # [00:00] <jsbell> https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=RESOLVED&component=Indexed%20Database%20API&list_id=34841&product=WebAppsWG&query_format=advanced&resolution=LATER
6. # [00:06] * cwilso__ is now known as cwilso
7. # [00:06] <cwilso> zakim, choose a victim
8. # [00:06] <Zakim> Not knowing who is chairing or who scribed recently, I propose bryan
9. # [00:06] <cwilso> zakim, choose a victim
10. # [00:06] <Zakim> Not knowing who is chairing or who scribed recently, I propose bryan
11. # [00:06] * Quits: israelh (~israelh@public.cloak) ("Page closed")
12. # [00:06] * Yves debian-grade random
13. # [00:06] * Joins: lgombos (~lgombos@public.cloak)
14. # [00:06] * Joins: krisk (~krisk@public.cloak)
15. # [00:06] * darobin lol
16. # [00:06] * Joins: israelh (~israelh@public.cloak)
17. # [00:06] * Joins: jinsong (wjs@public.cloak)
18. # [00:06] <cwilso> scribenick: cwilso
19. # [00:07] <ArtB> http://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures -> IDB v.Next Features
20. # [00:07] <cwilso> jsbell: dropped links (above) on iDB v2
21. # [00:07] * Joins: alia (~alia@public.cloak)
22. # [00:07] <cwilso> ...not comprehensive, but between buglist and wiki, pretty good.
23. # [00:08] <cwilso> ...lots of ideas for things that will require more discussion - full text indexing, etc. We want to write these down in "iDBv2".
24. # [00:08] * Joins: genelian_ (~genelian@public.cloak)
25. # [00:08] <cwilso> (general agreement)
26. # [00:08] * Quits: nhiroki (~nhiroki@public.cloak) ("Page closed")
27. # [00:09] <cwilso> jsbell: volunteers as editor, looks for co-editor: ali raises hand
28. # [00:09] * Zakim cwilso, you typed too many words without commas; I suspect you forgot to start with 'to ...'
29. # [00:09] <cwilso> jsbell: if there's anything other features you want to see in there, please contribute.
30. # [00:09] <ArtB> q+
31. # [00:09] * Zakim sees ArtB on the speaker queue
32. # [00:10] <cwilso> art: this could be the first time we've start v2 work, so a couple of questions
33. # [00:10] * Quits: zqzhang (~zqzhang@public.cloak) (Ping timeout: 180 seconds)
34. # [00:10] <cwilso> ...1) should we issue a call for feature requests?
35. # [00:11] <cwilso> ...2) we have a relatively large list here, should we prioritize?
36. # [00:11] * Quits: bryan (~bryan@public.cloak) ("")
37. # [00:11] * Joins: zqzhang (~zqzhang@public.cloak)
38. # [00:11] <cwilso> ...3) in terms of the spec itself, do you intend to incorporate v1, or have a delta spec?
39. # [00:11] <cwilso> jsbell: I agree with your questions. On 3, I'd welcome feedback.
40. # [00:12] * Joins: sicking (~sicking@public.cloak)
41. # [00:12] <sicking> q+
42. # [00:12] * Zakim sees ArtB, sicking on the speaker queue
43. # [00:12] <mounir> ack ArtB
44. # [00:12] * Zakim sees sicking on the speaker queue
45. # [00:12] <cwilso> art: if we did a copy, we might be duplicating bugs that need to be fixed (in v1 and v2), but would like to hear if anyone has experience doing these.
46. # [00:12] <cwilso> s/these/deltas vs incorporating
47. # [00:12] <tantek> Zakim, what's the topic?
48. # [00:12] <Zakim> I don't understand your question, tantek.
49. # [00:13] <cwilso> topic: indexedDB v2
50. # [00:13] <cwilso> ade: how extensive is what needs to be done? If it's mostly additive, an extension spec would make sense.
51. # [00:13] <cwilso> jsbell: the v1 spec doesn't really specify extension hooks, unfortunately.
52. # [00:14] <cwilso> ade: that was my question: if it's changing algorithms...
53. # [00:14] <cwilso> jsbell: more like inserting steps [in extant algorithms].
54. # [00:15] <cwilso> jonas: from a spec-writing point of view, since we'd be inserting additional steps, that might be messy. We could try that way and back away if it's too messy.
55. # [00:15] <cwilso> art: all for letting jsbell and ali experiment.
56. # [00:15] <xiaoqian> ack sicking
57. # [00:15] * Zakim sees no one on the speaker queue
58. # [00:15] <cwilso> (general agreement)
59. # [00:16] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
60. # [00:16] <cwilso> sicking: when it comes to features, I'd like to see us add features when multiple people agree on the feature.
61. # [00:16] <cwilso> marcos: is there a feature list? (yes)
62. # [00:16] <cwilso> jsbell: art is proposing we broadcast that we're starting on the list, ask for prioritization and other features.
63. # [00:16] <cwilso> art: yes.
64. # [00:17] <cwilso> action: jsbell to broadcast to the list with alia that we're starting on iDB2, ask for prioritization and feature suggestions.
65. # [00:17] * RRSAgent records action 11
66. # [00:17] * @trackbot is creating a new ACTION.
67. # [00:17] <@trackbot> Created ACTION-724 - Broadcast to the list with alia that we're starting on idb2, ask for prioritization and feature suggestions. [on Joshua Bell - due 2014-04-17].
68. # [00:18] <cwilso> israelh: what about Promise compatibility?
69. # [00:19] <cwilso> jsbell: current model is pretty tied to event model. It may be fairly extensive changes, although there is the desire to do it. We don't have an answer yet.
70. # [00:20] * Joins: jcraig (~jcraig@public.cloak)
71. # [00:20] <cwilso> israelh: we've talked about iDB as the API to be used for caching (e.g. offline). Have you seen adoption of this pattern? The Outlook Web Access uses ??? to cache. Have you seen similar patterns?
72. # [00:20] <cwilso> jsbell: Google Docs uses it to cache for offline and editing.
73. # [00:21] <cwilso> marcos: met with a team who had problems because they couldn't batch the way they wanted to, so it was too slow.
74. # [00:21] <cwilso> jsbell: jonas and I were having a conversation about this before - promises might naively push people into this .then().then().then() pattern...
75. # [00:22] <cwilso> ...but promises.all would enable this. We should have this on the list - batching.
76. # [00:22] <cwilso> action on jsbell to add batching to the wiki list.
77. # [00:22] * @trackbot is creating a new ACTION.
78. # [00:22] <@trackbot> Error finding 'on'. You can review and register nicknames at <http://www.w3.org/2008/webapps/track/users>.
79. # [00:22] <cwilso> action jsbell to add batching to the wiki list.
80. # [00:22] * @trackbot is creating a new ACTION.
81. # [00:22] <@trackbot> Created ACTION-725 - Add batching to the wiki list. [on Joshua Bell - due 2014-04-17].
82. # [00:23] <cwilso> israelh: when we set out to do indexeddb, we expected that libraries would be built on top of idb primitives as abstractions. Curious if that's happened.
83. # [00:24] <cwilso> jsbell: should have a good answer to this, but don't right now. No one super-successful library that I know of.
84. # [00:24] <cwilso> sicking: WRT the main things we've seen requests for: getting change notifications, mostly small things like opening a key cursor on an object store and performance.
85. # [00:25] <cwilso> s/change/update
86. # [00:25] <cwilso> jsbell: also, the fact that clear browsing data wipes iDB has forced some other notifications we've done, want to get those documented.
87. # [00:26] <cwilso> israelh: one more last question: how are you thinking about max limits?
88. # [00:27] <cwilso> sicking: what matters is the usage, we don't want to limit rows per store, but we do need to limit total store size, cache size,.... unified quota.
89. # [00:27] * Joins: opoto (~opoto@public.cloak)
90. # [00:27] <cwilso> slightlyoff: would like to see an API that lets us see how much quota you're "paying" for.
91. # [00:28] <cwilso> jsbell: should be able to prioritize frequently visited sites, etc., too.
92. # [00:28] <mounir> https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html -> Screen Orientation API
93. # [00:28] <cwilso> topic: screen orientation
94. # [00:29] <mounir> https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=Screen%20Orientation&list_id=34844&product=WebAppsWG -> open bugs for screen orientation
95. # [00:29] <ArtB> http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0038.html -> Mounir's Screen Orientation status
96. # [00:29] <cwilso> mounir: last week I updated the specs to reflect requests (e.g. from Mozilla)
97. # [00:30] <cwilso> mounir: if you have any questions or implementation feedback, please speak up
98. # [00:30] <cwilso> sicking: test suite?
99. # [00:30] <cwilso> marcos: I'm working on that.
100. # [00:30] <cwilso> sicking: I'd be excited to remove our prefix.
101. # [00:31] <cwilso> israelh: I think we're in the same boat as Mozilla WRT locking.
102. # [00:31] <cwilso> mounir: now you can lock to any of four angles; not arbitrary angle.
103. # [00:32] <cwilso> sicking: other feedback I don't feel quite as strongly about: some websites assume angle=0 means portrait. On many tablets, zero is actually landscape; so implementation may force you to hold device in the wrong angle.
104. # [00:32] <mounir> s/any of four angles/any of four types/
105. # [00:32] * cwilso thx
106. # [00:33] <tantek> q+ to respond to sicking's example
107. # [00:33] * Zakim sees tantek on the speaker queue
108. # [00:33] * Joins: KenjiBX (~KenjiBX@public.cloak)
109. # [00:33] <cwilso> sicking: my understanding is the use case for the angle is to add that to device orientation events, so you get an orientation relative to the device not the screen (?)
110. # [00:34] <cwilso> mounir: not sure how to respond to that feedback.
111. # [00:34] <cwilso> sicking: don't call it orientation, call it something else
112. # [00:34] <cwilso> sicking: but don't break back compat.
113. # [00:34] <ArtB> RRSAgent, make minutes
114. # [00:34] <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/10-webapps-minutes.html ArtB
115. # [00:35] <cwilso> marcos: I believe this is possible
116. # [00:35] <cwilso> mounir: <expresses skepticism at the size of the necessary monkeypatch> :)
117. # [00:35] * cwilso notes there's a queue
118. # [00:36] <cwilso> tantek: what's the use case driving this feedback?
119. # [00:36] <adrianba> q?
120. # [00:36] * Zakim sees tantek on the speaker queue
121. # [00:37] <cwilso> mounir: I get many small use cases for angle: only real strong use case was device orientation will give you angle to the screen, but if your screen is in a different mode "up" means something else. (?)
122. # [00:37] <cwilso> tantek: if so, expose the lock state.
123. # [00:37] <cwilso> mounir: no, you want to expose the angle the screen's currently on
124. # [00:40] <cwilso> sicking: the use case here is if you have a racing game where you tilt the screen; if the screen is unlocked, if the user holds the device one way you'll get orientation events one way you get events in the range 85-95, flipped the other way 265-275
125. # [00:40] <cwilso> sicking: now that it's been shipping for a few years we can't change it.
126. # [00:40] <cwilso> mounir: do we expose an angle that lets developers correct for it, or do we expose a new set of events that works the right way?
127. # [00:40] <cwilso> mounir: maybe we should do both.
128. # [00:40] <cwilso> ...in case there's something else they want to do with the angle.
129. # [00:41] <cwilso> sicking: except people will do silly things with it.
130. # [00:41] <cwilso> mounir: you're concerned people will read angle instead of type
131. # [00:41] <cwilso> ...? they do that today because they don't have an option.
132. # [00:41] <cwilso> sicking: I don't share your optimism.
133. # [00:41] * Yves footbazookas ftw!
134. # [00:42] <cwilso> sicking: we should definitely give enough rope for people to hang themselves, unless we're only giving them the rope in order TO hang themselves.
135. # [00:43] <cwilso> sicking: unless we have a strong use case, we should just do both events and figure people who would need this use case can subtract angles.
136. # [00:43] <mounir> q+
137. # [00:43] * Zakim sees tantek, mounir on the speaker queue
138. # [00:43] <mounir> q- tantek
139. # [00:43] * Zakim sees mounir on the speaker queue
140. # [00:43] <sicking> q-
141. # [00:43] * Zakim sees mounir on the speaker queue
142. # [00:43] <cwilso> israelh: seems like people would want to see the native orientation of the screen.
143. # [00:43] <cwilso> mounir: you can get this from type and angle.
144. # [00:44] <cwilso> mounir: not sure what the purpose is; this is pretty easy to determine.
145. # [00:45] <cwilso> israelh: just seems like most APIs that do this expose the native orientation.
146. # [00:45] <cwilso> marcos: cheap and easy! Instant win!
147. # [00:46] <cwilso> mounir: it's ONE LINE, dude!
148. # [00:46] * cwilso notes he's now editorializing. This is why you don't have me minute. :)
149. # [00:46] <cwilso> sicking: it's not even a new event, it's one property. It's wafer-thin.
150. # [00:46] <ArtB> q?
151. # [00:46] * Zakim sees mounir on the speaker queue
152. # [00:46] <ArtB> ack mounir
153. # [00:46] * Zakim sees no one on the speaker queue
154. # [00:47] <mounir> q+
155. # [00:47] * Zakim sees mounir on the speaker queue
156. # [00:47] <cwilso> mounir: <you have failed to beat me into submission yet>
157. # [00:47] <cwilso> sicking: it should be easier to do the right thing.
158. # [00:47] <cwilso> mounir: I would prefer if we consider these issues as orthogonal.
159. # [00:48] * Yves orthogonal issues yes, but which issue is up?
160. # [00:48] <mounir> q?
161. # [00:48] * Zakim sees mounir on the speaker queue
162. # [00:48] * Quits: dsr (dsr@public.cloak) ("be seeing you")
163. # [00:49] <mounir> ack mounir
164. # [00:49] * Zakim sees no one on the speaker queue
165. # [00:49] <cwilso> mounir: most systems can't tell what the default orientation is, particularly when locked. that's why I shied away from exposing here.
166. # [00:50] <cwilso> art: were there other points to raise, other questions? Only other thing I had was a message from Lars...
167. # [00:50] <ArtB> http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0057.html -> Lars
168. # [00:50] <cwilso> art: someone from the group should reply to Lars. Marcos, did you agree to reply?
169. # [00:50] <cwilso> marcos: I think I told him before the core IG would take that up, because I think that is quite vital.
170. # [00:51] <cwilso> action: marcos to reply to Lars
171. # [00:51] * RRSAgent records action 12
172. # [00:51] * @trackbot is creating a new ACTION.
173. # [00:51] <@trackbot> Created ACTION-726 - Reply to lars [on Marcos Caceres - due 2014-04-17].
174. # [00:51] * Quits: skddc (~anonymous@public.cloak) (Ping timeout: 180 seconds)
175. # [00:52] <cwilso> art: I think we're done with this topic, then.
176. # [00:52] <cwilso> topic: web workers v2
177. # [00:52] <hober> Hixie: ^^
178. # [00:54] <ArtB> http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0442.html -> Discusion on p-webapps
179. # [00:54] <adrianba> q+
180. # [00:54] * Zakim sees adrianba on the speaker queue
181. # [00:54] <cwilso> art: there was some discussion in Shenzhen about WWv2; Travis agreed to take up the action, but nothing much occurred.
182. # [00:55] <cwilso> art: don't know what the priority of this would be.
183. # [00:55] <cwilso> ack adrianba
184. # [00:55] * Zakim sees no one on the speaker queue
185. # [00:56] <cwilso> adrianba: I think the concern at SZ was that we were getting blocked on shared workers, so wanted to crack that out; but that seems to have unblocked.
186. # [00:56] <cwilso> sicking: we don't have event source at all; somewhat behind on shared workers
187. # [00:57] <smaug> s/at all/at all in workers/
188. # [00:57] <cwilso> art: what should we talk about? you guys wanted to add this.
189. # [00:57] <cwilso> sicking: interested in blob: situation, don't know if that needs v2 or just clarification.
190. # [00:58] <cwilso> sicking: interested in synchronous message passing for dedicated workers; don't need if that needs further discussion, since we are the only ones that have committed to implement.
191. # [00:58] <ArtB> https://www.w3.org/Bugs/Public/buglist.cgi?component=Web%20Workers%20%28editor%3A%20Ian%20Hickson%29&list_id=34849&product=WebAppsWG&;resolution=--- -> Web Workers bug
192. # [00:59] <cwilso> sicking: maybe it's too early to start a v2 at this point, just need to clarify the blob: url conversation.
193. # [00:59] <cwilso> art: sounds like we're done with this topic, then.
194. # [00:59] <cwilso> art: only other topic for today was administrative stuff:
195. # [01:00] <cwilso> robin: I volunteer to scribe tomorrow morning.
196. # [01:00] <cwilso> scribenick: mounir
197. # [01:01] * Quits: richt (~richt@public.cloak) (Client closed connection)
198. # [01:01] * Joins: richt (~richt@public.cloak)
199. # [01:01] <mounir> Topic: friday agenda
200. # [01:02] <mounir> ArtB: I don't think there is anything else than Web Components... anything else?
201. # [01:02] <mounir> (... silence...)
202. # [01:02] <mounir> ArtB: ok, lets do Web Components tomorrow
203. # [01:02] <mounir> Topic: Admin - copying specs
204. # [01:02] <mounir> marcos: there are a bunch of spec copying from another standards
205. # [01:02] <mounir> ... organization to this organization and they fall out of date
206. # [01:03] <mounir> ... anything people search for stuff they end up looking
207. # [01:03] <mounir> ... at the wrong specification
208. # [01:03] <mounir> ... the idea is to have "one spec to rule them all"
209. # [01:03] <mounir> ArtB: is it a webapp specific issue?
210. # [01:03] * Joins: jcraig_ (~jcraig@public.cloak)
211. # [01:03] <mounir> marcos: yes, because webapps in the worse offender
212. # [01:03] <mounir> ArtB: can we quantify that?
213. # [01:03] <mounir> marcos: I would like people to voice their concerns
214. # [01:03] <mounir> darobin: I agree it is a problem
215. # [01:04] <mounir> Yves: is it a problem because specs are no longer up to date?
216. # [01:04] <mounir> marcos: the spec on TR is from 2012 but was updated a lot
217. # [01:05] <mounir> ... since then and its hard to know if its up to date or not
218. # [01:05] <mounir> ... generally speaking
219. # [01:05] <mounir> ArtB: I agree that it's not really... there is a general problem
220. # [01:05] <mounir> ... we might want to have a rule that say that we should not
221. # [01:05] <mounir> ... do this anymore in webapps unless someone commit to
222. # [01:05] <mounir> ... keep it out of date
223. # [01:05] <mounir> tantek: it's a waste of time
224. # [01:06] <mounir> ArtB: maybe we could say in the header that we would never
225. # [01:06] <mounir> ... publish this thing ever again until the spec is updated?
226. # [01:06] <mounir> darobin: I agree it's probably the best we can do at the
227. # [01:06] <mounir> ... webapps level but we could do better at the w3c level
228. # [01:06] <mounir> ... if you are interested, feel free to contact me or tantek
229. # [01:07] <mounir> ... we are looking for input and suggestions
230. # [01:07] * Quits: jcraig (~jcraig@public.cloak) (Ping timeout: 180 seconds)
231. # [01:07] * jcraig_ is now known as jcraig
232. # [01:07] <mounir> tantek: marcos, we should list the different issues to find
233. # [01:07] <mounir> ... solutions because some might be easy and some hard
234. # [01:07] <mounir> ... for example, changing google search results
235. # [01:07] <mounir> marcos: we had issues with specs being rejected because they
236. # [01:07] <mounir> ... were referring whatwg specs
237. # [01:08] <mounir> tantek: I believe we work on that at a AB level
238. # [01:08] <mounir> ... for example, if there is a reference in mounir's spec
239. # [01:08] * Quits: richt (~richt@public.cloak) (Ping timeout: 180 seconds)
240. # [01:08] <mounir> ... to an old spec, we should fix that
241. # [01:09] <mounir> tantek: I think that we should not find an editor just for
242. # [01:09] <mounir> ... copying whatwg specs, it's a waste of time
243. # [01:09] <mounir> ArtB: I haven't said it's a good option, but that it is an option
244. # [01:09] <mounir> tantek: this said, it's worth noting that having WD
245. # [01:10] <mounir> ... helps with IP stuff so we might want that
246. # [01:10] <mounir> .. I don't know of any other steps?
247. # [01:10] <mounir> s/.. I/... I/
248. # [01:10] <mounir> Adrian: recommendation
249. # [01:10] <mounir> phl: it's actually when most of the IPR happens
250. # [01:10] <Zakim> -bryan
251. # [01:10] <mounir> ArtB: something we could do is having something in the spec
252. # [01:11] <mounir> ... saying "we are only publishing this for attorneys, if you
253. # [01:11] <mounir> ... are not an attorney, look at this instead"
254. # [01:11] <mounir> ... I'm not saying it's a good option but it's a solution
255. # [01:11] * Joins: richt (~richt@public.cloak)
256. # [01:12] <mounir> ryosuke: linking to the latest spec isn't always the right
257. # [01:12] <mounir> ... thing because sometimes you want to link to something
258. # [01:12] <mounir> ... that are also two years old
259. # [01:13] <mounir> marcos: as an editor, it's your responsibility to check
260. # [01:13] <mounir> ... for reference changes
261. # [01:13] <mounir> marcos: the entire points to version thing is not a good idea
262. # [01:14] <mounir> ArtB: any other comments about that particular topic?
263. # [01:14] <mounir> ArtB: any other admin stuff?
264. # [01:15] <Zakim> -Olli_Pettay
265. # [01:15] * Quits: zqzhang (~zqzhang@public.cloak) ("Page closed")
266. # [01:15] <mounir> ArtB: that will be it for today, thanks everyone
267. # [01:15] * Quits: arrrno (~arrrno@public.cloak) ("Page closed")
268. # [01:15] * Quits: adrianba (~adrianba@public.cloak) ("Page closed")
269. # [01:15] * Quits: aizu (~aizu@public.cloak) ("Page closed")
270. # [01:15] * Quits: jhazen (~jhazen@public.cloak) ("Page closed")
271. # [01:15] * Quits: jmajnert (~jmajnert@public.cloak) ("")
272. # [01:16] <ArtB> RRSAgent, make minutes
273. # [01:16] <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/10-webapps-minutes.html ArtB
274. # [01:16] <Zakim> -[Paypal]
275. # [01:16] <Zakim> IA_WebApps()12:00PM has ended
276. # [01:16] <Zakim> Attendees were [Paypal], Olli_Pettay, Bryan_Sullivan, arunranga, +1.425.264.aaaa, bryan, +1.650.946.aabb, Bin_Hu
277. # [01:17] * Quits: opoto (~opoto@public.cloak) ("http://www.kiwiirc.com/ - A hand crafted IRC client")
278. # [01:18] * Quits: israelh (~israelh@public.cloak) ("Page closed")
279. # [01:19] * Quits: plh (plehegar@public.cloak) ("Leaving")
280. # [01:19] * Quits: Ferasm (~Ferasm@public.cloak) (Ping timeout: 180 seconds)
281. # [01:19] * Quits: horo (~horo@public.cloak) (Ping timeout: 180 seconds)
282. # [01:20] * Quits: ArtB (~abarsto@public.cloak) ("Leaving.")
283. # [01:20] * Quits: jinsong (wjs@public.cloak) (Ping timeout: 180 seconds)
284. # [01:20] * Quits: richt (~richt@public.cloak) (Client closed connection)
285. # [01:20] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
286. # [01:21] * Joins: richt (~richt@public.cloak)
287. # [01:21] * Quits: genelian_ (~genelian@public.cloak) (Ping timeout: 180 seconds)
288. # [01:21] * Quits: xiaoqian (xiaoqian@public.cloak) (Ping timeout: 180 seconds)
289. # [01:21] * Quits: krisk (~krisk@public.cloak) (Ping timeout: 180 seconds)
290. # [01:22] * Quits: lmclister (~lmclister@public.cloak) ("")
291. # [01:22] * Quits: sicking (~sicking@public.cloak) (Ping timeout: 180 seconds)
292. # [01:22] * Quits: BenjamP (~BenjamP@public.cloak) (Ping timeout: 180 seconds)
293. # [01:22] * Quits: alia (~alia@public.cloak) (Ping timeout: 180 seconds)
294. # [01:23] * Quits: rniwa (~rniwa@public.cloak) (Ping timeout: 180 seconds)
295. # [01:23] * Quits: lgombos (~lgombos@public.cloak) (Ping timeout: 180 seconds)
296. # [01:23] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
297. # [01:28] * Quits: richt (~richt@public.cloak) (Ping timeout: 180 seconds)
298. # [01:41] * Parts: arunranga (~arunranga@public.cloak) (arunranga)
299. # [01:45] * Quits: chaals (~Adium@public.cloak) ("Leaving.")
300. # [01:49] * Quits: Bin_Hu (~Bin_Hu@public.cloak) ("Page closed")
301. # [01:57] * Quits: KenjiBX (~KenjiBX@public.cloak) (Ping timeout: 180 seconds)
302. # [02:00] * Joins: richt (~richt@public.cloak)
303. # [02:27] * Quits: hayato (~sid20728@public.cloak) (Client closed connection)
304. # [02:28] * Joins: hayato (~sid20728@public.cloak)
305. # [02:34] * Joins: lgombos (~gombos@public.cloak)
306. # [02:51] * Quits: lgombos (~gombos@public.cloak) (Client closed connection)
307. # [03:03] * Quits: smaug (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
308. # [03:08] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
309. # [03:10] * Quits: wonsuk (~uid27693@public.cloak) ("Connection closed for inactivity")
310. # [03:16] * Quits: jungkees (~uid24208@public.cloak) ("Connection closed for inactivity")
311. # [03:25] * Joins: jcraig (~jcraig@public.cloak)
312. # [03:46] * Joins: lmclister (~lmclister@public.cloak)
313. # [03:55] * Quits: lmclister (~lmclister@public.cloak) ("")
314. # [04:00] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
315. # [04:00] * Quits: richt (~richt@public.cloak) (Client closed connection)
316. # [04:00] * Joins: richt (~richt@public.cloak)
317. # [04:07] * Quits: richt (~richt@public.cloak) (Ping timeout: 180 seconds)
318. # [04:11] * Joins: jcraig (~jcraig@public.cloak)
319. # [04:28] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
320. # [04:56] * Joins: lmclister (~lmclister@public.cloak)
321. # [04:57] * Quits: lmclister (~lmclister@public.cloak) (lmclister)
322. # [04:57] * Joins: lmclister (~lmclister@public.cloak)
323. # [05:01] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
324. # [05:02] * Joins: lmclister (~lmclister@public.cloak)
325. # [05:08] * Joins: sicking (~sicking@public.cloak)
326. # [05:11] * Quits: lmclister (~lmclister@public.cloak) ("")
327. # [05:24] * Joins: lmclister (~lmclister@public.cloak)
328. # [05:27] * Joins: abarsto (~abarsto@public.cloak)
329. # [05:27] * abarsto is now known as ArtB
330. # [05:27] <ArtB> Agenda: https://www.w3.org/wiki/Webapps/April2014Meeting
331. # [05:28] <ArtB> RRSAgent, make minutes
332. # [05:28] <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/10-webapps-minutes.html ArtB
333. # [05:28] <ArtB> zakim, bye
334. # [05:28] * Parts: Zakim (zakim@public.cloak) (Zakim)
335. # [05:31] <ArtB> Scribe: Art, Philippe, KrisK, ChrisW, Robin, Adrian, Mounir
336. # [05:31] <ArtB> RRSAgent, make minutes
337. # [05:31] <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/10-webapps-minutes.html ArtB
338. # [05:40] * Quits: lmclister (~lmclister@public.cloak) ("")
339. # [05:46] <ArtB> rrsagent, bye
340. # [05:46] <RRSAgent> I see 12 open action items saved in http://www.w3.org/2014/04/10-webapps-actions.rdf :
341. # [05:47] <RRSAgent> ACTION: barstow update testing info in PubStatus for DOM P&S spec [1]
342. # [05:47] <RRSAgent> recorded in http://www.w3.org/2014/04/10-webapps-irc#T16-25-49
343. # [05:47] <RRSAgent> ACTION: Art to follow with Tantek and Anne on next steps for fullscreen [2]
344. # [05:47] <RRSAgent> recorded in http://www.w3.org/2014/04/10-webapps-irc#T16-36-03
345. # [05:47] <RRSAgent> ACTION: krisk push full screen api tests into github [3]
346. # [05:47] <RRSAgent> recorded in http://www.w3.org/2014/04/10-webapps-irc#T16-37-24
347. # [05:47] <RRSAgent> ACTION: Kris to look at tests for Fullscreen [4]
348. # [05:47] <RRSAgent> recorded in http://www.w3.org/2014/04/10-webapps-irc#T16-37-24-1
349. # [05:47] <RRSAgent> ACTION: tyoshino to look at the failures on Server-Sent Events [5]
350. # [05:47] <RRSAgent> recorded in http://www.w3.org/2014/04/10-webapps-irc#T16-55-04
351. # [05:47] <RRSAgent> ACTION: Art to change WebMessaging test facilitator to Kris [6]
352. # [05:47] <RRSAgent> recorded in http://www.w3.org/2014/04/10-webapps-irc#T17-14-17
353. # [05:47] <RRSAgent> ACTION: Kris to provide test results for Web Workers [7]
354. # [05:47] <RRSAgent> recorded in http://www.w3.org/2014/04/10-webapps-irc#T17-20-00
355. # [05:47] <RRSAgent> ACTION: Robin to start writing a high level explainer about the pieces that are needed to put together editing [8]
356. # [05:47] <RRSAgent> recorded in http://www.w3.org/2014/04/10-webapps-irc#T18-27-15
357. # [05:47] <RRSAgent> ACTION: barstow update WebApp's Draft charter to reflect Eric's File specs are moving to WG Notes [9]
358. # [05:47] <RRSAgent> recorded in http://www.w3.org/2014/04/10-webapps-irc#T18-46-56
359. # [05:47] <RRSAgent> ACTION: artb CFC for FPWD for service workers [10]
360. # [05:47] <RRSAgent> recorded in http://www.w3.org/2014/04/10-webapps-irc#T20-20-03
361. # [05:47] <RRSAgent> ACTION: jsbell to broadcast to the list with alia that we're starting on iDB2, ask for prioritization and feature suggestions. [11]
362. # [05:47] <RRSAgent> recorded in http://www.w3.org/2014/04/10-webapps-irc#T22-18-18
363. # [05:47] <RRSAgent> ACTION: marcos to reply to Lars [12]
364. # [05:47] <RRSAgent> recorded in http://www.w3.org/2014/04/10-webapps-irc#T22-51-38
365. # [05:47] * Parts: RRSAgent (rrsagent@public.cloak) (RRSAgent)
366. # [05:48] * Quits: ArtB (~abarsto@public.cloak) ("Leaving.")
367. # [07:09] * Joins: jcraig (~jcraig@public.cloak)
368. # [07:10] * Joins: lgombos (~gombos@public.cloak)
369. # [07:13] * Joins: anssik (~uid10742@public.cloak)
370. # [07:20] * Joins: tantek (~tantek@public.cloak)
371. # [07:29] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
372. # [07:37] * Quits: lgombos (~gombos@public.cloak) (Ping timeout: 180 seconds)
373. # [07:38] * Joins: jcraig (~jcraig@public.cloak)
374. # [07:38] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
375. # [09:17] * Quits: anssik (~uid10742@public.cloak) ("Connection closed for inactivity")
376. # [09:42] * Joins: lgombos (~gombos@public.cloak)
377. # [10:20] * Quits: lgombos (~gombos@public.cloak) (Ping timeout: 180 seconds)
378. # [10:52] * Joins: skddc (~anonymous@public.cloak)
379. # [11:00] * Joins: Lachy (~Lachy@public.cloak)
380. # [11:28] * Joins: hallvors (~hallvors@public.cloak)
381. # [11:48] * Quits: sicking (~sicking@public.cloak) (sicking)
382. # [11:56] * Joins: richt (~richt@public.cloak)
383. # [12:27] * Joins: chaals (~Adium@public.cloak)
384. # [12:31] * Joins: smaug (~chatzilla@public.cloak)
385. # [13:04] * Quits: richt (~richt@public.cloak) (Client closed connection)
386. # [13:05] * Joins: richt (~richt@public.cloak)
387. # [13:12] * Quits: richt (~richt@public.cloak) (Ping timeout: 180 seconds)
388. # [13:19] * Quits: chaals (~Adium@public.cloak) ("Leaving.")
389. # [13:26] * Joins: richt (~richt@public.cloak)
390. # [13:29] * Joins: chaals (~Adium@public.cloak)
391. # [13:36] * Quits: richt (~richt@public.cloak) (Client closed connection)
392. # [13:36] * Joins: richt (~richt@public.cloak)
393. # [13:43] * Quits: richt (~richt@public.cloak) (Ping timeout: 180 seconds)
394. # [14:15] * Quits: smaug (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
395. # [14:19] * Joins: dom (dom@public.cloak)
396. # [14:34] * Quits: chaals (~Adium@public.cloak) ("Leaving.")
397. # [14:36] * Quits: hallvors (~hallvors@public.cloak) (Ping timeout: 180 seconds)
398. # [14:55] * Quits: tantek (~tantek@public.cloak) (tantek)
399. # [15:41] * Quits: Lachy (~Lachy@public.cloak) (Ping timeout: 180 seconds)
400. # [15:42] * Joins: Lachy (~Lachy@public.cloak)
401. # [15:43] * Joins: richt (~richt@public.cloak)
402. # [15:52] * Joins: fjh (~fhirsch3@public.cloak)
403. # [16:06] * Joins: smaug (~chatzilla@public.cloak)
404. # [16:26] * Quits: richt (~richt@public.cloak) (Client closed connection)
405. # [16:26] * Joins: richt (~richt@public.cloak)
406. # [16:32] * Joins: richt_ (~richt@public.cloak)
407. # [16:32] * Joins: fjh_ (~fhirsch3@public.cloak)
408. # [16:33] * Quits: richt (~richt@public.cloak) (Client closed connection)
409. # [16:33] * Quits: fjh_ (~fhirsch3@public.cloak) (fjh_)
410. # [16:33] * Joins: lmclister (~lmclister@public.cloak)
411. # [16:39] * Quits: astearns (~sid15080@public.cloak) (Ping timeout: 180 seconds)
412. # [16:39] * Joins: astearns (~sid15080@public.cloak)
413. # [16:40] * Quits: fjh (~fhirsch3@public.cloak) (fjh)
414. # [16:41] * Quits: smaug (~chatzilla@public.cloak) (Client closed connection)
415. # [16:41] * Joins: stryx`_ (~stryx@public.cloak)
416. # [16:41] * Quits: lmclister (~lmclister@public.cloak) ("")
417. # [16:41] * Quits: stryx` (~stryx@public.cloak) (Ping timeout: 180 seconds)
418. # [17:06] * Joins: chaals (~Adium@public.cloak)
419. # [17:07] * Joins: smaug (~chatzilla@public.cloak)
420. # [17:19] * dglazkov good morning, Webapps!
421. # [17:20] * Joins: anssik (~uid10742@public.cloak)
422. # [17:28] <tyoshino> morning
423. # [17:43] * Joins: abarsto (~abarsto@public.cloak)
424. # [17:43] * abarsto is now known as ArtB
425. # [17:44] * Quits: smaug (~chatzilla@public.cloak) ("ChatZilla 0.9.90.1 [Firefox 31.0a1/20140411030201]")
426. # [17:45] * Joins: john_hazen (~john_hazen@public.cloak)
427. # [17:46] <cwilso> 'mornin'.
428. # [17:47] * Joins: smaug (~chatzilla@public.cloak)
429. # [17:48] * Joins: lmclister (~lmclister@public.cloak)
430. # [17:54] * Joins: FerasM (~FerasM@public.cloak)
431. # [18:01] * Joins: Bin_Hu (~Bin_Hu@public.cloak)
432. # [18:01] * Quits: Lachy (~Lachy@public.cloak) ("My MacBook Pro has gone to sleep. ZZZzzz…")
433. # [18:04] * Joins: Zakim (zakim@public.cloak)
434. # [18:04] <ArtB> zakim, this is IA_WebApps
435. # [18:04] <Zakim> ok, ArtB; that matches IA_WebApps()12:00PM
436. # [18:04] * Joins: RRSAgent (rrsagent@public.cloak)
437. # [18:04] <RRSAgent> logging to http://www.w3.org/2014/04/11-webapps-irc
438. # [18:05] * Joins: alia (~alia@public.cloak)
439. # [18:05] * Joins: aizu (~aizu@public.cloak)
440. # [18:05] <ArtB> RRSAgent, log spans midnight
441. # [18:05] <RRSAgent> I'm logging. I don't understand 'log spans midnight', ArtB. Try /msg RRSAgent help
442. # [18:05] * Joins: Arrrno (~Arrrno@public.cloak)
443. # [18:06] <ArtB> ScribeNick: ArtB
444. # [18:06] <ArtB> Scribe: Art
445. # [18:06] * Joins: krisk (~krisk@public.cloak)
446. # [18:06] <Arrrno> Present+ Arnaud_Braud
447. # [18:06] * Joins: israelh (~israelh@public.cloak)
448. # [18:07] <tyoshino> Present+ Takeshi_Yoshino
449. # [18:07] <ArtB> Meeting: WebApps f2f Meeting (San Jose CA US)
450. # [18:07] <dglazkov> http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0074.html
451. # [18:07] <krisk> present+ krisk
452. # [18:08] <dglazkov> present+ dglazkov
453. # [18:08] <Zakim> -[IPcaller]
454. # [18:08] * dglazkov cargocults
455. # [18:08] <ArtB> Agenda: https://www.w3.org/wiki/Webapps/April2014Meeting
456. # [18:08] <israelh> present+ israel hilerio
457. # [18:08] * Joins: adrianba (~adrianba@public.cloak)
458. # [18:08] <Zakim> +[IPcaller]
459. # [18:08] <ArtB> Present+ Art_Barstow
460. # [18:08] <anssik> Present+ Anssi_Kostiainen
461. # [18:08] <alia> Present+ Ali_Alabbas
462. # [18:08] <Yves> Present+ Yves_Lafon
463. # [18:08] * Joins: BenjamP (~BenjamP@public.cloak)
464. # [18:08] * Joins: rniwa (~rniwa@public.cloak)
465. # [18:08] <smaug> Zakim, [IPcaller] is Olli_Pettay
466. # [18:08] <Zakim> +Olli_Pettay; got it
467. # [18:08] <cwilso> Present+ Chris_Wilson
468. # [18:08] <israelh> present+ israel_hilerio
469. # [18:08] <FerasM> Present+ Feras_Moussa
470. # [18:08] <MikeSmith> Present+ MichaelTmSmith
471. # [18:08] <john_hazen> Present+ John_Hazen
472. # [18:09] <falken> Present+ Matt_Falkenhagen
473. # [18:09] <smaug> Zakim, nick smaug is Olli_Pettay
474. # [18:09] <Zakim> ok, smaug, I now associate you with Olli_Pettay
475. # [18:09] <BenjamP> Present+ Ben_Peters
476. # [18:09] <adrianba> Present+ Adrian_Bateman
477. # [18:09] * Joins: zqzhang (~zqzhang@public.cloak)
478. # [18:09] <hayato> Present+ Hayato_Ito
479. # [18:10] <zqzhang> Present+ Zhiqiang_Zhang
480. # [18:10] * Yves zakim, code?
481. # [18:10] * Zakim saw 9274 (tel:+1.617.761.6200 sip:zakim@voip.w3.org) given for the conference code, Yves
482. # [18:10] * Joins: Deen_King-Smith (~Deen_King-Smith@public.cloak)
483. # [18:10] * Parts: Deen_King-Smith (~Deen_King-Smith@public.cloak)
484. # [18:10] * Joins: dksmith (~dksmith@public.cloak)
485. # [18:10] <ArtB> RRSAgent, meeting spans midnight
486. # [18:10] <RRSAgent> ok, ArtB; I will not start a new log at midnight
487. # [18:11] * Joins: opoto (~opoto@public.cloak)
488. # [18:11] <opoto> present+ Olivier_Potonniee
489. # [18:11] * Joins: xiaoqian (xiaoqian@public.cloak)
490. # [18:11] * shepazu ArtB, please ping me when the charter comes up
491. # [18:12] * ArtB to shepazu - charter was yesterday
492. # [18:12] <Zakim> +[Paypal]
493. # [18:12] * ArtB sorry about that Doug!
494. # [18:13] <smaug> hello all
495. # [18:13] * shepazu :(
496. # [18:13] * smaug will be listening again in the background.
497. # [18:13] * Arrrno you missed all the charter fun, poor thing
498. # [18:13] * Joins: genelian_ (~genelian@public.cloak)
499. # [18:14] <genelian_> present+ Gene_Lian
500. # [18:14] * Joins: jinsong (wjs@public.cloak)
501. # [18:14] <ArtB> zakim, who's here?
502. # [18:14] <Zakim> On the phone I see ??P2, Olli_Pettay, [Paypal]
503. # [18:15] <Zakim> On IRC I see jinsong, genelian_, xiaoqian, opoto, dksmith, zqzhang, rniwa, BenjamP, adrianba, israelh, krisk, Arrrno, aizu, alia, RRSAgent, Zakim, Bin_Hu, FerasM, lmclister, smaug,
504. # [18:15] <Zakim> ... john_hazen, ArtB, anssik, chaals, stryx`_, astearns, richt_, dom, skddc, hayato, kochi, paul___irish, krijnhoetmer, tobie__, morrita, slightlyoff, dfreedm_, cwilso, timeless_,
505. # [18:15] <Zakim> ... scheib__, jsbell, dcooney, dglazkov, cabanier__, krit, tyoshino, hober, falken, Domenic_, pdr__, gavin, tzik, shepazu, jgraham, decadance, gsnedders, heycam|away, schuki
506. # [18:15] <ArtB> RRSAgent, make minutes
507. # [18:15] <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/11-webapps-minutes.html ArtB
508. # [18:15] * dksmith slaps dksmith around a bit with a large fishbot
509. # [18:16] * Quits: aizu (~aizu@public.cloak) (Ping timeout: 180 seconds)
510. # [18:16] * Quits: dom (dom@public.cloak) ("")
511. # [18:16] <MikeSmith> Zakim, who's on the phone?
512. # [18:16] <Zakim> On the phone I see ??P2, Olli_Pettay, [Paypal]
513. # [18:17] * MikeSmith do we know who P2 on the phone is?
514. # [18:17] * Joins: jmajnert (~jmajnert@public.cloak)
515. # [18:17] <anssik> zakim, ??P2 is me
516. # [18:17] <Zakim> +anssik; got it
517. # [18:17] * MikeSmith thanks anssik
518. # [18:18] * Joins: jungkees (~uid24208@public.cloak)
519. # [18:18] <jungkees> Present+ Jungkee_Song
520. # [18:19] * Joins: Travis (~Travis@public.cloak)
521. # [18:20] <israelh> Topic: Web Components
522. # [18:20] <adrianba> scribe: israelh
523. # [18:21] * Joins: plh (plehegar@public.cloak)
524. # [18:21] <israelh> dglazkov: WOuld like to break down discussion into three topics: Shadow DOM, Custom Elements, and HTML Inputs
525. # [18:21] * Joins: aizu (~aizu@public.cloak)
526. # [18:22] <adrianba> s/Inputs/Imports/
527. # [18:22] <israelh> ... Shadow DOM is the more interesting. Let's pick which one we want to discuss first.
528. # [18:22] <israelh> ... Start with Custom Elements ?
529. # [18:22] <krisk> s/WOuld/Would/
530. # [18:22] <israelh> ... Shadow DOM after that?
531. # [18:22] <israelh> ... Custom elements is in first draft
532. # [18:23] <ArtB> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html -> Custom Elements Editor's Draft
533. # [18:23] <dglazkov> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24578
534. # [18:23] <israelh> ... And interesting topic to start with 24578 buhg
535. # [18:23] <israelh> ... Registering a register primitive
536. # [18:23] * Quits: alia (~alia@public.cloak) (Ping timeout: 180 seconds)
537. # [18:24] <israelh> ... Having the ability to expose internal attributes on Customer elements allow you to clone it, assing it to a different document
538. # [18:25] <ArtB> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567#c69 -> Anne's comment #69 for bug 20567
539. # [18:25] * rniwa says I have a selection API specification draft hosted at http://rniwa.github.io/selection-api.html
540. # [18:25] <israelh> ... The idea is that when an element is adopted from one doc to another, and as an an author of the element you will get a callback that allows you to reason about the attribute being used in other elements
541. # [18:26] <israelh> ... also, the idea that you could use the registry as a way to scope the element names.
542. # [18:26] * Joins: alia (~alia@public.cloak)
543. # [18:27] * Joins: alia_ (~alia@public.cloak)
544. # [18:27] * Quits: alia_ (~alia@public.cloak) ("Page closed")
545. # [18:28] <israelh> ... a web developer has a sub-tree in their document and would like to parse their specific elements from the local registry. Having a scoping concept would be very useful for them. However, if you want to rountrip when coming back form the parse you would have problems
546. # [18:28] <israelh> ... because when you serialize the tree the parse would have no idea of where that element came from, thus surprising.
547. # [18:28] <israelh> ... I would like to introduce the registry concept into the spec and see where it goes from there.
548. # [18:28] * Quits: richt_ (~richt@public.cloak) ("Leaving...")
549. # [18:29] <israelh> ... I want to allow allowNode callback to reason about registries.
550. # [18:29] <israelh> ... I would like to get everyone's opinion about it.
551. # [18:29] * rniwa rniwa
552. # [18:29] * pdr__ is now known as pdr
553. # [18:29] <israelh> rniwa: What is the use case for the callback.
554. # [18:30] <israelh> dglazkov: deeper into this subject. IE and FF have a behavior that is different from blink and WebKit and their prototype when it is adopted from another doc.
555. # [18:31] <israelh> ... IE and FF when you are adopted from one doc to another, you loose your old prototypes. Blink and WebKit don't do that.
556. # [18:31] <israelh> ... there is disagrements whether this should be on spec.
557. # [18:31] * Quits: mounir (~mounir@public.cloak) ("leaving")
558. # [18:31] <israelh> ... the callback we are discussing provides a mechanism to allow elements to update the prototypes dynamically. Thus, becoming and implementation detail instead of part of the spec.
559. # [18:32] <israelh> rniwa: it might be more useful to standardize the UA behaviors instead of putting this on the hands of the devs.
560. # [18:33] <israelh> dglazkov: for custom elements this decision is not so clear. It is not always clear what is the right behavior. Specially if the definintion of my element is not defined on the new environment.
561. # [18:33] <israelh> ... element foo may colide with a different definition of another element foo on that document.
562. # [18:34] <israelh> rniwa: it seems strange that each doc would behave diff on each environment. It doesn't allow you to reason about the custom element on the environment that is being used.
563. # [18:34] <israelh> dglazkov: this seems bad if you don't have the ability to reason about the custom elements diff.
564. # [18:34] * ArtB oh, so we need namespaces for each custom element ;-)
565. # [18:34] <israelh> adrianba: it would be bad.
566. # [18:35] <israelh> rniwa: it seems like we need to figure out how we can guarantee that the custom element keeps the same information across document. Maybe this is the issue.
567. # [18:35] <israelh> dglazkov: that is what registers let you do. You can look at the registry and reason about this.
568. # [18:35] <israelh> rniwa: potentially you can have a global map for each page. that checks if the definition of the class has been raised and possibly rejected. Some type of consistency check.
569. # [18:36] <israelh> ... we probably don't want to reason about having different custom elements that are of the same expected type.
570. # [18:36] <israelh> dglazkov: the thing is that it doesn't have to be the case, the problem is that the scenario could happen and we need to figure out how to deal with this.
571. # [18:37] <israelh> rniwa: for ex. you can imagine the registry happening about all in one script context, within one navigation.
572. # [18:38] <israelh> dglazkov: there is a specific reason the registry is scoped to the doc. because each doc could have its own set of elements.
573. # [18:39] <israelh> ... in xhr docs don't have a registry for custom elements and don't run script.
574. # [18:39] <israelh> ... there is no document in browsing context. there is no association between document and browser context.
575. # [18:39] <israelh> rniwa: in the case of XHR, there isn't any document context.
576. # [18:40] <israelh> dglazkov: the create implementation of create document should have a document context.
577. # [18:40] * Joins: KenjiBX (~KenjiBX@public.cloak)
578. # [18:41] <israelh> ... (looking at spec chapters looking for something )
579. # [18:41] <rniwa> s/document context/browsing context/
580. # [18:42] <israelh> ... creating and passing a regisry section, we do associate a new registry at that point when creating a new import document (those things don't have a browsing context but are able to operate as if they had a registry)
581. # [18:42] <israelh> ... It is a good idea to look at this bug 20567 and understand what needs to be done here.
582. # [18:43] <dglazkov> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567#c69
583. # [18:43] <israelh> rniwa: exposing a list of custom registries seems like a good thing. but I'm not sure how the ability to update the definition of the doc using this information is a good idea.
584. # [18:43] <israelh> adrianba: if you end up with a button and import a different button (but when looking at the elements they look the same) that seems like a bad situation.
585. # [18:44] <israelh> dglazkov: I agree this is a bad situation, that is what we are trying to solve.
586. # [18:44] <israelh> ... this is not a use case, it is more of how do we deal with this if it happens.
587. # [18:44] <israelh> adrianba: can we just say that the call fails and the element doesn't work.
588. # [18:45] <israelh> dglazkov: it seems reasonable to make it work, however we need to reason about their seirialization differences.
589. # [18:46] <israelh> adrianba: can we clone the prototype?
590. # [18:46] <israelh> ... if we import from one doc to another and then clone the prototype things might work.
591. # [18:47] <israelh> dglazkov: I'm not sure there is a concept of cloning the prototype. the notion that you are attached to the old world, where someone creates a doc, registers things to it, import those notes, but not sure why you would do that although it is supported.
592. # [18:48] <israelh> rniwa: maybe we could have the registry that is shared across elements that come from the same origin.
593. # [18:48] <smaug> what does cloning the prototype mean? should the expando properties from the old prototype be cloned too?
594. # [18:48] <israelh> ... if we do that, we have the same issue where one prototype has multiple def, but if we had this mechanism (park all docs in the same origin) we might be okay if registration is simulatneous. It would reduce the instance in which the def are diff.
595. # [18:49] * Joins: mjs (~mjs@public.cloak)
596. # [18:49] <israelh> ... after we create the object, that doesn't mean that the two objects are the same.
597. # [18:49] <mjs> q+
598. # [18:49] * Zakim sees mjs on the speaker queue
599. # [18:49] <israelh> dglazkov: if you want to compare, you would have to introduce the abiltiy to compare diff between elements.
600. # [18:50] <israelh> rniwa: if we allow customents, we need to provide that ability to compare themselves. This could be a big developer issue. We need to come up with a solution where we don't burden the author of the custom element.
601. # [18:51] <plh> ack mjs
602. # [18:51] * Zakim sees no one on the speaker queue
603. # [18:51] <israelh> mjs: clarification, do we have the usecase for adapt a custom element from one doc to another, is this a real case or theoretical.
604. # [18:52] <israelh> adrianba: is the situation where the custom element has the same name but a different instantiation
605. # [18:52] <israelh> mjs: can we just let this scenario fail, or do we need to support it? failing seems like a good approach if this is an edge case.
606. # [18:53] <israelh> dglazkov: I didn't say this wasn't sufficient, i would like to reduce the number of errors we throw.
607. # [18:53] <israelh> ... yes it simplifies but it will likely anoy the developer.
608. # [18:53] <israelh> mjs: It will only anoy the author if this is a common case, otherwise he should be okay.
609. # [18:53] <KenjiBX> +q
610. # [18:53] * Zakim sees KenjiBX on the speaker queue
611. # [18:54] * Joins: kochi_w3c (~kochi_w3c@public.cloak)
612. # [18:54] <israelh> dglazkov: there are many shades of gray here. There is a reasonable situation with HTML templates when you are moving from a template to the main document. We need to support this situation, we don't want to throw.
613. # [18:54] <ArtB> q?
614. # [18:54] * Zakim sees KenjiBX on the speaker queue
615. # [18:54] <israelh> mjs: there are simple behaviors we could support without throwing.
616. # [18:55] <israelh> ... (talking about possible options). buttom line we should err on the side of simplicity.
617. # [18:55] <Yves> msg &systeam triple checked which passwd, the old or the new one? ;)
618. # [18:55] <israelh> dglazkov: the main case where we need to do the right thing is when we deal with multiple docs that are import docs and templates. Those things have to work, if we start messing with the definitions there we are in trouble.
619. # [18:56] <Yves> s/msg &systeam triple checked which passwd, the old or the new one? ;)//
620. # [18:56] * Yves goes outside buying new hands
621. # [18:56] * Zakim Yves, you typed too many words without commas; I suspect you forgot to start with 'to ...'
622. # [18:56] <israelh> mjs: import docs share the same registry.
623. # [18:56] <israelh> ... requiring docs to deal with extra complexities seems difficult to address as a component author.
624. # [18:57] <israelh> dglazkov: what complexity are you talking: adapt mode callback and registry? The adopt mode callback allows for changes to be reacted when loading resources.
625. # [18:57] <israelh> mjs: do custom elements allow for remove and insert into documents?
626. # [18:57] <israelh> dglazkov: no
627. # [18:58] <israelh> mjs: adapt doesn't seem like a special case unless, many people have already created custom elements without this functionality.
628. # [18:58] <israelh> dglazkov: not sure how DOM core works here. Anne had some ideas here. We can definetely talk about the importance of this callback.
629. # [18:59] <israelh> mjs: what is the correct venue to discuss this?
630. # [18:59] <israelh> dglazkov: 20567 bug is the right venue for this.
631. # [18:59] <adrianba> ack next
632. # [18:59] * Zakim sees KenjiBX at the head of the speaker queue
633. # [18:59] * Zakim sees no one on the speaker queue
634. # [18:59] <rniwa> +q
635. # [18:59] * Zakim sees rniwa on the speaker queue
636. # [18:59] <israelh> KenjiBX:
637. # [19:00] <israelh> KenjiBX: it seems there is no real case, and the conclusion is to make it fail. If we find out later that there is a use case, can we then deal with this situation.
638. # [19:01] <israelh> dglazkov: I beleive this is reasonable. That is the reason I wanted to bring it up to the group. I wanted to get everyone's opinion in the need to register. I will put it in the back burner. THere are some usescases that might help. I'm not feeling the love right now.
639. # [19:01] <israelh> ... we can talk about the difference between adoption and registration.
640. # [19:02] <ArtB> ack rniwa
641. # [19:02] * Zakim sees no one on the speaker queue
642. # [19:02] <israelh> mjs: adpation node without inserting anywhere is very rare, (doesn't seem to happen).
643. # [19:02] * Quits: chaals (~Adium@public.cloak) ("Leaving.")
644. # [19:03] <israelh> ... if they were to change to insert doc and remove doc, then we could easily look for customer default view. if we had that, elements could check that. If I had the option of adding the adapt callback then I would prefer the ability to inserting attach and detach.
645. # [19:04] <ArtB> Present+ Maciej, Laszlo_Gombos, Alex_Russell
646. # [19:04] <israelh> mjs: if we had remove and insert, we could simplify the operations.
647. # [19:04] * Joins: tantek (~tantek@public.cloak)
648. # [19:04] <israelh> dglazkov: please provide feedback on bug and state your opinion, it could be that what you are suggesting is good enough.
649. # [19:05] <israelh> mjs: maybe we should have a different bug on remove and add callback
650. # [19:05] <rniwa> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24577
651. # [19:05] <israelh> dglazkov: there seems to be one bug on this (24577)
652. # [19:07] <israelh> mjs: I think Anne in this bug is looking at the leaking of the entire document when the element moves.
653. # [19:07] <israelh> dglazkov: any help here would be appreciated, maybe if we solve this problem we might be in good shape for the previous bug.
654. # [19:08] <israelh> mjs: It seems like letting thing fails would be the initial good approach for this.
655. # [19:08] <israelh> ... perhaps the concept of a global registry that is shared everywhere could be an interesting approach.
656. # [19:09] <israelh> dglazkov: let's work on these two bugs and discuss the possibility to add remove and add from document concepts.
657. # [19:10] <israelh> dglazkov: is the ship in the water or the deep in the ground :-)
658. # [19:10] <alia> Scribe: Ali
659. # [19:10] <alia> ScribeNick: alia
660. # [19:11] <alia> dglazkov: I need something in my custom elements to mean something different. Use case: I'm building a framework. Custom elements are in and out of the framework. Inside is the plumbing that uses custom elements because it's useful. How to separate the two and don't expose to each other.
661. # [19:11] * Quits: Bin_Hu (~Bin_Hu@public.cloak) ("Page closed")
662. # [19:12] <ArtB> RRSAgent, make minutes
663. # [19:12] <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/11-webapps-minutes.html ArtB
664. # [19:12] <alia> ... Shadow DOM is a good example. Parser is per docment. But that seems like a bad idea. Maybe we could let the frameworks define the registry that contains the internal plumbing and feed it to innerHTML of the fragment parsing of the shadow trees that they're creating so that when they create these things they get the definitions of these outside elements.
665. # [19:12] <ArtB> RRSAgent, make log Public
666. # [19:12] <RRSAgent> I have made the request, ArtB
667. # [19:12] <mjs> q+
668. # [19:12] * Zakim sees mjs on the speaker queue
669. # [19:12] <ArtB> RRSAgent, make minutes
670. # [19:12] <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/11-webapps-minutes.html ArtB
671. # [19:13] <alia> ... Allows the ability to scope the parser. Bringing up here. Give me a doc registry and add stuff to it. May have a method that is in addition to pass the registry.
672. # [19:13] * Joins: Lachy (~Lachy@public.cloak)
673. # [19:13] <alia> ... Can put things in template and as it's being inserted into the shadow tree, they will be inflated the proper way. Not sure if this is outlandish or crazy or both.
674. # [19:14] <ArtB> ack mjs
675. # [19:14] * Zakim sees no one on the speaker queue
676. # [19:14] <alia> mjs: Want to understand the use case better. Two possible meanings. An element that is used in the light DOM. TR in TABLE. TR outside of TABLE is not sensical. Other compound elements that have these structures. Want to have some elements as implementation details.
677. # [19:15] <alia> dglazkov: You're right on. Shadow DOM is the prime use case, but there are some thoughts on this in light DOM. Parent changes the meaning of the element outside.
678. # [19:16] <alia> mjs: Need different ways of dealing with these two cases. Need an attachment of the custom element to be conditional based on the parent element.
679. # [19:16] <alia> ... Which do we want?
680. # [19:16] <alia> dglazkov: I don't care how it's fixed, but we need a fix. In my mind, having meaning changed based on the parent is a path to madness.
681. # [19:16] <adrianba> q?
682. # [19:16] * Zakim sees no one on the speaker queue
683. # [19:17] <alia> mjs: Want to refactor internal implementation. Two completely different use cases.
684. # [19:17] <alia> dglazkov: When a developer has no Shadow DOM, they only have one of them. Here is my internal and external stuff. Spoken from a developer who has not ever had a shadow tree.
685. # [19:17] <rniwa> q+
686. # [19:17] * Zakim sees rniwa on the speaker queue
687. # [19:18] <alia> alexrussel: We don't know what we don't know in this area. We don't know what people actually want to do. If we make it possible to create new local namesets, it removes any incentive to agree on global names. We lose our ability to define elements and custom semantics. Would lose value on the web.
688. # [19:19] <alia> mjs: Depends on which use case. Some degree of global agreement. There can be imports, but some internal that it can use. Cleaner way to do it, than have scoped registry. Only some of the names I define can be exported. May change the way the that import function works, so it is not suggested we do it right now.
689. # [19:20] <alia> ... TR almost makes sense in the context of the TABLE element. There are specific elements that are defined in this hierarchy.
690. # [19:21] <alia> ... It seems obvious that people would want to build things like this. It clearly is a use case. Do not agree with using private names would reduce incentive to create global names.
691. # [19:21] <alia> ... Get developers to participate in the group so we can have a direct conversation with them to understand the use cases better.
692. # [19:22] <alia> ... It would help if you want clarification on this feedback to ask them directly.
693. # [19:22] <alia> dglazkov: I will try to get people.
694. # [19:22] <alia> ... We have beaten this registry thing pretty well. Moving on to custom elements.
695. # [19:23] <alia> ... I want to tackle exposing element on callback queues first.
696. # [19:23] <ArtB> http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0074.html -> Dimitri's topic list
697. # [19:23] <alia> ... There was a valid point brought up that custom element spec reminds us of a special kind of mutation observers.
698. # [19:24] * Joins: jsbell_ (~jsbell@public.cloak)
699. # [19:24] * Quits: FerasM (~FerasM@public.cloak) ("Page closed")
700. # [19:24] <alia> ... In the custom elements spec, in queueing and invoking callback. The general idea is there is a quantum of time for invoking callbacks that is different than queueing callbacks. Might be a good idea to expose this a mutation observer so that developers can start using it directly.
701. # [19:24] <alia> ... Want to gauge opinion.
702. # [19:25] <dglazkov> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24579
703. # [19:25] * Joins: FerasM (~uid28672@public.cloak)
704. # [19:25] <alia> rniwa: Only feedback is that it is vaguely specified. Transitioning between scripts. Multiple stacks of user scripts and user agent scripts that would result in messy situation. Running two user scripts with an interleaved DOM script based on the spec's wording. Could use more clarification.
705. # [19:26] <alia> dglazkov: Posted a bug 24579. After callback, drain the pool, so that we can fix the problem
706. # [19:27] <alia> mjs: Super inconvenient because every native method that does this wouldn't require annotation. If implementations are done in native and client code, the draining needs to be conditional. There are some cases when this could happen.
707. # [19:27] * Quits: Lachy (~Lachy@public.cloak) ("My MacBook Pro has gone to sleep. ZZZzzz…")
708. # [19:27] <alia> dglazkov: This is a separate topic and so we need to separate the abstractions. Need to separate the quantum of time for callbacks and queueing. Start trusting it in a certain point in time and stop at a certain point in time.
709. # [19:28] <alia> ... Only a few methods that do this.
710. # [19:28] <alia> mjs: There are many methods that don't mutate DOM but could mutate script that mutate DOM.
711. # [19:28] <dglazkov> https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/Element.idl
712. # [19:29] <alia> dglazkov: Already done this in Blink, if you look at the element.IDL, you would see a bunch of Custom element callbacks. Some of them, some will, but it's not really that bad.
713. # [19:29] <alia> mjs: Let me ask a specific quesiton, does dispatch event have this notation?
714. # [19:29] <alia> ... Could retake the DOM.
715. # [19:29] <alia> dglazkov: Dispatch event itself does not mutate DOM.
716. # [19:30] <ArtB> q?
717. # [19:30] * Zakim sees rniwa on the speaker queue
718. # [19:30] * Quits: plh (plehegar@public.cloak) ("Leaving")
719. # [19:30] <alia> ... In the event handler will have its own draining which will arrive at a consistent state.
720. # [19:30] <alia> mjs: Will always be at a safe point in this case.
721. # [19:31] <ArtB> ack rniwa
722. # [19:31] * Zakim sees no one on the speaker queue
723. # [19:31] <morrita> Just FYI: https://code.google.com/p/chromium/codesearch#search/&q=CustomElementCallbacks%20file:idl
724. # [19:31] <john_hazen> s/could mutate script/could include script/
725. # [19:31] <alia> dglazkov: Trying to wrap up mutation events. Did not participate in mutation observers but will give it a shot and see what I can come up with.
726. # [19:32] <alia> rniwa: Jonas pointed out on one of the threads is that mutation observers calling each other back while in an observer itself, with this new nano task timing, it's possible to create an element in the observer and that could create an issue.
727. # [19:33] <alia> dglazkov: When changed to a generic mechanism, but solved by queues. Need to look into this in more detail. Mutation observer observes per element, narrowed down. An element queue and a callback queue, and every element has an element queue, separating these out allows for handling this in a consistent fashion.
728. # [19:34] <alia> rniwa: Trying really hard to solve issue where removing the element itself.
729. # [19:34] <alia> dglazkov: Going to see them being called in the same order for consistency. If observing yourself, you see that you are being attached.
730. # [19:35] <alia> mjs: I don't think that's the biggest problem. The problem is that attaching can occur inside the attach.
731. # [19:35] <alia> ... In attach callback that removes a node, inside the attach, document.body.appendChild(this). Inside that attach, you would insert back in the document, at which point you would be calling attach again.
732. # [19:36] <alia> dglazkov: The element queue solves this. While inside of the attach handler, you won't hear any callbacks until completion. What is the element that you're procesing and which is the callback you're processing is asked when there is an execution.
733. # [19:37] <alia> rniwa: Attach will be called, but the detach will be called later.
734. # [19:37] * Joins: mounir (~mounir@public.cloak)
735. # [19:37] <alia> dglazkov: After finishing running callback of attach, then attach would occur.
736. # [19:38] <ArtB> q?
737. # [19:38] * Zakim sees no one on the speaker queue
738. # [19:38] <alia> ... When using element callbacks, you have to rely on what the callbacks tell you, because the state is going to tell you either you're going to observe the outside world or only the callbacks that arrived. If you have been detached despite having been attached, it will work because you can trust the callbakcs.
739. # [19:39] <alia> s/callbakcs/callbacks
740. # [19:39] <alia> rniwa: In the custom code, there may be some event that asynchronously causes issues.
741. # [19:40] <alia> ArtB: Now going to break, coming back at 11.
742. # [19:43] * Joins: marcosc (~marcosc@public.cloak)
743. # [19:45] * Quits: rniwa (~rniwa@public.cloak) (Ping timeout: 180 seconds)
744. # [19:45] * Quits: kochi_w3c (~kochi_w3c@public.cloak) (Ping timeout: 180 seconds)
745. # [19:46] * Quits: krisk (~krisk@public.cloak) (Ping timeout: 180 seconds)
746. # [19:47] * Quits: alia (~alia@public.cloak) (Ping timeout: 180 seconds)
747. # [19:48] * Quits: mjs (~mjs@public.cloak) (Ping timeout: 180 seconds)
748. # [19:59] <ArtB> RRSAgent, make minutes
749. # [19:59] <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/11-webapps-minutes.html ArtB
750. # [20:02] * Joins: krisk (~krisk@public.cloak)
751. # [20:02] <krisk> scribe: krisk
752. # [20:02] * Joins: darobin (rberjon@public.cloak)
753. # [20:03] * darobin "Many types of XML-processing applications need to address into the internal structures of XML resources using URI references, for example, the XML Linking Language, XML Inclusions, the Resource Description Framework, and SOAP 1.2." A group of winners right there!
754. # [20:03] <Zakim> -Olli_Pettay
755. # [20:03] <smaug> (another meeting)
756. # [20:03] * Joins: rniwa (~rniwa@public.cloak)
757. # [20:04] * Joins: plh (plehegar@public.cloak)
758. # [20:04] * Joins: kochi_w3c (~kochi_w3c@public.cloak)
759. # [20:05] <krisk> artb: proposes to have a meeting once in a while for web components
760. # [20:05] * Joins: mjs (~mjs@public.cloak)
761. # [20:05] <ArtB> ACTION: barstow work with Dimitr re a Web Components calls/meetings
762. # [20:05] * @trackbot is creating a new ACTION.
763. # [20:05] * RRSAgent records action 1
764. # [20:05] <@trackbot> Created ACTION-727 - Work with dimitr re a web components calls/meetings [on Arthur Barstow - due 2014-04-18].
765. # [20:05] <krisk> ACTION: artb setup semi regular meeting for web components
766. # [20:05] * RRSAgent records action 2
767. # [20:05] * @trackbot is creating a new ACTION.
768. # [20:05] <@trackbot> Created ACTION-728 - Setup semi regular meeting for web components [on Arthur Barstow - due 2014-04-18].
769. # [20:05] <krisk> TOPIC: Custom Elements
770. # [20:05] <krisk> ..automatic upgrade of custom elements
771. # [20:06] <krisk> dglazkov: I'd like to present a use case for this..
772. # [20:06] <krisk> ..after an element is registered
773. # [20:06] <krisk> ..section 7 in spec, step #7 (run element upgrade algo)
774. # [20:07] * darobin hober, slightlyoff: FWIW I think this can be turned into something sane http://www.w3.org/TR/xptr-framework/ and this can be spec'ed so as to work http://simonstl.com/articles/cssFragID.html
775. # [20:07] <krisk> If an element in or outside of a tree when the registation comes around the element will take the right shape
776. # [20:08] <krisk> The key use case was that when we would run queryselector would not work (shadow doms)
777. # [20:08] <krisk> ..we wanted to make this easier for devs
778. # [20:08] <krisk> The side effect is that a sync loaded document, framework devs want to get to a consistent state and don't want to do extra work
779. # [20:09] <krisk> ..When I talked to amber, they were very unhappy I removed this from the spec (which I didn't) and then they were very happy
780. # [20:09] * Quits: lmclister (~lmclister@public.cloak) ("")
781. # [20:10] <krisk> ..They don't want to have to deal with ambiguity when this element will be completed
782. # [20:10] <krisk> It's basically queryselectorall'ible everywhere
783. # [20:10] <krisk> mjs: Some people from apple don't like this...
784. # [20:11] <krisk> ..You want to load some custom element - three problems
785. # [20:11] <krisk> ..web page load parse is slow, forces UA do display partial display
786. # [20:12] <krisk> ..Manually have to go check or manually upgrade these elements
787. # [20:12] <krisk> If you just want to know when the state is done and complete
788. # [20:12] <krisk> ..you could wait until all are done loading, not optimal, if one set if slow
789. # [20:13] * Quits: KenjiBX (~KenjiBX@public.cloak) (Ping timeout: 180 seconds)
790. # [20:13] <krisk> The third option is what is in the spec, if you access the element before the upgrade has been complete you have a problem
791. # [20:13] <krisk> ..which is a hazard - accessing an html element proto
792. # [20:14] <krisk> ..so you have to wait
793. # [20:14] <krisk> Either way you better not do any scripting untill all is complete
794. # [20:15] <krisk> dglazkov: The key part you can access this until the upgrade has completed
795. # [20:15] <krisk> mjs: you can't save a ref
796. # [20:15] <krisk> dgazkov: it will always be the same ref
797. # [20:16] <krisk> .The swizzle doesn't modify the change...
798. # [20:16] <krisk> ..we ensure the swizzle only adds more items on top of the proto
799. # [20:17] <krisk> mjs: Let me ask a clarifying question..
800. # [20:18] <krisk> dglazkov: you can't go from select to my custom select
801. # [20:18] <krisk> mjs: can you not only do this with a generic html element?
802. # [20:19] <krisk> dglazkov: you need to specificaly call to extend select
803. # [20:19] * Joins: arunranga (~arunranga@public.cloak)
804. # [20:20] <krisk> dglazkov: this make sure that you only insert items at the top of the prototype chain
805. # [20:20] <krisk> ..Then you can save, set prop, to the elements, etc...
806. # [20:21] <krisk> ..before the upgrade
807. # [20:21] <krisk> mjs: It seem that from the 3 possible choices, we don't want the bad perf.
808. # [20:22] <krisk> mjs: you have the hazard or you get the work done but the the proto-type may not be perfect until the upgrade is complete
809. # [20:22] <krisk> ..It's not required but a nice to have in the base system
810. # [20:23] <krisk> dglazkov: We have to make sure that with multiple frameworks need a single 'go'
811. # [20:23] <krisk> mjs: one for of this would be a single event for all is one possible solution, not that I'm saying this is the best solution
812. # [20:24] <krisk> alex: feedback from users has been pretty strong that not having this ability is bad
813. # [20:24] <krisk> mjs: how we choose to do 'science' compared to asks from feedback?
814. # [20:25] <krisk> rniwa: For page that use the old style (display:none)..
815. # [20:25] <krisk> dglazkov: that has never been the case - psudeo - unresolved whould be the 'match'
816. # [20:26] <krisk> rniwa: so now if you have some component that load sync, you have to have some style that uses component
817. # [20:26] <slightlyoff> (I also added that strong feedback across multiple toolkits/users is distinct from weak feedback)
818. # [20:28] <krisk> dglazkov: this is not a problem at least in webkit and blink
819. # [20:28] <krisk> dglazkov: the problem we have seen is you really can only do display:none or a block
820. # [20:28] <krisk> rniwa: let me make my point
821. # [20:29] <krisk> ..if the author had to specify the style for an unresolved element, which will not be consistent on page load times
822. # [20:29] * Joins: lmclister (~lmclister@public.cloak)
823. # [20:29] <krisk> ..Their is basically no way to get consistent results of the element rendering
824. # [20:30] <krisk> dglazkov: This has nothing related to upgrade mechanism
825. # [20:30] * Joins: KenjiBX (~KenjiBX@public.cloak)
826. # [20:31] <krisk> mjs: one use case, could be a select control that shows up like a map
827. # [20:31] <krisk> ..before the upgrade it would look ugly until the upgrade has occured.
828. # [20:31] <krisk> ..even display: none would be ugly
829. # [20:32] <krisk> ..no real way exists to fix this problem
830. # [20:32] <krisk> alex: we shoud ask css to help to get a mechanism to be in control of the display/paint/rendering can start
831. # [20:33] <krisk> dglazkov: web devs do bad patterns to try to control this pattern, like in editing..
832. # [20:34] <krisk> ...one framework uses document.write...
833. # [20:35] <krisk> rniwa: can we take this upgrade to the mailig list?
834. # [20:35] <krisk> dglazkov: sure
835. # [20:35] * Joins: tantek_ (~tantek@public.cloak)
836. # [20:35] * Quits: tantek_ (~tantek@public.cloak) ("Page closed")
837. # [20:35] <krisk> rniwa: To help close on the flash of styling issues
838. # [20:35] <krisk> TOPIC: Shadow Dom
839. # [20:36] <dglazkov> smaug: are you there?
840. # [20:36] <smaug> just a sec
841. # [20:36] <krisk> yves will now scribe!
842. # [20:36] <Yves> scribe: Yves
843. # [20:36] <smaug> now
844. # [20:36] * Yves adjourn!
845. # [20:36] <Zakim> +[IPcaller]
846. # [20:36] <darobin> Zakim, [ is smaug
847. # [20:36] <Zakim> sorry, darobin, I do not recognize a party named '['
848. # [20:36] * Yves shadow dom: http://www.w3.org/People/Dom/portrait.jpg
849. # [20:36] <darobin> Zakim, +[ is smaug
850. # [20:36] <Zakim> sorry, darobin, I do not recognize a party named '+['
851. # [20:37] * darobin Zakim, [IPCaller] is smaug
852. # [20:37] * Zakim +smaug; got it
853. # [20:37] * dglazkov we can hear you really well!!
854. # [20:37] <smaug> good
855. # [20:37] <dglazkov> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887
856. # [20:39] <dglazkov> https://etherpad.mozilla.org/RKukNtHHlO
857. # [20:39] <Yves> rniwa: issue is about nested shadow dom
858. # [20:39] <Yves> dglazkov: etherpad above has canonical examples
859. # [20:40] * Joins: skddc_ (~anonymous@public.cloak)
860. # [20:42] <Yves> rniwa: why firing the even at the last insertion point is not enough?
861. # [20:42] <Yves> dglazkov: as the insertion point is at the most nested place, the nesting shadow tree does not hear the event
862. # [20:43] <rniwa> s/the even at/the event at/
863. # [20:43] * Quits: skddc (~anonymous@public.cloak) (Ping timeout: 180 seconds)
864. # [20:43] * skddc_ is now known as skddc
865. # [20:43] <Yves> one solution was to generate interim div to listen to the insertion point, which is bad as well
866. # [20:44] <ArtB> q?
867. # [20:44] * Zakim sees no one on the speaker queue
868. # [20:44] <Yves> the specs breaks the invariant that item in the even path are always children of the next item
869. # [20:46] <Yves> rniwa: is the spec bz's proposal?
870. # [20:46] <Yves> dglazkov: no it's the other one
871. # [20:47] * rniwa already likes Boris' proposal.
872. # [20:47] <smaug> ++ rniwa
873. # [20:47] * rniwa looks at mjs & hober.
874. # [20:49] <Yves> (Hayato Ito describes the alg)
875. # [20:50] * hober is happy to defer to rniwa's considered opinion here.
876. # [20:52] <Yves> Hayato: the second algorithm has more complexity
877. # [20:52] * hober rniwa: http://w3cmemes.tumblr.com/post/39943615914/
878. # [20:53] * rniwa that happens EVERY TIME!
879. # [20:53] <Yves> dglazkov: I agree that preserving the invariant is desirable
880. # [20:53] <smaug> more ++ to rniwa
881. # [20:54] <smaug> rniwa: were you surprised somehow?
882. # [20:54] <Yves> rniwa: to me, bz's proposal make more sense. Much easier for developers
883. # [20:54] <Yves> ArtB: looks like we have a way forward here
884. # [20:57] <Yves> maciej: how about discussing encapsulation?
885. # [20:57] <darobin> ScribeNick: darobin
886. # [20:57] <mjs> http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0312.html
887. # [20:57] <darobin> mjs: back in Dec 2012 we had a big discussion about Components and traversability of the shadow DOM and how that relates to encapsulation
888. # [20:57] <darobin> ... the upshot was this
889. # [20:58] <darobin> ... previous to that the shadow was not traversable from the outside, after it was
890. # [20:58] <darobin> ... we tentatively agreed that it made sense to provide both public and private modes, and even a more isolated mode
891. # [20:58] <darobin> ... I would really like it if at least the public and private mode could both be supported
892. # [20:58] <darobin> ... isolated mode has some design that needs to be investigates
893. # [20:59] <darobin> ... private might be the wrong name, give the impression of a security boundary, we could say open/closed
894. # [20:59] <darobin> ... I'd really like to address this before it's too late to make changes to how shadowRoots work
895. # [20:59] <darobin> ... what can I do to help move this forward?
896. # [20:59] <darobin> dglazkov: I totally want to do these modes
897. # [21:00] <darobin> ... because of the opacity of the style engine we don't have a great way of controlling this
898. # [21:00] <darobin> ... in JS it's easy
899. # [21:00] <darobin> ... but for styling we don't have a way to prevent this
900. # [21:00] <darobin> ... I udnerstand the need for it, I want to add it to the spec
901. # [21:00] <darobin> ... I can make it the next thing I work on
902. # [21:00] <dglazkov> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144
903. # [21:00] <krisk> s/udnerstand/understand/
904. # [21:01] <darobin> dglazkov: the way I thought I'd tackle this problem
905. # [21:01] <darobin> ... today you don't pass anythin when you create a shadow
906. # [21:01] <darobin> ... we could pass in a property bag
907. # [21:01] <darobin> ... I would suggest a string value so that we can add isolated later
908. # [21:01] * darobin damn
909. # [21:01] <darobin> s/... I would suggest/mjs: I would suggest/
910. # [21:02] <darobin> dglazkov: maybe we could close style separately
911. # [21:02] * Joins: hallvors (~hallvors@public.cloak)
912. # [21:02] <darobin> mjs: there are interesting side effects with querySelection then
913. # [21:02] <darobin> dglazkov: so it could be a single flag
914. # [21:02] <darobin> ... the ability to look inside is important because tools need introspection
915. # [21:03] <darobin> mjs: it doesn't make sense to do these separately (matching selectors, looking into the DOM)
916. # [21:03] <darobin> ... because you can use one to do the other
917. # [21:03] <darobin> dglazkov: I think that's reasonable
918. # [21:03] <darobin> mjs: if it's a string, we can add one later. Scales better than bag of booleans
919. # [21:04] <darobin> dglazkov: we have to prevent people to style into built-in element, so we have this mode
920. # [21:04] <darobin> ... to me it was literally a matter of getting to do this, got distracted
921. # [21:04] <darobin> ... I can start working on this
922. # [21:04] <darobin> mjs: I'm willing to offer help with reading, implementing, etc.
923. # [21:04] <darobin> ... I'm very interested in getting this in
924. # [21:05] <darobin> ... I thikn it's a fundamental building block for fully isolated components, which I think are a great use case
925. # [21:05] <darobin> dglazkov: I've also been looking at implementing all the HTML elements as custom elements
926. # [21:05] <darobin> ... so this is useful for that too
927. # [21:05] <hober> MikeSmith: I went to create a bug on the Shadow Styling spec, blocked on 20144, but there's no component for it in Bugzilla.
928. # [21:06] <darobin> rniwa: should we discuss which should be the default?
929. # [21:06] <darobin> [hilarity ensues]
930. # [21:06] <darobin> mjs: let's do the uncontroversial part first, debate later
931. # [21:06] <darobin> dglazkov: next?
932. # [21:07] <darobin> mjs: isolation?
933. # [21:07] <darobin> dglazkov: I would like insight
934. # [21:07] <darobin> mjs: one thing I noted in the bug
935. # [21:07] * MikeSmith hober will create a component now. What the's spec URL?
936. # [21:07] * rniwa could someone post the bug URL?
937. # [21:07] <darobin> ... there are 2 things you need, DOM encapsulation, and a walled-off scripting environment
938. # [21:07] <darobin> ... no global namespace, clean prototypes
939. # [21:08] <falken> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16509
940. # [21:08] <darobin> ... you also need sanitising paramters passed in and their return values from methods
941. # [21:08] <darobin> ... you need to rewrap DOM nodes across the boundary
942. # [21:08] <darobin> ... so you need Structured Clone Plus
943. # [21:08] <darobin> ... otherwise you can pass trapped values
944. # [21:08] <darobin> dglazkov: I think you're right.... eventually
945. # [21:09] * hober MikeSmith: http://www.w3.org/TR/css-scoping-1/
946. # [21:09] <darobin> mjs: if you want the page to be protected, you need a support mechanism other than script tag
947. # [21:09] <darobin> ... you need to run script safely
948. # [21:09] <darobin> ... XBL2 has a way of addressing things, you can import things
949. # [21:09] <darobin> ... pretty different from HTML Import which has script run in your context
950. # [21:10] <darobin> ... for safe imports you need a different mechanism
951. # [21:10] <darobin> dglazkov: there's a proposal for a DOMWorker
952. # [21:10] <darobin> ... a Worker that runs in your thread in step
953. # [21:10] <darobin> ... postMessaging only, can be loaded x-origin
954. # [21:10] <darobin> ... but once loaded is in its own worker
955. # [21:10] <darobin> mjs: can it export its registration?
956. # [21:10] <darobin> dglazkov: no, it works in its own shadow
957. # [21:11] <darobin> ... the worker manages the element
958. # [21:11] <darobin> ... the element acts from the outside as if it has a shadow tree but you can't get to it
959. # [21:11] <darobin> ... but from the inside it has a shadowRoot
960. # [21:11] <darobin> mjs: that seems insufficient
961. # [21:11] <darobin> ... you need to be able to register from the inside and sanitisation at the boundary
962. # [21:11] <darobin> slightlyoff: you can get that by reducing the surface area to attributes
963. # [21:12] <darobin> ... forward the attribute changes
964. # [21:12] <darobin> mjs: if your goal is to implement HTML this is not enough, elements need to expose APIs
965. # [21:12] * MikeSmith hober https://www.w3.org/Bugs/Public/enter_bug.cgi?product=CSS&component=CSS%20Scoping
966. # [21:12] <darobin> dglazkov: I feel that HTML elements don't need that
967. # [21:12] * hober MikeSmith: thanks!
968. # [21:12] <darobin> mjs: e.g. video and canvas are useless without APIs
969. # [21:12] * Quits: mjs (~mjs@public.cloak) (Ping timeout: 180 seconds)
970. # [21:13] <darobin> dglazkov: yes, but HTML does not need isolation
971. # [21:13] <darobin> ... isolation is collaboration between components that don't trust one another
972. # [21:13] <darobin> ... it seems to me the HTML elements model is different
973. # [21:13] <darobin> mjs: HTML elements certainly don't trust the page
974. # [21:13] <darobin> ... but I'm not sure that saves you a lot of complexity
975. # [21:14] <darobin> ... HTML element have a membrane where elements are sanitised, more than cloning since it supports DOM nodes and such
976. # [21:14] <darobin> dglazkov: you could define an IDL for contract
977. # [21:15] <darobin> rniwa: in a way yes, we can create a wrapper object for the prototype and function calls are forwarded after sanitisation
978. # [21:15] <darobin> mjs: in and out values get converted in the same way as they do for JS/C++ communication
979. # [21:15] <darobin> slightlyoff: only asynchronous?
980. # [21:15] <darobin> mjs: that's not powerful enough to implement HTML
981. # [21:16] <darobin> ... do we need to be able to do HTML, or is "like HTML but asynchronous" enough?
982. # [21:16] <darobin> dglazkov: I'd like to be able to implement HTML
983. # [21:16] <darobin> ... as an aspirational goal, though maybe not reached
984. # [21:16] <darobin> mjs: I think it's not impossible
985. # [21:16] <darobin> ... XBL had something that was powerful enough
986. # [21:16] <darobin> ... it's a question of what you're willing to give up
987. # [21:17] <darobin> ... if DOM Workers are already in the same thread, then you don't lose much by allowing sync methods
988. # [21:17] <darobin> ... it's important to be clear on whether something is an actual goal
989. # [21:17] <darobin> ... as a reviewer I need to know what the goals are
990. # [21:17] <darobin> dglazkov: so I think it's an actual goal
991. # [21:18] <darobin> ... is the [Like] button thing the same scenario
992. # [21:18] <darobin> ... as the built-in HTML elements
993. # [21:18] <darobin> mjs: the like widget case it needs communication with the communication case
994. # [21:18] <darobin> ... it would likely not be a dealbreaker to be limited to async and certain data type
995. # [21:19] <darobin> ... HTML elements need sanitisation on the way in
996. # [21:19] <darobin> ... returning values also, don't want anyone to violate my internal prototype
997. # [21:19] <darobin> ... the only thing that the like widget stuff doesn't need is sync communication
998. # [21:19] <darobin> ... so I think they're similar enough that you could use the same plumbing
999. # [21:20] <darobin> slightlyoff: we will probably have to rely on ES6 Proxies to define the membrane
1000. # [21:20] <darobin> rniwa: if we really want to make everything async, we could have the wrapper return a Promise, and resolve when the method returns
1001. # [21:20] <darobin> ... there are many ways to solve the issue
1002. # [21:20] <darobin> dglazkov: structure this goal as this
1003. # [21:21] <darobin> ... we at the limit want to implement all of the HTML elements in JS
1004. # [21:21] <darobin> ... similar widgets with trust issues are lower-fidelity subcases of the same
1005. # [21:21] <darobin> rniwa: I'm not sure I agree with this, there are some really funky HTLM elements, do you want to implement <custom-script>?
1006. # [21:22] <darobin> mjs: it's hard because either they'd have to be implemented in terms of existing elements or you'd need new primitives
1007. # [21:22] <darobin> ... also you don't want them to be able to change their parsing, e.g. reimplementing <table> or <script>
1008. # [21:23] <darobin> ... altering behaviour of the parser is beyond membranes
1009. # [21:23] <darobin> dglazkov: the reason you need these membranes is because inside of the element are capabilities you don't want to leak to the author
1010. # [21:23] <ArtB> q?
1011. # [21:24] * Zakim sees no one on the speaker queue
1012. # [21:24] <darobin> mjs: that's a security issue
1013. # [21:24] <darobin> ... but there's also a robustness issue where if you pass a bad value you don't want a component to barf all over itself
1014. # [21:24] <darobin> ... you need a membrane for that
1015. # [21:24] <darobin> dglazkov: I don't think this is a major point
1016. # [21:24] <darobin> ... I udnerstand what you're saying
1017. # [21:24] <darobin> ... agree 100% on the membrane idaes
1018. # [21:24] * Quits: plh (plehegar@public.cloak) ("Leaving")
1019. # [21:24] <darobin> ... I'm signing up to do this
1020. # [21:25] <krisk> s/idase/ideas/
1021. # [21:25] * darobin I don't think you corrected that krisk :)
1022. # [21:25] <rniwa> s/idaes/ideas/
1023. # [21:26] <darobin> mjs: we have to limit ourselves to createElement because the parser is funky, and we have to exclude some unsafe primitives like <input type=file>
1024. # [21:26] <darobin> s/udnerstand/understand/
1025. # [21:26] * hallvors says hello. Enjoy lunch. (RSN)
1026. # [21:26] * Parts: arunranga (~arunranga@public.cloak) (arunranga)
1027. # [21:26] <darobin> ... we need a more fleshed out spec for security review
1028. # [21:27] <darobin> slightlyoff: this sort of primitive allows for all sorts of attacks
1029. # [21:27] <darobin> mjs: there are some existing systems that take control of everything and try to sanitise everything
1030. # [21:27] <darobin> slightlyoff: our experience is that that's very brittle
1031. # [21:27] <darobin> mjs: I tend to be wary of things that are complex and need to be gotten exactly right
1032. # [21:28] <darobin> ... we can make the method membrane isomorphic to postMessage, using the method name as a string
1033. # [21:28] <darobin> ... so it's not necessarily a bigger surface than postMessage
1034. # [21:28] <darobin> [LUNCH]
1035. # [21:28] * Quits: Arrrno (~Arrrno@public.cloak) ("Page closed")
1036. # [21:29] * Quits: israelh (~israelh@public.cloak) ("Page closed")
1037. # [21:29] <ArtB> RRSAgent, make minutes
1038. # [21:29] <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/11-webapps-minutes.html ArtB
1039. # [21:29] <smaug> thanks all
1040. # [21:29] * smaug will be offline
1041. # [21:29] <Zakim> -smaug
1042. # [21:31] * Quits: Yves (ylafon@public.cloak) (Server going down)
1043. # [21:31] * Quits: jinsong (wjs@public.cloak) (Server going down)
1044. # [21:31] * Quits: darobin (rberjon@public.cloak) (public-irc.w3.org team-irc.w3.org)
1045. # [21:31] * Quits: xiaoqian (xiaoqian@public.cloak) (public-irc.w3.org team-irc.w3.org)
1046. # [21:31] * Quits: Zakim (zakim@public.cloak) (public-irc.w3.org team-irc.w3.org)
1047. # [21:31] * Quits: shepazu (schepers@public.cloak) (public-irc.w3.org team-irc.w3.org)
1048. # [21:31] * Quits: RRSAgent (rrsagent@public.cloak) (public-irc.w3.org team-irc.w3.org)
1049. # [21:31] * Quits: @trackbot (trackbot@public.cloak) (public-irc.w3.org team-irc.w3.org)
1050. # [21:32] * Quits: krisk (~krisk@public.cloak) (Ping timeout: 180 seconds)
1051. # [21:34] * Quits: zqzhang (~zqzhang@public.cloak) (Ping timeout: 180 seconds)
1052. # [21:34] * Quits: genelian_ (~genelian@public.cloak) (Ping timeout: 180 seconds)
1053. # [21:36] * Quits: kochi_w3c (~kochi_w3c@public.cloak) (Ping timeout: 180 seconds)
1054. # [21:36] * team-irc.w3.org sets mode: +sn
1055. # [21:36] * Joins: trackbot (trackbot@public.cloak)
1056. # [21:36] * Joins: darobin (rberjon@public.cloak)
1057. # [21:36] * team-irc.w3.org sets mode: +o darobin
1058. # [21:37] * Quits: KenjiBX (~KenjiBX@public.cloak) (Ping timeout: 180 seconds)
1059. # [21:39] * Joins: shepazu (schepers@public.cloak)
1060. # [21:46] * Quits: aizu (~aizu@public.cloak) (Ping timeout: 180 seconds)
1061. # [21:47] * Quits: marcosc (~marcosc@public.cloak) (Client closed connection)
1062. # [21:49] * Quits: smaug (~chatzilla@public.cloak) (Client closed connection)
1063. # [21:50] * Quits: @darobin (rberjon@public.cloak) (Client closed connection)
1064. # [22:04] * Joins: Yves (ylafon@public.cloak)
1065. # [22:04] * Joins: BenjamP_ (~BenjamP@public.cloak)
1066. # [22:05] * Joins: aizu (~aizu@public.cloak)
1067. # [22:06] * Joins: xiaoqian (xiaoqian@public.cloak)
1068. # [22:06] * Joins: krisk (~krisk@public.cloak)
1069. # [22:08] * Joins: sicking (~sicking@public.cloak)
1070. # [22:09] * rniwa sicking: hi sicking!
1071. # [22:09] * Joins: KenjiBX (~KenjiBX@public.cloak)
1072. # [22:09] <BenjamP_> topic: shadow dom
1073. # [22:09] <adrianba> scribe: BenjamP
1074. # [22:09] <sicking> rniwa: hey, sorry i didn't make it down today
1075. # [22:09] * Quits: BenjamP (~BenjamP@public.cloak) (Ping timeout: 180 seconds)
1076. # [22:10] <sicking> something came up
1077. # [22:10] <BenjamP_> dglazkov: let's spend time on imperative api
1078. # [22:10] * rniwa sicking: we're talking about imperative API for insertion points
1079. # [22:10] <sicking> rniwa: imperative API ++
1080. # [22:10] * Joins: KenjiBX_ (~KenjiBX@public.cloak)
1081. # [22:11] <dglazkov> https://gist.github.com/dglazkov/ce96f673b0b2ce7b8c55
1082. # [22:12] * Joins: jinsong (wjs@public.cloak)
1083. # [22:14] <BenjamP_> the following is based on the doc linked above- Distribution Callback section.
1084. # [22:14] <BenjamP_> dglazkov: we don't know when to run the callback
1085. # [22:14] * Yves bugzilla is up, rejoice!
1086. # [22:15] <BenjamP_> ... this has to do with how the box trees compose. Previously, we don't have to compute style until later, we can defer it. But problem is we have to run it the callback when you query the property.
1087. # [22:16] <BenjamP_> rniwa: I think it's worse
1088. # [22:16] * Quits: KenjiBX (~KenjiBX@public.cloak) (Ping timeout: 180 seconds)
1089. # [22:17] <BenjamP_> dglazkov: we have an array or add/remove methods. The array can be the filter. The problem is the author has to implement the distribution algorithm by hand. <details> has to set a mutation observer.
1090. # [22:17] * Quits: hallvors (~hallvors@public.cloak) (Ping timeout: 180 seconds)
1091. # [22:17] * Quits: KenjiBX_ (~KenjiBX@public.cloak) (Ping timeout: 180 seconds)
1092. # [22:18] <BenjamP_> ... another (bad) idea is selector-based routing. Insert children based on selector
1093. # [22:18] <dglazkov> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18429#c4
1094. # [22:19] <BenjamP_> ,,, this bug shows combination of passive array and selector-based rounting
1095. # [22:19] <BenjamP_> ... so 4 total ideas here. Looking for thoughts
1096. # [22:19] <BenjamP_> rniwa: let's have a list of candidates and notify author when it changes.
1097. # [22:21] <BenjamP_> dglazkov: we could get stuck in 2-resolution loop
1098. # [22:22] <BenjamP_> rniwa: not necessarily. Distribution doesn't need to be synchronous. We could instead compose at the end and notify all. It's okay because we won't paint during the micro-task
1099. # [22:23] <BenjamP_> dglaskov: we don't want it to return 0 because it hasn't rendered. [in steps], what is offset top? Would be zero. This gives ability to reason about what's happening when things are added to the DOM, and you'll see them later.
1100. # [22:24] <BenjamP_> ... author won't know if it has run or not
1101. # [22:24] <BenjamP_> rniwa: similar to custom elements unresolved state
1102. # [22:25] <BenjamP_> ...don't want to expose timing in engine. Synchronous costs perf, async we'll have times when things aren't up to date
1103. # [22:25] <BenjamP_> dglaskov: this doesn't matter for routing
1104. # [22:25] <BenjamP_> ... conceptual model is css
1105. # [22:26] <BenjamP_> ... run it at the end of micro-task. I don't think that's unreasonable. But let's make sure we not confusing users mental model
1106. # [22:27] <BenjamP_> rniwa: selector-based routing has an expensive query, doesn't address random element use case
1107. # [22:27] * Quits: trackbot (trackbot@public.cloak) (Client closed connection)
1108. # [22:27] * Quits: xiaoqian (xiaoqian@public.cloak) (Client closed connection)
1109. # [22:27] * Quits: jinsong (wjs@public.cloak) (Client closed connection)
1110. # [22:28] * Joins: xiaoqian (xiaoqian@public.cloak)
1111. # [22:28] <BenjamP_> dglaskov: random is solved by selectors. When you create a router you define random
1112. # [22:28] * Joins: trackbot (trackbot@public.cloak)
1113. # [22:28] <BenjamP_> rniwa: you have to listen to mutations of your children
1114. # [22:28] <BenjamP_> dglaskov: no you don't
1115. # [22:29] <BenjamP_> rniwa: inserting elements should not break the selection
1116. # [22:29] <BenjamP_> dglaskov: valid point
1117. # [22:30] <BenjamP_> ... you'll sometime have ocasional inconsistency with imperative. That's okay.
1118. # [22:30] <BenjamP_> ... style resolution after callback?
1119. # [22:31] <BenjamP_> ... you could trigger it, but it doesn't typically need to run before callback
1120. # [22:32] <BenjamP_> rniwa: there are times you want to stay in sync and have them happen at the same time
1121. # [22:33] * Parts: jmajnert (~jmajnert@public.cloak)
1122. # [22:33] <BenjamP_> dglaskov: insertion point needs an onDistrobution event
1123. # [22:34] <BenjamP_> rniwa: I agree it's weird to get wrong offsetTop, but our options are limited
1124. # [22:35] <BenjamP_> hayato: it's a tough issue
1125. # [22:35] * Quits: sicking (~sicking@public.cloak) (sicking)
1126. # [22:35] <BenjamP_> dglaskov: if you choose imperative, it may be difficult, but that's ok
1127. # [22:36] <BenjamP_> ... not sure if this is a problem in real life
1128. # [22:36] <BenjamP_> ArtB: something about potatoes
1129. # [22:36] * Yves post-prandial silence
1130. # [22:36] <krisk> +Bacon please
1131. # [22:37] <ArtB> s/something about potatoes/carbos for lunch syndrome/
1132. # [22:37] <BenjamP_> topic: imports
1133. # [22:37] <dglazkov> https://gist.github.com/omo/9986103
1134. # [22:37] <BenjamP_> dglaskov: let's talk about blocking rendering
1135. # [22:37] * Joins: sicking (~sicking@public.cloak)
1136. # [22:38] * Quits: skddc (~anonymous@public.cloak) (Ping timeout: 180 seconds)
1137. # [22:38] <ArtB> https://gist.github.com/omo/9986103 -> HTML Imports: Discussion over Async/Progressive Loading
1138. # [22:38] <BenjamP_> ... imports are modeled after stylesheets
1139. # [22:38] * Joins: alia (~alia@public.cloak)
1140. # [22:39] <BenjamP_> ... trying to enable asynchronous loading, but sometimes we have to block
1141. # [22:40] <BenjamP_> ... if you have a script block in you doc, your loading imports will be sync with script.
1142. # [22:41] <BenjamP_> ... without <script> it will load in parallel, and will then block on paint
1143. # [22:41] <BenjamP_> Alex: this is not a rule
1144. # [22:41] <BenjamP_> dglaskov: right, but everyone does this
1145. # [22:41] <slightlyoff> BenjamP_: s/dglaskov/dglazkov/
1146. # [22:42] <BenjamP_> dglazkov: *pounds fist*
1147. # [22:42] * ArtB t-shirt: The Web Will be Aysnc or Dead!
1148. # [22:43] <BenjamP_> dglazkov: async loading makes other elements change. We've only had sync loading until now, so we didn't see this
1149. # [22:44] * Joins: jinsong (wjs@public.cloak)
1150. # [22:44] <BenjamP_> ... example: twitter doesn't want to block. So we invented async
1151. # [22:44] <BenjamP_> ... still some disagree about default sync/async
1152. # [22:45] <BenjamP_> Alex: speaking for pro-async. Agree that there are 2 different types of users- own the whole page or don't
1153. # [22:46] <BenjamP_> ... even for not-own-whole-page: makes sense to enable doc fade-in. What does it take to achieve? With sync/async: you have little control so you write your own staging code. Works around sync/async order
1154. # [22:46] <BenjamP_> rniwa: what are you ordering?
1155. # [22:48] <BenjamP_> Alex: if building an app: need to pull in code, elements, etc, have an early moment when I want to control (inline script), then pull in dependencies (async). Should we paint early while it's loading, and then paint again when all is available?
1156. # [22:48] <BenjamP_> ... if you're small part of the doc, you want to be able to say when you're ready and provide a placeholder
1157. # [22:48] <BenjamP_> rniwa: 3 state: unresolved, resolved, final
1158. # [22:48] <BenjamP_> ... which part are you talking about?
1159. # [22:48] <BenjamP_> Alex: they're all related
1160. # [22:49] <BenjamP_> ... blocking causes you to have to choose what you are targeting
1161. # [22:50] <slightlyoff> e.g., how would you reason about a hierarchy of things that all need resolution? As Jake Archibald phrases it, the "deeply resolved question"
1162. # [22:51] <BenjamP_> dglazkov: example- if I'm a framework, you have to load basic concepts quickly and do first paint (loading screen?). Then do more things because I've notified the users I'm getting ready. With HTML imports you have 1 sync import that does the quick first paint.
1163. # [22:51] <BenjamP_> ... I want to allow developers to draw a line and say "i want to paint here". Everyone has a 2 phase approach
1164. # [22:51] <BenjamP_> rniwa: this isn't unique to imports
1165. # [22:51] <slightlyoff> one way to think about this is trying to provide explicit API for defining resolution
1166. # [22:52] <BenjamP_> dglazkov: the problem is that they have to fall off the html train right away
1167. # [22:52] <BenjamP_> ... let's think abou this. we won' t solve it here
1168. # [22:53] <BenjamP_> Alex: we're missing a primitve, We want to define resolution. sync/async allow us to create 2 moments- now and later. You're now missing the ability to describe what happens when you get to the resolution
1169. # [22:53] <BenjamP_> rniwa: waiting is a special case; normal state is the final state.
1170. # [22:53] * Joins: KenjiBX (~KenjiBX@public.cloak)
1171. # [22:54] <BenjamP_> Alex: there is a final moment that we should be able to reason about in the code. We don't have resolved/unresolved except for custom elements.
1172. # [22:54] <BenjamP_> ... we don't have a way to talk about dependencies
1173. # [22:55] <BenjamP_> rniwa: if you implement a custom image element, the browser can't reason about when it's ready
1174. # [22:55] <BenjamP_> ... maybe we should load a pseudo element?
1175. # [22:55] <BenjamP_> dglazkov: I'm fine letting developers solve this first and learn from it
1176. # [22:56] <BenjamP_> Alex: decision at first paint needs developer control. Should be able to delay paint until dev is ready
1177. # [22:56] * Joins: lmcliste_ (~lmclister@public.cloak)
1178. # [22:57] * Joins: esprehn (~sid10445@public.cloak)
1179. # [22:57] * Quits: lmclister (~lmclister@public.cloak) (Ping timeout: 180 seconds)
1180. # [22:57] <dglazkov> esprehn!!!
1181. # [22:57] * Yves zakim, code?
1182. # [22:57] * Joins: Zakim (zakim@public.cloak)
1183. # [22:57] * Yves zakim, this is webapps
1184. # [22:57] * Zakim ok, Yves; that matches IA_WebApps()12:00PM
1185. # [22:57] <esprehn> dglazkov: :)
1186. # [22:58] * Yves zakim, who is here?
1187. # [22:58] * Zakim sees on the phone: anssik, [Paypal]
1188. # [22:58] * Zakim sees on irc: esprehn, lmcliste_, KenjiBX, jinsong, alia, sicking, trackbot, xiaoqian, krisk, aizu, BenjamP_, Yves, shepazu, MikeSmith, ed, Hixie, logbot, schuki, heycam|away,
1189. # [22:58] * Zakim ... gsnedders, decadance, jgraham, tzik, gavin, pdr, Domenic_, falken, hober, tyoshino, krit, cabanier__, dglazkov, dcooney, jsbell, scheib__, timeless_, cwilso, dfreedm_,
1190. # [22:58] * Zakim ... slightlyoff, morrita, tobie__, krijnhoetmer, paul___irish, kochi, hayato, astearns, stryx`_, anssik, ArtB, john_hazen, adrianba, dksmith, opoto, jungkees, Travis, tantek,
1191. # [22:58] * Zakim ... jsbell_
1192. # [22:58] * Yves zakim, code?
1193. # [22:58] * Zakim doesn't yet know the conference code
1194. # [22:58] <ArtB> +1.617.761.6200 ; PIN = 9274#
1195. # [22:58] <slightlyoff> scribenick slightlyoff
1196. # [22:59] <BenjamP_> rrsagent,generate minutes
1197. # [22:59] <slightlyoff> dglazkov: I forgot something about imports...will need to bring it up on the list
1198. # [23:00] * adrianba did we lose rrsagent?
1199. # [23:00] <slightlyoff> (discussion about next topic, perhaps inheritance)
1200. # [23:00] * Joins: RRSAgent (rrsagent@public.cloak)
1201. # [23:00] <RRSAgent> logging to http://www.w3.org/2014/04/11-webapps-irc
1202. # [23:00] <Zakim> -anssik
1203. # [23:00] * Yves oops!
1204. # [23:01] <Zakim> + +1.301.460.aaaa
1205. # [23:01] <xiaoqian> rrsagent, make minutes
1206. # [23:01] <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/11-webapps-minutes.html xiaoqian
1207. # [23:01] * Yves do someone have a log since... when we came back from lunch?
1208. # [23:01] <slightlyoff> rniwa: one problem we found with the current inheritance model is that if you have an element, say a <random-> element, if you have a subclass that wants to use a different distribution...the <random-> element wants to show the name it's subclassed distribution
1209. # [23:01] <slightlyoff> rniwa: you don't have a way to add an insertion point in shadow DOM that's only available in the subclasses
1210. # [23:01] * xiaoqian oops
1211. # [23:01] <krisk> * looks like no logs since after lunch...
1212. # [23:02] <slightlyoff> rniwa: if I have some bit of content that needs to be transcluded in the shadow dom to the subclass from the parent class, how do you do that?
1213. # [23:02] <slightlyoff> dglazkov: you have all the tools....
1214. # [23:02] <slightlyoff> rniwa: how do I set an insertion point that's only for the subclass?
1215. # [23:02] * Yves rrsagent, this meeting span midnight
1216. # [23:02] <RRSAgent> I'm logging. I don't understand 'this meeting span midnight', Yves. Try /msg RRSAgent help
1217. # [23:02] <slightlyoff> dglazkov: that will be coming from the light dom?
1218. # [23:02] <slightlyoff> rniwa: no, it's coming from the subclass
1219. # [23:02] * Yves rrsagent, do not start a new log
1220. # [23:02] <RRSAgent> ok, Yves; I will not start a new log at midnight
1221. # [23:03] * Yves rrsagent, make log public
1222. # [23:03] * RRSAgent I have made the request, Yves
1223. # [23:03] <slightlyoff> rniwa: the way to do it today is to replace the entire shadow dom and place your own things inside it
1224. # [23:03] * ArtB Yves - did the RRSAgent log get truncated?
1225. # [23:03] <ArtB> RRSAgent, make minutes
1226. # [23:03] <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/11-webapps-minutes.html ArtB
1227. # [23:03] <slightlyoff> dglazkov: yes, you have to make sure that your concrete subclasses aren't of other concrete classes
1228. # [23:03] * Yves yeah, we lost from lunch to... now :/ I can reconstruct if someone has a log, then regen the minutes
1229. # [23:04] <slightlyoff> rniwa: even if you use an abstract class, the selectors that might match aren't constrained
1230. # [23:05] <krisk> * I can send you a text file, what is your email yves?
1231. # [23:05] * Yves yves@w3.org
1232. # [23:06] * Yves thx!
1233. # [23:06] <slightlyoff> rniwa: if you have a <uniformally-random> element and a <gaussian-random> element, and the superclass has a distributionName, you can't make sure that you only handle the property in the shadow dom of hte subclass, not the parent class
1234. # [23:06] * adrianba here is a log since lunch: http://pages.adrianba.net/w3c/public-webapps-2014-04-11.txt
1235. # [23:06] <slightlyoff> (esphren joins)
1236. # [23:06] <slightlyoff> dglazkov: (revisiting distribution question since we have esphren)
1237. # [23:07] * Yves thx all, will fix once the meeting is over
1238. # [23:07] <slightlyoff> esprehn: my issue with the delayed distribution is that it doesn't describe what <details> does
1239. # [23:07] <slightlyoff> esprehn: today if you append to it and then query offsetTop, we'll give you answer immediately
1240. # [23:08] <slightlyoff> esprehn: we only do this at recalc-style time
1241. # [23:08] <slightlyoff> slightlyoff: we have a "takeRecords()" in O.o and Mutation Observer,s why istn't that model workable here?
1242. # [23:09] <slightlyoff> esprehn: we don't have a defined time in the platform for this
1243. # [23:09] <slightlyoff> slightlyoff: so we're missing an API for this kicking off callbacks?
1244. # [23:09] <slightlyoff> dglazkov: so appendChild() is when thigns become real
1245. # [23:10] <slightlyoff> esprehn: we'd need to make sure that children of the <details> element don't have layout information until rAF time
1246. # [23:11] <slightlyoff> esprehn: we have a strong guarantee about shadow roots being unobservable, which isn't true today, and we'd be making it observable
1247. # [23:11] <slightlyoff> esprehn: if we allow scripts to do arbitrary things, we need to define a time for it
1248. # [23:11] <slightlyoff> slightlyoff: are those things (offsetTop, etc.) bugs or features?
1249. # [23:12] <slightlyoff> esprehn: I'd like to make sure that <details> isn't magical
1250. # [23:12] <slightlyoff> slightlyoff: agreed
1251. # [23:12] <Zakim> - +1.301.460.aaaa
1252. # [23:12] * Quits: sicking (~sicking@public.cloak) (Ping timeout: 180 seconds)
1253. # [23:12] <slightlyoff> (discussions of topics and group stamina)
1254. # [23:13] <esprehn> sorry I have to run, but I'm happy to discuss further in the future
1255. # [23:14] <slightlyoff> dglazkov: next issue: 3 quick bugs
1256. # [23:15] <slightlyoff> dglazkov: in my opinion, all of the import documents should be forced to be UTF-8
1257. # [23:15] <slightlyoff> dglazkov: we don't have the usual issues around legacy, so we'll just assume UTF-8...what say we?
1258. # [23:15] <ArtB> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21275 -> [Imports]: Force utf-8
1259. # [23:15] <slightlyoff> dglazkov: developers get unhappy about needing to include explicit including
1260. # [23:15] <slightlyoff> s/including/encoding
1261. # [23:16] <slightlyoff> (charset meta)
1262. # [23:16] <slightlyoff> dglazkov: we'd like to be able to assume UTF8
1263. # [23:16] <slightlyoff> MikeSmith: we're going to fallback to windows 1252 if you don't specify something else, which is wrong
1264. # [23:16] * Joins: sicking_ (~sicking@public.cloak)
1265. # [23:16] <slightlyoff> hober: it's a bit weird because it's inconsistent, and the existing behavior isn't something we like...I can see this going either way
1266. # [23:17] <slightlyoff> rniwa: what about XHR?
1267. # [23:17] <slightlyoff> rniwa: matching behavior with XHR might be good. If this is truly odball, it might be confusing
1268. # [23:18] * Quits: alia (~alia@public.cloak) (Ping timeout: 180 seconds)
1269. # [23:18] <slightlyoff> dglazkov: (quotes annevk): "UTF8 should be used for anything new"
1270. # [23:18] <slightlyoff> (HTML, a celebration of inconsistencies)
1271. # [23:18] <slightlyoff> hober, MikeSmith: no objection in the room
1272. # [23:19] <ArtB> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24349 -> [imports]: Import documents should always be in no-quirks mode
1273. # [23:19] <slightlyoff> rniwa: I'm not sure I'd object
1274. # [23:19] <slightlyoff> hober: webvtt is already always UTF8
1275. # [23:19] <slightlyoff> adrianba: it's not HTML
1276. # [23:19] <slightlyoff> MikeSmith: I'd recommend that if you feel strongly, participate in the bug
1277. # [23:20] <slightlyoff> slightlyoff: (looking at bug history) when will this be resolved?
1278. # [23:20] <slightlyoff> dglazkov: next topic: import documents should always be in no-quirks-mode
1279. # [23:20] <slightlyoff> (not exactly resolved, 'because we can't do that)
1280. # [23:21] <slightlyoff> dglazkov: next topic: blocking DOMContentLoaded while imports load
1281. # [23:21] <ArtB> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23526 -> [imports]: blocking DOMContentLoaded while HTML imports are loaded
1282. # [23:21] <slightlyoff> morrita: not sure about the context either...
1283. # [23:21] <slightlyoff> morrita: some folks are using this event without waiting for things like <img>
1284. # [23:22] <slightlyoff> morrita: there's no event that's similar to imports already
1285. # [23:22] <slightlyoff> rniwa: presumably this is only for the sync case?
1286. # [23:22] <slightlyoff> morrita: yes
1287. # [23:22] <slightlyoff> dglazkov: I only got context on this recently and I don't know...do we need a new event?
1288. # [23:23] <slightlyoff> slightlyoff: don't want to design a feature here, but I can see both cases
1289. # [23:23] <slightlyoff> rniwa: <script defer> does block DOMCOntentLoaded
1290. # [23:23] <slightlyoff> rniwa: this is similar to that
1291. # [23:24] <slightlyoff> rniwa: in that sense, blocking it on imports seems right in the sync case
1292. # [23:24] <slightlyoff> (starting gun fires)
1293. # [23:25] <slightlyoff> ArtB: thanks to dglazkov for taking the time
1294. # [23:25] <slightlyoff> dglazkov: I'll be getting back to spec work shortly, thank you
1295. # [23:25] <slightlyoff> thanks to Brad Hill for hosting
1296. # [23:25] <slightlyoff> (applause)
1297. # [23:25] <slightlyoff> Topic: conclusion
1298. # [23:26] * Quits: adrianba (~adrianba@public.cloak) ("Page closed")
1299. # [23:26] * Quits: aizu (~aizu@public.cloak) ("Page closed")
1300. # [23:26] <MikeSmith> yeah much thanks to Brad and to PayPal for hosting
1301. # [23:26] <MikeSmith> RRSAgent, make minutes
1302. # [23:26] <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/11-webapps-minutes.html MikeSmith
1303. # [23:27] * Quits: opoto (~opoto@public.cloak) ("http://www.kiwiirc.com/ - A hand crafted IRC client")
1304. # [23:27] * Parts: BenjamP_ (~BenjamP@public.cloak)
1305. # [23:28] * Quits: ArtB (~abarsto@public.cloak) ("Leaving.")
1306. # [23:29] * Quits: john_hazen (~john_hazen@public.cloak) (Ping timeout: 180 seconds)
1307. # [23:30] * Quits: rniwa (~rniwa@public.cloak) (Ping timeout: 180 seconds)
1308. # [23:31] <Zakim> -[Paypal]
1309. # [23:31] <Zakim> IA_WebApps()12:00PM has ended
1310. # [23:31] <Zakim> Attendees were anssik, [Paypal], +1.301.460.aaaa
1311. # [23:32] * Quits: krisk (~krisk@public.cloak) (Ping timeout: 180 seconds)
1312. # [23:33] * Quits: dksmith (~dksmith@public.cloak) (Ping timeout: 180 seconds)
1313. # [23:35] * Quits: jinsong (wjs@public.cloak) (Ping timeout: 180 seconds)
1314. # [23:39] * Quits: KenjiBX (~KenjiBX@public.cloak) (Ping timeout: 180 seconds)
1315. # [23:46] * Quits: sicking_ (~sicking@public.cloak) (sicking_)
1316. # [23:47] * Quits: tantek (~tantek@public.cloak) (tantek)
1317. # [23:49] * Quits: xiaoqian (xiaoqian@public.cloak) (Ping timeout: 180 seconds)
1318. # Session Close: Sat Apr 12 00:00:00 2014

The end :)