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

Options:

  1. # Session Start: Wed Apr 04 00:00:00 2007
  2. # Session Ident: #whatwg
  3. # [00:00] <KevinMarks> what happened to sequencing?
  4. # [00:01] * Quits: othermaciej (i=mjs@nat/apple/x-4e91ed9e92950315) (Read error: 104 (Connection reset by peer))
  5. # [00:02] * Joins: othermaciej (i=mjs@nat/apple/x-938a5adb0c49ecab)
  6. # [00:02] <othermaciej> Hixie: I think everything should reset but probably a single "emptied" event is ok to express, not sure offhand
  7. # [00:02] <othermaciej> KevinMarks: I don't think sequencing is in yet
  8. # [00:04] <KevinMarks> this kind of stuff is why trying to handle sequencing in the js layer is hard
  9. # [00:05] <Hixie> othermaciej: so not even an 'abort' event?
  10. # [00:05] <othermaciej> Hixie: I'm not up to speed on the current state of the events
  11. # [00:06] <hsivonen> Hixie: I see (Re: no enforceable patents of Baseline)
  12. # [00:06] <hsivonen> markp: I'm glad to see you can finally talk with us. Welcome.
  13. # [00:07] <hsivonen> markp: can you say what your job at Google is? are you going to work on Web Forms 2.0 accessibility in Gecko?
  14. # [00:07] <othermaciej> KevinMarks: the main reason for built-in sequencing is the same as looping, that you can better avoid glitches by appropriately pre-buffering
  15. # [00:08] <Hixie> othermaciej: 'abort' would be the progress event, from DOM Level 0
  16. # [00:09] <othermaciej> Hixie: would probably make sense to have that, since it has more general purposes than UI control state
  17. # [00:09] <Hixie> yeah, just not sure when to fire it
  18. # [00:12] <KevinMarks> yes
  19. # [00:16] <markp> hsivonen: hi; yes, i can talk to you (on company time, even!); my official title is "lead technical writer"; my position involves some of these things: http://www.google.com/support/jobs/bin/answer.py?answer=53090 ; i am no longer working on firefox or accessibility issues
  20. # [00:18] * Quits: karlUshi (n=karl@124-144-94-185.rev.home.ne.jp) ("Where dwelt Ymir, or wherein did he find sustenance?")
  21. # [00:21] <hsivonen> markp: ok
  22. # [00:40] * Quits: markp (n=pilgrim@adsl-221-33-29.rmo.bellsouth.net) (Read error: 113 (No route to host))
  23. # [00:40] * Quits: hendry (n=hendry@91.84.53.136) (Remote closed the connection)
  24. # [01:06] * Quits: KevinMarks (i=KevinMar@pdpc/supporter/active/kevinmarks) ("The computer fell asleep")
  25. # [01:08] * Joins: hober (n=ted@unaffiliated/hober)
  26. # [01:09] * Joins: KevinMarks (i=KevinMar@nat/google/x-0b2ea348a8f3c87f)
  27. # [01:17] * Joins: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  28. # [01:18] * Quits: tylerr (n=tylerr@outbound.wa1.ascentium.com) ("Leaving")
  29. # [01:19] <Hixie> ok we're gonna synchronously fire an 'abort' event while load() is running, followed by an 'emptied' event.
  30. # [01:19] <Hixie> the next questios whether to fire the 'begin' event before or after the method returns
  31. # [01:19] <Hixie> and whether to set the state to LOADING before or after the method returns
  32. # [01:19] <Hixie> i'm pretty sure we want to set LOADING before.
  33. # [01:20] <Hixie> but if we fire 'begin' afterwards, that would mean there's a period of time where it's LOADING and there is script running even though the 'begin' event hasn't fired yet
  34. # [01:20] <Hixie> i suppose now that we have 'abort' firing synchronously we can do the same with 'bugin'
  35. # [01:20] <Hixie> 'begin' even
  36. # [01:21] * Joins: htmlr (n=cjb@203-206-237-84.dyn.iinet.net.au)
  37. # [01:21] * Quits: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  38. # [01:34] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  39. # [01:35] * Quits: othermaciej (i=mjs@nat/apple/x-938a5adb0c49ecab) (Read error: 104 (Connection reset by peer))
  40. # [01:36] <Hixie> hm, we're gonna have to change the html parsing spec to not drop <option> elements to support web forms 2 <datalist>
  41. # [01:43] * Joins: RCanine (n=ryan@c-68-42-71-188.hsd1.mi.comcast.net)
  42. # [01:52] * Quits: gavin (n=gavin@firefox/developer/gavin) (Read error: 104 (Connection reset by peer))
  43. # [01:52] * Joins: welly (n=welly@62-31-60-148.cable.ubr12.azte.blueyonder.co.uk)
  44. # [01:53] * Joins: markp (n=pilgrim@adsl-221-33-29.rmo.bellsouth.net)
  45. # [01:56] * Joins: karlUshi (n=karl@133.27.246.23)
  46. # [01:56] * Quits: htmlr (n=cjb@203-206-237-84.dyn.iinet.net.au) (Read error: 113 (No route to host))
  47. # [01:56] * Joins: htmlr (n=cjb@CPE-138-130-176-60.nsw.bigpond.net.au)
  48. # [01:57] * Joins: gavins (n=gavin@firefox/developer/gavin)
  49. # [02:00] * Quits: KevinMarks (i=KevinMar@pdpc/supporter/active/kevinmarks) ("The computer fell asleep")
  50. # [02:02] * Joins: mpt (n=mpt@121-72-128-156.dsl.telstraclear.net)
  51. # [02:04] * Joins: markp_ (n=pilgrim@adsl-221-33-29.rmo.bellsouth.net)
  52. # [02:05] * Joins: Lachy__ (n=chatzill@220-245-91-147.static.tpgi.com.au)
  53. # [02:05] * Lachy__ is now known as Lachy
  54. # [02:07] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.1.3 (IRC client for Emacs)")
  55. # [02:11] * Joins: KevinMarks (i=KevinMar@nat/google/x-9fd36788e5d30f4a)
  56. # [02:14] * Quits: h3h (n=h3h@66-162-32-234.static.twtelecom.net) ("|")
  57. # [02:18] * Quits: Lachy (n=chatzill@220-245-91-147.static.tpgi.com.au) ("Chatzilla 0.9.77 [Firefox 2.0.0.3/2007030919]")
  58. # [02:20] * Quits: markp (n=pilgrim@adsl-221-33-29.rmo.bellsouth.net) (Read error: 110 (Connection timed out))
  59. # [02:21] * Joins: markp__ (n=pilgrim@adsl-221-33-29.rmo.bellsouth.net)
  60. # [02:21] * markp__ is now known as markp
  61. # [02:22] * Quits: markp (n=pilgrim@adsl-221-33-29.rmo.bellsouth.net) (Client Quit)
  62. # [02:24] * Joins: Lachy (n=chatzill@58.105.240.232)
  63. # [02:32] * Quits: markp_ (n=pilgrim@adsl-221-33-29.rmo.bellsouth.net) (Read error: 113 (No route to host))
  64. # [02:32] * Joins: yod (n=ot@softbank221018155222.bbtec.net)
  65. # [02:34] * Joins: marcosc_ (n=chatzill@131.181.148.226)
  66. # [02:36] * Joins: htmlr_ (n=cjb@203-206-237-84.dyn.iinet.net.au)
  67. # [02:40] * Quits: RCanine (n=ryan@c-68-42-71-188.hsd1.mi.comcast.net)
  68. # [02:41] * Quits: marcosc (n=chatzill@131.181.148.226) (Read error: 60 (Operation timed out))
  69. # [02:54] * Quits: htmlr (n=cjb@CPE-138-130-176-60.nsw.bigpond.net.au) (Read error: 110 (Connection timed out))
  70. # [02:56] * Joins: h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com)
  71. # [02:59] * Quits: h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com) (Client Quit)
  72. # [03:04] * Joins: RCanine (n=ryan@c-68-61-156-82.hsd1.mi.comcast.net)
  73. # [03:11] * Quits: Dashiva (i=Dashiva@v035b.studby.ntnu.no)
  74. # [03:12] * Joins: h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com)
  75. # [03:16] * Joins: Dashiva (i=Dashiva@v035b.studby.ntnu.no)
  76. # [03:18] * Parts: a-ja (n=chatzill@adsl-70-237-142-180.dsl.stlsmo.sbcglobal.net)
  77. # [03:18] * Joins: a-ja (n=chatzill@adsl-70-237-142-180.dsl.stlsmo.sbcglobal.net)
  78. # [03:19] * Quits: a-ja (n=chatzill@adsl-70-237-142-180.dsl.stlsmo.sbcglobal.net) ("Chatzilla 0.9.73-rdmsoft [XULRunner 1.9a1/2006042715]")
  79. # [03:21] * Quits: welly (n=welly@62-31-60-148.cable.ubr12.azte.blueyonder.co.uk)
  80. # [03:24] * Quits: kingryan (n=kingryan@dsl092-187-033.sfo1.dsl.speakeasy.net)
  81. # [03:26] * Quits: KevinMarks (i=KevinMar@nat/google/x-9fd36788e5d30f4a) ("The computer fell asleep")
  82. # [03:40] * Quits: bzed (n=bzed@dslb-084-059-120-121.pools.arcor-ip.net) ("Leaving")
  83. # [03:41] * Quits: RCanine (n=ryan@c-68-61-156-82.hsd1.mi.comcast.net)
  84. # [04:05] * Quits: gavins (n=gavin@firefox/developer/gavin) (Read error: 60 (Operation timed out))
  85. # [04:05] * Joins: gavins (n=gavin@firefox/developer/gavin)
  86. # [04:13] * Joins: RCanine (n=ryan@c-68-61-156-82.hsd1.mi.comcast.net)
  87. # [04:24] * Quits: Philip` (n=excors@zaynar.demon.co.uk)
  88. # [04:24] * Quits: RCanine (n=ryan@c-68-61-156-82.hsd1.mi.comcast.net)
  89. # [04:43] * Quits: tantek_ (n=tantek@dsl092-187-033.sfo1.dsl.speakeasy.net)
  90. # [04:54] * moeffju is now known as moeffju[ZzZz]
  91. # [05:04] * Joins: RCanine (n=ryan@c-68-61-156-82.hsd1.mi.comcast.net)
  92. # [05:19] * Joins: tantek (n=tantek@c-71-202-220-222.hsd1.ca.comcast.net)
  93. # [05:34] * Quits: tantek (n=tantek@c-71-202-220-222.hsd1.ca.comcast.net) (Read error: 145 (Connection timed out))
  94. # [05:44] * Joins: jcgregorio (n=chatzill@adsl-072-148-043-048.sip.rmo.bellsouth.net)
  95. # [05:45] * Quits: RCanine (n=ryan@c-68-61-156-82.hsd1.mi.comcast.net)
  96. # [05:54] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  97. # [05:55] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  98. # [05:59] * Joins: zcorpan (n=zcorpan@esk-ba-1-nomad.net.mdh.se)
  99. # [06:00] <zcorpan> morning
  100. # [06:01] <Lachy> hey zcorpan
  101. # [06:01] <Lachy> how did your interview at Opera go?
  102. # [06:05] * Joins: zcorpan_ (n=zcorpan@esk-ba-1-nomad.net.mdh.se)
  103. # [06:10] <zcorpan_> Lachy: it went well (see logs)
  104. # [06:10] <Lachy> in this channel or #html-wg?
  105. # [06:10] <Lachy> and on what date?
  106. # [06:11] * Joins: zcorpan__ (n=zcorpan@esk-ba-1-nomad.net.mdh.se)
  107. # [06:11] * othermaciej wonders if he could get a req approved to hire a standards expert so he can order others to flame on mailing lists and go to useless meetings instead of doing it himself
  108. # [06:12] <zcorpan__> 18:19 20070403 #whatwg
  109. # [06:13] * Joins: RCanine (n=ryan@c-68-42-71-188.hsd1.mi.comcast.net)
  110. # [06:16] <Lachy> where is Jönköping?
  111. # [06:16] * Lachy looks it up in google maps...
  112. # [06:17] <Lachy> ah, Sweeden
  113. # [06:19] <zcorpan__> content authors will continue to use flash until <video> works with one codec across the browsers the author cares about
  114. # [06:20] <zcorpan__> then they might reconsider
  115. # [06:21] * Quits: zcorpan (n=zcorpan@esk-ba-1-nomad.net.mdh.se) (Read error: 110 (Connection timed out))
  116. # [06:22] * Joins: KevinMarks (n=KevinMar@h-68-164-93-9.snvacaid.dynamic.covad.net)
  117. # [06:22] * zcorpan__ is now known as zcorpan
  118. # [06:24] <Lachy> and they will only switch from flash to <video> if there are clear benefits to do so
  119. # [06:25] <Hixie> othermaciej: if you do do that, make sure it's someone who actually knows what they're talking about
  120. # [06:25] <Hixie> othermaciej: a lot of companies will hire ivory tower people to do that and that's how you end up in the mess we have now :-)
  121. # [06:26] * Quits: zcorpan_ (n=zcorpan@esk-ba-1-nomad.net.mdh.se) (Read error: 110 (Connection timed out))
  122. # [06:26] <othermaciej> Hixie: I would only hire someone for such a post whose standards-related work I was personally familiar with, most likely
  123. # [06:26] <Hixie> that works
  124. # [06:27] <othermaciej> I think I know which subset of those reflects a good set of web standards values
  125. # [06:28] <KevinMarks> do what?
  126. # [06:29] <othermaciej> KevinMarks: that's a convoluted way of saying "people who are not idiots and whose opinions about web stuff are reasonably similar to my own"
  127. # [06:31] <zcorpan> what will the hired someone do?
  128. # [06:32] <othermaciej> participate in standards groups, help develop standards, help write specs for apple proposed standard features, make standards-driven test cases for both official standard body use and for webkit regression testing use
  129. # [06:32] <othermaciej> but I'm not yet sure if I need a special person to do that or can get people I work with to do more of that kind of stuff
  130. # [06:33] <Lachy> do you have anyone in mind who you'd like to hire. if you could?
  131. # [06:34] * Quits: dbaron (n=dbaron@corp-242.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  132. # [06:35] <othermaciej> I have a likely short list in mind, but probably not worth discussing further until the position is less hypothetical
  133. # [06:35] <Lachy> fair enough
  134. # [06:35] <KevinMarks> would that include iTunes baroque RSS support or is this a pure webkit position?
  135. # [06:36] <othermaciej> mainly web standards that are relevant to Safari/WebKit though I'd hope there could be internal advocacy to other teams at Apple when appropriate
  136. # [06:36] <othermaciej> (lord knows I don't have the time for such things)
  137. # [06:55] * Quits: jcgregorio (n=chatzill@adsl-072-148-043-048.sip.rmo.bellsouth.net) ("ChatZilla 0.9.78 [Firefox 2.0.0.2/0000000000]")
  138. # [07:07] <karlUshi> othermaciej: I think it is a mistake to hire someone for a standard group as it disconnects the person from the real work in the team. It would work only if the person was really working with all engineers on a daily basis.
  139. # [07:07] * Joins: icaaq_ (i=icaaaq@c-a237e455.231-7-64736c10.cust.bredbandsbolaget.se)
  140. # [07:08] <othermaciej> karlUshi: I would expect such a person to work actively with the team, though probably more on testing than implementation
  141. # [07:08] <karlUshi> though someone specialist of Web stuff advocating to all teams developing things related to html inside the company could indeed be a good thing
  142. # [07:08] <karlUshi> othermaciej: yes testing seems a good option
  143. # [07:09] <karlUshi> for spec writing we lack often of good technical writers too, or at least technical writers for reviewing the spec.
  144. # [07:10] <karlUshi> hmmm thinking of it. Apple might have in-house technical writers who could read stuff
  145. # [07:11] <othermaciej> we have tech writers but I think at best they could help with copyediting
  146. # [07:19] * Quits: h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com)
  147. # [07:19] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net) (" then we we")
  148. # [07:24] * Quits: zcorpan (n=zcorpan@esk-ba-1-nomad.net.mdh.se) (Read error: 110 (Connection timed out))
  149. # [07:27] * Joins: zcorpan (n=zcorpan@esk-ba-1-nomad.net.mdh.se)
  150. # [07:28] * Quits: RCanine (n=ryan@c-68-42-71-188.hsd1.mi.comcast.net)
  151. # [07:30] <zcorpan> with firefox 3, i can finally start to use display:inline-block. :) floats can be such a pita when you really just want inline-block
  152. # [07:35] * Quits: MikeSmith (n=MikeSmit@58.157.21.205) ("Get thee behind me, satan.")
  153. # [07:36] * Quits: KevinMarks (n=KevinMar@h-68-164-93-9.snvacaid.dynamic.covad.net) ("biab")
  154. # [07:36] * Joins: KevinMarks (n=Snak@h-68-164-93-9.snvacaid.dynamic.covad.net)
  155. # [07:45] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  156. # [07:49] * Joins: MikeSmith (n=MikeSmit@58.157.21.205)
  157. # [08:03] * Quits: zcorpan (n=zcorpan@esk-ba-1-nomad.net.mdh.se) (Read error: 110 (Connection timed out))
  158. # [09:12] * Parts: icaaq_ (i=icaaaq@c-a237e455.231-7-64736c10.cust.bredbandsbolaget.se)
  159. # [09:15] <Hixie> othermaciej: when talking about the CAN_SHOW_this or that states, complete this sentence: "Media elements have a state which describes..."
  160. # [09:16] <othermaciej> "... their current degree of presentability"
  161. # [09:16] <othermaciej> "... their current degree of presentability at the current time position"
  162. # [09:16] <Hixie> that works
  163. # [09:16] <Hixie> thanks
  164. # [09:27] * Quits: Lachy (n=chatzill@58.105.240.232) ("Chatzilla 0.9.77 [Firefox 2.0.0.3/2007030919]")
  165. # [09:34] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net) (" then we we")
  166. # [09:39] * Quits: karlUshi (n=karl@133.27.246.23) ("Where dwelt Ymir, or wherein did he find sustenance?")
  167. # [09:41] * Joins: icaaq_ (i=icaaaq@c-a237e455.231-7-64736c10.cust.bredbandsbolaget.se)
  168. # [09:56] * Quits: yod (n=ot@softbank221018155222.bbtec.net) ("Leaving")
  169. # [10:14] * Joins: zcorpan (n=zcorpan@esk-ba-1-nomad.net.mdh.se)
  170. # [10:18] * Joins: tylerr (n=tylerr@c-24-16-148-66.hsd1.mn.comcast.net)
  171. # [10:20] * Parts: icaaq_ (i=icaaaq@c-a237e455.231-7-64736c10.cust.bredbandsbolaget.se)
  172. # [10:20] * Joins: icaaq_ (i=icaaaq@c-a237e455.231-7-64736c10.cust.bredbandsbolaget.se)
  173. # [10:30] * Joins: welly (n=welly@62-31-60-148.cable.ubr12.azte.blueyonder.co.uk)
  174. # [10:33] * Lachy_ is now known as Lachy
  175. # [10:34] * Quits: welly (n=welly@62-31-60-148.cable.ubr12.azte.blueyonder.co.uk) (Client Quit)
  176. # [10:41] * Quits: htmlr_ (n=cjb@203-206-237-84.dyn.iinet.net.au)
  177. # [11:01] * Parts: icaaq_ (i=icaaaq@c-a237e455.231-7-64736c10.cust.bredbandsbolaget.se)
  178. # [11:03] * Quits: aroben (i=adamrobe@nat/apple/x-4402603ae40e2671)
  179. # [11:06] * Joins: ROBOd (n=robod@86.34.246.154)
  180. # [11:20] * Joins: karlUshi (n=karl@124-144-94-185.rev.home.ne.jp)
  181. # [11:42] * Joins: hendry (n=hendry@91.84.53.136)
  182. # [11:42] * Quits: zcorpan (n=zcorpan@esk-ba-1-nomad.net.mdh.se) (Read error: 110 (Connection timed out))
  183. # [11:44] <Hixie> this <video> patch to introduce the new state systems is gonna be a whopper.
  184. # [11:44] <Hixie> it's over 1500 lines already
  185. # [12:01] * Joins: met_ (n=Martin@b14-4.vscht.cz)
  186. # [12:03] * Quits: tylerr (n=tylerr@c-24-16-148-66.hsd1.mn.comcast.net) ("Leaving")
  187. # [12:12] * Quits: santek (n=st@ut-w-7bd6.mxs.adsl.euronet.nl)
  188. # [12:21] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  189. # [13:14] * Joins: zcorpan (n=zcorpan@84-216-43-95.sprayadsl.telenor.se)
  190. # [13:29] * Joins: Philip` (n=excors@zaynar.demon.co.uk)
  191. # [13:37] <hsivonen> It'll be interesting to see what Nokia ships when Opera is ready to offer them Theora support as part of the engine
  192. # [13:39] <MikeSmith> hsivonen - didn't (somebody) say that there was no way that Nokia would ship Theora?
  193. # [13:41] <hsivonen> MikeSmith: timeless said on the list that they wouldn't. And the manager of the whole Maemo operation earlier said that they wouldn't ship Vorbis without their own people vetting it first (without indication of whether any vetting is actually taking place).
  194. # [13:45] <hsivonen> taking out features from Presto due no an OEM legal policy would be uncool, though
  195. # [13:46] <hsivonen> s/no/to/
  196. # [14:12] <MikeSmith> hsivonen - yeah, certainly would not be the best thing for end users
  197. # [14:13] * moeffju[ZzZz] is now known as moeffju
  198. # [14:27] * Joins: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl)
  199. # [14:32] * Joins: ravenn (n=ravenn@203-206-240-219.dyn.iinet.net.au)
  200. # [14:32] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  201. # [14:46] * Quits: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl) (Read error: 110 (Connection timed out))
  202. # [14:56] * Joins: Dorward (n=Dorward@91.84.53.6)
  203. # [14:57] * Dorward hears a rumour that Hixie is pushing for clients to be allowed to treat text/plain documents as HTML and points out that when Safari did that to http://www.hixie.ch/advocacy/xhtml it became rather difficult to read.
  204. # [14:57] * Joins: Lachy_ (n=Lachlan@124-168-25-222.dyn.iinet.net.au)
  205. # [14:58] <Dashiva> Rumors aren't always that reliable
  206. # [14:58] <Dorward> Dashiva: No, which is why I <em>ed that it was a rumour rather then acting as though it was fact.
  207. # [15:06] <zcorpan> now we need another google project: a blog using genchi
  208. # [15:06] * Quits: Lachy (n=Lachlan@203-214-144-160.perm.iinet.net.au) (Read error: 110 (Connection timed out))
  209. # [15:07] <zcorpan> should be straight-forward to migrate from WP or other popular blogs to that hypothetical blog
  210. # [15:08] <zcorpan> and it should integrate with hsivonens validator
  211. # [15:23] * Quits: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl) (Read error: 110 (Connection timed out))
  212. # [15:26] <Dashiva> "The src content attribute on media elements gives the address of the video to show."
  213. # [15:27] <Dashiva> Hixie: Maybe that should say media instead of video?
  214. # [15:31] * Joins: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl)
  215. # [15:32] * mw22____________ is now known as mw22
  216. # [15:42] * Quits: ravenn (n=ravenn@203-206-240-219.dyn.iinet.net.au) (Client Quit)
  217. # [16:09] * Joins: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl)
  218. # [16:17] * Quits: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl) (Read error: 60 (Operation timed out))
  219. # [16:29] * Quits: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl) (Read error: 110 (Connection timed out))
  220. # [16:30] * Quits: met_ (n=Martin@b14-4.vscht.cz) ("Chemists never die, they just stop reacting.")
  221. # [16:40] * Joins: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl)
  222. # [16:40] * mw22____________ is now known as mw22
  223. # [16:54] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  224. # [17:04] * Quits: MikeSmith (n=MikeSmit@58.157.21.205) ("Get thee behind me, satan.")
  225. # [17:17] * Joins: tantek_ (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  226. # [17:17] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net) (Read error: 104 (Connection reset by peer))
  227. # [17:18] * Joins: h3h (n=h3h@66-162-32-234.static.twtelecom.net)
  228. # [17:21] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca) (Read error: 131 (Connection reset by peer))
  229. # [17:23] * Quits: mpt (n=mpt@121-72-128-156.dsl.telstraclear.net) ("This computer has gone to sleep")
  230. # [17:26] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  231. # [17:48] * Joins: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  232. # [17:55] * Quits: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl) ("Chatzilla 0.9.75-rdmsoft [XULRunner 1.8.0.4/2006060814]")
  233. # [18:01] * Joins: annevk (n=annevk@86.90.70.28)
  234. # [18:04] <annevk> hello
  235. # [18:08] * Joins: psa (n=yomode@posom.com)
  236. # [18:15] <zcorpan> hello annevk
  237. # [18:16] * annevk though that HTMLImageElement.complete was some new feature but apparently browsers already support it in incompatible ways
  238. # [18:17] <annevk> I suppose "in incompatible ways" goes without saying...
  239. # [18:20] <Philip`> I've used that in Firefox and Opera with no problems (to poll for image loading, since I didn't want to use events), though my code was gratuitously incompatible with IE anyway so I have no idea how it handles complete
  240. # [18:21] <annevk> Philip`, what did you use it for?
  241. # [18:21] * Joins: jcgregorio (i=chatzill@nat/ibm/x-7566f10aec8dd49d)
  242. # [18:21] <Philip`> But "The DOM attribute complete must return true if the user agent has downloaded the image specified in the src attribute, and it is a valid image." doesn't seem to agree with what I found - I'm fairly sure I had complete==true once the image had failed to load (e.g. with a 404 error)
  243. # [18:21] <Philip`> (so I tested width!=0 to see if it had actually loaded successfully, and replaced it with an error image otherwise)
  244. # [18:22] * annevk used "javascript:alert((new Image()).complete)" as testcase
  245. # [18:23] <Philip`> That was just in a canvas game, which loaded images while running and only wanted to check for updated status between frames
  246. # [18:26] * Quits: KevinMarks (n=Snak@pdpc/supporter/active/kevinmarks) ("bye")
  247. # [18:27] * annevk will make some testcases later to test interop a bit better
  248. # [18:27] * annevk is going to fetch a Wii now!
  249. # [18:28] <Philip`> Hmm, I can't work out what I was doing that made it look like it worked, or whether I was just imagining the whole thing...
  250. # [18:30] <Philip`> Oh wait, that's because I'm trying .completed instead of .complete, hence it always returning undefined...
  251. # [18:32] <Philip`> data:text/html,<script>var i=new Image(); i.src="http://microsoft.com/404"; alert(i.complete); setTimeout(function(){alert(i.complete)}, 1000);</script>
  252. # [18:32] <Philip`> That does what I expected - False at first, then True after it's got the error response
  253. # [18:32] <Philip`> but only in FF/Opera - IE returns False/False
  254. # [18:44] * Quits: tantek_ (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  255. # [18:52] * Joins: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl)
  256. # [18:53] <annevk> IE makes more sense imo
  257. # [18:56] * gavin_ quotes annevk out of context
  258. # [18:56] <gavin_> I can see it on Digg now
  259. # [18:56] <annevk> :p
  260. # [18:56] * Joins: tylerr (n=tylerr@outbound.wa1.ascentium.com)
  261. # [19:01] <Philip`> IE isn't as useful since it only allows the polling-equivalent of onload and you can't poll for the same conditions as onerror, whereas FF/O sort of let you tell the difference between complete-successful and complete-error
  262. # [19:01] <Philip`> but IE does make more sense for something called "complete"
  263. # [19:01] * Joins: bzed (n=bzed@dslb-084-059-119-004.pools.arcor-ip.net)
  264. # [19:02] <annevk> afaict the attribute just reflects whether the load event has been dispatched on the element or not
  265. # [19:03] <annevk> i suppose what FF/O is let it reflect whether load or error has been dispatched
  266. # [19:03] <annevk> (but that may be what you just said, I'm a bit dense)
  267. # [19:05] * Joins: hober (n=ted@unaffiliated/hober)
  268. # [19:05] <Philip`> That was what I was thinking (and what seems to happen when I test it), though I'm not sure if what I actually said made sense :-)
  269. # [19:06] * Joins: dbaron (n=dbaron@corp-242.mountainview.mozilla.com)
  270. # [19:09] <annevk> That doesn't seem to be true either
  271. # [19:10] <annevk> alerting complete in a load event handler returns false in IE
  272. # [19:10] * Joins: tantek (n=tantek@dsl092-187-033.sfo1.dsl.speakeasy.net)
  273. # [19:11] <annevk> Philip`, it's a security risk... consider an image from an intranet
  274. # [19:13] <annevk> .complete does return true after the load event of the window object is dispatched, but not before...
  275. # [19:13] * annevk wonders if that can be considered a bug in IE
  276. # [19:14] <Philip`> For data URLs? I was thinking that if you are able to call canvas.toDataURL, you are the same person who was calling canvas.drawImage, so you had the Image, so you could read image.src and get the image data out. But I don't know how much cross-domain scripting is allowed, and whether one of those assumptions is wrong
  277. # [19:16] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  278. # [19:17] <annevk> Philip`, the only way to get the image data is through <canvas>
  279. # [19:17] <annevk> Philip`, hence the restriction
  280. # [19:18] <annevk> (the security model of the web is rather odd, but we have to deal with it :))
  281. # [19:19] <Philip`> But when the image is loaded from a data: URL (e.g. because it came from another call to canvas.toDataURL), you can read .src and get the image data without using the canvas at all
  282. # [19:20] <Philip`> like by writing a PNG decoder in JavaScript, which I guess is a little painful but theoretically possible
  283. # [19:20] <annevk> I'm not up to speed with data: URIs and security, sorry
  284. # [19:21] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  285. # [19:21] * Joins: santek (n=st@ut-w-7bd6.mxs.adsl.euronet.nl)
  286. # [19:22] <annevk> One thing that is problematic with data: URIs if I remember correctly is when they are the result of a redirect
  287. # [19:25] <Philip`> Ah, sounds like that kind of thing makes it awkward
  288. # [19:32] <annevk> http://tc.labs.opera.com/html/img/ has four tests which show that no browser implements the spec
  289. # [19:37] <Philip`> And none misimplement it in the same way
  290. # [19:37] <Philip`> Test: 1 2 3 4
  291. # [19:37] <Philip`> Firefox: F P P F
  292. # [19:37] <Philip`> Opera: F P P DNR
  293. # [19:37] <Philip`> IE: P F F P
  294. # [19:37] <Philip`> Safari: F F F DNR
  295. # [19:38] * Joins: kingryan (n=kingryan@dsl092-187-033.sfo1.dsl.speakeasy.net)
  296. # [19:42] <zcorpan> another <figure> with <credit>: http://www.tellusgame.com/Tellusfilm/2.%20Finished/artikelsidan.html
  297. # [19:44] <zcorpan> i've noticed that whatever html5 feature i use (usually type=email &c), as soon as i pass the code to someone else it disappears. probably their editors or tools remove them or complain about them
  298. # [19:45] <zcorpan> or they are dicks and want to pass validator.w3.org
  299. # [19:53] <zcorpan> http://www.tellusgame.com/Tellusfilm/2.%20Finished/kronikorsidan.html has only <credit> and no caption for the figures
  300. # [19:55] * Joins: KevinMarks (i=KevinMar@nat/google/x-0cebe23e61bfb576)
  301. # [19:58] <zcorpan> firefox seems to be buggy about display:table-cell. sometimes they get rendered on their own line. on reload it renders correctly
  302. # [19:58] * zcorpan will try to reproduce with a simpler test case
  303. # [20:10] * Quits: jcgregorio (i=chatzill@nat/ibm/x-7566f10aec8dd49d) (Read error: 110 (Connection timed out))
  304. # [20:12] * Quits: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  305. # [20:12] <annevk> Microsoft just joined the HTML WG
  306. # [20:12] * Joins: jcgregorio (i=chatzill@nat/ibm/x-5097dedee268b694)
  307. # [20:12] <annevk> With Chris Wilson as their sole participant
  308. # [20:14] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  309. # [20:15] * Joins: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  310. # [20:15] * Quits: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net) (Client Quit)
  311. # [20:15] <annevk> if Martin Atkins is around, my apologies...
  312. # [20:17] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  313. # [20:19] <Dashiva> How so?
  314. # [20:19] <annevk> for asking he question he apparently already addressed
  315. # [20:20] <annevk> s/he question/a question/
  316. # [20:30] * Joins: aroben (i=adamrobe@nat/apple/x-dc264a665affcdfa)
  317. # [20:54] <zcorpan> hsivonen: would it be possible to generate a typesetted pdf of the spec dynamically? would be nice to offer a printable version of the latest spec without having people to typeset it manually
  318. # [21:02] * Quits: jcgregorio (i=chatzill@nat/ibm/x-5097dedee268b694) (Read error: 110 (Connection timed out))
  319. # [21:14] <hsivonen> zcorpan: yes, it would be reasonable. however, I think I'd overstep my Prince license if I did that
  320. # [21:14] <hsivonen> zcorpan: but with a Server license, no technical problem
  321. # [21:14] <annevk> I suppose we might be able to get one...
  322. # [21:14] * Joins: jcgregorio (i=chatzill@nat/ibm/x-2038e74477888afb)
  323. # [21:17] * Joins: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  324. # [21:17] <hsivonen> zcorpan: I guess the best way to do it would be installing Prince (under a server license) on Dreamhost and running it in an SVN post-commit hook each time Hixie commits a new version
  325. # [21:17] <hsivonen> it should probably be run twice: A4 and Letter
  326. # [21:21] <hsivonen> hmm. Perhaps if Hixie is the licensee and invokes Prince as part of his commit script, a Single-User license with Hixie as the licensee would work
  327. # [21:23] <annevk> There's quite a few Prince people on the WHATWG list
  328. # [21:26] <hsivonen> annevk: I know. More the reason to comply. :-) but OTOH, more chance that the Prince people might help with such a setup
  329. # [21:26] * annevk points molly to http://simon.html5.org/test/ie7b2-bugs/
  330. # [21:30] * zcorpan should probably mark the ones already fixed as obsolete
  331. # [21:31] <annevk> you could add a readm.txt mentioning all the fixed tests
  332. # [21:31] <annevk> readme*
  333. # [21:32] <zcorpan> you know off-hand which they are?
  334. # [21:32] <annevk> nope
  335. # [21:33] <zcorpan> ok
  336. # [21:37] * Quits: psa (n=yomode@posom.com) (Remote closed the connection)
  337. # [21:52] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  338. # [21:55] * Quits: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
  339. # [21:58] * Quits: KevinMarks (i=KevinMar@nat/google/x-0cebe23e61bfb576) ("The computer fell asleep")
  340. # [22:12] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  341. # [22:19] * Quits: jcgregorio (i=chatzill@nat/ibm/x-2038e74477888afb) ("ChatZilla 0.9.78 [Firefox 2.0.0.2/0000000000]")
  342. # [22:42] * Joins: KevinMarks (i=KevinMar@nat/google/x-95ff6ec940187c28)
  343. # [22:51] <annevk> http://twitter.com/Hixie/statuses/14588161
  344. # [22:51] <annevk> seems Hixie adopted twitter
  345. # [22:51] <othermaciej> !
  346. # [22:52] <hober> yay!
  347. # [22:54] <othermaciej> haha, I know what group that is
  348. # [22:55] <Hixie> blame tantek
  349. # [22:55] <Hixie> for me using twitter
  350. # [22:55] <Hixie> i wish it worked though
  351. # [22:55] <othermaciej> wow, that's a whole lotta twittering
  352. # [22:55] <Hixie> the jabber server never sends me updates
  353. # [22:56] * Hixie uses it as an IM away message
  354. # [22:56] <annevk> oh yeah, I just picked a funny line
  355. # [22:56] <tantek> Hixie, check your prefs and make sure you set (*) IM
  356. # [22:56] <Hixie> i have
  357. # [22:56] <Hixie> and i've said 'on'
  358. # [22:56] <tantek> and then i believe you have to appear "online"
  359. # [22:56] <tantek> rather than "away"
  360. # [22:56] <Hixie> i do
  361. # [22:56] <tantek> otherwise i think it stops sending them to your jabber
  362. # [22:56] <tantek> er, im
  363. # [22:56] <tantek> odd
  364. # [22:57] <Hixie> i'm present, logged in, enabled it, confirmed it with the code, said 'on', the works
  365. # [22:57] <Hixie> never gotten it to send any of my friends' messages to me
  366. # [22:57] <Dashiva> The twitter server seems slow like the css 2.1 specification process
  367. # [22:58] * Dashiva notes that Hixie himself only sends lggwg moves during like 1/4 of the day
  368. # [22:59] <Hixie> more like 3/4
  369. # [22:59] <Hixie> but sure
  370. # [22:59] <othermaciej> if twitter starts containing useful information, I might have to sign up :-(
  371. # [23:00] * annevk was wondering about the same thing
  372. # [23:00] <Hixie> twitter, as far as i've experienced, is a write-only medium
  373. # [23:00] <Hixie> note that my blog shows my status and updates it in real time if you leave the page open
  374. # [23:01] <hsivonen> twitter on ADSL is slower than Flickr on GPRS
  375. # [23:04] <tantek> btw, some folks hangout sometimes in #twitter
  376. # [23:05] <tantek> and at least you can twitter about any problems you have on twitter
  377. # [23:05] <Dashiva> We could make a twitter clone that selects random lines from IRC instead :)
  378. # [23:06] <annevk> krijnh, could modify his bot so we could do "twitter: blah" and it would appear in some #whatwg twitter
  379. # [23:06] <Dashiva> twitter: Hi mom
  380. # [23:06] <Hixie> tantek: i've done so several times :-)
  381. # [23:07] <Hixie> tantek: i really have no idea why it doesn't work
  382. # [23:09] <tantek> How strange - I thought I had added you and for some reason when I went to your profile I had not.
  383. # [23:09] <othermaciej> the twitter web site seems to be pretty slow right now
  384. # [23:09] <tantek> re-adding twitter.com/hixie
  385. # [23:09] <tantek> ah there are your bug reports
  386. # [23:09] <tantek> ok, let's try this...
  387. # [23:10] <hsivonen> aaagh. Atom abuse by twitter: double escaped titles
  388. # [23:11] * Joins: psa (n=yomode@posom.com)
  389. # [23:11] <hsivonen> getting rid of this problem is why Atom exists
  390. # [23:12] <Dashiva> Making it easier to do it right just means more energy left for doing it wrong!
  391. # [23:12] <annevk> i suppose that shows that inventing something new doesn't solve problems
  392. # [23:16] <tantek> hsivonen - I use XHTML titles and very few Atom consumers decode them - instead I see literal: "<div> Tantek's Updates</div>" as the title
  393. # [23:17] <tantek> e.g. http://blogsearch.google.com/blogsearch?q=link:tantek.com&scoring=d
  394. # [23:17] <annevk> nowadays i think that Atom might have been a mistake
  395. # [23:18] <tantek> Of course Technorati's Atom parsing is compliant (as one of the earlier consumers: http://www.intertwingly.net/wiki/pie/KnownAtomConsumers )
  396. # [23:18] <KevinMarks> the problem is the pain people went through for RSS lingers in their atom parsers
  397. # [23:18] <zcorpan> is http://simon.html5.org/test/ie7b2-bugs/037.html valid or not?
  398. # [23:18] <tantek> annevk, as a publisher, I'm very happy about Atom being there - semantics are much more well defined
  399. # [23:19] <annevk> tantek, we could have fixed RSS to make semantics well defined
  400. # [23:19] <KevinMarks> and as a parser, it is way better
  401. # [23:19] <annevk> zcorpan, it's valid per HTML5, yes
  402. # [23:19] <othermaciej> it would have been better to fix RSS
  403. # [23:19] <tantek> and rel="enclosure" made it trivial to mark media items that I had already been linking to as podcast items
  404. # [23:19] <zcorpan> annevk: ok
  405. # [23:19] <KevinMarks> that was made impossible
  406. # [23:19] <KevinMarks> really
  407. # [23:19] <tantek> as opposed to dealing with yet another random new element
  408. # [23:19] <hober> I don't think fixing RSS was, politically, an option
  409. # [23:19] <annevk> in due course someone still has to fix RSS and Atom
  410. # [23:19] <KevinMarks> Atom is fixed
  411. # [23:20] <annevk> the Atom specification doesn't say what consumers should do with invalid Atom
  412. # [23:20] <tantek> annevk - no, people tried fixing RSS to make its semantics well defined and failed. That's why Atom happened. See: Sam Ruby, Tim Bray.
  413. # [23:20] <KevinMarks> the feed validaotr makes invalid atom very clear
  414. # [23:20] <tantek> Atom is much more easily "fixed" in that regard (interoperable error handling) than RSS.
  415. # [23:21] <annevk> the HTML WG tried to fix HTML at some point to and then went on with XHTML2 because it was considered too hard
  416. # [23:21] <KevinMarks> with RSS the error message are more like 'this is a matter of debate'
  417. # [23:21] <annevk> RSS should be "trivial" compared to HTML
  418. # [23:21] <tantek> annevk, no that's not the reason
  419. # [23:21] <tantek> there was political motivation/pressure to do a "pure XML" version of HTML
  420. # [23:21] <KevinMarks> which became RSS 1.0, the RDF flavour
  421. # [23:21] <tantek> that was greater than the pressure to "fix" HTML
  422. # [23:21] <othermaciej> Atom does seem like an XHTML2-style solution
  423. # [23:21] <annevk> ok, maybe the former XForms WG then
  424. # [23:21] <tantek> some folks had the delusion that "pure XML" = "fix"
  425. # [23:22] <KevinMarks> RSS 1.0 was the xhtml2-like solution
  426. # [23:22] <annevk> probably the XForms people, yes
  427. # [23:22] <hober> KevinMarks: exactly
  428. # [23:22] <tantek> KevinMarks FTW
  429. # [23:22] <annevk> Atom is yet another one
  430. # [23:22] <KevinMarks> no
  431. # [23:22] <tantek> Atom doesn't have that much reinvention.
  432. # [23:22] <KevinMarks> I suppose hAtom is the HTML solution...
  433. # [23:23] <annevk> in two flavors, 0.3 and 1.0
  434. # [23:23] <hsivonen> tantek: I use XHTML titles as well. No complaints. However, many Atom consumers don't get namespace-prefixed XHTML right.
  435. # [23:23] <annevk> tantek, it does, it has all the same features under different element names
  436. # [23:23] <tantek> hsivonen, I use @xmlns rather than namespace-prefixed tags
  437. # [23:23] <KevinMarks> as opposed to the 9 or 12 flavours of RSS
  438. # [23:23] * Quits: aroben (i=adamrobe@nat/apple/x-dc264a665affcdfa)
  439. # [23:23] <tantek> annevk, not quite - it has more and more precise semantics
  440. # [23:23] <tantek> (atom vs. rss)
  441. # [23:24] <annevk> KevinMarks, well, you have to support all those flavors already
  442. # [23:24] <othermaciej> fortunately Atom and RSS are both much simpler than HTML
  443. # [23:24] <KevinMarks> it specifies which elements can contain HTML
  444. # [23:24] <annevk> KevinMarks, so better fix those than introduce even more
  445. # [23:24] <hsivonen> tantek: me too for the feed that I actually intend to be read. however, to point out brokenness I have implemented a non-canonical feed elsewhere
  446. # [23:24] <othermaciej> so an incompatible break is merely inordinately expensive as opposed to impossible
  447. # [23:24] <hober> Fortunately, Mark Pilgrim et al. already did all the heavy lifting, by writing the UFP :)
  448. # [23:24] * tantek leaves it to KevinMarks to provide the rest of the history of Atom lesson.
  449. # [23:25] * annevk was part of the Atom WG
  450. # [23:25] * KevinMarks was too
  451. # [23:25] * annevk doesn't need history lessons about it
  452. # [23:25] <hsivonen> Atom wasn't like XHTML 2.0. HTML didn't have a Winer.
  453. # [23:25] <KevinMarks> so how would you propose fixing RSS?
  454. # [23:25] * hsivonen was also part of the Atom WG
  455. # [23:25] <othermaciej> making a whatwg style community breakaway spec for RSS might have, in retrospect, been better
  456. # [23:26] <tantek> I thought that was what was tried, by Cadenhead
  457. # [23:26] <hober> othermaciej: in some sense, that's what the RSS AB is
  458. # [23:26] <hober> tantek: right
  459. # [23:26] <tantek> with the RSS committee or WTF it was called
  460. # [23:26] <annevk> much the same way HTML has been fixed
  461. # [23:26] <hober> the rss advisory board
  462. # [23:26] <tantek> but that blew up in a bunch of blog drama AFAIK
  463. # [23:26] <tantek> yeah that thing
  464. # [23:26] <annevk> I think that was a pretty silly effort
  465. # [23:26] <annevk> not much community involvement at all and it focused on paragraph level changes as opposed to actually digging up all the issues etc.
  466. # [23:28] <othermaciej> anyway, it's true that staging a hostile takeover of a broken spec is harder than making a new one
  467. # [23:28] * zcorpan added some notes to http://simon.html5.org/test/ie7b2-bugs/
  468. # [23:28] <annevk> problem is that the new one doesn't define much error handling either
  469. # [23:28] <hober> annevk: I'd say that that's an underlying problem with xml
  470. # [23:29] <hober> seems to me the html5lib liberalxmlparser is showing the way in that case
  471. # [23:29] <annevk> hober, I don't mean namespace-well-formedness error handling
  472. # [23:29] <hober> I know what you mean
  473. # [23:30] <annevk> what to do with a feed <feed xmlns="atomns"></feed>
  474. # [23:30] <tantek> othermaciej - good point
  475. # [23:30] <tantek> however, if any group *could* do it, i think whatwg could
  476. # [23:30] <tantek> and certainly would get a lot of, ahem, press for it
  477. # [23:30] <annevk> we already defined sniffing for feeds
  478. # [23:30] <tantek> because you can almost guarantee a fairly high level of blog drama
  479. # [23:30] <annevk> well, Hixie did
  480. # [23:31] <tantek> is there an RSS 2.1 spec?
  481. # [23:31] <othermaciej> I think the takeover of html is keeping everyone sufficiently busy
  482. # [23:31] <hober> othermaciej++
  483. # [23:31] <tantek> agreed. fixing HTML is much more important than fixing RSS
  484. # [23:31] <annevk> hober, I plan to remove namespace-well-formed from XML btw
  485. # [23:31] <Philip`> Maybe work on RSS5 can be slotted between HTML5 and XML5
  486. # [23:31] <kingryan> why don't we just obsolete RSS?
  487. # [23:32] <hober> kingryan: RFC4287 already did :)
  488. # [23:32] * kingryan points at http://microformats.org/wiki/hatom
  489. # [23:32] <annevk> kingryan, obsolete in what sense?
  490. # [23:32] <hsivonen> I think an RSS5 would be destructive to the atmosphere of the WHATWG list
  491. # [23:32] <annevk> rss-whatwg
  492. # [23:32] <tantek> especially since "S" and "5" look too similar in many fonts
  493. # [23:32] <Dashiva> It would be much more effective to aim for legislation making RSS illegal
  494. # [23:33] <hsivonen> people are nicer on the WHATWG list than on the AtomPub list
  495. # [23:33] <othermaciej> things that are more important to fix than RSS include:
  496. # [23:33] <tantek> when RSS is outlawed, only outlaws will (be in a) syndicate ?
  497. # [23:33] <kingryan> annevk: create something more useful and easier to us
  498. # [23:33] <kingryan> use*
  499. # [23:33] <othermaciej> DOM Core, CSS, SVG
  500. # [23:33] <hsivonen> syndication in general and RSS in particular make people act in non-nice ways
  501. # [23:33] <othermaciej> MathML is probably less important to fix than RSS
  502. # [23:33] <tantek> SVG? that needs something much more like Atomization treatment
  503. # [23:34] <annevk> VML!
  504. # [23:35] <tantek> annevk, no no no, you really want VRML.
  505. # [23:35] <zcorpan> TIME
  506. # [23:35] <tantek> keeps on ticking
  507. # [23:35] <zcorpan> or, SMIL
  508. # [23:35] * Joins: pnhChris (n=cac6982@c-68-36-151-200.hsd1.nj.comcast.net)
  509. # [23:36] <annevk> othermaciej, HTTP
  510. # [23:36] <annevk> XML
  511. # [23:36] <annevk> video codecs :)
  512. # [23:36] <hsivonen> WS-*5
  513. # [23:36] <annevk> heh
  514. # [23:37] <zcorpan> RDF5
  515. # [23:37] <othermaciej> HTTP spec does need fixing
  516. # [23:37] <othermaciej> I don't know what is wrong with XML offhand
  517. # [23:37] * annevk wants graceful error handling
  518. # [23:37] <othermaciej> HTTP isn't in nearly as bad shape as SVG
  519. # [23:37] <hober> I'm all for interoperable error handling -- if someone wants to write up "what the UFP does" in spec form, that would be potentially good
  520. # [23:37] <othermaciej> WS-* and RDF are of no interest to me
  521. # [23:38] <tantek> hsivonen, othermaciej - I believe the proper term is WS-death-*
  522. # [23:38] <othermaciej> annevk: an error-recovering version of XML would be a significant incompatible break - not sure it's worth it
  523. # [23:38] <annevk> lots of mobile content already breaks in Opera because we don't do it
  524. # [23:39] <annevk> I think Webkit shipped in Nokia has therefore disabled XML for XHTML...
  525. # [23:39] <tantek> ah, "mobile content"
  526. # [23:39] <tantek> is that another oxymoron?
  527. # [23:39] <annevk> and feeds too
  528. # [23:39] <annevk> although with feeds it's mostly character encoding which most browsers seem to ignore...
  529. # [23:39] <tantek> btw, Hixie, you may want to de-add yourself from yourself: http://twitter.com/Hixie - that might be causing problems.
  530. # [23:39] <annevk> (on the HTTP level most implementations of XML are non-compliant)
  531. # [23:40] <zcorpan> it could possible to define graceful error handling for xml in a way that is compatible with xml 1.0 handling, although it wouldn't be possible to drop the internal subset (other than making it non-conforming)
  532. # [23:40] * zcorpan thinks
  533. # [23:40] <annevk> yeah, internal subset is most of the complexity of XML
  534. # [23:41] <zcorpan> if new processors silently ignored internal subsets then they wouldn't be compatible with existing xml documents that rely on the internal subset
  535. # [23:41] <zcorpan> a lot of svg images do
  536. # [23:42] <annevk> it has to be supported obviously
  537. # [23:42] <annevk> all XML 1.0 content needs to remain working
  538. # [23:42] <zcorpan> indeed
  539. # [23:42] <annevk> and all wanabe XML 1.0 content will start working
  540. # [23:42] <annevk> in some way
  541. # [23:43] <zcorpan> an xml 1.0 processor should also be a conforming xml5 processor (i.e. error recovery should be optional)
  542. # [23:43] <zcorpan> (imho)
  543. # [23:44] <annevk> xml5 would be a superset
  544. # [23:44] <annevk> as xml1.1 will be mostly integrated as well
  545. # [23:44] <annevk> and namespaces for xml too
  546. # [23:45] <othermaciej> this all sounds like a lot of work
  547. # [23:45] <othermaciej> it's a wonder the web works at all
  548. # [23:45] <zcorpan> but things that are parse errors in xml 1.0 (and namespaces in 1.0) surely should continue to be (so that processors are allowed to stop)?
  549. # [23:46] <annevk> that would mean that a processor is allowed to stop at <?xml version="1.1"?>
  550. # [23:46] <zcorpan> yes
  551. # [23:46] <annevk> i'm not really sure what the value in that is
  552. # [23:47] <hsivonen> annevk: the value is creating an atmosphere of doubt about guarantees of non-XML 1.0 XML5 working
  553. # [23:47] <hsivonen> annevk: so people would still have an incentive to try to get things right
  554. # [23:47] <hsivonen> annevk: which would make the upgrade less damaging to users of XML 1.0 processors
  555. # [23:48] <annevk> i suppose
  556. # [23:48] <hsivonen> nn
  557. # [23:48] <annevk> i'll let the spec lawyering to you :)
  558. # [23:48] <zcorpan> hsivonen: nn
  559. # Session Close: Thu Apr 05 00:00:00 2007

The end :)