/irc-logs / freenode / #whatwg / 2009-07-17 / end

Options:

  1. # Session Start: Fri Jul 17 00:00:00 2009
  2. # Session Ident: #whatwg
  3. # [00:01] * Quits: mat_t_ (n=mattomas@ppp-3-250.glou-b-1.access.uk.tiscali.com) ("This computer has gone to sleep")
  4. # [00:02] * Joins: yshin (n=yshin@72.14.227.1)
  5. # [00:04] <MikeSmith> Hixie: do that and <footer> will lose any real distinction from <section> except in name
  6. # [00:04] <MikeSmith> same content model, just different name
  7. # [00:04] <MikeSmith> maybe that's what people actually want
  8. # [00:05] * Joins: jacobolus (n=jacobolu@adsl-75-36-158-29.dsl.pltn13.sbcglobal.net)
  9. # [00:06] <ezyang> you would think that footer would be fairly unambiguous
  10. # [00:07] <MikeSmith> ezyang: people use the same names for different things
  11. # [00:07] <Hixie> MikeSmith: <section> is in the outline, that's the big difference
  12. # [00:07] <MikeSmith> it seems like the general pattern that's may be emerging is that trying to be helpfully prescriptive in the spec about constraints on the content models of the structural elements is, in practice, maybe not going to be helpful
  13. # [00:07] <ezyang> Yeah, though I thought the web design community had formed a consensus on the design pattern of the "header" and the "footer"
  14. # [00:07] <MikeSmith> Hixie: can you imagine that somebody might next ask, why is footer not in the outline algorithm?
  15. # [00:08] <Hixie> MikeSmith: they haven't asked that for <header>
  16. # [00:08] <Hixie> basically this would make <header> and <footer> symmetric
  17. # [00:08] <MikeSmith> ezyang: I don't think the web design community has formed a consensus on anything. any single thing.
  18. # [00:08] <ezyang> :-/ Very possible.
  19. # [00:08] <MikeSmith> Hixie: symmetry is good. it makes things simpler for people
  20. # [00:09] <MikeSmith> ezyang: and Web designers may have different notions of what a footer is than, say, people who design outline algorithms
  21. # [00:10] * Joins: yshin_ (n=yshin@72.14.227.1)
  22. # [00:10] <ezyang> I'm pretty sure they don't think footers go in outline algorithms.
  23. # [00:11] * Joins: mat_t (n=mattomas@ppp-3-250.glou-b-1.access.uk.tiscali.com)
  24. # [00:11] <MikeSmith> ezyang: I'm pretty sure some don't know what an outline algorithm is, and might not even care if they did know.
  25. # [00:11] * Quits: yshin (n=yshin@72.14.227.1) (Success)
  26. # [00:11] <ezyang> "semantics"
  27. # [00:12] <hober> consider the site footer here: http://www.powazek.com/2005/09/000537.html
  28. # [00:12] * MikeSmith looks
  29. # [00:12] <ezyang> Yeah. Totally not appropriate in the outline algo
  30. # [00:12] <hober> I can imagine the blog post above marked up in an <article>
  31. # [00:13] <hober> but I can imagine this footer as <footer><section><h2>The Fine Print</h2>...</section>...</footer>
  32. # [00:13] <MikeSmith> hober: to me, the footer is the just part that has derek (at) powazek (dot) com in the left column
  33. # [00:13] <MikeSmith> the Fine Print part is a sectin
  34. # [00:13] <MikeSmith> section
  35. # [00:13] * Quits: mat_t (n=mattomas@ppp-3-250.glou-b-1.access.uk.tiscali.com) (Client Quit)
  36. # [00:13] <MikeSmith> with navigational content
  37. # [00:14] <hober> from that article: "So new here is a wayfinding footer - the kind of stuff that's usually ignored in sidebars. Will it help people stay on the site and surf around? I don't know - you tell me."
  38. # [00:15] <hober> I'm not saying I disagree, MikeSmith, but I think that's the crux of the confusion. People think of different things when they think of footers.
  39. # [00:15] <hober> I can imagine Derek's footer (the big one) participating in *the page*'s outline
  40. # [00:15] <hober> but not *the article*'s outline
  41. # [00:17] <MikeSmith> hober: agreed that it's clear people think of different things
  42. # [00:17] * Quits: jianli (n=jianli@72.14.227.1)
  43. # [00:17] <MikeSmith> i'd suspect most people would call that a footer
  44. # [00:18] <MikeSmith> to me, it could just as well be a nav
  45. # [00:18] * Joins: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
  46. # [00:19] <MikeSmith> the physical placement of that content in the footer seems to me arbitrary
  47. # [00:19] <MikeSmith> at the footer of the page, I mean
  48. # [00:20] <MikeSmith> it could be presented as a pop-up
  49. # [00:21] <MikeSmith> I guess I would myself tend to think of footer content as something that makes the most sense at the end of the document flow
  50. # [00:22] <MikeSmith> like the stuff that comes at the very end of a movie
  51. # [00:22] <MikeSmith> not the full credits that roll by
  52. # [00:22] <MikeSmith> but just the last frame
  53. # [00:28] * Parts: billmason (n=billmaso@ip120.unival.com)
  54. # [00:37] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  55. # [00:48] * Quits: drostie (n=hopkins@5ED17066.cable.ziggo.nl) ("even marathon runners need to nap / i ran all the way there and then ran back / but back was gone...")
  56. # [00:50] * Joins: ttepass- (n=ttepas--@p5B014A2C.dip.t-dialin.net)
  57. # [00:56] * Joins: aboodman2 (n=aboodman@72.14.229.81)
  58. # [01:04] * Quits: bgalbraith (n=bgalbrai@nat/mozilla/x-ba82f9150e30f90e)
  59. # [01:04] * Quits: aboodman (n=aboodman@72.14.229.81) (Read error: 110 (Connection timed out))
  60. # [01:04] * aboodman2 is now known as aboodman
  61. # [01:04] * Joins: T-- (n=ttepas--@p5B014F94.dip.t-dialin.net)
  62. # [01:05] * Joins: weinig_ (n=weinig@17.246.16.121)
  63. # [01:06] * Joins: bgalbraith (n=bgalbrai@nat/mozilla/x-e15c67abd83a6bc2)
  64. # [01:06] * Quits: webben (n=benh@217.12.14.240) (Read error: 110 (Connection timed out))
  65. # [01:07] * Joins: ap_ (n=ap@17.246.19.81)
  66. # [01:08] * Quits: ttepasse (n=ttepas--@p5B015D48.dip.t-dialin.net) (Read error: 110 (Connection timed out))
  67. # [01:09] * Joins: jianli (n=jianli@72.14.227.1)
  68. # [01:16] * Joins: ttepasse (n=ttepas--@p5B01602C.dip.t-dialin.net)
  69. # [01:17] * Joins: tantek (n=tantek@c-24-130-115-72.hsd1.ca.comcast.net)
  70. # [01:17] * Quits: weinig_ (n=weinig@17.246.16.121)
  71. # [01:17] * Quits: ttepass- (n=ttepas--@p5B014A2C.dip.t-dialin.net) (Read error: 110 (Connection timed out))
  72. # [01:21] * Quits: dbaron (n=dbaron@nat/mozilla/x-2fb7fbf94e43e33c) (Read error: 110 (Connection timed out))
  73. # [01:22] * Quits: weinig (n=weinig@nat/apple/x-a2e622d10287345c) (Read error: 110 (Connection timed out))
  74. # [01:23] * Quits: ap (n=ap@nat/apple/x-776de00be21b872d) (Read error: 110 (Connection timed out))
  75. # [01:23] * Joins: dbaron (n=dbaron@nat/mozilla/x-3b75e5810f6fd9ef)
  76. # [01:25] * Joins: dglazkov_ (n=dglazkov@nat/google/x-3eb26954b687f035)
  77. # [01:26] * Quits: dglazkov (n=dglazkov@nat/google/x-dcccb95d8e299da8) (Read error: 104 (Connection reset by peer))
  78. # [01:29] * Quits: T-- (n=ttepas--@p5B014F94.dip.t-dialin.net) (Read error: 110 (Connection timed out))
  79. # [01:53] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  80. # [01:55] * Quits: JoePeck (n=JoePeck@74.69.85.249) (Read error: 104 (Connection reset by peer))
  81. # [01:55] * Joins: JoePeck_ (n=JoePeck@cpe-74-69-85-249.rochester.res.rr.com)
  82. # [01:58] * Joins: jorlow (n=jorlow@nat/google/x-46732a89d1c28499)
  83. # [01:59] <Hixie> good god i hate the ietf process
  84. # [02:00] <Hixie> apparently there's some meeting going on so i can't upload new drafts
  85. # [02:00] <Hixie> it's amazing to me that the ietf explicitly _prevent_ progress during their meetings
  86. # [02:00] <Hixie> i mean, i know meetings aren't usually productive in the first place, but actually preventing progress is just stunning
  87. # [02:03] <MikeSmith> meetings in general can be pretty productive, even standards meetings sometimes
  88. # [02:03] * Quits: sebmarkbage (n=miranda@h-6-72.A146.priv.bahnhof.se) (Read error: 104 (Connection reset by peer))
  89. # [02:04] <MikeSmith> I had a boss at a previous job who tried to institute a "everybody stands" (no sitting) meeting policy
  90. # [02:04] <MikeSmith> to force everybody to actually focus on talking to each other and getting something done
  91. # [02:05] <MikeSmith> he also had a "no food at meetings" policy
  92. # [02:06] <MikeSmith> as far as other kinds of meetings, if you're doing direct product-dev work for real paying customers, it's pretty hard to avoid meetings
  93. # [02:06] <MikeSmith> though those meetings also aren't always productive. they're just necessary
  94. # [02:07] <MikeSmith> then there are "apology" meetings...
  95. # [02:07] <MikeSmith> maybe that's something more unique to Japan
  96. # [02:07] * Quits: heycam (n=cam@203-217-77-251.dyn.iinet.net.au) ("bye")
  97. # [02:08] * Joins: sebmarkbage (n=miranda@h-6-72.A146.priv.bahnhof.se)
  98. # [02:08] <MikeSmith> go to a meeting to "apologize" to customer for mistakes you actually did not make, but were in fact either the customer's fault or their hand-picked system integrator's fault
  99. # [02:09] <Philip`> If you admit mistakes, surely they'd sue you
  100. # [02:10] <MikeSmith> lawsuits are pretty rare in Japan
  101. # [02:10] <MikeSmith> actual contracts are kinda rare too
  102. # [02:11] <MikeSmith> at least in my limited experience (doing professional-services type customized product development)
  103. # [02:11] * Quits: dglazkov_ (n=dglazkov@nat/google/x-3eb26954b687f035) (Read error: 110 (Connection timed out))
  104. # [02:12] <MikeSmith> and even when customers do sign contracts, they feel free to ignore them if they want. or change the terms unilaterally
  105. # [02:12] <MikeSmith> when dealing with big companies here, you're pretty much at their mercy
  106. # [02:13] <MikeSmith> the threat of losing future business with them is enough to make you do what they say
  107. # [02:14] * Joins: taf2_ (n=taf2@98.218.77.43)
  108. # [02:14] <mookid> [13:37] <Philip`> If you encode the desired content-type in the URI, it's not possible for a general-purpose HTTP-processing device to understand what's the resource identifier and what's the content-type selector, because there's no standard for encoding that stuff in URIs
  109. # [02:15] * Quits: sayrer (n=sayrer@user-0cceh2r.cable.mindspring.com) (hubbard.freenode.net irc.freenode.net)
  110. # [02:15] * Quits: jorlow (n=jorlow@nat/google/x-46732a89d1c28499) (hubbard.freenode.net irc.freenode.net)
  111. # [02:15] * Quits: jianli (n=jianli@72.14.227.1) (hubbard.freenode.net irc.freenode.net)
  112. # [02:15] * Quits: shepazutoo (n=schepers@adsl-150-136-82.rmo.bellsouth.net) (hubbard.freenode.net irc.freenode.net)
  113. # [02:15] * Quits: Dashiva (i=Dashiva@m223j.studby.ntnu.no) (hubbard.freenode.net irc.freenode.net)
  114. # [02:15] * Quits: Rik|work (n=Rik|work@fw01d.skyrock.net) (hubbard.freenode.net irc.freenode.net)
  115. # [02:15] * Quits: hamaji (n=hamaji@220.109.219.244) (hubbard.freenode.net irc.freenode.net)
  116. # [02:15] * Quits: JohnResig (n=JohnResi@121.255.201.74.static.ey03.engineyard.com) (hubbard.freenode.net irc.freenode.net)
  117. # [02:15] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (hubbard.freenode.net irc.freenode.net)
  118. # [02:15] * Quits: eighty4 (n=eighty4@eighty4.se) (hubbard.freenode.net irc.freenode.net)
  119. # [02:15] * Quits: ndim (i=hun@moooo.n-dimensional.de) (hubbard.freenode.net irc.freenode.net)
  120. # [02:15] * Quits: sebmarkbage (n=miranda@h-6-72.A146.priv.bahnhof.se) (hubbard.freenode.net irc.freenode.net)
  121. # [02:15] * Quits: JoePeck_ (n=JoePeck@cpe-74-69-85-249.rochester.res.rr.com) (hubbard.freenode.net irc.freenode.net)
  122. # [02:15] * Quits: ap_ (n=ap@17.246.19.81) (hubbard.freenode.net irc.freenode.net)
  123. # [02:15] * Quits: bgalbraith (n=bgalbrai@nat/mozilla/x-e15c67abd83a6bc2) (hubbard.freenode.net irc.freenode.net)
  124. # [02:15] * Quits: roc (n=roc@203-97-204-82.dsl.clear.net.nz) (hubbard.freenode.net irc.freenode.net)
  125. # [02:15] * Quits: cying (n=cying@70.90.171.153) (hubbard.freenode.net irc.freenode.net)
  126. # [02:15] * Quits: jwalden (n=waldo@nat/mozilla/x-38a7b66dbbb37252) (hubbard.freenode.net irc.freenode.net)
  127. # [02:15] * Quits: dolske (n=dolske@nat/mozilla/x-adf072ca2300fd83) (hubbard.freenode.net irc.freenode.net)
  128. # [02:15] * Quits: riven (n=colin@pdpc/supporter/professional/riven) (hubbard.freenode.net irc.freenode.net)
  129. # [02:15] * Quits: tyoshino (n=tyoshino@220.109.219.244) (hubbard.freenode.net irc.freenode.net)
  130. # [02:15] * Quits: Khazou (n=khaz@xvm-5-189.ghst.net) (hubbard.freenode.net irc.freenode.net)
  131. # [02:15] * Quits: foolip (n=Philip@pat.se.opera.com) (hubbard.freenode.net irc.freenode.net)
  132. # [02:15] * Quits: gavin____ (n=gavin@CPE001346f5db49-CM0018c0db9a8a.cpe.net.cable.rogers.com) (hubbard.freenode.net irc.freenode.net)
  133. # [02:15] * Quits: karlcow (n=karl@nerval.la-grange.net) (hubbard.freenode.net irc.freenode.net)
  134. # [02:15] * Quits: Yudai (n=Yudai@p929c7b.kngwnt01.ap.so-net.ne.jp) (hubbard.freenode.net irc.freenode.net)
  135. # [02:15] * Quits: Hixie (i=ianh@trivini.no) (hubbard.freenode.net irc.freenode.net)
  136. # [02:15] * Quits: hendry (n=hendry@webvm.net) (hubbard.freenode.net irc.freenode.net)
  137. # [02:15] * Quits: ray (i=ray@ipv6.the.ug) (hubbard.freenode.net irc.freenode.net)
  138. # [02:15] * Quits: doublec (n=chris@li30-216.members.linode.com) (hubbard.freenode.net irc.freenode.net)
  139. # [02:15] <mookid> [13:38] <Hixie> Philip`: such a standard or convention could be easily established
  140. # [02:15] * Joins: sebmarkbage (n=miranda@h-6-72.A146.priv.bahnhof.se)
  141. # [02:15] * Joins: jorlow (n=jorlow@nat/google/x-46732a89d1c28499)
  142. # [02:15] * Joins: JoePeck_ (n=JoePeck@cpe-74-69-85-249.rochester.res.rr.com)
  143. # [02:15] * Joins: jianli (n=jianli@72.14.227.1)
  144. # [02:15] * Joins: ap_ (n=ap@17.246.19.81)
  145. # [02:15] * Joins: bgalbraith (n=bgalbrai@nat/mozilla/x-e15c67abd83a6bc2)
  146. # [02:15] * Joins: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
  147. # [02:15] * Joins: cying (n=cying@70.90.171.153)
  148. # [02:15] * Joins: jwalden (n=waldo@nat/mozilla/x-38a7b66dbbb37252)
  149. # [02:15] * Joins: shepazutoo (n=schepers@adsl-150-136-82.rmo.bellsouth.net)
  150. # [02:15] * Joins: dolske (n=dolske@nat/mozilla/x-adf072ca2300fd83)
  151. # [02:15] * Joins: sayrer (n=sayrer@user-0cceh2r.cable.mindspring.com)
  152. # [02:15] * Joins: riven (n=colin@pdpc/supporter/professional/riven)
  153. # [02:15] * Joins: Dashiva (i=Dashiva@m223j.studby.ntnu.no)
  154. # [02:15] * Joins: tyoshino (n=tyoshino@220.109.219.244)
  155. # [02:15] * Joins: foolip (n=Philip@pat.se.opera.com)
  156. # [02:15] * Joins: Khazou (n=khaz@xvm-5-189.ghst.net)
  157. # [02:15] * Joins: Rik|work (n=Rik|work@fw01d.skyrock.net)
  158. # [02:15] * Joins: hamaji (n=hamaji@220.109.219.244)
  159. # [02:15] * Joins: gavin____ (n=gavin@CPE001346f5db49-CM0018c0db9a8a.cpe.net.cable.rogers.com)
  160. # [02:15] * Joins: ray (i=ray@ipv6.the.ug)
  161. # [02:15] * Joins: karlcow (n=karl@nerval.la-grange.net)
  162. # [02:15] * Joins: JohnResig (n=JohnResi@121.255.201.74.static.ey03.engineyard.com)
  163. # [02:15] * Joins: Yudai (n=Yudai@p929c7b.kngwnt01.ap.so-net.ne.jp)
  164. # [02:15] * Joins: Hixie (i=ianh@trivini.no)
  165. # [02:15] * Joins: hendry (n=hendry@webvm.net)
  166. # [02:15] * Joins: ndim (i=hun@moooo.n-dimensional.de)
  167. # [02:15] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
  168. # [02:15] * Joins: eighty4 (n=eighty4@eighty4.se)
  169. # [02:15] * Joins: doublec (n=chris@li30-216.members.linode.com)
  170. # [02:16] <mookid> [13:40] <Philip`> Hixie: You couldn't establish it in a way that wouldn't conflict with other people not following that standard and perfectly legitimately happening to use the same magic URI query parameter or whatever the content-type thing is stored as
  171. # [02:17] <mookid> :)
  172. # [02:18] <Philip`> I have no idea what any of that means
  173. # [02:18] * Philip` should probably go to bed
  174. # [02:18] <Hixie> it was a reply to your comment last november: http://krijnhoetmer.nl/irc-logs/whatwg/20081120#l-432
  175. # [02:20] <Hixie> er i mean a reply to my comment last november: http://krijnhoetmer.nl/irc-logs/whatwg/20081120#l-424
  176. # [02:23] <mookid> hows the work on my accept attribute coming along Ian ?
  177. # [02:24] <mookid> I can't believe we're never going to get to use HTTP conneg
  178. # [02:25] * Quits: ap_ (n=ap@17.246.19.81) (Remote closed the connection)
  179. # [02:25] * Joins: weinig (n=weinig@nat/apple/x-8e5f23595e270fb0)
  180. # [02:25] * Joins: ap (n=ap@nat/apple/x-3eabc5aeb666fa01)
  181. # [02:26] <MikeSmith> anybody know anybody HTML5-savvy who's in Postsdam/Berlin or nearby and willing to do a presentation on HTML5 in October?
  182. # [02:27] * Quits: bgalbraith (n=bgalbrai@nat/mozilla/x-e15c67abd83a6bc2)
  183. # [02:28] <mookid> Hixie: are you open to bribery?
  184. # [02:30] <Hixie> yeah, but i'm expensive
  185. # [02:30] * Quits: dbaron (n=dbaron@nat/mozilla/x-3b75e5810f6fd9ef) ("8403864 bytes have been tenured, next gc will be global.")
  186. # [02:30] * Joins: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
  187. # [02:30] <ezyang> "Every man has his price. The trick is knowing how much."
  188. # [02:37] * Joins: weinig_ (n=weinig@17.246.16.121)
  189. # [02:38] <roc> how about blackmail and threats of violence?
  190. # [02:39] * Quits: weinig_ (n=weinig@17.246.16.121) (Read error: 104 (Connection reset by peer))
  191. # [02:39] * Joins: weinig_ (n=weinig@17.246.16.121)
  192. # [02:39] * Quits: weinig_ (n=weinig@17.246.16.121) (Remote closed the connection)
  193. # [02:39] <Hixie> roc: nope
  194. # [02:39] <MikeSmith> threats reminds me again of customers... "If you don't fix this bug, there will be no next project."
  195. # [02:39] <Hixie> roc: can't buy model trains with those
  196. # [02:40] * Joins: weinig_ (n=weinig@nat/apple/x-d2d3a0968a5db41e)
  197. # [02:40] <MikeSmith> heh
  198. # [02:40] <roc> sure would be a shame if something were to happen to those model trains
  199. # [02:40] * Quits: weinig (n=weinig@nat/apple/x-8e5f23595e270fb0) (Read error: 104 (Connection reset by peer))
  200. # [02:41] <Hixie> they're sadly all in boxes right now :-(
  201. # [02:41] <Hixie> don't have room to put up a lyout
  202. # [02:41] <MikeSmith> Hixie: did you know that Chaos Computer Club started out as a group of model-train otaku?
  203. # [02:46] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
  204. # [02:47] * Quits: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
  205. # [02:50] * Quits: taf2_ (n=taf2@98.218.77.43)
  206. # [03:00] * Joins: shepazu (n=schepers@adsl-150-136-82.rmo.bellsouth.net)
  207. # [03:02] * Quits: shepazutoo (n=schepers@adsl-150-136-82.rmo.bellsouth.net) (Read error: 60 (Operation timed out))
  208. # [03:04] * Joins: archtech (n=stanv@83.228.56.37)
  209. # [03:06] * Joins: auk (n=scott@cpe-75-83-19-98.socal.res.rr.com)
  210. # [03:08] * Quits: dave_levin (n=dave_lev@72.14.227.1)
  211. # [03:18] * Joins: taf2_ (n=taf2@98.218.77.43)
  212. # [03:26] * Joins: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
  213. # [03:38] * Quits: tantek (n=tantek@c-24-130-115-72.hsd1.ca.comcast.net)
  214. # [03:43] * Quits: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
  215. # [03:44] * Quits: cying (n=cying@70.90.171.153)
  216. # [03:46] * Joins: dave_levin (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net)
  217. # [03:46] * Quits: weinig_ (n=weinig@nat/apple/x-d2d3a0968a5db41e)
  218. # [03:54] * Quits: ZombieLoffe (n=e@unaffiliated/zombieloffe)
  219. # [03:58] * Quits: yshin_ (n=yshin@72.14.227.1)
  220. # [04:03] * Joins: jorlow_ (n=jorlow@nat/google/x-a2d661f034b38201)
  221. # [04:06] * Quits: jorlow (n=jorlow@nat/google/x-46732a89d1c28499) (Read error: 60 (Operation timed out))
  222. # [04:06] * Quits: jorlow_ (n=jorlow@nat/google/x-a2d661f034b38201) (Client Quit)
  223. # [04:08] * Joins: jorlow (n=jorlow@nat/google/x-4ed6d8973e7b2f9e)
  224. # [04:15] * Joins: annodomini (n=lambda@wikipedia/lambda)
  225. # [04:15] * Quits: ap (n=ap@nat/apple/x-3eabc5aeb666fa01)
  226. # [04:18] * Joins: weinig (n=weinig@nat/apple/x-c21fc3740d1eee72)
  227. # [04:31] * Parts: jacobolus (n=jacobolu@adsl-75-36-158-29.dsl.pltn13.sbcglobal.net)
  228. # [04:36] * Quits: taf2_ (n=taf2@98.218.77.43)
  229. # [04:42] * Quits: nessy (n=nessy@124-170-249-152.dyn.iinet.net.au) ("This computer has gone to sleep")
  230. # [04:43] * Joins: nessy (n=nessy@124-170-249-152.dyn.iinet.net.au)
  231. # [04:47] * Joins: dglazkov (n=dglazkov@c-67-188-3-204.hsd1.ca.comcast.net)
  232. # [04:52] * Quits: nessy (n=nessy@124-170-249-152.dyn.iinet.net.au) (Read error: 60 (Operation timed out))
  233. # [04:56] * Quits: jorlow (n=jorlow@nat/google/x-4ed6d8973e7b2f9e)
  234. # [05:01] * Joins: jorlow (n=jorlow@67.218.103.5)
  235. # [05:02] * Joins: jorlow_ (n=jorlow@72.14.224.1)
  236. # [05:07] * Quits: dglazkov (n=dglazkov@c-67-188-3-204.hsd1.ca.comcast.net)
  237. # [05:09] * Joins: coopy (n=pernilss@adsl-99-41-70-71.dsl.aus2tx.sbcglobal.net)
  238. # [05:09] <coopy> hello
  239. # [05:16] * Quits: MikeSmith (n=MikeSmit@EM114-48-159-180.pool.e-mobile.ne.jp) ("Tomorrow to fresh woods, and pastures new.")
  240. # [05:18] * Joins: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
  241. # [05:22] * Quits: jorlow (n=jorlow@67.218.103.5) (Read error: 110 (Connection timed out))
  242. # [05:30] * Quits: auk (n=scott@cpe-75-83-19-98.socal.res.rr.com) (Success)
  243. # [05:45] * Quits: jwalden (n=waldo@nat/mozilla/x-38a7b66dbbb37252) ("->home")
  244. # [05:46] * Quits: jorlow_ (n=jorlow@72.14.224.1)
  245. # [05:47] * Quits: coopy (n=pernilss@adsl-99-41-70-71.dsl.aus2tx.sbcglobal.net)
  246. # [05:56] * Joins: ap (n=ap@70-7-214-89.pools.spcsdns.net)
  247. # [06:03] * Quits: sgalineau (n=sylvaing@nat/microsoft/x-2cbc43fba2e4def8) (Read error: 110 (Connection timed out))
  248. # [06:05] * Joins: bgalbraith (n=bgalbrai@71.202.109.116)
  249. # [06:05] * Quits: bgalbraith (n=bgalbrai@71.202.109.116) (Remote closed the connection)
  250. # [06:06] * Joins: jwalden (n=waldo@c-98-248-40-206.hsd1.ca.comcast.net)
  251. # [06:13] * Quits: othermaciej (n=mjs@17.203.15.242)
  252. # [06:21] * Joins: cying (n=cying@adsl-75-41-114-136.dsl.pltn13.sbcglobal.net)
  253. # [06:24] * Joins: sgalineau (n=sylvaing@c-98-247-143-102.hsd1.wa.comcast.net)
  254. # [06:27] * Joins: ttepass- (n=ttepas--@p5B016430.dip.t-dialin.net)
  255. # [06:32] * Joins: T-- (n=ttepas--@p5B016356.dip.t-dialin.net)
  256. # [06:48] * Joins: nessy (n=nessy@124-170-249-152.dyn.iinet.net.au)
  257. # [06:51] * Quits: ttepasse (n=ttepas--@p5B01602C.dip.t-dialin.net) (Read error: 110 (Connection timed out))
  258. # [06:51] * Joins: ttepasse (n=ttepas--@91.1.97.250)
  259. # [06:56] * Quits: ttepasse (n=ttepas--@91.1.97.250) (Read error: 104 (Connection reset by peer))
  260. # [06:56] * Quits: ttepass- (n=ttepas--@p5B016430.dip.t-dialin.net) (Read error: 110 (Connection timed out))
  261. # [06:56] * Joins: tantek (n=tantek@70.36.139.128)
  262. # [07:04] * Quits: T-- (n=ttepas--@p5B016356.dip.t-dialin.net) (Read error: 110 (Connection timed out))
  263. # [07:12] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  264. # [07:12] * Quits: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
  265. # [07:23] * Joins: coopy (n=pernilss@99.41.70.71)
  266. # [07:24] * Joins: dave_levin_ (n=dave_lev@72.14.224.1)
  267. # [07:26] * Quits: dave_levin (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net) (Read error: 60 (Operation timed out))
  268. # [07:33] * Parts: coopy (n=pernilss@99.41.70.71)
  269. # [07:35] * Joins: auk (n=scott@cpe-75-83-19-98.socal.res.rr.com)
  270. # [07:39] * Joins: boblet (n=boblet@p2227-ipbfp4102osakakita.osaka.ocn.ne.jp)
  271. # [07:42] * Quits: weinig (n=weinig@nat/apple/x-c21fc3740d1eee72)
  272. # [07:43] * Quits: sayrer (n=sayrer@user-0cceh2r.cable.mindspring.com) (Read error: 110 (Connection timed out))
  273. # [08:02] * Quits: ap (n=ap@70-7-214-89.pools.spcsdns.net)
  274. # [08:08] * Joins: pauld (n=pauld@86.146.144.6)
  275. # [08:11] * Quits: sgalineau (n=sylvaing@c-98-247-143-102.hsd1.wa.comcast.net) (Read error: 110 (Connection timed out))
  276. # [08:12] * Joins: pesla (n=retep@procurios.xs4all.nl)
  277. # [08:18] * Joins: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  278. # [08:20] * Quits: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
  279. # [08:29] * dave_levin_ is now known as dave_levin
  280. # [08:33] * Quits: ukai (n=ukai@220.109.219.244) (Remote closed the connection)
  281. # [08:34] * Joins: ukai (n=ukai@220.109.219.244)
  282. # [08:38] * Joins: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl)
  283. # [08:50] * Joins: Mrmil (n=ut_ollie@77.236.204.8)
  284. # [08:51] * Joins: sayrer (n=sayrer@user-0cceh2r.cable.mindspring.com)
  285. # [09:00] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  286. # [09:04] * Quits: dolske (n=dolske@nat/mozilla/x-adf072ca2300fd83) (Read error: 110 (Connection timed out))
  287. # [09:10] * Quits: pauld (n=pauld@86.146.144.6)
  288. # [09:19] * Quits: tantek (n=tantek@70.36.139.128)
  289. # [09:19] * Joins: dolske (n=dolske@76.103.40.203)
  290. # [09:20] * Joins: tantek (n=tantek@c-76-126-175-28.hsd1.ca.comcast.net)
  291. # [09:20] * Joins: tantekc (n=tantek@70.36.139.128)
  292. # [09:27] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) ("bye")
  293. # [09:28] * Quits: auk (n=scott@cpe-75-83-19-98.socal.res.rr.com) ("Ex-Chat")
  294. # [09:30] * Quits: cying (n=cying@adsl-75-41-114-136.dsl.pltn13.sbcglobal.net)
  295. # [09:31] * Joins: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de)
  296. # [09:37] * Quits: tantek (n=tantek@c-76-126-175-28.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  297. # [09:40] <boblet> Hey all, can anyone tell me the WhatWG stance on role, either the ARIA or the ‘bestowing semantics’ variety?
  298. # [09:40] <takkaria> I'm not sure there is a WHATWG "stance" per se
  299. # [09:41] <Hixie> ARIA is scheduled to get merged into HTML5 whenever the ARIA group are done dealing with their last call comments adequately
  300. # [09:41] <Hixie> (er "merged" in the sense that it will be conforming to use ARIA in HTML5 - i don't expect to copy the text in verbatim or anything)
  301. # [09:41] <boblet> ok
  302. # [09:42] <Hixie> (i expect it'll just be a list of attributes, a list of constraints on when they can be used, and a reference to the ARIA author and implementor specs)
  303. # [09:42] <boblet> Hixie: any idea if that will be eg in time for October?
  304. # [09:42] <Hixie> no idea
  305. # [09:42] <tantekc> Hixie, what are your standards for "merged" in the sense of conforming to use and referencing external specs rather than copying the text in verbatim etc.?
  306. # [09:43] * tantekc is now known as tantek
  307. # [09:44] <Hixie> dunno, it hasn't come up before :-)
  308. # [09:45] <boblet> Hixie: what about the ‘using role for adding semantic meaning’ idea? I’m guessing there’s a reason for <nav> rather than <ul role="nvaigation">…
  309. # [09:47] <Hixie> how is it different to class=""?
  310. # [09:49] <boblet> I’m guessing because the semantic meanings are formally and officially defined, and that implementors then add support for these meanings where appropriate
  311. # [09:49] <Hixie> oh. then how is it different to elements?
  312. # [09:49] * Quits: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  313. # [09:51] <boblet> I guess because then the semantics can be applied to more than one element, depending on which one was most appropriate
  314. # [09:51] <Hixie> isn't that just like nesting?
  315. # [09:51] <Hixie> i don't really understand the problem this would solve
  316. # [09:53] * Joins: MikeSmith (n=MikeSmit@EM114-48-134-244.pool.e-mobile.ne.jp)
  317. # [09:54] <boblet> I’m personally happy with the whole new elements approach—I think it’s conceptually simpler to add a few new elements than use div with role (or class) for everything, and easier to teach. I’m trying to understand the difference between John Allsopp’s approach and adding new elements.
  318. # [09:56] <MikeSmith> one difference is it that elements can be further subclassed
  319. # [09:56] <boblet> It certainly seems like the Microformats approach has paid off in faster implementation for the problems they’ve addressed, so I can see the logic to role being more amenable to rapid changes vs adding new elements
  320. # [09:56] <boblet> hey Mike
  321. # [09:56] * Quits: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de) (Remote closed the connection)
  322. # [09:56] <MikeSmith> hey
  323. # [09:56] <boblet> by subclassed are you meaning with classes or with nesting?
  324. # [09:56] <tantek> boblet - indeed.
  325. # [09:57] <tantek> after the experience with microformats and the ability to assign *multiple* semantics to a single element, it's pretty clear to me that the one element = one tag = one meaning design of SGML/HTML/XML is fundamentally flawed.
  326. # [09:57] <MikeSmith> boblet: if you used <div class=section> for bunch of sections and then you want to to further distinguish between kinds of sections, you don't have a class attribute to use to subclass them any more
  327. # [09:57] <Hixie> boblet: depends what you're solving, but yes
  328. # [09:58] <Hixie> boblet: if we were designing a new markup language from scratch, this would be a good discussion to have :-)
  329. # [09:58] <tantek> space separated set of class names for semantics has provided far better flexibility in terms of more easily marking up content that web authors actually publish.
  330. # [09:58] <boblet> MikeSmith: well only if you’re using IE6 ;-)
  331. # [09:58] <tantek> MikeSmith - not true - you can add additional class names to provide additional semantics in your class="section" example.
  332. # [09:59] <boblet> woops, I think I might have started something :)
  333. # [09:59] <MikeSmith> boblet: tantek's right, I'm wrong. :)
  334. # [10:00] <boblet> MikeSmith: well, as I said you’re right for IE6 (and CSS styling)—it only sees the first (or was it last?) class name
  335. # [10:00] <tantek> Hixie, I asked the above question (re: reference vs. wholly incorporate) because I am revising hCard, hCalendar, hReview, hAtom with bug fix revisions that incorporate numerous issue resolutions (including your issue regarding conformance criteria for user-agents and authors).
  336. # [10:01] <MikeSmith> if authors want to do <div class="section something"> instead of using <section class="something">, the existence of a <section> element does not prevent them from doing that
  337. # [10:02] <tantek> e.g. hCard 1.0.1, hCalendar 1.0.1. - at that point I'm confident that those specifications will be more thorough, and incorporate more issue resolutions than the corresponding pre-defined microdata vocabularies of vcard/vevent.
  338. # [10:03] <tantek> not to mention be backed by actual experience from numerous authors publishing hCards and hCalendar events as defined.
  339. # [10:04] <tantek> and thus it should be reasonable to consider incorporating hCard and hCalendar vocabularies by *reference* rather by redefinition inline in the HTML5 spec.
  340. # [10:05] <boblet> MikeSmith: I think that web authors perceive class as an ad hoc system, rather than something official. While Microformats have pushed it a long way, I think that a W3-defined vocabulary of semantics (either new elements or role values) are far more official. Also I’m guessing implementors would feel the same—they’d be more likely to build functionality on something that’s defined (by W3) rather than something that’s just
  341. # [10:05] <MikeSmith> boblet: you got cut off there
  342. # [10:06] <Hixie> tantek: i think we're actually going to take out the few vocabularies that are in there already (the vcard and vevent ones, and the licensing works one)
  343. # [10:06] <tantek> Hixie, this is just a heads up of work in progress. I will re-raise the issue when hCard 1.0.1 and hCalendar 1.0.1 drafts have been published. In either case, I do think it is premature/unwise to include pre-defined microdata vocabularies. Hopefully the updates to hCard and hCalendar will make that even more clear.
  344. # [10:06] <boblet> too wordy—my bad. how far?
  345. # [10:06] <Hixie> tantek: and put them in their own specs
  346. # [10:06] <Hixie> tantek: i haven't worked out what should happen reference-wise
  347. # [10:06] <MikeSmith> to "that's jus..."
  348. # [10:06] * Joins: pauld (n=pauld@host86-146-144-6.range86-146.btcentralplus.com)
  349. # [10:06] <Hixie> tantek: it might be that we end up with a section that mentions vocabularies that use various features like class="" (assuming microformats continue to use those instead of item/itemprop) and item/itemprop
  350. # [10:06] <Hixie> tantek: in a non-normative way
  351. # [10:07] <Hixie> tantek: in which case i'd be happy to link to some normative definitions if there are some
  352. # [10:07] <boblet> RT: Also I’m guessing implementors would feel the same—they’d be more likely to build functionality on something that’s defined (by W3) rather than something that’s just agreed (by users of Microformats etc)
  353. # [10:07] <tantek> Hixie, the licensing works one will take more effort because it requires completion of the in-progress "licensing microformat", however it will very likely have similar to features to what you've written up - as you seem to have come to many of the same conclusions as the licensing microformats brainstorming efforts.
  354. # [10:07] <MikeSmith> boblet: but none of us want something official if it overly restricts authors. the point is to try to find some kind of sweet spot. to provide more authoring ease without locking people into something official that ends up restricting and confusing them too much
  355. # [10:08] <Hixie> tantek: that's no coincidence, the microformats wiki was one of my main crib sheets :-)
  356. # [10:09] <tantek> we do seem to agree that the ccREL as designed is problematic due to it's ability/encouragement for license proliferation, which IMHO is a fatal design flaw. http://microformats.org/wiki/licensing-brainstorming#ccREL_issues
  357. # [10:10] <tantek> s/it's/its duh
  358. # [10:10] <boblet> MikeSmith: well, I think new elements could also be considered fairly restrictive (in terms of number and release cycle)
  359. # [10:11] <tantek> Hixie, that is good to hear that the pre-defined vocabularies will be taken out of the HTML5 spec.
  360. # [10:11] * Joins: heycam (n=cam@203-217-77-251.dyn.iinet.net.au)
  361. # [10:11] <boblet> That’s why the potential of eg role values being defined in a Microformats-like way but by WhatWG/W3 seems really interesting—official and well-thought-out like elements, but faster release cycle like µF
  362. # [10:11] <tantek> As far as microformats use of class vs. item/itemprop, it is likely that for the forseeable future microformats will continue to make use of the class attribute for backwards compatibility.
  363. # [10:12] <othermaciej> as an implementor, I don't have a problem in principle implementing things based on microformats, just because they are not W3C-official or whatever
  364. # [10:12] <tantek> However, I believe it does make sense to advocate use of HTML5's features when authors are able to do so (are able to depend on them based on their use cases), and it is more advantageous to do so.
  365. # [10:13] <othermaciej> the main problems with microformats (neither completely fatal) are that parsing has historically not been defined very tightly, and the trickiness of figuring out the right browser UI to expose them
  366. # [10:13] <tantek> This will likely be an extension of the "How to use microformats in HTML5" work in development, that advocates use of the <time> element etc.
  367. # [10:13] <othermaciej> (from a browser implementor perspective)
  368. # [10:14] <othermaciej> one thing I like about microdata is that it takes you from parsing to a data model in a precisely defined way
  369. # [10:14] <tantek> othermaciej, I will encourage you to review the hCard 1.0.1 and hCalendar 1.0.1 drafts regarding the thoroughness of parsing definition. it is my intent to make those definitions thorough through both prose and test cases.
  370. # [10:14] <othermaciej> so microdata-based formats could start defining things at the data model level
  371. # [10:15] <tantek> I agree, the parsing to data model description of the general microdata feature is quite admirable.
  372. # [10:15] <othermaciej> tantek: I did say "historically", cause I haven't reviewed recently
  373. # [10:15] <tantek> (btw parsing details are a known issue that I've resolved as needing additional work for hCard 1.0.1 and hCalendar 1.0.1)
  374. # [10:16] <othermaciej> one other thing I like about microdata is that it exposes the data model through a nice DOM API, which is friendly to data extraction via client-side script or client-side logic in general
  375. # [10:17] <tantek> we are doing something similar in microformats for our recent test-suite update efforts: http://microformats.org/wiki/test-suite
  376. # [10:18] <othermaciej> hCard and hCalendar are probably among the microformats that are most interesting for likely built-in browser features, if anyone ever goes there
  377. # [10:18] <othermaciej> I would really like to support hAtom as well, but that probably won't happen unless our feed parsing code is open sourced and a motivated individual can take matters into their own hands
  378. # [10:20] <tantek> othermaciej - does it help that there is existing open source XSLT that you can incorporate to transform hAtom to Atom and then just pipe that into your existing support? http://rbach.priv.at/Microformats/hAtom2Atom/
  379. # [10:20] <tantek> specifically, available under the The W3C Open Source License per http://rbach.priv.at/Microformats/hAtom2Atom/readme.txt
  380. # [10:20] <Hixie> boblet: I expect HTML's release cycle to be remarkably quicker once HTML5 is done
  381. # [10:21] <othermaciej> tantek: the people who originally wrote our support are no longer with the company and left a... very creative combination of diverse technologies that... provides an intellectual puzzle for those of us on the team
  382. # [10:21] <othermaciej> so it doesn't actually help that much directly, but thanks for the reference
  383. # [10:22] <Hixie> boblet: the main problem with HTML that made HTML5 take so long was the utterly woeful state of the HTML and DOM HTML specifications prior to HTML5, in terms of conformance criteria for implementors (of all classes, not just browsers), and in terms of missing features altogether (DOM level 0 in particular)
  384. # [10:22] <tantek> othermaciej - that's too bad. perhaps as you say you can open sourcce the feed parsing code as part of WebKit and thus enable folks to improve it.
  385. # [10:22] <othermaciej> I think open sourcing the code would also likely lead to it being greatly simplified and improved
  386. # [10:22] <Hixie> tantek: that makes sense (using class for back compat vs using microdata when it makes sense going forward)
  387. # [10:23] <othermaciej> because WebKit has much higher standards for code quality than most Apple-internal code
  388. # [10:24] <tantek> othermaciej - in case you want to try experimenting with that code with a bunch of other microformats folks/devs to bounce ideas/thoughts off of - I encourage you (and anyone else here interested in microformats development) to participate in microformatsDevCamp July 25-26 http://microformats.org/wiki/events/2009-07-25-dev-camp
  389. # [10:24] <Hixie> one thing that's unclear to me when it comes to splitting off the vocabularies is how to handle the HTML->Atom and HTML->RDF sections
  390. # [10:25] <MikeSmith> othermaciej: that's kind of a little bit disturbing to hear (about Apple-internal code standards vs Webkit standards)
  391. # [10:25] <tantek> Hixie, that's good to hear, and not surprising, given that we both have a bit of a bias for back compat, while incrementally improving things in the future.
  392. # [10:25] <tantek> Hixie, HTML to Atom will likely be handled in the hAtom update.
  393. # [10:25] <Hixie> tantek: indeed :-)
  394. # [10:25] <othermaciej> MikeSmith: so you're saying, given how terrible WebKit is, you're surprised Macs and iPhones even boot?
  395. # [10:25] <MikeSmith> heh
  396. # [10:25] <MikeSmith> no, not at all man
  397. # [10:26] <Hixie> specifically i mean how to handle http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#atom
  398. # [10:26] <othermaciej> Hixie: HTML->RDF isn't really a custom vocabulary
  399. # [10:26] <tantek> HTML -> RDF is more complicated (everything is more complicated with RDF) and will require an update to XMDP
  400. # [10:26] <Hixie> and how to handle http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#rdf
  401. # [10:26] * Joins: abii (n=macbook@cm27.delta30.maxonline.com.sg)
  402. # [10:26] <Hixie> othermaciej: no but it references the custom vocabularies
  403. # [10:26] <Hixie> othermaciej: HTML->Atom is not a custom vocab at all either
  404. # [10:26] <MikeSmith> othermaciej: just that I would hope Apple-internal code standards would be as exacting was you guys
  405. # [10:26] <Hixie> othermaciej: but it reuses the vcard vocabulary to get people's names out and suchlike
  406. # [10:27] <othermaciej> MikeSmith: we have hundreds of people looking at our code every day
  407. # [10:27] * MikeSmith catches up on othermaciej's actual joke
  408. # [10:27] <Hixie> i think i might just leave those parts in the html5 spec proper and have references out -- it's not like the reference needs to be normative
  409. # [10:27] <othermaciej> few projects are like that, open source or not
  410. # [10:27] * Quits: pauld (n=pauld@host86-146-144-6.range86-146.btcentralplus.com) ("Gone for a burton")
  411. # [10:27] <tantek> Hixie, I wonder, if the 'profile' attribute helped enable XMDP, and thus automatic conversion from HTML to RDF, would that be sufficient to add it back (in contrast to say, the "about" attribute, which is brand new as far as HTML is concerned).
  412. # [10:27] <MikeSmith> othermaciej: yeah, understood. it's unique in a number of ways
  413. # [10:28] <MikeSmith> or at least quite exceptional in a number of ways (if not unique)
  414. # [10:28] <othermaciej> and we tend to attract people who are fussy about code quality details
  415. # [10:28] <Hixie> tantek: not sure what you mean
  416. # [10:28] <Hixie> tantek: the HTML->RDF section is "automatic conversion from HTML to RDF" already
  417. # [10:28] <tantek> but requires the new "about" attribute IIRC
  418. # [10:28] <Hixie> there's a new "about" attribute?
  419. # [10:29] <Hixie> we may be talking about something else
  420. # [10:29] <tantek> I thought I saw a diff that introduced it - perhaps relating to the licensing vocab
  421. # [10:29] <tantek> I did notice that the citation/bibtex vocab got removed
  422. # [10:29] <Hixie> there's an itemprop="about" field, if that's what you mean, but that's not really RDF-specific (though it is a key part of the subpart of the HTML->RDF conversion concerned with converting microdata)
  423. # [10:30] <Hixie> (that's just one part of the algorithm though)
  424. # [10:30] <Hixie> (there's lots of other stuff in that algorithm, like converting <blockquote cite=""> to RDF statements, etc)
  425. # [10:30] <tantek> yes - I believe that's what I'm referring to.
  426. # [10:30] <tantek> (the itemprop="about" thing)
  427. # [10:32] <tantek> frankly, I think the whole approach of encouraging the inclusion of invisible hyperlinks in content (what the "about" design does in RDF/RDFa) is fundamentally flawed. the "dark data" problem as it were.
  428. # [10:33] <Hixie> yeah. that's why i like itemprop=about -- it encourages people to use <img> or <a href=""> to say what they're talking about
  429. # [10:33] * Joins: mat_t (n=mattomas@nat/canonical/x-36d1fd70ed245b74)
  430. # [10:33] <Hixie> i was quite honestly surprised that RDFa really doesn't make the licensing use case as easy as microdata can
  431. # [10:33] <Hixie> i sent a mail about that where i showed what i thought the best you could do with RDFa was, and it was surprisingly verbose compared to what i ended up with with microdata
  432. # [10:34] <Hixie> including some duplication of data, which violates what i thought was an RDFa design goal (DRY)
  433. # [10:34] <boblet> sorry—cake attack
  434. # [10:35] * Joins: danbri (n=danbri@s5590d015.adsl.wanadoo.nl)
  435. # [10:35] <gsnedders|work> Hixie: The aim is to make it impossible to create multiple body elements except by using DOM manipulation, right?
  436. # [10:36] <Hixie> gsnedders|work: not especially, why?
  437. # [10:36] <boblet> tantek: will current Microformats be released in Microdata format at some stage?
  438. # [10:36] <gsnedders|work> Hixie: See my email to public-html yesterday
  439. # [10:36] <gsnedders|work> Hixie: Just having two body elements seems somewhat ugly
  440. # [10:37] <tantek> boblet - doubtful. but will likely happen is that microformats.org will document how to use *any* microformat generically using microdata syntax. watch this page for updates: http://microformats.org/wiki/html5
  441. # [10:38] <Hixie> gsnedders|work: it's on the pile
  442. # [10:38] <gsnedders|work> Hixie: Yeah, I knew it would be :)
  443. # [10:38] <boblet> thanks, will do
  444. # [10:38] <boblet> Hixie: I understand about the work required in HTML5. Good to hear you think post-HTML5 release cycles will be faster
  445. # [10:39] <Hixie> ideally i'd like html to move to a continuous development cycle instead of the w3c process of long drawn out lc/cr/pr/rec
  446. # [10:40] <tantek> Hixie, a continuous development cycle may be possible if you incorporate TDD.
  447. # [10:40] <gsnedders|work> Just publish second, third, fourth, etc. edition of HTML 5, hence avoiding that.
  448. # [10:40] <Hixie> TDD?
  449. # [10:40] <tantek> test driven development
  450. # [10:41] <tantek> thus each feature can quickly progress through wd/ts/cr via interop
  451. # [10:41] <Hixie> i think it'd be possible even without that
  452. # [10:41] <Hixie> though it would certainly help
  453. # [10:41] <tantek> relatively in parallel
  454. # [10:41] <Hixie> the problem is the forking of the spec source, not the testing
  455. # [10:42] <gsnedders|work> Using some sane VCS should mitigate most of that
  456. # [10:42] <othermaciej> it's hard to implement against a constantly evolving snapshot
  457. # [10:42] <boblet> I hope *all* major browser makers have got on the train by the time that happens :)
  458. # [10:42] <tantek> as long as the tests are clustered by / attached to section of the spec, presumably the tests would fork along with their respective spec prose.
  459. # [10:42] <tantek> othermaciej - believe me, I sympathize with that.
  460. # [10:42] <Hixie> othermaciej: that's unaffected by this, since in practice all the implementation work happens before we get to LC anyway
  461. # [10:42] <othermaciej> and it's hard to be confident in an implementation without a thorough test suite, which is also very hard to develop against a constantly evolving snapshot
  462. # [10:42] <tantek> (ahem, CSS 2.0 vs. CSS 2.1 etc.)
  463. # [10:43] <othermaciej> Hixie: hopefully - some HTML5 features that seem useful still have 0 implementations
  464. # [10:43] <Hixie> gsnedders|work: i'm not aware of any good VCS that handles forking over multiple years in what i would consider a "sane" manner
  465. # [10:43] <tantek> btw in terms of "how do I use microformats with a specific version of HTML", I drafted this as a start: http://microformats.org/wiki/HTML3
  466. # [10:43] <gsnedders|work> Hixie: I think is mainly depends on quite how much they diverge
  467. # [10:43] <Hixie> gsnedders|work: i'd expect that to be "a lot"
  468. # [10:43] <gsnedders|work> Hixie: I expect HTML 6 would mainly add stuff to it
  469. # [10:44] <Hixie> if i add stuff into the middle of the navigation algorithm, no amount of VCS is going to keep me sane
  470. # [10:44] <othermaciej> but really the challenge for using the spec is not just new features (where naturally you look there first) but rather aligning old implementations of features that used to be in the mutual reverse engineering domain with the spec
  471. # [10:44] <takkaria> othermaciej: it's also hard to write tests for a evolving snapshot, which is part of the problem...
  472. # [10:44] <othermaciej> takkaria: indeed - I believe I mentioned that above
  473. # [10:44] <Hixie> othermaciej: yeah
  474. # [10:45] <takkaria> othermaciej: ah, I misparsed :)
  475. # [10:45] <othermaciej> it will be very hard to every fully support HTML5 without a "bug fix only" branch
  476. # [10:45] <Hixie> how do you mean?
  477. # [10:45] <othermaciej> (a bug-fix-only branch of the spec that is)
  478. # [10:45] <boblet> Hixie: returning to the elements vs role conversation, while you’re not starting from scratch I perceive HTML5’s structural elements as new as role would be, so I’m still wondering why elements over role
  479. # [10:46] <Hixie> othermaciej: oh if we keep adding new features, we'll never get to the point where there are two full impls, sure
  480. # [10:46] <othermaciej> a version of the spec that only corrects errors, doesn't add new functionality, so that you can go through methodically without it changing out from under you
  481. # [10:46] <boblet> are there any advantages of using elements, or conversely are there any disadvantages of using roles?
  482. # [10:46] <Hixie> boblet: because <foo> is nicer to type than <z z="foo">
  483. # [10:47] <boblet> Hixie: yep, that’s a good reason
  484. # [10:47] <Hixie> boblet: if the syntax made it easier to have nodes in the DOM be given multiple labels at once, e.g. if the syntax had <a b c> as equivalent to <c b a> or <b a c> or whatever, that'd be a very different story
  485. # [10:47] <othermaciej> software projects pretty commonly have stable and new development branches, rarely ones that live for years, but that is not unprecedented
  486. # [10:48] <Hixie> othermaciej: yeah, it may be that that the benefits to implementors are worth the pain to the spec writer :-)
  487. # [10:48] <Hixie> othermaciej: i've never heard of any project that had a branch that lasted more than about a month where people on the project haven't complained that it was a mistake
  488. # [10:49] <Hixie> and i've heard of _many_ such branches
  489. # [10:49] <othermaciej> WebKit has had stable branches last over a year that we actually shipped off of, but they didn't have direct new development and the longer you go the harder it gets to backport fixes
  490. # [10:50] <tantek> othermaciej - indeed, your revising of specs points are good ones.
  491. # [10:50] <boblet> Hixie: not sure I understood that :) what about <ul role="aside nav"> vs <aside><nav><ul> for article section links?
  492. # [10:50] <othermaciej> we didn't really complain about that except to the extent that backporting bug fixes is less fun than new development
  493. # [10:50] <tantek> for this reason I'm simultaneously editing an hCard 1.0.1 and hCard 1.1.
  494. # [10:51] <othermaciej> although the one time we tried feature development based on an old branch - it was hell
  495. # [10:51] <Hixie> boblet: <aside><nav> is redundant, just use <nav>, but in general i'd say the role="" alternative looks much uglier and doesn't really get you any useful benefits.
  496. # [10:51] <gsnedders|work> othermaciej: It'd be nice to have an infinitely large test suite and a no-regressions policy so you could always ship the latest code :)
  497. # [10:51] <Hixie> boblet: again, because of the way the DOM works, there are things that are much harder to do if you put the semantics in attributes
  498. # [10:51] <gsnedders|work> (But yeah, that's mainly idealistic)
  499. # [10:51] <othermaciej> sadly, our test suite is not yet infinite
  500. # [10:52] <Hixie> boblet: e.g. <z z="audio applet"> -- does it have an HTMLAudioElement interface, or an HTMLAppletElement interface?
  501. # [10:52] <Hixie> boblet: does it spawn an applet or play audio?
  502. # [10:52] <Hixie> boblet: similarly, consider the huge pain that <input type=""> has been in terms of changing the implementation of the widget dynamically
  503. # [10:52] <othermaciej> <input type="bad design">
  504. # [10:52] <Hixie> boblet: what happens when a script changes a <z z="iframe"> to a <z z="embed">?
  505. # [10:53] <Hixie> othermaciej: it's the same design as role="", basically
  506. # [10:53] <gsnedders|work> Hixie: Is that really any worse than changing tagName?
  507. # [10:53] <boblet> Hixie: ok thanks for the detailed explanation. I think I understand the issue a lot better now. Will have to chat more about this with John the next time he’s over
  508. # [10:53] <othermaciej> Hixie: preaching to the choir, sir
  509. # [10:54] <Hixie> gsnedders|work: you can't change tagname
  510. # [10:54] <gsnedders|work> localName?
  511. # [10:54] <Hixie> you can't change localname either
  512. # [10:54] <gsnedders|work> readonly too
  513. # [10:54] <othermaciej> although type="" is more narrowly scoped and the corner cases of the behavior are now reasonably well defined, so it's relatively tamed
  514. # [10:54] <gsnedders|work> How boring.
  515. # [10:55] <othermaciej> there is renameNode() in DOM Level 3 Core
  516. # [10:55] <Hixie> othermaciej: it certainly was significant effort to define how on earth to handle type="" changes :-)
  517. # [10:55] <othermaciej> but I would expect browser-hosted implementations to always make a new node for that
  518. # [10:55] <Hixie> (renameNode() creates a new node and copies the attributes over, basically)
  519. # [10:55] * Joins: svl (n=me@86.87.68.167)
  520. # [10:56] <boblet> It’d be a good idea for this to be addressed in the FAQ sometime as it’s a pretty popular topic atm (eg recent zeldman.com article comments)
  521. # [10:56] <othermaciej> it gives implementations the option to actually change the existing node's tag name, but that would be dumb
  522. # [10:57] <Hixie> boblet: please feel free to collect the responses here into a coherent entry for the faq and to add it :-)
  523. # [10:58] <boblet> Hixie: d’oh! :)
  524. # [10:58] <Hixie> othermaciej: it's especially bad if it means some UAs return the same node and others have two nodes
  525. # [10:58] <boblet> oh btw if anyone has the time (har!) to check out some articles I wrote on HTML5 I’d appreciate some feedback
  526. # [10:59] <boblet> The most recent one is: http://bit.ly/TE2TL “HTML5 structure—HTML4 and XHTML1 to HTML5”
  527. # [10:59] <othermaciej> Hixie: I could rant for a long time about the many bad ideas in the DOM, but I'm just going to remind myself of the channel topic
  528. # [10:59] <Hixie> heh
  529. # [11:01] <boblet> thanks for your time all. Later!
  530. # [11:02] <tantek> heh indeed
  531. # [11:02] <tantek> that seems like an appropriate note to call it a night.
  532. # [11:02] <Hixie> nn
  533. # [11:02] <tantek> thanks for the updates and feedback Hixie and othermaciej.
  534. # [11:03] * Parts: boblet (n=boblet@p2227-ipbfp4102osakakita.osaka.ocn.ne.jp)
  535. # [11:04] * Joins: ROBOd (n=robod@89.122.216.38)
  536. # [11:08] * gsnedders|work normally calls this a morning
  537. # [11:11] * Joins: jacobolus (n=jacobolu@adsl-75-36-158-29.dsl.pltn13.sbcglobal.net)
  538. # [11:18] * Joins: Phae (n=phaeness@gateb.thls.bbc.co.uk)
  539. # [11:27] <zcorpan> http://simon.html5.org/test/html/semantics/video/support/video.php - chrome seems happy to ignore mime type in <video>
  540. # [11:27] <Hixie> doublec: ^
  541. # [11:27] <gsnedders|work> Hixie: You've gone for the night! Go way!
  542. # [11:28] <Hixie> i did?
  543. # [11:29] <Hixie> zcorpan: what's the actual type of that video?
  544. # [11:29] <zcorpan> Hixie: it's an ogg/theora/vorbis file
  545. # [11:30] <Hixie> huh. i don't remember installed xiph codecs, i wonder when i did that
  546. # [11:33] <gsnedders|work> When you thought it was a good idea?
  547. # [11:35] <zcorpan> i just updated webkit and now it's giving a crash dialog all the time... but the safari window is still open and more or less usable
  548. # [11:35] <zcorpan> oh well
  549. # [11:36] * Quits: jianli (n=jianli@72.14.227.1) (Read error: 60 (Operation timed out))
  550. # [11:36] * Joins: jianli (n=jianli@72.14.227.1)
  551. # [11:39] * Quits: jwalden (n=waldo@c-98-248-40-206.hsd1.ca.comcast.net) ("ChatZilla 0.9.85 [Firefox 3.5.1pre/20090712031210]")
  552. # [11:42] * Quits: MikeSmith (n=MikeSmit@EM114-48-134-244.pool.e-mobile.ne.jp) ("Tomorrow to fresh woods, and pastures new.")
  553. # [11:49] * Quits: mat_t (n=mattomas@nat/canonical/x-36d1fd70ed245b74) ("This computer has gone to sleep")
  554. # [11:51] * Joins: mat_t (n=mattomas@nat/canonical/x-32a18592159512df)
  555. # [11:56] * Joins: zdobersek (n=zan@cpe-92-37-69-22.dynamic.amis.net)
  556. # [12:01] * Joins: Lachy_ (n=Lachlan@pat-tdc.opera.com)
  557. # [12:05] * Quits: Lachy (n=Lachlan@85.196.122.246) (Read error: 110 (Connection timed out))
  558. # [12:11] <hsivonen> Hixie: the problem <div role=navigation> solves compared to <nav> is the parsing of <p>foo<nav><p>bar... in legacy browsers
  559. # [12:14] <Hixie> that's it?
  560. # [12:14] <Hixie> that's what has everyone up in arms?
  561. # [12:15] <Lachy_> Hixie, yeah, that and the perception that role="" is more extensible than creating new elements
  562. # [12:16] * Lachy_ is now known as Lachy
  563. # [12:16] * Joins: ZombieLoffe (n=e@unaffiliated/zombieloffe)
  564. # [12:17] <Philip`> I thought everyone wanted to write XHTML-like strict syntax with closing tags and everything, so implied </p>s wouldn't make a difference
  565. # [12:17] <hsivonen> tantek: btw, regarding your earlier comments about XSLT, XHTML and performance: with the Validator.nu HTML Parser, the step of serializing as XHTML5 and reparsing as XML is optimized away
  566. # [12:17] <hsivonen> tantek: (earlier as in a week or so earlier)
  567. # [12:18] <hsivonen> Philip`: I'm leaning towards making implied </p> closes warnings even when V.nu users don't ask for it
  568. # [12:18] <hsivonen> Philip`: with the new structural elements, omitting </p> may be a real compat issue
  569. # [12:19] <zcorpan> hsivonen: but not for e.g. <p><p>?
  570. # [12:20] <Philip`> hsivonen: I might like it to silently accept <p>...<p>... and <div><p>...</div>, but warn if the </p> is implied by a start tag other than <p>
  571. # [12:20] <hsivonen> zcorpan: I can imagine that making it an unconditional warning for <p>foo<p>bar could annoy people
  572. # [12:20] <hsivonen> Philip`: makes sense
  573. # [12:20] <zcorpan> hsivonen: i think p and form have weird parsing in various browsers
  574. # [12:21] <zcorpan> <p><form>, <form><p></form>x, etc
  575. # [12:21] <zcorpan> <p><table> in ie7
  576. # [12:23] <zcorpan> hsivonen: if you have an option to warn for all implied tags, you could make it clear in the UI that it's for debugging rather than Superior Correctness
  577. # [12:24] <hsivonen> zcorpan: any suggestions on how to make it clear?
  578. # [12:24] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  579. # [12:24] <zcorpan> Debugging options: show messages for implied tags
  580. # [12:25] <zcorpan> maybe could have them as Info rather than warning
  581. # [12:25] <hsivonen> zcorpan: yeah, info makes sense
  582. # [12:28] <hsivonen> Hixie: the other problem that role=navigation solves is that you can overlay role=navigation onto an <ul>
  583. # [12:28] <hsivonen> Hixie: no, I don't understand why the extra DOM node / CSS box for <nav> is an issue
  584. # [12:28] <mookid> Hixie: discussion on that blog post I linked to yesterday is on-going, be good to get some feedback from your end :)
  585. # [12:29] <hsivonen> I wish we could put a swift end to the "HTML is sloppy" meme, but I guess it's futile to try as long as implied tag messages on V.nu are vaporware
  586. # [12:29] <Hixie> hsivonen: the question "what problem does it solve" sort of asks for the answer to be a problem, not a random feature of questionable value :-P
  587. # [12:30] <Hixie> i wish i understood why implied tags are sloppy
  588. # [12:30] <hsivonen> Hixie: I know
  589. # [12:30] <hsivonen> Hixie: feel free to ask people who prefer role=navigation why they prefer it
  590. # [12:31] <hsivonen> I also don't understand why it's important to care about being consistent with <br> vs. <br/> within a document but not so important to care about consistency with <br/> vs. <br />
  591. # [12:32] <mookid> Hixie: implied tags will bring pain and hurt the same way that semi-colon insertion causes problems in javascript
  592. # [12:32] <hsivonen> I think the difference between <br>, <br/> and <br /> isn't something a validator should whine about. I think it's something that a "reformat code" command in a text editor should fix
  593. # [12:33] <Hixie> i don't understand why people want the /> at all
  594. # [12:33] <gsnedders|work> Hixie: Because it is explicit and you don't need to remember what tags are implicit
  595. # [12:33] <Hixie> i really hate it personally
  596. # [12:33] <mookid> it's the parser equivalent of bank-bailouts
  597. # [12:33] <Hixie> gsnedders|work: i really can't say i've ever found that a problem
  598. # [12:33] <hsivonen> gsnedders|work: you need to remember which tags are implicit anyway.
  599. # [12:34] <zcorpan> allowing /> has the drawback that people think they can write <div/> too
  600. # [12:34] <hsivonen> gsnedders|work: </p> won't help you when you write <p>foo<table>...</table>bar</p>
  601. # [12:34] <hsivonen> zcorpan: indeed
  602. # [12:34] <hsivonen> zcorpan: /> confuses the mental model people have
  603. # [12:34] <gsnedders|work> hsivonen: Yeah, right. But if you disallow implicit tags…
  604. # [12:34] * gsnedders|work doesn't think doing so is a good idea though
  605. # [12:34] <Lachy> hsivonen, warning about implied </p> when it's implied by one of the new HTML5 sectioning elements would be valuable for compat reasons. But warning about when it's implied by <p> or <div> is too much
  606. # [12:35] <zcorpan> Lachy: what about <p><form>?
  607. # [12:35] * gsnedders|work thinks unquoted attribute values starting with ` should be non-conforming, for IE compat.
  608. # [12:35] <hsivonen> Lachy: what about <p><table>?
  609. # [12:37] <mookid> you poor people realy have to go through all this stuff every day don't you?
  610. # [12:38] * Joins: myakura (n=myakura@p5137-ipbf707marunouchi.tokyo.ocn.ne.jp)
  611. # [12:38] <mookid> pretty thankless task
  612. # [12:39] <mookid> good on you :)
  613. # [12:41] <hsivonen> maybe knowing when omitting quotes is OK should be positioned as professional 1337 skillz instead of positioning quote omission as sloppy :-)
  614. # [12:41] <Lachy> hsivonen, zcorpan, I'm not sure about those
  615. # [12:42] <Lachy> IIRC, HTML5 says those should imply </p>, right?
  616. # [12:42] <gsnedders|work> Lachy: yes
  617. # [12:42] <othermaciej> I used to like always quoting just to avoid wondering whether I had to
  618. # [12:42] <Lachy> which browser doesn't do that? Is it just IE?
  619. # [12:43] <othermaciej> now I drop the quotes only when I'm sure they are not needed (e.g. attribute value is a single purely alphanumeric word)
  620. # [12:43] <gsnedders|work> IE < 8 and IE 8 when not in IE8 mode
  621. # [12:44] <othermaciej> I still like providing implied open and close tags because the more I learn about the rules for those, the less confident I am of ever getting them right
  622. # [12:44] <Lachy> hmm, ok. that makes them problematic, at least for now
  623. # [12:45] <gsnedders|work> othermaciej: If you ignore where whitespace goes they aren't that complex
  624. # [12:45] <Lachy> othermaciej, I never found the rules for implied tags complicated. At least for HTML4, they seemed fairly intuitive.
  625. # [12:45] <hsivonen> the only time I've had trouble with authoring quoteless attributes was when I had /> immediately after
  626. # [12:45] <hsivonen> those two features aren't nice together
  627. # [12:46] <Lachy> othermaciej, do you always include <tbody>? From my experience, that's one of the few that most people leave out
  628. # [12:46] <othermaciej> no, not <tbody>
  629. # [12:46] <othermaciej> I didn't even know it existed until after I started working on a Web browser
  630. # [12:46] <Lachy> I usually leave it out, except when I also use <thead>
  631. # [12:47] <othermaciej> of course that's almost 8 years ago now
  632. # [12:48] <othermaciej> I was thinking to myself who might have the record for working the longest continuously on a single browser, and I am betting it's someone at Opera
  633. # [12:48] * Quits: kristallpirat (n=kristall@c-base/crew/kristall) (Read error: 110 (Connection timed out))
  634. # [12:48] <othermaciej> at least if you don't count Netscape/Mozilla/Firefox as a single browser lineage
  635. # [12:49] <zcorpan> we have a number of people who have worked more than 8 years at opera
  636. # [12:49] <Lachy> othermaciej, that's possible. We have a few staff who've been here for 10 years. Then there's people like Jon and Håkon who've been here since the beginning.
  637. # [12:50] <Hixie> othermaciej: hyatt's high up on that list i'm sure
  638. # [12:50] <Hixie> Lachy: howcome wasn't at opera since the beginning
  639. # [12:50] <othermaciej> IE had a break and I count Netscape --> Firefox as a discontinuity although I'm not going to declare exactly where it happened
  640. # [12:50] <Lachy> wasn't he?
  641. # [12:50] <Hixie> brendan too
  642. # [12:50] <Hixie> (brendan would be high on the list i mean)
  643. # [12:51] <Hixie> oh on a single browser
  644. # [12:51] <othermaciej> yeah
  645. # [12:51] <Hixie> as opposed to browsers in general
  646. # [12:51] <Hixie> hm
  647. # [12:51] <Hixie> hard to say what a single browser is really
  648. # [12:51] <Hixie> netscape->firefox probably was less of a change than some opera releases
  649. # [12:51] <othermaciej> on browsers continuously in general, then yeah, probably some Mozilla people have a good claim
  650. # [12:52] <hsivonen> Dan Mosedale would probably be high on the list
  651. # [12:54] <othermaciej> would he still count as "working on a browser"?
  652. # [12:56] <hsivonen> hmm. MailCo...
  653. # [13:08] * Joins: othermaciej_ (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  654. # [13:08] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  655. # [13:10] <Philip`> "< Lachy> IIRC, HTML5 says those should imply </p>, right?" ... "I never found the rules for implied tags complicated" - if they're not complicated, why did you sound so uncertain about those cases? :-)
  656. # [13:12] <Lachy> Philip`, I couldn't remember if HTML5 changed those rules.
  657. # [13:12] <Lachy> I remember there was discussion about doing that, at least for <p><table>
  658. # [13:13] <Hixie> this is why i don't change the rules willy nilly and try to keep them as simple as possible :-P
  659. # [13:13] <Philip`> So it sounds like they are a bit complicated
  660. # [13:14] <Lachy> Philip`, you also quote mined me. I also said "At least for HTML4, they seemed fairly intuitive."
  661. # [13:15] <hsivonen> is there a Mail.app solution for marking dupes in www-archive read if I've already read them in my WHATWG/public-html folder?
  662. # [13:15] <Hixie> he doesn't like my solution :-P
  663. # [13:15] <Hixie> (route all mail through gmail)
  664. # [13:16] <Lachy> Hixie, how does routing it all through gmail help?
  665. # [13:16] <Hixie> gmail coallesces duplicate e-mails
  666. # [13:16] <Hixie> my mind just exploded
  667. # [13:16] <hsivonen> Hixie: how does gmail figure out what my preferred folder for a given email is? or do they show up in all folders but get marked read?
  668. # [13:16] <Hixie> steven pemberton just told me something was "not valid, but permitted"
  669. # [13:16] <Lachy> wtf?
  670. # [13:16] <hsivonen> Hixie: URL?
  671. # [13:17] <gsnedders|work> Is there any way to get the interface of an element (given a DOM element node)?
  672. # [13:17] <Hixie> hsivonen: if you get multiple copies of an e-mail, it picks one of them and junks the rest. so, if you're using Sender: headers or some such for filtering, you get a random one.
  673. # [13:18] <Hixie> (this also means that if you're cc'ed on a message to a w3c list, you won't have the X-Archived-At headers, which is making it harder for me to give y'all a link to the aforementioned message)
  674. # [13:18] <hsivonen> Hixie: ah. when an email is sent to hsivonen@iki.fi, public-html and www-archive, I'd prefer to see only the public-html copy
  675. # [13:18] <Hixie> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jul/0117.html
  676. # [13:18] <Lachy> Hixie, I filter most of my mail based on the List-Id using .procmailrc
  677. # [13:18] <Hixie> hsivonen: yeah, you'd likely get the hsivonen@iki.fi copy (since gmail would see that one first)
  678. # [13:18] <Hixie> (i use recipient filtering to get around this)
  679. # [13:18] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (Read error: 104 (Connection reset by peer))
  680. # [13:19] <hsivonen> Hixie: wow. (at Steven)
  681. # [13:20] <gsnedders|work> So he's basically just saying HTML 4.01 has rules for invalid content.
  682. # [13:20] <hsivonen> Hixie: that reminds me of the novel interpretations of what XML 1.0 says about error handling
  683. # [13:21] <Philip`> If it's permitted, what is not permitted?
  684. # [13:21] * gsnedders|work isn't sure he understands the email
  685. # [13:22] <gsnedders|work> Still, is there any way to get the interface implemented by a DOM element node?
  686. # [13:22] <Philip`> (It makes sense that it's permitted in the sense that nobody will come and shoot you if you write it, even though it's invalid, but that applies to all strings of bytes so it's not a very interesting distinction, and I'm not sure what sense makes more sense)
  687. # [13:22] <Lachy> I'd want a way to have my mail filtering work much more like usenet newsgroups work with good clients. i.e. Dupes get filtered into individual mailing list folders, but when one is read in one folder all dupes with the same message ID get marked as read too.
  688. # [13:23] <othermaciej_> he doesn't really explain what "permitted but invalid" means
  689. # [13:23] <othermaciej_> maybe you have his permission to make invalid documents
  690. # [13:23] <othermaciej_> (thanks Steve!)
  691. # [13:24] <Lachy> I find Steven's message confusing, since he claims that HTML5 conflates the issue of conformance and processing, but it is in fact his claims that seem to do that
  692. # [13:25] <Lachy> since he quoted a processing requirement to back up his claim that something was permitted, despite being invalid
  693. # [13:26] * othermaciej_ is now known as othermaciej
  694. # [13:27] <Lachy> wow, his understanding of HTML vs. XHTML and MIME types is even more twisted. http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jul/0118.html
  695. # [13:28] <gsnedders|work> Lachy: Find a normative statement to disprove that.
  696. # [13:29] <Lachy> gsnedders|work, disprove what?
  697. # [13:29] <hsivonen> Lachy: I think the opinion on MIME types is not news
  698. # [13:29] <gsnedders|work> Lachy: Find something that means that MIME types have to describe the data.
  699. # [13:30] * Joins: Creap (n=Creap@vemod.brg.sgsnet.se)
  700. # [13:31] <Hixie> gsnedders|work: i plan to include that statement in my updates of the mime registrations for text/html and application/xhtml+xml, fwiw
  701. # [13:31] <gsnedders|work> And that isn't going to happen until we reach REC, I guess
  702. # [13:32] <Lachy> gsnedders|work, "Content-Type specifies the media type of the underlying data." -- RFC 2616 section 7.2.1
  703. # [13:32] <gsnedders|work> Lachy: That's an informative statement.
  704. # [13:33] <gsnedders|work> Lachy: There was a long discussion about this on ietf-http-wg
  705. # [13:33] <Lachy> in a normative section?
  706. # [13:33] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
  707. # [13:33] <gsnedders|work> That doesn't make it normative.
  708. # [13:34] <Hixie> gsnedders|work: i plan to start doing it next month, dunno how the ietf will take it though
  709. # [13:34] <gsnedders|work> Hmm, text/html and application/xhtml+xml are only informational RFCs
  710. # [13:34] <gsnedders|work> And as they are informational, I don't think you can have normative requirements (as otherwise it isn't informational)
  711. # [13:35] * Joins: tndH (n=Rob@129.11.105.100)
  712. # [13:38] <Hixie> ...for now
  713. # [13:38] <othermaciej> the MIME type dictates processing, it makes sense that it should dictate conformance
  714. # [13:39] <gsnedders|work> othermaciej: What, normatively, says the MIME type dictates processing?
  715. # [13:39] <othermaciej> what makes sense is to figure out how to spec that soundly, rather than to quibble about whether it is the case
  716. # [13:39] <Hixie> christ it's late
  717. # [13:39] <Hixie> when did that happen
  718. # [13:39] <gsnedders|work> Hixie: Well, you said "nn" several hours ago
  719. # [13:39] <othermaciej> gsnedders|work: nothing says that normatively - it's just true as a fact of reality
  720. # [13:39] <Hixie> i was saying that to tantek who said he was going to bed
  721. # [13:40] <gsnedders|work> Hixie: Oh, OK. I thought you were too.
  722. # [13:40] <Hixie> lord no, it was barely midnight
  723. # [13:40] * gsnedders|work facepalms
  724. # [13:41] * gsnedders|work still wants an answer to his question (of whether you can find out what interface a DOM element implements)
  725. # [13:41] * Quits: JoePeck_ (n=JoePeck@cpe-74-69-85-249.rochester.res.rr.com)
  726. # [13:41] <gsnedders|work> (Like whether it is just HTMLElement or some sub-interface)
  727. # [13:42] <othermaciej> gsnedders|work: you mean from code?
  728. # [13:42] <gsnedders|work> othermaciej: Yes, from JS
  729. # [13:43] <Lachy> gsnedders|work, if (elm instanceof HTMLFooElement) { ... } else if (elm instanceof HTMLBarElement) ...
  730. # [13:44] <gsnedders|work> Lachy: No way to just get the name as a string or whatever?
  731. # [13:44] <othermaciej> instanceof would be a sound way - a hackier way would be to toString() it and remove the "[object " prefix and "]" suffix
  732. # [13:44] <Lachy> yeah, toString() could work, but no guarantee of its reliability
  733. # [13:44] <othermaciej> (neither of these techniques will tell you all implemented interfaces, just the one that the implementation considers the "class")
  734. # [13:45] <gsnedders|work> Lachy: Unreliable how?
  735. # [13:45] <gsnedders|work> othermaciej: Yeah, right
  736. # [13:45] <othermaciej> I seem to recall some spec adding requirements for toString (can't remember if it was HTML5 or Web IDL)
  737. # [13:45] <Hixie> toString() will fail for some elements like HTMLAnchorElement (<a>) which stringify
  738. # [13:45] <othermaciej> but I don't think IE will do it
  739. # [13:46] <gsnedders|work> Oh yay
  740. # [13:46] <othermaciej> good point
  741. # [13:46] <hsivonen> the RDFa TF thread is http://archive.scripting.com/2003/06/13#When:8:12:30AM all over again
  742. # [13:47] <Hixie> julian and i actually agree on something
  743. # [13:47] <Lachy> IE8 seems to do it properly in IE8 mode, but IE7 mode and earlier generally just return "[object]" for most elements
  744. # [13:47] * Joins: dave_levin_ (n=dave_lev@72.14.227.1)
  745. # [13:47] <Hixie> now i KNOW i have to go to bed, i'm clearly halucinating
  746. # [13:47] * Quits: dave_levin_ (n=dave_lev@72.14.227.1) (Remote closed the connection)
  747. # [13:47] <gsnedders|work> Quick, go quiet in here!
  748. # [13:49] * Joins: remysharp (n=remyshar@84.12.169.15)
  749. # [13:49] <zcorpan> Philip`: research time :-) type="video/..." or type="audio/..." (or single quotes)
  750. # [13:49] <zcorpan> Philip`: i'd like to know common values for the ... in html pages
  751. # [13:49] * Lachy must get back to work. I need to answer complicated questions for my US work visa, explaining why the US should let Opera employ me there, instead of hiring a US citizen.
  752. # [13:50] <Philip`> zcorpan: I hope it can wait, since I should probably unplug my computer to avoid the possibility of it getting lightninged and I have no battery power left
  753. # [13:50] <zcorpan> Philip`: sure no rush
  754. # [13:50] <Philip`> Remind me later if I forget :-)
  755. # [13:51] <gsnedders|work> Lachy: I do like how a country founded on immigration is so hostile to immigrants
  756. # [13:51] * Joins: maikmerten (n=merten@129.217.26.196)
  757. # [13:52] <zcorpan> or possibly without quotes
  758. # [13:53] <remysharp> gsnedders|work: can I ask a Q about your outliner?
  759. # [13:53] <gsnedders|work> remysharp: Sure
  760. # [13:53] <remysharp> when it hits a section that doesn't have a title, it says untitled section
  761. # [13:53] <gsnedders|work> Right
  762. # [13:53] <Lachy> gsnedders|work, yeah, a lot of countries are becoming like that, unfortunately
  763. # [13:54] <remysharp> sorry - just checking what I wanted to ask - one mo...
  764. # [13:54] <remysharp> the spec says re: section: "typically with a heading"
  765. # [13:54] * Quits: tndH (n=Rob@129.11.105.100) (Remote closed the connection)
  766. # [13:54] <remysharp> but if it doesn't contain a heading, is an outliner going to assume the heading then?
  767. # [13:54] <remysharp> this doesn't really come across in the current spec - so just checking really.
  768. # [13:55] <gsnedders|work> remysharp: That's up to the implementer
  769. # [13:55] <gsnedders|work> remysharp: I took the solution of giving "Untitled Section"
  770. # [13:55] <remysharp> okay, but it's fair to say that it could just be ignored in the TOC too?
  771. # [13:56] <gsnedders|work> Yeah
  772. # [13:56] <remysharp> I guess in a way, your outliner is making me question my use of <section> - so perhaps I should have used a <div> in certain places.
  773. # [13:56] <gsnedders|work> I think Anolis does that, but mainly because I meant it to say "Untitled Section" but I screwed up :)
  774. # [13:57] <gsnedders|work> remysharp: Yeah, I wanted to point out untitled sections there
  775. # [13:57] <zcorpan> gsnedders|work: maybe you should make "Untitled Section" italic or something
  776. # [13:57] <gsnedders|work> remysharp: But otherwise it's somewhat missing some sections, which seems suboptimal for an outline
  777. # [13:57] <gsnedders|work> zcorpan: Yeah, probably
  778. # [13:58] <remysharp> Here's the url I'm running it against: http://gsnedders.html5.org/outliner/process.py?url=http%3A%2F%2Ffull-frontal.org
  779. # [13:58] <remysharp> The thing is -
  780. # [13:58] <remysharp> is that it's putting untitled section at the top level
  781. # [13:58] <remysharp> which looks like the title of the toc
  782. # [13:58] <remysharp> *doc
  783. # [13:58] <remysharp> but it's not - I've used a <section> to align the page to the centre
  784. # [13:59] <remysharp> rather than a <div> because IE would render the background of the <div> with JS off - so it's a reasonable work around to wrap with a <section>
  785. # [13:59] <gsnedders|work> zcorpan: It should do that now
  786. # [13:59] <gsnedders|work> No, it throws an error now
  787. # [13:59] <gsnedders|work> fail
  788. # [14:00] <zcorpan> remysharp: if you just want to center the page, don't use <section>
  789. # [14:00] <gsnedders|work> Now it works
  790. # [14:00] <remysharp> zcorpan: what would you suggest?
  791. # [14:00] <Lachy> remysharp, as a rule of thumb, I recommend that content with its own heading should use section (or other appropriate sectioning element), and otherwise just use div
  792. # [14:00] <zcorpan> remysharp: center the <body>
  793. # [14:01] <zcorpan> gsnedders|work: nice
  794. # [14:01] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  795. # [14:02] <remysharp> zcorpan: I'm going to test centering the body, but I'm not sure that's the right solution.
  796. # [14:02] <remysharp> As the big man said: I'll be back.
  797. # [14:09] <remysharp> zcorpan: centering half works
  798. # [14:09] <remysharp> technically it's the right thing
  799. # [14:10] <remysharp> but from a styling point of view, it means we (authors) lose flexibility to style our documents
  800. # [14:11] <remysharp> bah, I'm not sure there's a right answer, except whether untitled sections (i.e. lacking headings) should be included in the TOC since the spec says "typically"
  801. # [14:12] * Quits: dave_levin (n=dave_lev@72.14.224.1)
  802. # [14:18] * gsnedders|work is feeling distinctly "meh" at late '80s The Sisters Of Mercy
  803. # [14:20] * Quits: remysharp (n=remyshar@84.12.169.15) ("Gotta shoot - peeyaow!")
  804. # [14:21] * gsnedders|work notes that coincides with the time that goth rock became popular… coincidence?
  805. # [14:22] * Lachy wonders who The Sisters of Mercy are.
  806. # [14:24] <gsnedders|work> Lachy: http://en.wikipedia.org/wiki/The_Sisters_of_Mercy
  807. # [14:24] <Lachy> they appear to only be popular in the UK
  808. # [14:24] <Lachy> which would explain why I haven't heard of them or any of their songs
  809. # [14:31] <hsivonen> oh. crap. It seems I have a broken hard disk, and I lost data again.
  810. # [14:31] <hsivonen> something that I had sworn would never happen again
  811. # [14:31] <Lachy> hsivonen, no backup?
  812. # [14:31] <hsivonen> but I hadn't had the time to make everything work with my RAID
  813. # [14:32] <hsivonen> Lachy: I think there's a time window of photos without backups
  814. # [14:32] <hsivonen> sigh
  815. # [14:33] <hsivonen> ooh. ooh. maybe I do have that stuff on two disks
  816. # [14:33] <hsivonen> maybe I just lost some scanned receipts whose hard copies exist off-site anyway
  817. # [14:36] <hsivonen> I'm angry that other people are allowed to blow up bedrock and there's nothing I can do to keep them from sending shockwaves to my office
  818. # [14:37] <Lachy> hsivonen, do you know what it would cost to get the data professionally recovered
  819. # [14:37] <hsivonen> Lachy: too much
  820. # [14:37] <Lachy> ok
  821. # [14:38] <hsivonen> Lachy: at least it was too much when I last had a hard drive incident in 2004 or 2005
  822. # [14:38] <Lachy> is the disk functional at all?
  823. # [14:39] <hsivonen> It makes bad noise and doesn't automount
  824. # [14:39] <Lachy> ok. That might make it difficult to use data recovery software
  825. # [14:40] <hsivonen> however, I have an offsite backup that was taken just a couple of days before that disk was cloned
  826. # [14:40] <hsivonen> and since then, I have done very little that I don't also have on the internal drive
  827. # [14:41] <hsivonen> anyway, I guess I'll just have to bite the bullet, take the offsite backup and merge it and the internal drive state to a RAID
  828. # [14:41] <Lachy> I'm hoping I never run into that problem again. Although, I need to keep increasing my amount of storage space.
  829. # [14:41] <hsivonen> the reason why I hadn't taken the RAID to use is that I was unable to get my whole home directory working off NFS
  830. # [14:42] <hsivonen> I think I'm going to try to use AFP with ~/Library on a local disk and everything else symlinked to the RAID
  831. # [14:42] <Lachy> so far, I'm up to 8TB worth of external drives. It's not quite enough though
  832. # [14:43] <hsivonen> I started to use Flickr in order to have an in-the-cloud copy of my photos, but I'm 7 months behind getting my photos uploaded
  833. # [14:45] <Lachy> I want an in-the-cloud copy of my ripped DVD collection. But I don't have the bandwidth up upload 2TB worth of ISOs, nor any cost effective storage provider
  834. # [14:45] <hsivonen> well, there are a ton of backups of popular culture around
  835. # [14:46] <Lachy> where?
  836. # [14:46] <hsivonen> I'm worried about data I produce myself and the isn't on Flickr, on hsivonen.iki.fi, in svn or in hg yet
  837. # [14:46] <hsivonen> in any DVD store
  838. # [14:46] <Lachy> that defeates the purpose of ripping the data off the discs in the first place
  839. # [14:49] * Quits: nessy (n=nessy@124-170-249-152.dyn.iinet.net.au) ("This computer has gone to sleep")
  840. # [14:50] <hsivonen> I did the stupid, stupid thing when the failed drive started making noise. I turned it off. I should have kept in on and started to copy it to another drive immediately.
  841. # [14:51] <Philip`> zcorpan: If you don't care about it being in a helpfully processed format, try http://philip.html5.org/data/type-audio-video-raw.txt
  842. # [14:54] <hsivonen> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jul/0128.html
  843. # [14:56] <gsnedders|work> Where is event-source nowadays?
  844. # [14:56] <hsivonen> gsnedders|work: in JS only
  845. # [14:56] <hsivonen> IIRC
  846. # [14:58] <gsnedders|work> hsivonen: What spec is it? Where?
  847. # [14:58] <hsivonen> oh. No idea.
  848. # [14:58] <takkaria> gsnedders|work: http://dev.w3.org/html5/eventsource/
  849. # [14:58] <gsnedders|work> takkaria: thx
  850. # [14:59] <takkaria> gsnedders|work: honestly, http://lmgtfy.com/?q=EventSource+html5
  851. # [15:00] <gsnedders|work> takkaria: Oh, I didn't include the html5 bit :P
  852. # [15:00] <takkaria> hsivonen: I don't even understand that message
  853. # [15:01] <hsivonen> http://www.zeldman.com/2009/07/16/html-5-is-a-mess-now-what/#comment-44915
  854. # [15:01] <hsivonen> "Also, I got tired of really nasty people sending me almost illegal hate mail on these subjects – hardly a professional approach to doing business."
  855. # [15:01] <hsivonen> that's not good
  856. # [15:05] * hsivonen wonders who has been sending hate mail in the name of HTML5 and what can be done about it
  857. # [15:11] * Joins: taf2_ (n=taf2@38.99.201.242)
  858. # [15:15] <Philip`> I don't quite understand how he complains about it being Hixie's spec and a despotic regime, and then complains about design by committee - surely it can't be both?
  859. # [15:15] * Philip` wonders if he's missing something
  860. # [15:16] <takkaria> I think that's part of the problem
  861. # [15:17] * hsivonen also wonders if the hate mail has been actually sent by people or by *a* person
  862. # [15:23] <Lachy> I wonder why anyone would be sending him hate mail about HTML5?
  863. # [15:23] <Lachy> maybe it would be worth contacting him for clarification
  864. # [15:28] <zcorpan> Philip`: thanks!
  865. # [15:34] * Quits: annodomini (n=lambda@wikipedia/lambda)
  866. # [15:39] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Read error: 113 (No route to host))
  867. # [15:42] * Joins: JoePeck (n=JoePeck@jpecoraro.rit.edu)
  868. # [15:45] * Joins: sgalineau (n=sylvaing@c-98-247-143-102.hsd1.wa.comcast.net)
  869. # [15:46] * Joins: aroben (n=aroben@unaffiliated/aroben)
  870. # [15:52] * Quits: archtech (n=stanv@83.228.56.37)
  871. # [15:56] * Joins: ap (n=ap@174-145-34-186.pools.spcsdns.net)
  872. # [16:00] * Joins: sbublava (n=stephan@77.119.160.139.wireless.dyn.drei.com)
  873. # [16:07] * Joins: kristallpirat (n=kristall@c-base/crew/kristall)
  874. # [16:07] * Quits: ap (n=ap@174-145-34-186.pools.spcsdns.net)
  875. # [16:12] * Joins: annodomini (n=lambda@wikipedia/lambda)
  876. # [16:14] * Joins: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
  877. # [16:16] <gsnedders|work> Does Mozilla still support HTMLUnknownElement?
  878. # [16:17] <Lachy> gsnedders|work, <foo></foo><script>w(document.getElementsByTagName("foo")[0])</script>
  879. # [16:17] <Lachy> apparently, yes
  880. # [16:18] <takkaria> alert(HTMLUnknownElement) would work just as well, surely?
  881. # [16:19] <Lachy> takkaria, don't make things unnecessarily easy!
  882. # [16:20] <takkaria> k
  883. # [16:23] * Parts: zcorpan (n=zcorpan@pat.se.opera.com)
  884. # [16:23] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  885. # [16:25] <Philip`> gsnedders|work: You should read through the source code to find out
  886. # [16:25] <Philip`> Anything else is just cheating
  887. # [16:26] <gsnedders|work> Philip`: or grep
  888. # [16:27] * Joins: webben (n=benh@nat/yahoo/x-55f04858fe366393)
  889. # [16:31] * Parts: Mrmil (n=ut_ollie@77.236.204.8)
  890. # [16:33] <zcorpan> Philip`: was the type="" thing from the 425k set?
  891. # [16:34] <Philip`> zcorpan: Yes
  892. # [16:35] <zcorpan> Philip`: ok
  893. # [16:39] <gsnedders|work> How can I stop if (HTMLUnknownElement) from throwing?
  894. # [16:40] <gsnedders|work> if (typeof HTMLUnknownElement != 'undefined')
  895. # [16:41] <zcorpan> gsnedders|work: yes
  896. # [16:42] <zcorpan> http://simon.html5.org/dump/type-audio-video-philip-dotbot.xml
  897. # [16:42] <zcorpan> also http://simon.html5.org/dump/type-audio-video-google-code-search.txt
  898. # [16:42] * Quits: sgalineau (n=sylvaing@c-98-247-143-102.hsd1.wa.comcast.net) (Read error: 110 (Connection timed out))
  899. # [16:46] * Joins: sgalineau (n=sylvaing@nat/microsoft/x-90c9a8a33c3f9500)
  900. # [16:52] * Quits: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
  901. # [16:56] * zcorpan added links to http://wiki.whatwg.org/wiki/Video_type_parameters
  902. # [16:56] * Joins: webben_ (n=benh@nat/yahoo/x-e62c1651083a27d4)
  903. # [17:01] <zcorpan> http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/conf/mime.types - hmm, i can't find mime.types for apache 2.2.x
  904. # [17:02] <zcorpan> or is that the latest mime.types?
  905. # [17:05] * Joins: billmason (n=billmaso@69.30.57.136)
  906. # [17:06] * Quits: webben (n=benh@nat/yahoo/x-55f04858fe366393) (Read error: 113 (No route to host))
  907. # [17:07] * Quits: maikmerten (n=merten@129.217.26.196) (Remote closed the connection)
  908. # [17:10] * Quits: sgalineau (n=sylvaing@nat/microsoft/x-90c9a8a33c3f9500) (Read error: 110 (Connection timed out))
  909. # [17:10] * Joins: archtech (n=stanv@83.228.56.37)
  910. # [17:11] * Joins: sgalineau (n=sylvaing@nat/microsoft/x-75a49eefcfa437f3)
  911. # [17:12] * Joins: dglazkov (n=dglazkov@nat/google/x-f0328ac3110c37f7)
  912. # [17:12] <zcorpan> is the dom viewer broken in ie8 again?
  913. # [17:13] <zcorpan> or at least the w() function
  914. # [17:13] <Rik|work> zcorpan: xss protection ?
  915. # [17:13] <zcorpan> Rik|work: i have that disabled
  916. # [17:13] <zcorpan> ie says there's a script error
  917. # [17:17] * Quits: taf2_ (n=taf2@38.99.201.242)
  918. # [17:45] * Disconnected
  919. # [17:45] * Attempting to rejoin channel #whatwg
  920. # [17:46] * Rejoined channel #whatwg
  921. # [17:46] * Topic is 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks!'
  922. # [17:46] * Set by annevk on Thu Feb 05 13:51:18
  923. # [17:46] <remysharp> there's an oninput event?
  924. # [17:46] <sebmarkbage> no, just in Gecko, and only for textareas/textboxes.
  925. # [17:46] <remysharp> ah, right. Hm - let me try to explain better
  926. # [17:46] <remysharp> if I use contenteditable on a p element
  927. # [17:46] * Quits: JoePeck (n=JoePeck@jpecoraro.rit.edu)
  928. # [17:46] <sebmarkbage> actually oninput is in HTML5 too
  929. # [19:46] * Disconnected
  930. # [19:47] * Attempting to rejoin channel #whatwg
  931. # [19:48] * Rejoined channel #whatwg
  932. # [19:48] * Topic is 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks!'
  933. # [19:48] * Set by annevk on Thu Feb 05 13:51:18
  934. # [19:51] <takkaria> gsnedders: I got it working. :)
  935. # [19:55] * Quits: abii (n=macbook@cm27.delta30.maxonline.com.sg)
  936. # [19:58] * Joins: aarron (n=aarron@97.81.84.39)
  937. # [20:02] * Joins: jwalden_ (n=waldo@nat/mozilla/x-2ec3054323fdf194)
  938. # [20:02] * Quits: sgalineau (n=sylvaing@nat/microsoft/x-75a49eefcfa437f3) (Read error: 104 (Connection reset by peer))
  939. # [20:03] * Quits: webben_ (n=benh@nat/yahoo/x-e62c1651083a27d4) (Read error: 60 (Operation timed out))
  940. # [20:04] * Quits: thin (n=maurice@64.150.222.36)
  941. # [20:07] * Joins: JoePeck (n=JoePeck@129.21.65.24)
  942. # [20:09] * Joins: jorlow (n=jorlow@nat/google/x-058fbb689978bdef)
  943. # [20:10] * Quits: jwalden (n=waldo@nat/mozilla/x-58fa72ecd94b8b3e) (Read error: 110 (Connection timed out))
  944. # [20:11] * Joins: ttepasse (n=ttepas--@p5B014C24.dip.t-dialin.net)
  945. # [20:13] * Joins: bgalbraith (n=bgalbrai@nat/mozilla/x-f5e1aa88e67f8c93)
  946. # [20:13] * Quits: dglazkov (n=dglazkov@nat/google/x-f0328ac3110c37f7)
  947. # [20:16] <gsnedders> takkaria: Oh dear… find something more useful!
  948. # [20:16] * Quits: dave_levin (n=dave_lev@72.14.224.1)
  949. # [20:31] * Quits: jorlow (n=jorlow@nat/google/x-058fbb689978bdef) (Read error: 110 (Connection timed out))
  950. # [20:33] * aroben|lunch is now known as aroben
  951. # [20:37] * gsnedders finds a ton of tweets mentioning him, all because of Henny
  952. # [20:40] * Joins: Lachy (n=Lachlan@85.196.122.246)
  953. # [20:40] <takkaria> hm, it doesn't look like you can define getters on HTMLElement
  954. # [20:42] <gsnedders> Really? I think you _should_ be able to.
  955. # [20:42] <gsnedders> jgraham would know…
  956. # [20:42] <gsnedders> Wow, BTS3 is so much quicker than during work hours.
  957. # [20:43] <takkaria> hmm
  958. # [20:43] <takkaria> OK, I was being a bit hopeful really
  959. # [20:43] <takkaria> you can override it
  960. # [20:51] * Joins: dave_levin (n=dave_lev@72.14.227.1)
  961. # [21:01] * Quits: taf2_ (n=taf2@38.99.201.242)
  962. # [21:08] * Quits: dimich_ (n=dimich@72.14.224.1)
  963. # [21:08] * Quits: onar_ (n=onar@c-67-180-87-66.hsd1.ca.comcast.net)
  964. # [21:12] * Quits: danbri (n=danbri@unaffiliated/danbri)
  965. # [21:14] * Joins: yshin (n=yshin@72.14.227.1)
  966. # [21:16] * Joins: sgalineau (n=sylvaing@nat/microsoft/x-d437c3ef839e9ec2)
  967. # [21:16] * Joins: weinig (n=weinig@nat/apple/x-ca4ebfb770a95bb2)
  968. # [21:18] * Quits: dolske (n=dolske@76.103.40.203) (Read error: 110 (Connection timed out))
  969. # [21:21] * Joins: dolske (n=dolske@nat/mozilla/x-6da13258cd0ecd35)
  970. # [21:28] * Joins: jorlow (n=jorlow@nat/google/x-573d1c179190efc9)
  971. # [21:36] * Joins: danbri (n=danbri@s5590d015.adsl.wanadoo.nl)
  972. # [21:42] * Quits: sbublava (n=stephan@77.119.160.139.wireless.dyn.drei.com)
  973. # [21:45] * Quits: bgalbraith (n=bgalbrai@nat/mozilla/x-f5e1aa88e67f8c93)
  974. # [21:50] * Joins: Sidnicious (n=Sidney@unaffiliated/sidnicious)
  975. # [21:52] * Quits: archtech (n=stanv@83.228.56.37) (No route to host)
  976. # [21:52] <Sidnicious> I want to ask a question to solve a discussion from #html: If one is abandoning XHTML for a page, should he use the new doctype or an HTML 4 doctype? How do older browsers handle <DOCTYPE html>?
  977. # [21:52] <Sidnicious> s/#html/#css/
  978. # [21:54] <Philip`> Sidnicious: It makes old browsers render in standards mode (instead of quirks mode)
  979. # [21:55] <Philip`> Sidnicious: See e.g. the table near the bottom of http://hsivonen.iki.fi/doctype/
  980. # [21:56] <Sidnicious> The people I'm talking to think of HTML 5 as separate from HTML 4, and believe that it's dangerous to use the new doctype until HTML 5 is officially supported by every popular browser
  981. # [21:58] <gsnedders> Sidnicious: It is officially supported to some extent in all browsers.
  982. # [21:58] <Philip`> Sidnicious: Every popular browser behaves precisely the same if you use <!DOCTYPE html> as if you use e.g. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
  983. # [21:59] <Philip`> Sidnicious: (That also works the other way, so you can use HTML5 features like <canvas> and <video> with an HTML4 doctype exactly the same as with the HTML5 doctype)
  984. # [22:01] * Joins: bgalbraith (n=bgalbrai@nat/mozilla/x-ea4947f3eb591c35)
  985. # [22:01] <Sidnicious> Philip`: Great, thank you.
  986. # [22:04] <gsnedders> Sidnicious: The only difference is in what is conforming, and what throws a validation error (though almost everything from HTML 4.01 Strict is conforming HTML 5)
  987. # [22:05] * Quits: jorlow (n=jorlow@nat/google/x-573d1c179190efc9)
  988. # [22:05] * Joins: nessy (n=nessy@124-170-249-152.dyn.iinet.net.au)
  989. # [22:07] * Quits: weinig (n=weinig@nat/apple/x-ca4ebfb770a95bb2)
  990. # [22:09] * Joins: jorlow (n=jorlow@nat/google/x-aabe64cba94ffd85)
  991. # [22:16] * Joins: zdobersek1 (n=zan@cpe-92-37-74-196.dynamic.amis.net)
  992. # [22:16] * Joins: zcorpan (n=zcorpan@c83-252-201-53.bredband.comhem.se)
  993. # [22:19] * Quits: aarron (n=aarron@97.81.84.39)
  994. # [22:21] * Joins: weinig (n=weinig@17.246.19.126)
  995. # [22:24] * Joins: dglazkov (n=dglazkov@nat/google/x-ab41287b8655c308)
  996. # [22:25] * Joins: mat_t (n=mattomas@ppp-3-250.glou-b-1.access.uk.tiscali.com)
  997. # [22:25] * Quits: mat_t (n=mattomas@ppp-3-250.glou-b-1.access.uk.tiscali.com) (Remote closed the connection)
  998. # [22:25] * Quits: maikmerten (n=maikmert@BAE2149.bae.pppool.de) (Remote closed the connection)
  999. # [22:26] * Quits: jianli (n=jianli@72.14.227.1)
  1000. # [22:30] * Quits: nessy (n=nessy@124-170-249-152.dyn.iinet.net.au) ("This computer has gone to sleep")
  1001. # [22:31] * Quits: zdobersek (n=zan@cpe-92-37-66-28.dynamic.amis.net) (Read error: 110 (Connection timed out))
  1002. # [22:34] * Quits: zcorpan (n=zcorpan@c83-252-201-53.bredband.comhem.se) (Read error: 110 (Connection timed out))
  1003. # [22:37] * Quits: jorlow (n=jorlow@nat/google/x-aabe64cba94ffd85) (Remote closed the connection)
  1004. # [22:37] * Joins: jorlow (n=jorlow@nat/google/x-f8b272b4653c235c)
  1005. # [22:39] * Quits: weinig (n=weinig@17.246.19.126) (Remote closed the connection)
  1006. # [22:39] * Joins: weinig (n=weinig@nat/apple/x-8fa10c9a5f1c2acc)
  1007. # [22:53] * Quits: kristallpirat (n=kristall@c-base/crew/kristall) ("Wünsche weiterhin guten Flug")
  1008. # [22:58] * Joins: onar_ (n=onar@17.226.23.106)
  1009. # [22:59] * Quits: JoePeck (n=JoePeck@129.21.65.24)
  1010. # [23:01] * aroben is now known as aroben|meeting
  1011. # [23:04] * Joins: poe (n=xerox@unaffiliated/xerox)
  1012. # [23:05] * Parts: poe (n=xerox@unaffiliated/xerox)
  1013. # [23:08] * Quits: onar_ (n=onar@17.226.23.106)
  1014. # [23:08] * Quits: dglazkov (n=dglazkov@nat/google/x-ab41287b8655c308) (Remote closed the connection)
  1015. # [23:08] * Joins: dglazkov (n=dglazkov@nat/google/x-08b0bb134d20ce1b)
  1016. # [23:19] * Quits: tantekc (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  1017. # [23:23] <gsnedders> "Mark as read" on 500 emails feels good.
  1018. # [23:23] <takkaria> disgusting
  1019. # [23:23] <Sidnicious> But... but... you didn't read them!
  1020. # [23:23] <takkaria> it's only 23:20, I'm sure you could read them all before bed :p
  1021. # [23:24] <gsnedders> I don't read everything on help mailing lists!
  1022. # [23:24] <Philip`> If you lie to your mail client like that, how do I know you're not going to lie to me? :-(
  1023. # [23:24] <ezyang> You sir, need mail filters
  1024. # [23:24] <gsnedders> ezyang: I have mail filters.
  1025. # [23:24] <ezyang> oh ho, so it's not 500 emails in your inbox :-)
  1026. # [23:24] <gsnedders> ezyang: Hell no, my inbox is almost always at zero unread.
  1027. # [23:25] <gsnedders> ezyang: It's mainly css-d, thelist, MySQL General Discussion and such like which are unread
  1028. # [23:25] <Sidnicious> gsnedders: At that point, why not just delete them and go to the list archives? Are you maintaining your own personal archive of each list?
  1029. # [23:26] <gavin_> Hixie: is it just me or does http://www.whatwg.org/specs/web-apps/current-work/#concept-error-nothandled not point to the right place?
  1030. # [23:26] <gsnedders> Sidnicious: Because then I have the hassle of resubscribing whenever I want to ask a question.
  1031. # [23:26] <gavin_> it's one line below http://www.whatwg.org/specs/web-apps/current-work/#report-the-error
  1032. # [23:26] <Sidnicious> No, I mean deleting older messages, keeping your subscription to the list.
  1033. # [23:26] <gsnedders> Sidnicious: Oh, no reason
  1034. # [23:26] <gsnedders> Sidnicious: Disk space is cheap
  1035. # [23:27] <Sidnicious> Heh. Fair enough.
  1036. # [23:27] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  1037. # [23:27] <gsnedders> (Actually, that's not true, when dealing with quick 2.5" HDs disk space is fairly expensive, but I have bigger issues than email)
  1038. # [23:28] <Philip`> Disk space is really cheap until you've got one byte more data than you have storage, and then it's really expensive
  1039. # [23:28] <ezyang> gsnedders: you can totally have asubscription and instruct it not to send you messages.
  1040. # [23:29] <Philip`> (though "really expensive" is relative to e.g. a packet of chocolate biscuits, rather than to e.g. a house)
  1041. # [23:29] <ezyang> and then you add P.S. please cc
  1042. # [23:29] <gsnedders> ezyang: That means remembering :)
  1043. # [23:29] <ezyang> I mean, what mailman really should do is let you send only conversations that you care about :-)
  1044. # [23:29] <gsnedders> ezyang: see http://www.flickr.com/photos/gsnedders/2185019213/ and http://www.flickr.com/photos/gsnedders/2185803994/
  1045. # [23:30] <gsnedders> ezyang: That's really out of date, I have more mailboxes than that now :)
  1046. # [23:30] <gavin_> Hixie: er, I guess it is pointing to the right place (first mention?), but I don't see a definition there
  1047. # [23:30] <Philip`> gavin_: Can you click the term to see a list of all the places it's mentioned?
  1048. # [23:31] <gavin_> yes
  1049. # [23:32] <gavin_> oh, is http://www.whatwg.org/specs/web-apps/current-work/#dfnReturnLink-0 the definition?
  1050. # [23:32] <gavin_> I guess so
  1051. # [23:32] <Philip`> That URL isn't going to work very well over IRC
  1052. # [23:33] <gavin_> hmm?
  1053. # [23:33] <Philip`> It's a locally-generated fragment ID
  1054. # [23:33] <gavin_> huh? the page results are non-deterministic?/
  1055. # [23:34] * Joins: weinig_ (n=weinig@17.246.19.126)
  1056. # [23:34] <gsnedders> Hixie wrote it. Don't assume it will be.
  1057. # [23:34] <gavin_> (why is it locally generated to begin with?)
  1058. # [23:34] <gsnedders> gavin_: Because Hixie told me to write the script to do it on the server, and I haven't written it yet.
  1059. # [23:35] <Philip`> gavin_: I think the idea is that when you click a use of a definition, it jumps to the use by giving it a locally-generated ID (because normally it's just an <a href> without an id)
  1060. # [23:36] <gavin_> I see
  1061. # [23:42] <Hixie> gavin_: the definition is the bold word that says "not handled"
  1062. # [23:42] <Hixie> gavin_: it's just a constant. It could say "after which the error is either grapefruit or pineapple:"
  1063. # [23:44] <gavin_> that's not what I'd call a definition
  1064. # [23:45] <gavin_> but I get it now
  1065. # [23:50] * Quits: weinig (n=weinig@nat/apple/x-8fa10c9a5f1c2acc) (Read error: 110 (Connection timed out))
  1066. # [23:51] <Hixie> i agree that it's not really a definition. not sure what the definition would be though
  1067. # [23:51] <Hixie> it's like "true" and "False"
  1068. # [23:54] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  1069. # [23:55] * Quits: gsnedders (n=gsnedder@c83-252-195-142.bredband.comhem.se)
  1070. # [23:59] * Joins: JoePeck (n=JoePeck@cpe-74-69-85-249.rochester.res.rr.com)
  1071. # Session Close: Sat Jul 18 00:00:00 2009

The end :)