/irc-logs / freenode / #whatwg / 2011-10-18 / end

Options:

1. # Session Start: Tue Oct 18 00:00:01 2011
2. # Session Ident: #whatwg
3. # [00:00] <Hixie> you fire a SYNTAX_ERR if there's three arguments
4. # [00:00] <Hixie> regardless of what they are
5. # [00:00] <Hixie> unless they're both '*'
6. # [00:00] <Hixie> (or presumably any valid origin, i haven't tested other origins)
7. # [00:01] <annevk> what did you pass as argument?
8. # [00:03] <zcorpan> i'll have to look at that tomorrow i guess. now sleep
9. # [00:03] <annevk> Hixie, I think we throw because you pass the arguments in the wrong order
10. # [00:03] <Hixie> i tried both orders
11. # [00:03] <annevk> targetOrigin comes before transfer
12. # [00:03] <Hixie> i tried both orders
13. # [00:07] * Quits: zcorpan (~zcorpan@pat.se.opera.com) (Quit: zcorpan)
14. # [00:07] * Quits: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi) (Ping timeout: 248 seconds)
15. # [00:10] * Quits: Lachy (~Lachy@cm-84.215.59.50.getinternet.no) (Quit: Computer has gone to sleep.)
16. # [00:11] * Quits: temp02 (~temp01@unaffiliated/temp01) (Ping timeout: 248 seconds)
17. # [00:11] * Joins: Lachy (~Lachy@cm-84.215.59.50.getinternet.no)
18. # [00:11] * Joins: temp01 (~temp01@unaffiliated/temp01)
19. # [00:12] * Joins: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi)
20. # [00:15] <Hixie> hey, check it out. my test was bogus after all and opera is not buggy, and webkit doesn't support both orders
21. # [00:15] <Hixie> <-- idiot
22. # [00:16] <Hixie> still, opera should throw, and does not, for postMessage('', '*', '*')
23. # [00:16] <annevk> if only you could read what you wrote the first time around
24. # [00:16] <gsnedders> Hixie: throw TypeError?
25. # [00:16] <Hixie> yeah
26. # [00:17] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
27. # [00:18] * Quits: tantek (~tantek@2620:101:8003:200:2484:2070:fe6d:b60e) (Quit: tantek)
28. # [00:24] * Joins: shans (shanesteph@nat/google/x-xfdqtvfpkzewuozj)
29. # [00:25] * Quits: annevk (~annevk@EM111-191-182-28.pool.e-mobile.ne.jp) (Ping timeout: 252 seconds)
30. # [00:26] * Quits: MikeSmith (~MikeSmith@EM111-191-182-28.pool.e-mobile.ne.jp) (Ping timeout: 252 seconds)
31. # [00:32] * Joins: MikeSmith (~MikeSmith@EM111-191-181-133.pool.e-mobile.ne.jp)
32. # [00:32] * Joins: annevk (~annevk@EM111-191-181-133.pool.e-mobile.ne.jp)
33. # [00:32] <annevk> cpearce, if fullscreen element or its ancestor is removed from document and that document has descendant documents with non-null fullscreen elements, should we fire events on those documents?
34. # [00:32] <annevk> cpearce, in Gecko per http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1210 that does not even seem possible
35. # [00:32] <annevk> cpearce, also, I guess the other question is in what scenario something like that happens and whether we need to deal with it
36. # [00:33] * Quits: jdaggett (~jdaggett@ad005178.dynamic.ppp.asahi-net.or.jp) (Quit: jdaggett)
37. # [00:33] <cpearce> annevk: if the descendents change out of full-screen mode due to an ancestor being removed, then yes, we should fire fullscreenchanged in them.
38. # [00:34] <annevk> cpearce, but as my test shows in e.g. Gecko you no longer have Document objects in such a scenario
39. # [00:35] <cpearce> annevk: hmmm....
40. # [00:35] <annevk> I also sort of fail to see the use case for catching this case, but it's not too hard
41. # [00:36] <annevk> The other question I had was about order of events relative to setting the "fullscreen element"
42. # [00:36] <annevk> do you fire the event after you have set/unset "fullscreen element" for the entire chain or do you do it per document?
43. # [00:36] * jernoble is now known as jernoble|afk
44. # [00:37] * jernoble|afk is now known as jernoble
45. # [00:37] <cpearce> I queue a task to fire the event as I traverse the doc tree making changes.
46. # [00:38] <cpearce> I'm in fact firing the change events for enter before change events for exit, but that's easily changeable.
47. # [00:38] <annevk> e.g. say the order becomes top-down when setting and bottom-up when unsetting, if I set and there's two documents, and the event dispatches on the first, the second still has a null fullscreen element?
48. # [00:39] <cpearce> The events won't dispatch until all docs in the tree have their fullscreen element set
49. # [00:39] <annevk> but you just said you fire them as you traverse?
50. # [00:39] <annevk> oh, queue a task
51. # [00:39] <cpearce> bingo.
52. # [00:40] <annevk> but then you can observe state separately
53. # [00:40] <cpearce> how?
54. # [00:40] <annevk> state change* e.g. in mutation events
55. # [00:41] <annevk> or from a timer
56. # [00:41] * Joins: tantek (~tantek@nat/mozilla/x-ksivtsscxiussffh)
57. # [00:41] <annevk> state change and event dispatch should always be coupled I think
58. # [00:42] <annevk> and I guess it makes sense you do it on a per-document basis since they might not be all related browsing contexts
59. # [00:42] <cpearce> I'm not sure what you mean. All the state change happens in the task which queues tasks to fire the events.
60. # [00:43] <annevk> doesn't that mean you can have other tasks running before the event is dispatched?
61. # [00:43] <cpearce> yep...
62. # [00:43] <annevk> e.g. in XHR you queue a task to change readyState and dispatch an event
63. # [00:44] <annevk> I think pretty much all APIs work that way
64. # [00:44] <cpearce> we have the same problem with the video spec, state can change before the event runs.
65. # [00:44] <cpearce> but fortunately you can query Document.fullscreen to tell if the target has entered or exited fullscreen...
66. # [00:46] <annevk> I don't really know the media API
67. # [00:47] <annevk> so why not have a single task which changes state and dispatches the event?
68. # [00:49] * Quits: ezoe (~ezoe@61-205-125-113f1.kyt1.eonet.ne.jp) (Ping timeout: 248 seconds)
69. # [00:50] * Quits: dbaron (~dbaron@66.207.208.98) (Quit: 8403864 bytes have been tenured, next gc will be global.)
70. # [00:51] <cpearce> annevk: It is simpler to implement with the events queued, since if you dispatch them synchronously in the task to change state, the world could change underneath you in the event handler. I can't really think of any reason from a user's perspective though.
71. # [00:51] * Quits: tantek (~tantek@nat/mozilla/x-ksivtsscxiussffh) (Quit: tantek)
72. # [00:54] <annevk> cpearce, so is requestFullscreen and exitFullscreen fully synchronous then?
73. # [00:54] <cpearce> annevk: at the moment they are for us.
74. # [00:54] <cpearce> we don't have an animation for enter, if you wanted an animation I think you'd need to make them async though.
75. # [00:55] <annevk> yeah, it seems like we would want that down the road
76. # [00:55] * Quits: shans (shanesteph@nat/google/x-xfdqtvfpkzewuozj) (Quit: shans)
77. # [00:55] <cpearce> we have a bug on file for that too.
78. # [00:55] <annevk> I wonder what sicking thinks of changing state sync and notifying async
79. # [00:56] * Quits: Amorphous (jan@unaffiliated/amorphous) (Ping timeout: 248 seconds)
80. # [00:57] * jernoble is now known as jernoble|afk
81. # [00:57] <annevk> I guess you pretty much have to change state sync for :fullscreen
82. # [00:57] * jernoble|afk is now known as jernoble
83. # [00:59] * Joins: shans (shanesteph@nat/google/x-emwxybrkrwwhdlqs)
84. # [00:59] <annevk> and someone needs to verify for me this doesn't fuck with "unit of related similar-origin browsing contexts"
85. # [00:59] <annevk> because I cannot really work it out
86. # [01:00] <annevk> I guess it might in a way
87. # [01:01] <annevk> cpearce, what if the top-level browsing context is already busy while you call requestFullscreen, don't you get blockage?
88. # [01:01] <annevk> I guess currently there's no multi-process going on for that in Gecko
89. # [01:02] <cpearce> mmmm.... we have one process, and are moving to conceptually one process per tab, so that can't happen (I think...).
90. # [01:03] <cpearce> and in multi-process firefox I dispatch an event to the chrome process to make it fullscreen, so it is technically async to make the window full-screen, but I've not focused too much on that yet.
91. # [01:04] <cpearce> since we're a few months out from enabling multi-process by default.
92. # [01:06] * Quits: Telling (~unknown@80-71-135-15.u.parknet.dk) (Quit: ...)
93. # [01:06] <annevk> yeah I guess the method can just wait
94. # [01:06] <annevk> you can probably not cause deadlock so I guess it should be okay, but it would be nice if someone could verify
95. # [01:07] <annevk> don't really want to prevent implementations that have multi-process outside per-tab
96. # [01:07] <annevk> I think e.g. Chrome wanted to move in that direction
97. # [01:07] <cpearce> yeah.
98. # [01:09] <annevk> btw
99. # [01:09] <annevk> fullscreendeny, would that fire async too?
100. # [01:10] * Quits: benjoffe (~benjoffe_@CPE-121-218-225-100.lnse4.cht.bigpond.net.au) (Read error: Connection reset by peer)
101. # [01:10] <cpearce> I think it should match fullscreenchange, so yes.
102. # [01:11] <annevk> do we use "deny" elsewhere in the platform?
103. # [01:11] <annevk> could make it fullscreenerror I suppose... meh
104. # [01:11] * Joins: Amorphous (jan@unaffiliated/amorphous)
105. # [01:13] <cpearce> fullscreendenied matches tense with fullscreenchanged, and matches tense with the events fired in the video spec, many of which are past tense. I don't really know the other HTML specs.
106. # [01:14] <annevk> well "changed" is going to become "change"
107. # [01:15] <annevk> we have hashchange for instance
108. # [01:16] <cpearce> I think it makes sense for it to be past tense if it's dispatched async.
109. # [01:17] * jernoble is now known as jernoble|afk
110. # [01:18] <AryehGregor> hashchange is surely dispatched async.
111. # [01:19] <annevk> generally events do not use past tense
112. # [01:19] <annevk> there's a couple for which it was a mistake
113. # [01:20] <annevk> but we have volumechange, durationchange, ratechange
114. # [01:20] <Hixie> hashchange is fired synchronously from within a task that is itself async
115. # [01:22] <cpearce> argh, what am I saying, our implementation already dispatches mozfullscreenchange, not *changed. :P
116. # [01:22] <annevk> Hixie, can you dispatch events on documents that are not the active document?
117. # [01:22] <cpearce> I do think it sounds funny having a fullscreendeny event though.
118. # [01:23] <Hixie> annevk: well
119. # [01:23] <annevk> fullscreenerror might be somewhat better
120. # [01:23] <cpearce> well, it's not really an error though.
121. # [01:23] <Hixie> annevk: you mean using that document as the context? you can, but the task would just sit in the queue until it became active
122. # [01:23] <annevk> okay
123. # [01:23] <Hixie> i would avoid it where possible though
124. # [01:24] <Hixie> since the doc could get discarded any minute anyway
125. # [01:24] <annevk> Hixie, if you remove an <iframe> from a document does that <iframe>'s document become inactive?
126. # [01:25] <Hixie> this part of the spec is a little controversial, but:
127. # [01:25] <annevk> cpearce, if you navigate a child browsing context that has a fullscreen element in it, and then navigate back, is it still the fullscreen element?
128. # [01:25] <Hixie> annevk: it is "active" but not "fully active"
129. # [01:26] <annevk> okay
130. # [01:26] <Hixie> annevk: it stops getting events and stuff though, iirc
131. # [01:26] <cpearce> annevk: We should exit full-screen mode when a full-screen document navigates.
132. # [01:27] <Hixie> annevk: (because the event loop only takes tasks for docs that are fully active)
133. # [01:28] <annevk> cpearce, the top-level browsing context?
134. # [01:28] <annevk> Hixie, thanks
135. # [01:29] <cpearce> annevk: If we navigate a non-full-screen child iframe and the parent is full-screen, there's no need to break out of full-screen.
136. # [01:29] <annevk> cpearce, right
137. # [01:30] <annevk> cpearce, but what if you navigate a child frame that contains a fullscreen element?
138. # [01:30] <annevk> I mean the top-level browsing context will still have a fullscreen element in that case too
139. # [01:31] <cpearce> annevk: It seems that if a document has a full-screen element, it must be full-screen? So since it's full-screen we should exit full-screen mode?
140. # [01:32] <smaug____> annevk: how does "fullscreendeny"/"...error" solve the problem that it may take arbitrary amount time for user to decide whether to allow the fullscreen mode
141. # [01:32] <annevk> your use of fullscreen confuses me, do you mean exit it for that document only or the whole top-level-browsing context?
142. # [01:33] <cpearce> smaug: we use a ask forgiveness model now, so the decision to deny can be made synchronously.
143. # [01:33] <smaug____> ?
144. # [01:33] <cpearce> annevk: If we exit for one, we exit for all.
145. # [01:33] <smaug____> user many not allow or deny
146. # [01:33] <smaug____> user may just be slow to say anything
147. # [01:34] <zewt> i notify in advance that i will not forgive any browser vendor that lets pages show fullscreen ads at me
148. # [01:34] <annevk> cpearce, okay
149. # [01:34] <cpearce> smaug: I mean, *we* don't have UI which requires the user to approve requests for full-screen, we just go full-screen and give them the option to exit. I guess though you're concerned about vendors which do want to implement an approval UI...
150. # [01:35] <smaug____> that is no-go
151. # [01:35] <smaug____> I'm pretty sure vendors don't want to implement such thing
152. # [01:35] <zewt> (pretty disconcerting that it seems nobody but me seems to care if pages are allowed to show fullscreen ads)
153. # [01:36] <smaug____> going to fullscreen *must* ask permission
154. # [01:36] <smaug____> (or the permission can be given beforehand)
155. # [01:36] <cpearce> if you put ads in an iframe they won't be able to go full-screen unless there's a fullscreenallowed attribute on the iframe.
156. # [01:36] <zewt> smaug____: but from what i've heard, both FF and Chrome intend to go fullscreen without asking (and then asking after it's too late) ...
157. # [01:36] <smaug____> uh
158. # [01:37] <smaug____> that sure hasn't been security reviewed
159. # [01:37] <zewt> which i find horrifying
160. # [01:37] <smaug____> it sounds absolute horrifying
161. # [01:37] <cpearce> That has. We show a bug warning to make it obvious you've gone fullscreen.
162. # [01:37] <zewt> i don't want a big, obnoxious warning every time i go fullscreen (like Flash does), that's also bad
163. # [01:37] <gsnedders> IMO Flash's behaviour is fine.
164. # [01:38] <zewt> and ... again, that doesn't solve the problem that it's letting pages go fullscreen to show ads (asking after is *too late* then)
165. # [01:38] <zewt> (it's already shoved a gigantic ad in my face)
166. # [01:38] <gsnedders> To go full-screen, the change must either happen as a result of a user initiated action, or must be confirmed by the user, IMO.
167. # [01:38] <smaug____> cpearce: what is the reason to allow web page to do such a major change to the UI without asking user's permission?
168. # [01:39] <gsnedders> Which addresses all the major uses of Flash full-screen I can think of.
169. # [01:39] <cpearce> right, the fullscreen request is only granted in user initiated action.
170. # [01:39] <zewt> gsnedders: both of those are still intending to require it to be within a click/keypress, but that doesn't solve these problems
171. # [01:39] <cpearce> So permission is implicit.
172. # [01:39] <zewt> uh
173. # [01:39] * gsnedders is rather out-of-touch of all of this stuff, though
174. # [01:39] <zewt> sorry, "implicit permission" doesn't make sense, heh
175. # [01:40] <gsnedders> zewt: If it's harder to do than in Flash, people will keep using Flash for stuff like full-screen video.
176. # [01:40] <smaug____> clicking something on the page is not the same as giving permission
177. # [01:40] <gsnedders> So we can't make it considerably harder than with Flash, IMO.
178. # [01:40] <gsnedders> Like, a site moving to HTML for video shouldn't regress the UX.
179. # [01:40] * eric_carlson is now known as ericc|away
180. # [01:40] <gsnedders> By asking permission extra times.
181. # [01:41] <zewt> gsnedders: importing major problems of Flash into HTML because people will continue to use Flash is a very poor rationale--there's a *reason* i use flashblock!
182. # [01:41] <zewt> (of course, any sane UI would have the major response be "allow this, and don't ask in the future", so you usually only have to agree to it the first time)
183. # [01:42] <gsnedders> If I press a button on YouTube to go full screen, I damn well want it to go full screen. I don't want to then have to confirm it. Even the first time.
184. # [01:42] <smaug____> (there is a reason why I don't have Flash installed in this browser profile)
185. # [01:42] <zewt> gsnedders: that implies pages being able to smear gigantic ads in my face without permission; so I say, too bad, live with it
186. # [01:42] <zewt> no way that I can see of allowing one without the other
187. # [01:44] <zewt> it's bad enough that I'm afraid to click anywhere in the window on things like image hosts, for fear that a page will use it to open a popup; this would be so much worse
188. # [01:44] <annevk> not "too bad", if we're not competitive with the usability of Flash people will just use that
189. # [01:44] <gsnedders> Yeah. If it's too restrictive people simply won't use it.
190. # [01:45] <smaug____> zewt: with Chrome you can fear also that clicking anywhere in the window starts recording and sending your audio to google ;)
191. # [01:45] <zewt> if flash lets people format the user's hard drive, we'd have to let them do that too, or they'll just keep using flash? heh
192. # [01:46] <gsnedders> zewt: There's a rather large difference.
193. # [01:46] <zewt> smaug____: sounds like a massive security hole
194. # [01:46] <annevk> non-rational arguments ftw
195. # [01:46] <zewt> gsnedders: difference of magnitude only
196. # [01:46] <annevk> o_O
197. # [01:46] <zewt> the idea that html has to let people do everything flash does, regardless of if that causes serious, obnoxious problems on the web, is a bad one
198. # [01:46] <smaug____> zewt: that is Google's "clicking gives permission" -permission model
199. # [01:46] <annevk> but that's not the idea
200. # [01:47] <zewt> sure seems like it
201. # [01:47] * Quits: riven (~riven@pdpc/supporter/professional/riven) (Read error: Operation timed out)
202. # [01:48] <annevk> then you haven't really been paying attention
203. # [01:48] <zewt> non-rational arguments ftw
204. # [01:49] <zewt> disagreeing with me doesn't mean i havn't been paying attention
205. # [01:49] <annevk> e.g. we didn't copy the crossdomain.xml disaster
206. # [01:49] <zewt> no, you designed something better for its use cases; you're not doing that here
207. # [01:50] <annevk> I don't really see a better way here to be honest
208. # [01:50] <annevk> I also hardly see the popup abuse you talk about
209. # [01:51] <annevk> making the popular use case impossibly annoying is just not going to work
210. # [01:51] <zewt> plenty of random sites open popups during the first click event they see, to work around the user-interaction restriction
211. # [01:51] <zewt> (don't have one off-hand)
212. # [01:52] <zewt> how is it "impossibly annoying"? it's the model used by geolocation
213. # [01:55] <annevk> geolocation is infrequent, fullscreen is frequent
214. # [01:55] <zewt> hardly infrequent if you're searching on mobile
215. # [01:55] <smaug____> how often do you use fullscreen, I mean from different domains?
216. # [01:56] * jernoble|afk is now known as jernoble
217. # [01:56] <gsnedders> I find it annoying in the geolocation case, but I think that's partly a UI issue.
218. # [01:57] <annevk> smaug____, pretty often I think, mostly for video, sometimes slideshows
219. # [01:57] <smaug____> and they are really from different domains?
220. # [01:58] <zewt> smaug____: FF6's geoloc confirmation box is sort of annoying, because you have to open a dropdown to get to the most common answer for most people (always)
221. # [01:58] * gsnedders is more than happy to try full-screen with explicit user confirmation first, but will need to watch for user feedback
222. # [01:58] <smaug____> I would have guessed most of the fullscreen usage comes from youtube
223. # [01:58] <zewt> three "yes"/"no"/"just this once" buttons would be nicer
224. # [01:58] <annevk> smaug____, there's quite a bit of self-hosted video out there as well
225. # [02:00] <zewt> i suppose also because the confirmation is "out-of-line"; at least for mouse-initiated events, it'd be nicer (at least for fullscreen buttons) if the box appeared over the button you clicked
226. # [02:00] <smaug____> zewt: I don't recall what FF6 did. Nightly has IMO quite good UI for geolocation permission
227. # [02:00] <annevk> cpearce, can you reply to Darin Fisher on the mailing list with Mozilla's use cases for not ignoring calls to requestFullscreen while fullscreen?
228. # [02:01] <cpearce> sure.
229. # [02:01] <zewt> smaug____: http://zewt.org/~glenn/ff6%20doorhanger.png
230. # [02:01] <smaug____> zewt: seems like Nightly has that
231. # [02:01] <smaug____> and it is IMO ok API
232. # [02:02] <smaug____> s/API/UI/
233. # [02:02] <zewt> it's not bad, but could be streamlined as I said ^
234. # [02:02] <smaug____> you can click share, or just ignore the whole thing
235. # [02:02] <zewt> better than a modal dialog, obviously
236. # [02:03] <smaug____> the point is that if you don't want to share, you don't need to do anything
237. # [02:03] <smaug____> and if you explicitly want to share always, you need to click once more
238. # [02:04] <zewt> yeah, but again, my most common answer (always) is a clumsier two-step UI, and if that was used for confirming fullscreen, it's inconveniently way in the corner instead of near whatever fullscreen button I clicked (putting aside keyboard events)
239. # [02:05] <smaug____> is always the most common answer?
240. # [02:05] <zewt> i can't speak for everyone :)
241. # [02:05] <smaug____> to me the most common answer is "I don't care", so I don't click anything
242. # [02:05] <smaug____> and next most common answer is, "ok, allow this time"
243. # [02:06] <zewt> for me in the fullscreen case, i'm pretty sure the only two i'd use are "always" and "no"
244. # [02:07] <zewt> ("always" if it's a fullscreen I actually requested; "never" if it's a mysterious attempt to go fullscreen that I didn't ask for)
245. # [02:07] * Quits: shans (shanesteph@nat/google/x-emwxybrkrwwhdlqs) (Quit: shans)
246. # [02:15] <Hixie> why does opera not work on http://www.hixie.ch/tests/adhoc/dom/css/StyleSheet/002.html ?
247. # [02:16] * jernoble is now known as jernoble|afk
248. # [02:16] <Hixie> wait, IE doesn't either now
249. # [02:16] <Hixie> aw man, what have i done now
250. # [02:16] <zewt> Hixie: the tried and true "paste on irc" debugging technique
251. # [02:18] <Hixie> ok IE's problem is it misteriously only finds 2 links
252. # [02:18] <Hixie> but what's opera doing
253. # [02:18] <Hixie> o_O
254. # [02:18] <Hixie> opera's not running the timeout? o_O
255. # [02:18] <gsnedders> Hixie: I wonder if the setTimeout is running not when you think it is
256. # [02:19] <Hixie> maybe
257. # [02:19] <gsnedders> Hixie: It's running it. After it has run the second script.
258. # [02:19] <Hixie> how can that be
259. # [02:19] <Hixie> it's a 100ms timeout and the third link takes 2 seconds to load
260. # [02:19] * Quits: jacobolus (~jacobolus@c-71-198-169-213.hsd1.ca.comcast.net) (Remote host closed the connection)
261. # [02:19] * Joins: davidb_ (~davidb@bas1-toronto06-2925210074.dsl.bell.ca)
262. # [02:20] <gsnedders> Hixie: DSE enabled?
263. # [02:20] <Hixie> DSE?
264. # [02:20] <gsnedders> Delayed Script Execution
265. # [02:20] <Hixie> what is that?
266. # [02:20] <gsnedders> opera:config#Extensions|DelayedScriptExecution
267. # [02:21] <gsnedders> Hmm, has no effect.
268. # [02:21] <gsnedders> Hixie: speculative parsing + some more complexity
269. # [02:23] * Joins: myakura (~myakura@FL1-203-136-164-250.tky.mesh.ad.jp)
270. # [02:24] <gsnedders> Hixie: Are you sure Opera blocks on link elements?
271. # [02:25] * Joins: tantek (~tantek@99.22.229.14)
272. # [02:25] <gsnedders> Hixie: Note that behaviour is likely different between Op12 and Op11.50
273. # [02:26] * jernoble|afk is now known as jernoble
274. # [02:26] <Hixie> yes, opera is blocking (for more than 150ms) on the link elements.
275. # [02:26] <Hixie> but it's blocking less than 1000ms
276. # [02:26] <Hixie> or something
277. # [02:26] <Hixie> i can't say i understand what opera is doing
278. # [02:27] <Hixie> oh no
279. # [02:27] <_bga> http://www.youtube.com/watch?v=Ws6AAhTw7RA
280. # [02:27] <Hixie> i was timing it wrong
281. # [02:27] <Hixie> ok, opera isn't blocking at all
282. # [02:27] <Hixie> ok that's another bug then :-)
283. # [02:28] <Hixie> it acts like it's blocking
284. # [02:28] <Hixie> i mean, the page takes 2 seconds to load and all
285. # [02:28] <annevk> that you can detect it is prolly a bug
286. # [02:28] <Hixie> i don't understand what opera's doing at all. it has all the disadvantages of blocking and none of the advantages.
287. # [02:28] * Joins: shans (shanesteph@nat/google/x-uiitofclmqycrueg)
288. # [02:28] <annevk> oh
289. # [02:28] <annevk> that does sound wrong
290. # [02:30] <gsnedders> AFAIK it only blocks on a CSSOM call while there is a stylesheet yet to load
291. # [02:31] <gsnedders> Or at least that's the theory
292. # [02:31] <gsnedders> So, on the whole, I think the .sheet accesses block
293. # [02:31] * Quits: jamesr (jamesr@nat/google/x-xijuhbjacodrccpe) (Ping timeout: 240 seconds)
294. # [02:31] * Quits: smaug____ (~chatzilla@GYYYKMMCCVI.gprs.sl-laajakaista.fi) (Ping timeout: 260 seconds)
295. # [02:33] * Quits: myakura (~myakura@FL1-203-136-164-250.tky.mesh.ad.jp) (Remote host closed the connection)
296. # [02:38] * Joins: shepazu (~shepazu@pool-173-76-153-144.bstnma.fios.verizon.net)
297. # [02:39] * Joins: riven (~riven@53518387.cm-6-2c.dynamic.ziggo.nl)
298. # [02:39] * Quits: riven (~riven@53518387.cm-6-2c.dynamic.ziggo.nl) (Changing host)
299. # [02:39] * Joins: riven (~riven@pdpc/supporter/professional/riven)
300. # [02:39] * Quits: tantek (~tantek@99.22.229.14) (Quit: tantek)
301. # [02:39] * Quits: saba (~foo@unaffiliated/saba) (Quit: leaving)
302. # [02:40] * Quits: KillerX (~anant@nat/mozilla/x-lsevappdtcxehqat) (Ping timeout: 258 seconds)
303. # [02:41] <Hixie> gsnedders: so why doesn't the script run until after parsing has finished?
304. # [02:41] <Hixie> gsnedders: note how parsed gets set to true
305. # [02:41] <Hixie> oh wait, i see what you're saying
306. # [02:41] * Quits: davidb_ (~davidb@bas1-toronto06-2925210074.dsl.bell.ca) (Quit: davidb_)
307. # [02:42] <Hixie> interesting
308. # [02:42] <Hixie> so opera blocks the script itself
309. # [02:42] <Hixie> huh
310. # [02:43] * Quits: shepazu (~shepazu@pool-173-76-153-144.bstnma.fios.verizon.net) (Client Quit)
311. # [02:43] <annevk> yeah, we just stop script executing until loading and parsing is done
312. # [02:43] <annevk> execution*
313. # [02:43] * Quits: cygri (~cygri@wg1-nat.fwgal01.deri.ie) (Quit: cygri)
314. # [02:45] * Joins: davidb (~davidb@bas1-toronto06-2925210074.dsl.bell.ca)
315. # [02:45] * Joins: mkanat (mkanat@nat/google/x-xiwkwejrulpymtlf)
316. # [02:46] * jernoble is now known as jernoble|afk
317. # [02:56] * Quits: danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl) (*.net *.split)
318. # [02:56] * Quits: zewt (~x@c-24-62-196-44.hsd1.ma.comcast.net) (*.net *.split)
319. # [02:56] * Quits: robman (~robman@eth4584.nsw.adsl.internode.on.net) (*.net *.split)
320. # [02:56] * Quits: hamaji (~hamaji@220.109.219.244) (*.net *.split)
321. # [02:56] * Quits: Hixie (~ianh@trivini.no) (*.net *.split)
322. # [02:56] * Quits: reggna (~reggna@godis.olf.sgsnet.se) (*.net *.split)
323. # [02:56] * Quits: Necrathex (~nectop@82-170-160-25.ip.telfort.nl) (*.net *.split)
324. # [02:56] * Quits: Martijnc (~Martijn@d54C02C64.access.telenet.be) (*.net *.split)
325. # [02:56] * Quits: asmodai (asmodai@178-85-121-247.dynamic.upc.nl) (*.net *.split)
326. # [02:56] * Quits: tomaw (tom@freenode/staff/tomaw) (*.net *.split)
327. # [02:56] * Quits: [tm] (~MikeSmith@sideshowbarker.net) (*.net *.split)
328. # [02:56] * Quits: PrgmrBill (~PrgmrBill@unaffiliated/prgmrbill) (*.net *.split)
329. # [02:56] * Quits: tellnes (~KrooniX@ec2-79-125-26-36.eu-west-1.compute.amazonaws.com) (*.net *.split)
330. # [02:56] * Quits: moo-_- (~quassel@herd37.twinapex.fi) (*.net *.split)
331. # [02:56] * Quits: broquaint (a52b469f90@78.47.79.137) (*.net *.split)
332. # [02:56] * Quits: wilhelm (~wilhelm@trivini.no) (*.net *.split)
333. # [02:56] * Quits: michel_v (~tofu@unaffiliated/michelv/x-000000001) (*.net *.split)
334. # [02:56] * Quits: davidb (~davidb@bas1-toronto06-2925210074.dsl.bell.ca) (*.net *.split)
335. # [02:56] * Quits: sicking (~chatzilla@206-15-76-122.static.twtelecom.net) (*.net *.split)
336. # [02:56] * Quits: ryanseddon (u1832@gateway/web/irccloud.com/x-sjgqcbalxyjiricd) (*.net *.split)
337. # [02:56] * Quits: fishd (darin@nat/google/x-tpxeypsisgwvuqjw) (*.net *.split)
338. # [02:56] * Quits: GPHemsley (~GPHemsley@pdpc/supporter/student/GPHemsley) (*.net *.split)
339. # [02:56] * Quits: temp01 (~temp01@unaffiliated/temp01) (*.net *.split)
340. # [02:56] * Quits: foolip (~philip@83.218.67.122) (*.net *.split)
341. # [02:56] * Quits: jdong_ (~quassel@222.126.155.250) (*.net *.split)
342. # [02:56] * Quits: volkmar (~volkmar@gentoo/developer/volkmar) (*.net *.split)
343. # [02:56] * Quits: twisted` (~twisted@205.189.73.45) (*.net *.split)
344. # [02:56] * Quits: othree (~othree@admin39.ct.ntust.edu.tw) (*.net *.split)
345. # [02:56] * Quits: pererik (~pe@unaffiliated/pererik) (*.net *.split)
346. # [02:56] * Quits: doublec (~doublec@unaffiliated/doublec) (*.net *.split)
347. # [02:56] * Quits: krijn (u2319@gateway/web/irccloud.com/x-sslxwkyblevwmrqp) (*.net *.split)
348. # [02:56] * Quits: beowulf (u116@pdpc/supporter/professional/beowulf) (*.net *.split)
349. # [02:56] * Quits: Philip` (~philip@zaynar.co.uk) (*.net *.split)
350. # [02:56] * Quits: jgraham (~jgraham@web22.webfaction.com) (*.net *.split)
351. # [03:00] * Joins: davidb (~davidb@bas1-toronto06-2925210074.dsl.bell.ca)
352. # [03:00] * Joins: temp01 (~temp01@unaffiliated/temp01)
353. # [03:00] * Joins: sicking (~chatzilla@206-15-76-122.static.twtelecom.net)
354. # [03:00] * Joins: danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl)
355. # [03:00] * Joins: foolip (~philip@83.218.67.122)
356. # [03:00] * Joins: ryanseddon (u1832@gateway/web/irccloud.com/x-sjgqcbalxyjiricd)
357. # [03:00] * Joins: jdong_ (~quassel@222.126.155.250)
358. # [03:00] * Joins: Necrathex (~nectop@82-170-160-25.ip.telfort.nl)
359. # [03:00] * Joins: zewt (~x@c-24-62-196-44.hsd1.ma.comcast.net)
360. # [03:00] * Joins: volkmar (~volkmar@gentoo/developer/volkmar)
361. # [03:00] * Joins: robman (~robman@eth4584.nsw.adsl.internode.on.net)
362. # [03:00] * Joins: michel_v (~tofu@unaffiliated/michelv/x-000000001)
363. # [03:00] * Joins: twisted` (~twisted@205.189.73.45)
364. # [03:00] * Joins: Martijnc (~Martijn@d54C02C64.access.telenet.be)
365. # [03:00] * Joins: fishd (darin@nat/google/x-tpxeypsisgwvuqjw)
366. # [03:00] * Joins: reggna (~reggna@godis.olf.sgsnet.se)
367. # [03:00] * Joins: Hixie (~ianh@trivini.no)
368. # [03:00] * Joins: hamaji (~hamaji@220.109.219.244)
369. # [03:00] * Joins: asmodai (asmodai@178-85-121-247.dynamic.upc.nl)
370. # [03:00] * Joins: othree (~othree@admin39.ct.ntust.edu.tw)
371. # [03:00] * Joins: pererik (~pe@unaffiliated/pererik)
372. # [03:00] * Joins: GPHemsley (~GPHemsley@pdpc/supporter/student/GPHemsley)
373. # [03:00] * Joins: wilhelm (~wilhelm@trivini.no)
374. # [03:00] * Joins: broquaint (a52b469f90@78.47.79.137)
375. # [03:00] * Joins: moo-_- (~quassel@herd37.twinapex.fi)
376. # [03:00] * Joins: tellnes (~KrooniX@ec2-79-125-26-36.eu-west-1.compute.amazonaws.com)
377. # [03:00] * Joins: PrgmrBill (~PrgmrBill@unaffiliated/prgmrbill)
378. # [03:00] * Joins: [tm] (~MikeSmith@sideshowbarker.net)
379. # [03:00] * Joins: tomaw (tom@freenode/staff/tomaw)
380. # [03:00] * Joins: doublec (~doublec@unaffiliated/doublec)
381. # [03:00] * Joins: jgraham (~jgraham@web22.webfaction.com)
382. # [03:00] * Joins: Philip` (~philip@zaynar.co.uk)
383. # [03:00] * Joins: beowulf (u116@pdpc/supporter/professional/beowulf)
384. # [03:00] * Joins: krijn (u2319@gateway/web/irccloud.com/x-sslxwkyblevwmrqp)
385. # [03:01] * Joins: agektmr (~Adium@220.109.219.244)
386. # [03:02] * Joins: yuuki (~kobayashi@58x158x182x50.ap58.ftth.ucom.ne.jp)
387. # [03:07] * Quits: ap_ (~ap@2620:149:4:1b01:89f7:195f:c205:606e) (Quit: ap_)
388. # [03:08] * Joins: jacobolus (~jacobolus@c-67-164-92-84.hsd1.ca.comcast.net)
389. # [03:12] <annevk> when is Chrome going to return "" for canPlayType("video/mp4")?
390. # [03:13] <annevk> "next couple months" in http://blog.chromium.org/2011/01/html-video-codec-support-in-chrome.html for a reasonable definition of "next couple" has not really happened it seems
391. # [03:13] <annevk> or am I missing something?
392. # [03:15] * Quits: _bga (~bga@ppp78-37-224-175.pppoe.avangarddsl.ru) (Read error: Connection reset by peer)
393. # [03:16] * Quits: astearns (~anonymous@192.150.22.5) (Ping timeout: 260 seconds)
394. # [03:16] * Quits: jennb (jennb@nat/google/x-zrvdbebzjojnstkx) (Quit: jennb)
395. # [03:18] * Joins: shepazu (~shepazu@pool-173-76-153-144.bstnma.fios.verizon.net)
396. # [03:18] * Quits: jwalden (~waldo@2620:101:8003:200:224:d7ff:fef0:8d90) (Quit: ChatZilla 0.9.87-2.1450hg.fc15 [XULRunner 7.0.1/20110930134335])
397. # [03:24] <annevk> cpearce, so given what Hixie said earlier about inactive documents it seems not dispatching fullscreenchange on removed documents or documents navigated away from is the way to go
398. # [03:26] <cpearce> no. we should still dispatch, so that if the document is re-added or navigated back to, it gets a notification. otherwise if we navigate back, it will still think it's in fullscreen mode. we'd need to rely on the event not being dispatched until the doc is reactivated though (if I understood that correctly that should happen?)
399. # [03:27] <cpearce> does that make sense?
400. # [03:27] <annevk> I guess we could do that too, but Hixie said he rather avoids it
401. # [03:28] <annevk> cpearce, btw, for requestFullscreen if you are already fullscreen, exitFullscreen is going to do the wrong thing
402. # [03:28] <cpearce> how so?
403. # [03:29] <annevk> I'm on site A that embeds site B
404. # [03:29] <annevk> site A does requestFullscreen
405. # [03:29] <annevk> then site B does requestFullscreen
406. # [03:29] <annevk> then site B does exitFullscreen
407. # [03:29] * Quits: othermaciej (~mjs@17.245.89.72) (Quit: othermaciej)
408. # [03:29] <annevk> A is no longer fullscreen
409. # [03:30] * Joins: nattokirai (~nattokira@rtr.mozilla.or.jp)
410. # [03:30] <cpearce> hmmm. true.
411. # [03:31] <annevk> so either the entire design needs a revamp to allow for a single browsing context go in and out of fullscreen rather than a whole set or we should give up on this use case
412. # [03:32] <annevk> I think
413. # [03:32] * Quits: dave_levin (dave_levin@nat/google/x-oksemwthusvmifia) (Quit: dave_levin)
414. # [03:39] <cpearce> how annoying.
415. # [03:39] <annevk> is it easy to display a single browsing context (including descendants of course) fullscreen?
416. # [03:40] <annevk> basically displaying fullscreen on a per-Document basis
417. # [03:40] <annevk> that way you can have a nested stack if so desired
418. # [03:41] <annevk> and it would definitely make the whole dispatch "fullscreenchange" everywhere stuff easier
419. # [03:41] <annevk> since that will only affect a single document
420. # [03:42] <annevk> also solves the potential cross-process issue
421. # [03:42] <cpearce> Not really. then you need to pop the rendering of documents out of their rendering targets, which greatly complicates things. With the nested full-screen approach, all you need is to apply css rules, and you're there.
422. # [03:42] * Quits: davidb (~davidb@bas1-toronto06-2925210074.dsl.bell.ca) (Quit: davidb)
423. # [03:45] <annevk> sigh
424. # [03:46] <annevk> the other way is pretty silly too though
425. # [03:46] <annevk> not being able to fullscreen a video while fullscreen
426. # [03:49] * Joins: macpherson (macpherson@nat/google/x-quzvgwvcnqmxehkn)
427. # [03:53] <cpearce> annevk: I think we should just have exitFullScreen() exit fullscreen state on the document and all descendent documents. Then in my powerpoint/video use case, users can use the video controls to exit fullscreen on the video element but remain in fullscreen in the slide deck. The UA can and should break out of all fullscreen on ESC keypress though, where they'll call exitFullScreen() on the...
428. # [03:53] <cpearce> ...root doc.
429. # [03:54] <cpearce> where the UA will call exitFullScreen() on the root doc that is. Users should be absolutely sure that when they press ESC, they've exited fullscreen.
430. # [03:55] <annevk> it should probably also set the frame element of the parent document to null or some such
431. # [03:56] <annevk> otherwise B is still fullscreen
432. # [03:56] <annevk> just not its embedded video (maybe)
433. # [03:58] <cpearce> right, exitFullScreen() on the root document should reset fullscreen state (Document.fullscreenElement, Document.fullscreen) on the root document and all its descendents. So it would exit fullscreen in all documents completely.
434. # [03:58] <cpearce> I wonder if that's going to confuse people...
435. # [03:59] <annevk> I'm not talking about the root document
436. # [03:59] <annevk> A embeds B
437. # [03:59] <annevk> through <iframe> A1
438. # [03:59] <annevk> if B goes fullscreen A1 will become the fullscreen element of A
439. # [04:00] <annevk> if B then invokes exitFullscreen that should be reset somehow
440. # [04:02] <cpearce> right, I get you. I guess that should become null as you suggest, which is equivalent to making A's document fullscreen without a specific fullscreen element.
441. # [04:04] <annevk> I think it would also make sense that requestFullscreen can only be invoked for a descendant of the current fullscreen document
442. # [04:05] <annevk> so you only traverse in one direction
443. # [04:05] <annevk> cpearce, should we add document.requestFullscreen?
444. # [04:07] * Quits: rniwa (rniwa@nat/google/x-etcslgbyevuicrvr) (Quit: rniwa)
445. # [04:08] <cpearce> annevk: I don't think we really need document.requestFullscreen, you can just use document.body.requestFullscreen(). When I said "making A's document fullscreen..." the result is its body is displayed fullscreen, though it's not reported as the fullscreen element in Document.fullscreenElement.
446. # [04:10] <annevk> given the current styling rules the result is most definitely not the same
447. # [04:11] <annevk> we could of course have exitFullscreen on a descendant of the top-level browsing context make it set the fullscreen element of its parent to its parent root element
448. # [04:13] <cpearce> how is document.body.requestFullScreen() not the same as document.requestFullScreen()?
449. # [04:13] <cpearce> I guess document.body != root?
450. # [04:13] <annevk> depends on how you define things
451. # [04:14] <annevk> I'm just saying that setting A's fullscreen element to null is probably not the correct way here
452. # [04:14] * Quits: necolas (~necolas@5e0c0fc8.bb.sky.com) (Remote host closed the connection)
453. # [04:16] <cpearce> If we dispatch a fullscreenchange event when we change A's fullscreen element (to whatever) then A will have the opportunity to request the fullscreen element to what it meant it to be.
454. # [04:17] <cpearce> And yeah, only granting requests for fullscreen in a descendant of the fullscreen document (if there is one) simplifies implementation. I can't really think of a case were it would be useful to grant requests from sibling/cousin documents.
455. # [04:17] <annevk> that'll give you flickering, but I guess that's somewhat acceptable
456. # [04:17] <annevk> for this use case you want the root element to be the fullscreen element anyway I think
457. # [04:18] <annevk> cpearce, about the styling rules, should we have transform:none for :fullscreen-ancestor and probably disable transitions/animations?
458. # [04:18] <annevk> cpearce, also seems like background:black needs to be complemented by color:#fff or some such
459. # [04:19] * Joins: davidb (~davidb@bas1-toronto06-2925210074.dsl.bell.ca)
460. # [04:20] * Joins: jamesr (jamesr@nat/google/x-zdwvumueuwrtifer)
461. # [04:20] <cpearce> annevk: not sure about transfoms etc. That's outside of my expertise. Probably worth suggesting.
462. # [04:22] * Joins: astearns (~anonymous@c-50-132-63-33.hsd1.wa.comcast.net)
463. # [04:22] <annevk> they create stacking contexts afaik, so...
464. # [04:22] <annevk> will discuss with roc at some point I guess
465. # [04:22] <annevk> better sort the API side out first
466. # [04:25] <roc> yeah we should have transform:none
467. # [04:25] * Joins: scor (~scor@drupal.org/user/52142/view)
468. # [04:27] <roc> whether cancelling fullscreen on a subdocument also cancels fullscreen on the parent document is a tricky one
469. # [04:28] <roc> we may need some per-document flag to indicate whether the document requested fullscreen
470. # [04:29] <annevk> yeah
471. # [04:29] <annevk> because now in the A B case above
472. # [04:29] <annevk> if B calls requestFullscreen and then exitFullscreen
473. # [04:29] <annevk> A would still be fullscreen
474. # [04:29] <annevk> which is obviously wrong
475. # [04:29] <roc> there are use-cases where it should cancel fullscreen on the parent, and use-cases where it shouldn't
476. # [04:29] <annevk> cpearce, ^^
477. # [04:29] <roc> maybe if we have a per-doc flag to indicate whether it wants to be fullscreen
478. # [04:29] <annevk> I guess we need to track which documents went fullscreen
479. # [04:30] <roc> which is set on requestFullScreen, and cleared on exitFullScreen
480. # [04:30] * Joins: homata__ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
481. # [04:30] <roc> and then exitFullscreen would remove fullscreen status from all the ancestors up to and excluding the first one that has the want-fullscreen flag set
482. # [04:31] <annevk> exitFullscreen also needs to clear all descendants
483. # [04:31] <roc> yes ok
484. # [04:31] <annevk> yeah that additional state is needed otherwise you get sad behavior
485. # [04:31] <Hixie> annevk: re earlier, i'd rather avoid sending events to inactive documents if we can by arranging the api so it's not needed, but if it's needed, sobeit
486. # [04:32] <annevk> Hixie, is it better to state "do animation async" or "spin the event loop until the animation is finished"
487. # [04:32] <annevk> and what is the difference?
488. # [04:32] <cpearce> roc: what element would become fullscreen when then want-fullscreen doc returns to being fullscreen? its root element? what was formerly its fullscreen eleent?
489. # [04:32] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 258 seconds)
490. # [04:33] <annevk> former fullscreen element is prolly best
491. # [04:33] * Joins: dbaron (~dbaron@173.243.46.194)
492. # [04:33] <jamesr> so you have a stack of fullscreen elements to pop out of?
493. # [04:34] <annevk> yeah
494. # [04:34] <Hixie> annevk: not much different. "spin the event loop" is defined as just queuing a task to continue running the algorithm :-)
495. # [04:35] <Hixie> annevk: so it depends on whether you want stuff happening in the background or whether you want it in a task
496. # [04:35] <Hixie> annevk: ("stuff" being anything in your algorithm other than the animation)
497. # [04:36] <annevk> method -> state change -> non blocking animation -> events
498. # [04:36] <annevk> is prolly the order we should have
499. # [04:37] <annevk> not sure what should happen if requestFullscreen or exitFullscreen is invoked during the non-blocking animation
500. # [04:37] <annevk> i guess you would get some additional events
501. # [04:38] * Joins: AlexNRoss (~AleossIRC@unaffiliated/aleoss)
502. # [04:44] <roc> ugh, the idea of a stack kinda sucks
503. # [04:45] * Quits: jamesr (jamesr@nat/google/x-zdwvumueuwrtifer) (Ping timeout: 240 seconds)
504. # [04:45] * jamesr_ dislikes stack
505. # [04:46] <roc> what if we let each document have it's own fullscreen element, and define the concept of an effective fullscreen element, which is either the document's own fullscreen element, or the element for a fullscreen subdocument
506. # [04:46] <annevk> alternatives: 1) not make this work 2) make it possible for a single document to go fullscreen
507. # [04:47] <roc> jamesr_: it would be helpful if we had more feedback from Webkit people; I met two different Chrome people working on fullscreen last week yet it's Mozilla and Opera working on the spec
508. # [04:47] <annevk> roc, darin fisher asked questions on list
509. # [04:47] <roc> good, I'm behind
510. # [04:48] * Joins: tantek (~tantek@70-36-139-219.dsl.dynamic.sonic.net)
511. # [04:48] <roc> ah, only three hours ago, I don't feel bad about that :-)
512. # [04:48] <annevk> :)
513. # [04:48] <annevk> how does the effective fullscreen element concept help?
514. # [04:49] <roc> define styling in terms of it
515. # [04:50] <annevk> oh I read it wrong
516. # [04:50] <annevk> they could be the same right?
517. # [04:50] <roc> they could be
518. # [04:51] <roc> it means that if a subdocument exits fullscreen then the fullscreen element reverts to whatever the document requested
519. # [04:51] <roc> without needing a stack
520. # [04:51] <annevk> if a subdocument goes fullscreen does the document get a notification change?
521. # [04:51] <roc> yes
522. # [04:53] <annevk> it's sort of the same as a stack I guess, it's just an implementation detail
523. # [04:53] <jamesr_> roc, the apple guys rambo'd an implementation into 5.1 as i understand it
524. # [04:53] <jamesr_> roc, including such wonderful things like overriding offsetWidth/offsetHeight for some crazy compat hack in some scenario
525. # [04:54] <annevk> should prolly go with "fullscreen element" and "original fullscreen element" so it's clear what fullscreenElement and :fullscreen refer to
526. # [04:54] <roc> jamesr_: sweet
527. # [04:54] <jamesr_> so now we're mostly trying to play catch-up. i'll try to prod the googlers involved with the chromium implementation to participate more as the opportunity arises
528. # [04:58] <annevk> "fullscreen element", "original fullscreen element", "requestfullscreen invoked", and "fullscreen allowed"
529. # [04:58] <annevk> is the state required I guess
530. # [04:59] <roc> thanks
531. # [05:03] * Joins: jarek (~jarek@unaffiliated/jarek)
532. # [05:06] <annevk> lunch and stuff, I'll redo my sketches from yesterday to work out this new model
533. # [05:06] <annevk> I haven't committed anything thus far
534. # [05:06] <annevk> on the plus side this does seem easier than the call requestFullscreen method anywhere model
535. # [05:06] * Quits: agektmr (~Adium@220.109.219.244) (Quit: Leaving.)
536. # [05:08] * Joins: Rik`_ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
537. # [05:08] * Quits: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
538. # [05:08] * Joins: jarek- (~jarek@aeap119.neoplus.adsl.tpnet.pl)
539. # [05:09] * Quits: MikeSmith (~MikeSmith@EM111-191-181-133.pool.e-mobile.ne.jp) (Quit: MikeSmith)
540. # [05:09] <jarek-> Hi
541. # [05:09] <jarek-> CSS2 spec defines {nonascii} as [\240-\377]
542. # [05:09] * Quits: jarek (~jarek@unaffiliated/jarek) (Ping timeout: 260 seconds)
543. # [05:09] <jarek-> but I'm not sure what actually 240-377 range refer too
544. # [05:10] <jarek-> this is obviously not range from ASCII table
545. # [05:10] <jarek-> it also doesn't look like UTF
546. # [05:10] <jarek-> s/refer/refers
547. # [05:10] * Quits: Rik`_ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
548. # [05:11] * Joins: Rik` (~Rik`@2a01:e34:ec0f:1570:3c9a:d144:b8c7:1773)
549. # [05:12] * Quits: jarek- (~jarek@aeap119.neoplus.adsl.tpnet.pl) (Client Quit)
550. # [05:12] * Joins: jarek (~jarek@unaffiliated/jarek)
551. # [05:13] * Joins: Rik`_ (~Rik`@2a01:e34:ec0f:1570:39f3:bd05:30c1:437a)
552. # [05:15] * Joins: Rik`__ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
553. # [05:16] * Quits: Rik` (~Rik`@2a01:e34:ec0f:1570:3c9a:d144:b8c7:1773) (Ping timeout: 240 seconds)
554. # [05:17] * Quits: Rik`__ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
555. # [05:17] * Joins: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
556. # [05:18] <annevk> jarek, isn't there some note explaining it?
557. # [05:18] * nunnun is now known as nunnun_away
558. # [05:18] * Quits: Rik`_ (~Rik`@2a01:e34:ec0f:1570:39f3:bd05:30c1:437a) (Ping timeout: 244 seconds)
559. # [05:18] * nunnun_away is now known as nunnun
560. # [05:18] * Quits: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
561. # [05:18] <annevk> jarek, so there is, which says the octal codes are Unicode
562. # [05:19] * Joins: nonge_ (~nonge@p5082B572.dip.t-dialin.net)
563. # [05:19] * Joins: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
564. # [05:20] <jarek> annevk: I see, thanks
565. # [05:20] * Quits: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
566. # [05:21] * Joins: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
567. # [05:22] * Joins: Rik`_ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
568. # [05:22] * Quits: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
569. # [05:23] * Quits: nonge__ (~nonge@p5B32681E.dip.t-dialin.net) (Ping timeout: 276 seconds)
570. # [05:23] * Quits: Rik`_ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
571. # [05:23] * Joins: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
572. # [05:26] * Joins: Rik`_ (~Rik`@2a01:e34:ec0f:1570:b555:e876:8dd2:c12d)
573. # [05:26] * Quits: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
574. # [05:27] * Joins: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
575. # [05:28] <jarek> so it is allowed to have signs such as ® or µ inside css ID names?
576. # [05:28] * Joins: othermaciej (~mjs@c-24-6-209-189.hsd1.ca.comcast.net)
577. # [05:28] <jarek> that's interesting
578. # [05:29] <Hixie> what's a "css ID name"?
579. # [05:29] <Hixie> do you mean the #foo syntax or id="foo"?
580. # [05:29] <jarek> Hixie: e.g. #headyer® > h1
581. # [05:29] <Hixie> ah. well you can have anything in that, even spaces, if you escape it
582. # [05:29] <Hixie> e.g. #\ { ... }
583. # [05:30] <Hixie> matches elements whose id is a space
584. # [05:30] <jarek> but id="foo®" is not allowed, right?
585. # [05:30] <Hixie> not that that's a legal ID in HTML
586. # [05:30] <jarek> so what's the point in allowing it in CSS idents?
587. # [05:30] * Quits: Rik`_ (~Rik`@2a01:e34:ec0f:1570:b555:e876:8dd2:c12d) (Ping timeout: 240 seconds)
588. # [05:30] <Hixie> in HTML, id="" can take any value except one containing spaces, and except the empty string
589. # [05:30] * Quits: shans (shanesteph@nat/google/x-uiitofclmqycrueg) (Quit: shans)
590. # [05:31] <Hixie> well, nothing stops someone from applying CSS to a language that uses spaces in IDs
591. # [05:31] <annevk> once we tie CSS closer to the DOM there will be
592. # [05:32] <annevk> but then it will still have to work
593. # [05:32] <annevk> really going now
594. # [05:32] * Quits: annevk (~annevk@EM111-191-181-133.pool.e-mobile.ne.jp) (Quit: annevk)
595. # [05:32] <Hixie> even then someone could define a mapping
596. # [05:33] * Joins: shans (shanesteph@nat/google/x-wbtllxilfzzwurci)
597. # [05:36] * nunnun is now known as nunnun_away
598. # [05:39] * Quits: shepazu (~shepazu@pool-173-76-153-144.bstnma.fios.verizon.net) (Quit: shepazu)
599. # [05:39] * Joins: Evanescence (~Evanescen@122.237.28.137)
600. # [05:49] * Quits: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi) (Ping timeout: 245 seconds)
601. # [05:49] * Quits: cpearce (~chatzilla@60.234.54.74) (Ping timeout: 255 seconds)
602. # [05:51] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
603. # [05:53] * Joins: homata (~homata@u585243.xgsnun9.imtp.tachikawa.mopera.net)
604. # [05:54] * Joins: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi)
605. # [05:54] * Joins: agektmr (~Adium@220.109.219.244)
606. # [05:54] * Quits: davidb (~davidb@bas1-toronto06-2925210074.dsl.bell.ca) (Quit: davidb)
607. # [05:54] * Joins: Bezoar (~Adium@c-24-143-67-135.customer.broadstripe.net)
608. # [05:56] * Quits: homata__ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 258 seconds)
609. # [06:05] * Quits: jarek (~jarek@unaffiliated/jarek) (Quit: jarek)
610. # [06:05] * Quits: homata (~homata@u585243.xgsnun9.imtp.tachikawa.mopera.net) (Ping timeout: 248 seconds)
611. # [06:08] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
612. # [06:09] * Quits: erlehmann (~erlehmann@dslb-178-005-210-187.pools.arcor-ip.net) (Quit: Ex-Chat)
613. # [06:12] * Joins: cpearce (~chatzilla@ip-118-90-78-13.xdsl.xnet.co.nz)
614. # [06:12] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 258 seconds)
615. # [06:15] * Quits: AlexNRoss (~AleossIRC@unaffiliated/aleoss) (Quit: We love you, Dark Continent! Good night!)
616. # [06:16] * Quits: tantek (~tantek@70-36-139-219.dsl.dynamic.sonic.net) (Quit: tantek)
617. # [06:16] * Quits: ojan (ojan@nat/google/x-nghgxrkihbjxeigj) (Quit: ojan)
618. # [06:18] * nunnun_away is now known as nunnun
619. # [06:23] * Quits: mkanat (mkanat@nat/google/x-xiwkwejrulpymtlf) (Quit: Ex-Chat)
620. # [06:30] * Quits: shans (shanesteph@nat/google/x-wbtllxilfzzwurci) (Quit: shans)
621. # [06:32] * Quits: cpearce (~chatzilla@ip-118-90-78-13.xdsl.xnet.co.nz) (Ping timeout: 248 seconds)
622. # [06:32] * dglazkov is now known as dglazkov|away
623. # [06:33] * Joins: shans (shanesteph@nat/google/x-tlmfpmjbdokwqggl)
624. # [06:40] * Joins: cpearce (~chatzilla@ip-118-90-78-13.xdsl.xnet.co.nz)
625. # [06:53] * Quits: dbaron (~dbaron@173.243.46.194) (Quit: 8403864 bytes have been tenured, next gc will be global.)
626. # [06:55] * Quits: shans (shanesteph@nat/google/x-tlmfpmjbdokwqggl) (Quit: shans)
627. # [07:04] * Joins: GlitchMr (~glitchmr@178-36-40-163.adsl.inetia.pl)
628. # [07:17] * Joins: rniwa (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net)
629. # [07:18] * Joins: hasather_ (~hasather_@84.38.144.96)
630. # [07:28] * Joins: shans (shanesteph@nat/google/x-bleydgppcyvpqxsc)
631. # [07:49] * Joins: FlorianX (~Florian_S@p4FE2CB4F.dip.t-dialin.net)
632. # [07:51] * Joins: Areks (~Areks@rs.gridnine.com)
633. # [08:01] * Quits: jacobolus (~jacobolus@c-67-164-92-84.hsd1.ca.comcast.net) (Remote host closed the connection)
634. # [08:01] * Quits: rniwa (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net) (Remote host closed the connection)
635. # [08:01] * Joins: rniwa (~rniwa@216.239.45.130)
636. # [08:03] * Quits: hasather_ (~hasather_@84.38.144.96) (Remote host closed the connection)
637. # [08:08] * Quits: ralphholzmann (~ralph@li76-151.members.linode.com) (Ping timeout: 255 seconds)
638. # [08:08] * Joins: zdobersek (~zan@89.142.245.190)
639. # [08:09] * Joins: jacobolus (~jacobolus@c-71-198-169-213.hsd1.ca.comcast.net)
640. # [08:13] * Joins: Rich_Clark (~chatzilla@94-193-82-82.zone7.bethere.co.uk)
641. # [08:17] * Quits: shans (shanesteph@nat/google/x-bleydgppcyvpqxsc) (Quit: shans)
642. # [08:20] * Joins: ezoe (~ezoe@203-140-90-201f1.kyt1.eonet.ne.jp)
643. # [08:21] * Joins: ralphholzmann (~ralph@li76-151.members.linode.com)
644. # [08:27] * Joins: brucel (~brucel@cpc4-smal11-2-0-cust879.perr.cable.virginmedia.com)
645. # [08:28] * Joins: dirkpennings (~Vuurbal@90-145-26-140.bbserv.nl)
646. # [08:32] * Joins: tomasf (~tomasf@77.72.97.5.c.fiberdirekt.net)
647. # [08:57] * Joins: MikeSmith (~MikeSmith@p3156-ipbf1909marunouchi.tokyo.ocn.ne.jp)
648. # [08:59] * Joins: annevk (~annevk@p3156-ipbf1909marunouchi.tokyo.ocn.ne.jp)
649. # [09:00] * Joins: benjoffe (~benjoffe_@CPE-121-218-225-100.lnse4.cht.bigpond.net.au)
650. # [09:01] <annevk> lunch breaks these days take a while
651. # [09:01] <annevk> I do know a whole lot more about the component model so that's nice
652. # [09:02] <Hixie> every time i end up in a discussion with semantic web people, i end up questioning why we even do microdata at all
653. # [09:03] <Hixie> (then i remember there's some interesting use cases with drag and drop)
654. # [09:03] <Hixie> (but those are never the ones they mention, and the ones they mention almost always seem to be either unrealistic or theoretical)
655. # [09:06] <annevk> it's such a time sink
656. # [09:07] <annevk> and HTML is really somewhat unique in that
657. # [09:10] * Joins: virtuelv (~virtuelv_@pat-tdc.opera.com)
658. # [09:15] * Quits: GlitchMr (~glitchmr@178-36-40-163.adsl.inetia.pl) (Quit: GlitchMr)
659. # [09:18] * Quits: nessy (~Adium@74.125.56.18) (Quit: Leaving.)
660. # [09:20] * Joins: agektmr1 (~Adium@220.109.219.245)
661. # [09:21] * Quits: Bezoar (~Adium@c-24-143-67-135.customer.broadstripe.net) (Quit: Leaving.)
662. # [09:22] * Joins: agektmr2 (~Adium@220.109.219.244)
663. # [09:22] * Quits: agektmr (~Adium@220.109.219.244) (Read error: Connection reset by peer)
664. # [09:23] * Quits: roc (~chatzilla@222-152-162-45.jetstream.xtra.co.nz) (Ping timeout: 260 seconds)
665. # [09:25] * Quits: agektmr1 (~Adium@220.109.219.245) (Ping timeout: 252 seconds)
666. # [09:29] * Joins: roc (~chatzilla@222-152-166-44.jetstream.xtra.co.nz)
667. # [09:31] * Joins: bezoar (~Adium@c-24-143-67-135.customer.broadstripe.net)
668. # [09:34] * Quits: roc (~chatzilla@222-152-166-44.jetstream.xtra.co.nz) (Ping timeout: 258 seconds)
669. # [09:38] <annevk> hmm
670. # [09:38] <annevk> so I think the fullscreen model still does not work cpearce :(
671. # [09:39] <annevk> cpearce, Document is fullscreen, same document hosts a couple of videos by means of <video> elements
672. # [09:39] <annevk> cpearce, document.exitFullscreen is going to do the wrong thing
673. # [09:51] * Quits: zdobersek (~zan@89.142.245.190) (Quit: Leaving.)
674. # [09:51] * Joins: zdobersek1 (~zan@89.142.245.190)
675. # [09:52] <MikeSmith> hsivonen: small patch review when you have time
676. # [09:52] <MikeSmith> https://gist.github.com/1294834
677. # [09:52] <MikeSmith> for http://bugzilla.validator.nu/show_bug.cgi?id=865
678. # [10:00] * Joins: smaug____ (~chatzilla@GYYYKMMCCVI.gprs.sl-laajakaista.fi)
679. # [10:08] <annevk> cpearce, I wrote an email
680. # [10:08] <annevk> guess I'll write the WHATWG Weekly if there's anything to report on
681. # [10:08] <jgraham> annevk: This concept of nested fullscreen seems like it will make for a confusing user experience
682. # [10:08] <jgraham> I could be wrong
683. # [10:09] <annevk> your site is displayed fullscreen, you have a video in it
684. # [10:09] <annevk> the user hits the fullscreen button on the video, then exits
685. # [10:10] <annevk> what is the expected user experience?
686. # [10:10] <annevk> to me it seems pretty obvious you want the site to remain fullscreen
687. # [10:10] * Joins: zcorpan (~zcorpan@pat.se.opera.com)
688. # [10:10] <annevk> but I could be wrong
689. # [10:10] <jgraham> I'm not sure
690. # [10:11] <jgraham> It seems like you could get into a situation where you think "exit fullscreen" will actually cause you to exit fullscreen when it won't
691. # [10:12] <annevk> the alternative is to not support nesting and if you want nesting you need to implement your own concept of fullscreen
692. # [10:12] <annevk> which is kind of sucky given all the benefits of using fullscreen
693. # [10:13] <jgraham> I wonder if it is a problem if a site takes you two levels of fullscreen deep, gives you an "exit fullscreen" button and meanwhile draws something that looks like maximised browser chrome on the inner fullscreen
694. # [10:13] <foolip> won't calling requestFullscreen when already in fullscreen cause the fullscreen'd element to change?
695. # [10:13] <foolip> if so, they could just have the "exit fullscreen" button call fullscreen on another element in this situation
696. # [10:13] <foolip> although the native UI won't do the same thing
697. # [10:13] <jgraham> Maybe it's not, since you could do that even without the concept of nested fullscreen
698. # [10:14] <jgraham> (but if there is a browser escape hatch that only works one level deep, it could be more confusing)
699. # [10:14] <foolip> still, if I ever actually wanted to really exit fullscreen, I'd be pretty annoyed if I found myself in n levels of fullscren
700. # [10:14] <annevk> foolip, yeah, then you get a disparity between <video controls> and <video> with site-supplied controls
701. # [10:14] <annevk> to exit fullscreen you press "Esc"
702. # [10:15] <annevk> we'll clearly advertise that in the UI and it will go through everything
703. # [10:16] <jgraham> I guess as long as browsers implement a method that blows away all fullscreen there's no problem
704. # [10:16] <foolip> anyway, the user putting a page into fullscreen with F11 isn't the same as requestFullscreen right?
705. # [10:16] <jgraham> Is it possible for sites to bind to the esc key? Or is that forbidden?
706. # [10:16] * Joins: roc (~chatzilla@222-152-167-217.jetstream.xtra.co.nz)
707. # [10:16] <foolip> so the case where a site just happens to be in fullscreen without knowing it can be handled
708. # [10:17] <annevk> foolip, I would sort of like it to be the same
709. # [10:17] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
710. # [10:17] <annevk> jgraham, the site would never get hold of this key basically
711. # [10:17] <annevk> jgraham, while in fullscreen
712. # [10:17] <annevk> foolip, i.e. have the API and UI work together
713. # [10:18] <foolip> hmm, that does sound nice I agree
714. # [10:19] <jgraham> So that is equivalent to requestFullscreen on the root element?
715. # [10:19] <annevk> or on a video element
716. # [10:19] <annevk> kind of depends
717. # [10:19] <jgraham> What? Why would video be special?
718. # [10:22] * Quits: roc (~chatzilla@222-152-167-217.jetstream.xtra.co.nz) (Ping timeout: 240 seconds)
719. # [10:25] <foolip> A fullscreen button in native controls and option in the context menu of <video> would make sense, but not so much for <input>
720. # [10:26] <annevk> we should definitely have it on the native controls
721. # [10:26] <jgraham> But also for <canvas> or <svg> or <div> with a video and some other stuff in
722. # [10:27] <annevk> dunno about those
723. # [10:27] <jgraham> Well I don't necessarily think we should
724. # [10:27] <jgraham> But video isn't really that special
725. # [10:27] <annevk> yes it is
726. # [10:27] <foolip> the spec could allow it, but I doubt anyone will implement it
727. # [10:27] <annevk> for <video>?
728. # [10:27] <foolip> for <input> :)
729. # [10:27] <annevk> oh
730. # [10:27] <jgraham> Only in the case it has native controls. Even then it could be using other stuff synced to the video
731. # [10:28] <jgraham> That would mean that taking it fullscreen alone didn't make sense
732. # [10:28] <annevk> sounds like an edge case
733. # [10:28] * Joins: FlorianX1 (~Florian_S@p4FE2D4A2.dip.t-dialin.net)
734. # [10:28] <foolip> jgraham, then the page author will have to provide fullscreen controls
735. # [10:28] <foolip> UI for picking a random element to fullscreen would have to look something like dragonfly's focus rectangles, i.e. intolerable
736. # [10:29] <jgraham> Right, I'm not saying that will work
737. # [10:29] <jgraham> I'm saying that the converse will break sometimes
738. # [10:29] <foolip> absolutely
739. # [10:29] <jgraham> I don't know how often that will be
740. # [10:29] <foolip> all of my <track> demos so far will break
741. # [10:29] <foolip> but that's fine I think
742. # [10:30] <jgraham> An end user that doesn't understand the implementation may disagree ofc
743. # [10:30] * Quits: FlorianX (~Florian_S@p4FE2CB4F.dip.t-dialin.net) (Ping timeout: 240 seconds)
744. # [10:30] <jgraham> Anyway, I don't know
745. # [10:30] <foolip> uh, yeah, users...
746. # [10:31] <foolip> I do look forward for bug reports that the captions don't show in fullscreen because the page author did it using scripts
747. # [10:31] <jgraham> Possibly people only use video with native controls in testcases so this is irrelevant
748. # [10:31] <foolip> s/for/to/
749. # [10:32] <foolip> yeah, you don't see them a lot
750. # [10:33] <zcorpan> annevk: video with custom controls isn't an edge case
751. # [10:34] <zcorpan> custom controls for video and fullscreen is kind of a problem. you might want to allow the user to enter fullscreen from the context menu of the video, but you still want to show the custom controls in fullscreen
752. # [10:36] <jgraham> There could be some mechanism for changing the element that will go fullscreen. That could be evil though
753. # [10:36] <foolip> zcorpan, presumably not without some involvement from the script managing the controls?
754. # [10:36] <annevk> zcorpan, we were not talking about custom controls
755. # [10:39] * Quits: temp01 (~temp01@unaffiliated/temp01) (Ping timeout: 259 seconds)
756. # [10:42] * Joins: roc (~chatzilla@222-152-160-29.jetstream.xtra.co.nz)
757. # [10:43] <zcorpan> what were you talking about? custom captions?
758. # [10:43] <zcorpan> seems like you'd want those in fullscreen too
759. # [10:43] <zcorpan> foolip: what can the script do if the user fullscreened from the video's context menu?
760. # [10:44] <foolip> zcorpan, if there is an event when fullscreen happens and some kind of container element then presumably it can make the controls visible in fullscreen as well
761. # [10:45] <annevk> yeah, the site could check fullscreenchange events and retarget accordingly
762. # [10:45] <foolip> but I doubt anyone would, scripts will mostly assume that the context menu and native controls do not exist
763. # [10:45] <foolip> and break if they do
764. # [10:46] <annevk> it seems reasonable for browsers to provide native controls if the fullscreen element is the video element itself
765. # [10:46] <roc> what problem are you guys talking about?
766. # [10:46] <annevk> UI and API-based fullscreen interaction
767. # [10:47] <roc> ah
768. # [10:47] * Quits: zdobersek1 (~zan@89.142.245.190) (Quit: Leaving.)
769. # [10:47] <annevk> roc, could you look at my most recent email to the WHATWG list?
770. # [10:48] <roc> ok
771. # [10:49] <roc> I would not allow cancelFullScreen to leave full-screen state if the user initiated it
772. # [10:49] * Quits: sicking (~chatzilla@206-15-76-122.static.twtelecom.net) (Ping timeout: 258 seconds)
773. # [10:50] * Joins: rtuin (~rtuin@213.125.175.250)
774. # [10:50] <annevk> is that in reply to my email?
775. # [10:50] * Quits: FlorianX1 (~Florian_S@p4FE2D4A2.dip.t-dialin.net) (Ping timeout: 240 seconds)
776. # [10:51] * Joins: FlorianX (~Florian_S@p4FE2D4A2.dip.t-dialin.net)
777. # [10:54] * Joins: roc_ (~chatzilla@222-152-160-29.jetstream.xtra.co.nz)
778. # [10:54] <zcorpan> foolip: you mean you would change the 'fullscreen element' after the user fullscreened the video?
779. # [10:55] * Quits: roc (~chatzilla@222-152-160-29.jetstream.xtra.co.nz) (Ping timeout: 252 seconds)
780. # [10:55] <annevk> fwiw, if there are custom controls I very much doubt the user will right-click
781. # [10:55] * roc_ is now known as roc
782. # [10:56] <roc> annevk: yes
783. # [10:57] <annevk> because it doesn't address my email
784. # [10:58] <annevk> site goes fullscreen (either API or UI-wise, I don't really care) then you want to view some video in it that's in the same document
785. # [10:58] <annevk> and you want to continue using the site
786. # [10:58] <annevk> after viewing the video, or maybe halfway
787. # [11:11] * Joins: temp01 (~temp01@unaffiliated/temp01)
788. # [11:11] * Quits: roc (~chatzilla@222-152-160-29.jetstream.xtra.co.nz) (Ping timeout: 248 seconds)
789. # [11:12] <foolip> zcorpan, either that or if there is always a container into which more elements can be stuffed
790. # [11:12] <foolip> but that seems a bit magical
791. # [11:13] * Parts: brucel (~brucel@cpc4-smal11-2-0-cust879.perr.cable.virginmedia.com)
792. # [11:13] * Joins: roc (~chatzilla@222-152-160-29.jetstream.xtra.co.nz)
793. # [11:17] * Quits: nattokirai (~nattokira@rtr.mozilla.or.jp) (Quit: nattokirai)
794. # [11:17] * Quits: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi) (Read error: Operation timed out)
795. # [11:22] <annevk> roc, did you see http://krijnhoetmer.nl/irc-logs/whatwg/20111018#l-783 ?
796. # [11:24] * Quits: rniwa (~rniwa@216.239.45.130) (Ping timeout: 260 seconds)
797. # [11:24] * Joins: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi)
798. # [11:24] * Quits: Lachy (~Lachy@cm-84.215.59.50.getinternet.no) (Quit: Computer has gone to sleep.)
799. # [11:27] <roc> yeah
800. # [11:27] <roc> well, I just read your link
801. # [11:28] <annevk> I haven't really figured out a simple way to make the single document case work yet :(
802. # [11:29] <annevk> I guess authors can hack around it using <iframe srcdoc=""> but that seems like a really ugly workaround
803. # [11:29] * Quits: agektmr2 (~Adium@220.109.219.244) (Quit: Leaving.)
804. # [11:32] <roc> one option is that the video fullscreen controls could explicitly save the previous fullscreen element, if any, and then when un-full-screening the element you either requestFullScreen on the old element or else cancelFullScreen if there wasn't one
805. # [11:33] <annevk> does that assume custom controls?
806. # [11:34] <annevk> it doesn't seem nice if the API and UI have wildly different implementations
807. # [11:35] * Quits: gkellogg (~gregg@c-98-248-150-91.hsd1.ca.comcast.net) (Ping timeout: 245 seconds)
808. # [11:35] <annevk> I suppose you could also make this work UI-wise somehow, but it's not pretty
809. # [11:39] * Joins: gkellogg (~gregg@c-98-248-150-91.hsd1.ca.comcast.net)
810. # [11:43] * Quits: Areks (~Areks@rs.gridnine.com) (Ping timeout: 240 seconds)
811. # [11:48] * Joins: Lachy (~Lachy@pat-tdc.opera.com)
812. # [11:48] * Quits: joepie91 (~joepie91@s514735fe.adsl.wanadoo.nl) (Ping timeout: 248 seconds)
813. # [11:49] * Joins: joepie91 (~joepie91@s514735fe.adsl.wanadoo.nl)
814. # [11:49] * Joins: Areks (~Areks@rs.gridnine.com)
815. # [11:52] * Quits: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Remote host closed the connection)
816. # [12:00] * Joins: shans (~shanestep@124-171-52-239.dyn.iinet.net.au)
817. # [12:05] * Quits: MikeSmith (~MikeSmith@p3156-ipbf1909marunouchi.tokyo.ocn.ne.jp) (Quit: MikeSmith)
818. # [12:05] * Quits: annevk (~annevk@p3156-ipbf1909marunouchi.tokyo.ocn.ne.jp) (Quit: annevk)
819. # [12:06] * Quits: shans (~shanestep@124-171-52-239.dyn.iinet.net.au) (Quit: shans)
820. # [12:13] * Joins: bga_ (~bga@ppp78-37-224-175.pppoe.avangarddsl.ru)
821. # [12:15] * Quits: temp01 (~temp01@unaffiliated/temp01) (Ping timeout: 240 seconds)
822. # [12:19] * Joins: nessy (~Adium@124-168-52-143.dyn.iinet.net.au)
823. # [12:20] * Joins: zdobersek (~zan@89.142.245.190)
824. # [12:21] * Joins: Rik` (~Rik`@mozilla-paris-253-98.cnt.nerim.net)
825. # [12:33] * Quits: lhnz (~lhnz@188-223-83-48.zone14.bethere.co.uk) (Quit: Leaving)
826. # [12:33] * Quits: zdobersek (~zan@89.142.245.190) (Quit: Leaving.)
827. # [12:54] * Quits: virtuelv (~virtuelv_@pat-tdc.opera.com) (Quit: Ex-Chat)
828. # [12:58] * Quits: Areks (~Areks@rs.gridnine.com) (Read error: Connection reset by peer)
829. # [13:00] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Quit: Leaving...)
830. # [13:04] * Joins: shans (~shanestep@124-171-52-239.dyn.iinet.net.au)
831. # [13:05] * Joins: temp01 (~temp01@unaffiliated/temp01)
832. # [13:14] * Joins: myakura (~myakura@FL1-203-136-164-250.tky.mesh.ad.jp)
833. # [13:15] * Joins: necolas (~necolas@5e0c0fc8.bb.sky.com)
834. # [13:20] * Quits: shans (~shanestep@124-171-52-239.dyn.iinet.net.au) (Quit: shans)
835. # [13:28] * Joins: virtuelv (~virtuelv_@pat-tdc.opera.com)
836. # [13:33] * Quits: Lachy (~Lachy@pat-tdc.opera.com) (Quit: Textual IRC Client: http://www.textualapp.com/)
837. # [13:34] * Quits: nessy (~Adium@124-168-52-143.dyn.iinet.net.au) (Quit: Leaving.)
838. # [13:36] * Joins: scor (~scor@drupal.org/user/52142/view)
839. # [13:42] * Joins: Lachy (~Lachy@pat-tdc.opera.com)
840. # [13:46] * Joins: Areks (~Areks@rs.gridnine.com)
841. # [13:53] * Joins: Telling (~unknown@80-71-135-15.u.parknet.dk)
842. # [13:57] * Quits: smaug____ (~chatzilla@GYYYKMMCCVI.gprs.sl-laajakaista.fi) (Quit: Reconnecting…)
843. # [13:58] * Joins: smaug____ (~chatzilla@GYYYKMMCCVI.gprs.sl-laajakaista.fi)
844. # [13:58] * Joins: annevk (~annevk@EM114-48-219-192.pool.e-mobile.ne.jp)
845. # [13:59] * Quits: foolip (~philip@83.218.67.122) (Remote host closed the connection)
846. # [14:00] * Joins: MikeSmith (~MikeSmith@EM114-48-219-192.pool.e-mobile.ne.jp)
847. # [14:15] * Joins: foolip (~philip@83.218.67.122)
848. # [14:18] * Quits: Evanescence (~Evanescen@122.237.28.137) (Quit: my website: http://stardiviner.dyndns-blog.com/)
849. # [14:19] <annevk> http://www.identityblog.com/?p=1201
850. # [14:23] * Quits: virtuelv (~virtuelv_@pat-tdc.opera.com) (Quit: Ex-Chat)
851. # [14:29] * Quits: ericc|away (~ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net) (Quit: ericc|away)
852. # [14:37] * Quits: ezoe (~ezoe@203-140-90-201f1.kyt1.eonet.ne.jp) (Ping timeout: 245 seconds)
853. # [14:40] * Quits: yuuki (~kobayashi@58x158x182x50.ap58.ftth.ucom.ne.jp) (Quit: Leaving...)
854. # [14:51] * heycam|away is now known as heycam
855. # [14:53] * Joins: davidb (~davidb@66.207.208.98)
856. # [14:53] * heycam is now known as heycam|away
857. # [14:54] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
858. # [15:00] * Quits: smaug____ (~chatzilla@GYYYKMMCCVI.gprs.sl-laajakaista.fi) (Ping timeout: 245 seconds)
859. # [15:01] * Joins: jonatasnona (~jonatas@lba.inpa.gov.br)
860. # [15:01] * Joins: smaug____ (~chatzilla@YZMYDLXV.gprs.sl-laajakaista.fi)
861. # [15:02] * Joins: jwm (~jwm@c-50-129-90-95.hsd1.in.comcast.net)
862. # [15:05] * Joins: shepazu (~shepazu@64.119.130.114)
863. # [15:06] * Quits: annevk (~annevk@EM114-48-219-192.pool.e-mobile.ne.jp) (Quit: annevk)
864. # [15:13] <smaug____> annevk: ttp://www.identityblog.com/?p=1201 is interesting
865. # [15:13] <smaug____> annevk: http://www.identityblog.com/?p=1201 is interesting
866. # [15:14] <smaug____> thanks for the link
867. # [15:15] * Joins: MacTed (~Thud@63.119.36.36)
868. # [15:18] * Joins: GlitchMr (~glitchmr@178-36-40-163.adsl.inetia.pl)
869. # [15:18] * Joins: jdong_bot_ (~jdong_bot@117.79.233.189)
870. # [15:18] * Quits: tomasf (~tomasf@77.72.97.5.c.fiberdirekt.net) (Quit: tomasf)
871. # [15:18] * Joins: miketaylr (~miketaylr@206.217.92.186)
872. # [15:19] * Joins: ezoe (~ezoe@61-205-124-231f1.kyt1.eonet.ne.jp)
873. # [15:21] * Joins: dbaron (~dbaron@66.207.208.98)
874. # [15:37] * Quits: nonge_ (~nonge@p5082B572.dip.t-dialin.net) (Quit: Verlassend)
875. # [15:38] * Joins: nonge (~nonge@p5082B572.dip.t-dialin.net)
876. # [15:43] * Quits: silky (~silky@pool-74-108-142-22.nycmny.fios.verizon.net) (Remote host closed the connection)
877. # [15:49] * Joins: scor (~scor@drupal.org/user/52142/view)
878. # [15:57] * Joins: silky (~silky@pool-74-108-142-22.nycmny.fios.verizon.net)
879. # [16:04] * Joins: J_Voracek (~J_Voracek@71.21.195.70)
880. # [16:05] * Joins: RobbertAtWork (~Robbert@a83-160-99-114.adsl.xs4all.nl)
881. # [16:07] * Joins: eric_carlson (~eric@17.212.152.104)
882. # [16:15] * Joins: davidwalsh (~davidwals@75-135-74-55.dhcp.mdsn.wi.charter.com)
883. # [16:16] * Quits: J_Voracek (~J_Voracek@71.21.195.70) (Ping timeout: 255 seconds)
884. # [16:18] * Quits: shepazu (~shepazu@64.119.130.114) (Quit: shepazu)
885. # [16:23] * Joins: tomasf (~tomasf@host-95-199-24-240.mobileonline.telia.com)
886. # [16:33] * Joins: danbri_ (~danbri@ip176-48-210-87.adsl2.static.versatel.nl)
887. # [16:33] * Quits: danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl) (Ping timeout: 256 seconds)
888. # [16:35] * Joins: _bga (~bga@ppp78-37-226-215.pppoe.avangarddsl.ru)
889. # [16:38] * Quits: bga_ (~bga@ppp78-37-224-175.pppoe.avangarddsl.ru) (Ping timeout: 252 seconds)
890. # [16:41] * Joins: shepazu (~shepazu@64.119.130.114)
891. # [16:50] * Joins: lhnz (~lhnz@188-223-83-48.zone14.bethere.co.uk)
892. # [16:50] * Quits: zcorpan (~zcorpan@pat.se.opera.com) (Quit: zcorpan)
893. # [16:57] * Joins: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie)
894. # [17:04] * Joins: agektmr (~Adium@p2156-ipbf5107marunouchi.tokyo.ocn.ne.jp)
895. # [17:08] * Quits: Areks (~Areks@rs.gridnine.com) (Ping timeout: 240 seconds)
896. # [17:09] * Quits: rtuin (~rtuin@213.125.175.250) (Quit: Leaving)
897. # [17:17] * Quits: tomasf (~tomasf@host-95-199-24-240.mobileonline.telia.com) (Ping timeout: 245 seconds)
898. # [17:21] * Quits: smaug____ (~chatzilla@YZMYDLXV.gprs.sl-laajakaista.fi) (Ping timeout: 252 seconds)
899. # [17:26] * Quits: dirkpennings (~Vuurbal@90-145-26-140.bbserv.nl) (Ping timeout: 255 seconds)
900. # [17:38] * Quits: Lachy (~Lachy@pat-tdc.opera.com) (Quit: Computer has gone to sleep.)
901. # [17:45] * Joins: eric_carlson_ (~ericc@17.212.154.205)
902. # [17:46] * Quits: eric_carlson_ (~ericc@17.212.154.205) (Client Quit)
903. # [17:48] * Quits: jdong_bot_ (~jdong_bot@117.79.233.189) (Remote host closed the connection)
904. # [17:49] * dglazkov|away is now known as dglazkov
905. # [17:49] <dglazkov> good morning, Whatwg!
906. # [17:54] * Quits: ukai (ukai@nat/google/x-plemsbhbifsnrkle) (Read error: Operation timed out)
907. # [18:05] * Joins: KillerX__ (~anant@nat/mozilla/x-izzyuffewfmzkfru)
908. # [18:05] * Quits: KillerX__ (~anant@nat/mozilla/x-izzyuffewfmzkfru) (Client Quit)
909. # [18:06] * Quits: agektmr (~Adium@p2156-ipbf5107marunouchi.tokyo.ocn.ne.jp) (Quit: Leaving.)
910. # [18:08] * Joins: jarek (~jarek@unaffiliated/jarek)
911. # [18:08] <jarek> Hi
912. # [18:08] * Quits: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi) (Ping timeout: 240 seconds)
913. # [18:08] <jarek> which specification introduces the "@supports" atrule?
914. # [18:09] <jarek> I have stumbled upon it in one example in http://www.w3.org/TR/css3-fonts
915. # [18:10] <hasather> jarek: http://www.w3.org/TR/css3-conditional/#at-supports
916. # [18:10] * Joins: tantek (~tantek@70-36-139-219.dsl.dynamic.sonic.net)
917. # [18:11] <jarek> hasather: thanks
918. # [18:12] * Joins: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi)
919. # [18:12] <jarek> btw, do you know if any browser supports @supports?
920. # [18:12] * Joins: Maurice` (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
921. # [18:17] <zewt> @supports (@supports)
922. # [18:18] * Joins: tomasf (~tom@c-5ed9e555.024-204-6c6b7012.cust.bredbandsbolaget.se)
923. # [18:21] * Joins: ukai (ukai@nat/google/x-ncndgybmurbbioch)
924. # [18:21] * Joins: agektmr (~Adium@p2156-ipbf5107marunouchi.tokyo.ocn.ne.jp)
925. # [18:26] * Quits: GlitchMr (~glitchmr@178-36-40-163.adsl.inetia.pl) (Read error: Connection reset by peer)
926. # [18:26] <jarek> http://www.w3.org/TR/css3-fonts/ uses following code in one example:
927. # [18:26] <jarek> font-family: Mercury Serif, serif;
928. # [18:26] <jarek> is this really valid? Shouldn't Mercury Serif be put between quotes?
929. # [18:29] * Joins: Areks (~Areks@176.14.214.163)
930. # [18:29] <jarek> "Font family names must either be given quoted as strings, or unquoted as a sequence of one or more identifiers. This means most punctuation characters and digits at the start of each token must be escaped in unquoted font family names."
931. # [18:30] * Joins: Lachy (~Lachy@cm-84.215.59.50.getinternet.no)
932. # [18:30] <miketaylr> i would quote mercury serif, yes
933. # [18:30] * Quits: davidwalsh (~davidwals@75-135-74-55.dhcp.mdsn.wi.charter.com) (Quit: Reading http://davidwalsh.name)
934. # [18:32] * Quits: Lachy (~Lachy@cm-84.215.59.50.getinternet.no) (Client Quit)
935. # [18:33] <jarek> so Mercury Serif is a valid name, but 9Mercury Serif would fail :/
936. # [18:35] * Quits: shepazu (~shepazu@64.119.130.114) (Quit: shepazu)
937. # [18:38] * Quits: astearns (~anonymous@c-50-132-63-33.hsd1.wa.comcast.net) (Quit: astearns)
938. # [18:40] * Joins: rniwa (~rniwa@216.239.45.130)
939. # [18:43] * Quits: Rich_Clark (~chatzilla@94-193-82-82.zone7.bethere.co.uk) (Ping timeout: 245 seconds)
940. # [18:44] * Quits: RobbertAtWork (~Robbert@a83-160-99-114.adsl.xs4all.nl) (Quit: RobbertAtWork)
941. # [18:48] * Joins: dave_levin (dave_levin@nat/google/x-cnwojtozztzszvkj)
942. # [18:48] * Quits: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) (Quit: brb)
943. # [18:48] * Joins: hasather_ (~hasather_@84.38.144.96)
944. # [18:48] * Joins: Ms2ger (~Ms2ger@91.181.39.217)
945. # [18:49] * Joins: rabbi1 (~manjunath@49.249.126.233)
946. # [18:52] * Joins: ap (~ap@2620:149:4:1b01:4c1e:7463:3957:d61b)
947. # [18:55] * Joins: jennb (jennb@nat/google/x-djxeqligkvhtlfjb)
948. # [18:57] <Ms2ger> jarek, yes
949. # [18:57] <Ms2ger> Fun, isn't it?
950. # [19:03] * Joins: smaug____ (~chatzilla@cs181151161.pp.htv.fi)
951. # [19:05] * Joins: GlitchMr (~glitchmr@178-36-40-163.adsl.inetia.pl)
952. # [19:11] * Quits: jonatasnona (~jonatas@lba.inpa.gov.br) (Quit: Saindo)
953. # [19:11] * Joins: astearns (~anonymous@192.150.22.5)
954. # [19:16] * Quits: agektmr (~Adium@p2156-ipbf5107marunouchi.tokyo.ocn.ne.jp) (Quit: Leaving.)
955. # [19:16] * Quits: jarek (~jarek@unaffiliated/jarek) (Ping timeout: 260 seconds)
956. # [19:18] * Joins: sicking (~chatzilla@206-15-76-122.static.twtelecom.net)
957. # [19:21] * Joins: jwalden (~waldo@2620:101:8003:200:224:d7ff:fef0:8d90)
958. # [19:24] * Quits: myakura (~myakura@FL1-203-136-164-250.tky.mesh.ad.jp) (Remote host closed the connection)
959. # [19:33] * Joins: shepazu (~shepazu@64.119.130.114)
960. # [19:48] * jernoble|afk is now known as jernoble
961. # [19:55] * Quits: dbaron (~dbaron@66.207.208.98) (Quit: 8403864 bytes have been tenured, next gc will be global.)
962. # [20:00] * Quits: MikeSmith (~MikeSmith@EM114-48-219-192.pool.e-mobile.ne.jp) (Ping timeout: 252 seconds)
963. # [20:00] * Joins: paissad (~paissad@89-92-16-151.hfc.dyn.abo.bbox.fr)
964. # [20:01] * Joins: Bass10 (~Bass10@c-76-113-194-7.hsd1.mn.comcast.net)
965. # [20:03] * Quits: Bass10 (~Bass10@c-76-113-194-7.hsd1.mn.comcast.net) (Max SendQ exceeded)
966. # [20:05] * Quits: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi) (Ping timeout: 255 seconds)
967. # [20:06] * Joins: MikeSmith (~MikeSmith@EM114-48-186-54.pool.e-mobile.ne.jp)
968. # [20:06] * Joins: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi)
969. # [20:11] * Joins: dydx (~dydz@adsl-75-36-190-15.dsl.pltn13.sbcglobal.net)
970. # [20:11] * Joins: mokush (~quassel@188.24.43.163)
971. # [20:16] * Quits: rniwa (~rniwa@216.239.45.130) (Quit: rniwa)
972. # [20:22] * Joins: jamesr (jamesr@nat/google/x-mfrwqsgluwhxcarq)
973. # [20:31] * Joins: micheil (~micheil@195.24.233.121)
974. # [20:31] * Joins: erlehmann (~erlehmann@dslb-178-005-210-187.pools.arcor-ip.net)
975. # [20:32] * Quits: dydx (~dydz@adsl-75-36-190-15.dsl.pltn13.sbcglobal.net) (Read error: Connection reset by peer)
976. # [20:40] * Quits: shepazu (~shepazu@64.119.130.114) (Quit: shepazu)
977. # [20:48] * Joins: dbaron (~dbaron@66.207.208.98)
978. # [20:49] * Joins: shepazu (~shepazu@64.119.130.114)
979. # [20:50] * Quits: gkellogg (~gregg@c-98-248-150-91.hsd1.ca.comcast.net) (Ping timeout: 260 seconds)
980. # [21:03] * Quits: shepazu (~shepazu@64.119.130.114) (Quit: shepazu)
981. # [21:06] * Joins: rniwa (rniwa@nat/google/x-nknbmhtxoqwghvim)
982. # [21:06] * Quits: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi) (Ping timeout: 256 seconds)
983. # [21:08] * Joins: shepazu (~shepazu@64.119.130.114)
984. # [21:11] * Joins: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi)
985. # [21:12] * Joins: ojan (ojan@nat/google/x-aboifemjxyvrinym)
986. # [21:16] * Joins: gkellogg (~gregg@c-98-248-150-91.hsd1.ca.comcast.net)
987. # [21:17] * Joins: xtoph (~xtoph@213.47.185.206)
988. # [21:29] * Joins: dydx (~dydz@adsl-75-36-190-15.dsl.pltn13.sbcglobal.net)
989. # [21:29] * Quits: mokush (~quassel@188.24.43.163) (Remote host closed the connection)
990. # [21:34] * Joins: nessy (~Adium@124-168-52-143.dyn.iinet.net.au)
991. # [21:38] * Quits: shepazu (~shepazu@64.119.130.114) (Quit: shepazu)
992. # [21:39] * Quits: nessy (~Adium@124-168-52-143.dyn.iinet.net.au) (Client Quit)
993. # [21:40] * Quits: jamesr_ (jamesr@nat/google/x-rqjuuihahwucbzqg) (Quit: Ex-Chat)
994. # [21:40] * Joins: shepazu (~shepazu@64.119.130.114)
995. # [21:46] * Quits: sicking (~chatzilla@206-15-76-122.static.twtelecom.net) (Ping timeout: 255 seconds)
996. # [21:50] * Quits: FlorianX (~Florian_S@p4FE2D4A2.dip.t-dialin.net) (Read error: Connection reset by peer)
997. # [21:52] * rniwa is now known as rniwa|afk
998. # [21:55] * Joins: rniwa (rniwa@nat/google/x-wzowvgtyyvyezngn)
999. # [21:57] * Joins: jamesr_ (jamesr@nat/google/x-gywjsygxvzbvfico)
1000. # [22:07] * Quits: GlitchMr (~glitchmr@178-36-40-163.adsl.inetia.pl) (Read error: Connection reset by peer)
1001. # [22:07] * Quits: rniwa (rniwa@nat/google/x-wzowvgtyyvyezngn) (Quit: rniwa)
1002. # [22:09] <jgraham> So is David Flanagan writing a html parser in js?
1003. # [22:11] * Quits: cpearce (~chatzilla@ip-118-90-78-13.xdsl.xnet.co.nz) (Ping timeout: 240 seconds)
1004. # [22:14] <Ms2ger> Along with his dom implementation, yes
1005. # [22:14] <Ms2ger> https://github.com/andreasgal/dom.js
1006. # [22:14] <Ms2ger> "all HTML parser tests pass!"
1007. # [22:16] * danbri_ is now known as danbri
1008. # [22:18] <jgraham> So is that actually a necessary part of dom.js?
1009. # [22:19] * Quits: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi) (Ping timeout: 248 seconds)
1010. # [22:19] <jgraham> And what's next, the network layer?
1011. # [22:22] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
1012. # [22:24] * Joins: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi)
1013. # [22:25] <Ms2ger> That'll be in rust, more likely
1014. # [22:26] <jgraham> So what I don't understand is where script scheduling fits is
1015. # [22:26] <jgraham> *in
1016. # [22:26] <jgraham> That is tightly coupled to the parser
1017. # [22:27] <jgraham> So it seems weird to have those in different languages
1018. # [22:27] <jgraham> But writing the scheduler in javascript seems... unlikely
1019. # [22:27] <jgraham> But maybe I am wrong about one of those things
1020. # [22:28] <Ms2ger> Dunno, haven't been following closely
1021. # [22:28] <Ms2ger> What I know is from http://dl.dropbox.com/u/4186469/rust-all-hands-w2011/assets/fallback/index.html around slide 38
1022. # [22:29] <Ms2ger> Though that claims the HTML parser would be in rust
1023. # [22:29] * Quits: MacTed (~Thud@63.119.36.36) (*.net *.split)
1024. # [22:29] * Quits: roc (~chatzilla@222-152-160-29.jetstream.xtra.co.nz) (*.net *.split)
1025. # [22:29] * Quits: mpt (~mpt@canonical/mpt) (*.net *.split)
1026. # [22:29] * Quits: Dashiva (Dashiva@wikia/Dashiva) (*.net *.split)
1027. # [22:29] * Quits: manu-db (~msporny@digitalbazaar.com) (*.net *.split)
1028. # [22:30] * Joins: MacTed (~Thud@63.119.36.36)
1029. # [22:30] * Joins: roc (~chatzilla@222-152-160-29.jetstream.xtra.co.nz)
1030. # [22:30] * Joins: mpt (~mpt@canonical/mpt)
1031. # [22:30] * Joins: Dashiva (Dashiva@wikia/Dashiva)
1032. # [22:30] * Joins: manu-db (~msporny@digitalbazaar.com)
1033. # [22:32] * Quits: tomasf (~tom@c-5ed9e555.024-204-6c6b7012.cust.bredbandsbolaget.se) (Quit: tomasf)
1034. # [22:36] * Joins: shans (~shanestep@74.125.56.17)
1035. # [22:39] * Quits: davidb (~davidb@66.207.208.98) (Quit: davidb)
1036. # [22:40] * Joins: zcorpan (~zcorpan@pat.se.opera.com)
1037. # [22:40] <zcorpan> TabAtkins: now this is some flippin https://twitter.com/#!/wilto/status/126342267337318400
1038. # [22:40] * Quits: tantek (~tantek@70-36-139-219.dsl.dynamic.sonic.net) (Quit: tantek)
1039. # [22:40] * Quits: smaug____ (~chatzilla@cs181151161.pp.htv.fi) (Ping timeout: 258 seconds)
1040. # [22:41] * Quits: miketaylr (~miketaylr@206.217.92.186) (Ping timeout: 276 seconds)
1041. # [22:41] * Joins: KillerX_ (~anant@nat/mozilla/x-dlcffjwnhbtepvyw)
1042. # [22:43] * Joins: cpearce (~chatzilla@60.234.54.74)
1043. # [22:47] * Joins: sicking (~chatzilla@206-15-76-122.static.twtelecom.net)
1044. # [23:02] * Quits: gnarf (~gnarf@unaffiliated/gnarf) (Ping timeout: 258 seconds)
1045. # [23:03] * Parts: zcorpan (~zcorpan@pat.se.opera.com)
1046. # [23:03] * Joins: gnarf (~gnarf@unaffiliated/gnarf)
1047. # [23:05] * Joins: zcorpan (~zcorpan@node-7ahkvq28vc65m79q2.a0.ipv6.opera.com)
1048. # [23:08] * Quits: xtoph (~xtoph@213.47.185.206)
1049. # [23:13] * Quits: hober (~ted@unaffiliated/hober) (Read error: Connection reset by peer)
1050. # [23:14] * Joins: hober (~ted@unaffiliated/hober)
1051. # [23:15] * Joins: mkanat (mkanat@nat/google/x-dwhcoqzujmtcnbre)
1052. # [23:17] * Quits: jamesr (jamesr@nat/google/x-mfrwqsgluwhxcarq) (Ping timeout: 240 seconds)
1053. # [23:20] * Quits: Maurice` (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
1054. # [23:21] * Quits: KillerX_ (~anant@nat/mozilla/x-dlcffjwnhbtepvyw) (Quit: KillerX_)
1055. # [23:21] * Joins: smaug____ (~chatzilla@GGYYYMKDXXVII.gprs.sl-laajakaista.fi)
1056. # [23:21] * Quits: MacTed (~Thud@63.119.36.36)
1057. # [23:21] * Quits: shepazu (~shepazu@64.119.130.114) (Quit: shepazu)
1058. # [23:22] * Quits: Ms2ger (~Ms2ger@91.181.39.217) (Quit: nn)
1059. # [23:23] * Quits: micheil (~micheil@195.24.233.121) (Quit: http://brandedcode.com | http://github.com/miksago)
1060. # [23:25] * Quits: jwm (~jwm@c-50-129-90-95.hsd1.in.comcast.net) (Read error: Connection reset by peer)
1061. # [23:26] * Quits: Areks (~Areks@176.14.214.163) (Ping timeout: 260 seconds)
1062. # [23:27] * Joins: nessy (~Adium@74.125.56.18)
1063. # [23:31] * Parts: zcorpan (~zcorpan@node-7ahkvq28vc65m79q2.a0.ipv6.opera.com)
1064. # [23:33] * Joins: KillerX_ (~anant@70-36-146-71.dsl.dynamic.sonic.net)
1065. # [23:39] * Joins: jwm (~jwm@c-50-129-90-95.hsd1.in.comcast.net)
1066. # [23:40] * Quits: smaug____ (~chatzilla@GGYYYMKDXXVII.gprs.sl-laajakaista.fi) (Ping timeout: 252 seconds)
1067. # [23:48] * Joins: davidb (~davidb@bas1-toronto06-2925210074.dsl.bell.ca)
1068. # [23:52] * Quits: KillerX_ (~anant@70-36-146-71.dsl.dynamic.sonic.net) (Quit: KillerX_)
1069. # [23:53] * Joins: zcorpan (~zcorpan@node-7ahkvq28vc65m79q2.a0.ipv6.opera.com)
1070. # [23:53] * Joins: tantek (~tantek@206-15-76-122.static.twtelecom.net)
1071. # [23:54] * Joins: smaug____ (~chatzilla@YMKDCCXXXVII.gprs.sl-laajakaista.fi)
1072. # Session Close: Wed Oct 19 00:00:00 2011

The end :)