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

Options:

  1. # Session Start: Fri Jun 26 00:00:00 2009
  2. # Session Ident: #whatwg
  3. # [00:02] * Parts: billmason (n=billmaso@ip7.unival.com)
  4. # [00:02] * Quits: ttepasse (n=ttepasse@dslb-084-060-063-070.pools.arcor-ip.net) ("?Q")
  5. # [00:06] * Quits: gsnedders (n=gsnedder@82-35-33-133.cable.ubr01.camd.blueyonder.co.uk)
  6. # [00:09] <hober> I guess Michael Jackson missed his opportunity to report a typo in the spec & gain immortality via inclusion in the Acknowledgments section.
  7. # [00:09] * Quits: drostie (n=hopkins@5ED17066.cable.ziggo.nl) (Read error: 110 (Connection timed out))
  8. # [00:14] * Quits: drostie_ (n=hopkins@5ED17066.cable.ziggo.nl) (Connection timed out)
  9. # [00:23] * Parts: jbalogh (n=jeff@nat/mozilla/x-232a3e69c7734742)
  10. # [00:24] * Joins: sayrer (n=chatzill@cvo-cr1-203-149.peak.org)
  11. # [00:24] <sayrer> jgraham: ftr, I am not an HTML anarchist
  12. # [00:25] <sayrer> but I don't like pointless rules either
  13. # [00:25] <sayrer> and I think "semantic markup" is not worth very much
  14. # [00:26] <sayrer> so disallowing <font> while allowing style="" seems ridiculous
  15. # [00:27] <sayrer> go ahead, just move that presentation stuff into attribute values rather than element and attribute names... then everything is ok!
  16. # [00:27] <sayrer> it's like that monty python skit where everyone changes chairs and says "there, that's much better"
  17. # [00:33] * Quits: cying (n=cying@70.90.171.153)
  18. # [00:43] * Quits: jennb (n=jennb@72.14.227.1)
  19. # [00:46] * Quits: ZombieLoffe (n=e@unaffiliated/zombieloffe)
  20. # [00:46] * Joins: jennb (n=jennb@72.14.227.1)
  21. # [00:47] * Quits: heycam (n=cam@124-168-58-6.dyn.iinet.net.au) ("bye")
  22. # [00:47] <beowulf> sayrer: pity, i liked the idea of someone being an HTML anarchist
  23. # [00:49] <sayrer> beowulf, prescriptivists have a tough time telling a descriptivist from an anarchist, so there HTML anarchists in the minds of some
  24. # [00:53] <beowulf> sayrer: what is descriptivism in the context of HTML?
  25. # [00:54] * Joins: drostie (n=hopkins@5ED17066.cable.ziggo.nl)
  26. # [00:54] <sayrer> beowulf: that would mean writing down what mean, without judging whether they're doing it wrong
  27. # [00:54] <sayrer> what markup means
  28. # [00:54] <sayrer> so for instance, @valign is banned as wrong in Ian's draft
  29. # [00:55] <sayrer> descriptivist approach would be to write it down, and note that the same task can be accomplished other ways (synonyms)
  30. # [00:57] <sayrer> http://en.wikipedia.org/wiki/Ain%27t is a could example
  31. # [00:57] <sayrer> good example
  32. # [00:57] <sayrer> "It is a word that is widely used by many people, but its use is commonly considered to be improper.[1]"
  33. # [00:58] <beowulf> sayrer: ah, i get you
  34. # [00:59] <sayrer> A related concept is the virtue of "semantic markup"
  35. # [00:59] <sayrer> people who obsess about whether they are using <dt> right
  36. # [00:59] <sayrer> my opinion is that the section that most precisely defines the semantics of these elements is section 11, rendering
  37. # [01:00] * Joins: weinig_ (n=weinig@17.246.19.29)
  38. # [01:02] * Joins: cying (n=cying@70.90.171.153)
  39. # [01:04] * Quits: othermaciej (n=mjs@17.246.18.129)
  40. # [01:15] * aroben is now known as aroben|away
  41. # [01:15] * Quits: weinig (n=weinig@17.203.15.178) (Read error: 110 (Connection timed out))
  42. # [01:21] * Joins: kangax (n=kangax@157.130.31.226)
  43. # [01:22] * Quits: archtech (n=stanv@83.228.56.37)
  44. # [01:24] * Joins: ginger (n=nessy@124-170-139-223.dyn.iinet.net.au)
  45. # [01:31] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
  46. # [01:33] * Quits: nessy (n=nessy@203-166-245-242.dyn.iinet.net.au) (Read error: 101 (Network is unreachable))
  47. # [01:33] * Quits: dglazkov (n=dglazkov@nat/google/x-21b7da9a9938072f)
  48. # [01:35] * Quits: dave_levin (n=dave_lev@72.14.227.1)
  49. # [01:38] * Joins: archtech (n=stanv@83.228.56.37)
  50. # [01:39] * Joins: dglazkov (n=dglazkov@nat/google/x-ecb26e5eea17ec61)
  51. # [01:43] * Joins: othermaciej (n=mjs@17.246.18.129)
  52. # [01:45] * Quits: tndH (n=Rob@james-baillie-pc083-229.student-halls.leeds.ac.uk) ("ChatZilla 0.9.85-rdmsoft [XULRunner 1.9.0.1/2008072406]")
  53. # [01:48] * Quits: kangax (n=kangax@157.130.31.226)
  54. # [01:55] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  55. # [02:06] * Quits: dglazkov (n=dglazkov@nat/google/x-ecb26e5eea17ec61)
  56. # [02:07] * Quits: archtech (n=stanv@83.228.56.37)
  57. # [02:10] * Quits: bgalbraith (n=bgalbrai@nat/mozilla/x-bf48039f1fd289d8)
  58. # [02:17] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  59. # [02:22] * Quits: Hixie (i=ianh@trivini.no) (Read error: 110 (Connection timed out))
  60. # [02:26] * Quits: jennb (n=jennb@72.14.227.1)
  61. # [02:28] * Quits: dolske (n=dolske@nat/mozilla/x-ad5bb93524d8ae5a)
  62. # [02:32] * Quits: yshin (n=yshin@72.14.227.1) (Read error: 60 (Operation timed out))
  63. # [02:34] * Quits: dbaron (n=dbaron@nat/mozilla/x-ec32f7be791714bb) ("8403864 bytes have been tenured, next gc will be global.")
  64. # [02:38] * Joins: dolske (n=dolske@nat/mozilla/x-166aa09f5288c234)
  65. # [02:39] * Parts: ojan (n=ojan@nat/google/x-23eea3036d8ff5f4)
  66. # [03:05] * Quits: weinig_ (n=weinig@17.246.19.29)
  67. # [03:15] * Quits: cying (n=cying@70.90.171.153)
  68. # [03:26] * Quits: slightlyoff (n=slightly@72.14.229.81)
  69. # [03:28] * Joins: zcorpan (n=zcorpan@c83-252-196-43.bredband.comhem.se)
  70. # [03:30] <zcorpan> jgraham: when it comes to generating table descriptions, i think a good first step would be to include the number of rows and columns, and where the table headers are
  71. # [03:35] <zcorpan> "Table with 19 rows and 7 columns. The first two rows contain headers. The first row and the first column contain merged cells."
  72. # [03:35] <zcorpan> http://projectcerbera.com/web/study/2007/tables/clark2006/05-housing/original
  73. # [03:37] <zcorpan> hmm actually that table has merged cells on the first two rows and the first two columns
  74. # [03:37] <zcorpan> but i guess the top left cell should be ignored
  75. # [03:37] * Joins: MikeSmith (n=MikeSmit@tea14.w3.mag.keio.ac.jp)
  76. # [03:38] <zcorpan> or maybe empty cells should be ignored
  77. # [03:39] <zcorpan> maybe it's not so useful to say where there are merged cells
  78. # [03:39] <zcorpan> maybe just stating that it contains merged cells
  79. # [03:43] * zcorpan looks at the forming a table algorithm in the spec
  80. # [03:55] <zcorpan> might also be good to announce when there are more than one tbody or when there's a tfoot
  81. # [04:09] * Quits: ginger (n=nessy@124-170-139-223.dyn.iinet.net.au) ("Leaving")
  82. # [04:23] * Quits: sayrer (n=chatzill@cvo-cr1-203-149.peak.org) (Read error: 110 (Connection timed out))
  83. # [04:35] * Joins: bgalbraith (n=bgalbrai@71.202.109.116)
  84. # [04:38] * Quits: JoePeck (n=JoePeck@cpe-74-69-85-249.rochester.res.rr.com) (Read error: 104 (Connection reset by peer))
  85. # [04:38] * Joins: JoePeck (n=JoePeck@cpe-74-69-85-249.rochester.res.rr.com)
  86. # [04:46] * Joins: sayrer (n=chatzill@cvo-cr1-203-149.peak.org)
  87. # [04:47] * Quits: dolske (n=dolske@nat/mozilla/x-166aa09f5288c234)
  88. # [04:58] * Joins: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
  89. # [05:05] <MikeSmith> zcorpan: you still around?
  90. # [05:09] <MikeSmith> sayrer: you got time to chat?
  91. # [05:15] <zcorpan> MikeSmith: yes
  92. # [05:16] <MikeSmith> zcorpan: do you have a local workspace for testing v.nu changes?
  93. # [05:16] * Joins: dolske (n=dolske@c-76-103-40-203.hsd1.ca.comcast.net)
  94. # [05:17] * Quits: sayrer (n=chatzill@cvo-cr1-203-149.peak.org) (Read error: 104 (Connection reset by peer))
  95. # [05:17] <zcorpan> MikeSmith: local workspace?
  96. # [05:18] * Joins: sayrer (n=chatzill@cvo-cr1-203-149.peak.org)
  97. # [05:18] <MikeSmith> zcorpan: I mean, an svn workspace, so that you can sync up to latest svn revision and then re-run a local v.nu to test changes?
  98. # [05:19] <zcorpan> MikeSmith: ah. no
  99. # [05:20] <zcorpan> i checked out the source on my windows laptop but didn't get it to run
  100. # [05:20] <zcorpan> i probably don't have JDK on my mac
  101. # [05:20] <MikeSmith> ok, no problem
  102. # [05:21] <zcorpan> is there something you'd like me to test?
  103. # [05:21] <MikeSmith> I'm adding frameset to the actual schema
  104. # [05:21] <MikeSmith> and wanted to make sure I've not muffed it up
  105. # [05:22] <MikeSmith> I have my own simple tests for it, but wanted to double-check
  106. # [05:22] * Quits: jwalden (n=waldo@nat/mozilla/x-162181c234085789) ("ChatZilla 0.9.85 [Firefox 3.5pre/20090624033017]")
  107. # [05:24] <zcorpan> ping me when it's live in v.nu and i can try to break it
  108. # [05:24] <MikeSmith> OK
  109. # [05:26] * Joins: karlcow (n=karl@nerval.la-grange.net)
  110. # [05:28] <MikeSmith> zcorpan: anyway, the only difference my change will introduce is that when you check a document that has <frameset>, the "Error: Element frameset not allowed as child of element html in this context. (Suppressing further errors from this subtree.)" message will be suppressed
  111. # [05:29] <MikeSmith> oh, and it will actually report any errors in the subtree
  112. # [05:30] <zcorpan> MikeSmith: will it complain about required children missing (i.e. the <body>)?
  113. # [05:33] * zcorpan guesses not
  114. # [05:36] <MikeSmith> zcorpan: you guess right, it won't
  115. # [05:36] <zcorpan> MikeSmith: have you tested noframes before and after the frameset?
  116. # [05:37] <MikeSmith> zcorpan: nope
  117. # [05:38] <MikeSmith> but if you give a test, I will add it and test it before I check in
  118. # [05:39] <zcorpan> html4 only allows noframes inside frameset, but the html5 parser inserts noframes to head or html for before and after respectively
  119. # [05:40] <zcorpan> <!doctype html><title>noframes</title><noframes></noframes><frameset><noframes></noframes></frameset><noframes></noframes>
  120. # [05:40] <zcorpan> i guess it should whine about the first and last
  121. # [05:42] <zcorpan> and missing frame or frameset child
  122. # [05:45] <MikeSmith> zcorpan: OK, this is what I get:
  123. # [05:45] <MikeSmith> http://pastebin.com/m4ba0c569
  124. # [05:45] <MikeSmith> so I guess I need to add <noframes> as a valid child of <head>
  125. # [05:48] <zcorpan> MikeSmith: why?
  126. # [05:48] <zcorpan> MikeSmith: html4 doesn't allow noframes in head
  127. # [05:49] <MikeSmith> ah, OK
  128. # [05:49] <MikeSmith> so what should it be reporting for that case?
  129. # [05:49] * Quits: sayrer (n=chatzill@cvo-cr1-203-149.peak.org) (Read error: 110 (Connection timed out))
  130. # [05:51] <zcorpan> MikeSmith: what you pasted seems correct
  131. # [05:52] * Quits: karlcow (n=karl@nerval.la-grange.net) (Remote closed the connection)
  132. # [05:53] <MikeSmith> zcorpan: OK
  133. # [05:54] <zcorpan> MikeSmith: maybe it's not so useful to assert that the elements other than the top-most frameset being obsolete
  134. # [06:00] * Quits: Lachy (n=Lachlan@85.196.122.246) ("Leaving")
  135. # [06:06] * Joins: tantek (n=tantek@70.36.139.106)
  136. # [06:06] <MikeSmith> dglazkov: great to finally have http basic auth working in chrome on linux
  137. # [06:14] * Joins: sayrer (n=chatzill@cvo-cr1-203-149.peak.org)
  138. # [06:14] <MikeSmith> zcorpan: btw, I have an open bugzilla issue for keeping track of ideas around how to do better reporting for obsolete elements
  139. # [06:15] <MikeSmith> and obsolete attributes
  140. # [06:15] <MikeSmith> http://bugzilla.validator.nu/show_bug.cgi?id=481
  141. # [06:16] <dglazkov> MikeSmith: I take full credit for this.
  142. # [06:16] <dglazkov> MikeSmith: what wasn't working again?
  143. # [06:16] <dglazkov> :)
  144. # [06:16] <MikeSmith> heh
  145. # [06:16] <MikeSmith> dglazkov: I think it just wasn't implemented at all until 190
  146. # [06:16] <MikeSmith> anyway, it's still only implemented so far for linux, not Mac
  147. # [06:17] <MikeSmith> dglazkov: hey, btw and just fyi - http://code.google.com/p/chromium/issues/detail?id=15422
  148. # [06:19] <othermaciej> MikeSmith: so would the validator report attributes or elements as obsolete instead of unknown?
  149. # [06:19] <othermaciej> that would be neat
  150. # [06:20] <MikeSmith> othermaciej: yeah, it does that already for a number of elements -- just elements that were in HTML4, but not in HTML5
  151. # [06:20] <MikeSmith> so, it doesn't do it for <marquee>, but does for <big>, etc.
  152. # [06:21] <MikeSmith> except we didn't have <frameset> and <noframes> and <basefont> in there
  153. # [06:21] <sayrer> "warning <big> is far too short, please use a style attribute"
  154. # [06:21] <MikeSmith> sayrer: heh
  155. # [06:21] <MikeSmith> othermaciej: so all that I'm changing now is just to add those
  156. # [06:22] <MikeSmith> sayrer: so is it your position that validators should not report anything as obsolete?
  157. # [06:22] <MikeSmith> or that we shouldn't have validators at all?
  158. # [06:22] <sayrer> I am totally in favor of lint tools
  159. # [06:22] * Joins: dave_levin (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net)
  160. # [06:22] <sayrer> I'm not so sure about a hard line between valid/invalid
  161. # [06:23] <sayrer> I gather I'm in good company on that one
  162. # [06:23] <MikeSmith> sayrer: well, you are in company, but not sure if it's necessarily "good" company (scare quotes intentional)
  163. # [06:23] <sayrer> I was thinking of a tbl presentation ;)
  164. # [06:24] <othermaciej> MikeSmith: I'm not sure <marquee> is "obsolete" in quite the same way
  165. # [06:24] <MikeSmith> (scare quotes seem to be the trendy thing to do, so I'm trying to use them more frequently)
  166. # [06:24] <MikeSmith> othermaciej: yeah, true
  167. # [06:24] <othermaciej> MikeSmith: don't you mean "scare" quotes?
  168. # [06:24] * Quits: aroben|away (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  169. # [06:24] <MikeSmith> heh
  170. # [06:24] <othermaciej> sayrer: I'm dubious about the value of a normative spec defining the behavior of lint tools
  171. # [06:24] <sayrer> I think that's what he "means"
  172. # [06:25] <sayrer> othermaciej: me too, that's why I don't like the current author conformance requirements
  173. # [06:25] <othermaciej> sayrer: however, hsivonen made the plausible argument that having a certain common level of baseline rules is an interoperability benefit for authoring tools and validators
  174. # [06:25] <sayrer> since there are many rules that are basically lint tool kind of things
  175. # [06:25] <MikeSmith> we should have double scare quotes -- e,g., ""working group"" -- to indicate an extra amount of disdain
  176. # [06:25] <othermaciej> that's the only really convincing argument I have heard for why such things make sense as conformance requirements
  177. # [06:26] <othermaciej> sayrer: do you think the spec should contain any authoring conformace requirements?
  178. # [06:26] <Dashiva> MikeSmith: Shouldn't you use a different quote set for one of them, to avoid it parsing as "", working group, ""?
  179. # [06:26] * Quits: tantek (n=tantek@70.36.139.106) (Read error: 60 (Operation timed out))
  180. # [06:26] <MikeSmith> heh
  181. # [06:26] <othermaciej> sayrer: it's not totally clear to me if you doubt the value of all of them or only some?
  182. # [06:26] * Joins: jwalden (n=waldo@c-98-248-40-206.hsd1.ca.comcast.net)
  183. # [06:26] <othermaciej> MikeSmith: I would think nested scare quotes would neutralize
  184. # [06:27] <MikeSmith> ah yeah, true
  185. # [06:27] <othermaciej> MikeSmith: since in general "foo" means 'people call it foo, but I don't really think it is, I'm just using their term under protest'
  186. # [06:27] <sayrer> othermaciej: some rules seem to be in place because the markup is "presentational"
  187. # [06:27] <MikeSmith> you can use them to quote somebody else's use of scare quotes -- to show disdain for the fact that they are using scare quotes
  188. # [06:28] <othermaciej> sayrer: are those the only kinds of rules you don't like?
  189. # [06:28] <MikeSmith> sayrer: very true, and not everybody is in agreement about that class of constraints
  190. # [06:28] <MikeSmith> e.g, the presentational attributes on <table>
  191. # [06:28] <othermaciej> "make presentational markup conforming" is a pretty clear position and worth discussing on that basis
  192. # [06:29] <sayrer> oh, I think concrete spec text would make it easier to discuss
  193. # [06:29] <othermaciej> I have an easier time reading a few sentences than a whole alternate spec
  194. # [06:29] <sayrer> then there are those things that seem kind of vestigial or ineffective
  195. # [06:30] <sayrer> like @profile and @summary
  196. # [06:30] <MikeSmith> the bulk of the kind of conformance checking that v.nu is doing is simply checks like, "you can't have a <dd> as a child of a <ul>"
  197. # [06:30] <othermaciej> I suspect many others are in that position
  198. # [06:30] <sayrer> those vestigial things hardly seem worth bannign
  199. # [06:31] <sayrer> or declaring invalid
  200. # [06:31] <othermaciej> sayrer: do you think rules like what MikeSmith cited (can't have a <dd> as a child of a <ul>) are worthwhile?
  201. # [06:31] <othermaciej> or more specifically, are they worthwhile as conformance requirements?
  202. # [06:31] <sayrer> yes, that is the class of things that I have a hard time characterizing. a lint tool would clearly want to report "<b><i>foo</b></i>"
  203. # [06:32] <sayrer> to use a really brain dead example
  204. # [06:32] <othermaciej> misnested tags are in some sense a different level of error than structurally sound markup that happens to violate content model rules
  205. # [06:33] <MikeSmith> yeah, <b><i>foo</b></i> gets reported by the parser, not validator code
  206. # [06:33] <othermaciej> I think some people are interested in avoiding presentational markup in their output, and others are not
  207. # [06:33] <sayrer> for sure
  208. # [06:33] <othermaciej> right now the spec is a compromise and therefore doesn't fully address either need
  209. # [06:34] <othermaciej> I wonder if it would make sense to have two classes of conformance to address this
  210. # [06:34] <MikeSmith> "Error: End tag b violates nesting rules."
  211. # [06:34] <sayrer> I am in favor of an authoring guide
  212. # [06:35] <MikeSmith> I think it would make sense to have user-tunable validators
  213. # [06:36] <othermaciej> if we accept Henri's premise that there needs to be a shared set of rules, so that different combinations of content generators and validators can interoperate without large switching costs, then an authoring guide may be insufficient
  214. # [06:36] <othermaciej> I'm not sure if that premise is right
  215. # [06:37] <MikeSmith> there's a market for validators, just like there is a market for browsers
  216. # [06:37] <othermaciej> but it sounds plausible
  217. # [06:37] <MikeSmith> and people place value on validators
  218. # [06:38] <othermaciej> the idea being, my CMS generates markup that is error-free in Validator A, but I decide I like the user interface of Validator B better
  219. # [06:38] <othermaciej> can I switch without being flooded with errors?
  220. # [06:38] <MikeSmith> right
  221. # [06:38] <othermaciej> that seems to be a case where interoperability matters
  222. # [06:39] <othermaciej> so that makes me think that there has to be some shared definition of what counts as content errors
  223. # [06:39] <othermaciej> so it's not a viable position for the WG to completely fail to define authoring conformance
  224. # [06:39] <sayrer> I don't think any of that follows
  225. # [06:40] <sayrer> in particular, I am not suggesting the WG fail to define anything
  226. # [06:40] <othermaciej> I'm not saying you are suggesting that
  227. # [06:40] <sayrer> ok
  228. # [06:40] <MikeSmith> anyway, it does at least seem that there's a fundamental baseline of document-conformance rules that we could get agreement on
  229. # [06:40] <othermaciej> it is now clear to me that you think there should be some definition of what constitutes an error
  230. # [06:40] <othermaciej> and that at the very least, you don't think presentational markup or obsolete but harmless attributes should be in that category
  231. # [06:40] <sayrer> well, there are things that I would like to have attention brought to, as an author
  232. # [06:41] <sayrer> "this may not mean what you think it means" is something I want to know about
  233. # [06:41] <MikeSmith> right
  234. # [06:41] <MikeSmith> e.g., a <dd> as a child of <ul>
  235. # [06:42] <sayrer> well, what is the error you would report for that?
  236. # [06:42] <othermaciej> it's not clear to me what you think should be in that definition, or whether you think those rules should be labeled something other than "conformance", or how you feel about whether they need to be in a separate document from browser conformance rules
  237. # [06:43] <sayrer> 1.) not sure what should be there, probably requires user testing
  238. # [06:43] <sayrer> 2.) don't want the labeled as conformance requirements in the HTML document, somewhere else is fine
  239. # [06:43] <sayrer> 3.) probably separate
  240. # [06:44] <sayrer> MikeSmith: what is the ideal error for <dd> in <ul> ?
  241. # [06:44] <othermaciej> so it's ok to label the rules conformance requirements, but not if they are in the same document as browser conformance requirements?
  242. # [06:44] <sayrer> yes
  243. # [06:44] <othermaciej> I can understand the rest of your position, but not that part
  244. # [06:45] <sayrer> the other conformance requirements in the document have interop ramifications
  245. # [06:45] <MikeSmith> sayrer: I don't know what would be ideal, but at a minimum, the checker should report, "<dd> is not allowed as a child of <ul>"
  246. # [06:45] <sayrer> well, it is allowed
  247. # [06:45] <MikeSmith> and then report what is allowed as a child of <ul>
  248. # [06:46] <othermaciej> hsivonen would argue that validity rules have interop ramifications (between different validators and different content generators)
  249. # [06:46] <sayrer> I find that position pretty circular
  250. # [06:46] * Quits: zcorpan (n=zcorpan@c83-252-196-43.bredband.comhem.se)
  251. # [06:46] <othermaciej> I don't see how it's circular
  252. # [06:47] <othermaciej> the idea is that you can switch content generating tools without changing validators, or vice versa
  253. # [06:47] * Parts: JoePeck (n=JoePeck@cpe-74-69-85-249.rochester.res.rr.com)
  254. # [06:47] <othermaciej> I think it's a much less important form of interoperability than browser <--> content
  255. # [06:48] <othermaciej> but being able to switch out pieces independently is pretty much what interoperability means
  256. # [06:48] <MikeSmith> sayrer: OK, if I get your point, the error might more precisely be, "using <dd> as a child of <ul> is probably not going to have the effect you might be expecting"
  257. # [06:48] <MikeSmith> sayrer: "<dd> as a child of <ul> is probably not something you want to do"
  258. # [06:49] <sayrer> "we need this rule so the things that check rules will have a rule"
  259. # [06:50] <othermaciej> I think a more fair presentation of the position would be "we need rules about what is an error so that content producers and tools that check for content errors can agree on what is an error"
  260. # [06:51] <othermaciej> you could say "tools that check for content errors" should not label anything they report as errors, but the same reasoning applies if you call them "errors" or "conditions that indicate the author may not have said what he meant" or whatever
  261. # [06:52] <othermaciej> or "warnings"
  262. # [06:52] * Quits: sayrer (n=chatzill@cvo-cr1-203-149.peak.org) (Read error: 60 (Operation timed out))
  263. # [06:54] * Joins: Hixie (i=ianh@trivini.no)
  264. # [06:54] * Joins: dglazkov_ (n=dglazkov@72.14.224.1)
  265. # [06:55] * Joins: sayrer (n=chatzill@cvo-cr1-203-149.peak.org)
  266. # [06:55] * Joins: onar_ (n=onar@c-67-180-87-66.hsd1.ca.comcast.net)
  267. # [06:55] <sayrer> validator interop is not something the w3c is chartered to
  268. # [06:56] * Joins: dglazkov__ (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
  269. # [06:56] <sayrer> to do
  270. # [06:56] * Quits: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net) (Read error: 54 (Connection reset by peer))
  271. # [06:57] <sayrer> I am not even sure it's desirable, but if it is, every validator implementor will rush to become Rec FooValidator2015 or whatever
  272. # [06:57] <sayrer> I suppose there's a subtext of everyone being paranoid about rogue additions to the language
  273. # [06:57] <sayrer> but I don't think these rules are going to help that
  274. # [07:00] <othermaciej> I could buy that validator interop is not an important goal
  275. # [07:01] <sayrer> it would certainly be easier to suss out if the author conformance rules had clear, uniform motivations
  276. # [07:01] <othermaciej> so far, the one validator developer who has spoken up thinks it is
  277. # [07:01] <othermaciej> they do seem to have different motivations
  278. # [07:02] <MikeSmith> sayrer: it might also help if we used the term "document conformance" instead of "authoring conformance"
  279. # [07:02] <othermaciej> there's surface syntax errors where the motivation seems to be that they are likely to indicate an error, and may result in divergent behavior in older browsers
  280. # [07:03] <othermaciej> there's nesting rules where violating them results in parser madness (like <p> not allowed in <table>) or because some elements have very fixed behavior and other children don't make sense (like <div> not being allowed in <select>)
  281. # [07:03] <MikeSmith> othermaciej: right
  282. # [07:04] * dglazkov__ is now known as dglazkov
  283. # [07:04] <MikeSmith> there are also cases like, you can't nest <a href>s if you want them to have an expected effect
  284. # [07:05] <MikeSmith> or, as a class, you can't nest interactive elements
  285. # [07:05] <othermaciej> there's nesting rules that are based on what is believed to be proper semantic structure, but which are not in any way enforced and won't cause interop problems if you violate them (like <b> not allowed immediately inside <ul>)
  286. # [07:06] <othermaciej> there's elements or attribute that have an effect but are banned because they are presentational
  287. # [07:06] <MikeSmith> yeah
  288. # [07:06] <Hixie> <b> inside <ul> will cause problems to any tool that tries to do anything useful with list items in a list
  289. # [07:06] <othermaciej> there's elements or attributes that have no effect, and may have been in older specs, but are banned because they are useless
  290. # [07:06] <Hixie> (e.g. scripts that resort lists)
  291. # [07:07] <othermaciej> there's elements or attributes that have no current effect and were never in a spec (the general ban on unknown elements or attributes)
  292. # [07:07] <heycam> Hixie, "but the novice authors is cautioned" in the new "A quick introduction to HTML" section
  293. # [07:07] <othermaciej> there's rules for attribute values that disallow things that can't have an effect because they don't satisfy the basic syntax of the attribute (that would be in the "likely to be an error" category)
  294. # [07:07] <Hixie> heycam: thanks
  295. # [07:08] <othermaciej> I'm not sure if that list of categories was exhaustive
  296. # [07:08] <sayrer> elements that have an effect but were never in a spec
  297. # [07:09] <sayrer> that's all I can think of
  298. # [07:09] * Quits: bgalbraith (n=bgalbrai@71.202.109.116)
  299. # [07:09] * Quits: jacobolus (n=jacobolu@c-98-248-43-68.hsd1.ca.comcast.net) (Read error: 113 (No route to host))
  300. # [07:10] <othermaciej> there's also mandatory content, like the fact that documents must have a <title> or that <img> elements must have a src attribute
  301. # [07:13] <sayrer> those last two seem different to me
  302. # [07:13] <sayrer> maybe it's not important
  303. # [07:14] <othermaciej> I see your point; not sure how to express the difference
  304. # [07:14] <othermaciej> some mandatory content is mandatory because the associated container won't work otherwise
  305. # [07:14] * Quits: dglazkov_ (n=dglazkov@72.14.224.1) (Read error: 110 (Connection timed out))
  306. # [07:15] <othermaciej> many elements are also required to have " at least one descendant text node that is not inter-element whitespace, or at least one descendant element node that is embedded content"
  307. # [07:15] <othermaciej> which effectively rules out being empty
  308. # [07:16] <othermaciej> I'm not sure if that's in the "otherwise the element doesn't work" category of mandatory content, or the "because it seems right to require this" category
  309. # [07:16] <sayrer> one class of content nesting rules would seem to concern mark up where the DOM is quite different from the lexical nesting of the markup
  310. # [07:16] <sayrer> parser madness
  311. # [07:19] <othermaciej> if I'm reading the spec right, it seems like it is conforming for <table> or <ul> to be empty, but not for <p> or <b> to be empty
  312. # [07:20] * Quits: sayrer (n=chatzill@cvo-cr1-203-149.peak.org) ("ChatZilla 0.9.82.1-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  313. # [07:20] * Joins: sayrer (n=chatzill@cvo-cr1-203-149.peak.org)
  314. # [07:20] <sayrer> interesting. people put empty <p> elements in to space things out quite a lot
  315. # [07:20] <sayrer> heretical
  316. # [07:21] <othermaciej> empty <p> elements collapse away
  317. # [07:22] <othermaciej> (at least by default; you could presumably style them not to)
  318. # [07:23] <Hixie> you must be reading an old version of the spec
  319. # [07:23] <Hixie> either that or i missed some bit
  320. # [07:23] <Hixie> because empty <p> is explicitly allowed (though mildly discouraged) to enable scripts to fill them in later
  321. # [07:23] <Hixie> and to allow templates to be filled in later yet still be validated
  322. # [07:25] <sayrer> oh right
  323. # [07:25] <sayrer> must be <br>s or something when they do that
  324. # [07:27] <sayrer> anyway, we have quite a few axes for these rules
  325. # [07:27] <Hixie> <br>s?
  326. # [07:27] <othermaciej> I see, "flow content" non-emptiness is a SHOULD now
  327. # [07:40] * Joins: nessy (n=nessy@124-170-139-223.dyn.iinet.net.au)
  328. # [07:44] * Joins: jacobolus (n=jacobolu@adsl-69-227-227-155.dsl.pltn13.pacbell.net)
  329. # [07:52] <Hixie> hsivonen: yt?
  330. # [07:52] <Hixie> hsivonen: i'm still baffled by http://www.w3.org/Bugs/Public/show_bug.cgi?id=6776
  331. # [07:53] * Parts: sayrer (n=chatzill@cvo-cr1-203-149.peak.org)
  332. # [07:54] <hsivonen> Hixie: what's unclear?
  333. # [07:56] * Quits: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
  334. # [07:57] <Hixie> should i add something to the xhtml syntax section saying "XSLT 1.0 processors, when the method is 'html', must violate the XSLT 1.0 spec in the following way:"?
  335. # [07:57] <Hixie> or some other section?
  336. # [07:58] <Hixie> basically i don't understand where to put this
  337. # [07:58] <hsivonen> I'd put it near the text/html DOM API differences
  338. # [07:58] <Hixie> (and i am concerned about getting shot by the xslt working group for doing something that i really don't care about :-) )
  339. # [07:58] <Hixie> the case sensitivity stuff?
  340. # [07:58] <hsivonen> it would be confusing to put this in XHTML section
  341. # [07:58] <hsivonen> yeah
  342. # [07:59] <hsivonen> for wg concerns, see the linked bug
  343. # [07:59] <Hixie> i don't see how the section you're indicating has anything to do with xslt whatsoever
  344. # [07:59] <Hixie> it's all about the DOM
  345. # [07:59] <hsivonen> this is about the DOM, too
  346. # [08:01] <hsivonen> XSLT processors that output to a character or byte stream are unaffected
  347. # [08:03] <Hixie> hmmm
  348. # [08:03] <Hixie> ok
  349. # [08:08] * Joins: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de)
  350. # [08:19] * Quits: virtuelv (n=virtuelv@084202133045.customer.alfanett.no) (Read error: 60 (Operation timed out))
  351. # [08:20] * Quits: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
  352. # [08:24] * Quits: onar_ (n=onar@c-67-180-87-66.hsd1.ca.comcast.net)
  353. # [08:25] * Joins: jacobolu_ (n=jacobolu@adsl-69-227-227-155.dsl.pltn13.pacbell.net)
  354. # [08:26] * Quits: othermaciej (n=mjs@17.246.18.129)
  355. # [08:32] * Quits: jacobolu_ (n=jacobolu@adsl-69-227-227-155.dsl.pltn13.pacbell.net) (Remote closed the connection)
  356. # [08:34] <Hixie> hsivonen: ok, how is http://www.whatwg.org/specs/web-apps/current-work/#dom-based-xslt-1.0-processors
  357. # [08:39] <Hixie> well i checked it in
  358. # [08:39] <Hixie> let me know how it is
  359. # [08:40] * Joins: annevk2 (n=annevk@x1-6-00-1f-f3-c7-59-a0.k396.webspeed.dk)
  360. # [08:44] * Quits: jacobolus (n=jacobolu@adsl-69-227-227-155.dsl.pltn13.pacbell.net) (Read error: 110 (Connection timed out))
  361. # [08:46] * Joins: jacobolus (n=jacobolu@c-98-248-43-68.hsd1.ca.comcast.net)
  362. # [08:50] * Joins: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl)
  363. # [08:51] * Quits: jacobolus (n=jacobolu@c-98-248-43-68.hsd1.ca.comcast.net) (Remote closed the connection)
  364. # [08:58] * Joins: zdobersek (n=zan@cpe-92-37-69-125.dynamic.amis.net)
  365. # [09:01] * Joins: eighty4 (n=eighty4@eighty4.se)
  366. # [09:02] * Joins: hdh (n=hdh@hdh-1-pt.tunnel.tserv20.hkg1.ipv6.he.net)
  367. # [09:20] <hsivonen> Hixie: looks good
  368. # [09:20] <Hixie> woo
  369. # [09:21] <hsivonen> thanks
  370. # [09:24] * Joins: archtech (n=stanv@83.228.56.37)
  371. # [09:24] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  372. # [09:24] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  373. # [09:28] * Quits: dave_levin (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net)
  374. # [09:33] * Joins: jacobolus (n=jacobolu@c-98-248-43-68.hsd1.ca.comcast.net)
  375. # [09:34] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) ("bye")
  376. # [09:39] * Quits: jacobolus (n=jacobolu@c-98-248-43-68.hsd1.ca.comcast.net) (Remote closed the connection)
  377. # [09:39] * Joins: jacobolus (n=jacobolu@c-98-248-43-68.hsd1.ca.comcast.net)
  378. # [09:40] * Parts: annevk2 (n=annevk@x1-6-00-1f-f3-c7-59-a0.k396.webspeed.dk)
  379. # [09:40] * Joins: annevk2 (n=annevk@x1-6-00-1f-f3-c7-59-a0.k396.webspeed.dk)
  380. # [09:45] * Quits: hdh (n=hdh@hdh-1-pt.tunnel.tserv20.hkg1.ipv6.he.net) (Remote closed the connection)
  381. # [09:52] * Quits: drostie (n=hopkins@5ED17066.cable.ziggo.nl) (Remote closed the connection)
  382. # [09:54] * Joins: hdh (n=hdh@hdh-1-pt.tunnel.tserv20.hkg1.ipv6.he.net)
  383. # [10:12] * Quits: annevk2 (n=annevk@x1-6-00-1f-f3-c7-59-a0.k396.webspeed.dk)
  384. # [10:15] * Joins: BARTdG (n=BARTdG@5ED42544.cable.ziggo.nl)
  385. # [10:17] * Joins: danbri (n=danbri@s5590d015.adsl.wanadoo.nl)
  386. # [10:22] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  387. # [10:22] * Quits: BARTdG (n=BARTdG@5ED42544.cable.ziggo.nl) ("Apparaat USB-apparaat voor massa-opslag uit systeem verwijderd")
  388. # [10:34] <Hixie> hsivonen: still here?
  389. # [10:36] * Joins: tiglionabbit (n=nick@67-207-136-95.slicehost.net)
  390. # [10:36] <Hixie> hsivonen: http://www.whatwg.org/specs/web-apps/current-work/#interactions-with-xpath-and-xslt
  391. # [10:36] <Hixie> checked in
  392. # [10:46] * Joins: zcorpan (n=zcorpan@c83-252-196-43.bredband.comhem.se)
  393. # [10:49] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  394. # [10:52] <hsivonen> Hixie: looks good. thanks
  395. # [10:53] <hsivonen> Hixie: can the XPath bit be annotated as implemented in Gecko and WebKit and the XSLT bit be annotated as implemented in Gecko?
  396. # [10:55] <hsivonen> hmm. does WebKit output to DOM from XSLT?
  397. # [10:56] <othermaciej> WebKit's XSLT will serialize and reparse
  398. # [10:56] <hsivonen> othermaciej: thanks
  399. # [10:57] <Hixie> hsivonen: reload and there should be separate IDs for the two parts of that section
  400. # [10:57] <othermaciej> I believe that makes the given conformance requirement inapplicable
  401. # [10:57] <hsivonen> othermaciej: it does, yes
  402. # [10:58] <hsivonen> I annotated Gecko and WebKit nightlies as supporting the section
  403. # [10:58] <hsivonen> since the last part doesn't apply to WebKit
  404. # [11:01] <MikeSmith> Hixie: can you conceive of any possible workaround for the Webkit bug that prevents get-author-view-onload of the spec from working?
  405. # [11:02] * Quits: zcorpan (n=zcorpan@c83-252-196-43.bredband.comhem.se) (Read error: 110 (Connection timed out))
  406. # [11:02] <othermaciej> MikeSmith: what's the bug?
  407. # [11:02] <Hixie> MikeSmith: i wrote a workaround earlier today
  408. # [11:03] <Hixie> othermaciej: .disabled doesn't seem to work on <link rel=stylesheet> in webkit the first time it's set, or something
  409. # [11:03] <Hixie> hsivonen: cool, thanks
  410. # [11:03] <othermaciej> weird
  411. # [11:04] <Hixie> othermaciej: i haven't created a minimal test case, so i don't know exactly what the issue is
  412. # [11:05] <MikeSmith> othermaciej: https://bugs.webkit.org/show_bug.cgi?id=26673
  413. # [11:06] <othermaciej> sounds plausible
  414. # [11:06] <othermaciej> maybe a kind volunteer will make a reduction
  415. # [11:07] * Joins: ZombieLoffe (n=e@unaffiliated/zombieloffe)
  416. # [11:08] * Quits: hdh (n=hdh@hdh-1-pt.tunnel.tserv20.hkg1.ipv6.he.net) (Remote closed the connection)
  417. # [11:08] * Joins: zcorpan (n=zcorpan@c83-252-196-43.bredband.comhem.se)
  418. # [11:09] * Joins: ROBOd (n=robod@89.122.216.38)
  419. # [11:10] * Joins: mat_t (n=mattomas@nat/canonical/x-82f398b1570649f0)
  420. # [11:11] <takkaria> hey, has anyone got a recentish IE to hand?
  421. # [11:11] <jgraham> othermaciej: The thing that we are more likely to have to spend time on is how aria interacts with HTML semantically e.g. what does aria-labelledby mean on a table cell if it does/does not point to a table header
  422. # [11:11] <jgraham> takkaria: Install virtualbox :)
  423. # [11:11] <jgraham> (or: yes)
  424. # [11:12] <takkaria> I'm wondering what IE does if you go to "http://spaces.ru/fff/6789004718042409/0/427562/Gameloft_Asphalt_4_Elite_Racing_3D_HD_v1.0.6_S60v3_SymbianOS9.sisx", mainly whether it tries to display the page or whether it pops up a download box
  425. # [11:12] <othermaciej> jgraham: I could also imagine additional validity rules preventing nonsensical combinations
  426. # [11:12] <othermaciej> like <input type="text" role="checkbox">
  427. # [11:13] <Hixie> currently aria actually says we're not allowed to disallow that
  428. # [11:13] <jgraham> othermaciej: So can I
  429. # [11:13] <Hixie> that was one of my last call comments
  430. # [11:13] <Hixie> are there any content models that use "Text" other than <option>, <title>, and <textarea>?
  431. # [11:14] <othermaciej> Hixie: what's the specific part that says that?
  432. # [11:14] * Joins: heycam (n=cam@124-168-58-6.dyn.iinet.net.au)
  433. # [11:14] <Hixie> othermaciej: i forget the exact section off-hand
  434. # [11:15] <othermaciej> does it have conformance requirements for markup language specifications?
  435. # [11:16] <othermaciej> (they don't seem to have a clear statement of conformance classes)
  436. # [11:16] <Hixie> http://www.w3.org/WAI/PF/comments/details?comment_id=267
  437. # [11:16] <Hixie> see section 6.1.1
  438. # [11:17] <Hixie> http://www.w3.org/TR/2009/WD-wai-aria-20090224/#host_general_role
  439. # [11:17] * Joins: ap (n=ap@194.154.88.47)
  440. # [11:17] <othermaciej> I see, that does seem like a problem
  441. # [11:18] * Joins: annevk2 (n=annevk@131.165.177.65)
  442. # [11:18] <othermaciej> I wonder if that is intentionally meant to prevent banning of crazy combinations, or just an attempt to say a language can't ban all use of an ARIA role wholesale, without considering the issue
  443. # [11:20] <jgraham> othermaciej: I have heard various aria types insist that aria should always override host semantics so <input type=text role=checkbox> would be considered fine and indicative of a checkbox
  444. # [11:21] <othermaciej> jgraham: it's kind of crazy to consider it fine
  445. # [11:21] <othermaciej> but one thing I didn't realize before is that overriding host semantics has some associated implementation challenge
  446. # [11:22] <othermaciej> because any time an ARIA-related attribute is set at all, you have to stop doing all or most of the built-in accessibility behavior
  447. # [11:22] <Philip`> takkaria: I get a download prompt in IE8 on Vista
  448. # [11:22] <othermaciej> or at least, it seems like the output of assistive technologies would be nonsense if something was both a checkbox and a text box, or (as in Hixie's example) both checked and unchecked
  449. # [11:22] * Quits: zcorpan (n=zcorpan@c83-252-196-43.bredband.comhem.se) (Read error: 60 (Operation timed out))
  450. # [11:24] * Joins: mpt_ (n=mpt@canonical/launchpad/mpt)
  451. # [11:24] <takkaria> Philip`: thanks
  452. # [11:24] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Read error: 113 (No route to host))
  453. # [11:27] * Quits: annevk2 (n=annevk@131.165.177.65) (Read error: 104 (Connection reset by peer))
  454. # [11:32] * Quits: jwalden (n=waldo@c-98-248-40-206.hsd1.ca.comcast.net) ("ChatZilla 0.9.85 [Firefox 3.5pre/20090624033017]")
  455. # [11:33] <Hixie> i just got my first ironic error message from hsivonen's validator
  456. # [11:34] <jgraham> The validator does irony now?
  457. # [11:35] <Hixie> while validating the spec after changing it to allow <p> in <caption>, which included a change to an example to add an actual <p> to an actual <caption>, the validator told me that that was wrong.
  458. # [11:35] * Joins: roc (n=roc@121.74.138.213)
  459. # [11:35] <takkaria> you need a "I am the spec author and what I say goes" box on v.nu
  460. # [11:37] <Hixie> actually adding the validator step to my generator script has caught so many typos and errors that it's awesome
  461. # [11:39] * mpt_ is now known as mpt
  462. # [11:49] <MikeSmith> jgraham, Hixie: browsers generally behave as expected for multiple pargraphs or lists in a <caption>?
  463. # [11:51] <jgraham> MikeSmith: AFAICT yes
  464. # [11:53] <hsivonen> how many WebKit ports does Nokia have and how many of them are active?
  465. # [11:53] <MikeSmith> hsivonen: as far as I know of it least, they have one: the native S60 port
  466. # [11:54] <othermaciej> they have the Qt port
  467. # [11:54] <MikeSmith> and it is not being actively developed, and has not been for a long time
  468. # [11:54] <othermaciej> as far as I know, that's the only port that Nokia actually maintains upstream
  469. # [11:54] <MikeSmith> othermaciej: they have an S60 QtWebKit port now
  470. # [11:55] <othermaciej> I don't know what if anything they do in private trees
  471. # [11:55] * Joins: drostie (n=hopkins@wlan-145-94-168-181.wlan.tudelft.nl)
  472. # [11:55] <MikeSmith> a "pre-release" one - http://sideshowbarker.net/2009/06/26/s60-qtwebkit/
  473. # [11:56] <hsivonen> MikeSmith: the native S60 port that shipped with S60r3.1 is dead, right? so is QtWebKit what they are on track shipping when they next refresh the bundled browser on S60?
  474. # [11:56] <MikeSmith> hsivonen: as far as I can tell, yeah, the native S60 port is dead.
  475. # [11:56] <hsivonen> ok
  476. # [11:57] <MikeSmith> as far as how QtWebKit fits into their product plans, they have said nothing publicly
  477. # [11:57] <othermaciej> they don't maintain the webkit.org copy of it that lives on a very old branch
  478. # [11:57] <othermaciej> (the native S60 port)
  479. # [11:58] <MikeSmith> http://sideshowbarker.net/2008/04/11/s60-webkit-dead/
  480. # [12:00] <MikeSmith> that was more than 1 year ago, they closed all open bugs on it en masse
  481. # [12:00] <MikeSmith> after there had at that time not been any checkins to the branch for 8 months
  482. # [12:00] <othermaciej> I would guess the native S60 port is abandoned but there's not been a definitive statement
  483. # [12:00] <othermaciej> it's possible they did all sorts of things in a private tree, or maybe not
  484. # [12:01] <othermaciej> who knows?
  485. # [12:02] <MikeSmith> the work QtWebKit port for S60 is being done in public, I think
  486. # [12:02] <MikeSmith> I mean, I think they have a publicly readable repository
  487. # [12:02] <MikeSmith> heh
  488. # [12:02] <MikeSmith> this is what dude wrote at the time in response to my post -
  489. # [12:02] <MikeSmith> http://blogs.s60.com/2008/04/whoa_there
  490. # [12:03] <othermaciej> sure, it's clear that QtWebKit for S60 is being worked on
  491. # [12:03] <othermaciej> and one could certainly guess they want this to be part of their product strategy
  492. # [12:03] <MikeSmith> "We are not backing away from Webkit no matter what you might have read on one of those new-fangled “website” things ... No, no, no — it’s just that we’re focusing on the newer Leopard branch"
  493. # [12:04] <MikeSmith> anyway, ancient history now
  494. # [12:04] * Joins: myakura (n=myakura@p1145-ipbf7105marunouchi.tokyo.ocn.ne.jp)
  495. # [12:04] <othermaciej> I believe they tried to bring their port up to the Safari 3.0 version of WebKit and failed
  496. # [12:06] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  497. # [12:06] <Hixie> ok time to go to bed
  498. # [12:06] <Hixie> actually long past time to go to bed
  499. # [12:06] <Hixie> nn
  500. # [12:15] * Quits: MikeSmith (n=MikeSmit@tea14.w3.mag.keio.ac.jp) ("Tomorrow to fresh woods, and pastures new.")
  501. # [12:20] * othermaciej is now known as om_sleep
  502. # [12:21] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Read error: 104 (Connection reset by peer))
  503. # [12:22] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  504. # [12:24] * Joins: Romme (n=romme@78.111.82.66)
  505. # [12:24] <Romme> is here a right place to ask about html5lib? i've googled, but still haven't found the answer
  506. # [12:25] <takkaria> sure
  507. # [12:28] <jgraham> Romme: Ask away
  508. # [12:29] <hsivonen> Nokia also has a port of WebKit for Maemo, right? A variant of the GTK port.
  509. # [12:29] <Romme> jgraham: how do i serialize an element without including it's start and end tags?
  510. # [12:30] * Quits: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de) (Read error: 110 (Connection timed out))
  511. # [12:32] <Romme> i've tried ''.join(serializer.HTMLSerializer().serialize(walker(lxmletree.FragmentRoot(content)), 'UTF-8')), where content is my element
  512. # [12:33] <Romme> but it then serializes everything until my document ends
  513. # [12:36] * Joins: jacobolu_ (n=jacobolu@c-76-102-55-224.hsd1.ca.comcast.net)
  514. # [12:36] <Romme> and i don't quite understand what FragmentWrapper and FragmentRoot are for
  515. # [12:39] <jgraham> Romme: Of the top of my head I don't think we support that in an easy way but it does seen like a reasonable feature request. I'm pretty sure it is possible to hack
  516. # [12:39] <jgraham> (sorry I got distracted by rl)
  517. # [12:40] <Romme> i've heard that if i parse my data with parseFragment, then i will get a fragment when serializing as well, but the problem is, i'm not parsing a fragment, but a document instead
  518. # [12:42] <jgraham> Romme: Which tree backend are you using?
  519. # [12:42] <Romme> jgraham: lxml
  520. # [12:44] * Quits: drostie (n=hopkins@wlan-145-94-168-181.wlan.tudelft.nl) (Remote closed the connection)
  521. # [12:44] <takkaria> are there any tests for abarth's content-type sniffing draft?
  522. # [12:44] <jgraham> Romme: Give me a moment I will just check something
  523. # [12:44] <jgraham> takkaria: IIRC gsnedders has some
  524. # [12:45] <takkaria> hm, I guess I'll wait til he comes online again
  525. # [12:46] <jgraham> takkaria: You may see him in person before then :)
  526. # [12:47] <takkaria> that is a point :)
  527. # [12:47] * Quits: jacobolus (n=jacobolu@c-98-248-43-68.hsd1.ca.comcast.net) (Read error: 113 (No route to host))
  528. # [12:49] <jgraham> Romme: t = html5lib.parse("<div><a>b</a> abc <b>c</b></div>", treebuilder="lxml")
  529. # [12:49] <jgraham> tw = html5lib.treewalkers.getTreeWalker("lxml")
  530. # [12:49] <jgraham> div = t.find("//div")
  531. # [12:49] <jgraham> for item in tw(list(div)):print item
  532. # [12:50] <jgraham> gives all the children of the <div> but not the <div> itself. So I guess that will serialize OK
  533. # [12:50] <Romme> i would have just serialized it with lxml then :P
  534. # [12:51] <Romme> i need the features of html5lib, like omitting optional tags or quotes in attribute names
  535. # [12:51] <Romme> oops
  536. # [12:51] <Romme> sorry
  537. # [12:52] <Romme> didn't notice the "tw"
  538. # [12:52] <jgraham> s = html5lib.serializer.HTMLSerializer()
  539. # [12:52] <jgraham> s.render(tw(list(div)))
  540. # [12:52] <jgraham> u'<a>b</a> abc <b>c</b>'
  541. # [12:54] <Romme> i wonder why render() converts it to a list instead of just iterating
  542. # [12:56] <Romme> jgraham: thanks, but that serialized it until my document ended
  543. # [12:57] <jgraham> Romme: I don't actually know, but it might be a theory that doing join on a list is faster than joing it on an iterator. I have no idea if this is true or not
  544. # [12:57] <Romme> with end tags for element which haven't started
  545. # [12:57] <jgraham> Romme: Can you give an example of something that doesn't work?
  546. # [12:57] * Joins: Midler (n=midler@95.209.32.185.bredband.tre.se)
  547. # [12:58] <Romme> jgraham: wait a moment, i'll create a testcase
  548. # [12:58] * Quits: mat_t (n=mattomas@nat/canonical/x-82f398b1570649f0) ("This computer has gone to sleep")
  549. # [12:59] * Joins: mat_t (n=mattomas@nat/canonical/x-ca15dc01f139c320)
  550. # [13:00] * jgraham notes that using list() or not seems to make no speed difference
  551. # [13:01] * Joins: Midler1 (n=midler@95.209.12.57.bredband.tre.se)
  552. # [13:03] <Romme> a few more minutes
  553. # [13:08] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (Read error: 104 (Connection reset by peer))
  554. # [13:13] <Romme> jgraham: http://files.getdropbox.com/u/268483/testcase.tar.bz2
  555. # [13:16] * Quits: Midler (n=midler@95.209.32.185.bredband.tre.se) (Read error: 110 (Connection timed out))
  556. # [13:21] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
  557. # [13:23] <Midler1> In case someone of you have missed (its not about html5...but still) http://blogs.msdn.com/outlook/archive/2009/06/24/the-power-of-word-in-outlook.aspx#commentform
  558. # [13:24] <Midler1> its like they will stay in the 90:s forever
  559. # [13:32] <Romme> well, at least they're not dicks about letting us hide that thing out of sight. i'm quite tired of minimizing evolution and moving it to the second workspace
  560. # [13:34] <jgraham> Romme: AFAICT your testcase works. At least the textcontent of the serialized fragment seems to be the same as that of the div element
  561. # [13:35] <jgraham> Possibly the div just doesn't get closed?
  562. # [13:36] <Romme> jgraham: Vim confirms that the div is indeed closed
  563. # [13:36] <Romme> hmmph, maybe it's just my version of html5lib, i'll try installing the newest one
  564. # [13:36] <Romme> what version are you using?
  565. # [13:37] <jgraham> Romme: Some random development version. I don't recommend pulling the head at the moment though; things are not really in a perfect state
  566. # [13:37] <jgraham> This is unlikely to have changed
  567. # [13:42] <jgraham> Oh wait, I am probably wrong
  568. # [13:58] * Quits: zdobersek (n=zan@cpe-92-37-69-125.dynamic.amis.net) (Read error: 110 (Connection timed out))
  569. # [13:59] * Joins: zdobersek (n=zan@cpe-92-37-77-71.dynamic.amis.net)
  570. # [14:06] <jgraham> Romme: When I said I was wrong, I meant about the testcase working for me. I was comparing the wrong things. I think the solution is more complex than I first thought
  571. # [14:06] <jgraham> One approach would be to write a filter that dropped the first tag and everything after the matching end tag
  572. # [14:09] * Joins: billyjackass (n=MikeSmit@EM114-48-211-4.pool.e-mobile.ne.jp)
  573. # [14:09] * Joins: MikeSmith (n=MikeSmit@EM114-48-211-4.pool.e-mobile.ne.jp)
  574. # [14:09] * Quits: billyjackass (n=MikeSmit@EM114-48-211-4.pool.e-mobile.ne.jp) (Client Quit)
  575. # [14:09] <jgraham> In theory using copy.deepcopy to get the nodes into a list could work (because afaik it breaks parent pointers) but I think it doesn't actually work right now
  576. # [14:09] <jgraham> File a feature request
  577. # [14:10] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  578. # [14:11] * Joins: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de)
  579. # [14:12] * Philip` decides that writing a GUI half in C++ and half in JS is actually quite a pain
  580. # [14:12] <Philip`> so I suppose I should just rewrite it all in JS
  581. # [14:12] <hsivonen> Philip`: Firefox?
  582. # [14:13] <Philip`> hsivonen: No, something using wxWidgets
  583. # [14:18] <Philip`> Hmm, I currently have three separate sections of code viewing and controlling the same piece of data (GUI written in JS; GUI written in C++; game engine in C++ in another thread) - I wonder if there's meant to be some magic design pattern that makes it all stay in sync trivially...
  584. # [14:20] <Philip`> s/makes/would make/
  585. # [14:22] * Quits: jacobolu_ (n=jacobolu@c-76-102-55-224.hsd1.ca.comcast.net) (Remote closed the connection)
  586. # [14:23] * Joins: jacobolus (n=jacobolu@c-76-102-55-224.hsd1.ca.comcast.net)
  587. # [14:30] <hendry> Philip`: when in doubt, write in C
  588. # [14:49] * Joins: kangax (n=kangax@ool-182f8118.dyn.optonline.net)
  589. # [14:58] <Philip`> hendry: I'd generally prefer to make things easier for myself, not harder :-)
  590. # [15:19] * Joins: pmuellr (n=pmuellr@nat/ibm/x-60db570c7b53f26a)
  591. # [15:37] * Joins: zdobersek1 (n=zan@cpe-92-37-71-156.dynamic.amis.net)
  592. # [15:38] * Joins: aroben (n=aroben@unaffiliated/aroben)
  593. # [15:43] * Quits: zdobersek (n=zan@cpe-92-37-77-71.dynamic.amis.net) (Read error: 60 (Operation timed out))
  594. # [15:46] * Quits: ap (n=ap@194.154.88.47)
  595. # [15:59] * Quits: kangax (n=kangax@ool-182f8118.dyn.optonline.net)
  596. # [16:06] * Joins: bgalbraith (n=bgalbrai@71.202.109.116)
  597. # [16:11] * Joins: onar_ (n=onar@c-67-180-87-66.hsd1.ca.comcast.net)
  598. # [16:12] * Quits: onar_ (n=onar@c-67-180-87-66.hsd1.ca.comcast.net) (Client Quit)
  599. # [16:20] * Joins: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
  600. # [16:21] * Quits: bgalbraith (n=bgalbrai@71.202.109.116) (Read error: 60 (Operation timed out))
  601. # [16:31] * Joins: zdobersek (n=zan@cpe-92-37-70-216.dynamic.amis.net)
  602. # [16:40] * Joins: bgalbraith (n=bgalbrai@nat/mozilla/x-471ce159c3c68964)
  603. # [16:40] * Joins: zdobersek2 (n=zan@cpe-92-37-64-226.dynamic.amis.net)
  604. # [16:46] * Quits: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
  605. # [16:46] * Quits: zdobersek1 (n=zan@cpe-92-37-71-156.dynamic.amis.net) (Read error: 110 (Connection timed out))
  606. # [16:54] * Quits: zdobersek (n=zan@cpe-92-37-70-216.dynamic.amis.net) (Read error: 110 (Connection timed out))
  607. # [16:58] * Quits: myakura (n=myakura@p1145-ipbf7105marunouchi.tokyo.ocn.ne.jp) (Read error: 110 (Connection timed out))
  608. # [17:00] * Joins: zdobersek (n=zan@cpe-92-37-77-193.dynamic.amis.net)
  609. # [17:00] * Quits: zdobersek2 (n=zan@cpe-92-37-64-226.dynamic.amis.net) (Read error: 110 (Connection timed out))
  610. # [17:03] * Quits: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl) ("Disconnected...")
  611. # [17:04] * Joins: zdobersek1 (n=zan@cpe-92-37-68-112.dynamic.amis.net)
  612. # [17:06] * Quits: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de) (Remote closed the connection)
  613. # [17:08] * Joins: zcorpan (n=zcorpan@c83-252-196-43.bredband.comhem.se)
  614. # [17:10] * Joins: kangax (n=kangax@157.130.31.226)
  615. # [17:17] * Quits: zdobersek (n=zan@cpe-92-37-77-193.dynamic.amis.net) (No route to host)
  616. # [17:26] * Quits: zcorpan (n=zcorpan@c83-252-196-43.bredband.comhem.se) (Read error: 110 (Connection timed out))
  617. # [17:30] * Joins: dglazkov (n=dglazkov@nat/google/x-486b4e1fd57f18a3)
  618. # [17:33] * Quits: nessy (n=nessy@124-170-139-223.dyn.iinet.net.au) ("This computer has gone to sleep")
  619. # [17:42] * Joins: sbublava (n=stephan@77.116.156.215.wireless.dyn.drei.com)
  620. # [17:43] * Joins: ttepasse (n=ttepasse@dslb-084-060-019-060.pools.arcor-ip.net)
  621. # [17:44] * Joins: dave_levin (n=dave_lev@72.14.227.1)
  622. # [17:48] * Quits: Dashiva (i=Dashiva@wikia/Dashiva)
  623. # [17:49] * Quits: mat_t (n=mattomas@nat/canonical/x-ca15dc01f139c320) ("Leaving")
  624. # [17:57] * Joins: mat_t (n=mattomas@nat/canonical/x-fb3747ce485e42f8)
  625. # [18:07] * Joins: myakura (n=myakura@p1145-ipbf7105marunouchi.tokyo.ocn.ne.jp)
  626. # [18:28] * Joins: sbublava_ (n=stephan@77.118.28.61.wireless.dyn.drei.com)
  627. # [18:31] * Joins: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
  628. # [18:31] * Quits: Romme (n=romme@78.111.82.66) ("Ex-Chat")
  629. # [18:39] * Quits: sbublava (n=stephan@77.116.156.215.wireless.dyn.drei.com) (Read error: 104 (Connection reset by peer))
  630. # [18:41] * Quits: Midler1 (n=midler@95.209.12.57.bredband.tre.se) ("Leaving.")
  631. # [18:49] * Joins: tndH (n=Rob@host86-154-227-105.range86-154.btcentralplus.com)
  632. # [18:57] * Quits: sbublava_ (n=stephan@77.118.28.61.wireless.dyn.drei.com)
  633. # [18:58] * Joins: cying (n=cying@70.90.171.153)
  634. # [19:00] * Joins: cyberpea1 (n=james@fedora/cyberpear)
  635. # [19:01] * Quits: mat_t (n=mattomas@nat/canonical/x-fb3747ce485e42f8) ("This computer has gone to sleep")
  636. # [19:05] * Joins: mat_t (n=mattomas@nat/canonical/x-410a7bd334b371bc)
  637. # [19:05] * Quits: cyberpea1 (n=james@fedora/cyberpear) (Read error: 60 (Operation timed out))
  638. # [19:08] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  639. # [19:10] * Joins: mlpug (n=mlpug@a88-115-161-57.elisa-laajakaista.fi)
  640. # [19:11] * Joins: maikmerten (n=maikmert@BAE345f.bae.pppool.de)
  641. # [19:11] * Joins: cyberpea1 (n=james@fedora/cyberpear)
  642. # [19:12] * Quits: mat_t (n=mattomas@nat/canonical/x-410a7bd334b371bc) (leguin.freenode.net irc.freenode.net)
  643. # [19:12] * Quits: aroben (n=aroben@unaffiliated/aroben) (leguin.freenode.net irc.freenode.net)
  644. # [19:12] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (leguin.freenode.net irc.freenode.net)
  645. # [19:12] * Quits: ZombieLoffe (n=e@unaffiliated/zombieloffe) (leguin.freenode.net irc.freenode.net)
  646. # [19:12] * Quits: inimino (n=inimino@atekomi.inimino.org) (leguin.freenode.net irc.freenode.net)
  647. # [19:12] * Joins: mat_t (n=mattomas@nat/canonical/x-bc60ad139c22ea25)
  648. # [19:12] * Joins: aroben (n=aroben@unaffiliated/aroben)
  649. # [19:12] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  650. # [19:12] * Joins: ZombieLoffe (n=e@unaffiliated/zombieloffe)
  651. # [19:17] * Quits: cyberpear (n=james@fedora/cyberpear) (Connection timed out)
  652. # [19:20] * Joins: weinig (n=weinig@17.246.16.228)
  653. # [19:21] * Quits: mat_t (n=mattomas@nat/canonical/x-bc60ad139c22ea25) (Read error: 54 (Connection reset by peer))
  654. # [19:28] * Quits: weinig (n=weinig@17.246.16.228)
  655. # [19:38] * Quits: ttepasse (n=ttepasse@dslb-084-060-019-060.pools.arcor-ip.net) ("?Q")
  656. # [19:39] * Joins: cyberpear (n=james@fedora/cyberpear)
  657. # [19:42] * Joins: weinig (n=weinig@17.246.16.228)
  658. # [19:47] * Joins: Midler (n=midler@95.209.1.191.bredband.tre.se)
  659. # [19:53] * Joins: dbaron (n=dbaron@nat/mozilla/x-9c7d848aaa27c300)
  660. # [19:56] * Quits: cyberpea1 (n=james@fedora/cyberpear) (Read error: 110 (Connection timed out))
  661. # [19:57] * Quits: weinig (n=weinig@17.246.16.228)
  662. # [20:02] * Joins: cyberpea3 (n=james@fedora/cyberpear)
  663. # [20:03] * Joins: weinig (n=weinig@17.246.16.228)
  664. # [20:06] * Quits: dolske (n=dolske@c-76-103-40-203.hsd1.ca.comcast.net)
  665. # [20:07] * Quits: cyberpear (n=james@fedora/cyberpear) (Read error: 110 (Connection timed out))
  666. # [20:10] * Joins: slightlyoff (n=slightly@72.14.229.81)
  667. # [20:10] * Joins: allanmac (n=allanmac@dsl092-075-022.bos1.dsl.speakeasy.net)
  668. # [20:14] * Quits: danbri (n=danbri@unaffiliated/danbri)
  669. # [20:15] * Joins: yshin (n=yshin@72.14.227.1)
  670. # [20:17] * Quits: weinig (n=weinig@17.246.16.228)
  671. # [20:17] * Quits: myakura (n=myakura@p1145-ipbf7105marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  672. # [20:18] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  673. # [20:19] * Joins: cyberpea1 (n=james@fedora/cyberpear)
  674. # [20:26] * Quits: cyberpea3 (n=james@fedora/cyberpear) (Success)
  675. # [20:27] * Joins: weinig (n=weinig@17.246.16.228)
  676. # [20:30] * Quits: MikeSmith (n=MikeSmit@EM114-48-211-4.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
  677. # [20:31] * Joins: Dashiva (i=Dashiva@m223j.studby.ntnu.no)
  678. # [20:32] * Joins: dolske (n=dolske@nat/mozilla/x-1d8582e591fcc274)
  679. # [20:35] * Quits: dolske (n=dolske@nat/mozilla/x-1d8582e591fcc274) (Client Quit)
  680. # [20:36] * Joins: inimino (n=inimino@atekomi.inimino.org)
  681. # [20:36] * Joins: dolske (n=dolske@nat/mozilla/x-2be62b94f4a05bd8)
  682. # [20:45] * Quits: cyberpea1 (n=james@fedora/cyberpear) (Read error: 110 (Connection timed out))
  683. # [20:46] * Joins: danbri (n=danbri@s5590d015.adsl.wanadoo.nl)
  684. # [20:46] * Quits: weinig (n=weinig@17.246.16.228)
  685. # [20:47] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Read error: 113 (No route to host))
  686. # [20:48] * Quits: danbri (n=danbri@unaffiliated/danbri) (Client Quit)
  687. # [20:50] * Joins: taf2 (n=taf2@68.49.245.59)
  688. # [21:00] * Joins: weinig (n=weinig@17.246.16.228)
  689. # [21:01] * Joins: cyberpea2 (n=james@fedora/cyberpear)
  690. # [21:03] * Joins: zcorpan (n=zcorpan@c83-252-196-43.bredband.comhem.se)
  691. # [21:12] * Joins: jwalden (n=waldo@nat/mozilla/x-5c45ae8f84650f84)
  692. # [21:17] * Quits: kangax (n=kangax@157.130.31.226)
  693. # [21:21] * Quits: cyberpea2 (n=james@fedora/cyberpear) (Read error: 110 (Connection timed out))
  694. # [21:23] * Quits: cying (n=cying@70.90.171.153)
  695. # [21:31] * Parts: zcorpan (n=zcorpan@c83-252-196-43.bredband.comhem.se)
  696. # [21:34] * Quits: allanmac (n=allanmac@dsl092-075-022.bos1.dsl.speakeasy.net) ("Leaving.")
  697. # [21:35] * Joins: ttepasse (n=ttepasse@dslb-084-060-062-244.pools.arcor-ip.net)
  698. # [21:41] * Joins: jennb (n=jennb@72.14.227.1)
  699. # [21:44] * Joins: cyberpear (n=james@fedora/cyberpear)
  700. # [21:59] * Quits: pmuellr (n=pmuellr@nat/ibm/x-60db570c7b53f26a)
  701. # [22:02] * Quits: yshin (n=yshin@72.14.227.1) (Read error: 110 (Connection timed out))
  702. # [22:12] * Joins: danbri (n=danbri@s5590d015.adsl.wanadoo.nl)
  703. # [22:13] * Joins: kangax (n=kangax@157.130.31.226)
  704. # [22:13] * Joins: danbri_ (n=danbri@s5590d015.adsl.wanadoo.nl)
  705. # [22:18] * Quits: bgalbraith (n=bgalbrai@nat/mozilla/x-471ce159c3c68964)
  706. # [22:26] * Joins: cying (n=cying@70.90.171.153)
  707. # [22:29] * Joins: yshin (n=yshin@72.14.227.1)
  708. # [22:30] * Quits: danbri_ (n=danbri@unaffiliated/danbri) (Connection timed out)
  709. # [22:35] * Quits: danbri (n=danbri@unaffiliated/danbri) (Read error: 110 (Connection timed out))
  710. # [22:37] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  711. # [22:39] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  712. # [22:48] * Joins: danbri (n=danbri@s5590d015.adsl.wanadoo.nl)
  713. # [22:52] * Quits: danbri (n=danbri@unaffiliated/danbri) (Client Quit)
  714. # [22:53] * Joins: bgalbraith (n=bgalbrai@nat/mozilla/x-a88fc4060c12f7c3)
  715. # [22:56] * Quits: om_sleep (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  716. # [23:06] * Quits: maikmerten (n=maikmert@BAE345f.bae.pppool.de) (Remote closed the connection)
  717. # [23:18] * Quits: tndH (n=Rob@host86-154-227-105.range86-154.btcentralplus.com) ("ChatZilla 0.9.85-rdmsoft [XULRunner 1.9.0.1/2008072406]")
  718. # [23:27] * Quits: cying (n=cying@70.90.171.153)
  719. # [23:28] * Parts: zdobersek1 (n=zan@cpe-92-37-68-112.dynamic.amis.net)
  720. # [23:28] * Joins: ojan (n=ojan@72.14.229.81)
  721. # [23:36] * Quits: ttepasse (n=ttepasse@dslb-084-060-062-244.pools.arcor-ip.net) ("?Q")
  722. # [23:41] * Joins: dimich_ (n=dimich@72.14.227.1)
  723. # [23:43] * Quits: dimich_ (n=dimich@72.14.227.1) (Client Quit)
  724. # [23:47] * Quits: mlpug (n=mlpug@a88-115-161-57.elisa-laajakaista.fi) (Remote closed the connection)
  725. # [23:54] * Quits: Maurice (i=copyman@5ED548D4.cable.ziggo.nl) ("Disconnected...")
  726. # [23:56] * Joins: othermaciej (n=mjs@17.246.17.13)
  727. # Session Close: Sat Jun 27 00:00:00 2009

The end :)