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

Options:

  1. # Session Start: Sun Apr 01 00:00:00 2007
  2. # Session Ident: #whatwg
  3. # [00:18] * Joins: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  4. # [00:34] * Quits: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  5. # [01:12] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  6. # [01:41] * Joins: welly (n=welly@62-31-60-148.cable.ubr12.azte.blueyonder.co.uk)
  7. # [01:43] * Quits: hendry (n=hendry@91.84.53.136) (Remote closed the connection)
  8. # [02:49] * Joins: virtuelv (n=arve@ti132110a341-1087.bb.online.no)
  9. # [02:52] * Quits: virtuelv (n=arve@ti132110a341-1087.bb.online.no) (Client Quit)
  10. # [03:28] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  11. # [03:31] * Joins: ravenn (n=ravenn@203-214-133-148.perm.iinet.net.au)
  12. # [03:31] * Joins: zcorpan (n=zcorpan@esk-ba-1-nomad.net.mdh.se)
  13. # [03:33] * Quits: welly (n=welly@62-31-60-148.cable.ubr12.azte.blueyonder.co.uk)
  14. # [03:46] * Joins: zcorpan_ (n=zcorpan@esk-ba-1-nomad.net.mdh.se)
  15. # [03:51] * Joins: welly (n=welly@62-31-60-148.cable.ubr12.azte.blueyonder.co.uk)
  16. # [03:52] * Quits: zcorpan (n=zcorpan@esk-ba-1-nomad.net.mdh.se) (Read error: 145 (Connection timed out))
  17. # [03:53] * Quits: jcgregorio (n=chatzill@adsl-072-148-043-048.sip.rmo.bellsouth.net) ("Chatzilla 0.9.77 [Firefox 2.0.0.2/0000000000]")
  18. # [04:05] * Quits: welly (n=welly@62-31-60-148.cable.ubr12.azte.blueyonder.co.uk)
  19. # [04:06] * Quits: Philip` (n=excors@zaynar.demon.co.uk)
  20. # [04:13] * Quits: Lachy (n=Lachlan@210-84-40-143.dyn.iinet.net.au) (Read error: 104 (Connection reset by peer))
  21. # [04:13] * Joins: Lachy (n=Lachlan@210-84-40-143.dyn.iinet.net.au)
  22. # [04:15] * om_lunch is now known as othermaciej
  23. # [04:33] * Quits: Lachy (n=Lachlan@210-84-40-143.dyn.iinet.net.au) (Read error: 104 (Connection reset by peer))
  24. # [04:33] * Joins: Lachy (n=Lachlan@210-84-40-143.dyn.iinet.net.au)
  25. # [04:52] * bzed is now known as bzed|n8n8
  26. # [04:55] * Quits: bzed|n8n8 (n=bzed@dslb-084-059-122-125.pools.arcor-ip.net) ("Leaving")
  27. # [05:05] * Joins: h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com)
  28. # [05:15] <zcorpan_> <meta http-equiv=content-access-control> should perhaps be allowed, as the html version of <?access-control?>
  29. # [05:32] * Joins: tantek (n=tantek@208-106-21-119.dsl.static.sonic.net)
  30. # [06:16] * Joins: tantek_ (n=tantek@208-106-21-119.dsl.static.sonic.net)
  31. # [06:16] * Quits: tantek (n=tantek@208-106-21-119.dsl.static.sonic.net) (Connection timed out)
  32. # [06:25] * Joins: tantek (n=tantek@208-106-21-119.dsl.static.sonic.net)
  33. # [06:30] * moeffju is now known as moeffju[ZzZz]
  34. # [06:39] * Quits: tantek_ (n=tantek@208-106-21-119.dsl.static.sonic.net) (Read error: 110 (Connection timed out))
  35. # [06:39] * Joins: tantek_ (n=tantek@208-106-21-119.dsl.static.sonic.net)
  36. # [06:55] * Quits: tantek (n=tantek@208-106-21-119.dsl.static.sonic.net) (Read error: 110 (Connection timed out))
  37. # [07:02] * Joins: tantek (n=tantek@208-106-21-119.dsl.static.sonic.net)
  38. # [07:07] * Quits: tantek_ (n=tantek@208-106-21-119.dsl.static.sonic.net) (Read error: 110 (Connection timed out))
  39. # [07:11] * Joins: tantek_ (n=tantek@208-106-21-119.dsl.static.sonic.net)
  40. # [07:16] <Hixie> zcorpan_: can't be an element, access control has to be done before you create the root element
  41. # [07:18] <othermaciej> you could use a pre-parser, but that's lame
  42. # [07:18] <othermaciej> that reminds me, I owe a review of access-control
  43. # [07:26] * Quits: tantek (n=tantek@208-106-21-119.dsl.static.sonic.net) (Read error: 110 (Connection timed out))
  44. # [07:35] <zcorpan_> ok
  45. # [07:36] * Quits: h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com)
  46. # [07:48] * Quits: tantek_ (n=tantek@208-106-21-119.dsl.static.sonic.net) (Connection timed out)
  47. # [07:50] * Quits: santek (n=st@ut-w-7bd6.mxs.adsl.euronet.nl)
  48. # [07:51] * Joins: tantek (n=tantek@208-106-21-119.dsl.static.sonic.net)
  49. # [07:51] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  50. # [08:01] * Joins: tantek_ (n=tantek@208-106-21-119.dsl.static.sonic.net)
  51. # [08:19] * Quits: tantek (n=tantek@208-106-21-119.dsl.static.sonic.net) (Read error: 110 (Connection timed out))
  52. # [08:37] * Joins: tantek (n=tantek@208-106-21-119.dsl.static.sonic.net)
  53. # [08:50] * Quits: tantek_ (n=tantek@208-106-21-119.dsl.static.sonic.net) (Connection timed out)
  54. # [09:03] * Joins: tantek_ (n=tantek@208-106-21-119.dsl.static.sonic.net)
  55. # [09:16] <zcorpan_> http://www.brucelawson.co.uk/index.php/2007/wcag-2-released/
  56. # [09:18] * Quits: tantek (n=tantek@208-106-21-119.dsl.static.sonic.net) (Read error: 110 (Connection timed out))
  57. # [09:18] * Joins: tantek (n=tantek@208-106-21-119.dsl.static.sonic.net)
  58. # [09:21] <Lachy> that links to http://juicystudio.com/article/wcag2surpriserelease.php ...
  59. # [09:21] <Lachy> which links to http://accessify.com/news/2007/04/wcag-20-finally-here/ ...
  60. # [09:21] <Lachy> and then to ... http://boxofchocolates.ca/archives/2007/04/01/wcag2-a-done-deal ...
  61. # [09:21] <othermaciej> looks like they coordinated
  62. # [09:21] <Lachy> http://www.einfach-fuer-alle.de/blog/eintraege.php?id=2044_0_1_0 and finally back to Bruce Lawson's
  63. # [09:22] <zcorpan_> fishy eh
  64. # [09:22] <Lachy> it's an april fools joke
  65. # [09:22] <zcorpan_> yup
  66. # [09:22] * Quits: tantek_ (n=tantek@208-106-21-119.dsl.static.sonic.net) (Read error: 110 (Connection timed out))
  67. # [09:22] <zcorpan_> othermaciej has another :)
  68. # [09:23] <Lachy> I got suspicious of that when I noticed that bruce didn't actually link to the new spec
  69. # [09:26] <othermaciej> who, me?
  70. # [09:26] * othermaciej looks innocent
  71. # [09:27] <zcorpan_> hehe
  72. # [09:27] * zcorpan_ looks forward to safari 3 using trident
  73. # [09:29] <Lachy> excellent! Now we just need Opera and Mozilla to drop their engines and adopt trident to, and we'll have 4 fully interoperable browsers!
  74. # [09:29] <othermaciej> apparently mozilla is adopting WebKit: http://burntelectrons.org/index.php?itemid=219
  75. # [09:32] <Lachy> so when will apple begin shipping vista on all new macs?
  76. # [09:33] <zcorpan_> 1 april 2008
  77. # [09:33] <othermaciej> I cannot comment on future product releases
  78. # [09:33] * hsivonen goes find the latest RFC
  79. # [09:37] <hsivonen> doesn't IETF have an April 1 RFC this year at all?
  80. # [09:38] <othermaciej> maybe they have not posted it yet
  81. # [09:41] <Lachy> http://en.wikipedia.org/wiki/April_1st_RFC - they didn't post one last year either
  82. # [09:42] <othermaciej> maybe they decided it wasn't funny any more
  83. # [09:44] <othermaciej> haha, UTF-9
  84. # [09:44] <Lachy> we should post something on whatwg blog. hmm. any ideas?
  85. # [09:45] <othermaciej> adopting XHTML2 might be too obvious
  86. # [09:45] <Lachy> that's what I thought
  87. # [09:45] <othermaciej> how about a new RDF serialization of HTML5?
  88. # [09:45] <othermaciej> probably also too obvious
  89. # [09:45] <Lachy> adopting the role attribute?
  90. # [09:46] <othermaciej> that might not be obvious enough :-)
  91. # [09:47] <hsivonen> a few years back Jukka Korpela wrote about a new version of HTML on April 1st, but, in reality, XSL-FO was pretty much like his joke...
  92. # [09:48] <Lachy> yeah, XHTML 3.0!
  93. # [09:48] <hsivonen> http://www.cs.tut.fi/~jkorpela/html/xhtml3.html
  94. # [09:50] * Parts: zcorpan_ (n=zcorpan@esk-ba-1-nomad.net.mdh.se)
  95. # [09:50] <hsivonen> an N3 serialization for HTML5 would take the RDF idea a step further
  96. # [09:52] <hsivonen> (in general, I'm not a big fan of April Fools jokes polluting the information space)
  97. # [09:56] * Joins: ROBOd (n=robod@86.34.246.154)
  98. # [09:58] * othermaciej is now known as mjshtml
  99. # [10:00] <Hixie> if someone posts an april 1st blog entry, they better have an april 2nd blog entry lined up
  100. # [10:01] <Lachy> why? To explain that the first was a joke?
  101. # [10:02] <Hixie> no, to not confuse people when april fools is over
  102. # [10:02] <Lachy> ok
  103. # [10:02] <Hixie> :-)
  104. # [10:34] <ROBOd> will someone post an April fools joke? :)
  105. # [10:34] <Lachy> if someone comes up with a good idea for one
  106. # [10:35] <mjshtml> Hixie to be replaced as HTML5 editor by Chris Wilson
  107. # [10:35] <Lachy> LOL!
  108. # [10:35] <ROBOd> "The WHATWG will disolve given that Chris Wilson has taken over doing a great job" (scary joke)
  109. # [10:36] <Lachy> who wants to write it?
  110. # [10:36] <mjshtml> or Steven Pemberton, take your pick
  111. # [10:36] <mjshtml> maybe that can be the 4/2 clarification
  112. # [10:37] <Lachy> nah, Steve's doing a great job with XHTML2. Chris is more believable since he's actually joining the HTMLWG
  113. # [10:38] <mjshtml> "doing a great job with XHTML2"
  114. # [10:38] <mjshtml> parse error
  115. # [10:39] <hsivonen> people may take a Chris Wilson joke too seriously
  116. # [10:39] <hsivonen> RDF fun is safer
  117. # [10:40] <mjshtml> Chris Wilson may take a Chrisl Wilson joke too seriously
  118. # [10:40] <Lachy> I don't know RDF well enough to write anything about it
  119. # [10:40] <ROBOd> "Due to many complaints we've decided rewrite the entire HTML 5 specification, from scratch"
  120. # [10:40] <mjshtml> I think it would be funny if written right, you just have to get more outrageous as you go along
  121. # [10:40] <mjshtml> start believable and work your way up
  122. # [10:41] <ROBOd> mjshtml: exactly
  123. # [10:44] <Lachy> what about a reason for Hixie no longer doing it? Lack of time? motivation? support? illness? something else?
  124. # [10:44] <ROBOd> another joke .. but this might be also taken too seriously and it's quite subtle: start from this email http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-August/002069.html
  125. # [10:46] <hsivonen> I think writing the spec from scratch with outrageous technical details is the best one so far (I'd avoid stuff that might start serious PR problem rumors. like Hixie getting sick or legal stuff)
  126. # [10:46] <ROBOd> yes
  127. # [10:46] <Lachy> how about adopting XForms Transitional?
  128. # [10:47] <ROBOd> Lachy: just looked yesterday at XForms Transitional... uhm... that's soo "very" Web Forms2 (IIANM)
  129. # [10:47] <ROBOd> (besides being still a work in progress...)
  130. # [10:48] <hsivonen> XForms Transitional, XSL-FO, RDF, XHTML 2.0, W3C XML Schema, SOAP, ...
  131. # [10:48] <mjshtml> forget XForms Transitional, how about straight-up XForms?
  132. # [10:48] <Lachy> XForms transitional does seem to be an effort to rewrite WF2 from scratch
  133. # [10:48] <ROBOd> Lachy: what's the use?
  134. # [10:48] <mjshtml> the <style> element will no longer contain CSS, instead it will include an inline XSLT stylesheet
  135. # [10:48] <Lachy> the use of what?
  136. # [10:49] <mjshtml> the global href attribute from XHTML2 will be replaced by a global xlink:href attribtue from XLink
  137. # [10:49] <ROBOd> Lachy: of rewriting from scratch WF2?
  138. # [10:49] <Lachy> I don't know, ask DanC
  139. # [10:49] <mjshtml> the global src attribute will also be replaced by a global xlink:href attribute from XLink
  140. # [10:49] <ROBOd> Lachy: he's not around :)
  141. # [10:49] <mjshtml> it writes itself
  142. # [10:49] <mjshtml> actually, DaveR would be the one to ask
  143. # [10:50] <Lachy> oh, yes, sorry
  144. # [10:50] <ROBOd> mjshtml: yes, Dave Ragget?
  145. # [10:50] <mjshtml> yes
  146. # [10:50] * mjshtml is now known as othermaciej
  147. # [10:50] <othermaciej> he invented it
  148. # [10:50] <hsivonen> HTML5 will be rewritten from scratch to separate semantics (RDF) from presentation (XSL-FO) and behavior (the XML script thing from XForms). the normative schema will be in XSD and the for enterprise-readiness, the transport will be SOAP with WS-Security for making it bullet-proof
  149. # [10:50] * Joins: tantek_ (n=tantek@208-106-21-119.dsl.static.sonic.net)
  150. # [10:52] <ROBOd> hsivonen: for it to be a good joke, you must reference some Microsoft proprietary format :)
  151. # [10:52] <hsivonen> ROBOd: it can be deployed today thanks to WPF/E?
  152. # [10:52] <othermaciej> hah
  153. # [10:53] <ROBOd> "HTML 5 will be based off the new ISO standard by Microsoft: Office Open XML"
  154. # [10:53] <othermaciej> haha
  155. # [10:53] <othermaciej> the problem with redesigning HTML in a bad way is it's hard to fit in all the possible bad technologies
  156. # [10:53] <ROBOd> 90% of the users will have support for viewing the documents
  157. # [10:54] <ROBOd> othermaciej: exactly, so pick one really bad. OOXML :)
  158. # [10:56] <ROBOd> advantages must also be stated clearly: "1. market penetration (even your secretary knows how to view and edit such OOXML documents). 2. we firmly believe that this ISO standard is written for better interoperability between implementations, making life easier for developers and users."
  159. # [10:56] * Quits: tantek (n=tantek@208-106-21-119.dsl.static.sonic.net) (Connection timed out)
  160. # [10:56] <ROBOd> and 3. we do not really want to reinvent the wheel :)
  161. # [10:57] <othermaciej> hah
  162. # [10:58] <hsivonen> ROBOd: you can have the best of both worlds by defining an XSLT mapping between OOXML and RDF/XSL-FO
  163. # [10:58] <ROBOd> hsivonen: hahahaha, exactly that's what i was writing!
  164. # [10:58] <ROBOd> lol
  165. # [10:59] <Lachy> ROBOd, are you writing the post?
  166. # [10:59] <ROBOd> the greatest advantage is you can use only one can XSLT to convert your HTML4 (error on purpose) to OOXML HTML5, and vice-versa
  167. # [10:59] <othermaciej> maybe it should use a combination of GRDDL and XSLT
  168. # [10:59] <othermaciej> GRDDL to generate RDF, and XSLT to generate XSL-FO
  169. # [11:00] * Joins: virtuelv (n=arve@ti132110a341-1657.bb.online.no)
  170. # [11:00] <ROBOd> Lachy: yeah :). how can I do this?
  171. # [11:00] <ROBOd> if you want i can write it
  172. # [11:00] <ROBOd> (i am not *writing* it as we speak, of course)
  173. # [11:00] <Lachy> go for it
  174. # [11:01] <ROBOd> Lachy: do i have to signup somewhere and login? or i shall write the HTML document and send it to you via email?
  175. # [11:02] <Lachy> just write it, put a draft somewhere so we can review it, then I can publish the final version for you
  176. # [11:02] <ROBOd> Lachy: ok, will do
  177. # [11:02] <Lachy> or you can just register on blog.whatwg.org and do it yourself
  178. # [11:02] <ROBOd> i suppose it doesn't have to be long :P (the blog post)
  179. # [11:03] <Lachy> no, just 2 or 3 paragrahs should be sufficient
  180. # [11:03] * Joins: hendry (n=hendry@91.84.53.136)
  181. # [11:04] <ROBOd> yes
  182. # [11:05] <Lachy> is anyone able to understand this? http://www.w3.org/mid/711a73df0704010055i13fe8c38vc710cb1016f6e344@mail.gmail.com
  183. # [11:05] <hsivonen> the serialization could be OOXML but the *architectural model* could be RDF/XSL-FO/XForms-script-thing
  184. # [11:06] <othermaciej> hah
  185. # [11:06] <othermaciej> make sure to work in the word "backplane"
  186. # [11:08] <hsivonen> Lachy: assuming that Dave P isn't joking today, I am rather surprised by his position
  187. # [11:12] <Lachy> I just don't understand why downstream processijng of xml requires validation, or what versioning has to do with that
  188. # [11:13] <hsivonen> Lachy: it requires validation if your processing code barfs on invalid stuff
  189. # [11:14] <hsivonen> Lachy: what I don't understand is how versioning saves you in that case
  190. # [11:14] <hsivonen> Lachy: basically, validating first allows for less robust Java/Python/whatever code
  191. # [11:14] <Lachy> I also don't understand what that has to do with HTML and CSS, which the thread is about
  192. # [11:14] <hsivonen> Lachy: since the code can assume the doc met the constraints already
  193. # [11:15] <hsivonen> Lachy: Dave P is an XML guy, so perhaps he isn't thinking about a browser use case but a semi-private system use case
  194. # [11:16] * Joins: welly (n=welly@62-31-60-148.cable.ubr12.azte.blueyonder.co.uk)
  195. # [11:17] <ROBOd> done
  196. # [11:17] <ROBOd> the document is available locally... i don't like pasting links on the channel (it's logged)
  197. # [11:17] <ROBOd> Lachy: can I PM you?
  198. # [11:17] <Lachy> sure
  199. # [11:17] <ROBOd> thanks
  200. # [11:18] <hsivonen> Lachy: can I see it as a draft in WP?
  201. # [11:18] * Quits: welly (n=welly@62-31-60-148.cable.ubr12.azte.blueyonder.co.uk) (Client Quit)
  202. # [11:18] <Lachy> yeah
  203. # [11:19] <ROBOd> erm, there are some typos and grammar errors :)
  204. # [11:21] <hsivonen> whoa: http://www.w3.org/TR/backplane/
  205. # [11:21] <Lachy> Should we call it HTML6 intead?
  206. # [11:22] <othermaciej> did you mention the backplane?
  207. # [11:22] <othermaciej> it's essential for maximum ludicrousness value
  208. # [11:22] <hsivonen> enterprise-strength backplane
  209. # [11:22] <Lachy> people might find it hard to believe that we're dropping everything we've already done, it would be more believable if they think it's the future replacement
  210. # [11:22] <ROBOd> othermaciej: change the article, if you have access
  211. # [11:22] <othermaciej> people will believe anything
  212. # [11:23] <othermaciej> I don't
  213. # [11:23] <ROBOd> Lachy: good point
  214. # [11:24] <hsivonen> Lachy: dropping everything is good
  215. # [11:24] <ROBOd> name it HTML 6 ... "we are now planning for the future HTML 6, since ... HTML 5 is already being worked on by the W3C"
  216. # [11:24] <hsivonen> Lachy: otherwise HTML5 needs to become HTML6 Transitional
  217. # [11:24] <Lachy> hsivonen, that would be DaveR's job
  218. # [11:24] <ROBOd> :)
  219. # [11:25] <hsivonen> the good thing with global warming is that ocean boiling requires less additional energy
  220. # [11:26] <ROBOd> Lachy: let me know when the joke is posted :)
  221. # [11:27] <Lachy> I'm just making a few modifications to call it HTML6 and change the first paragraph accordingly
  222. # [11:27] * hsivonen hopes the X people won't get too bitterly offended
  223. # [11:27] <Lachy> othermaciej, I don't know what to say about the backplane
  224. # [11:27] * Joins: annevk (n=annevk@86.90.70.28)
  225. # [11:27] <Lachy> hi annevk
  226. # [11:27] <ROBOd> Lachy: just say something about the b*l*ackplane
  227. # [11:27] <ROBOd> :)
  228. # [11:27] <hsivonen> Lachy: I can try to work the backplane in
  229. # [11:28] <Lachy> ok, I'll save the draft
  230. # [11:29] * hsivonen looks
  231. # [11:29] <annevk> maybe we should have something about the UN negotiating a truce between the W3C and WHATWG?
  232. # [11:29] <othermaciej> Lachy: what you say doesn't have to mean anything
  233. # [11:29] <othermaciej> that's the key
  234. # [11:29] <othermaciej> "backplane" means whatever you want it to mean
  235. # [11:29] <annevk> othermaciej, btw, review the dev.w3.org version of access-control, not the thing published on /tr/
  236. # [11:30] <hsivonen> ok if I work in a bit more X stuff along the lines I said earlier?
  237. # [11:30] <ROBOd> Lachy: in the advantages say ...
  238. # [11:30] <annevk> "backplane" is the XForms data model + more of where that came from
  239. # [11:30] * annevk isn't sure what the XForms data model is, exactly
  240. # [11:31] <ROBOd> "Having XML as the backplane, developers will see the immediate benefit of using their existing XML parsers and serializers"
  241. # [11:31] <annevk> you want "XML toolchain" I think
  242. # [11:32] <ROBOd> annevk: xforms doesn't fit into the OOXML archtecture model
  243. # [11:32] <annevk> yeah, well, what does?
  244. # [11:32] <Lachy> annevk, HTML6 does, apparently :-)
  245. # [11:32] <ROBOd> annevk: yeah, whatever :) ... the XML toolchain, saw fit to use parser and serializer
  246. # [11:33] <annevk> maybe we should also state something that's not a joke
  247. # [11:33] <annevk> after HTML5 we'll focus on SVG5
  248. # [11:36] <ROBOd> "We also sent a proposal to the CSS WG: we would like CSS 4 to marry the syntax of XSLT and the power of CSS" (lol)
  249. # [11:36] <ROBOd> css3-syntax-sugar :)
  250. # [11:37] <ROBOd> (which is available as a css 3 module; future revisions becoming css 4)
  251. # [11:38] <hsivonen> still editing
  252. # [11:39] <ROBOd> :)
  253. # [11:41] <annevk> you mean the syntax of XSL-FO
  254. # [11:41] <annevk> XSLT is sort of orthogonal to CSS at this point
  255. # [11:42] <ROBOd> annevk: hence... the idea :)
  256. # [11:43] <ROBOd> annevk: i also stated that XSLT can be used to transform HTML4 to HTML 6 OOXML :)
  257. # [11:43] <ROBOd> a simple XSLT document, that is
  258. # [11:43] <hsivonen> ok. I worked in some more buzzwords
  259. # [11:44] <ROBOd> but keep it believable :) at least for newbies :)
  260. # [11:44] <hsivonen> minor edit still
  261. # [11:44] <hsivonen> Lachy: did you intend to publish take two tomorrow?
  262. # [11:45] <hsivonen> still a bit more editing
  263. # [11:45] * Joins: tantek (n=tantek@208-106-21-119.dsl.static.sonic.net)
  264. # [11:46] <Lachy> oh, oops, I meant to take that out of the draft. ROBOd added that for tomorrows post, but I don't think we need it.
  265. # [11:46] <hsivonen> done
  266. # [11:46] * Joins: welly (n=welly@62-31-60-148.cable.ubr12.azte.blueyonder.co.uk)
  267. # [11:46] <Lachy> we could just publish something on a more serious topic
  268. # [11:46] <Lachy> like <video>
  269. # [11:47] * Quits: tantek_ (n=tantek@208-106-21-119.dsl.static.sonic.net) (Connection timed out)
  270. # [11:47] <hsivonen> Lachy: do you approve of my edits? are they offensive?
  271. # [11:47] <annevk> seen http://www.google.com/tisp/ already?
  272. # [11:47] <ROBOd> annevk: yeah, kinda ... weak
  273. # [11:47] * Lachy looks
  274. # [11:48] <ROBOd> i liked http://www.google.com/tisp/notfound.html
  275. # [11:50] <annevk> heh http://groups.google.com/group/google-tisp/
  276. # [11:51] <hsivonen> Lachy: FWIW, I think what I wrote is pretty tame compared to real suggestions. the potentially offensive part is framing stuff that reads like real suggestions as a joke
  277. # [11:53] <Lachy> it's funny. Most people will find it believable because they have no idea what on earth you're talking about :-)
  278. # [11:54] <annevk> do we have multiple posts?
  279. # [11:54] <Lachy> I took out the take two section aswell
  280. # [11:54] <Lachy> no, just the one on blog.whatwg.org
  281. # [11:55] <hsivonen> Lachy: are you editing still? I suggest chaging "integration with SOAP-based" to "binding with..."
  282. # [11:55] * othermaciej looks forward to seeing it
  283. # [11:55] * annevk too
  284. # [11:55] <Lachy> hsivonen, fixed
  285. # [11:56] <hsivonen> Lachy: thanks
  286. # [11:56] <annevk> "Founded in 1998 by Stanford Ph.D. wannabes Larry Page and Sergey Brin,"
  287. # [11:59] <Lachy> I think it's ready to publish, unless you have any last minute changes
  288. # [11:59] <Lachy> I changed the title to Plans for HTML6
  289. # [11:59] <hsivonen> Lachy: the second to last paragraph isn't funny enough, but I don't have good fixes
  290. # [12:01] <hsivonen> afk.
  291. # [12:01] <othermaciej> if someone sends by privmsg I can make suggestions
  292. # [12:01] <othermaciej> or y'all can just post it, I'm sure it's amusing enough
  293. # [12:01] <ROBOd> othermaciej: agreed
  294. # [12:01] <Lachy> I'll put it online temporarily for those of you without blog accts...
  295. # [12:02] <ROBOd> registered
  296. # [12:03] <Lachy> you probably won't be able to see it cause your not its editor or an admin
  297. # [12:03] <annevk> you can also just publish it and make changes later...
  298. # [12:04] <ROBOd> ah, yes
  299. # [12:05] <othermaciej> the only change I'd make is to remove "The above being said, "
  300. # [12:06] <othermaciej> it's pretty amusing
  301. # [12:06] <ROBOd> it's pretty good
  302. # [12:06] <Lachy> othermaciej, done
  303. # [12:06] <ROBOd> good additions
  304. # [12:14] <ROBOd> still editing?
  305. # [12:14] <hsivonen> Using a fairly simplistic XSLT should probably be "Using a fairly simplistic XSLT style sheet"
  306. # [12:17] <hsivonen> let's ship it!
  307. # [12:17] <Lachy> hsivonen, done.
  308. # [12:18] <hsivonen> Lachy: thanks
  309. # [12:19] <othermaciej> is it there yet?
  310. # [12:21] <Lachy> just making a few minor changes that annevk PM'd me
  311. # [12:22] <Lachy> http://blog.whatwg.org/html6-plan
  312. # [12:22] <annevk> I think we should have something like "reveal our behind-closed-doors-decided plans ..."
  313. # [12:22] <hsivonen> thanks to everyone who participated
  314. # [12:24] <ROBOd> :)
  315. # [12:24] * annevk submits a comment
  316. # [12:24] <othermaciej> lol
  317. # [12:24] <ROBOd> annevk: already did
  318. # [12:25] <ROBOd> seriously now... any ETA?
  319. # [12:25] <ROBOd> lol
  320. # [12:25] <Lachy> annevk, lol!
  321. # [12:26] <ROBOd> i think the use of WHATTF name adds to the point :)
  322. # [12:26] <hsivonen> http://whattf.org/
  323. # [12:26] <Lachy> oh crap, we got the expansion wrong for WHATF
  324. # [12:26] <Lachy> *WHATTF
  325. # [12:26] <ROBOd> hsivonen: precisely
  326. # [12:29] * annevk changes topic to 'WHATWG (HTML6) -- http://www.whattf.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks!'
  327. # [12:29] * Quits: tantek (n=tantek@208-106-21-119.dsl.static.sonic.net)
  328. # [12:29] * annevk changes topic to 'WHATTF (HTML6) -- http://www.whattf.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks!'
  329. # [12:29] <ROBOd> :)
  330. # [12:41] * Quits: welly (n=welly@62-31-60-148.cable.ubr12.azte.blueyonder.co.uk)
  331. # [12:54] <ROBOd> we have the HTML 6 plans blog post, the HTML 6 topic, .... we only need a HTML 6 thread on the mailing list
  332. # [12:55] <hsivonen> I think the blog comment work better today than email
  333. # [12:56] <ROBOd> someone digg&slashdot the article
  334. # [12:59] <ROBOd> i have to go now, i'll be back later
  335. # [13:00] * Quits: ROBOd (n=robod@86.34.246.154) (Remote closed the connection)
  336. # [13:05] <Lachy> it would be funny if it made slashdot and people thought it was sersious :-)
  337. # [13:07] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  338. # [13:08] * Joins: Philip` (n=excors@zaynar.demon.co.uk)
  339. # [13:27] * Joins: bzed (n=bzed@dslb-084-059-107-207.pools.arcor-ip.net)
  340. # [13:32] * othermaciej is now known as om_sleep
  341. # [13:51] * Joins: met_ (n=Hassman@r5bx220.net.upc.cz)
  342. # [13:59] <Dashiva> "A++++ would implement again"
  343. # [13:59] <Lachy> what?
  344. # [14:00] <Dashiva> I was just thinking of a comment for the HTML6 post
  345. # [14:04] * met_ just read about HTML 6
  346. # [14:08] <hsivonen> hmm. I have 21 slides for a 15-minute presentation about HTML5 conformance checking
  347. # [14:09] <hsivonen> have to practice some more to squeeze it a bit
  348. # [14:09] <Lachy> that should be enough
  349. # [14:09] <Lachy> how long are you spending on each slide?
  350. # [14:09] <hsivonen> slightly less than a minute on average. my last practice run was 18 minutes
  351. # [14:10] <annevk> wow, that's a lot of slides
  352. # [14:10] <hsivonen> yes :-(
  353. # [14:10] * annevk had eight / nine for a twenty minute presentation
  354. # [14:10] <hsivonen> but these are Keynote slides not PowerPoint slides
  355. # [14:11] <annevk> what does that mean? one word per slide?
  356. # [14:11] <hsivonen> annevk: something like that :-)
  357. # [14:11] <hsivonen> I have 5 slides up front about what HTML5 and WHATWG are
  358. # [14:11] <hsivonen> I think I should try to squeeze that part
  359. # [14:12] <Lachy> can we see the slides?
  360. # [14:12] * jgraham has managed both 40 minute talks on <30 slides and 17 minute talks on 25 slides...
  361. # [14:12] <Lachy> oh, never mind, I don't have keynote anyway
  362. # [14:13] <hsivonen> Lachy: http://hsivonen.iki.fi/thesis/dippaesitelma.pdf
  363. # [14:13] <Lachy> hmm. Apparently a trial version of keynote came with my mac. Nice!
  364. # [14:15] <jgraham> hsivonen: Do you know the projector you're using? We have one with an odd issue with white-on-black (move your head and you see rainbows)
  365. # [14:15] <hsivonen> jgraham: I don't
  366. # [14:15] <hsivonen> jgraham: I could make an inverted backup
  367. # [14:16] <jgraham> I've only ever seen the problem with this one projector but it is quite annoying...
  368. # [14:18] <hsivonen> perhaps I should get rid of references to the WHATWG and not explain the context on that level
  369. # [14:21] <hsivonen> pruned to 18 slides
  370. # [14:21] <Lachy> which ones did you take out?
  371. # [14:21] <hsivonen> the ones about the WHATWG and new and old features
  372. # [14:22] <hsivonen> not that relevant to the implementation of conformance checking
  373. # [14:22] <Lachy> yeah, I was going to suggest those because they're not relevant
  374. # [14:43] <hsivonen> when I had the presentation about Gecko bug 18333, I made sure that I don't go overtime and then I was too quick...
  375. # [14:47] * bzed is now known as bzed|sk8
  376. # [14:55] <hsivonen> I wonder if there a drop-in color invert filter for Quartz...
  377. # [15:23] * bzed|sk8 is now known as bzed
  378. # [15:31] * moeffju[ZzZz] is now known as moeffju
  379. # [15:41] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  380. # [16:22] * Quits: Philip` (n=excors@zaynar.demon.co.uk) (Read error: 110 (Connection timed out))
  381. # [16:24] * Joins: Lachlan (n=Lachlan@210-84-40-143.dyn.iinet.net.au)
  382. # [16:24] * Quits: Lachy (n=Lachlan@210-84-40-143.dyn.iinet.net.au) ("Leaving")
  383. # [16:24] * Lachlan is now known as Lachy
  384. # [16:30] * Quits: Lachy (n=Lachlan@210-84-40-143.dyn.iinet.net.au) ("leaving")
  385. # [16:30] * Joins: Lachy (n=Lachlan@210-84-40-143.dyn.iinet.net.au)
  386. # [16:35] * Joins: Lachlan (n=Lachlan@210-84-40-143.dyn.iinet.net.au)
  387. # [16:38] * Joins: karlUshi (n=karl@124-144-94-185.rev.home.ne.jp)
  388. # [16:42] * Quits: ravenn (n=ravenn@203-214-133-148.perm.iinet.net.au)
  389. # [16:42] * Quits: Lachlan (n=Lachlan@210-84-40-143.dyn.iinet.net.au) ("leaving")
  390. # [17:04] * Joins: Philip` (n=excors@zaynar.demon.co.uk)
  391. # [17:41] * Joins: santek (n=st@ut-w-7bd6.mxs.adsl.euronet.nl)
  392. # [17:43] * Joins: ROBOd (n=robod@86.34.246.154)
  393. # [17:46] * Joins: h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com)
  394. # [17:46] * Quits: annevk (n=annevk@86.90.70.28) (Read error: 110 (Connection timed out))
  395. # [17:47] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  396. # [17:59] * Quits: santek (n=st@ut-w-7bd6.mxs.adsl.euronet.nl) (adams.freenode.net irc.freenode.net)
  397. # [18:00] * Joins: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  398. # [18:00] * weinig is now known as weinig|away
  399. # [18:00] * Joins: santek (n=st@ut-w-7bd6.mxs.adsl.euronet.nl)
  400. # [18:19] * Joins: santek_ (n=st@ut-w-7bd6.mxs.adsl.euronet.nl)
  401. # [18:28] * Quits: santek (n=st@ut-w-7bd6.mxs.adsl.euronet.nl) (Read error: 110 (Connection timed out))
  402. # [18:41] * Quits: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net) (Remote closed the connection)
  403. # [18:41] * Joins: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  404. # [19:05] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  405. # [19:18] * Quits: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  406. # [19:19] * Quits: dolphinling (n=chatzill@rbpool4-37.shoreham.net) ("Help, help, I'm being repressed!")
  407. # [19:21] * Joins: annevk (n=annevk@5352CE6F.cable.casema.nl)
  408. # [20:13] * Quits: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com) (Read error: 110 (Connection timed out))
  409. # [20:28] <Hixie> i think i know why i'm uncomfortable with the proposed ready states
  410. # [20:28] <Hixie> they don't all apply to audio
  411. # [20:33] * Quits: h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com)
  412. # [20:33] <Hixie> also, i don't like the idea of a readyState-like API not only incrementing
  413. # [20:45] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  414. # [20:51] <virtuelv> Hixie: huh? care to elaborate (about readyStates incrementing)
  415. # [20:51] <Hixie> for <video>
  416. # [20:51] <Hixie> http://webkit.org/specs/HTML_Timed_Media_Elements.html#mediastatus
  417. # [20:52] <virtuelv> I got that part, but why are you uncomfortable with a non-incremental value for readyState?
  418. # [20:56] <virtuelv> (if anything, I'm a bit uncomfortable not being able to predict when the buffer will be empty beforehand
  419. # [20:57] <Hixie> the proposal from apple has the state going 0..2..3..4..2..3..2..3..4..5..2..3..4..2..6
  420. # [20:57] <Hixie> instead of 0..1..2..3..4..55
  421. # [20:58] <Hixie> http://www.whatwg.org/specs/web-apps/current-work/#media is what i'm thinking of using
  422. # [20:58] <Hixie> (not yet specced out)
  423. # [20:58] <Hixie> (just in the idl)
  424. # [21:01] <annevk> loaded is 10 because you expect many more states at some point?
  425. # [21:01] <Hixie> actually loaded was 10 in order to have the buffered and networking states in sync
  426. # [21:01] <Hixie> but screw that
  427. # [21:02] <Hixie> we don't need loaded and partial under buffering
  428. # [21:04] <annevk> so which states don't make sense for audio?
  429. # [21:05] <Hixie> pausable
  430. # [21:05] <Hixie> but i think we'll deal with it
  431. # [21:06] <annevk> also, how about replacing .seek() with a read/write .position
  432. # [21:07] <virtuelv> again, what worries me a bit is that there's insufficient information in both suggestions to determine when to start playing back and be guaranteed a skip-free playback
  433. # [21:07] <annevk> that will also allow you to do the theoretical .advance() easily
  434. # [21:07] <annevk> virtuelv, i think ENDABLE is for that
  435. # [21:08] <virtuelv> annevk: that is not neccesarily always what you want
  436. # [21:08] <virtuelv> the latency for that might be too long, depending on the length of the media
  437. # [21:09] <Hixie> yes seek() is going away
  438. # [21:09] <Hixie> one thing at a time
  439. # [21:11] <Hixie> virtuelv: the state will become ENDABLE when the UA believes that at the current buffering rate, you'll be able to reach the end just as the end is downloaded.
  440. # [21:11] <Hixie> is that what you meant?
  441. # [21:17] <virtuelv> it is what I meant, but you can't always guarantee that endable is a definite state
  442. # [21:18] <Hixie> could you elaborate?
  443. # [21:18] <virtuelv> someone might, for instance, start a download at the same time, at which point the movie will no longer be endable
  444. # [21:18] <Hixie> yup, then the state will no longer be that
  445. # [21:20] <Hixie> what information would you want instead?
  446. # [21:22] <virtuelv> usually, someone streaming media will know the size and duration of the media, and knowing exactly how much is in the browser's buffer/cache and the current download rate would make more sense to me
  447. # [21:23] <Hixie> that information is already available in the api
  448. # [21:37] * Joins: dbaron (n=dbaron@c-71-198-189-81.hsd1.ca.comcast.net)
  449. # [21:44] * om_sleep is now known as othermaicje
  450. # [21:44] * othermaicje is now known as othermaciej
  451. # [21:48] * Quits: annevk (n=annevk@5352CE6F.cable.casema.nl) (Read error: 110 (Connection timed out))
  452. # [21:50] <othermaciej> Hixie: what you came up with seems pretty complicated
  453. # [21:50] <othermaciej> Hixie: three separate state enums?
  454. # [21:51] <othermaciej> plus a bunch of booleans
  455. # [21:51] <othermaciej> I think the only one of Apple's states that might not apply to pure audio is PRESENTABLE
  456. # [21:52] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  457. # [21:57] <Hixie> i removed a bunch of hte booleans that were there before actually
  458. # [21:58] <Hixie> the only real difference between this and the apple proposal is the splitting of the 'state' into two, one for network state, and one for the ready state
  459. # [21:58] <Hixie> which are orthogonal anyway
  460. # [21:58] <Hixie> since 'ready' state can be affected by things like seeking even when the whole file is downloaded
  461. # [21:59] <othermaciej> that and you made playback state a quad-state instead of a boolean
  462. # [21:59] <Hixie> well that was there before
  463. # [21:59] <Hixie> you need it to be quadstate, otherwise you don't know when to show the "i'm _trying_ to play!" spinner
  464. # [22:00] <othermaciej> you could just say paused reflects only the user-chosen playback state
  465. # [22:01] <othermaciej> I'm not sure there's a need to reflect EMPTY vs. PAUSED (in purely playback terms, as opposed to the EMPTY state in the two other concepts of state) or PLAYING vs. WAITING
  466. # [22:02] <othermaciej> wouldn't the state of the controls be exactly the same in case of the latter two?
  467. # [22:03] <Hixie> the controls would be, but in waiting you'd have a spinner
  468. # [22:03] <Hixie> this is something that the quicktime and frontrow renderers do really badly actually
  469. # [22:03] <othermaciej> you would?
  470. # [22:03] <Hixie> they just freeze when they're seeking or buffering, with no indication to the user that they're working and not locked up
  471. # [22:04] <Hixie> obviously there's no requirement that the author provide such a ui
  472. # [22:04] <Hixie> but it should at least be possible
  473. # [22:04] <othermaciej> as does YouTube
  474. # [22:04] <othermaciej> and Google Video
  475. # [22:04] <othermaciej> does anyone's actual UI show a spinner in such a case?
  476. # [22:05] <Hixie> those two at least shows the buffered bar, so there's some indication of why it's paused
  477. # [22:05] <othermaciej> yes, so does QuickTime
  478. # [22:06] <othermaciej> that's kind of the de facto standard for such things
  479. # [22:06] <Hixie> well for some reason i am much more often confused as to whether quicktime is locked up or not
  480. # [22:06] <Hixie> in any case, i don't see the disadvantage of exposing this information. Is it hard to implement or something?
  481. # [22:07] <othermaciej> no, it's just more complicated to use
  482. # [22:07] <othermaciej> since you have extra states that don't relate to anything you'd do in the UI
  483. # [22:07] <Hixie> how about if i make paused = 0 and playing and waiting 1 and 2 respectively
  484. # [22:07] <Hixie> then you can do if (video.playing)
  485. # [22:07] <Hixie> or playbackState or whatever it's called
  486. # [22:09] <othermaciej> the fact that "waiting" is useful only for a UI idea you had that no one actually uses makes me doubt it should be overloaded onto the same variable that tells you playing vs. paused
  487. # [22:09] <Hixie> i suggested having two booleans and you were against that too
  488. # [22:11] <othermaciej> well, Apple's proposal gives you enough info to tell if you are really advancing in time without having a specific state value or bool for it, since it is of marginal value for reflection in the UI
  489. # [22:12] <othermaciej> I'm not sure if your version still does, since I don't know what the states mean or what the allowed transitions are
  490. # [22:12] <othermaciej> but I gotta say that three separate state enums, all of which are primarily useful to tell you what actions are allowed now, triggers my complexity overload alert
  491. # [22:13] <Hixie> well it's a complicated problem
  492. # [22:13] <Hixie> the three states are orthogonal
  493. # [22:14] <Hixie> (regarding the rate thing -- that part of the apple proposal wasn't really clear to me)
  494. # [22:14] <Hixie> (i couldn't work out what values the currentRate would have other than 0 and the playbackRate, at which point it is exactly the same as a boolean)
  495. # [22:14] <Dashiva> As long as a "basic user" can ignore most of the states and still get a sensible interface, the complexity isn't necessarily bad
  496. # [22:14] <othermaciej> Hixie: you could tell even without looking at the rate, since you can see whether your current state is playable, and if you are not paused; only if both are true are you actually advancing
  497. # [22:14] <Hixie> (and i don't see that two booleans, playing and 'playbackRate', which can never be false and true respectvely, is better than a three-state attribute)
  498. # [22:15] <Hixie> "(playable || endable) && (!paused)"
  499. # [22:16] <Hixie> and even that's not true, because in the autoplay case you'll wait for endable, not playable
  500. # [22:16] <othermaciej> video.readyState < PLAYABLE && !video.paused is your WAITING state
  501. # [22:16] <othermaciej> in the autoplay case, you are paused until autoplay starts
  502. # [22:16] <Hixie> so paused _isn't_ the user's state.
  503. # [22:16] <othermaciej> (that's how it should be anyway, since the user should still be able to hit "play" early)
  504. # [22:16] <Hixie> how can the user prevent autoplay then?
  505. # [22:17] <othermaciej> you can't
  506. # [22:17] <Hixie> ...
  507. # [22:17] <othermaciej> you have to hit pause after it autoplays
  508. # [22:17] <othermaciej> unless there is some special control for it
  509. # [22:17] <Hixie> what would the control do?
  510. # [22:17] <othermaciej> that's how things that autoplay work now
  511. # [22:17] <othermaciej> no idea
  512. # [22:17] <othermaciej> remove the "autoplay" attribute?
  513. # [22:18] <Hixie> so autoplay would be implemented as a default action of the transition to endable?
  514. # [22:18] <Hixie> i guess that could work
  515. # [22:18] <othermaciej> I really don't like endable as a name either
  516. # [22:18] <Hixie> (i'm not sure designing the api around current UIs to the exclusion of better UIs is good design, though)
  517. # [22:18] <othermaciej> it implies the author or user could take the action of ending in that state
  518. # [22:18] <Hixie> the names can be sorted out later
  519. # [22:19] <othermaciej> well, some of the names actively confuse me
  520. # [22:19] <othermaciej> I don't know what pausable means
  521. # [22:19] <Hixie> same as your presentable
  522. # [22:19] <othermaciej> I don't know what the distinction between "loading" and "buffering" is (aren't the two words basically synonymous in normal computer use?)
  523. # [22:19] <Hixie> loading = we don't have metadata, buffering = we do have metadata
  524. # [22:20] <Hixie> i'm open to any name changes
  525. # [22:21] <othermaciej> let's set aside the name changes right now and talk about the actual states and transitions first
  526. # [22:21] <gsnedders> does anything apart from Gecko trunk support getElementsByClassName?
  527. # [22:22] <othermaciej> my net connection is too fast because even on the QuickTime trailers site I can't find in-page video that's large enough that it doesn't autoplay promptly
  528. # [22:22] <othermaciej> was gonna give a link to an example of such
  529. # [22:23] <Hixie> oh i've seen that ui often
  530. # [22:23] <Hixie> drives me crazy
  531. # [22:23] <Hixie> i can't go through opening a bunch of videos in tabs and go through and pause them all before they play
  532. # [22:24] <Hixie> because if i hit pause, they play instead.
  533. # [22:24] <Hixie> but i agree that that's ok
  534. # [22:24] <Hixie> we can do autoplay as a default action from the paused state when you transition to 'endable'
  535. # [22:24] <othermaciej> I think that is true of all autoplaying UIs (though I don't have a dialup connection handy to test it for youtube)
  536. # [22:25] <othermaciej> in Safari we don't start plugins in background tabs so they won't play until you switch to the tab anyway
  537. # [22:25] <Hixie> they won't start downloading either
  538. # [22:25] <Hixie> so i have to go to the tab to start the download, then start them, then pause them
  539. # [22:25] <Hixie> it's annoying
  540. # [22:25] <othermaciej> that is true
  541. # [22:25] <Hixie> then when i'm ready i have to rewind and play
  542. # [22:26] <othermaciej> it would be nice to preload videos in tabs w/o them playing
  543. # [22:26] <Hixie> instead of what i'd like to do, which is just, when i'm ready, switch the tab and hit play
  544. # [22:26] <othermaciej> I often want that when I'm gonna ride the train
  545. # [22:26] <Hixie> but <video> will help with this
  546. # [22:26] <othermaciej> it could load but not autoplay
  547. # [22:26] <othermaciej> in a background tab
  548. # [22:26] <Hixie> since we can have user prefs to disable autoplay
  549. # [22:26] <othermaciej> until you switch to the tab
  550. # [22:26] <othermaciej> or user prefs
  551. # [22:26] <Hixie> or that
  552. # [22:26] <othermaciej> but we don't tend to go to prefs as the first thing to solve UI problems
  553. # [22:27] <Hixie> yeah the automatic thing is better
  554. # [22:27] <Hixie> just not autoplaying in bg tabs
  555. # [22:28] <Hixie> anyway
  556. # [22:28] <Hixie> so i've collapsed the currentRate 'boolean' and the playing boolean to just the playing three-state thing
  557. # [22:29] <Hixie> and split the state in the apple proposal into two states, since the apple proposal didn't allow for the case where even though everyhting is loaded you might not have the current frame ready yet (seeking)
  558. # [22:29] <Hixie> those don't seem like an increase in complexity, they seem like a lateral move
  559. # [22:29] <Hixie> and an improvement
  560. # [22:30] <Hixie> (reload the spec for the latest strawman: http://www.whatwg.org/specs/web-apps/current-work/#media )
  561. # [22:32] <othermaciej> I think CAN_PLAY_THROUGH makes more sense than ENDABLE -- first thought was CAN_PLAY_TO_END, but the end isn't even relevant on an infinite stream
  562. # [22:32] <othermaciej> and yet you can be in this state (but only if your transfer rate is fast enough)
  563. # [22:33] <othermaciej> I think dropping LOADED might be better than this split
  564. # [22:33] <othermaciej> LOADED is only useful in theory to tell you that not only can you play through everywhere and do everything, but also that can't possibly change
  565. # [22:34] <othermaciej> but if seeking can temporarily change that, then it doesn't have much value
  566. # [22:35] <othermaciej> I still don't think WAITING is justified and I don't think you have really countered my argument against it (can discover from other info and UI value is questionable)
  567. # [22:35] <Hixie> i disagree, i think you need is so that controllers who join part way can establish what the state of the network connection is
  568. # [22:35] <Hixie> (re loaded)
  569. # [22:35] <Hixie> since they won't get the progress events
  570. # [22:36] <othermaciej> hmm
  571. # [22:37] <othermaciej> the thing is, you might not currently be using the network even when not in LOADED state
  572. # [22:38] <othermaciej> if an implementation caches the remote resource in chunks for instance
  573. # [22:38] <othermaciej> and won't load the next ever if you pause in the middle of the current one
  574. # [22:38] <othermaciej> and it may be impossible to achieve LOADED
  575. # [22:38] <Hixie> once you're LOADED, you can go offline without any troubles ever
  576. # [22:39] <Hixie> if you're not in LOADED, going offline could show a warning
  577. # [22:39] <othermaciej> if you are presenting an rtsp stream, or if your implementation discards buffers
  578. # [22:39] <othermaciej> ok, that seems like a valid use
  579. # [22:39] <othermaciej> this makes me think LOADING vs. BUFFERING distinction really belongs in the other state, since it is not about network progress but about what you can currently do with the data
  580. # [22:40] <othermaciej> (you may be in BUFFERING state when in fact not currently doing a network transfer or planning to)
  581. # [22:40] <othermaciej> so perhaps it should be EMPTY, LOADING, LOADED, ERROR for one
  582. # [22:40] <othermaciej> and EMPTY, HAVE_METADATA, HAVE_FRAME, PLAYABLE, CAN_PLAY_THROUGH for the other
  583. # [22:41] <Hixie> could do
  584. # [22:41] <Hixie> not sure it's more useful though
  585. # [22:41] <othermaciej> well, HAVE_METADATA vs. HAVE_FRAME seems more clear than LOADING vs. BUFFERING
  586. # [22:42] <Hixie> you mean the names?
  587. # [22:42] <Hixie> the names can change
  588. # [22:42] <othermaciej> and LOADING vs. BUFFERING is not about the state of networking, it is about what level of presentation is available, which is what the readyState is about
  589. # [22:43] <Hixie> well it's kind of networking -- LOADING means you haven't received enough data yet to know if you'll go to ERROR or not
  590. # [22:43] <Hixie> BUFFERING means you've received enough data to know you're happy and to have initialised the rest of the object
  591. # [22:45] <Hixie> the problem with putting METADATA in the readyState is that you then have this awkward EMPTY METADATA HAVE_FRAME distinction
  592. # [22:45] <Hixie> where EMPTY becomes effectively useless
  593. # [22:45] <othermaciej> EMPTY means you can't do anything
  594. # [22:45] <Hixie> since you'll never be EMPTY once you've recieved METADATA
  595. # [22:46] <othermaciej> yeah, it's an initial state you can't come back to
  596. # [22:46] <othermaciej> much like the network-related EMPTY state
  597. # [22:46] <Hixie> conceptually, the current strawman has one state that always increases in value, and the readyState which can switch randomly across all states
  598. # [22:46] <othermaciej> you can switch back to EMPTY?
  599. # [22:46] <Hixie> i don't really like making the second one parially random-access but partially ordered
  600. # [22:46] * Joins: Brandan (n=Brandan@c-75-70-200-174.hsd1.co.comcast.net)
  601. # [22:47] <Hixie> sure, EMPTY is just "i don't have a frame or anything for this playback position"
  602. # [22:47] <othermaciej> I think it is overly simplistic to say state machines must either be linear or always allow transition to all states
  603. # [22:47] <othermaciej> I mean, you couldn't build a coke machine with those constraints
  604. # [22:47] <Hixie> they don't have to
  605. # [22:47] <Hixie> but it makes it way simpler if they do :-)
  606. # [22:47] <othermaciej> and that's the canonical example of a simple state machine
  607. # [22:47] <othermaciej> simpler for who?
  608. # [22:47] <othermaciej> the spec author, who can get out of drawing a state transition diagram?
  609. # [22:48] <Hixie> authors to understand, me to spec, implementors to follow...
  610. # [22:48] <gsnedders> it's easier to understand when implementing
  611. # [22:48] <othermaciej> when implementing, you have to understand every single transition arc
  612. # [22:48] <Hixie> right, so it's simpler if those are easyto enumerate
  613. # [22:49] <othermaciej> if you can go from any state to any other, that's n^2-n transition arcs
  614. # [22:49] <Hixie> there are no more transitions in your proposal (METADATA in readyState) than mine (METADATA in networkState)
  615. # [22:49] <othermaciej> that is in fact maximal complexity for an n-state machine, not minimal
  616. # [22:50] <Hixie> our proposals have the same number of transitions
  617. # [22:50] <othermaciej> sure, I'm just debating the premise that a "random access" state machine is somehow good for implementors
  618. # [22:50] <Hixie> i'm not saying that
  619. # [22:50] * Quits: met_ (n=Hassman@r5bx220.net.upc.cz) ("Chemists never die, they just stop reacting.")
  620. # [22:51] <Hixie> i'm saying that two state machines one of which is purely linear and the other of which is purely random-access is better than two state machines where one is linear and the other is bigger than the random access one, adding one extra arc that isn't random access
  621. # [22:52] <othermaciej> and I think if you want to partition state, you should do it by how the state will be used and what it represents, not by what the state transitions look like
  622. # [22:53] <Hixie> that's actually what i said originally when you originally suggested that
  623. # [22:53] <Hixie> i think having METADATA in the network state is more useful
  624. # [22:53] * Quits: dbaron (n=dbaron@c-71-198-189-81.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  625. # [22:53] <othermaciej> [ EMPTY --> LOADING --> METADATA --> LOADED ] doesn't make logical sense
  626. # [22:54] <Hixie> [ EMPTY -> opening connection -> received metadata -> receiving data -> received all ] makes logical sense
  627. # [22:54] <Hixie> however, one argument against this is you'd never stay in the metadata state
  628. # [22:54] <othermaciej> it would if "receiving metadata" was actually a separate step
  629. # [22:55] <othermaciej> but having the metadata is a side effect of being in the "I'm transferring bytes now" step, not a separate operation
  630. # [22:55] <Dashiva> But the "all metadata available" event would be useful, so it has to get into there somehow
  631. # [22:56] <Hixie> that's a point
  632. # [22:56] <Hixie> having it in the readyState means you'll get that message more often
  633. # [22:56] <Hixie> though
  634. # [22:56] <Hixie> no
  635. # [22:56] <othermaciej> you'll get it any time you seek to a place where you don't have a frame ready immediately
  636. # [22:56] <Hixie> we could just say that when you don't get the BUFFERING state until you have the metadata
  637. # [22:56] <Hixie> s/when//
  638. # [22:56] <othermaciej> but otherwise you would have gotten the readyState EMPTY state then
  639. # [22:57] <Dashiva> Or make metadataLoaded a separate boolean with associated event... mhrr
  640. # [22:57] <Hixie> actually we can get rid of this step altogether if we have the states split....
  641. # [22:58] <Hixie> you just define BUFFERING to happen only after you have metadata
  642. # [22:58] <Hixie> then you're set
  643. # [22:58] <othermaciej> I'm not sure what that means or how it is different than what the doc says now
  644. # [22:59] * Hixie gets himself really confused
  645. # [22:59] <Hixie> i just went through three arguments in a row that put me straight back to where i was initially
  646. # [22:59] <Hixie> i am not dizzy
  647. # [22:59] <Hixie> now
  648. # [22:59] <othermaciej> you have [ EMPTY -> LOADING -> BUFFERING -> LOADED ] right now
  649. # [23:00] <Hixie> right. that's what i think we want. EMPTY = nothing done. LOADING = sent request. BUFFERING = got back metadata, other fields now are initialised. LOADED = all data now downloaded, you can go offline safely.
  650. # [23:00] <othermaciej> I think LOADING vs. BUFFERING is descriptively poor as a way to say whether you have the metadata, and I think having the metadata belongs logically with presentability state, not networking state
  651. # [23:00] <Hixie> LOADING doesn't mean you have the metadata
  652. # [23:00] <Hixie> LOADING means you don't have anything, but you've requested it
  653. # [23:00] <othermaciej> LOADING means you don't have the metadata
  654. # [23:00] <Hixie> SENT maybe would be better
  655. # [23:00] <othermaciej> BUFFERING means you do
  656. # [23:01] <othermaciej> that is the only difference
  657. # [23:01] * Quits: santek_ (n=st@ut-w-7bd6.mxs.adsl.euronet.nl)
  658. # [23:01] <othermaciej> otherwise they both mean you are receiving some octets over the network
  659. # [23:01] <Hixie> right.
  660. # [23:01] <Hixie> so what's wrong with that?
  661. # [23:02] <othermaciej> the names of the states have no relation to this distinction
  662. # [23:02] <othermaciej> and in fact sound like synonyms
  663. # [23:02] <Hixie> i'm open to new names
  664. # [23:02] <othermaciej> (because from a purely networking POV, they are)
  665. # [23:03] <Dashiva> So you will be in BUFFERING state even if you're playing back with fast enough download to never enter buffering mode before end?
  666. # [23:03] <Hixie> i thought we weren't discussing names yet :-)
  667. # [23:03] * Joins: h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com)
  668. # [23:03] <othermaciej> I think the problem with the names is because they are trying to draw a distinction that, from the point of view of networking, does not exist
  669. # [23:03] * Hixie changes the names to EMPTY SENT LOADING LOADED
  670. # [23:03] <Dashiva> FINISHED :)
  671. # [23:04] <Hixie> finished, like language, initialised, and various other words, are bad in APIs because people mistype them too much
  672. # [23:04] <othermaciej> SENT vs. LOADING is misleading, since you might take it to mean that in SENT state you have not received any bytes yet
  673. # [23:04] <othermaciej> which is not the distinction it is trying to draw
  674. # [23:05] <othermaciej> seriously, having the metadata or not is a presnetability issue not a networking issue
  675. # [23:05] <othermaciej> putting it into the readyState immediately makes it super clear, for this reason
  676. # [23:05] <Hixie> UNSENT, SENT, RECEIVING, DONE? that's what XHR uses.
  677. # [23:05] <othermaciej> it's true that you can't go back to not having metadata
  678. # [23:05] <Hixie> it totally is a network issue
  679. # [23:06] <Hixie> until you have this part of the data, nothing else makes any sense
  680. # [23:06] <othermaciej> it is no more a network issue than having the first frame is a network issue
  681. # [23:06] <Hixie> except that you can go and lose the first frame
  682. # [23:06] * Dashiva wonders about mistyping finished
  683. # [23:06] <Hixie> but you can never lose the metadata
  684. # [23:07] <othermaciej> whether you can lose that level of presentability is not in any way due to networking
  685. # [23:07] <othermaciej> it's because having a frame is dependent on where you are on the timeline
  686. # [23:08] <Hixie> granted, but i don't see why that matters. how is having it in the attribute that tells you the state of frame playbackability useful?
  687. # [23:09] <Hixie> it seems to me that having the metadata is closer to the network state (it's a milestone along the download) than it is to the seeking and decoding state
  688. # [23:09] <othermaciej> that's the state you normally need to track to know what state to put the controls in
  689. # [23:10] <Hixie> controls don't disable themselves just because you're not able to play the current frame in current UIs
  690. # [23:11] <Hixie> they enable themselves once, when you have enough data to know wtf you're looking at
  691. # [23:11] <othermaciej> it's really only the first transition to having a frame that significantly matters, really
  692. # [23:12] <othermaciej> since most things only show placeholder UI before you have the first frame, when you seek they usually stick on the last frame seen
  693. # [23:12] <Hixie> agreed
  694. # [23:13] * Hixie ponders on this
  695. # [23:16] <Hixie> (on names, HAVE_FRAME doesn't really work for audio)
  696. # [23:16] <othermaciej> that state isn't really relevant to pure audio
  697. # [23:17] <othermaciej> since audio is more purely time-based, there's no such thing as presenting a static view of the current time
  698. # [23:18] <Hixie> there could be (e.g. embedded static images, captions, visualisation)
  699. # [23:20] <othermaciej> a static image along the lines of cover art would be considered metadata, not a playable track
  700. # [23:20] <othermaciej> if there is a text track displayed as captions, it's probably reasonable to consider each piece of text a "frame"
  701. # [23:21] <othermaciej> probably better than calling the state CAN_SHOW_STATIC_VIEW_OF_CURRENT_TIME
  702. # [23:21] * othermaciej is now known as om_coffee
  703. # [23:21] <om_coffee> will be back
  704. # [23:53] <hsivonen> what's the process of getting something published in w3.org/TR/?
  705. # [23:53] <hsivonen> I mean: why is the backplane stuff there?
  706. # [23:57] <karlUshi> http://www.w3.org/TR/2006/NOTE-backplane-20061116/
  707. # [23:57] <karlUshi> *W3C Coordination Group Note*
  708. # [23:58] * Joins: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  709. # [23:58] <karlUshi> "Publication as a Coordination Group Note does not imply endorsement by the W3C Membership. "
  710. # [23:59] <karlUshi> ok time to prepare to take a shower
  711. # Session Close: Mon Apr 02 00:00:00 2007

The end :)