/irc-logs / freenode / #whatwg / 2007-04-03 / end

Options:

  1. # Session Start: Tue Apr 03 00:00:00 2007
  2. # Session Ident: #whatwg
  3. # [00:02] <hsivonen> Hixie: good luck with authors figuring out how to clamp an encoder to that profile
  4. # [00:03] <hsivonen> Hixie: Baseline JPEG works because authors don't have non-baseline software available to them
  5. # [00:03] <Hixie> i'm not the one to convince.
  6. # [00:03] <Hixie> (note how the spec already says Ogg Theora)
  7. # [00:09] * Quits: Philip` (n=excors@zaynar.demon.co.uk) (adams.freenode.net irc.freenode.net)
  8. # [00:09] * Quits: aroben (i=adamrobe@nat/apple/x-7d0e06435459043e) (adams.freenode.net irc.freenode.net)
  9. # [00:09] * Quits: moeffju (i=moeffju@ubermutant.net) (adams.freenode.net irc.freenode.net)
  10. # [00:09] * Quits: hendry (n=hendry@91.84.53.136) (adams.freenode.net irc.freenode.net)
  11. # [00:09] * Quits: dolphinling (n=chatzill@155.42.85.193) (adams.freenode.net irc.freenode.net)
  12. # [00:09] * Quits: gavin (n=gavin@firefox/developer/gavin) (adams.freenode.net irc.freenode.net)
  13. # [00:09] * Quits: psa (n=yomode@71.93.19.66) (adams.freenode.net irc.freenode.net)
  14. # [00:09] * Quits: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl) (adams.freenode.net irc.freenode.net)
  15. # [00:09] * Quits: bzed (n=bzed@dslb-084-059-119-114.pools.arcor-ip.net) (adams.freenode.net irc.freenode.net)
  16. # [00:09] * Quits: Lachy (n=Lachlan@210-84-40-143.dyn.iinet.net.au) (adams.freenode.net irc.freenode.net)
  17. # [00:09] * Quits: mpt (n=mpt@121-72-130-40.dsl.telstraclear.net) (adams.freenode.net irc.freenode.net)
  18. # [00:09] * Quits: dbaron (n=dbaron@corp-242.mountainview.mozilla.com) (adams.freenode.net irc.freenode.net)
  19. # [00:09] * Quits: tantek (n=tantek@dsl092-187-033.sfo1.dsl.speakeasy.net) (adams.freenode.net irc.freenode.net)
  20. # [00:09] * Quits: h3h (n=h3h@66-162-32-234.static.twtelecom.net) (adams.freenode.net irc.freenode.net)
  21. # [00:09] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca) (adams.freenode.net irc.freenode.net)
  22. # [00:09] * Quits: Hixie (n=ianh@trivini.no) (adams.freenode.net irc.freenode.net)
  23. # [00:09] * Quits: Dashiva (i=Dashiva@v035b.studby.ntnu.no) (adams.freenode.net irc.freenode.net)
  24. # [00:09] * Quits: laug (n=laug@poy.chewa.net) (adams.freenode.net irc.freenode.net)
  25. # [00:09] * Quits: hsivonen (n=hsivonen@kekkonen.cs.hut.fi) (adams.freenode.net irc.freenode.net)
  26. # [00:09] * Quits: kingryan (n=kingryan@dsl092-187-033.sfo1.dsl.speakeasy.net) (adams.freenode.net irc.freenode.net)
  27. # [00:09] * Quits: KevinMarks (i=KevinMar@nat/google/x-77421f62a5eb9287) (adams.freenode.net irc.freenode.net)
  28. # [00:09] * Quits: weinig|away (n=weinig@odin.landmark.edu) (adams.freenode.net irc.freenode.net)
  29. # [00:09] * Quits: jgraham (n=jgraham@85-210-140-237.dsl.pipex.com) (adams.freenode.net irc.freenode.net)
  30. # [00:09] * Quits: syp (n=syp@lasigpc9.epfl.ch) (adams.freenode.net irc.freenode.net)
  31. # [00:09] * Quits: citoyen (i=eira@synth.no) (adams.freenode.net irc.freenode.net)
  32. # [00:09] * Quits: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com) (adams.freenode.net irc.freenode.net)
  33. # [00:10] * Quits: marcosc (n=chatzill@131.181.148.226) (adams.freenode.net irc.freenode.net)
  34. # [00:10] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (adams.freenode.net irc.freenode.net)
  35. # [00:10] * Quits: othermaciej (i=mjs@nat/apple/x-471217599cc71116) (adams.freenode.net irc.freenode.net)
  36. # [00:10] * Quits: TML (i=joey@unaffiliated/tml) (adams.freenode.net irc.freenode.net)
  37. # [00:10] * Quits: deltab (n=deltab@82-46-154-93.cable.ubr02.smal.blueyonder.co.uk) (adams.freenode.net irc.freenode.net)
  38. # [00:10] * Quits: bewest (n=ben@httpcraft/bewest) (adams.freenode.net irc.freenode.net)
  39. # [00:11] * Joins: Philip` (n=excors@zaynar.demon.co.uk)
  40. # [00:11] * Joins: hsivonen (n=hsivonen@kekkonen.cs.hut.fi)
  41. # [00:11] * Joins: laug (n=laug@poy.chewa.net)
  42. # [00:11] * Joins: Dashiva (i=Dashiva@v035b.studby.ntnu.no)
  43. # [00:11] * Joins: Hixie (n=ianh@trivini.no)
  44. # [00:11] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  45. # [00:11] * Joins: tantek (n=tantek@dsl092-187-033.sfo1.dsl.speakeasy.net)
  46. # [00:11] * Joins: dbaron (n=dbaron@corp-242.mountainview.mozilla.com)
  47. # [00:11] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
  48. # [00:11] * Joins: marcosc (n=chatzill@131.181.148.226)
  49. # [00:11] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  50. # [00:11] * Joins: citoyen (i=eira@synth.no)
  51. # [00:11] * Joins: aroben (i=adamrobe@nat/apple/x-7d0e06435459043e)
  52. # [00:11] * Joins: psa (n=yomode@71.93.19.66)
  53. # [00:11] * Joins: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl)
  54. # [00:11] * Joins: moeffju (i=moeffju@ubermutant.net)
  55. # [00:11] * Joins: bzed (n=bzed@dslb-084-059-119-114.pools.arcor-ip.net)
  56. # [00:11] * Joins: hendry (n=hendry@91.84.53.136)
  57. # [00:11] * Joins: dolphinling (n=chatzill@155.42.85.193)
  58. # [00:11] * Joins: Lachy (n=Lachlan@210-84-40-143.dyn.iinet.net.au)
  59. # [00:11] * Joins: mpt (n=mpt@121-72-130-40.dsl.telstraclear.net)
  60. # [00:11] * Joins: gavin (n=gavin@firefox/developer/gavin)
  61. # [00:12] * Joins: kingryan (n=kingryan@dsl092-187-033.sfo1.dsl.speakeasy.net)
  62. # [00:12] * Joins: KevinMarks (i=KevinMar@nat/google/x-77421f62a5eb9287)
  63. # [00:12] * Joins: weinig|away (n=weinig@odin.landmark.edu)
  64. # [00:12] * Joins: othermaciej (i=mjs@nat/apple/x-471217599cc71116)
  65. # [00:12] * Joins: TML (i=joey@unaffiliated/tml)
  66. # [00:12] * Joins: deltab (n=deltab@82-46-154-93.cable.ubr02.smal.blueyonder.co.uk)
  67. # [00:12] * Joins: bewest (n=ben@httpcraft/bewest)
  68. # [00:12] * Joins: jgraham (n=jgraham@85-210-140-237.dsl.pipex.com)
  69. # [00:12] * Joins: syp (n=syp@lasigpc9.epfl.ch)
  70. # [00:12] * Joins: h3h (n=h3h@66-162-32-234.static.twtelecom.net)
  71. # [00:29] * Quits: aroben (i=adamrobe@nat/apple/x-7d0e06435459043e)
  72. # [00:29] * Joins: karlUshi (n=karl@124-144-94-185.rev.home.ne.jp)
  73. # [00:43] * Joins: MikeSmith (n=MikeSmit@58.157.21.205)
  74. # [00:55] * Quits: hendry (n=hendry@91.84.53.136) ("leaving")
  75. # [01:19] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  76. # [01:40] <Hixie> we need a better term than readyState
  77. # [01:40] <Hixie> for the CAN_SHOW_/CAN_PLAY_ states
  78. # [01:44] <Hixie> readyState would be fine except that XHR and IE use it for network status
  79. # [01:45] <othermaciej> yeah
  80. # [01:45] <othermaciej> the accurate but too long name would be presentabilityState
  81. # [01:46] <othermaciej> or playabilityState if you wanna be a bit less accurate
  82. # [01:46] <othermaciej> or just playability
  83. # [02:05] * Joins: yod (n=ot@softbank221018155222.bbtec.net)
  84. # [02:06] * Quits: othermaciej (i=mjs@nat/apple/x-471217599cc71116)
  85. # [02:09] * Joins: othermaciej (i=mjs@nat/apple/x-61fdd87ef11366f5)
  86. # [02:18] * Joins: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  87. # [02:18] * Joins: Lachy_ (n=chatzill@58.105.240.232)
  88. # [02:18] * Quits: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net) (Remote closed the connection)
  89. # [02:19] * Joins: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  90. # [02:32] * Joins: welly_ (n=welly@62-31-60-148.cable.ubr12.azte.blueyonder.co.uk)
  91. # [02:34] * moeffju is now known as moeffju[ZzZz]
  92. # [02:35] * Quits: h3h (n=h3h@66-162-32-234.static.twtelecom.net) ("|")
  93. # [02:53] <Hixie> is an event that fires every few 100ms while playing useful, or should position ui be updated via timeouts?
  94. # [02:55] <othermaciej> timeouts + notification of reasons for rate change seem sufficient (that being pause or becoming unplayable)
  95. # [02:55] * Quits: welly_ (n=welly@62-31-60-148.cable.ubr12.azte.blueyonder.co.uk)
  96. # [02:55] <Hixie> ok.
  97. # [02:57] <Hixie> oh another thing, do we want paused to be a mutable attribute, or do we prefer play()/pause() ?
  98. # [02:57] <Hixie> this baby is going to have six bazillion events, jesus
  99. # [02:57] * Hixie has the events up on his whiteboard
  100. # [02:57] * Joins: welly_ (n=welly@149.254.200.218)
  101. # [02:57] <othermaciej> hmm
  102. # [02:58] <othermaciej> play() / pause() seems a lot more natural, even though normally I'd be more inclined to a read/write attribute
  103. # [02:58] <Hixie> that was my conclusion too
  104. # [02:58] <KevinMarks> don't they map to setplayrate anyway?
  105. # [02:59] <Hixie> it's not clear what we're going to do with the proposed playRate stuff
  106. # [02:59] <Hixie> but that's not today's problem anyway
  107. # [02:59] * Hixie is trying to spec out all the states first
  108. # [02:59] <KevinMarks> play() == setPlayRate(1.0) pause == setPlayRate(0) rewind=setPlayRate(-1)
  109. # [02:59] <KevinMarks> etc
  110. # [03:00] * Quits: Lachy_ (n=chatzill@58.105.240.232) (adams.freenode.net irc.freenode.net)
  111. # [03:00] * Quits: Philip` (n=excors@zaynar.demon.co.uk) (adams.freenode.net irc.freenode.net)
  112. # [03:00] <KevinMarks> if you're doing a property approach, that fits
  113. # [03:01] * Hixie ponders whether we need an event specifically for when playback stops despite it not being paused, in addition to the event we have for entering the readyState UNAVAILABLE state (which can also fire for other reasons, e.g. seeking to unbuffered data)
  114. # [03:02] <othermaciej> KevinMarks: Apple's proposal didn't work quite like that
  115. # [03:04] <Hixie> i'd use 'stalled' but we're using that for indicating lack of network progress
  116. # [03:04] <Hixie> maybe 'onwaiting'?
  117. # [03:04] <Hixie> i'll call it 'waiting' for now and we can work out what to do later.
  118. # [03:05] <Hixie> ok that's 20 events for <video> and <audio>
  119. # [03:06] <othermaciej> I think you should read Kevin Calhoun's message about networking models
  120. # [03:06] <othermaciej> I'm not sure 'stalled' makes sense, depending on your access strategy
  121. # [03:06] <othermaciej> (or things like 'bufferRate')
  122. # [03:06] <othermaciej> but he said it better
  123. # [03:06] <Hixie> the one he sent earlier today?
  124. # [03:06] <othermaciej> yes
  125. # [03:07] <Hixie> i've already rolled most of his feedback into the strawman proposal
  126. # [03:07] <Hixie> stalled just means that the UA isn't getting data but is expecting it
  127. # [03:07] <Hixie> provides an easy way to give a "your connection may be broken" message
  128. # [03:08] <Hixie> (or for greasemonkey scripts, e.g., to go in and provide that)
  129. # [03:08] <Hixie> the "seekable" attribute was added in response to his message, btw
  130. # [03:08] <Hixie> i'll reply to it in detail when i go through the e-mail feedback though
  131. # [03:11] * Quits: welly_ (n=welly@149.254.200.218) (Read error: 145 (Connection timed out))
  132. # [03:12] <othermaciej> I think "readonly attribute TimeRanges seekable" may be more general than needed, in practice I would expect you have only a single range at the beginning or you pretend any point is available
  133. # [03:12] <othermaciej> I think keeping a list of buffered ranges is just not applicable to some loading strategies so maybe we should think about what problem it is trying to solve
  134. # [03:13] <othermaciej> and I think bufferingRate isn't useful
  135. # [03:14] <othermaciej> if you want to estimate bytes per second, there's always progress events for that
  136. # [03:14] <othermaciej> although I'm not really sure how progress events would apply to an RTSP stream, or something that buffers incrementally using byte range requests
  137. # [03:18] * Joins: welly_ (n=welly@62-31-60-148.cable.ubr12.azte.blueyonder.co.uk)
  138. # [03:30] <KevinMarks> othermaciej: think about the bittorrent case, where you may have multiple blocks cached but not all
  139. # [03:31] <othermaciej> KevinMarks: bittorrent isn't the only case where that can happen
  140. # [03:31] <KevinMarks> I know, I'm using it as an example
  141. # [03:31] <othermaciej> KevinMarks: but bittorrent isn't something you'd use as a protocol to back video playback, since it gives you the data in random order
  142. # [03:31] <othermaciej> which is useless unless you are willing to download the whole thing up front
  143. # [03:32] <KevinMarks> no, you can treat it statistically like a fast-start
  144. # [03:33] <KevinMarks> when you have enough contiguous pieces from the start to play for longer then expected remaining download time, you can play
  145. # [03:35] <Hixie> hm, there are two error states really
  146. # [03:35] <Hixie> one where the media is still partly playable
  147. # [03:35] <Hixie> and one where it's not
  148. # [03:35] <KevinMarks> Kevin Calhoun wrote a usenet datahandler that would collect chunks from alt.binaries postings
  149. # [03:36] <othermaciej> the thing is, with bittorrent, the timewise first chunk could be the last you get
  150. # [03:37] <KevinMarks> yes, so at that point you do need to wait for the whole thing
  151. # [03:37] * Quits: kingryan (n=kingryan@dsl092-187-033.sfo1.dsl.speakeasy.net)
  152. # [03:39] <othermaciej> so yeah, you could make it work, it just wouldn't be advisable to serve page-embedded video by bittorrent
  153. # [03:40] <othermaciej> unless it is small enough to d/l the whole thing quickly
  154. # [03:40] <othermaciej> in which case, why bother w/ torrent
  155. # [03:41] <KevinMarks> I find torrents about the same speed as pulling videos from itunes store via akamai at home
  156. # [03:42] <KevinMarks> so it's a little moot
  157. # [03:44] <KevinMarks> for a fast-start, you know it is mostly coming in order, so you reach the expected completion time sooner, but for a torrent or sliced usenet download you can still reach it before download is complete
  158. # [03:46] <othermaciej> yeah the torrent problem is just that there's no way to bias it towards timewise earlier chunks and it is fine-grained enough that this is likely to hose you
  159. # [03:48] * Quits: othermaciej (i=mjs@nat/apple/x-61fdd87ef11366f5)
  160. # [03:48] <KevinMarks> well, there is, as which chunk you request is under client control, so you could favour earlier ones between otherwise equivalent ones (the next chunk rule is usually a function of rarity and others estimated rates)
  161. # [03:50] * Quits: KevinMarks (i=KevinMar@nat/google/x-77421f62a5eb9287) ("The computer fell asleep")
  162. # [04:08] * Joins: jcgregorio (n=chatzill@adsl-072-148-043-048.sip.rmo.bellsouth.net)
  163. # [04:12] <Hixie> i'm not sure how to handle this error problem
  164. # [04:12] <Hixie> short of having two error states
  165. # [04:12] <Hixie> or three, even
  166. # [04:13] * Hixie changes topic to 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks!'
  167. # [04:18] * Quits: welly_ (n=welly@62-31-60-148.cable.ubr12.azte.blueyonder.co.uk) (Read error: 110 (Connection timed out))
  168. # [04:20] <Hixie> hm, the apple proposal doesn't handle this at all, it just has an error state for the early part
  169. # [04:20] <Hixie> not for the later part
  170. # [04:26] * Quits: tantek (n=tantek@dsl092-187-033.sfo1.dsl.speakeasy.net)
  171. # [04:29] * Quits: bzed (n=bzed@dslb-084-059-119-114.pools.arcor-ip.net) ("Leaving")
  172. # [04:31] * Joins: htmlr (n=cjb@CPE-138-130-176-60.nsw.bigpond.net.au)
  173. # [04:45] * Quits: htmlr (n=cjb@CPE-138-130-176-60.nsw.bigpond.net.au)
  174. # [04:46] * Joins: htmlr (n=cjb@CPE-138-130-176-60.nsw.bigpond.net.au)
  175. # [04:53] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  176. # [04:54] * Quits: dbaron (n=dbaron@corp-242.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  177. # [05:07] * Joins: htmlr_ (n=cjb@CPE-138-130-176-60.nsw.bigpond.net.au)
  178. # [05:07] * Quits: htmlr (n=cjb@CPE-138-130-176-60.nsw.bigpond.net.au) (Read error: 54 (Connection reset by peer))
  179. # [05:14] * Joins: htmlr (n=cjb@210-84-51-60.dyn.iinet.net.au)
  180. # [05:19] * Quits: htmlr_ (n=cjb@CPE-138-130-176-60.nsw.bigpond.net.au) (Read error: 60 (Operation timed out))
  181. # [05:35] * Joins: othermaciej (n=mjs@netblock-66-245-248-74.dslextreme.com)
  182. # [05:43] * Quits: syp (n=syp@lasigpc9.epfl.ch) (adams.freenode.net irc.freenode.net)
  183. # [05:43] * Quits: jgraham (n=jgraham@85-210-140-237.dsl.pipex.com) (adams.freenode.net irc.freenode.net)
  184. # [05:43] * Quits: othermaciej (n=mjs@netblock-66-245-248-74.dslextreme.com)
  185. # [05:43] * Joins: jgraham (n=jgraham@85-210-140-237.dsl.pipex.com)
  186. # [05:43] * Joins: syp (n=syp@lasigpc9.epfl.ch)
  187. # [05:45] * Joins: syp_ (n=syp@lasigpc9.epfl.ch)
  188. # [05:45] * Joins: othermaciej (n=mjs@netblock-66-245-248-74.dslextreme.com)
  189. # [05:52] * Quits: syp (n=syp@lasigpc9.epfl.ch) (Read error: 104 (Connection reset by peer))
  190. # [05:55] * Quits: othermaciej (n=mjs@netblock-66-245-248-74.dslextreme.com) (Read error: 60 (Operation timed out))
  191. # [05:57] * Quits: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net) (Read error: 54 (Connection reset by peer))
  192. # [06:13] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  193. # [06:22] * Joins: Lachy_ (n=chatzill@220-245-91-147.static.tpgi.com.au)
  194. # [06:24] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  195. # [06:45] * Joins: h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com)
  196. # [06:51] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  197. # [06:51] <Lachy_> yay! XHTML+RDFa :-) http://www.w3.org/MarkUp/2007/ED-xhtml-rdfa-20070402/
  198. # [06:52] <othermaciej> it's a day late
  199. # [06:53] <Lachy_> yeah, but got to give them credit for stealing our HTML6 ideas so quickly
  200. # [06:55] <othermaciej> I see exactly three user agent conformance requirements
  201. # [06:55] <othermaciej> all of which are stupid
  202. # [06:59] <Lachy_> I found 3 MUST level and 1 SHOULD level UA requirement
  203. # [07:00] <othermaciej> ah, I missed the SHOULD
  204. # [07:03] <Lachy_> the whole thing is impossible to implement anyway, since it reuses the XHTML1 NS in incompatible ways
  205. # [07:03] <othermaciej> is this supposed to be part of XHTML2?
  206. # [07:03] <Lachy_> it appears to be XHTML1
  207. # [07:04] <Lachy_> "This document is an internal editors draft for development purposes. However, its content is based upon mature materials from [XHTML2] and is therefore considered nearly complete."
  208. # [07:04] <othermaciej> it seems to assume href on every element
  209. # [07:04] <Lachy_> that explains the problem
  210. # [07:05] <othermaciej> well, XHTML5 presumably won't have modularization so we will be safe
  211. # [07:11] * Quits: mpt (n=mpt@121-72-130-40.dsl.telstraclear.net) ("This computer has gone to sleep")
  212. # [07:17] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  213. # [07:24] <Lachy_> I just love how easy DTDs make things --> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Apr/0017.html
  214. # [07:25] <Hixie> introducing a new status to mean "not completely loaded but partialy loaded and we're not going to bother getting more" seems like more work than it's worth
  215. # [07:25] <Hixie> (for implementors and authors)
  216. # [07:25] <Hixie> but the alternative is to have the 'error' event send to either ERROR or LOADED depending on whether we passed LOADED_INITIAL_FRAME or not
  217. # [07:25] <Hixie> which seems poor
  218. # [07:27] * Quits: jcgregorio (n=chatzill@adsl-072-148-043-048.sip.rmo.bellsouth.net) ("Chatzilla 0.9.77 [Firefox 2.0.0.2/0000000000]")
  219. # [07:31] <Hixie> this sucks
  220. # [07:31] <Hixie> having a network problem or user cancelation nearly arbitrarily result in a LOADED or an ERROR is stupid
  221. # [07:32] <Hixie> in the former case there's no way to catch the error if joining late, e.g.
  222. # [07:32] <Hixie> but we can't use the same code as otherwise you can't tell if the other attributes are safe
  223. # [07:32] <Hixie> maybe we should just have a lastError attribute
  224. # [07:32] <Hixie> which is reset when you get a successful transition
  225. # [07:32] <Hixie> or rather, is reset by load()
  226. # [07:33] <Hixie> or maybe when we have an error or abort we should leave the state in its last state and set an error flag
  227. # [07:33] <othermaciej> I'm not sure you should go to LOADED on a user cancel or late error - probably better to stay in current state with alternate way to get the error (like lastError)
  228. # [07:33] <Hixie> that way you can see where the error occured
  229. # [07:34] <othermaciej> that might obviate the need for an ERROR state I guess
  230. # [07:34] <Hixie> yeah
  231. # [08:01] * Joins: KevinMarks (n=Snak@h-68-164-93-9.snvacaid.dynamic.covad.net)
  232. # [08:01] * Quits: h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com)
  233. # [08:02] <Hixie> man, the list of ways in which playback can stop when the media isn't paused is getting longer by the hour
  234. # [08:03] <othermaciej> oh yeah?
  235. # [08:03] <othermaciej> what besides entering non-playable state or reaching the end?
  236. # [08:05] <Hixie> currently: seeking (UNAVAILABLE and paused=false and seeking=true), buffering (UNAVAILABLE or CAN_SHOW_CURRENT_FRAME and paused=false and seeking=false, playback position isn't in the buffered range), ended is true, and a fatal error occured, either network error or during decoding.
  237. # [08:06] <Hixie> currently the first two will fire a 'waiting' event when they occur, the latter two won't.
  238. # [08:06] <othermaciej> fatal error partway should arguably count as truncating the duration
  239. # [08:07] * KevinMarks remembers all those arcane QuickTime chapters on clocks
  240. # [08:07] <Hixie> fatal errors might occur decoding the stream half-way, with a later part of the stream still playable if seeked to (i see this on DVDs often, sadly)
  241. # [08:07] <Hixie> not sure we care about that though
  242. # [08:16] * Quits: yod (n=ot@softbank221018155222.bbtec.net) ("Leaving")
  243. # [08:37] * Joins: santek (n=st@ut-w-7bd6.mxs.adsl.euronet.nl)
  244. # [09:03] <Hixie> should i reuse 'reset' for when we reset the <video> element when load() is invoked on an already-running <video>?
  245. # [09:06] <othermaciej> what else is 'reset' used for?
  246. # [09:06] <Hixie> forms
  247. # [09:09] * Quits: htmlr (n=cjb@210-84-51-60.dyn.iinet.net.au)
  248. # [09:13] <Hixie> hm, 'reset' bubbles for forms
  249. # [09:14] <Hixie> i guess i could make one here that doesn't but that seems like it would just confuse matters.
  250. # [09:15] * Quits: santek (n=st@ut-w-7bd6.mxs.adsl.euronet.nl)
  251. # [09:15] <Hixie> 'emptied' will do for now
  252. # [09:35] * Joins: met_ (n=Martin@b14-4.vscht.cz)
  253. # [09:35] * Joins: htmlr (n=cjb@210-84-51-60.dyn.iinet.net.au)
  254. # [09:38] * Quits: Lachy_ (n=chatzill@220-245-91-147.static.tpgi.com.au) ("Chatzilla 0.9.77 [Firefox 2.0.0.3/2007030919]")
  255. # [09:44] <Hixie> http://www.whatwg.org/specs/web-apps/current-work/source#mediaevents may be of interest
  256. # [09:49] <othermaciej> definition of "stalled" in the prose seems wrong (though description in the table is ok)
  257. # [09:49] <othermaciej> "If at any point the user agent has received no data for more than about three seconds, the user agent must fire a stalled event at the element."
  258. # [09:50] <Hixie> the prose isn't done yet
  259. # [09:50] <Hixie> i just did the table
  260. # [09:50] <Hixie> most of the prose is unchanged from the original checkin before the apple proposal was sent to the list
  261. # [09:51] <othermaciej> event names seem to be a mix of past and present tense
  262. # [09:52] <othermaciej> that is indeed a whole lot of events
  263. # [09:52] <Hixie> yeah at some point we need to do a cleanup of the names in this section
  264. # [09:52] <Hixie> events, constants, methods, attributes
  265. # [09:52] <Hixie> right now i just want to get the thing described
  266. # [09:53] <Hixie> the names can be discussed in the html wg :-P
  267. # [09:54] <hsivonen> ExternalizeBikeshedding as a design principle? :-)
  268. # [09:54] <othermaciej> hah
  269. # [09:54] <Hixie> :-)
  270. # [09:55] * Joins: ROBOd (n=robod@86.34.246.154)
  271. # [09:56] <othermaciej> is Murray Maloney a known person in the web standards world?
  272. # [09:57] * Joins: mpt (n=mpt@121-72-130-40.dsl.telstraclear.net)
  273. # [09:57] <Hixie> othermaciej: yes
  274. # [09:57] <othermaciej> I think I upset him by implying that the fact that he agreed or disagreed with something, with no further info, was uninteresting
  275. # [09:57] <othermaciej> (by private email)
  276. # [09:58] <Hixie> hah
  277. # [09:59] <Hixie> http://www.xml.com/pub/au/56 describes for what he's known pretty succintly
  278. # [10:59] * Joins: hendry (n=hendry@91.84.53.136)
  279. # [11:02] * Joins: welly_ (n=welly@62-31-60-148.cable.ubr12.azte.blueyonder.co.uk)
  280. # [11:06] * othermaciej is now known as om_sleep
  281. # [11:08] <MikeSmith> Hixie, om_sleep - I think Murray was also active back in the day in the IETF HTML WG
  282. # [11:08] <MikeSmith> https://listserv.heanet.ie/cgi-bin/wa?A0=html-wg
  283. # [11:09] * om_sleep obviously has no respect for his elders
  284. # [11:09] <om_sleep> I gave Dave Raggett a hard time too
  285. # [11:12] <MikeSmith> om_sleep - Dave's got thick skin. I don't know Murray personally, but I'd guess he's been involved enough in mailing list discussions to not get upset and take stuff personally
  286. # [11:13] <MikeSmith> and I think it's good for him to know how annoying people find those multiple +1 messages
  287. # [11:15] * Quits: welly_ (n=welly@62-31-60-148.cable.ubr12.azte.blueyonder.co.uk)
  288. # [11:20] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  289. # [11:27] * Quits: mpt (n=mpt@121-72-130-40.dsl.telstraclear.net) (Read error: 110 (Connection timed out))
  290. # [11:32] * Joins: mpt (n=mpt@121-72-137-137.dsl.telstraclear.net)
  291. # [11:39] * Quits: jgraham (n=jgraham@85-210-140-237.dsl.pipex.com) ("Leaving")
  292. # [11:48] * Quits: mpt (n=mpt@121-72-137-137.dsl.telstraclear.net) (Read error: 60 (Operation timed out))
  293. # [12:21] * Quits: hendry (n=hendry@91.84.53.136) (Remote closed the connection)
  294. # [13:11] * Joins: ravenn (n=ravenn@203-214-133-148.perm.iinet.net.au)
  295. # [13:12] * moeffju[ZzZz] is now known as moeffju
  296. # [13:49] * Joins: Philip` (n=excors@zaynar.demon.co.uk)
  297. # [14:08] * Joins: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  298. # [14:11] * Quits: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net) (Remote closed the connection)
  299. # [14:11] * Joins: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  300. # [14:16] * Joins: hendry (n=hendry@91.84.53.136)
  301. # [14:17] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  302. # [14:34] <hsivonen> clearly, http://www.w3.org/TR/2007/WD-curie-20070307/ has not been developed with backwards compat in mind
  303. # [14:36] <Lachy> did you expect it to be?
  304. # [14:36] <hsivonen> Lachy: I didn't.
  305. # [14:37] <hsivonen> but if it becomes a REC, some people might ask it to be supported for the XHTML 1.x namespace. :-(
  306. # [14:38] <hsivonen> qNames in content is already an anti-pattern
  307. # [14:39] <Lachy> I haven't actually read curie yet, how is it supposed to work?
  308. # [14:40] <Lachy> I'll just go read it, since it's quite short
  309. # [14:40] <hsivonen> Lachy: IRIs that start with [ and end with ] are treated as bracketed qNames that are resolved relative to namespace URIs
  310. # [14:55] * Quits: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net) (Read error: 110 (Connection timed out))
  311. # [15:04] * Quits: Lachy (n=Lachlan@210-84-40-143.dyn.iinet.net.au) (Read error: 104 (Connection reset by peer))
  312. # [15:04] * Joins: Lachy (n=Lachlan@210-84-40-143.dyn.iinet.net.au)
  313. # [15:06] <Lachy> I just finished reading the spec. It seems curies could be potentially useful in an authoring tool or CMS that processes them and outputs the full URIs to the web
  314. # [15:33] * Parts: ravenn (n=ravenn@203-214-133-148.perm.iinet.net.au)
  315. # [15:52] <hsivonen> Hixie: btw, do you have a reference to H.264 Baseline being free of enforceable patents?
  316. # [15:54] <hsivonen> I find it unbelievable that Baseline would be unencumbered. I would have expected to have heard the details by now elsewhere if it was.
  317. # [15:56] * Joins: Charl (n=Charl@spotter.nmmu.ac.za)
  318. # [16:01] * Quits: psa (n=yomode@71.93.19.66) (Read error: 110 (Connection timed out))
  319. # [16:42] * Joins: hendry_ (n=hendry@91.84.53.136)
  320. # [16:47] * Quits: hendry (n=hendry@91.84.53.136) (Read error: 145 (Connection timed out))
  321. # [16:52] * Joins: ericcarlson (i=ericcarl@nat/apple/x-972d227fe38ff7dc)
  322. # [17:18] * Quits: ericcarlson (i=ericcarl@nat/apple/x-972d227fe38ff7dc)
  323. # [17:21] * Quits: met_ (n=Martin@b14-4.vscht.cz) ("Chemists never die, they just stop reacting.")
  324. # [17:25] * om_sleep is now known as othermaciej
  325. # [17:27] * Joins: h3h (n=h3h@66-162-32-234.static.twtelecom.net)
  326. # [18:05] * Joins: tylerr (n=tylerr@outbound.wa1.ascentium.com)
  327. # [18:12] * Quits: Charl (n=Charl@spotter.nmmu.ac.za)
  328. # [18:18] * Joins: zcorpan (n=zcorpan@84-216-43-95.sprayadsl.telenor.se)
  329. # [18:19] * zcorpan was in linköping today
  330. # [18:21] <tylerr> Did you say hello to the Cardigans? :-)
  331. # [18:21] <hasather> zcorpan: how did it go?
  332. # [18:22] <hasather> tylerr: they are from Jönköping
  333. # [18:22] <hasather> if I'm not mistaken
  334. # [18:22] <zcorpan> hasather: it went well
  335. # [18:22] <tylerr> Oh! I need to check my sources then.
  336. # [18:22] <hasather> zcorpan: you got the job?
  337. # [18:22] <zcorpan> don't know yet
  338. # [18:22] <zcorpan> but it seems likely
  339. # [18:22] <tylerr> Ah yes you're right hasather, Jönköping. I get my pings confused. :-)
  340. # [18:22] <hasather> ok, but great that it went well
  341. # [18:23] <hasather> tylerr: :)
  342. # [18:24] <zcorpan> they knew more about html5 than last time i was there. talked to two other guys this time (although only one of them seemed to know stuff about html5)
  343. # [18:24] <zcorpan> last time i was there (in august) i talked to an svg guy or something
  344. # [18:24] <hasather> ok
  345. # [18:26] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net) (Read error: 54 (Connection reset by peer))
  346. # [18:26] <hasather> zcorpan: did they like your idea about a HTML5 test suite?
  347. # [18:26] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  348. # [18:27] <zcorpan> yeah
  349. # [18:27] <hasather> cool
  350. # [18:27] <zcorpan> although they could come up with other stuff i could work on too
  351. # [18:27] <zcorpan> like internal test suites or something
  352. # [18:33] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  353. # [18:42] * Joins: santek (n=st@ut-w-7bd6.mxs.adsl.euronet.nl)
  354. # [18:43] * Joins: aroben (i=adamrobe@nat/apple/x-4402603ae40e2671)
  355. # [18:48] * Joins: kingryan (n=kingryan@dsl092-187-033.sfo1.dsl.speakeasy.net)
  356. # [18:49] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  357. # [19:00] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  358. # [19:05] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  359. # [19:13] * Joins: tantek (n=tantek@dsl092-187-033.sfo1.dsl.speakeasy.net)
  360. # [19:15] <zcorpan> anyone know what "interoperable" is in swedish?
  361. # [19:16] <zcorpan> samfungerande?
  362. # [19:22] <zcorpan> or simply "interopererande"?
  363. # [19:22] * Quits: htmlr (n=cjb@210-84-51-60.dyn.iinet.net.au)
  364. # [19:26] <hasather> zcorpan: both could probably work, don't know a good word for it myself
  365. # [19:28] <zcorpan> http://sv.wikipedia.org/wiki/Interoperabilitet
  366. # [19:28] * zcorpan will go with the latter
  367. # [19:28] <hasather> yea, found that
  368. # [19:29] <hasather> zcorpan: ineroperabel maybe
  369. # [19:29] <hasather> +t
  370. # [19:30] <hasather> not a common Swedish word though
  371. # [19:37] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca) (Read error: 104 (Connection reset by peer))
  372. # [19:37] <zcorpan> interoperable it is
  373. # [19:37] <zcorpan> er
  374. # [19:38] <zcorpan> interoperabel
  375. # [19:38] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  376. # [19:50] * Joins: met_ (n=Hassman@r5bx220.net.upc.cz)
  377. # [19:56] * Joins: epeus (i=KevinMar@nat/google/x-0414ccd3972189fd)
  378. # [19:57] * Quits: KevinMarks (n=Snak@pdpc/supporter/active/kevinmarks) (Nick collision from services.)
  379. # [19:57] * epeus is now known as KevinMarks
  380. # [20:01] * Joins: dbaron (n=dbaron@corp-242.mountainview.mozilla.com)
  381. # [20:12] * Joins: bzed (n=bzed@dslb-084-059-120-121.pools.arcor-ip.net)
  382. # [20:25] * Quits: zcorpan (n=zcorpan@84-216-43-95.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  383. # [20:31] * Joins: zcorpan (n=zcorpan@esk-ba-1-nomad.net.mdh.se)
  384. # [20:57] * Quits: zcorpan (n=zcorpan@esk-ba-1-nomad.net.mdh.se) (Read error: 110 (Connection timed out))
  385. # [20:58] * Quits: ROBOd (n=robod@86.34.246.154) (Remote closed the connection)
  386. # [20:59] * Joins: ROBOd (n=robod@86.34.246.154)
  387. # [21:22] <Hixie> hsivonen: no, nobody seems willing to make that kind of claim on record :-(
  388. # [21:22] * Parts: tylerr (n=tylerr@outbound.wa1.ascentium.com)
  389. # [21:22] * Joins: tylerr (n=tylerr@outbound.wa1.ascentium.com)
  390. # [21:26] * Joins: markp (n=pilgrim@adsl-221-33-29.rmo.bellsouth.net)
  391. # [21:30] <markp> all right, this is probably a FAQ, but what's up with accesskey?
  392. # [21:31] <markp> it's mentioned repeatedly in wf2 but not at all in html5
  393. # [21:34] <Hixie> haven't yet worked out wtf to do with it
  394. # [21:35] <Hixie> it's so fundamentally broken in so many ways...
  395. # [21:35] <markp> documenting current practice isn't sufficient?
  396. # [21:35] <markp> i understand the extent of its brokenness
  397. # [21:36] <Hixie> currnet practice varies dramatically and is fundamentally broken
  398. # [21:36] <markp> that has never stopped you before...
  399. # [21:38] * hendry_ is now known as hendry
  400. # [21:38] <Hixie> markp: the difference is that for accesskey i don't know how to fix it :-(
  401. # [21:39] <markp> i see
  402. # [21:44] <markp> argh!
  403. # [21:44] <markp> http://msdn2.microsoft.com/en-us/library/ms535181.aspx
  404. # [21:44] <markp> "This example uses the address element to italicize text."
  405. # [21:44] <markp> just shoot me
  406. # [21:57] <markp> http://www.whatwg.org/specs/web-apps/current-work/#area does not define the nohref attribute
  407. # [21:57] <Hixie> what does the nohref attribute do?
  408. # [21:57] <markp> described here: http://www.w3.org/TR/html401/struct/objects.html#adef-nohref
  409. # [21:58] <Hixie> but what does the nohref attribute do?
  410. # [21:58] <Hixie> (there are few UA conformance requirements in the HTML4 spec, and none for nohref, so it's not a good source of information for what things in HTML do)
  411. # [21:59] <markp> i understand
  412. # [22:00] <markp> i believe it's a way of marking that the <area>'s lack of an @href attribute is intentional
  413. # [22:00] <Hixie> so it does nothing?
  414. # [22:00] <markp> i.e. for validation
  415. # [22:00] <markp> checking firefox code
  416. # [22:01] <markp> hang on
  417. # [22:01] <Hixie> (and if we can't trust that the lack of an href attribute is intentional, why can we trust that the presence of a nohref attribute _is_?)
  418. # [22:02] <markp> firefox does precisely nothing with it
  419. # [22:02] <markp> no changes in behavior, nothing
  420. # [22:02] <Hixie> ok then
  421. # [22:02] <markp> http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/nohref.asp says "Sets or retrieves whether clicks in this region cause action."
  422. # [22:02] <markp> which is slightly tantalizing
  423. # [22:02] <Hixie> msdn is wrong. :-)
  424. # [22:03] <Hixie> i tested it a lot, couldn't find that the attribute did anything, so i dropped it
  425. # [22:03] <Hixie> it seemed singularily pointless.
  426. # [22:03] <markp> aha
  427. # [22:03] <markp> http://www.idocs.com/tags/images/_AREA_NOHREF.html
  428. # [22:03] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  429. # [22:03] <markp> it is for dead zones in shaped <area>s
  430. # [22:04] <markp> see the idocs link
  431. # [22:06] <Hixie> yes but how does that differ from the lack of an href attribute?
  432. # [22:08] <markp> hacking the idocs test case reveals that there is no difference
  433. # [22:08] <markp> i have discovered html's most useless attribute
  434. # [22:08] <Hixie> pretty much
  435. # [22:08] <markp> or, more likely, rediscovered
  436. # [22:09] * Joins: tantek_ (n=tantek@dsl092-187-033.sfo1.dsl.speakeasy.net)
  437. # [22:09] * Quits: tantek (n=tantek@dsl092-187-033.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
  438. # [22:18] * Joins: aja (n=chatzill@adsl-70-237-142-180.dsl.stlsmo.sbcglobal.net)
  439. # [22:26] <aja> hi all...offering some experience re: 512 scanning for encoding. GRDDL parsing seems to be depending on profile for each microformat...and if one defines each official and draft uF, 512 is rapidly approached. might be something to work out with the GRDDL/hGRDDL WG folks
  440. # [22:27] <aja> 2nd concern: if multiple media and/or alternate stylesheet PI's are used, 512 can become a concern, too
  441. # [22:31] * Joins: Lachy_ (n=Lachlan@203-214-144-160.perm.iinet.net.au)
  442. # [22:33] * Quits: met_ (n=Hassman@r5bx220.net.upc.cz) ("Chemists never die, they just stop reacting.")
  443. # [22:39] * Quits: Lachy (n=Lachlan@210-84-40-143.dyn.iinet.net.au) (Read error: 145 (Connection timed out))
  444. # [22:41] * aja is now known as a-ja
  445. # [22:46] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  446. # [22:49] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  447. # [22:57] <KevinMarks> what's the significance of 512?
  448. # [22:59] <a-ja> KevinMarks: only first 512 bytes scanned for content encoding
  449. # [23:00] <KevinMarks> you mean explicit content-encoding, or for statistical guessing?
  450. # [23:00] * Parts: KevinMarks (i=KevinMar@pdpc/supporter/active/kevinmarks)
  451. # [23:00] * Joins: KevinMarks (i=KevinMar@pdpc/supporter/active/kevinmarks)
  452. # [23:00] <KevinMarks> oops
  453. # [23:00] <a-ja> explicit
  454. # [23:00] <KevinMarks> so the recommendation is to put the profiles after the content header?
  455. # [23:02] <a-ja> guess putting them on individuaal uF-containing elements rather than on <html> would do....but is that supported already?
  456. # [23:04] <Hixie> a-ja: we've dropped profile="" from HTML5 at the moment
  457. # [23:04] <Hixie> a-ja: based on the principle that nobody on the web was actually using it
  458. # [23:04] <a-ja> tell the GRDDL WG !
  459. # [23:05] <a-ja> tks, Hixie...wasn't aware of that. did see some related discussion back in Dec though
  460. # [23:05] <Hixie> nobody uses GRDDL either :-)
  461. # [23:06] <a-ja> heheh....certainly not yet anyway
  462. # [23:06] <Dashiva> GRDDL doesn't sound cool enough
  463. # [23:07] <a-ja> doesn't have the same ring to it that RDFa has?
  464. # [23:07] <Dashiva> It's missing at least one X
  465. # [23:09] <Hixie> well more importantly, there doesn't really seem to be much demand for a microformats-to-RDF convertor
  466. # [23:09] <Hixie> most people who consume microformats will just have microformat-specific parsers
  467. # [23:10] <a-ja> true enuff....and i haven't seen one yet that looked for a profile
  468. # [23:11] <a-ja> "in the wild" anyway
  469. # [23:11] <KevinMarks> as publishing profiles is a major pain
  470. # [23:11] <KevinMarks> and grepping for the container class is easier
  471. # [23:16] <Hixie> when someone changes the <video src=""> and invokes .load() again, what should happen?
  472. # [23:17] <Hixie> should everything reset to initial values?
  473. # [23:17] <Hixie> should events be fired for each attribute that's reset?
  474. # [23:27] <Dashiva> Looking at xhr, some kind of abort/unload event coupled with state changes to 0/empty/uninit. More than that could get really messy
  475. # [23:51] * Joins: othermaciej (i=mjs@nat/apple/x-4e91ed9e92950315)
  476. # [23:52] <othermaciej> Hixie: sorry for not being in the right place
  477. # [23:52] <Hixie> no worries
  478. # [23:52] <Hixie> i was confused
  479. # [23:52] <Hixie> anyway
  480. # [23:52] <Hixie> 23:17 < Hixie>|when someone changes the <video src=""> and invokes .load() again, what should happen?
  481. # [23:52] <Hixie> 23:17 < Hixie>|should everything reset to initial values?
  482. # [23:52] <Hixie> 23:17 < Hixie>|should events be fired for each attribute that's reset?
  483. # [23:54] <Hixie> in particular, right load you invoke a load() method to restart the video element with a new source
  484. # [23:54] <Hixie> but that needs to fire a whole sequence of events: abort on the previous thing, emptied because we're going back to zero, paused if it was previously playing, unavailable if we had a frame before, begin to indicate we've started a new download
  485. # [23:55] <Hixie> and i'm not really sure what order those events should fire in, and whether they should fire before or after load() returns
  486. # [23:56] <Hixie> it feels like 'abort' should fire after it returns, but it also feels like the attributes should be reset before it returns, and it feels like they should be reset after abort is fired
  487. # [23:56] <Hixie> which is an overconstrained situation
  488. # [23:56] <Hixie> we could just say that you can't re-use a <video> but that seems dumb
  489. # [23:56] <Hixie> i think i'm going to think on this while cycling to work. feel free to describe your thoughts here and i'll read them when i get in.
  490. # Session Close: Wed Apr 04 00:00:00 2007

The end :)