/irc-logs / w3c / #webapps / 2015-04-25 / end

Options:

Previous day, Next day

1. # Session Start: Sat Apr 25 00:00:00 2015
2. # Session Ident: #webapps
3. # [00:00] <chaals> agrnda?
4. # [00:00] <chaals> agenda?
5. # [00:00] * Zakim sees 3 items remaining on the agenda:
6. # [00:00] * Zakim 4. Jan…'s proposal for named thingo [from chaals]
7. # [00:00] * Zakim 6. details of imperative distribution API, don't make it impossible. [from chaals]
8. # [00:00] * Zakim 8. styling [from chaals]
9. # [00:01] <chaals> s/agrnda?//
10. # [00:01] * Joins: weinig (~weinig@public.cloak)
11. # [00:01] * Quits: sorvell (~sorvell@public.cloak) ("Page closed")
12. # [00:01] * Joins: sorvell (~sorvell@public.cloak)
13. # [00:01] <taylor> Back!
14. # [00:01] <taylor> DG: Following an exciting discussion on the slots proposal, we have a couple options
15. # [00:02] <taylor> DG: Would like to separate the issue: is it just aesthetics, or does it really bring concrete perf gains that allow us to do distributions in near-constant time?
16. # [00:02] <taylor> DG: Which opens up the opportunity for very simple imperative API
17. # [00:02] <chaals> q+ anne
18. # [00:02] * Zakim sees rniwa, chaals, anne on the speaker queue
19. # [00:02] <chaals> q-
20. # [00:02] * Zakim sees rniwa, anne on the speaker queue
21. # [00:02] <chaals> q- rn
22. # [00:02] * Zakim sees anne on the speaker queue
23. # [00:02] <taylor> DG: Options:
24. # [00:02] <taylor> DG: 1. don't do imperative API in v1 and go with content select
25. # [00:02] * ebryn -1 for content select
26. # [00:02] <taylor> DG: 2. Don't do imperative API and go with slots
27. # [00:03] <taylor> DG: 3. Imperative API and one of the other proposals
28. # [00:03] <sorvell> q+
29. # [00:03] * Zakim sees anne, sorvell on the speaker queue
30. # [00:03] <taylor> DG: (imperative and declarative as part of v1)
31. # [00:03] * ebryn +1 imperative API as part of v1
32. # [00:03] <taylor> DG: Needs to be time to fully put slots proposal through their paces and exercise it mentally
33. # [00:03] * chaals suggests ebryn put that as [+1 to …] not in a /me, so it gets into the minutes
34. # [00:03] * Joins: shepazu (schepers@public.cloak)
35. # [00:04] <ebryn> +1 to imperative API as part of v1
36. # [00:04] <taylor> DG: propose we nominate people to do due diligence and bring it to a concrete proposal
37. # [00:04] <taylor> DG: s/propose/4/
38. # [00:04] <taylor> JM: Could do enough design work on imperative API that we have a good answer, but do it later
39. # [00:05] <taylor> DG: Should be a prerequisite for 1. or 2.
40. # [00:05] <chaals> ack an
41. # [00:05] * Zakim sees sorvell on the speaker queue
42. # [00:05] <rniwa> +q
43. # [00:05] * Zakim sees sorvell, rniwa on the speaker queue
44. # [00:05] <mjs> q?
45. # [00:05] * Zakim sees sorvell, rniwa on the speaker queue
46. # [00:06] <taylor> AvK: If you get hold of a node inside shadow tree and dispatch the event, you can observe on the path what the distribution is
47. # [00:06] <taylor> AvK: This will very synchronously require you to do this synchronously
48. # [00:06] * rniwa seems to have 30,000 SVG nodes in his graph component...
49. # [00:06] <taylor> DG: Yes, this is correct
50. # [00:06] <chaals> ack sor
51. # [00:06] * Zakim sees rniwa on the speaker queue
52. # [00:06] * rniwa imagine running O(n) algorithm on that...
53. # [00:07] <taylor> SO: Want to emphasize that the slot proposal is incomplete. When you just have one name, this is unacceptable for reprojection
54. # [00:07] * rniwa wants DOM to be stupid fast, not kind-of-fast
55. # [00:07] <taylor> SO: Slot needs to be studied more and fleshed out
56. # [00:07] <taylor> RN: Qualify that imperative API is important
57. # [00:07] <chaals> q+
58. # [00:07] * Zakim sees rniwa, chaals on the speaker queue
59. # [00:07] <chaals> ack rn
60. # [00:07] * Zakim sees chaals on the speaker queue
61. # [00:07] <taylor> RN: Another option - no node distribution in v1
62. # [00:07] <taylor> RN: Worst case scenario
63. # [00:07] <taylor> RN: Timing of distribution is very important
64. # [00:08] <taylor> RN: Maybe it is better to focus on imperative API. Then each framework could emulate either syntax to figure out best declarative syntax.
65. # [00:09] <taylor> CMN: is there anyone that would be happy without any distribution
66. # [00:09] <taylor> [basically everyone]
67. # [00:09] <taylor> RESOLUTION: We need distribution of some sort in v1
68. # [00:09] <taylor> CMN: Is there anyone who can't live with starting at imperative API?
69. # [00:10] <taylor> CMN: Is there anyone opposed to starting out with an imperative API?
70. # [00:10] <taylor> [murmuring]
71. # [00:10] <taylor> CMN: Everyone wants an imperative API. Everyone wants distribution.
72. # [00:10] <taylor> CMN: Is there anyone that thinks they need to start by figuring out a declarative API?
73. # [00:11] <taylor> DG: Seems like we have enough difference of opinion in declarative API, the next step is we need to talk about the imperative API
74. # [00:11] <taylor> SO: We want this thing to ship.
75. # [00:11] <rniwa> +q
76. # [00:11] * Zakim sees chaals, rniwa on the speaker queue
77. # [00:11] <chaals> q+
78. # [00:11] * Zakim sees chaals, rniwa on the speaker queue
79. # [00:11] <chaals> q- later
80. # [00:11] * Zakim sees rniwa, chaals on the speaker queue
81. # [00:11] <taylor> SO: We have a declarative API, we don't have an imperative API
82. # [00:12] <hober> q?
83. # [00:12] * Zakim sees rniwa, chaals on the speaker queue
84. # [00:12] <chaals> ack rn
85. # [00:12] * Zakim sees chaals on the speaker queue
86. # [00:12] <taylor> RN: Imperative API got shot down because it wasn't compatible with content select
87. # [00:12] <taylor> RN: From imperative, we can start implementing
88. # [00:12] <taylor> RN: We can have more evidence from there as to what the right declarative syntax is
89. # [00:13] <taylor> RN: We need to start from things we can agree on
90. # [00:13] <taylor> CMN: Who cannot live with select api?
91. # [00:14] <taylor> CMN: Who cannot live with slots?
92. # [00:14] <taylor> [some for each]
93. # [00:14] * Quits: shepazu (schepers@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
94. # [00:14] <taylor> CMN: Need to come back after working on proposals
95. # [00:14] * Joins: shepazu (schepers@public.cloak)
96. # [00:14] <taylor> CMN: For now, we're trying to see if we can get to imperative API
97. # [00:14] <dglazkov> Zakim, agend
98. # [00:14] <Zakim> I don't understand 'agend', dglazkov
99. # [00:14] <taylor> CMN: So what does the imperative API look like again?
100. # [00:14] <dglazkov> Zakim, agenda
101. # [00:14] <Zakim> I don't understand 'agenda', dglazkov
102. # [00:15] <chaals> agenda?
103. # [00:15] * Zakim sees 3 items remaining on the agenda:
104. # [00:15] * Zakim 4. Jan…'s proposal for named thingo [from chaals]
105. # [00:15] * Zakim 6. details of imperative distribution API, don't make it impossible. [from chaals]
106. # [00:15] * Zakim 8. styling [from chaals]
107. # [00:15] <taylor> SM: Curious if the people at the whiteboard could say if imperative API will nerf our performance?
108. # [00:15] <dglazkov> agenda?
109. # [00:15] * Zakim sees 3 items remaining on the agenda:
110. # [00:15] * Zakim 4. Jan…'s proposal for named thingo [from chaals]
111. # [00:15] * Zakim 6. details of imperative distribution API, don't make it impossible. [from chaals]
112. # [00:15] * Zakim 8. styling [from chaals]
113. # [00:15] <smaug> rniwa: do you have a link to the old imperative API proposal
114. # [00:15] * Quits: shepazu (schepers@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
115. # [00:15] <taylor> RN: If API's that call back to JS any time any dom was modified in light dom, not acceptable
116. # [00:15] <taylor> RN: If we did it at end of microtask, like MO, perf impact is much smaller
117. # [00:16] <taylor> AvK: The only observable thing is that synchronous layout getters don't work
118. # [00:17] <taylor> JF: Isn't breaking the habit on layout forcing habits a bandaid we need to rip off at some point?
119. # [00:17] <dglazkov> q+
120. # [00:17] * Zakim sees chaals, dglazkov on the speaker queue
121. # [00:17] <chaals> ack ch
122. # [00:17] * Zakim sees dglazkov on the speaker queue
123. # [00:17] <chaals> ack dg
124. # [00:17] * Zakim sees no one on the speaker queue
125. # [00:17] <taylor> JF: Need to recognize that exploring this path might not be successful
126. # [00:18] <rniwa> my proposal for imperative API: https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0376.html
127. # [00:18] <rniwa> +q
128. # [00:18] * Zakim sees rniwa on the speaker queue
129. # [00:18] <taylor> Domenic: reportValidity, scrollIntoView - isn't it OK if we delay this a microtask
130. # [00:18] <taylor> DG: No, not ok. This is how developers have been using this.
131. # [00:19] <chaals> ack rn
132. # [00:19] * Zakim sees no one on the speaker queue
133. # [00:19] <taylor> RN: Link to proposal: https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0376.html
134. # [00:19] * Joins: Travis (~Travis@public.cloak)
135. # [00:20] <taylor> RN: add and remove to content element (names can change), will take new element in a light dom that gets distributed to insertion point
136. # [00:20] <taylor> RN: Just does exactly one time distribution
137. # [00:20] <mjs> q?
138. # [00:20] * Zakim sees no one on the speaker queue
139. # [00:20] <mjs> q+
140. # [00:20] * Zakim sees mjs on the speaker queue
141. # [00:20] <taylor> RN: You would use mutation observers to update distributed nodes
142. # [00:20] <sorvell> q+
143. # [00:20] * Zakim sees mjs, sorvell on the speaker queue
144. # [00:20] <taylor> RN: Most primitive API could come up with
145. # [00:21] <taylor> DG: This would work if we said "If you decide to use this API, you're on your own, you have to figure this out."
146. # [00:21] <taylor> RN: Drawback - you can't really reorder nodes inside insertion point
147. # [00:21] <taylor> RN: Need array potentially to add and manipulate from arbitrary points
148. # [00:21] <taylor> RN: Everything is synchronous
149. # [00:22] <taylor> AvK: Component author would write mutation observers, they'd have to wait for the MO's to fire before nodes get distributed again
150. # [00:22] <taylor> RN: Also lifecycle callback in CE about children being changed
151. # [00:22] <taylor> RN: Maybe could update nodes when we exit C++ code of node being added
152. # [00:23] <taylor> DG: Reprojection would be done by hand
153. # [00:23] * Zakim taylor, you typed too many words without commas; I suspect you forgot to start with 'to ...'
154. # [00:23] <taylor> MJS: What's tricky is timing
155. # [00:24] <taylor> MJS: Hard to tell in abstract whether next microtask is good enough, as opposed to current style resolution timing
156. # [00:24] <chaals> [straw poll - how many people ok with this idea so far - more, how many terrified so far - some]
157. # [00:24] <taylor> MJS: Style resolution timing is imprecise too
158. # [00:24] <taylor> MJS: Might require someone to try implementing it to see if in practice it is bad
159. # [00:25] <chaals> ack mj
160. # [00:25] * Zakim sees sorvell on the speaker queue
161. # [00:25] <taylor> DG: Sounds like a task force
162. # [00:25] * Joins: philipwalton (~philipwalton@public.cloak)
163. # [00:25] <taylor> SO: If we have RN's proposal that distribution is synchronous, I would say MO information is not sufficient to do reprojection
164. # [00:25] <Domenic_> It would be good to have examples of existing use cases to show that this would suffice for them and how it would be coded.
165. # [00:25] <taylor> SO: Would hope we could add information about distributed nodes changed to MO
166. # [00:25] <chaals> s/ MO /mutation observer
167. # [00:26] <chaals> s/to MO/to mutation observer
168. # [00:26] <taylor> SO: We're opening up the door for: Polymer could create a flush mechanism; all the mutation observers take records
169. # [00:26] <taylor> SO: not a good signal on way to do redistribution with the information that mutation observers surface currently
170. # [00:26] <slightlyoff> q?
171. # [00:26] * Zakim sees sorvell on the speaker queue
172. # [00:26] <slightlyoff> q+
173. # [00:26] * Zakim sees sorvell, slightlyoff on the speaker queue
174. # [00:27] <rniwa> q+
175. # [00:27] * Zakim sees sorvell, slightlyoff, rniwa on the speaker queue
176. # [00:27] * chaals thinks the weScrewedAbootHere event might be hard to type
177. # [00:27] <chaals> ack sor
178. # [00:27] * Zakim sees slightlyoff, rniwa on the speaker queue
179. # [00:27] <chaals> ack sli
180. # [00:27] * Zakim sees rniwa on the speaker queue
181. # [00:27] <taylor> AR: question of imperative-only seems at odds that there's a large simplification to be had with naming slots
182. # [00:27] <taylor> AR: degrees of freedom continue to accelerate as you go toward imperative
183. # [00:27] * ebryn recalls this being something the polymer team was advocating for
184. # [00:27] <taylor> AR: Could look at properties, for example
185. # [00:28] <taylor> AR: Thinks we should definitely have imperative API's in the platform
186. # [00:28] <sorvell> q+ Scott
187. # [00:28] * Zakim sees rniwa, Scott on the speaker queue
188. # [00:28] <chaals> [+1 to Alex' concern…]
189. # [00:28] <taylor> AR: Worries this will hurt inter-framework interoperability quite a lot
190. # [00:28] <ebryn> +1 to alex
191. # [00:28] <chaals> ack rn
192. # [00:28] * Zakim sees Scott on the speaker queue
193. # [00:28] <taylor> RN: Can add synchronous event or new record to mutation observer.
194. # [00:29] <Domenic_> q+
195. # [00:29] * Zakim sees Scott, Domenic_ on the speaker queue
196. # [00:29] <chaals> ack sc
197. # [00:29] * Zakim sees Domenic_ on the speaker queue
198. # [00:29] <taylor> SM: First version of Polymer had a lot of asynchronous behaviors - horrible for end-users
199. # [00:30] <taylor> SM: Nervous about any change where the user doesn't know "can I talk to this node now?" will cause lots of user confusion
200. # [00:30] <chaals> ack dom
201. # [00:30] * Zakim sees no one on the speaker queue
202. # [00:30] <taylor> SM: Cautionary tale about asynchrony as it impacts end-users
203. # [00:30] <taylor> Domenic: Would really like to see all of the existing use-cases showing how you would write this. With Polymer elements, for select and option, and details and summary.
204. # [00:30] <taylor> Domenic: Want to see that it addresses all the use-cases that selectors do and perhaps more complicated things
205. # [00:31] <taylor> Domenic: a childrenChanged callback would make it nicer, synchronousish
206. # [00:31] <taylor> Domenic; Should be able to build something at least as powerful as current select API
207. # [00:31] <taylor> EB: Don' think we should have to do this
208. # [00:32] <taylor> Domenic: You should be able to build anything with the imperative API
209. # [00:32] <dglazkov> q+
210. # [00:32] * Zakim sees dglazkov on the speaker queue
211. # [00:32] <taylor> CMN: Agree with Domenic. You may decide it's a bad idea, but it is useful to be able to show you can.
212. # [00:32] <taylor> CMN: Wondering if we have "champions" in the room?
213. # [00:32] <taylor> RN: Yes?
214. # [00:33] <taylor> CMN: I nominate you.
215. # [00:33] <taylor> RN: [with understanding] Yes
216. # [00:33] <taylor> EB: Would be happy to be involved in this from a framework author perspective
217. # [00:33] <chaals> ack dg
218. # [00:33] * Zakim sees no one on the speaker queue
219. # [00:34] <taylor> DG: Need to be working with RN on this - represent strongest opinions from Polymer and existing experiences
220. # [00:34] <taylor> DG: [Dimitri is singing]
221. # [00:34] <taylor> CMN: [also singing]
222. # [00:35] <taylor> AR: Hard to call a new low
223. # [00:35] <taylor> DG: Want to ask: "what is the timeline of this"
224. # [00:35] <taylor> DG: Would like to figure this out stat. Should we put a deadline on this?
225. # [00:35] <taylor> consensus: yes
226. # [00:36] <taylor> RN: Busy for the next few months
227. # [00:37] <taylor> MJS: Can carve out time, and DG and EB offered to help
228. # [00:37] <taylor> EB: Would graciously request that Safari time provide some time for this, given Safari stated that this was a blocker
229. # [00:38] <taylor> RN: Beginning of July
230. # [00:38] <taylor> EB: Beginning of July
231. # [00:38] <chaals> agenda?
232. # [00:38] * Zakim sees 3 items remaining on the agenda:
233. # [00:38] * Zakim 4. Jan…'s proposal for named thingo [from chaals]
234. # [00:38] * Zakim 6. details of imperative distribution API, don't make it impossible. [from chaals]
235. # [00:38] * Zakim 8. styling [from chaals]
236. # [00:39] * Quits: mjs (~mjs@public.cloak) (mjs)
237. # [00:39] <chaals> zakim, close item 4
238. # [00:39] <Zakim> agendum 4, Jan…'s proposal for named thingo, closed
239. # [00:39] <Zakim> I see 2 items remaining on the agenda; the next one is
240. # [00:39] <Zakim> 6. details of imperative distribution API, don't make it impossible. [from chaals]
241. # [00:39] <chaals> zakim, close item 6
242. # [00:39] <Zakim> agendum 6, details of imperative distribution API, don't make it impossible., closed
243. # [00:39] <Zakim> I see 1 item remaining on the agenda:
244. # [00:39] <Zakim> 8. styling [from chaals]
245. # [00:39] * Quits: wilsonpage (~wilsonpage@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
246. # [00:41] * Joins: wilsonpage (~wilsonpage@public.cloak)
247. # [00:43] * Quits: weinig (~weinig@public.cloak) (weinig)
248. # [00:44] * Joins: jsbell (~jsbell@public.cloak)
249. # [00:49] * Quits: LJWatson (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
250. # [00:51] * Quits: sorvell (~sorvell@public.cloak) (Ping timeout: 180 seconds)
251. # [00:53] * Quits: jan (~JanMiksovsky@public.cloak) (jan)
252. # [00:55] * Joins: mjs (~mjs@public.cloak)
253. # [00:56] <taylor> [back]
254. # [00:57] * Joins: jan (~JanMiksovsky@public.cloak)
255. # [00:57] <taylor> DG: Next topic is Style
256. # [00:58] <taylor> AvK: Really need Tab here for some of this
257. # [00:58] <taylor> AvK: Let's discuss replacement for /deep/
258. # [00:58] * Joins: sorvell (~sorvell@public.cloak)
259. # [00:58] * Quits: sorvell (~sorvell@public.cloak) ("Page closed")
260. # [00:58] * Joins: sorvell (~sorvell@public.cloak)
261. # [00:59] <taylor> SO: Can speak to /deep/ and ::shadow
262. # [00:59] <taylor> SO: "part" failed - key reason was we couldn't figure out how to target it beyond one level
263. # [00:59] <taylor> SO: Had to match an element and do part
264. # [00:59] <taylor> SO: "Up the tree" = nested shadow roots
265. # [01:00] <taylor> SO: Want a way to turn on CSS - some way to expose styling up the tree to be able to do theming in my complicated structure
266. # [01:00] <taylor> SO: deep and shadow were bad. leaky of implementation details. bad perf. brittle.
267. # [01:01] <taylor> SO: Best fit that we think we have right now for cross-scope styling is custom properties
268. # [01:01] <taylor> SO: They inherit. Inheritance doesn't stop a shadow root boundaries
269. # [01:01] <taylor> SO: Anywhere down the tree you can intercept this and set it to something different
270. # [01:01] <taylor> SO: Custom properties are implemented only in FF
271. # [01:01] <taylor> SO: Practically they can only implement one value in CSS
272. # [01:02] <taylor> SO: Would need X custom properties for all of the properties an element might want to expose
273. # [01:02] <taylor> SO: We think custom properties should be implemented, and augmented with "mixin" property
274. # [01:02] <taylor> SO: This way you can pass down a bag of properties down the tree
275. # [01:02] <taylor> SO: We think this is the right direction for the browser to go
276. # [01:02] <ebryn> q+
277. # [01:02] * Zakim sees ebryn on the speaker queue
278. # [01:02] <mjs> q+
279. # [01:02] * Zakim sees ebryn, mjs on the speaker queue
280. # [01:03] <taylor> AvK: Is it problematic that these are global variables?
281. # [01:03] * Joins: admin (~macmaster@public.cloak)
282. # [01:03] <taylor> SO: The Scope author has full control over their scope, can remap variables, reset values in my scope
283. # [01:04] <Domenic_> I think it's this one: https://tabatkins.github.io/specs/css-extend-rule/
284. # [01:04] <taylor> SO: Could add more control with resetStyleInheritance flag or similar
285. # [01:04] * ebryn reset style inheritance flag?
286. # [01:04] * ebryn link to more info?
287. # [01:05] <ebryn> :root { —myColor: #ccc; }
288. # [01:05] <ebryn> i think cssnext’s playground does a good job: https://cssnext.github.io/cssnext-playground/
289. # [01:05] * Joins: LJWatson (~chatzilla@public.cloak)
290. # [01:05] <chaals> s/[back]/Topic: Styling
291. # [01:05] <mjs> q+ to ask why custom properties instead of named parts
292. # [01:05] * Zakim sees ebryn, mjs on the speaker queue
293. # [01:05] <taylor> SO: You document your style API. You have to do this with any proposal.
294. # [01:06] <rniwa> +q
295. # [01:06] * Zakim sees ebryn, mjs, rniwa on the speaker queue
296. # [01:06] <taylor> AvK: so if inner tree doesn't want to expose anything, it doesn't have to?
297. # [01:06] <chaals> ack eb
298. # [01:06] * Zakim sees mjs, rniwa on the speaker queue
299. # [01:06] <taylor> SO: Correct
300. # [01:06] <taylor> EB: Recently became familiar with this proposal
301. # [01:06] <taylor> EB: Extremely excited with this proposal.
302. # [01:06] <taylor> EB: Began implementing a theming engine based on this proposal
303. # [01:06] <taylor> EB: Hadn't heard of mixin concept - interested in this as well
304. # [01:07] <hober> q+
305. # [01:07] * Zakim sees mjs, rniwa, hober on the speaker queue
306. # [01:07] <Domenic_> I can present an example of @extend usage
307. # [01:07] <taylor> EB: This is the solution. I've heard a lot of people complain about the problem of overriding style information in shadow roots.
308. # [01:07] <Domenic_> I figured out how to use it for the multiple properties thing
309. # [01:07] <Domenic_> I guess I can just type it here
310. # [01:07] <taylor> EB: This seems like a very elegant side-channel for propagating this information throughout the component hierarchies
311. # [01:07] * chaals yes please domenic
312. # [01:07] <justin> https://github.com/Polymer/polymer/blob/0.8-preview/PRIMER.md#xscope-styling
313. # [01:07] <chaals> ack mj
314. # [01:07] <Zakim> mjs, you wanted to ask why custom properties instead of named parts
315. # [01:07] * Zakim sees rniwa, hober on the speaker queue
316. # [01:08] <Domenic_> /* in shadow DOM */ <style> #internal-piece { @extend %my-component-internal-piece; }</style> <div id="internal-piece">...</div>
317. # [01:08] <taylor> MJS: Why custom properties instead of named parts?
318. # [01:08] <Domenic_> /* outside shadow DOM */ %my-component-internal-piece { color: blue; opacity: 0.5; }
319. # [01:08] <taylor> MJS: Seems more natural to say this-element:toolbar { color: red; }
320. # [01:08] <taylor> MJS: Then you're not making aliased clones of style properties
321. # [01:09] <taylor> SO: That's another way to go. From our perspective, it's really close.
322. # [01:09] <taylor> SO: The huge advantage is now we don't have this huge interaction with the selector engine
323. # [01:09] <chaals> ack rn
324. # [01:09] * Zakim sees hober on the speaker queue
325. # [01:09] <ebryn> +eb
326. # [01:09] * Zakim wonders where eb is
327. # [01:09] <ebryn> +q
328. # [01:09] * Zakim sees hober, ebryn on the speaker queue
329. # [01:09] <taylor> SO: Inheritance is a totally different model that fits better
330. # [01:09] <justin> q+
331. # [01:09] * Zakim sees hober, ebryn, justin on the speaker queue
332. # [01:09] * chaals wonders if domenic wants to q+
333. # [01:10] <hober> q-
334. # [01:10] * Zakim sees ebryn, justin on the speaker queue
335. # [01:10] <chaals> q+ domenic
336. # [01:10] * Zakim sees ebryn, justin, domenic on the speaker queue
337. # [01:11] * ebryn parts proposal link?
338. # [01:11] <taylor> RN: How do you specify specific values for a specific custom element that you match with a selector?
339. # [01:11] <taylor> SO: The basic answer is "You don't exactly" because doing so is selector matching, and we're not using selectors
340. # [01:11] <taylor> SO: If you have a button, and the button exposes a "button theme"
341. # [01:12] <taylor> SO: But in your scope you have a specific set of buttons, you have to expose each one as a different name
342. # [01:12] <taylor> SO: Advantage: we don't have to use complexity of style selector engine, and you don't expose details of the structure
343. # [01:12] <taylor> RN: How does a component author know what kind of types of buttons you may end up using?
344. # [01:13] <taylor> SO: Button just needs to expose a way of styling it
345. # [01:13] <taylor> SO: It's the user of the button that has to style the buttons individually
346. # [01:13] <chaals> ack ebry
347. # [01:13] * Zakim sees justin, domenic on the speaker queue
348. # [01:13] <taylor> MJS: What if there are lots of properties that you want the same way?
349. # [01:13] <taylor> SO: You can set properties to other properties
350. # [01:14] <taylor> MJS: Problem: overloading the same property names. My plan is to automatically namespace these with the component's name.
351. # [01:14] <taylor> s/MJS/EB/
352. # [01:14] <taylor> EB: I'm enforcing this a the framework level rather than the spec level
353. # [01:14] <mjs> q+ to ask about var()
354. # [01:15] * Zakim sees justin, domenic, mjs on the speaker queue
355. # [01:15] <taylor> SO: I'm imagining exactly the same thing
356. # [01:15] <taylor> SO: We haven't codified this yet in the system, but it's not a bad idea
357. # [01:15] <Domenic_> https://gist.github.com/domenic/56da9586bb1326a05edb
358. # [01:15] <mjs> q+ to ask about var() and how you update when your inherited style changes
359. # [01:15] * Zakim sees justin, domenic, mjs on the speaker queue
360. # [01:15] <taylor> SO: The fact that at each scope you can decide what happens gives you enough hooks
361. # [01:15] * chaals wonders if domenic wants to let mjs go first on queue or not
362. # [01:16] <taylor> EB: Would like to bet heavily on this API. Need to see part proposal.
363. # [01:16] <mjs> Named Parts proposal: https://lists.w3.org/Archives/Public/www-style/2014Feb/0621.html
364. # [01:16] <chaals> ack ju
365. # [01:16] * Zakim sees domenic, mjs on the speaker queue
366. # [01:16] <taylor> EB: Would love to see consensus get built. See alignment with Polymer team on this.
367. # [01:16] <taylor> JF: What makes this more powerful than parts: don't need to invent blacklist
368. # [01:17] <taylor> JF: Can expose a property, the value of which I might map to multiple styling points, use in a calculation, etc.
369. # [01:17] <taylor> JF: You get this power over just parts
370. # [01:17] <taylor> EB: Is it just me or does the parts proposal align to the named slots concept?
371. # [01:17] <taylor> consensus: yes
372. # [01:17] <rniwa> q+
373. # [01:17] * Zakim sees domenic, mjs, rniwa on the speaker queue
374. # [01:18] <taylor> EB: Seems clear to me I don't want my users to have to override CSS properties. Don't want them setting color and background color.
375. # [01:18] <chaals> q+ sam
376. # [01:18] * Zakim sees domenic, mjs, rniwa, sam on the speaker queue
377. # [01:18] <taylor> EB: Want to provide higher-level concepts than what CSS itself provides.
378. # [01:18] <mjs> Is this the actual spec for what people are talking about with custom properties and var()? http://dev.w3.org/csswg/css-variables/
379. # [01:18] <taylor> AvK: As long as CSS properties are granular enough, you can have a blacklist or whitelist for parts thing
380. # [01:18] <taylor> EB: I don't want granular
381. # [01:18] <taylor> SO: You cant have --secondary-color. We can invent that property and have it mean something
382. # [01:19] <LJWatson> q+ to say that there is an (edge) accessibility case for enabling users to override styles
383. # [01:19] * Zakim sees domenic, mjs, rniwa, sam, LJWatson on the speaker queue
384. # [01:19] <taylor> EB: My motivation: I want to be able to define the terminology and vocabulary that the user is using
385. # [01:19] <taylor> EB: I want my UI library to abstract away the granular, nitty-gritty details and expose them as something simple.
386. # [01:20] <taylor> EB: Not expose nitty gritty properties and have the user have to infer the API out
387. # [01:20] <taylor> CMN: So you want to be able to do something like expose the property "theme" and take that information and apply the component to where it ends up?
388. # [01:20] <hober> q+
389. # [01:20] * Zakim sees domenic, mjs, rniwa, sam, LJWatson, hober on the speaker queue
390. # [01:21] <taylor> EB: More of like an implicit thing than an explicit thing. The documentation for your component will have all the attributes and properties that you element has.
391. # [01:21] <taylor> EB: It will also have a "themeable" section of the things that can be changed by the parent
392. # [01:21] <taylor> EB: Like a side-channel
393. # [01:21] <taylor> EB: Don't want to be verbose always - want nice global aspect of CSS without allowing people to globally muck with your styling logic.
394. # [01:21] <Travis> q+
395. # [01:21] * Zakim sees domenic, mjs, rniwa, sam, LJWatson, hober, Travis on the speaker queue
396. # [01:22] <taylor> EB: You want people to muck with the styleable or themable properties of your element
397. # [01:22] <chaals> ack dom
398. # [01:22] * Zakim sees mjs, rniwa, sam, LJWatson, hober, Travis on the speaker queue
399. # [01:22] <taylor> Domenic: Check out the gist
400. # [01:22] <taylor> https://gist.github.com/domenic/56da9586bb1326a05edb
401. # [01:23] <taylor> Domenic: Custom properties let you customize one thing at a time, mixins let you customize as many things as you want at one time
402. # [01:23] <taylor> WP: Does mixin api let you whitelist or blacklist properties?
403. # [01:23] <chaals> q?
404. # [01:23] * Zakim sees mjs, rniwa, sam, LJWatson, hober, Travis on the speaker queue
405. # [01:23] <taylor> Domenic: Yes, you could override it.
406. # [01:23] <chaals> ack mj
407. # [01:23] <Zakim> mjs, you wanted to ask about var() and to ask about var() and how you update when your inherited style changes
408. # [01:23] * Zakim sees rniwa, sam, LJWatson, hober, Travis on the speaker queue
409. # [01:23] <taylor> EB: Yes. Normal CSS rules apply.
410. # [01:24] * Quits: jan (~JanMiksovsky@public.cloak) (jan)
411. # [01:24] <mjs> http://dev.w3.org/csswg/css-variables/
412. # [01:24] <taylor> MJS: I was confused about which part of this proposal is a request for UA to implement things vs. framework implementation
413. # [01:24] * Quits: philipwalton (~philipwalton@public.cloak) (Ping timeout: 180 seconds)
414. # [01:24] <chaals> s|http://dev.w3.org/csswg/css-variables/|-> http://dev.w3.org/csswg/css-variables/ the custom properties spec…|
415. # [01:25] <wilsonpage> q+
416. # [01:25] * Zakim sees rniwa, sam, LJWatson, hober, Travis, wilsonpage on the speaker queue
417. # [01:25] <wilsonpage> q-
418. # [01:25] * Zakim sees rniwa, sam, LJWatson, hober, Travis on the speaker queue
419. # [01:25] <taylor> MJS: As presented, this thing has similarly equivalent power to named parts
420. # [01:25] <taylor> MJS: But to do a whitelist of certain properties you need to invent a variable for each thing on your whitelist
421. # [01:26] * ebryn i want to invent those properties
422. # [01:26] <taylor> MJS: With parts people can just use the direct style property
423. # [01:26] <ebryn> +q
424. # [01:26] * Zakim sees rniwa, sam, LJWatson, hober, Travis, ebryn on the speaker queue
425. # [01:26] <chaals> q?
426. # [01:26] * Zakim sees rniwa, sam, LJWatson, hober, Travis, ebryn on the speaker queue
427. # [01:26] <justin> q+
428. # [01:26] * Zakim sees rniwa, sam, LJWatson, hober, Travis, ebryn, justin on the speaker queue
429. # [01:27] <taylor> SO: We have psuedos for like range - is there a whitelist for that?
430. # [01:27] <chaals> ack rn
431. # [01:27] * Zakim sees sam, LJWatson, hober, Travis, ebryn, justin on the speaker queue
432. # [01:27] <rniwa> q-
433. # [01:27] * Zakim sees sam, LJWatson, hober, Travis, ebryn, justin on the speaker queue
434. # [01:27] <taylor> MJS: When we allow psudoes for styling parts of elements they can only accept certain properties
435. # [01:27] * rniwa was gonna say the same thing
436. # [01:27] <taylor> s/psudoes/psuedos/
437. # [01:27] <chaals> ack sam
438. # [01:27] * Zakim sees LJWatson, hober, Travis, ebryn, justin on the speaker queue
439. # [01:28] <chaals> q+ ejb
440. # [01:28] * Zakim sees LJWatson, hober, Travis, ebryn, justin, ejb on the speaker queue
441. # [01:28] <chaals> q- ejb
442. # [01:28] * Zakim sees LJWatson, hober, Travis, ebryn, justin on the speaker queue
443. # [01:28] <chaals> q+ ebryn
444. # [01:28] * Zakim sees LJWatson, hober, Travis, ebryn, justin on the speaker queue
445. # [01:28] <taylor> SW: Seems like this has a lot of nice properties
446. # [01:28] <taylor> SW: The ability to take only a part of a thing
447. # [01:28] * Quits: Travis (~Travis@public.cloak) (Ping timeout: 180 seconds)
448. # [01:29] <taylor> SW: Seems like there's a nicer abstraction that's available here
449. # [01:29] <taylor> SW: 2 things you might want to do: a particular property or part of a property is something that you want to change property, or something you might only want the embedder of me to change
450. # [01:29] <taylor> SW: Have you run in to places where you want the author to be more or less restrictive
451. # [01:30] <taylor> EB: The second argument to var is a good fallback mechanism to globals
452. # [01:30] <taylor> EB: var lets you provide the fallback
453. # [01:30] <taylor> EB: There is potentially some other stuff to be explored - conventional naming mechanisms
454. # [01:30] <taylor> EB: Perhaps a framework idea: If you name your custom properties in a mechanism --color, perhaps you can assume that they meant to set the color property
455. # [01:31] * Quits: annevk (~annevk@public.cloak) (Client closed connection)
456. # [01:31] <Domenic_> Could we allow color: var(color)?
457. # [01:31] <taylor> EB: Might have some nice naming conventions for how you can override things so that the user doesn't have to learn what the unique name was
458. # [01:31] * Quits: misko (~misko@public.cloak) (misko)
459. # [01:31] * chaals worries about accidentally overriding the new CSS7 crazypaving property…
460. # [01:31] <taylor> EB: That coupled with automatic namespacing with custom element could be the convention to override a specific property
461. # [01:31] <chaals> ack LJ
462. # [01:31] <Zakim> LJWatson, you wanted to say that there is an (edge) accessibility case for enabling users to override styles
463. # [01:31] * Zakim sees hober, Travis, ebryn, justin on the speaker queue
464. # [01:31] <ebryn> q-
465. # [01:31] * Zakim sees hober, Travis, justin on the speaker queue
466. # [01:31] * Joins: Travis (~Travis@public.cloak)
467. # [01:32] <taylor> LJW: Edge case from a11y point of view - when people with low vision want to override styles of a website
468. # [01:32] * chaals doesn't think that is a stupid question
469. # [01:32] <taylor> LJW: How did these proposals let us handle things like keyboard focus visibility, where at the global level it is controlled but needs to move inside component?
470. # [01:32] <aboxhall> q+ to ask about separation of presentation and behaviour
471. # [01:32] * Zakim sees hober, Travis, justin, aboxhall on the speaker queue
472. # [01:32] <hober> q-
473. # [01:32] * Zakim sees Travis, justin, aboxhall on the speaker queue
474. # [01:33] <taylor> LJW: You want to be clear where your keyboard focus is. Typically global. Could it be matched up so that keyboard focus could be consistent everywhere?
475. # [01:33] <mjs> q+ to comment on focus
476. # [01:33] * Zakim sees Travis, justin, aboxhall, mjs on the speaker queue
477. # [01:33] <taylor> CMN: Perhaps a bad idea would be to whitelist focus
478. # [01:33] <taylor> MJS: No obviously good way to do it with inheritance model
479. # [01:33] <taylor> MJS: Plausibly you could imagine with part selector and focus selector you could style particular focus part
480. # [01:34] <taylor> SO: Using custom properties, at the point you consume the property you would match it against :focus
481. # [01:34] <taylor> SO: This is not as practical for high-contrast
482. # [01:35] <taylor> MJS: So if you wanted :hover :focus ... etc. you'd have to invent separate properties for each one?
483. # [01:35] <taylor> JF: You can apply a whole mixin of properties
484. # [01:35] <hober> q?
485. # [01:35] * Zakim sees Travis, justin, aboxhall, mjs on the speaker queue
486. # [01:35] <hober> q+
487. # [01:35] * Zakim sees Travis, justin, aboxhall, mjs, hober on the speaker queue
488. # [01:35] <mjs> q-
489. # [01:35] * Zakim sees Travis, justin, aboxhall, hober on the speaker queue
490. # [01:35] * Quits: zenorocha (~zenorocha@public.cloak) ("Page closed")
491. # [01:35] * Joins: weinig (~weinig@public.cloak)
492. # [01:36] <taylor> AvK: If it's a useragent thing you could override it
493. # [01:36] <Travis> q-
494. # [01:36] * Zakim sees justin, aboxhall, hober on the speaker queue
495. # [01:36] <taylor> CMN: Note: We need to figure out these things for a11y
496. # [01:36] <taylor> SW: What is the new thing in Shadow DOM that raises a problem?
497. # [01:37] <taylor> CMN: You might be right, it might not be a new problem.
498. # [01:37] <chaals> ack ju
499. # [01:37] * Zakim sees aboxhall, hober on the speaker queue
500. # [01:38] <chaals> ack abox
501. # [01:38] <Zakim> aboxhall, you wanted to ask about separation of presentation and behaviour
502. # [01:38] * Zakim sees hober on the speaker queue
503. # [01:38] <taylor> AB: One thing that concerns me is separation of presentation and behavior. Make sure we're keeping this in mind. Whether it shakes out as a best practice pattern.
504. # [01:38] <taylor> AB: People keep reimplementing button because they can't style it the way they want
505. # [01:38] <taylor> AB: Make sure we have this on our radar - that we can separate behavior and styling with custom elements
506. # [01:39] <chaals> ack hob
507. # [01:39] * Zakim sees no one on the speaker queue
508. # [01:39] <taylor> AvK: Domenic is working on this - reimplementing HTML as custom elements
509. # [01:40] <taylor> EO: CSS variables seems like a good fit for styling focus
510. # [01:40] <rniwa> q+
511. # [01:40] * Zakim sees rniwa on the speaker queue
512. # [01:40] <taylor> EO: Would be a mistake to think that CSS mixins are anything beyond a blog post, but variables are very far along
513. # [01:40] <taylor> EO: Happy to communicate that we want them
514. # [01:40] <sorvell> q+
515. # [01:40] * Zakim sees rniwa, sorvell on the speaker queue
516. # [01:41] <taylor> EO: How are these features helping us explain the platform: multiple shadow root issue with part proposal is a real one. With multiple form controls we have parts, and a way to take bundle of properties without CSS mixins.
517. # [01:42] <taylor> RN: One problem I can see is if we want isolated components, you can see any variables in original document inside component. We need a mechanism to either whitelist or expose a list of properties you're listening to, and page needs a way to expose a list of components you want to be able to use variables
518. # [01:42] <chaals> ack rn
519. # [01:42] * Zakim sees sorvell on the speaker queue
520. # [01:42] <chaals> ack so
521. # [01:42] * Zakim sees no one on the speaker queue
522. # [01:42] <taylor> SO: We feel like we needed shadow piercing because we were blocked on needing to do themeing. We feel unblocked now
523. # [01:43] <taylor> SO: We don't know how to do isolated scope themeing, but we don't have isolated scopes yet.
524. # [01:43] <taylor> SO: We have enough capability now to polyfill or shim additional features around it, which can inform v2
525. # [01:43] <taylor> RN: Can someone write up concrete proposal and set it to mailing list?
526. # [01:44] <rniwa> s/set/send/
527. # [01:44] <taylor> Domenic: Summarize: don't think there's much of a proposal other than "here's what we already have, and how we could use them"
528. # [01:44] <taylor> Domenic: We have a solution for blacklisting, we don't yet have one for whitelisting
529. # [01:44] <taylor> Domenic: Unresolved issue around non-standard elements in form controls. Do we want to standardize them, or move towards a model where there are standard custom properties
530. # [01:45] <hober> q?
531. # [01:45] * Zakim sees no one on the speaker queue
532. # [01:45] <taylor> DG: Want to make sure that there's nobody who feels that parts and custom properties proposals are conflicting with eachother
533. # [01:45] <taylor> MJS: Seems like you could implement both
534. # [01:46] <taylor> MJS: For isolated mode you probably don't want styles inheriting
535. # [01:46] <taylor> Domenic: Don't think this is a foregone conclusion - seems reasonable that you might want --slider-thumb-color with the browser
536. # [01:46] <taylor> MJS: Probably don't want it to inherit arbitrarily predefined properties
537. # [01:47] <rniwa> q+
538. # [01:47] * Zakim sees rniwa on the speaker queue
539. # [01:48] <taylor> MJS: Lets say you have secure login component with image for the user to see. Inherit css in that causes it to be hidden.
540. # [01:48] <taylor> Domenic: Only happens if the component specifically exposes this
541. # [01:48] <taylor> JS: You inherit only inheritable properties
542. # [01:48] <taylor> s/JS/JF/
543. # [01:49] <taylor> SO: inheritance breaks through inheritable properties
544. # [01:49] <taylor> Domenic: Set of inheritable properties should only be custom properties?
545. # [01:49] * ebryn lazyweb: what are the set of inheritable properties for shadow dom?
546. # [01:49] <taylor> RN: If you had a component that respects --property-one
547. # [01:49] <taylor> RN: Then you add --property-2 to another componnet
548. # [01:49] <chaals> ack rn
549. # [01:49] * Zakim sees no one on the speaker queue
550. # [01:50] <taylor> s/componnet/component
551. # [01:50] <taylor> RN: But then the first component author could change the component to use --property-1
552. # [01:50] <taylor> JF: Conventions around namespacing will be important here. Is it just a semantic property, or are you targeting a specific CSS property on a set of components?
553. # [01:50] <taylor> JF: Sometimes you want these collisions - you want different themes to share --primary-color
554. # [01:51] <taylor> JF: Yet to be determines how people do this
555. # [01:51] <taylor> DG: Really productive meeting!!
556. # [01:51] <taylor> [applause]
557. # [01:51] <Domenic_> http://dev.w3.org/csswg/css2/propidx.html has all the properties as of 2.1...
558. # [01:51] <Domenic_> azimuth is inherited woo
559. # [01:51] <taylor> DG: Much smaller set of contentious problems - some concrete work items
560. # [01:53] <taylor> DG: Resolutions:
561. # [01:53] <taylor> DG: Multiple shadow root - remove
562. # [01:53] <taylor> DG: Open-closed: Default value - explicitly declared, both open and closed in v1
563. # [01:54] <taylor> DG: EB and RN will drive proposal for imperative API
564. # [01:54] <taylor> DG: Event retargeting - swapping out path and the new deepPath
565. # [01:54] <taylor> DG: Shadow boundary piercing combinators are gone
566. # [01:54] <taylor> DG: Slot proposal blocked on imperative API resolution
567. # [01:55] * Quits: LJWatson (~chatzilla@public.cloak) ("ChatZilla 0.9.91.1 [Firefox 37.0.2/20150415140819]")
568. # [01:56] <taylor> DG: Lots of cool ideas on styling, don't see any big problems.
569. # [01:56] <taylor> EO: Don't see any problems here with custom properties
570. # [01:56] <taylor> DG: Need action item to talk about :host
571. # [01:57] <taylor> DG: :host is ability for you as a component to style yourself from the inside
572. # [01:58] <taylor> EB: Re; event path - if you're going to turn something on that isn't configurable, want confirmation that you have all the original information
573. # [01:58] <taylor> EB: Simplest thing for my perspective is to include the original event object
574. # [01:59] <taylor> EB: Would prefer non-mutated version of the original event object
575. # [01:59] <taylor> AR: Seems very sugar-y
576. # [01:59] <taylor> EB: Purely theoretical.
577. # [01:59] <taylor> AI(EB): Find out if this is a real problem.
578. # [01:59] <taylor> DG: Thanks everybody for coming!
579. # [01:59] <taylor> DG: If you're not tired you're amazing
580. # [02:00] <taylor> DG: Let's meet again some time.
581. # [02:00] <taylor> AvK: Meeting in July again might be good, if proposal is good
582. # [02:00] <taylor> DG: Let's plan for something. Good idea.
583. # [02:00] <taylor> DG: Plan same thing for Custom Elements
584. # [02:00] <aklein> Also should plan some sort of Custom Elements thing
585. # [02:01] <taylor> Thanks everyone!
586. # [02:01] * Quits: rniwa (~textual@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
587. # [02:01] <taylor> -- Fin --
588. # [02:01] * Quits: mjs (~mjs@public.cloak) (mjs)
589. # [02:01] * Quits: taylor (~taylor@public.cloak) ("Page closed")
590. # [02:01] * Quits: weinig (~weinig@public.cloak) (weinig)
591. # [02:02] * Parts: dglazkov (~sid4270@public.cloak)
592. # [02:02] <chaals> [Thanks to Taylor for scribing, Dmitry for getting this together, Chris for logistics…]
593. # [02:02] <chaals> rrsagent, draft minutes
594. # [02:02] <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/25-webapps-minutes.html chaals
595. # [02:02] * Quits: aklein (~sid4454@public.cloak) ("")
596. # [02:04] * Quits: wilsonpage (~wilsonpage@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
597. # [02:05] * Joins: joannawu (~JoannaWu@public.cloak)
598. # [02:07] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 180 seconds)
599. # [02:07] * Quits: Travis (~Travis@public.cloak) (Ping timeout: 180 seconds)
600. # [02:07] * Quits: sorvell (~sorvell@public.cloak) (Ping timeout: 180 seconds)
601. # [02:08] * Quits: smaug (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
602. # [02:11] * Quits: markg (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
603. # [02:11] * Quits: admin (~macmaster@public.cloak) ("Bye!")
604. # [02:12] * Quits: chaals (~Adium@public.cloak) ("Leaving.")
605. # [02:12] * Joins: hexalys (~hexalys@public.cloak)
606. # [02:12] * Quits: joannawu (~JoannaWu@public.cloak) (Ping timeout: 180 seconds)
607. # [02:12] * Quits: hexalys (~hexalys@public.cloak) ("Bye!")
608. # [02:38] * Joins: wilsonpage (~wilsonpage@public.cloak)
609. # [02:39] * Quits: jsbell (~jsbell@public.cloak) ("There's no place like home...")
610. # [02:39] * Quits: wilsonpage (~wilsonpage@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
611. # [02:40] * terri is now known as terri_offline
612. # [03:12] * Joins: jan (~JanMiksovsky@public.cloak)
613. # [03:14] * Quits: jan (~JanMiksovsky@public.cloak) (jan)
614. # [03:36] * Joins: mjs (~mjs@public.cloak)
615. # [03:44] * Joins: lizheming (~lizheming@public.cloak)
616. # [03:45] * Quits: lizheming (~lizheming@public.cloak) ("Page closed")
617. # [03:45] * Joins: joannawu (~JoannaWu@public.cloak)
618. # [04:03] * Joins: John (~John@public.cloak)
619. # [04:12] * Quits: mjs (~mjs@public.cloak) (mjs)
620. # [04:30] * Joins: marcosc__ (~marcosc@public.cloak)
621. # [04:30] * Quits: marcosc_ (~marcosc@public.cloak) (Client closed connection)
622. # [04:36] * Joins: mjs (~mjs@public.cloak)
623. # [04:38] * Quits: marcosc (~marcosc@public.cloak) (Client closed connection)
624. # [04:52] * Quits: mjs (~mjs@public.cloak) (mjs)
625. # [04:53] * Quits: John (~John@public.cloak) ("Page closed")
626. # [05:32] * Joins: smaug (~chatzilla@public.cloak)
627. # [05:34] * Joins: markg (~chatzilla@public.cloak)
628. # [05:38] * Joins: marcosc (~marcosc@public.cloak)
629. # [05:45] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
630. # [05:50] * Quits: aboxhall (~uid20617@public.cloak) ("Connection closed for inactivity")
631. # [06:11] * Joins: jyasskin (~textual@public.cloak)
632. # [06:20] * Joins: mjs (~mjs@public.cloak)
633. # [06:20] * Joins: arronei (~arronei@public.cloak)
634. # [06:22] * Joins: woozy (~woozy@public.cloak)
635. # [06:25] * Quits: woozy (~woozy@public.cloak) ("Page closed")
636. # [06:30] * Quits: mjs (~mjs@public.cloak) (mjs)
637. # [06:31] * Joins: rniwa (~textual@public.cloak)
638. # [06:40] * Joins: smaug_ (~chatzilla@public.cloak)
639. # [06:41] * Quits: smaug_ (~chatzilla@public.cloak) ("Reconnecting…")
640. # [06:45] * Quits: smaug (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
641. # [06:55] * Quits: jyasskin (~textual@public.cloak) ("Textual IRC Client: www.textualapp.com")
642. # [06:58] * Joins: jyasskin (~textual@public.cloak)
643. # [07:13] * Quits: joannawu (~JoannaWu@public.cloak) (Client closed connection)
644. # [07:18] * Joins: estellevw (~estellevw@public.cloak)
645. # [07:37] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 180 seconds)
646. # [07:44] * Joins: joannawu (~JoannaWu@public.cloak)
647. # [07:50] * Quits: estellevw (~estellevw@public.cloak) ("Snuggling with the puppies")
648. # [08:07] * Joins: shepazu (schepers@public.cloak)
649. # [08:11] * Quits: joannawu (~JoannaWu@public.cloak) (Client closed connection)
650. # [08:12] * Joins: joannawu (~JoannaWu@public.cloak)
651. # [08:20] * Parts: tantek (~tantek@public.cloak)
652. # [08:49] * Quits: joannawu (~JoannaWu@public.cloak) (Client closed connection)
653. # [08:54] * Quits: jyasskin (~textual@public.cloak) ("My computer has gone to sleep. ZZZzzz…")
654. # [09:26] * Joins: joannawu (~JoannaWu@public.cloak)
655. # [09:28] * Joins: jyasskin (~textual@public.cloak)
656. # [09:42] * Quits: joannawu (~JoannaWu@public.cloak) (Client closed connection)
657. # [09:43] * Joins: SteveF (~chatzilla@public.cloak)
658. # [09:56] * Quits: rniwa (~textual@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
659. # [09:57] * Joins: joannawu (~JoannaWu@public.cloak)
660. # [09:57] * Quits: joannawu (~JoannaWu@public.cloak) (Client closed connection)
661. # [10:25] * Joins: joannawu (~JoannaWu@public.cloak)
662. # [10:58] * Joins: rniwa (~textual@public.cloak)
663. # [11:00] * Quits: jyasskin (~textual@public.cloak) ("My computer has gone to sleep. ZZZzzz…")
664. # [11:09] * Quits: rniwa (~textual@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
665. # [11:35] * Joins: marcosc (~marcosc@public.cloak)
666. # [11:42] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
667. # [11:44] * Quits: joannawu (~JoannaWu@public.cloak) (Client closed connection)
668. # [12:01] * Joins: joannawu (~JoannaWu@public.cloak)
669. # [12:18] * Quits: joannawu (~JoannaWu@public.cloak) (Client closed connection)
670. # [12:19] * Joins: joannawu (~JoannaWu@public.cloak)
671. # [12:26] * Quits: joannawu (~JoannaWu@public.cloak) (Ping timeout: 180 seconds)
672. # [12:54] * Quits: SteveF (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
673. # [13:19] * Joins: joannawu (~JoannaWu@public.cloak)
674. # [13:27] * Quits: joannawu (~JoannaWu@public.cloak) (Ping timeout: 180 seconds)
675. # [14:03] * Quits: markg (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
676. # [14:20] * Joins: joannawu (~JoannaWu@public.cloak)
677. # [14:27] * Quits: joannawu (~JoannaWu@public.cloak) (Ping timeout: 180 seconds)
678. # [14:40] * Joins: marcosc (~marcosc@public.cloak)
679. # [14:47] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
680. # [15:03] * Joins: markg (~chatzilla@public.cloak)
681. # [15:36] * Joins: joannawu (~JoannaWu@public.cloak)
682. # [15:41] * Quits: markg (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
683. # [15:43] * Quits: joannawu (~JoannaWu@public.cloak) (Ping timeout: 180 seconds)
684. # [15:58] * Quits: shepazu (schepers@public.cloak) (Ping timeout: 180 seconds)
685. # [16:05] * Joins: estellevw (~estellevw@public.cloak)
686. # [16:12] * Joins: darobin (rberjon@public.cloak)
687. # [16:29] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
688. # [16:33] * Joins: marcosc (~marcosc@public.cloak)
689. # [16:33] * Quits: marcosc__ (~marcosc@public.cloak) (Client closed connection)
690. # [16:41] * Joins: marcosc_ (~marcosc@public.cloak)
691. # [16:44] * Joins: joannawu (~JoannaWu@public.cloak)
692. # [16:49] * Quits: marcosc_ (~marcosc@public.cloak) (Ping timeout: 180 seconds)
693. # [17:03] * Joins: arronei (~arronei@public.cloak)
694. # [17:30] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 180 seconds)
695. # [17:34] * Quits: estellevw (~estellevw@public.cloak) ("Snuggling with the puppies")
696. # [17:37] * Joins: estellevw (~estellevw@public.cloak)
697. # [18:07] * Joins: SteveF (~chatzilla@public.cloak)
698. # [18:12] * Joins: Guest70 (~textual@public.cloak)
699. # [18:23] * Quits: estellevw (~estellevw@public.cloak) ("Snuggling with the puppies")
700. # [18:35] * Joins: arronei (~arronei@public.cloak)
701. # [18:42] * Quits: joannawu (~JoannaWu@public.cloak) (Client closed connection)
702. # [18:51] * Joins: joannawu (~JoannaWu@public.cloak)
703. # [18:58] * Joins: markg (~chatzilla@public.cloak)
704. # [19:23] * Joins: jyasskin (~textual@public.cloak)
705. # [19:31] * Joins: marcosc_ (~marcosc@public.cloak)
706. # [19:32] * Quits: joannawu (~JoannaWu@public.cloak) (Client closed connection)
707. # [19:38] * Quits: marcosc_ (~marcosc@public.cloak) (Ping timeout: 180 seconds)
708. # [19:44] * Joins: shepazu (schepers@public.cloak)
709. # [19:46] * Quits: jyasskin (~textual@public.cloak) ("My computer has gone to sleep. ZZZzzz…")
710. # [19:52] * Joins: joannawu (~JoannaWu@public.cloak)
711. # [19:52] * Quits: joannawu (~JoannaWu@public.cloak) (Client closed connection)
712. # [19:52] * Joins: joannawu (~JoannaWu@public.cloak)
713. # [20:05] * Quits: SteveF (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
714. # [20:18] * Joins: shepazu_ (schepers@public.cloak)
715. # [20:18] * Quits: shepazu (schepers@public.cloak) (Client closed connection)
716. # [20:19] * Joins: darobin (rberjon@public.cloak)
717. # [20:25] * Quits: shepazu_ (schepers@public.cloak) (Client closed connection)
718. # [20:25] * Joins: shepazu (schepers@public.cloak)
719. # [20:27] * Quits: shepazu (schepers@public.cloak) (Client closed connection)
720. # [20:27] * Joins: shepazu (schepers@public.cloak)
721. # [20:29] * Quits: shepazu (schepers@public.cloak) (Client closed connection)
722. # [20:29] * Joins: shepazu_ (schepers@public.cloak)
723. # [20:32] * Quits: shepazu_ (schepers@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
724. # [20:39] * Joins: jyasskin (~textual@public.cloak)
725. # [20:39] * Quits: joannawu (~JoannaWu@public.cloak) (Client closed connection)
726. # [20:53] * Joins: joannawu (~JoannaWu@public.cloak)
727. # [21:00] * Quits: joannawu (~JoannaWu@public.cloak) (Ping timeout: 180 seconds)
728. # [21:06] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 180 seconds)
729. # [21:10] * Joins: SteveF (~chatzilla@public.cloak)
730. # [21:44] <hallvord> I'd like some developer comments on this idea: https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0173.html - any idea how I can get it some attention? Seems Chrome is busy improving their clipboard stuff support, which is cool, but it means it would be nice to find a good feature detection story soon..
731. # [21:48] * Quits: SteveF (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
732. # [21:50] * Joins: estellevw (~estellevw@public.cloak)
733. # [21:57] * Joins: smaug (~chatzilla@public.cloak)
734. # [22:01] * Joins: marcosc_ (~marcosc@public.cloak)
735. # [22:08] * Quits: marcosc_ (~marcosc@public.cloak) (Ping timeout: 180 seconds)
736. # [22:15] * Joins: shepazu (schepers@public.cloak)
737. # [22:24] * Quits: darobin (rberjon@public.cloak) ("Leaving...")
738. # [22:25] * Quits: shepazu (schepers@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
739. # [22:27] * Joins: shepazu (schepers@public.cloak)
740. # [22:44] * Joins: rniwa (~textual@public.cloak)
741. # [22:59] * Quits: shepazu (schepers@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
742. # [23:00] * Quits: rniwa (~textual@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
743. # [23:02] * Joins: marcosc_ (~marcosc@public.cloak)
744. # [23:09] * Quits: marcosc_ (~marcosc@public.cloak) (Ping timeout: 180 seconds)
745. # [23:14] * Quits: smaug (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
746. # [23:31] * Joins: rniwa (~textual@public.cloak)
747. # [23:38] * Quits: rniwa (~textual@public.cloak) (Ping timeout: 180 seconds)
748. # [23:40] * Joins: shepazu (schepers@public.cloak)
749. # Session Close: Sun Apr 26 00:00:00 2015

Previous day, Next day

Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn