/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 :)