/irc-logs / freenode / #whatwg / 2008-06-26 / end

Options:

  1. # Session Start: Thu Jun 26 00:00:00 2008
  2. # Session Ident: #whatwg
  3. # [00:01] * Joins: hasather (n=hasather@ti0034a380-2730.bb.online.no)
  4. # [00:03] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net) (Read error: 110 (Connection timed out))
  5. # [00:06] * tantek_ is now known as tantek
  6. # [00:10] * Joins: technomancy (n=phil@dsl081-164-175.sea1.dsl.speakeasy.net)
  7. # [00:11] <technomancy> hey, it looks like the gem version of html5lib that's been uploaded to rubyforge is rather out of date
  8. # [00:11] <technomancy> any chance 0.11 could be published?
  9. # [00:12] <technomancy> err--actually it looks like 0.10.1 is the latest for ruby
  10. # [00:13] * Quits: heycam (n=cam@124-168-70-30.dyn.iinet.net.au) ("bye")
  11. # [00:13] <Philip`> technomancy: 0.11 is only Python - the Ruby port is currently in a slightly broken unmaintained state
  12. # [00:14] * Parts: hasather (n=hasather@ti0034a380-2730.bb.online.no)
  13. # [00:14] <technomancy> I see. Well 0.10 is too old to work with mars (the Planet port); it looks like trunk is better.
  14. # [00:16] <jgraham__> technomancy: Ryan King suggested he might try and update the Ruby port sometime but otherwise it's a case of patch it yourself if you need to match the current spec, I'm afraid
  15. # [00:16] <kingryan> hey. yeah, i'm hoping to have time to work on it soon, but don't hold your breath
  16. # [00:18] <technomancy> Hmm... I know next to nothing about HTML 5; I just want mars to be easy to install.
  17. # [00:18] * Joins: KevinMarks (n=KevinMar@nat/google/x-c19d04165c79598d)
  18. # [00:20] <technomancy> is the version in trunk really that much worse than 0.10?
  19. # [00:21] <jgraham__> I think the trunk version is a little ahead of 0.10 but quite far behind 0.11. I guess it will fail a lot of the tests
  20. # [00:22] <jgraham__> It may be good enough for what you want to do, depending on what that is
  21. # [00:22] <technomancy> jgraham__: well Sam Ruby says to use trunk rather than the gem since it has a certain bug fix, but he didn't go into detail about what it was.
  22. # [00:23] <technomancy> yikes... it's been a long time since I've seen that many test failures.
  23. # [00:23] * Quits: qwert666 (n=qwert666@ett207.neoplus.adsl.tpnet.pl) ("Leaving")
  24. # [00:28] <Philip`> technomancy: Those test failures are probably caused by the tests changing (to follow more recent versions of HTML5), so it just indicates that the Ruby trunk is out of date rather than that it's buggier than in 0.10
  25. # [00:29] * Quits: psa2 (n=yomode@71.93.19.66) (kubrick.freenode.net irc.freenode.net)
  26. # [00:29] <kingryan> Philip` is right, the tests have been updated since the ruby port was last touched, so its just out of date, but stable and pretty good at dealing with real-world content
  27. # [00:29] * Joins: psa2 (n=yomode@71.93.19.66)
  28. # [00:29] * Quits: jmb (n=jmb@login.ecs.soton.ac.uk) (Remote closed the connection)
  29. # [00:30] * Joins: jmb (n=jmb@login.ecs.soton.ac.uk)
  30. # [00:30] <technomancy> gotcha
  31. # [00:31] <kingryan> i actually tested it against a couple million random pages on the web (back when i was at technorati) and it at least didn't crash during that :)
  32. # [00:31] * Joins: arun_ (n=arun@adsl-75-36-186-239.dsl.pltn13.sbcglobal.net)
  33. # [00:32] <Philip`> It's trivial to write a parser that doesn't crash, since you could just make it return an empty document - the only interesting thing is whether it parsed all those millions of pages correctly :-)
  34. # [00:35] <Hixie> what was the reason for not using "address" again?
  35. # [00:35] <Hixie> was it just <address>?
  36. # [00:37] <Philip`> http://www.answers.com/address - it has plenty of meanings already, so it'll cause much confusion if you try to force people to think of it instead as some specific technical concept you've defined
  37. # [00:39] <Hixie> yeah, fair enough
  38. # [00:41] <Hixie> bbl
  39. # [00:55] * arun_ is now known as aruner
  40. # [00:56] * Quits: webben_ (n=benh@nat/yahoo/x-f4e7e73f38048ba4) (Read error: 60 (Operation timed out))
  41. # [01:02] * Quits: smedero (n=smedero@mdp-nat251.mdp.com)
  42. # [01:08] * Joins: othermaciej (n=mjs@17.255.109.171)
  43. # [01:14] * Joins: defence2 (n=chatzill@ip70-179-99-2.dc.dc.cox.net)
  44. # [01:25] * Quits: defence2 (n=chatzill@ip70-179-99-2.dc.dc.cox.net) (Read error: 104 (Connection reset by peer))
  45. # [01:27] * Quits: aaronlev (n=chatzill@g226140114.adsl.alicedsl.de) ("ChatZilla 0.9.83 [Firefox 3.0/2008052906]")
  46. # [01:28] * Quits: KevinMarks (n=KevinMar@nat/google/x-c19d04165c79598d) ("The computer fell asleep")
  47. # [01:35] * Quits: othermaciej (n=mjs@17.255.109.171)
  48. # [01:36] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
  49. # [01:40] * Joins: othermaciej (n=mjs@17.255.109.171)
  50. # [02:15] * Quits: tndH (i=Rob@87.102.5.204) ("ChatZilla 0.9.83-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  51. # [02:17] * Joins: hdh0 (n=hdh@118.71.124.16)
  52. # [02:28] * Quits: othermaciej (n=mjs@17.255.109.171)
  53. # [02:34] * Quits: hdh (n=hdh@118.71.120.23) (Read error: 110 (Connection timed out))
  54. # [02:36] * Joins: webben (n=benh@91.85.160.213)
  55. # [02:39] * Quits: technomancy (n=phil@dsl081-164-175.sea1.dsl.speakeasy.net) ("rcirc on GNU Emacs 23.0.60.2")
  56. # [02:41] * Joins: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com)
  57. # [02:47] * Joins: othermaciej_ (n=mjs@17.203.15.160)
  58. # [02:55] * Quits: weinig_ (n=weinig@17.203.15.145) (Read error: 104 (Connection reset by peer))
  59. # [02:55] * Joins: weinig (n=weinig@17.203.15.145)
  60. # [02:56] * Quits: webben (n=benh@91.85.160.213) (Read error: 110 (Connection timed out))
  61. # [03:01] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.3 (IRC client for Emacs)")
  62. # [03:04] * Philip` sees https://bugzilla.mozilla.org/show_bug.cgi?id=214476 with part of the HTML5 tokeniser state machine
  63. # [03:07] * Quits: billmason (n=billmaso@ip192.unival.com) (".")
  64. # [03:10] * Joins: jacobolus (n=jacobolu@ip-12-22-56-126.hqglobal.net)
  65. # [03:28] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  66. # [03:34] * Quits: weinig (n=weinig@17.203.15.145) (Read error: 110 (Connection timed out))
  67. # [03:34] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  68. # [03:49] * Joins: hober (n=ted@unaffiliated/hober)
  69. # [03:51] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  70. # [04:02] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  71. # [04:09] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  72. # [04:23] * Joins: othermaciej (n=mjs@17.255.109.171)
  73. # [04:24] * Quits: othermaciej (n=mjs@17.255.109.171) (Client Quit)
  74. # [04:25] * Joins: othermaciej (n=mjs@17.255.109.171)
  75. # [04:26] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.3 (IRC client for Emacs)")
  76. # [04:39] * Quits: othermaciej (n=mjs@17.255.109.171)
  77. # [04:40] * Quits: othermaciej_ (n=mjs@17.203.15.160) (Read error: 110 (Connection timed out))
  78. # [05:12] * Quits: aruner (n=arun@adsl-75-36-186-239.dsl.pltn13.sbcglobal.net)
  79. # [05:16] * Joins: toolskyn_ (n=toolskyn@apher.xlshosting.com)
  80. # [05:24] * Quits: toolskyn (n=toolskyn@apher.xlshosting.com) (Read error: 104 (Connection reset by peer))
  81. # [05:40] * Joins: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  82. # [05:43] * Joins: kingryan_ (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net)
  83. # [05:43] * Quits: kingryan (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  84. # [06:38] * Quits: franksalim (n=franksal@cpe-72-130-134-143.san.res.rr.com) ("Leaving")
  85. # [06:45] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  86. # [07:03] * Joins: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net)
  87. # [07:41] * Quits: roc (n=roc@202.0.36.64)
  88. # [07:46] * Quits: jgraham__ (n=jgraham@81-86-219-217.dsl.pipex.com) (Read error: 110 (Connection timed out))
  89. # [08:02] * Quits: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  90. # [08:02] * Joins: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  91. # [08:25] * Joins: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de)
  92. # [08:38] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) ("bye")
  93. # [08:48] * Quits: jacobolus (n=jacobolu@ip-12-22-56-126.hqglobal.net)
  94. # [08:50] * Joins: jacobolus (n=jacobolu@ip-12-22-56-126.hqglobal.net)
  95. # [09:14] <hsivonen> mrbkap: parsetree.validator.nu isn't running the trunk of the Validator.nu parser (because I haven't fixed all the fallout from implementing SVG and MathML yet)
  96. # [09:17] * Joins: aaronlev (n=chatzill@g226140114.adsl.alicedsl.de)
  97. # [09:30] * Quits: jmb (n=jmb@login.ecs.soton.ac.uk) (Remote closed the connection)
  98. # [09:30] * Joins: jmb (n=jmb@login.ecs.soton.ac.uk)
  99. # [09:32] * Joins: heycam (n=cam@124-168-70-30.dyn.iinet.net.au)
  100. # [09:35] * Quits: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com)
  101. # [09:35] * Quits: jacobolus (n=jacobolu@ip-12-22-56-126.hqglobal.net)
  102. # [09:40] * Joins: aaronlev_ (n=chatzill@g226140114.adsl.alicedsl.de)
  103. # [09:41] * Joins: gDashiva (n=noone@195.18.164.170)
  104. # [09:42] <gDashiva> So this XSLT entry in bugzilla... it is being argued that using XSLT to output XHTML (instead of HTML) is an inferior solution.
  105. # [09:43] <Lachy> what the? One of Rob's bugs got marked ASSIGNED?!
  106. # [09:44] <Lachy> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5772
  107. # [09:44] <hsivonen> Hixie: I think the point of aggregating content is that you actually aggregate it instead of putting it in an iframe
  108. # [09:55] * Quits: jmb (n=jmb@login.ecs.soton.ac.uk) (Remote closed the connection)
  109. # [09:55] * Joins: jmb (n=jmb@login.ecs.soton.ac.uk)
  110. # [09:59] * Quits: aaronlev (n=chatzill@g226140114.adsl.alicedsl.de) (Read error: 110 (Connection timed out))
  111. # [10:02] <takkaria> jmb: ping. I'm thinking the best way to add ns support to hubbub is to add an enum to hubbub_tag which has the possible namespaces the spec says you can create elements in
  112. # [10:02] <takkaria> oh, wrong channel, sorry. :)
  113. # [10:03] <hsivonen> takkaria: how does the libxml2 tree impl. represent namespaces?
  114. # [10:04] * Joins: annevk (n=annevk@0x573ff34e.boanqu1.broadband.tele.dk)
  115. # [10:04] <takkaria> hsivonen: AFAICT, it passes around strings
  116. # [10:04] <hsivonen> takkaria: ok.
  117. # [10:04] <jmb> takkaria: heh
  118. # [10:05] <hsivonen> fwiw, it sucks when an XML API doesn't required namespaces to be interned in some way and lots and lots of string compares happen on the namespace
  119. # [10:06] <takkaria> yeah, I want to avoid string compares
  120. # [10:06] <takkaria> if libxml2 needs things converted to strings, that can be done easily enough in the hubbub<->libxml2 binding
  121. # [10:11] * Joins: zcorpan (n=zcorpan@pat-tdc.opera.com)
  122. # [10:16] <Hixie> hsivonen: it'll be in the same source document, just not in the same Document object
  123. # [10:23] <hsivonen> Hixie: if you had an HTML5-based blog and it showed automatic extracts of other blogs linking to you, would you put the extracts in iframes or would you sanitize the fragments heavily not to contain id or class attributes?
  124. # [10:26] <Hixie> iframes
  125. # [10:26] <Hixie> sandbox baby
  126. # [10:26] * Joins: roc (n=roc@121-72-174-49.dsl.telstraclear.net)
  127. # [10:35] * Quits: annevk (n=annevk@0x573ff34e.boanqu1.broadband.tele.dk) (Read error: 110 (Connection timed out))
  128. # [10:36] * Joins: jgraham (n=jgraham@81-86-212-29.dsl.pipex.com)
  129. # [10:44] <hsivonen> Hixie: fwiw, xmlns talisman checking is one of the things that block me from deploying the parser trunk in the validator, so I'm allowing the xmlns talisman on any HTML element at least for now
  130. # [10:45] <Hixie> hm?
  131. # [10:45] <Hixie> oh because your pipeline doesn't support xmlns="" all the way through?
  132. # [10:45] <Hixie> or?
  133. # [10:46] <hsivonen> Hixie: the pipeline doesn't support xmlns as attributes, so I'm doing the check in the tree builder
  134. # [10:47] <Hixie> right
  135. # [10:48] <Hixie> how do you handle xmlns:foo ?
  136. # [10:48] <Hixie> (e.g. on <embed>)
  137. # [10:48] <hsivonen> Hixie: there's a bug now
  138. # [10:48] <Hixie> or data-:foo=""
  139. # [10:49] <hsivonen> Hixie: those are invalid, so it's not a problem if the RELAX NG validator whines
  140. # [10:49] <hsivonen> Hixie: the problem is expressing valid things that are bogus in XML
  141. # [10:49] <Hixie> really?
  142. # [10:49] <hsivonen> of and the data thing doesn't matter, because data- is magic alreday
  143. # [10:49] <hsivonen> s/of/oh/
  144. # [10:50] <Hixie> i thought <embed xmlns> and data-:foo="" were both valid
  145. # [10:50] <hsivonen> xmlns:foo never is unless foo==xlink and in foreign
  146. # [10:51] <Hixie> where does the spec say that?
  147. # [10:51] <hsivonen> ooh. <embed>!
  148. # [10:52] <Hixie> right
  149. # [10:53] <hsivonen> that sucks
  150. # [10:53] <Hixie> <embed *> and data-* are the two places attributes are unconstrained
  151. # [10:53] <hsivonen> Hixie: but common attributes and aria-* are constrained on embed, right?
  152. # [10:54] <Hixie> common attributes yes
  153. # [10:54] <Hixie> aria-*, dunno, haven't yet seen a sane spec for those
  154. # [10:54] <hsivonen> Hixie: well, aria-* should be, right?
  155. # [10:54] <Hixie> (nor have i looked; a sane spec might exist)
  156. # [10:54] <Hixie> aria-* seem like they would be treated as common attributes, yes
  157. # [10:55] <hsivonen> Hixie: fwiw, I'd expect an aria state that isn't applicable to the current role of <embed> to be invalid on embed
  158. # [10:56] <hsivonen> Hixie: the tricky question is what to do with aria-bogus on embed
  159. # [10:56] <hsivonen> should that be valid or invalid?
  160. # [10:56] <Hixie> right, i'd expect most aria-* things that contradict html semantics to be invalid
  161. # [10:56] * Quits: Lachy (n=Lachlan@85.196.122.246) ("Leaving")
  162. # [10:56] <Hixie> aria-* is a defined set of attributes, right?
  163. # [10:56] <zcorpan> Hixie: yes
  164. # [10:56] <Hixie> so aria-bogus isn't in aria-*
  165. # [10:57] <hsivonen> Hixie: aria-* is a finite set
  166. # [10:57] <zcorpan> Hixie: right, but <embed> allows any attributes
  167. # [10:57] <hsivonen> Hixie: but aria-bogus is reserved for future ARIA
  168. # [10:57] <Hixie> oh i see what you're asking
  169. # [10:57] <hsivonen> zcorpan: so in that sense, aria-* is infinite
  170. # [10:57] <Hixie> i don't like the idea of reserving attributes personally
  171. # [10:57] <hsivonen> s/zcorpan/Hixie/
  172. # [10:57] <Hixie> and would be fine with just not worrying about it
  173. # [10:58] <hsivonen> Hixie: umm. you are reserving everything but data-*!
  174. # [10:58] <Hixie> not on <embed>
  175. # [10:59] <hsivonen> anyway, handling <embed> sucks
  176. # [10:59] <Hixie> s'what you get for using an xml pipeline and schemas :-D
  177. # [11:00] <hsivonen> Hixie: I blame namespaces for making some attributes special
  178. # [11:00] <Hixie> i blame namespaces for a lot of things :-)
  179. # [11:00] <Hixie> but that doesn't help us :-)
  180. # [11:01] <hsivonen> Hixie: we could help ourselves by not insisting that xmlns:foo be non-special
  181. # [11:02] <zcorpan> from a practical point of view, i'd like to know that i've typoed aria-disalbed on <embed>
  182. # [11:02] <hsivonen> zcorpan: good point
  183. # [11:02] <zcorpan> whether it's a warning or error matters less to me
  184. # [11:02] <hsivonen> zcorpan: although if you've typoed class, you wouldn't know
  185. # [11:02] <Hixie> from a practical point of view, i doubt any aria-* attributes are going to have a useful result on <embed>
  186. # [11:02] <zcorpan> hsivonen: true
  187. # [11:03] <Hixie> and if you care about accessibility, <embed> probably isn't going to even appear in your document
  188. # [11:03] <zcorpan> i guess the only aria attribute you'd use on embed, if anything, is role="presentation"
  189. # [11:04] <hsivonen> Hixie: if ARIA really never makes any sense whatsoever on <embed> (i.e. the plug-in always drives the accessibility API including the node for <embed> itself), then I'd prefer to see ARIA non-conforming on <embed>
  190. # [11:04] <Hixie> hsivonen: well like i said, i've yet to see a useful description of aria in html
  191. # [11:04] <Hixie> hsivonen: so i can't really make educated comments about aria
  192. # [11:05] <Hixie> as it stands now, html5 doesn't even acknowledge that aria exists
  193. # [11:05] <hsivonen> Hixie: which is a problem given all the discussions that assume that HTML5 will import aria-*
  194. # [11:06] <jgraham> Doesn't something like ariia-describedby make sense on <embed>?
  195. # [11:07] <hsivonen> Hixie: even if details are left for later, it would be nice to have a red box acknowledging the intent to import ARIA into common attributes
  196. # [11:07] <Hixie> i've already told the aria group that if they want html5 to import aria, aria needs to get its act together and define how it works in html5-levels of detail
  197. # [11:07] <hsivonen> jgraham: yes, if it is implementable in a sane way in a situation where the plug-in talks to the accessibility API, too.
  198. # [11:08] <jgraham> hsivonen: Why would the plugin need to talk to the accessibility API?
  199. # [11:08] <hsivonen> jgraham: to make the plug-in content navigable through AT
  200. # [11:08] * Joins: qwert666 (n=qwert666@acdg125.neoplus.adsl.tpnet.pl)
  201. # [11:09] <hsivonen> jgraham: Ideally, the accessible tree of Flash content should appear as a subtree of the HTML document's accessible tree without the user having to care about the integration point
  202. # [11:10] <jgraham> I thought that aria-describedby was for descriptions, no? It seems like you could describe the contents of the plugin even in the case that you couldn't actually use it, though clearly it would be better to actually be able to use it
  203. # [11:11] <zcorpan> i don't really understand the use-case for aria-describedby
  204. # [11:11] <hsivonen> jgraham: I think you can have descriptions for stuff that can also be further examined by AT
  205. # [11:15] <jgraham> hsivonen: I don't think it's clear that there are supposed to be any restrictions on what can have an aria-describedby which sort of makes sense since the develop might have no knowledge of what the AT can interact with
  206. # [11:17] * Joins: annevk (n=annevk@0x5da33d22.boanqu1.broadband.tele.dk)
  207. # [11:18] * jgraham likes how the aria spec says: Property: "labelledby [...] A related concept is label in HTML" but also says "Property: describedby: [...] A label should provide the user with the essence of the what the object does whereas describedby is intended to provide additional information which some users might need [...] HTML label element, and HTML table cell headers are de facto describedby values"
  208. # [11:19] <Hixie> that's about this |<------------------------------------------->| far from being good enough to be integrated with html5
  209. # [11:19] <annevk> de facto?
  210. # [11:20] <annevk> hah
  211. # [11:20] * annevk is at reboot10
  212. # [11:20] * annevk wonders if the WiFi dropped again :)
  213. # [11:20] <Hixie> hey anne
  214. # [11:20] <jgraham> The aria spec really sucks
  215. # [11:20] <jgraham> indeed
  216. # [11:20] <jgraham> Or to rearrange into the sentence I was aiming for, "Indeed, the aria spec really sucks"
  217. # [11:22] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  218. # [11:23] * Joins: aaronlev__ (n=chatzill@e176255090.adsl.alicedsl.de)
  219. # [11:23] * aaronlev__ is now known as aaronlev
  220. # [11:23] <annevk> ah, so I'm still online, I receive your messages in blobs
  221. # [11:23] <zcorpan> so there's new Image() and new Audio() but no new Video()
  222. # [11:25] * Joins: ROBOd (n=robod@89.122.216.38)
  223. # [11:25] * Joins: webben (n=benh@nat/yahoo/x-4f88c5f42c1acbb3)
  224. # [11:25] <annevk> hi Hixie
  225. # [11:26] <Hixie> zcorpan: new Image() is there for historical reasons, like new Option(); new Audio() is there because you will likely want to play with audio without thinking of it as an element
  226. # [11:31] <Philip`> Do any tests for Audio/<audio> exist yet?
  227. # [11:31] <Philip`> (Audio was pretty broken when I last played with it in Opera)
  228. # [11:31] <Hixie> i know of no tests
  229. # [11:33] <zcorpan> i have a few very basic tests
  230. # [11:34] <zcorpan> testing <video> and <audio> at the same time
  231. # [11:34] <zcorpan> http://simon.html5.org/test/html/dom/interfaces/HTMLElement/HTMLMediaElement/
  232. # [11:35] * Quits: kingryan_ (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net) (Remote closed the connection)
  233. # [11:35] <annevk> I have tests for new Audio() somewhere but I'm not sure if they're still valid with the new API
  234. # [11:35] * Joins: kingryan (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net)
  235. # [11:36] <Philip`> Okay, thanks
  236. # [11:37] <Philip`> I think the problems I had were with trying to play the same sound file multiple times
  237. # [11:37] <Philip`> which ought to mix everything together but in Opera it only played one at a time
  238. # [11:38] <othermaciej> we have some in the WebKit regression tests, though they are not thorough compliance tests or anything
  239. # [11:38] <Hixie> i've passed the 50% mark in my big URLification project
  240. # [11:43] * Quits: aaronlev_ (n=chatzill@g226140114.adsl.alicedsl.de) (Read error: 110 (Connection timed out))
  241. # [11:46] <roc> doublec is writing some
  242. # [11:48] <Philip`> What <audio> really needs is a spectrum analyser API
  243. # [11:48] <roc> graphic equalizer in every tab
  244. # [11:50] <Philip`> I want a web page with DOM nodes bouncing around in time with the background music
  245. # [11:51] <Hixie> that would be cool indeed
  246. # [11:51] <Hixie> send mail
  247. # [11:51] <Hixie> i'll get right on punting that to v3
  248. # [11:52] <mrbkap> Philip`: Because hamsters randomly bouncing around in the background isn't enough? They have to be in time with the music now too?
  249. # [11:52] <Philip`> Actually it could just expose the raw sample data, then you can write an FFT in JavaScript
  250. # [11:53] <Hixie> web 2.0 hamster dance: now in time with the music.
  251. # [11:53] <hsivonen> shoudn't they be badgers?
  252. # [11:53] <doublec> someone sent me a vorbis decoder in javascript - with raw sample data that would be useful :)
  253. # [11:53] <Lachy> oh, drawing visualations on canvas would be awesome
  254. # [11:54] <hsivonen> doublec: does it perform in real time on today's hardware?
  255. # [11:54] <Hixie> Philip`: you could implement the fft server-side, and use xhr to get each sample frame analysed, for extra web 2.0ness
  256. # [11:54] <Philip`> mrbkap: I thought the point of APNG was that the old animated hamster GIFs could now be rendered in full 24-bit colour
  257. # [11:54] <Philip`> so clearly this is the direction that the technology is evolving in
  258. # [11:55] <mrbkap> "Web 2.0, supporting more colorful, rhythmic hamsters"
  259. # [11:55] <doublec> hsivonen: it's actually actionscript and works in real time on the flash player. I've modified it to get it running on tamarin but haven't got it actually playing real sound yet.
  260. # [11:55] <hsivonen> doublec: cool.
  261. # [11:56] <Philip`> hsivonen: Badgers don't dance - only hamsters do
  262. # [11:56] <Lachy> if you're doing the analysis server side, you could just download a single file with all the data in it and just keep the audio and visualation synchronised.
  263. # [11:56] <doublec> as long as 'todays hardware' is dual core machine not doing anything but decoding a single file
  264. # [11:56] <Lachy> Philip`, could you build a demo site using such a workaround?
  265. # [11:57] <Philip`> Lachy: How would you keep them synchronised?
  266. # [11:57] <Lachy> time indexes
  267. # [11:58] <Hixie> use the flash plugin to listen to the music using the user's microphone
  268. # [11:58] <Hixie> and use that to sync the visual
  269. # [11:58] <Philip`> Synchronisation seems hard when you're using setTimeout with 16ms resolution
  270. # [12:00] <Lachy> if you frequently query the currentTime of the audio, you can adjust for any discrepencies
  271. # [12:00] <Lachy> as long as it doesn't drift too far out of sync to be perceptable to the user, it's not a big problem.
  272. # [12:01] <Philip`> Hixie: That wouldn't work for me, since I use earphones
  273. # [12:01] <Hixie> ah well
  274. # [12:01] <Hixie> the best plans of mice and men, et al
  275. # [12:04] * Quits: annevk (n=annevk@0x5da33d22.boanqu1.broadband.tele.dk) (Read error: 110 (Connection timed out))
  276. # [12:05] <Hixie> @#$%(&!@#
  277. # [12:06] <Lachy> ?
  278. # [12:06] <Hixie> window.open('http://{', 'x') does nothing if frame 'x' is an iframe, and shows an error if it has to open a new window
  279. # [12:06] <Hixie> except in firefox
  280. # [12:07] <Hixie> oh, and IE
  281. # [12:07] <Hixie> that'll teach me to test in reverse order of market share
  282. # [12:07] * hsivonen considers filing a spec bug about the infoset mappability of the attributes on <embed> and data-* attributes
  283. # [12:07] <Hixie> nevermind!
  284. # [12:07] <Hixie> i have to say, bugzilla makes rejecting bugs much more satisfying
  285. # [12:08] <Hixie> and, frankly, easier
  286. # [12:08] <hsivonen> Hixie: are you implying you'd reject a bug about infoset mappability?
  287. # [12:08] <gDashiva> And much more .. cyclic
  288. # [12:08] <gDashiva> resolve, reopen, resolve, reopen, the dance goes on until someone calls mike
  289. # [12:09] <Hixie> hsivonen: i wasn't trying to imply that, no
  290. # [12:09] <Hixie> with bugzilla, i can say "i agree" and mark the bug WONTFIX at the same time
  291. # [12:09] <Hixie> in e-mail, if i say "i agree", then it's assumed that i am not rejecting the request
  292. # [12:10] <Hixie> hsivonen: i'm not sure i really care about infoset mappability, though
  293. # [12:10] <Hixie> hsivonen: do you mean xml/html roundtripping?
  294. # [12:10] * Hixie has never been really sold on the value of xml/html roundtripping
  295. # [12:10] <hsivonen> Hixie: *you* may not care about it directly, but if the party line is "just stick an HTML5 parser at the front of your XML pipeline", perhaps it should matter
  296. # [12:11] <Philip`> http://philip.html5.org/tests/canvas/suite/tests/spec.html is produced via XML/HTML roundtripping
  297. # [12:11] <Philip`> but that's just because the XML version is far quicker to parse repeatedly
  298. # [12:12] <Hixie> it has certainly had a higher cost to maintain the fiction that the set of documents serialisable to html is the same as the set of documents serialisable to xml than i first anticipated
  299. # [12:13] <Hixie> hsivonen: i don't understand why the xml pipelines are so constrained to the infosets that the xml syntax allows
  300. # [12:13] <Hixie> hsivonen: why do xml pipelines enforce "tag names can't contain spaces", for instance? surely that's just excess code that isn't helping anyone
  301. # [12:13] <Hixie> hsivonen: i mean, the parser should enforce that, sure
  302. # [12:14] <Hixie> hsivonen: but once it's parsed, who cares
  303. # [12:14] <hsivonen> Hixie: some people (rightly) don't want pipelines to silently serialize stuff that can't be parsed back with a conforming XML 1.0 parser
  304. # [12:14] <zcorpan> hsivonen: but shouldn't that be part of the serializer?
  305. # [12:15] <Hixie> i understand that the serialiser would want to verify conformance of its output
  306. # [12:15] <hsivonen> zcorpan: that's a design decision which isn't *our* design decision
  307. # [12:15] <hsivonen> for example, XOM throws early
  308. # [12:15] <Hixie> but enforcing the serialiser's constraints in the pipeline itself seems like bad design to me
  309. # [12:15] <Hixie> anyway
  310. # [12:16] <Philip`> zcorpan: It's much easier for debugging if it complains immediately when unserialisable content is inserted into the document, rather than silently accepting it and then complaining thousands of lines of code later when you try serialising
  311. # [12:16] <hsivonen> Hixie: it seems sensible design in some sense, although it makes no sense for perf
  312. # [12:16] <Hixie> maybe we should just define a set of mutations to the "infoset" that html parsers can apply if they are going to be used with these overconstraining xml-biased pipelines
  313. # [12:16] <zcorpan> i guess it could make sense if all you have to deal with is xml
  314. # [12:17] <Hixie> (with the understanding that these mutations would be destructive)
  315. # [12:17] <hsivonen> zcorpan: obviously, all text/html from "out there" can't be losslessly mapped to XML 1.0 (4th ed. or earlier), but it's yucky in principle if conforming docs also expose the problems
  316. # [12:17] <Philip`> zcorpan: That seems sensible since all most people have to deal with is XML; it's just HTML that thinks it's a special case and doesn't fit in with the proper world-view
  317. # [12:18] * Joins: myakura (n=myakura@p1216-ipbf601marunouchi.tokyo.ocn.ne.jp)
  318. # [12:20] * Joins: tndH (i=Rob@87.102.5.204)
  319. # [12:20] <hsivonen> Hixie: I intend to ship a set of mutations, but it isn't theoretically pure to have to apply those to conforming docs
  320. # [12:20] <Hixie> i long ago gave up on things being theoretically pure
  321. # [12:21] <hsivonen> Hixie: then you can allow the xmlns talisman regardless of tree position :-)
  322. # [12:21] <Hixie> i was going to :-)
  323. # [12:21] <hsivonen> great :-)
  324. # [12:21] <Hixie> (hence the bug being assigned, not wontfixed :-) )
  325. # [12:22] <Hixie> assigned = i will do something
  326. # [12:23] * hsivonen starts fixing the infoset coercion regressions introduced by the SVG/MathML work
  327. # [12:24] <hsivonen> with the xlink fixup, the decision needs to be deferred until the tree builder
  328. # [12:29] * Quits: jruderman (n=jruderma@ip68-5-179-249.oc.oc.cox.net)
  329. # [12:30] <Hixie> http://www.w3.org/mid/op.udcpa1lp6hl8nm@clerew.man.ac.uk seems to miss the point a little
  330. # [12:34] * Joins: annevk (n=annevk@0x5da33d22.boanqu1.broadband.tele.dk)
  331. # [13:04] <hsivonen> Hixie: fwiw, the non-NCName munging I implemented is "_nonxml_" followed by the name escaped as UTF-8 and a-z and '-' passed through literally and other bytes escaped as two uppercase hex digits each, finally followed by "_"
  332. # [13:06] <hsivonen> actually, that's not good
  333. # [13:09] <hsivonen> I like it that the HTML5 spec now has a one-stop place to copy and paste namespace URIs from
  334. # [13:10] * Quits: roc (n=roc@121-72-174-49.dsl.telstraclear.net)
  335. # [13:12] <zcorpan> hsivonen: shouldn't the "nonxml" part be uppercase so that it's possible to distinguish between <a #> and <a _nonxml_23>?
  336. # [13:13] <zcorpan> i mean <a _nonxml_23_>
  337. # [13:13] <hsivonen> zcorpan: actually, I think the _noxml_ part should be a namespace that the parsing algorithm doesn't otherwise output
  338. # [13:13] <zcorpan> why?
  339. # [13:14] <hsivonen> zcorpan: that way I don't need to check for collisions with _noxml_ actually appearing in the input
  340. # [13:14] <zcorpan> uppercase can't appear in the input
  341. # [13:14] <hsivonen> zcorpan: excellent point
  342. # [13:14] <hsivonen> zcorpan: thanks
  343. # [13:29] <Lachy> so much for WebApps being a public group!
  344. # [13:29] <Lachy> they moved the telcon to #waf to get away from krijnh's IRC logs.
  345. # [13:30] <gDashiva> They are a public group. They're just using the w3c definition of public.
  346. # [13:32] * Quits: webben (n=benh@nat/yahoo/x-4f88c5f42c1acbb3)
  347. # [13:39] <zcorpan> so what was the [off] feature for?
  348. # [13:39] <Lachy> zcorpan, no idea
  349. # [13:39] <Lachy> I don't think anyone even bothered to announce that it was added on the mailing list.
  350. # [13:39] <Lachy> shepazu should have done that, since he pushed so hard for it
  351. # [13:41] * Joins: roc (n=roc@121-72-174-49.dsl.telstraclear.net)
  352. # [13:47] * Quits: annevk (n=annevk@0x5da33d22.boanqu1.broadband.tele.dk) (Read error: 104 (Connection reset by peer))
  353. # [13:49] * Joins: webben (n=benh@nat/yahoo/x-c9b2f59959dd072b)
  354. # [14:15] * Quits: roc (n=roc@121-72-174-49.dsl.telstraclear.net)
  355. # [14:34] * Joins: kingryan_ (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net)
  356. # [14:34] * Quits: kingryan (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net) (Read error: 54 (Connection reset by peer))
  357. # [14:36] * Joins: annevk2 (n=annevk@0x573ffcee.boanqu1.broadband.tele.dk)
  358. # [14:38] <shepazu> Lachy: I wasn't sure about the status of the feature... maybe krijnh would like to speak on it?
  359. # [14:39] <Lachy> shepazu, what is there to discuss? It was enabled at your request for the #webapps channel, and AFAIK, is still enabled.
  360. # [14:39] * Joins: excrypf (n=nogah@58.187.95.189)
  361. # [14:40] <Lachy> but, at the moment, it seems krijnh currently isn't making the #webapps logs public anyway
  362. # [14:41] <shepazu> when last I heard, Lachy, he was still working on it... and the WG hasn't actually come to a decision on logging... I don't consider a deadline to be a very good criteria of agreement
  363. # [14:41] <Lachy> well, I think the whole issue is silly. The fact that it's a public group should be enough to make any logging, by anyone in the channel, acceptable.
  364. # [14:43] <shepazu> why?
  365. # [14:43] <shepazu> that's not clear a priori
  366. # [14:44] <zcorpan> s/group/channel/
  367. # [14:44] <shepazu> the interesting thing for me the the different expectations of privacy... maybe a generational thing, or cultural?
  368. # [14:45] <Lachy> for me, public == public, not "public, but with secrets we need to hide"
  369. # [14:46] <shepazu> I was talking about this with friends, and the general sentiment was that private logging was one thing, but publishing logs (esp. when it's not absolutely clear that it's being logged) was invasive and rude
  370. # [14:47] <Lachy> if the topic includes a clear statement about their being public logs, there is no problem
  371. # [14:48] <shepazu> well, that's open to individual judgment... clearly, that's your view... but others might not thing so
  372. # [14:48] <shepazu> Lachy: every big company has secrets... why doesn't Hixie publish his Google research, for example?
  373. # [14:48] <Philip`> I think I gave up on the idea that my conversations should be unpublished by default when I realised that newsgroup posts from when I was 11 have been archived forever, so anything I say now shouldn't embarrass me more than anything I've said before :-)
  374. # [14:48] <shepazu> because he can't, legally
  375. # [14:48] <shepazu> Philip`: yeah, that's why I think it's a generational thing
  376. # [14:49] <gDashiva> So all the talk about being 'open' is just hand waving
  377. # [14:49] <shepazu> those of us who grew up before the Web tend to be a little more sensitive to privacy
  378. # [14:50] <Philip`> shepazu: He hasn't given details of his research to anyone outside Google, as far as I'm aware, which is quite different to giving details to a select group of people who have a higher status than all the other members of the public group
  379. # [14:50] <zcorpan> shepazu: if Hixie doesn't want to publish hsi research then he wouldn't paste the results in a public channel
  380. # [14:51] <shepazu> I'm just saying that "open" isn't black and white
  381. # [14:52] <shepazu> zcorpan: then without his raw research, we just have to trust that he is correct and giving the whole picture... that's a complex issue, too
  382. # [14:52] <Lachy> shepazu, there's a difference between choosing not to make something public, or saying it in a public channel and expecting it to be hidden
  383. # [14:53] <shepazu> yeah, but it's no more "ethical" to hide information than it is to reveal it to a select group, and it's no more pragmatic for the group's functioning
  384. # [14:54] * Quits: annevk2 (n=annevk@0x573ffcee.boanqu1.broadband.tele.dk) (Read error: 110 (Connection timed out))
  385. # [14:55] <zcorpan> shepazu: indeed -- one way to verify his results would be to do an independent research and comparing the results
  386. # [14:55] <Philip`> shepazu: I would possibly view "open" as meaning that anyone can participate as equally as possible, which means all relevant information (like past discussions) needs to be made available to anyone - otherwise it would unfairly favour the closed group of people who are already members and have exclusive access to certain information
  387. # [14:56] <Philip`> But I might realise that's the wrong way to view things :-)
  388. # [14:57] * Quits: excrypf (n=nogah@58.187.95.189) ("Leaving.")
  389. # [14:57] <gDashiva> Maybe WCAG2 redefined open while they were making up all those funny terms
  390. # [14:57] <shepazu> Philip`: in a way, WHATWG is not open in this sense, because in order to come up to speed on 4 years of history and discussion, it would be a major undertaking... obscurity through profusion :)
  391. # [14:58] <Lachy> shepazu, wtf?
  392. # [14:59] <zcorpan> shepazu: how do you suggest to make it easier to come up to speed?
  393. # [14:59] <Philip`> shepazu: That problem seems to often occur in open source projects too - they can be technically open, in that you can see the code and bug reports and mailing lists and everything, but it can be far too hard for anybody to enter the group because it's too large and complex and poorly documented
  394. # [14:59] <Lachy> that's like the public library isn't open because it would be a major undertaking to read all the books in there.
  395. # [14:59] <shepazu> Philip`: yeah, same sort of thing
  396. # [14:59] <shepazu> zcorpan: dunno... it's a hard problem
  397. # [14:59] <Lachy> s/like/like saying/
  398. # [15:00] <shepazu> I'm not ascribing blame or anything, just observing... openness is relative
  399. # [15:00] <Philip`> whereas other projects do provide good documentation, and tell you exactly how to check out the code and install dependencies and build and write simple patches and cope with the processes for filing bugs and committing code and whatever, which makes them much more open in the practical sense
  400. # [15:00] <shepazu> in a very real and pragmatic sense
  401. # [15:02] <gDashiva> There's a very important difference between something being naturally unopen (like a huge library) and intentionally closing down something that was open before (like moving your telcon)
  402. # [15:03] <hsivonen> shepazu: what does Hixie's research at Google have to do with WG openness?
  403. # [15:03] <jgraham_> Regardless of whether perfect openess is a viable goal, I still can't understand how people could object to logs of a *public* channel
  404. # [15:03] <Philip`> shepazu: In the WHATWG, I think it's quite possible to come up to speed quickly if you focus on a single component - most of the years of discussion are about all the other components and so you can ignore them entirely
  405. # [15:03] <hsivonen> shepazu: isn't it pretty clear that Hixie's research isn't 'open' and only the aggregate results or even just conclusions are disclosed?
  406. # [15:03] <Philip`> (At least that's what I did, by just looking at canvas stuff and ignoring everything else)
  407. # [15:04] <Philip`> (and then searching the mailing list and IRC logs for all previous discussions of it, which didn't take long)
  408. # [15:04] <shepazu> one reason the SVG WG has not been as quick as we'd have liked with the SVG-in-text/html thing is that we are busy with other things, but another major hurdle is that Hixie has constructed a complex and intricate set of criteria for HTML5 parsing and such, and it's taken us a while to grok it
  409. # [15:04] <shepazu> hsivonen: yes, that is absolutely clear :)
  410. # [15:05] <shepazu> Philip`: if I weren't busy with a ton of other things, that would be easier
  411. # [15:06] <Philip`> I suppose parsing is one of the least good components to focus on, since it's big and complex and has had loads of past discussion
  412. # [15:07] <shepazu> hsivonen: I'm just saying that no matter how "open" a group is, there are still secrets and hidden agendas among the parties... open minutes is actually not the hardest part of that problem
  413. # [15:07] <shepazu> Philip`: indeed :(
  414. # [15:07] <shepazu> and the rationales for things aren't always clear from the spec
  415. # [15:07] <Philip`> On the other hand, there's multiple people who generally understand it already and would be happy to respond to questions
  416. # [15:08] <Philip`> which is better than for most other features
  417. # [15:08] <hsivonen> shepazu: yeah, but I don't see how being secretive about the minutes helps, particularly if the group claims to do its work in public
  418. # [15:08] <shepazu> Philip`: yeah, lots of people are forthcoming, but sometimes facing the whole channel is not helpful...
  419. # [15:08] <shepazu> hsivonen: I understand what you're saying
  420. # [15:10] <Philip`> shepazu: Are the rationales for things *ever* clear from the spec? :-)
  421. # [15:10] <Philip`> A hundred years from now, most of the WHATWG members will be dead and nobody will be able to understand the reasoning behind the HTML5 spec and there will be nobody to explain it
  422. # [15:13] <shepazu> Philip`: that's one reason that good spec support documentation is important... also to "check your work"
  423. # [15:14] <zcorpan> Philip`: it seems reasonable to assume that there will be new people joining the work before we die
  424. # [15:14] <zcorpan> it's not like we're a fixed set of people and we need replacements when we die :)
  425. # [15:15] <jgraham_> The problem is that documenting everything that went in to forming a conclusion is orders of magnitude harder than just documenting the results. A certian amount of expediency is needed to make our work relevant
  426. # [15:15] <Philip`> zcorpan: The existing members won't perfectly transfer all their institutional memory to new members, so things will be forgotten and then will be lost forever since everyone was too lazy to write them down
  427. # [15:16] <shepazu> jgraham_: yeah, it's a balancing act
  428. # [15:19] <jgraham_> (I once read something by some sientists who suggested a "new method" for documenting code which was basically a chronology of all the design decisions that they tried and why they worked or didn't. In principle it sounds great, but the project they tried it on ended up with something like 800 pages of text most of which wasn't useul in figuring out how the end product worked)
  429. # [15:20] <jgraham_> s/sientists/scientists/
  430. # [15:21] <hsivonen> shepazu: are there examples of other WGs working on large specs and documenting the design rationale on the level you'd like to see in HTML5?
  431. # [15:22] <Philip`> I think things like "Authors should not use JIS_X0212-1990, x-JIS0208, and encodings based on EBCDIC." are unpleasantly far from the balance - it should at least say they're discouraged because they are not ASCII compatible and so can result in security vulnerabilities when accidentally decoded ASCII-compatibly, or something like that
  432. # [15:23] <shepazu> hsivonen: yes and no... first, let me say that I'm not talking about documenting the entire design rationale, just key points that aren't obvious... right now, the spec is proscriptive, and not very descriptive
  433. # [15:23] <Philip`> and like "If the charset attribute is specified, the element must be the first element in the head element of the file." where it can say that that's to avoid problems where it has to parse text before it's reached the charset element, or something like that
  434. # [15:23] <shepazu> Philip`: exactly
  435. # [15:25] <shepazu> the SVG WG, having almost completely new participants, have seen how earlier rationales were lost with the old members, and have to sometimes backwards-engineer the spec... so we've taken to recording Resolutions and Rationales in our minutes, so we can have a short summary of why we decided particularly unintuitive or obscure things
  436. # [15:26] <shepazu> we're not perfect at it, but it's not been bad, and it does help
  437. # [15:26] <shepazu> then again, we operate as a group, not as a single editor... so I'm not sure it would work for HTML5
  438. # [15:26] <Philip`> It seems the primary difficulty is getting someone to actually do the work
  439. # [15:27] <shepazu> but it does mean that most of us also understand pretty much most of the stuff we decide at a good level
  440. # [15:27] <shepazu> Philip`: you said it
  441. # [15:28] <shepazu> hard work, takes a certain set of aptitudes
  442. # [15:28] <shepazu> broad vision and strict attention to details
  443. # [15:28] <Philip`> particularly since this is not a group that will try to force people to do things they don't particularly want to
  444. # [15:29] <shepazu> Philip`: luckily for y'all, you have a huge worker base...
  445. # [15:29] <Philip`> shepazu: The number of participants doesn't help when 0% want to do the work :-)
  446. # [15:31] <shepazu> Philip`: at least it's not negative :)
  447. # [15:35] * hsivonen is getting close to fixing everything that has regressed in the parser since last release
  448. # [15:50] <Philip`> If browsers implement worker threads, will they be actual real threads, so people can fully utilise quad-core CPUs to compute Mandelbrot fractals in JavaScript?
  449. # [15:58] * Quits: jgraham_ (n=jgraham@xpc9.ast.cam.ac.uk) ("leaving")
  450. # [16:07] * Joins: smedero (n=smedero@mdp-nat251.mdp.com)
  451. # [16:08] * Joins: aroben (n=aroben@unaffiliated/aroben)
  452. # [16:24] * Joins: billmason (n=billmaso@ip192.unival.com)
  453. # [16:29] * Quits: timely (n=timeless@a88-115-13-211.elisa-laajakaista.fi) (Read error: 110 (Connection timed out))
  454. # [16:30] * Joins: annevk2 (n=annevk@0x5da33d22.boanqu1.broadband.tele.dk)
  455. # [16:31] * annevk2 is now known as annevk
  456. # [16:36] * Quits: scotfl (n=scotfl@S0106001b114f914a.ss.shawcable.net) (Read error: 110 (Connection timed out))
  457. # [16:38] * Joins: excrypf (n=nogah@58.187.95.189)
  458. # [16:51] * Quits: aaronlev (n=chatzill@e176255090.adsl.alicedsl.de) ("ChatZilla 0.9.83 [Firefox 3.0/2008052906]")
  459. # [16:53] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
  460. # [16:55] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) ("Verlassend")
  461. # [17:04] * Parts: excrypf (n=nogah@58.187.95.189)
  462. # [17:09] * Joins: Lachy (n=Lachlan@85.196.122.246)
  463. # [17:09] * Joins: eseidel (n=eseidel@72.14.228.1)
  464. # [17:22] * Quits: annevk (n=annevk@0x5da33d22.boanqu1.broadband.tele.dk) (Remote closed the connection)
  465. # [17:24] * Joins: hober (n=ted@unaffiliated/hober)
  466. # [17:30] * Joins: qwert666_ (n=qwert666@dal75.neoplus.adsl.tpnet.pl)
  467. # [17:34] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  468. # [17:41] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  469. # [17:42] <hsivonen> http://lists.w3.org/Archives/Public/www-html/2008Jun/0047.html
  470. # [17:45] * Quits: myakura (n=myakura@p1216-ipbf601marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  471. # [17:46] <zcorpan> getElementsByName doesn't match <sup name>
  472. # [17:46] * Quits: qwert666 (n=qwert666@acdg125.neoplus.adsl.tpnet.pl) (Read error: 110 (Connection timed out))
  473. # [17:46] <hsivonen> http://lists.w3.org/Archives/Public/www-html/2008Jun/0061.html
  474. # [17:53] <gsnedders> Is there any documentation of any de-facto standards for tag parsing?
  475. # [17:53] <hsivonen> gsnedders: tag like etag?
  476. # [17:53] <gsnedders> hsivonen: Like Flickr's tags
  477. # [17:54] <hsivonen> gsnedders: I don't know. What else do you need except splitting on colon?
  478. # [17:54] <hsivonen> gsnedders: or do you want to implment UI input consistently with Flickr?
  479. # [17:54] <gsnedders> hsivonen: Well, what happens with stuff like "foobar" lol, "meep"
  480. # [17:55] <hsivonen> ah, you mean parsing the input field
  481. # [17:55] <gsnedders> yeah
  482. # [18:09] * Joins: aroben (n=aroben@unaffiliated/aroben)
  483. # [18:12] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  484. # [18:14] * Joins: hasather (n=hasather@ti0034a380-2730.bb.online.no)
  485. # [18:15] * Quits: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net) ("The computer fell asleep")
  486. # [18:17] * Joins: weinig (n=weinig@17.203.15.145)
  487. # [18:37] * Quits: zcorpan (n=zcorpan@pat-tdc.opera.com) (Read error: 104 (Connection reset by peer))
  488. # [18:39] * Joins: zcorpan (n=zcorpan@pat-tdc.opera.com)
  489. # [18:42] * Joins: jgraham_ (n=jgraham@xpc9.ast.cam.ac.uk)
  490. # [18:49] * Quits: eseidel (n=eseidel@72.14.228.1)
  491. # [18:50] * Joins: arun_ (n=arun@adsl-75-36-186-239.dsl.pltn13.sbcglobal.net)
  492. # [18:50] * Joins: eseidel (n=eseidel@72.14.228.1)
  493. # [18:59] * Quits: zcorpan (n=zcorpan@pat-tdc.opera.com)
  494. # [19:00] * Parts: arun_ (n=arun@adsl-75-36-186-239.dsl.pltn13.sbcglobal.net)
  495. # [19:01] * Joins: aaronlev (n=chatzill@e176255090.adsl.alicedsl.de)
  496. # [19:02] <takkaria> heh, one of the CS lecturers from my university is telling Hixie he's wrong in the URL thread
  497. # [19:02] <Philip`> I think everybody is telling Hixie he's wrong in the UR[IL] thread
  498. # [19:03] * Joins: zcorpan (n=zcorpan@pat-tdc.opera.com)
  499. # [19:03] <gsnedders> Philip`: no, IRL!
  500. # [19:04] <Philip`> Sorry, the internet has already found a use for that TLA
  501. # [19:04] <gsnedders> IRI then?
  502. # [19:06] <takkaria> oh, Roy Fielding jumped in, awesome
  503. # [19:08] <takkaria> I don't know how that thread has gone on so long given that Hixie has said a few times that he'll just write the rules in HTML5 and be done with it
  504. # [19:09] * Quits: zcorpan (n=zcorpan@pat-tdc.opera.com)
  505. # [19:20] * Quits: eseidel (n=eseidel@72.14.228.1)
  506. # [19:21] * Joins: eseidel (n=eseidel@72.14.228.1)
  507. # [19:21] <hdh0> http://camendesign.com/?200805291052 wants a Fx3 extension to convert flash video to <video> playing with VLC
  508. # [19:22] * Joins: maikmerten (n=maikmert@Lb78c.l.pppool.de)
  509. # [19:24] * Joins: KevinMarks (n=KevinMar@nat/google/x-3dbabeb45706ff14)
  510. # [19:29] * Parts: hasather (n=hasather@ti0034a380-2730.bb.online.no)
  511. # [19:30] * Joins: hasather (n=hasather@ti0034a380-2730.bb.online.no)
  512. # [19:31] * Parts: hasather (n=hasather@ti0034a380-2730.bb.online.no)
  513. # [19:31] * Joins: hasather (n=hasather@ti0034a380-2730.bb.online.no)
  514. # [19:34] <gsnedders> does anyone have any stats about how common it is for optional tags to be omitted?
  515. # [19:35] * Quits: maikmerten (n=maikmert@Lb78c.l.pppool.de) (Remote closed the connection)
  516. # [19:42] * gsnedders bursts out laughing at a very well hidden joke in the HTML 5 parsing section
  517. # [19:43] <takkaria> which one's that?
  518. # [19:43] <gsnedders> takkaria: The sarcasm end tag
  519. # [19:44] <takkaria> ah :)
  520. # [19:44] <Philip`> gsnedders: No
  521. # [19:44] <gsnedders> I mean, just skimming over the spec, you'd never even see that
  522. # [19:45] * Joins: maikmerten (n=maikmert@Lb78c.l.pppool.de)
  523. # [19:49] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  524. # [19:50] * Joins: aroben (n=aroben@unaffiliated/aroben)
  525. # [19:52] <gsnedders> What supports the mid URI scheme?
  526. # [19:59] <takkaria> hsivonen: when processing tokens "using the rules for the secondary insertion mode", if something in the secondary insertion mode changes the insertion mode, should that change the insertion mode or the secondary insertion mode?
  527. # [20:00] <takkaria> er, Hixie, even ^^
  528. # [20:00] <takkaria> though I have a feeling either of you might know :)
  529. # [20:08] * Quits: ROBOd (n=robod@89.122.216.38) (Remote closed the connection)
  530. # [20:08] * Joins: ROBOd (n=robod@89.122.216.38)
  531. # [20:25] * Quits: webben (n=benh@nat/yahoo/x-c9b2f59959dd072b)
  532. # [20:35] <gsnedders> Philip`, jgraham: I'll be in Cam next Thurs – Tues, if you care :P
  533. # [20:37] <hsivonen> takkaria: using the rules of the secondary mode doesn't in itself take you out of 'in foreign'
  534. # [20:38] <hsivonen> takkaria: btw, modeling 'in foreign' as an insertion mode makes sense if you insertion mode is a function pointer as in Hixie's impl
  535. # [20:38] <hsivonen> takkaria: but if you insertion mode is a switch condition, modeling 'in foreign' as an insertion mode totally sucks
  536. # [20:38] <hsivonen> and having it as a separate flag is *much* better
  537. # [20:39] <takkaria> hmm
  538. # [20:39] <takkaria> atm I'm using a switch
  539. # [20:39] <hsivonen> takkaria: then I suggest doing what I do :-)
  540. # [20:39] <takkaria> I'm still not quite sure what happens, though, if you use the secondary insertion mode and something in there changes the insertion mode. it changes the real insertion mode, yeah, not the secondary insertion mode?
  541. # [20:40] <hsivonen> having an 'in foreign' flag and a mode variable for the rest of the modes
  542. # [20:40] <hsivonen> and when the 'in foreign' flag is set, your usual mode variable is the secondary mode
  543. # [20:42] <hsivonen> takkaria: hmm. I don't think end tag processing can change the secondary mode without the rules also causing an exit from foreign content anyway
  544. # [20:42] <hsivonen> but now I'm not 100% sure
  545. # [20:42] <hsivonen> but that has been my assumption
  546. # [20:43] <takkaria> mm, I'm going with your assumption I think
  547. # [20:44] * Joins: eseidel_ (n=eseidel@c-24-118-134-245.hsd1.mn.comcast.net)
  548. # [20:46] * Joins: eseidel__ (n=eseidel@72.14.228.1)
  549. # [20:47] * Joins: jacobolus (n=jacobolu@ip-12-22-56-126.hqglobal.net)
  550. # [20:53] * Joins: webben (n=benh@nat/yahoo/x-4f9eb39f8248ca79)
  551. # [20:54] * Quits: webben (n=benh@nat/yahoo/x-4f9eb39f8248ca79) (Client Quit)
  552. # [20:58] <takkaria> hsivonen: ah, you switch first on token type and then on state, hubbub does it the other way round
  553. # [21:02] * Quits: eseidel_ (n=eseidel@c-24-118-134-245.hsd1.mn.comcast.net) (Read error: 110 (Connection timed out))
  554. # [21:02] <hsivonen> takkaria: token-major switches allow nice fall-throughs
  555. # [21:02] * Quits: maikmerten (n=maikmert@Lb78c.l.pppool.de) (Remote closed the connection)
  556. # [21:03] <hsivonen> (or, well, token-major callbacks)
  557. # [21:04] <takkaria> mm, that does seem to be the case
  558. # [21:05] <takkaria> ah well, I'm not changing hubbub now. :)
  559. # [21:08] <takkaria> I think that I can possibly implement the "in foreign" state as just calling the token handler again from inside itself
  560. # [21:11] * Quits: eseidel (n=eseidel@72.14.228.1) (Read error: 110 (Connection timed out))
  561. # [21:12] * Quits: eseidel__ (n=eseidel@72.14.228.1)
  562. # [21:13] * Joins: itpastorn (n=itpastor@139.57.227.87.static.th.siw.siwnet.net)
  563. # [21:25] * Quits: jgraham_ (n=jgraham@xpc9.ast.cam.ac.uk) ("leaving")
  564. # [21:33] * Joins: webben (n=benh@nat/yahoo/x-07b2b729c2258068)
  565. # [21:46] <hsivonen> mrbkap: I updated http://parsetree.validator.nu/ to run the latest version of the parser
  566. # [21:49] <Philip`> hsivonen: No changes in comment parsing, I assume?
  567. # [21:50] <hsivonen> Philip`: I don't remember how old the previous deployment was, but it predated all the SVG and MathML work
  568. # [21:50] <hsivonen> Philip`: but most likely there haven't been comment parsing changes in that timeframe
  569. # [21:50] <Philip`> hsivonen: It'd be really nice if something like http://parsetree.validator.nu/?content=%3Ctest%3E worked
  570. # [21:50] <gsnedders> Philip`: I assume you don't care then :P
  571. # [21:52] <Philip`> gsnedders: I don't not care - I just assimilated the knowledge and didn't see a useful way to respond and then continued with the rest of my life :-)
  572. # [21:53] <Philip`> (unless it's not obvious that I'll be here over that time period too, in which case it may be useful for me to say so)
  573. # [21:54] <hsivonen> Philip`: perhaps tomorrow
  574. # [22:00] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  575. # [22:02] * Quits: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  576. # [22:02] * hsivonen wonders if <time> is principle-violating: http://twitter.com/t/statuses/843458747
  577. # [22:06] <Philip`> It violates the principle of being valid HTML4 / XHTML1
  578. # [22:06] <hsivonen> HTML4/XHTML1 validatity is overrated :-)
  579. # [22:07] <hsivonen> validity even
  580. # [22:09] <Philip`> Can you make <time> validate by sticking stuff in the DTD, or will that result in ugly "]>" stuff being rendered?
  581. # [22:10] <Lachy> Philip`, you have to create your own external DTD and use <!DOCTYPE html SYSTEM "htttp://.../my.dtd">
  582. # [22:11] <hsivonen> Philip`: you could put stuff in an external DTD, but DTDs are overrated and passé
  583. # [22:15] <hsivonen> is the microformats community opposed to encoding variable values as classes?
  584. # [22:15] * gsnedders commits with the message 'Bye-bye my dear "nymphet".'
  585. # [22:16] <gsnedders> (what is in that commit? hmm… who knows.)
  586. # [22:23] * hsivonen also notes http://twitter.com/t/statuses/843517093
  587. # [22:27] * hsivonen thinks the abbr design pattern is more of an anti-pattern than putting variable data in class...
  588. # [22:28] * gsnedders thinks it is less of an anti-pattern, but only marginally
  589. # [22:28] * Joins: aaronlev_ (n=chatzill@e176255090.adsl.alicedsl.de)
  590. # [22:29] <hsivonen> the abbr design pattern would suck less it they replaced 'T' with ' ' and didn't put a non-Z TZD in there
  591. # [22:29] <hober> I think it depends on usage. <abbr title="2008-06-26">6/26</abbr> is one thing--<abbr title="2008-06-26T12:24:00-07:00">1 hour ago</abbr> is something else entirely.
  592. # [22:30] <hsivonen> yeah
  593. # [22:30] <gsnedders> <time> ftw!
  594. # [22:30] <hober> I really like the recent datetime-design-pattern work
  595. # [22:30] <itpastorn> It's modeled on vCard and therefore there is a "T"
  596. # [22:33] <gsnedders> ISO8601:2004 makes the T optional if agreed by both parties
  597. # [22:35] * Quits: aaronlev (n=chatzill@e176255090.adsl.alicedsl.de) (Read error: 110 (Connection timed out))
  598. # [22:38] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  599. # [22:40] <itpastorn> And what would the other "party" be on the web that i am supposed to agrre with?
  600. # [22:40] <itpastorn> agree
  601. # [22:43] <gsnedders> The party who creates the date and the party who consumes the date, so in this case it would be agreed through the spec
  602. # [22:46] <itpastorn> My point is that there already are quite a few parsers on the market already. How would a spec change now work? There are many who would need to alter their apps.
  603. # [22:46] * Quits: aroben (n=aroben@unaffiliated/aroben) ("Leaving")
  604. # [22:47] * Joins: aroben (n=aroben@c-71-58-56-76.hsd1.pa.comcast.net)
  605. # [22:47] <jgraham> gsnedders: I assume you will also be in Cambridge even if I don't care :)
  606. # [22:47] <gsnedders> jgraham: s
  607. # [22:47] <gsnedders> or, if I don't press return accidentally…
  608. # [22:48] <gsnedders> seeming I have a train ticket down on the Wed evening, and a plane from STD on Tues…
  609. # [22:48] <jgraham> I'm away from Fri evening to Sun evening
  610. # [22:49] <Philip`> itpastorn: There's a party on the web? Nobody invited me :-(
  611. # [22:51] <gsnedders> itpastorn: Well, µf aren't really used enough to make such a change impossible
  612. # [22:53] <itpastorn> Yes, I actually agree. just wanted to play the devils adcocate....
  613. # [22:54] * Quits: KevinMarks (n=KevinMar@nat/google/x-3dbabeb45706ff14) ("The computer fell asleep")
  614. # [22:55] <itpastorn> The party is in Spain (3-0 over Russia)
  615. # [23:04] * Quits: aroben (n=aroben@unaffiliated/aroben)
  616. # [23:04] * Joins: KevinMarks (n=KevinMar@nat/google/x-a93228c2d4bc8fb9)
  617. # [23:04] * Joins: aroben (n=aroben@unaffiliated/aroben)
  618. # [23:10] <krijnh> shepazu, Lachy: the [off] thing works in #webapps
  619. # [23:10] <krijnh> Lachy: should I join #waf as well? ;)
  620. # [23:10] <gsnedders> itpastorn: (if we were talking about HTML, then I'd say it was impossible)
  621. # [23:10] * Joins: roc (n=roc@202.0.36.64)
  622. # [23:11] <krijnh> Lachy: And I'm not logging the channel atm
  623. # [23:11] <Lachy> krijnh, no. The whole point of them moving the telcon to #waf was to avoid being in your logs
  624. # [23:11] <krijnh> Yeah, I read that :)
  625. # [23:11] <mrbkap> hsivonen: Cool, thanks.
  626. # [23:15] * Joins: eseidel (n=eseidel@c-24-118-134-245.hsd1.mn.comcast.net)
  627. # [23:16] * Joins: eseidel_ (n=eseidel@72.14.228.1)
  628. # [23:16] <krijnh> Left #webapps, cause it's not my intention to be a PITA :) If people don't want logs, that's fine by me
  629. # [23:16] <krijnh> Nn everybody
  630. # [23:27] * Joins: jruderman (n=jruderma@ip68-5-179-249.oc.oc.cox.net)
  631. # [23:28] * Philip` wonders how long it's likely to take to build Firefox from Mercurial
  632. # [23:29] <roc> depends entlrely on hardware and OS
  633. # [23:30] <roc> fast dual-core Linux machine with 1GB of RAM: 20 minutes
  634. # [23:30] * Quits: kingryan_ (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  635. # [23:30] <roc> slow single-core Windows machine with 256MB RAM: all week
  636. # [23:31] * Joins: kingryan (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net)
  637. # [23:31] <Philip`> I have 2.0GHz C2D / 2GB / Linux, and I started 20 minutes ago, so hopefully that means it won't take much longer :-)
  638. # [23:31] <jcranmer> Philip`: which directory is it building ATM?
  639. # [23:31] <Philip`> jcranmer: /home/philip/mozilla/mozilla/src/security/manager/ssl/src/nsPSMBackgroundThread.cpp
  640. # [23:32] <jcranmer> ah, you're nearly done then
  641. # [23:33] <jcranmer> I remember building on a machine with 256 MB as it agonized through libxul... happy days now
  642. # [23:33] * Quits: eseidel (n=eseidel@c-24-118-134-245.hsd1.mn.comcast.net) (Read error: 110 (Connection timed out))
  643. # [23:33] <roc> yeah, the security module is the home stretch
  644. # [23:33] <Philip`> Oh, it's done
  645. # [23:34] <Philip`> 24 minutes
  646. # [23:36] <Philip`> Hooray, canvas text
  647. # [23:37] <Philip`> which changes size when you change the browser's text size :-(
  648. # [23:38] <Philip`> which means it's impossible to get predictable layouts
  649. # [23:40] * Joins: othermaciej (n=mjs@17.203.15.160)
  650. # [23:40] <roc> that sounds like a bug
  651. # [23:41] <roc> file it. we have code in SVG to prevent that.
  652. # Session Close: Fri Jun 27 00:00:00 2008

The end :)