/irc-logs / freenode / #whatwg / 2008-02-11 / end

Options:

  1. # Session Start: Mon Feb 11 00:00:00 2008
  2. # Session Ident: #whatwg
  3. # [00:00] <Hixie> that broke safari
  4. # [00:00] <annevk> bonus points
  5. # [00:00] <annevk> ;)
  6. # [00:01] * Joins: salty-horse (n=ori@pdpc/supporter/active/salty-horse)
  7. # [00:02] <salty-horse> this may be old news. graphviz over canvas: http://www.ryandesign.com/canviz/
  8. # [00:04] * Philip` hadn't seen that before
  9. # [00:04] <Philip`> Looks like it works well :-)
  10. # [00:05] <Philip`> Is it possible for someone to enter their own dot files?
  11. # [00:06] <salty-horse> I just saw this link on graphviz.org :)
  12. # [00:11] * Philip` fails to find any information about it other than https://mailman.research.att.com/pipermail/graphviz-interest/2007q3/004709.html
  13. # [00:13] <Hixie> Philip`: you've tested <canvas> the most, do you know if it's the case today that all <canvas> implementations create backing stores the same dimensions as the coordinate space?
  14. # [00:15] <salty-horse> Philip`, since the graphviz xdot output parsing is on the client-side, you already have all of the source code :)
  15. # [00:16] <Philip`> Hixie: I think WebKit might use a different scale if you some secret hidden OS X feature to change the UI scaling factor or something like that, but I've never tried that myself
  16. # [00:16] <Philip`> s/ / use /
  17. # [00:16] <Hixie> but other than that, they all just use the coordinate space?
  18. # [00:17] <Hixie> so if i have <canvas height=1 width=1> and canvas { height: 100%; width: 100%; } they all screw it up?
  19. # [00:17] <annevk> Firefox and Opera "do"
  20. # [00:18] <Philip`> The internal buffer is always independent of the size rendered on the screen
  21. # [00:18] <annevk> although in that case it's debatable what should happen as CSS stuff is just resizing after all the <canvas> stuff happened
  22. # [00:18] <Philip`> It wouldn't really make sense otherwise, given that you can change the rendered size easily
  23. # [00:18] <Hixie> i'm not saying the css stuff should control the buffer size
  24. # [00:18] <Philip`> (like by resizing the window if it's width:100%)
  25. # [00:18] <Hixie> i'm just asking if that would always make a 1x1 buffer
  26. # [00:19] <Philip`> I think in WebKit it would be (1*UI scaling factor)x(1*UI scaling factor), where UI scaling factor = 1 unless you're using developer tools to change it
  27. # [00:20] <Hixie> k
  28. # [00:20] <Philip`> (but I could be wrong :-) )
  29. # [00:20] <Hixie> that seems sad
  30. # [00:20] <roc> we're always 1:1
  31. # [00:20] <Philip`> Why?
  32. # [00:21] <roc> changing that would be pretty easy, but someone has to think about dynamic DPI changes
  33. # [00:21] <Philip`> s/^/Hixie: /
  34. # [00:22] <Hixie> Philip`: because it means that i can't pick a convenient coordinate space
  35. # [00:23] <Philip`> Not quite sure what you mean
  36. # [00:23] <Hixie> Philip`: i have to think about what my biggest likely rendering size (in terms of css pixels) will be
  37. # [00:23] <Hixie> instead of just saying "well i'll just work in the range 0..1"
  38. # [00:24] <Philip`> ctx.scale(canvas.width, canvas.height) would let you work in the range 0..1
  39. # [00:24] <Hixie> true
  40. # [00:25] <roc> Hixie: someone has to think about that. The browser can't really know.
  41. # [00:25] <Hixie> the browser could just use big abcking stores
  42. # [00:26] <roc> if it didn't care about performance
  43. # [00:26] <Hixie> right
  44. # [00:26] <roc> it turns out we do care about performance
  45. # [00:26] <Hixie> that's a tradeoff each browser vendor can make
  46. # [00:26] <annevk> if the author wants hires they should just use a huge <canvas>
  47. # [00:26] <annevk> imo
  48. # [00:26] <roc> it's useful to be able to get information from authors. Some authors care about performance too
  49. # [00:27] <annevk> and then scale using CSS
  50. # [00:27] <Philip`> Do any authors not care about performance?
  51. # [00:28] <Philip`> <canvas> is always going to be slow, because people want hi-res full-screen canvases with millions of pixels, so performance is unlikely to ever become irrelevant
  52. # [00:31] * Philip` likes to think of <canvas> as dynamic <img>, where you just say it's got w*h pixels and you can stick colour values in them, and tries not to think of <img src=x.svg> which breaks that model
  53. # [00:32] <Philip`> and anything more complex makes my head hurt
  54. # [00:39] * Joins: mpt (n=mpt@222-155-23-244.jetstream.xtra.co.nz)
  55. # [01:09] * Quits: jgraham (n=james@81-86-208-197.dsl.pipex.com) ("I get eaten by the worms")
  56. # [01:10] * Quits: mpt (n=mpt@222-155-23-244.jetstream.xtra.co.nz) ("Leaving")
  57. # [01:20] * Quits: salty-horse (n=ori@pdpc/supporter/active/salty-horse) ("Leaving")
  58. # [01:32] * Quits: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  59. # [01:33] * Joins: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  60. # [01:45] * Philip` notices that his text node coalescence thing totally breaks with foster parenting
  61. # [02:14] * Joins: jruderman_ (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  62. # [02:15] * Quits: webben (n=benh@82.152.229.45)
  63. # [02:19] * Quits: tndH (i=Rob@adsl-77-86-99-71.karoo.KCOM.COM) ("ChatZilla 0.9.80-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  64. # [02:21] <kig> img src=x.svg is a canvas with x.svg drawn onto it
  65. # [02:21] <kig> (ha ha)
  66. # [02:30] * Quits: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  67. # [02:34] * Joins: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  68. # [02:49] * Quits: jruderman_ (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  69. # [02:56] <Philip`> Oh, and now the foster parenting breaks my previous mechanism for splitting the generic CDATA algorithm to work on tokens one at a time
  70. # [02:57] * Philip` really doesn't like it :-(
  71. # [03:26] <Philip`> http://parsetree.validator.nu/?doc=http://philip.html5.org/misc/fostered-adoption-2.html
  72. # [03:26] <Philip`> html5lib and Validator.nu don't match Firefox or Safari for that
  73. # [03:28] <Philip`> (I don't know whether html5lib etc is implementing HTML5 non-buggily or not)
  74. # [03:28] * Philip` just wants to decide that the fostering thing is broken so he can not bother implementing it
  75. # [03:32] <dbaron> Hixie, do you still stand by https://bugzilla.mozilla.org/show_bug.cgi?id=54696#c13 ?
  76. # [03:32] <dbaron> Hixie, or do you think Mozilla's list-around-float behavior should just switch to match Safari and IE?
  77. # [03:32] <dbaron> Hixie, (I'd note that float-displace seems to have disappeared from all CSS drafts...)
  78. # [03:34] <SadEagle> dbaron: if you care: http://lists.kde.org/?l=kde-commits&m=119170968024486&w=2
  79. # [03:35] <SadEagle> IOW, at least some people rely on something like that.
  80. # [03:37] <SadEagle> Not sure it's the same thing, actually, but perhaps the testcase in http://bugs.kde.org/show_bug.cgi?id=150474#c2 will tell you something. (Could just be a similar-sounding bug, I don't know the rendering/CSS stuff)
  81. # [04:07] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) ("Leaving")
  82. # [04:36] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  83. # [04:55] * Joins: DxSadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com)
  84. # [04:57] * weinig is now known as weinig|foods
  85. # [05:08] * Quits: SadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com) (Read error: 110 (Connection timed out))
  86. # [05:19] <Hixie> dbaron: what do the other two browsers do?
  87. # [05:19] <dbaron> Hixie, other browsers make the bullets overlap the floats
  88. # [05:19] <dbaron> Hixie, the bullet is always displaced from the first line by border+padding
  89. # [05:19] <dbaron> Hixie, but the line isn't moved to compensate
  90. # [05:20] <Hixie> so the bullet are on the left of a left float?
  91. # [05:20] <dbaron> Hixie, (see also the three messages I just sent to www-style about float-displace)
  92. # [05:20] <dbaron> Hixie, no, they overlap a left float
  93. # [05:21] <Hixie> right but on which side though? left?
  94. # [05:21] <dbaron> they're a fixed distance (border + padding of the list item) from the right edge of the left float
  95. # [05:22] <dbaron> it's the formula you'd want if you also had float-displace indenting the line
  96. # [05:22] <Hixie> then i don't understand what you mean by "the line isn't moved to compensate"
  97. # [05:23] <dbaron> except float-displace isn't indenting the line, so the bullet overlaps the float
  98. # [05:23] <dbaron> Starting from the beginning, what other browsers do is position the bullet relative to the first line box of the block.
  99. # [05:23] <dbaron> or the place that said line box would start if there were one
  100. # [05:24] <dbaron> that line box is flush against the float
  101. # [05:24] * dbaron looks for a testcase
  102. # [05:24] <Hixie> i guess i don't understand how that differs from float-displace, given the right values of float-displace
  103. # [05:25] <dbaron> https://bugzilla.mozilla.org/attachment.cgi?id=302070
  104. # [05:25] <dbaron> it's like everybody's doing the right thing, except without setting float-displace:line on list items
  105. # [05:25] <dbaron> which means if we become consistent
  106. # [05:25] <dbaron> we'll never be able to change that default
  107. # [05:25] <dbaron> whereas now Mozilla is doing something that means float-displace:line would be a compromise between existing browsers
  108. # [05:26] <dbaron> so people could move to that default
  109. # [05:26] * myakura_ is now known as myakura
  110. # [05:27] <Hixie> i have to admit finding it difficult to really care :-)
  111. # [05:27] <Hixie> i think we should introduce float-displace and the other property
  112. # [05:27] <dbaron> well, float-displace as specced is rather broken
  113. # [05:27] <dbaron> but it's easily fixable
  114. # [05:27] <Hixie> but i've given up trying to make bert and fantasai see reason, so i'm not planning on trying to get any work done in the csswg any time soon
  115. # [05:28] <dbaron> ok, I guess I'll back out my patch
  116. # [05:28] <Hixie> what did your patch do?
  117. # [05:28] <dbaron> or most of it, anyway
  118. # [05:28] <dbaron> it made Mozilla match the behavior of other browsers
  119. # [05:28] <dbaron> where the bullets overlap the float
  120. # [05:28] <dbaron> but we don't move blocks
  121. # [05:30] <Hixie> isn't that one of the values of float-displace and company?
  122. # [05:30] <dbaron> moving blocks is, but it really sucks
  123. # [05:30] <dbaron> I think we want to get rid of it, except for things that introduce new BFCs
  124. # [05:30] <dbaron> where it would be the default
  125. # [05:31] <Hixie> so what's wrong with the behaviour of other browsers?
  126. # [05:31] <dbaron> bullets overlap floats
  127. # [05:31] <dbaron> pretty much any time they're next to floats
  128. # [05:38] <Hixie> hm
  129. # [05:38] <Hixie> that does suck
  130. # [05:38] <dbaron> So I don't think I have a good excuse for implementing float-displace this far after feature freeze.
  131. # [05:39] <dbaron> But I think I can leave most of what I fixed in.
  132. # [05:39] <Hixie> yeah
  133. # [05:44] * Quits: DxSadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com) ("(good night)")
  134. # [05:50] <dbaron> but still back out the change removing -moz-float-edge: margin-box from li
  135. # [05:50] * Quits: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  136. # [05:51] * Joins: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  137. # [06:04] * Joins: eseidel (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net)
  138. # [06:04] * Joins: eseidel_ (n=eseidel@72.14.224.1)
  139. # [06:06] * weinig|foods is now known as weinig
  140. # [06:17] * Joins: eseidel__ (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net)
  141. # [06:18] * Quits: eseidel (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  142. # [06:22] <dbaron> Hixie, actually, backing out doesn't yield as good behavior as I thought it did.
  143. # [06:22] <dbaron> Hixie, we had -moz-float-edge on the wrong element, essentially, so we overlapped the bullets too.
  144. # [06:22] <dbaron> Hixie, so we're probably stuck with it...
  145. # [06:23] <dbaron> Hixie, although I'd consider implementing float-displace and seeing what breaks
  146. # [06:26] * Quits: roc (n=roc@202.0.36.64)
  147. # [06:28] * Quits: eseidel_ (n=eseidel@72.14.224.1) (Read error: 110 (Connection timed out))
  148. # [06:32] * Quits: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca) ("http://www.csarven.ca/")
  149. # [06:36] * Joins: eseidel (n=eseidel@72.14.224.1)
  150. # [06:37] * Quits: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  151. # [06:47] * Joins: MikeSmith (n=MikeSmit@eM60-254-230-21.pool.emnet.ne.jp)
  152. # [06:47] * Joins: billyjack (n=MikeSmit@eM60-254-230-21.pool.emnet.ne.jp)
  153. # [06:47] * Quits: billyjack (n=MikeSmit@eM60-254-230-21.pool.emnet.ne.jp) (Read error: 104 (Connection reset by peer))
  154. # [06:49] * Quits: eseidel__ (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  155. # [06:49] * Joins: eseidel_ (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net)
  156. # [06:50] * Quits: eseidel (n=eseidel@72.14.224.1) (Read error: 104 (Connection reset by peer))
  157. # [06:55] <dbaron> Hixie, and I think bug 57882 was your fault, too :-P
  158. # [06:56] * Joins: MacDome (n=eric@68-240-185-41.area5.spcsdns.net)
  159. # [06:57] <MikeSmith> hendry - ping me when you are back on
  160. # [06:59] <Hixie> dbaron: oh?
  161. # [06:59] <dbaron> Hixie, moving -moz-float-edge from ul,ol to li in your html.css cleanup
  162. # [06:59] <dbaron> Hixie, when I wanted to back out, I was thinking our use of -moz-float-edge prevented bug 57882 and I had caused it
  163. # [06:59] <dbaron> Hixie, but we had it all along, so I think what I did is an improvement
  164. # [07:00] <dbaron> anyway, enough confusing myself for today.
  165. # [07:05] <Hixie> heh
  166. # [07:39] * Quits: heycam|sydney (n=cam@b4F38.static.pacific.net.au) ("bye")
  167. # [07:51] * Quits: MacDome (n=eric@68-240-185-41.area5.spcsdns.net)
  168. # [07:53] * Joins: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de)
  169. # [07:53] * Joins: jgraham (n=james@81-86-208-197.dsl.pipex.com)
  170. # [08:00] <Hixie> i have no idea how to find examples of what julian is saying doesn't happen
  171. # [08:04] * Joins: eseidel (n=eseidel@72.14.224.1)
  172. # [08:05] * Joins: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  173. # [08:06] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  174. # [08:19] * Joins: eseidel__ (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net)
  175. # [08:19] * Quits: eseidel_ (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  176. # [08:36] * Quits: eseidel (n=eseidel@72.14.224.1) (Read error: 110 (Connection timed out))
  177. # [08:42] * Joins: roc (n=roc@121-72-16-46.dsl.telstraclear.net)
  178. # [08:48] * Joins: weinig_ (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  179. # [08:53] * Joins: othermaciej (n=mjs@ip-217-204-142-41.easynet.co.uk)
  180. # [09:03] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  181. # [09:09] * weinig_ is now known as weinig|zZz
  182. # [09:29] * Joins: mpt (n=mpt@222-155-24-190.jetstream.xtra.co.nz)
  183. # [09:30] <Hixie> roc: yt?
  184. # [09:31] <roc> aye
  185. # [09:31] <Hixie> i'm looking at your application cache feedback, in particular your use case for a map application wanting to pick a tile that is known to be available locally as the starting point of a transition
  186. # [09:31] <Hixie> is this something you think we should resolve in v1 of the api?
  187. # [09:32] <Hixie> or something for the future?
  188. # [09:33] <roc> I don't have an opinion on that
  189. # [09:33] <roc> I know people have asked for it
  190. # [09:33] <roc> Google Maps people
  191. # [09:33] <roc> I don't know how to prioritize these things
  192. # [09:33] <Hixie> k
  193. # [09:36] * Quits: dbaron (n=dbaron@c-67-160-251-228.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  194. # [09:36] <Hixie> roc: let me know if you end up pressured to implement something for that use case and i'll bring it up, but for now i'm going to shunt that to v2.
  195. # [09:36] <Hixie> roc: i want to try and get the basic API nailed down first.
  196. # [09:37] <roc> sounds reasonable
  197. # [09:37] <roc> we did actually implement something
  198. # [09:37] <roc> should we take it out?
  199. # [09:37] <roc> http://mxr.mozilla.org/seamonkey/search?string=islocallyavailable
  200. # [09:38] * Hixie looks
  201. # [09:38] * Quits: eseidel__ (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net)
  202. # [09:39] <Hixie> lordy, nsGlobalWindow is trying to catch up to nsCSSFrameConstructor
  203. # [09:39] <roc> don't look there
  204. # [09:44] <Hixie> well, i would rename it mozIsLocallyAvailable
  205. # [09:45] <Hixie> in case we introduce it later with different semantics or something
  206. # [09:45] <Hixie> but no, don't remove it, it'd be good to find out how people use it
  207. # [09:45] <Hixie> implementation feedback is a great way to inform the spec
  208. # [09:46] <roc> ok
  209. # [09:47] * Quits: mpt (n=mpt@222-155-24-190.jetstream.xtra.co.nz) ("Leaving")
  210. # [09:47] <roc> you know we're actually shipping supposedly-HTML5-complaint offline-application support in FF3
  211. # [09:47] <Hixie> really? sweet
  212. # [09:48] <Hixie> is that implemented yet?
  213. # [09:48] <roc> yeah
  214. # [09:48] <roc> yeah it is
  215. # [09:48] <Hixie> wow, cool
  216. # [09:48] <Hixie> didn't hear any feedback from whoever implemented it, as far as i recall; i hope the spec was clear enough
  217. # [09:48] <roc> If you have a recent FF3 build, check out "Tools ... Clear Private Data"
  218. # [09:48] <Hixie> Offline Website Data?
  219. # [09:48] <Hixie> cool
  220. # [09:48] <roc> yeah
  221. # [09:49] <Hixie> i guess i should test it :-)
  222. # [09:49] <roc> that would be interesting :-)
  223. # [09:50] * roc is busy testing SVG filters :-(
  224. # [10:03] * Quits: myakura (n=myakura@p2098-ipbf4207marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  225. # [10:06] <Hixie> i've already found two bugs
  226. # [10:06] <Hixie> and i've only written five lines of code
  227. # [10:08] * Joins: hober (n=ted@unaffiliated/hober)
  228. # [10:08] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  229. # [10:09] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  230. # [10:14] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  231. # [10:23] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  232. # [10:26] * Joins: othermaciej_ (n=mjs@ip-217-204-142-41.easynet.co.uk)
  233. # [10:27] * Quits: othermaciej (n=mjs@ip-217-204-142-41.easynet.co.uk) (Read error: 104 (Connection reset by peer))
  234. # [10:33] <Hixie> http://www.hixie.ch/tests/adhoc/html/offline/
  235. # [10:33] <Hixie> firefox fails at least 003
  236. # [10:33] <Hixie> bed time now
  237. # [10:44] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) ("This computer has gone to sleep")
  238. # [10:46] <hsivonen> any opinion whether Validator.nu TLS cert handling should copy trusted certificates from e.g. Mozilla or just skip trust checking?
  239. # [10:47] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  240. # [10:48] * Joins: Camaban (n=adrianle@host81-133-60-253.in-addr.btopenworld.com)
  241. # [10:53] * Joins: ROBOd (n=robod@89.122.216.38)
  242. # [10:54] * MacDome is now known as MacDomeSleep
  243. # [10:56] * Joins: eseidel (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net)
  244. # [10:58] * Quits: MacDomeSleep (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  245. # [11:03] <Philip`> hsivonen: Maybe it would be useful if the validator trusted the intersection of what's trusted by each major browser, so it can tell you if some fraction of users will experience problems
  246. # [11:04] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 110 (Connection timed out))
  247. # [11:05] <Philip`> but I'd expect it really needs some way to validate pages that are behind untrusted certificates, because people might do that intentionally (and ask users to accept or install the certificate) and will still want to validate their pages
  248. # [11:06] <hsivonen> Philip`: yeah, given the current state of HttpClient, it is hard to have it both ways
  249. # [11:06] <hsivonen> Philip`: and having yet another checkbox would suck
  250. # [11:07] <hsivonen> I've tried to find a way to manage HttpClient cert trust on a per HttpClient instance or on a per request basis
  251. # [11:08] <hsivonen> but it seems that it can only be managed on a per-classloader basis, which is rather bad in case someone wants to run the validator servlet in a larger app server
  252. # [11:08] <hsivonen> Philip`: as for the intersection, I can see practical reasons to to the intersection thing
  253. # [11:10] <hsivonen> Philip`: I can also don't like the inherent problem of root trust-based trust management that blesses a relatively small number of gatekeepers who can extract money from anyone who wishes to do TLS in a user-friendly way
  254. # [11:13] * Joins: tndH_ (i=Rob@adsl-77-86-99-71.karoo.KCOM.COM)
  255. # [11:13] * tndH_ is now known as tndH
  256. # [11:13] * othermaciej_ is now known as othermaciej
  257. # [11:13] * Quits: othermaciej (n=mjs@ip-217-204-142-41.easynet.co.uk)
  258. # [11:27] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  259. # [11:31] <hsivonen> http://html5.validator.nu/?doc=https%3A%2F%2Flabs.mozilla.com%2Fforum%2F
  260. # [11:31] <hsivonen> validator.nu is now totally promiscuous when it comes to cert checking
  261. # [11:32] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("Leaving")
  262. # [11:32] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  263. # [11:38] <annevk> "On Sat, 13 Nov 2004, Henri Sivonen wrote:" heh
  264. # [11:38] <annevk> fortunately comments are not addressed in chronological order
  265. # [11:43] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.3 (IRC client for Emacs)")
  266. # [12:03] * Joins: heycam (n=cam@ppp232-187.static.internode.on.net)
  267. # [12:06] <hsivonen> hmm. the French Wikipedia says that its XHTML article is part of a series on programming languages...
  268. # [12:06] * Joins: webben (n=benh@nat/yahoo/x-80f668b70ae03e83)
  269. # [12:34] <annevk> so defaultChecked does change the checked state in browsers, but only if it was not changed before
  270. # [12:42] * Quits: jgraham (n=james@81-86-208-197.dsl.pipex.com) ("I get eaten by the worms")
  271. # [12:43] * Joins: myakura (n=myakura@p2098-ipbf4207marunouchi.tokyo.ocn.ne.jp)
  272. # [12:45] * Joins: jgraham (n=james@81-86-208-197.dsl.pipex.com)
  273. # [12:47] * Quits: MikeSmith (n=MikeSmit@eM60-254-230-21.pool.emnet.ne.jp) (Read error: 104 (Connection reset by peer))
  274. # [12:50] <annevk> oh, defaultChecked is actually more weird than that
  275. # [12:50] <annevk> :(
  276. # [12:52] <annevk> Firefox makes a distinction between setAttribute("checked", "checked") and defaultChecked
  277. # [12:57] * Quits: jgraham (n=james@81-86-208-197.dsl.pipex.com) ("I get eaten by the worms")
  278. # [12:59] * Joins: jgraham (n=james@81-86-208-197.dsl.pipex.com)
  279. # [13:00] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  280. # [13:02] <annevk> Hixie, either Acid3 should test a bunch of other things regarding defaultChecked so that we can extract a sane spec/impl out of it. If not it should simply avoid it so we won't be constrained further on
  281. # [13:04] <annevk> to the people doing dom5: kill hasFeature
  282. # [13:04] <annevk> (and friends)
  283. # [13:07] * Quits: heycam (n=cam@ppp232-187.static.internode.on.net) (Read error: 110 (Connection timed out))
  284. # [13:10] * Quits: webben (n=benh@nat/yahoo/x-80f668b70ae03e83) (Read error: 113 (No route to host))
  285. # [13:13] * Philip` begins to suspect that http://james.html5.org/cgi-bin/parsetree/parsetree.py?uri=http://philip.html5.org/misc/fostered-adoption-3.html is a bug in html5lib, because it should be impossible to append the p to the table element
  286. # [13:14] <hsivonen> Philip`: http://parsetree.validator.nu/?doc=http://philip.html5.org/misc/fostered-adoption-3.html
  287. # [13:15] <hsivonen> Philip`: looks like two independent implementations share the bug...
  288. # [13:16] <annevk> yaiks
  289. # [13:16] <annevk> Firefox does move the <p><b> thingie before <table>
  290. # [13:19] <annevk> probably time for revising the parser section
  291. # [13:46] <Philip`> annevk: I'm not sure the spec is wrong here
  292. # [13:48] <annevk> those two statements were not tightly related :)
  293. # [13:48] <annevk> sorry
  294. # [13:52] * Joins: MikeSmith (n=MikeSmit@EM117-55-23-224.pool.emnet.ne.jp)
  295. # [13:54] <Philip`> Ah, okay :-)
  296. # [14:02] * Quits: roc (n=roc@121-72-16-46.dsl.telstraclear.net)
  297. # [14:04] * Quits: myakura (n=myakura@p2098-ipbf4207marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  298. # [14:10] * Joins: webben (n=benh@nat/yahoo/x-2261a4b3a320223c)
  299. # [14:21] <Philip`> Oh, looks like html5lib/validator.nu are correct, and the spec is wrong
  300. # [14:22] <annevk> my main issue with spec changes at this point is fixing html5lib
  301. # [14:22] <annevk> i hope someone will add more parsing tests based on the updated spec and that we can then sort of figure out what needs to happen
  302. # [14:40] * Joins: phsiao (n=shawn@c-71-232-12-131.hsd1.ma.comcast.net)
  303. # [14:57] <Philip`> Hmm, Gmail's sponsored links aren't entirely appropriate when reading email about the foster parenting algorithm
  304. # [14:57] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  305. # [14:58] * Joins: aroben (n=aroben@c-69-248-233-130.hsd1.pa.comcast.net)
  306. # [14:58] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  307. # [15:13] <annevk> latest rumors: Y! to merge with AOL, Y! to form alliances with Google/Disney
  308. # [15:13] <hsivonen> Hixie: do you have feedback on text/html encoding sniffing from browser vendors? is the current spec language considered virtually final?
  309. # [15:15] * Joins: ROBOd (n=robod@89.122.216.38)
  310. # [15:17] <Philip`> Mozilla should buy Yahoo
  311. # [15:17] <annevk> heh, that'd be something
  312. # [15:18] <Philip`> using money secretly donated by Google
  313. # [15:18] <annevk> hsivonen, I doubt it had much review...
  314. # [15:18] <hsivonen> annevk: ok.
  315. # [15:18] <hsivonen> I won't implement it now then
  316. # [15:19] <hsivonen> I've already written one tentative implementation, so now it's someone else's turn :-)
  317. # [15:19] <hsivonen> "The attribute value must be serialised without the use of character entity references of any kind. " fun, fun, fun
  318. # [15:19] <hsivonen> go layering
  319. # [15:21] <annevk> that's actually pretty complex if you don't encounter it in the prescan
  320. # [15:21] <annevk> and since there's no longer a max bytes limit...
  321. # [15:22] <hsivonen> Hixie: why are entities prohibited if the algorithm now involves running the real tokenizer?
  322. # [15:23] <Philip`> http://james.html5.org/cgi-bin/parsetree/parsetree.py?source=<table><b><p></b> - hmm, EOF should cause an implied </p> which should get foster-parented which should result in one more parse error than is shown
  323. # [15:23] <hsivonen> } else if ("meta" == name) { // XXX do charset stuff
  324. # [15:23] <hsivonen> that explains why the parser wasn't doing what Sam Ruby suggested
  325. # [15:24] <hsivonen> although I though it already did...
  326. # [15:24] * Philip` wonders if it would be bad to commit evil tests to html5lib without offering to fix the code to pass them
  327. # [15:24] <annevk> yes
  328. # [15:25] <hsivonen> Philip`: I suggest putting evil tests to a separate test file
  329. # [15:25] <annevk> we still need to organize all those tests one day
  330. # [15:25] <annevk> but maybe we should wait for the spec to update itself first
  331. # [15:26] <gsnedders> the spec updates itself? oh,
  332. # [15:26] <gsnedders> I thought Hixie did the updating.
  333. # [15:26] <hsivonen> does the spec say anywhere that it is an error for HTTP charset and meta charset to disagree?
  334. # [15:26] <gsnedders> </bad_joke>
  335. # [15:28] <gsnedders> hsivonen: as far as I can see, no
  336. # [15:28] * Quits: wakaba (n=w@77.137.148.210.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  337. # [15:28] <hsivonen> gsnedders: ok
  338. # [15:28] * Joins: wakaba (n=w@77.137.148.210.dy.bbexcite.jp)
  339. # [15:38] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  340. # [15:43] <Philip`> Hmm, I assume that <table><td><a><table></table> shouldn't give a stack overflow
  341. # [15:44] <hsivonen> Philip`: does it somewhere?
  342. # [15:45] <Philip`> It does in my implementation
  343. # [15:46] <Philip`> Actually, that <a> is unnecessary
  344. # [15:48] * Parts: Camaban (n=adrianle@host81-133-60-253.in-addr.btopenworld.com)
  345. # [15:48] * Joins: Camaban (n=adrianle@host81-133-60-253.in-addr.btopenworld.com)
  346. # [15:49] <Philip`> Ah, it's just my ReprocessAsIf being broken if the insertion mode changes while reprocessing...
  347. # [16:00] <Philip`> ...which seems impossible to solve without adding even more state variables :-(
  348. # [16:16] * Joins: csarven (n=nevrasc@on-irc.csarven.ca)
  349. # [16:25] * Parts: zcorpan (n=zcorpan@pat.se.opera.com)
  350. # [16:25] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  351. # [16:25] * Quits: zcorpan (n=zcorpan@pat.se.opera.com) (Remote closed the connection)
  352. # [16:25] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  353. # [16:27] <annevk> http://en.wikipedia.org/wiki/Acid3
  354. # [16:37] <Lachy> wow, webkit has improved a lot in acid3 over the last few weeks
  355. # [16:39] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) ("Verlassend")
  356. # [16:41] <krijnh> Are there IE8 previews somewhere already? :)
  357. # [16:44] <alp> sigh, we still get data url parsing wrong :-(
  358. # [16:45] <gsnedders> alp: "we"?
  359. # [16:45] <alp> WebKit, GTK+ port
  360. # [16:47] <alp> is there a published algorithm? maybe that's going to work better than my interpretation of the RFC
  361. # [16:51] * Joins: billmason (n=billmaso@ip129.unival.com)
  362. # [16:51] * Quits: billmason (n=billmaso@ip129.unival.com) (Client Quit)
  363. # [16:52] * Quits: ray (i=ray@freenode/helper/ray) (Connection timed out)
  364. # [16:55] <Lachy> krijnh, not yet
  365. # [16:55] <krijnh> Bummer
  366. # [16:55] <Lachy> krijnh, the IE blog will most likely annonce it when there are
  367. # [16:56] <krijnh> Would be cool to see how it's doing now
  368. # [16:57] <hsivonen> hmm. Gecko and WebKit don't require http-equiv='content-type' to sniff charset
  369. # [16:57] <hsivonen> it seems that Opera 9.5 and IE7 do
  370. # [16:57] <hsivonen> http://browsershots.org/screenshots/63d26493fb4be33bb27db91ac31fd9a1/
  371. # [16:57] <hsivonen> yay for interop
  372. # [17:08] <alp> gsnedders: it turned out i was using a base64 decoder special-cased for window.atob(). using a generalised base64 decoder fixed acid3 test 97
  373. # [17:08] <gsnedders> ah.
  374. # [17:09] <alp> webkit's special-case b64 decoder needs a better name than base64Decode() clearly
  375. # [17:17] * Joins: SadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com)
  376. # [17:21] * gsnedders wonders if anyone who knows XPath is around
  377. # [17:26] <gsnedders> Is there anyway to find any comment node in the document with the content, "foobar"?
  378. # [17:27] <annevk> http://www.w3.org/TR/xpath
  379. # [17:27] <Philip`> I'd use grep
  380. # [17:28] <gsnedders> annevk: Reading the spec (actually, 2.0, not 1.0) makes me think no
  381. # [17:28] <gsnedders> Philip`: does that work on trees? :P
  382. # [17:28] <gsnedders> (i.e., I can't use grep)
  383. # [17:29] <Philip`> Serialise the tree then use grep
  384. # [17:29] <gsnedders> Philip`: I really don't want to be playing around with HTML with grep. HTML is too mad :)
  385. # [17:29] <annevk> something like //comment() plus something else might work
  386. # [17:30] <Philip`> Serialise the tree to XML then use grep
  387. # [17:30] <gsnedders> Philip`: too much serialising and parsing :)
  388. # [17:31] <gsnedders> annevk: seems to work in Safari (though that only claims to support 1.0), so I guess the Python impl I'm using is broken
  389. # [17:31] * gsnedders dives back into Python
  390. # [17:31] <Philip`> It sounds like you have determined the limit of "too much" totally arbitrarily just so you can reject my idea :'-(
  391. # [17:33] <gsnedders> Philip`: 2MB documents + Python = Slow enough all ready
  392. # [17:33] <gsnedders> Philip`: and seeming a stated aim of the spec-gen clone is to be quicker than the official one (which is written in Perl, sed, and C), parsing it too many times will make it too slow
  393. # [17:34] <gsnedders> (the real reason why the spec-gen is so slow is that it parses _loads_ of times)
  394. # [17:34] <annevk> from skimming the XPath spec it should be possible
  395. # [17:34] <gsnedders> annevk: that's what I think, too
  396. # [17:34] <gsnedders> I think I've just hit a bug in my very new Python impl
  397. # [17:34] <gsnedders> (well, not my impl, but the one I'm using)
  398. # [17:36] * Quits: grimboy (n=grimboy@78-105-162-250.zone3.bethere.co.uk) (Read error: 110 (Connection timed out))
  399. # [17:36] * Quits: phsiao (n=shawn@c-71-232-12-131.hsd1.ma.comcast.net)
  400. # [17:41] * Joins: hdh (n=hdh@118.71.75.182)
  401. # [17:46] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
  402. # [17:54] * Joins: phsiao (n=shawn@nat/ibm/x-3a13cc51d128f579)
  403. # [17:54] * Joins: cgriego (n=cgriego@216.138.69.206)
  404. # [18:02] * Quits: weinig|zZz (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  405. # [18:04] <Philip`> Hooray, more text issues
  406. # [18:05] <Philip`> html5lib says <!DOCTYPE HTML><frameset>test should only create one parse error for the text, but the spec unambiguously requires each character token to generate an individual parse error
  407. # [18:09] <jruderman> conclusion: "test" is a single character
  408. # [18:10] <SadEagle> or a single "character" token? :-)
  409. # [18:10] <Philip`> Perhaps it's a single Multicode character
  410. # [18:11] <Philip`> SadEagle: A single character token contains a single character
  411. # [18:11] <Philip`> (except in the reality of implementations)
  412. # [18:11] <hsivonen> Philip`: IIRC, Hixie said that in principle you should be able to treat runs of characters as units
  413. # [18:11] <hsivonen> Philip`: but the foster parenting stuff breaks that
  414. # [18:11] <hsivonen> what WebKit does is most sane IMO
  415. # [18:11] <hsivonen> what Gecko does seems unnecessarily complex
  416. # [18:12] <Philip`> Even without foster parenting, whitespace breaks that
  417. # [18:12] <hsivonen> Philip`: where?
  418. # [18:13] <hsivonen> (I'm assuming that the frameset case above isn't *really* mean to spew an error on each char separately)
  419. # [18:13] <annevk> hixie also mentioned that parse errors may be collapsed
  420. # [18:13] <annevk> no idea if that's reflected by the spec
  421. # [18:14] <hsivonen> Philip`: fwiw, the cases where html5lib and V.nu disagree on the exact # of tree construction errors, either one is just collapsing errors that would be guaranteed to fire together
  422. # [18:14] <hsivonen> Philip`: it didn't make sense to follow html5lib exactly, because IIRC, html5lib didn't follow the spec 100%, either
  423. # [18:14] <Philip`> With something like "<frameset> test" the spec says the whitespace and non-whitespace characters are handled through different paths, so you have to handle characters individually or split the text run up into whitespace and non-whitespace runs or think cleverly about how to make it work regardless
  424. # [18:15] <hsivonen> oh, right.
  425. # [18:15] <hsivonen> you can only coalesce runs of whitespace and runs of non-whitespace
  426. # [18:16] * Joins: hober (n=ted@unaffiliated/hober)
  427. # [18:16] <Philip`> It'd be inefficient to not coalesce combined whitespace-and-not characters in the common cases of big paragraphs of un-marked-up text
  428. # [18:16] <hsivonen> the trick case that shows WebKit vs. Gecko difference is when you have: <table>foo<!-- --> <!-- --> bar</table>, IIRC
  429. # [18:16] <hsivonen> Philip`: yeah
  430. # [18:17] <hsivonen> from the impl point of view I like what WebKit does: coalesce a run first and then check if it is all whitespace
  431. # [18:17] <hsivonen> which is why the crafter comment case tricks WebKit
  432. # [18:17] <hsivonen> crafted
  433. # [18:17] <Philip`> What if you want to do incremental display, and add Text nodes to the document before you've finished tokenising a run of characters?
  434. # [18:18] <hsivonen> Philip`: you'd assume that no single text run on normal pages is long enough without intervening markup to justify rendering a run of text incrementally
  435. # [18:18] <SadEagle> 1) how common is the case of a long run of characters w/o whitespace? 2) you can always update TextNodes, as long as you don't let JS run prematurely, anyway
  436. # [18:19] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  437. # [18:20] <Philip`> "<plaintext>5MB of text from Gutenberg"
  438. # [18:21] <SadEagle> that has whitespace, no?
  439. # [18:21] <gsnedders> SadEagle: that has no whitespace
  440. # [18:22] <Philip`> SadEagle: 2) The difficult is that you'd have to move the Text node from inside the table to outside, once you've discovered a non-whitespace character at the end
  441. # [18:22] <Dashiva> Maybe stating the definition would help the discussion :)
  442. # [18:23] <Philip`> SadEagle: 1) I'm assuming whitespace in the middle of a run of characters is coalesced with non-whitespace, because it seems inefficient otherwise
  443. # [18:23] * Quits: gsnedders (n=gsnedder@host86-151-228-75.range86-151.btcentralplus.com) ("Partying in teh intarwebs")
  444. # [18:23] <SadEagle> Philip`: ah, and you mean the rendering might "jump" due to the node movement?
  445. # [18:24] <Philip`> I mostly mean that the node movement is kind of complex and likely to include bugs :-)
  446. # [18:24] <SadEagle> what does the 5mb matter then? :-)
  447. # [18:25] <zcorpan> justify incremental rendering?
  448. # [18:26] <SadEagle> ah :-). Well, never mind me, I am dumb when 90% of my brain is dedicated to something else </lameexcuse>
  449. # [18:27] <Philip`> parse error: unmatched closing tag lameexcuse
  450. # [18:29] <Philip`> Grargh, I'm adopting children backwards
  451. # [18:59] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  452. # [19:08] * Parts: Camaban (n=adrianle@host81-133-60-253.in-addr.btopenworld.com)
  453. # [19:08] * Quits: hdh (n=hdh@118.71.75.182) (Remote closed the connection)
  454. # [19:10] * Quits: franksalim (n=franksal@cpe-72-130-134-143.san.res.rr.com)
  455. # [19:22] * Joins: grimboy (n=grimboy@78-105-162-250.zone3.bethere.co.uk)
  456. # [19:27] * Joins: gsnedders (n=gsnedder@host86-151-228-75.range86-151.btcentralplus.com)
  457. # [19:27] * Joins: parcelbrat (n=parcelbr@c-67-185-108-198.hsd1.wa.comcast.net)
  458. # [19:30] * Joins: psa (n=yomode@71.93.19.66)
  459. # [19:43] * Quits: parcelbrat (n=parcelbr@c-67-185-108-198.hsd1.wa.comcast.net)
  460. # [19:44] * Joins: weinig (n=weinig@17.203.15.140)
  461. # [19:58] * Joins: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  462. # [20:09] * Joins: moeffju (i=moeffju@ubermutant.net)
  463. # [20:10] * Quits: weinig (n=weinig@17.203.15.140) (Read error: 104 (Connection reset by peer))
  464. # [20:11] * Quits: MikeSmith (n=MikeSmit@EM117-55-23-224.pool.emnet.ne.jp) (Read error: 110 (Connection timed out))
  465. # [20:12] * Parts: moeffju (i=moeffju@ubermutant.net)
  466. # [20:16] * Joins: weinig (n=weinig@17.203.15.140)
  467. # [20:46] * Quits: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  468. # [20:49] * Quits: zcorpan (n=zcorpan@pat.se.opera.com) (Read error: 110 (Connection timed out))
  469. # [20:53] * Quits: eseidel (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net)
  470. # [20:54] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) ("Leaving")
  471. # [20:56] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  472. # [20:57] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Client Quit)
  473. # [20:59] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
  474. # [21:11] * Joins: virtuelv (n=virtuelv@65.80-202-82.nextgentel.com)
  475. # [21:13] * Joins: roc (n=roc@202.0.36.64)
  476. # [21:16] * Quits: webben (n=benh@nat/yahoo/x-2261a4b3a320223c) (Read error: 110 (Connection timed out))
  477. # [21:25] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  478. # [21:40] * Joins: webben (n=benh@82.152.229.45)
  479. # [21:43] * Quits: webben (n=benh@82.152.229.45) (Read error: 104 (Connection reset by peer))
  480. # [21:44] * Joins: webben (n=benh@82.152.229.45)
  481. # [21:55] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  482. # [22:04] <hsivonen> http://vesa.piittinen.name/doctype/
  483. # [22:13] * Joins: jruderman (n=jruderma@guest-228.mountainview.mozilla.com)
  484. # [22:19] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  485. # [22:19] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  486. # [22:22] <krijnh> Doesn't really work in Opera..
  487. # [22:24] <annevk> works in Opera 9.5 I think
  488. # [22:25] <annevk> string based apps and XML always go wrong: http://vesa.piittinen.name/doctype/?doctype=%3C%21DOCTYPE+html+PUBLIC+%22-%2F%2FWAPFORUM%2F%2FDTD+WML+2.0%2F%2FEN%22+%22http%3A%2F%2Fwww.wapforum.org%2FDTD%2Fwml20.dtd%22%3E&content-type=text%2Fxml
  489. # [22:26] <annevk> seems he never tested the XML stuff him/herself...
  490. # [22:26] <gsnedders> annevk: XML is easy. Don't you know? :)
  491. # [22:29] <annevk> better than you :p
  492. # [22:30] <gsnedders> Hey! My brain is a non-fatal XML parser! It's easy!
  493. # [22:33] <SadEagle> how well does it support external entities? :-)
  494. # [22:33] <gsnedders> SadEagle: it ignores them
  495. # [22:34] <gsnedders> (the built-in memory is too restrictive, as it would cause a segfault)
  496. # [22:36] * Joins: kingryan (n=ryan@dsl092-219-050.sfo1.dsl.speakeasy.net)
  497. # [22:40] * Joins: heycam (n=cam@ppp232-187.static.internode.on.net)
  498. # [22:41] <Dashiva> gsnedders: So it's non-validating?
  499. # [22:42] <gsnedders> Dashiva: totally.
  500. # [22:42] <gsnedders> Dashiva: it totally ignores all errors, so why bother using a validating parser? It just complicates matters by needing to get external entities!
  501. # [22:45] <Dashiva> Well, even if you ignore errors you might want to keep track of them, so you don't propagate them onto other, validating parsers ;)
  502. # [22:51] <zcorpan_> gsnedders: how about the internal subset?
  503. # [22:51] <gsnedders> zcorpan_: yeah, I parse that
  504. # [22:52] * zcorpan_ feeds the billion laughs attack to gsnedders' brain
  505. # [22:52] * gsnedders notes recursion (at any level) and throws a "too lazy" error
  506. # [22:53] * Philip` passes a U+2664 SPADE through gsnedders' head
  507. # [22:53] * gsnedders shrugs
  508. # [22:53] <Dashiva> Surely it would be better to use U+FDD0 before the joke gets too old
  509. # [22:54] * Quits: psa (n=yomode@71.93.19.66) (Remote closed the connection)
  510. # [22:55] <gsnedders> oh gwad/.
  511. # [22:55] <gsnedders> I actually looked that up.
  512. # [22:55] <gsnedders> I'm that willing to believe a comic!
  513. # [22:55] * Joins: psa (n=yomode@71.93.19.66)
  514. # [22:56] <gsnedders> brb
  515. # [22:56] * Quits: gsnedders (n=gsnedder@host86-151-228-75.range86-151.btcentralplus.com)
  516. # [22:58] * Quits: virtuelv (n=virtuelv@65.80-202-82.nextgentel.com) (Read error: 110 (Connection timed out))
  517. # [23:04] * Joins: jwalden (n=waldo@STRATTON-FOUR-O-EIGHT.MIT.EDU)
  518. # [23:04] * Joins: eseidel (n=eseidel@nat/google/x-f8f1b18068983d84)
  519. # [23:11] * Quits: heycam (n=cam@ppp232-187.static.internode.on.net) (Read error: 110 (Connection timed out))
  520. # [23:13] * Quits: cgriego (n=cgriego@216.138.69.206)
  521. # [23:17] * Quits: psa (n=yomode@71.93.19.66) (Remote closed the connection)
  522. # [23:24] * Joins: psa (n=yomode@71.93.19.66)
  523. # [23:28] * Quits: psa (n=yomode@71.93.19.66) (Remote closed the connection)
  524. # [23:30] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
  525. # [23:30] * Quits: jruderman (n=jruderma@guest-228.mountainview.mozilla.com)
  526. # [23:33] * Joins: psa (n=yomode@71.93.19.66)
  527. # [23:33] * Joins: heycam|sydney (n=cam@b4F38.static.pacific.net.au)
  528. # [23:38] * Joins: jruderman (n=jruderma@guest-228.mountainview.mozilla.com)
  529. # [23:40] * Quits: eseidel (n=eseidel@nat/google/x-f8f1b18068983d84)
  530. # [23:46] * Quits: phsiao (n=shawn@nat/ibm/x-3a13cc51d128f579)
  531. # [23:46] * Quits: psa (n=yomode@71.93.19.66) (Remote closed the connection)
  532. # [23:49] * Joins: gsnedders (n=gsnedder@host86-151-228-75.range86-151.btcentralplus.com)
  533. # [23:49] * Joins: psa (n=yomode@71.93.19.66)
  534. # [23:55] * Quits: psa (n=yomode@71.93.19.66) (Remote closed the connection)
  535. # [23:59] * Quits: roc (n=roc@202.0.36.64) (Remote closed the connection)
  536. # [23:59] <Hixie> hsivonen: the html5 spec requires that the content type declarations match the encoding used
  537. # Session Close: Tue Feb 12 00:00:00 2008

The end :)