/irc-logs / freenode / #whatwg / 2008-03-04 / end

Options:

  1. # Session Start: Tue Mar 04 00:00:00 2008
  2. # Session Ident: #whatwg
  3. # [00:04] * Quits: tndH (i=Rob@87.102.22.136) ("ChatZilla 0.9.81-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  4. # [00:09] * Quits: eseidel_ (n=eseidel@nat/google/x-02c327ef376cdca3)
  5. # [00:12] * Joins: eseidel_ (n=eseidel@nat/google/x-a5343905479b3a03)
  6. # [00:16] * Quits: eseidel (n=eseidelD@nat/google/x-5db16df1cca79100)
  7. # [00:19] * Quits: phsiao (n=shawn@nat/ibm/x-76cf993d9d447794) (Read error: 110 (Connection timed out))
  8. # [00:23] <jgraham> Hixie: In the outline algorithm, in the conditon "When exiting a sectioning content element, if the stack is not empty"
  9. # [00:23] <Hixie> yes?
  10. # [00:23] <jgraham> it's not clear to me what "Let current section be the last section in the outline of the current outlinee element.
  11. # [00:23] <jgraham> Insert its outline at the end of the current section. (This does not change which section is the last section in the outline.)" means
  12. # [00:24] <jgraham> Specifically the last line.
  13. # [00:24] <Hixie> oops
  14. # [00:24] <Hixie> "its" refers to the sectioning content element being exited
  15. # [00:24] <Hixie> let me fix that
  16. # [00:25] * Quits: billmason (n=billmaso@ip70.unival.com) (".")
  17. # [00:29] <Hixie> ok fixed
  18. # [00:29] <Hixie> is that clearer?
  19. # [00:33] <jgraham> I think that helps. I just need to work through and see if I have a sensible mental model of what's happening
  20. # [00:33] <Hixie> k
  21. # [00:33] <Hixie> i know you will, but, let me know what i can do to improve it
  22. # [00:34] <Hixie> the current algorithm should be way better than what was there before, yet get mostly the same results
  23. # [00:36] <annevk> Hixie, you're still going through parser feedback right?
  24. # [00:36] <Hixie> yes
  25. # [00:36] <Hixie> i'm stalled right now trying to figure out how to handle spaces in <table> x </table>
  26. # [00:37] <annevk> flip a coin :)
  27. # [00:38] <Hixie> between what and what? i have no options so far :-)
  28. # [00:38] <annevk> between " x <table></table>" and "x<table> </table>"
  29. # [00:38] <Philip`> annevk: Do you mean the algorithm for handling spaces should involve flipping a coin?
  30. # [00:39] <annevk> Philip`, that could be interesting, but requiring specific hardware for HTML 5 might be too much
  31. # [00:40] * jgraham suggests asking the user to decide
  32. # [00:41] <Philip`> annevk: Any implementation is acceptable as long as it acts the same as flipping a coin
  33. # [00:41] <Hixie> annevk: oh i've decided it's "x <table> </table>", the question is how to get there.
  34. # [00:41] <jgraham> "You have encountered a space inside a table. Would you like to move it outside (Y/n)"
  35. # [00:42] <Philip`> There should be a web service that provides a stream of random bits, called Flipr
  36. # [00:42] <Hixie> i'm thinking a flag on the table that decides whether spaces are sent out or not
  37. # [00:42] <Hixie> that gets set as soon as you send anything out
  38. # [00:42] <Hixie> the problem is nested tables in the innerHTML case makes this relatively hard to specify
  39. # [00:42] <annevk> so i think the current spec covers it
  40. # [00:42] <annevk> because you consume characters until the end
  41. # [00:42] <annevk> which makes "x " a character block
  42. # [00:43] <annevk> and the space before it gets treated specially
  43. # [00:43] <Hixie> the current spec has no concept of "character blocks" :-)
  44. # [00:43] <annevk> the append the character stuff
  45. # [00:43] <Hixie> but e.g. "<table> x<span></span> </table>" should become "x<span></span> <table> </table>"
  46. # [00:44] <Hixie> so it's not that simply
  47. # [00:44] <Hixie> simple
  48. # [00:44] <annevk> for real?
  49. # [00:44] * annevk didn't think that trailling space would be placed in front too
  50. # [00:45] <Hixie> "<table> foo<span></span> bar</table>" shouldn't display "foobar"
  51. # [00:45] <Hixie> it should display "foo bar"
  52. # [00:45] <Hixie> that's the bug :-)
  53. # [00:46] <annevk> a flag sounds easiest then, yes
  54. # [00:54] * Quits: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no) ("This computer has gone to sleep")
  55. # [00:55] * Quits: eseidel_ (n=eseidel@nat/google/x-a5343905479b3a03)
  56. # [00:57] <jgraham> Hixie: I think I'm still confused about what it means to insert a section "at the end of" another section. Do you mean "as the last child section of" the other section?
  57. # [00:58] <jgraham> (so if you have <body><section><h1>foo you end up with a section for the <section> as a child of the section for the <body>
  58. # [00:58] <Hixie> in "When entering a heading content element" i used the term "append it to /candidate section/"
  59. # [00:58] <Hixie> is that clearer?
  60. # [00:58] <annevk> sounds like appendChild()...
  61. # [01:00] <jgraham> Yeah, that bit is clearer.
  62. # [01:00] <Hixie> ok i'll use that terminology
  63. # [01:00] * Hixie regens
  64. # [01:03] * Parts: SadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com) ("Konversation terminated!")
  65. # [01:04] * Joins: eseidel (n=eseidel@nat/google/x-f11b040464606f9e)
  66. # [01:13] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  67. # [01:22] * Joins: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca)
  68. # [01:35] * Parts: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
  69. # [01:38] * Joins: kingryan (n=ryan@dsl092-002-056.sfo1.dsl.speakeasy.net)
  70. # [01:39] * Quits: kingryan (n=ryan@dsl092-002-056.sfo1.dsl.speakeasy.net) (Client Quit)
  71. # [01:39] * Joins: kingryan (n=ryan@dsl092-002-056.sfo1.dsl.speakeasy.net)
  72. # [01:59] * Quits: jgraham (n=james@81-86-215-67.dsl.pipex.com) ("I get eaten by the worms")
  73. # [01:59] * Quits: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com) (Read error: 110 (Connection timed out))
  74. # [02:02] * Joins: webben (n=benh@91.84.250.225)
  75. # [02:06] * Quits: eseidel (n=eseidel@nat/google/x-f11b040464606f9e)
  76. # [02:22] <Hixie> if anyone gets the reason behind the reference in the title of my latest blog, i'll be impressed
  77. # [02:26] <Hixie> hsivonen_: does validator.nu have a way to make it validate the page from the Referer field?
  78. # [02:27] <Hixie> hsivonen_: btw #presets in the "the pitch" section of your about page is a broken link
  79. # [02:33] * Joins: eseidel (n=eseidel@nat/google/x-757f827fe60ccd76)
  80. # [02:38] * Quits: kingryan (n=ryan@dsl092-002-056.sfo1.dsl.speakeasy.net)
  81. # [02:39] * Joins: kingryan (n=ryan@dsl092-002-056.sfo1.dsl.speakeasy.net)
  82. # [02:41] * Quits: kingryan (n=ryan@dsl092-002-056.sfo1.dsl.speakeasy.net) (Client Quit)
  83. # [02:53] <csarven> Hixie Does it have anything to do with http://www.whatwg.org/issues/data.html ? :)
  84. # [02:55] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  85. # [02:56] <Hixie> no
  86. # [03:06] * Quits: eseidel (n=eseidel@nat/google/x-757f827fe60ccd76)
  87. # [03:07] <csarven> BTW, that page is pretty slow in Firefox. Pretty smooth in Opera.
  88. # [03:07] <csarven> The mouse movement on canvas that is.
  89. # [03:07] <roc> Has everyone here read this already? "IE8 standards mode" will be the default "standards mode" http://blogs.msdn.com/ie/archive/2008/03/03/microsoft-s-interoperability-principles-and-ie8.aspx
  90. # [03:16] <Hixie> yeah, i even blogged about it
  91. # [03:16] <Hixie> great news
  92. # [03:19] <roc> sorry, I'm too slow
  93. # [03:19] <Hixie> :-)
  94. # [03:19] <Hixie> i didn't mean it that way :-)
  95. # [03:33] * mpt is disconcerted by a picture of Osama bin Laden next to the post about Acid 3
  96. # [03:33] <Hixie> uri?
  97. # [03:34] <mpt> http://www.flickr.com/photos/41089232@N00/114103905
  98. # [03:37] <Hixie> either flickr is down or my proxy is acting up
  99. # [03:38] <Hixie> wtf the web just died for me
  100. # [03:40] <Philip`> Didn't you hear about the scheduled maintenance tonight? The web has to be turned off for two hours while it's all upgraded
  101. # [03:40] <Hixie> wouldn't that be nice
  102. # [03:41] <Hixie> mpt: i don't see anything about acid3 on there? *confused*
  103. # [03:42] <mpt> Hixie, that was the photo "randomly selected from Flickr using Yahoo! Pipes based on the words in the latest Web log entry on this site"
  104. # [03:43] <Hixie> oh haha i didn't realise that was the image that had been selected
  105. # [03:43] <Hixie> wow that's funny
  106. # [03:45] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  107. # [03:45] * Joins: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  108. # [03:46] <Hixie> so...
  109. # [03:46] <Hixie> if we make <input type=hidden> stay in the table...
  110. # [03:46] <Hixie> what the heck should <table>x<input type=hidden></table> do
  111. # [03:46] * Hixie studies
  112. # [03:47] <jruderman> "This decision comes on the heels of a recent leak of a classified NSA National Security Assessment which ranked the Bush Administration itself as the #2 threat to U.S. national security interests."
  113. # [03:47] <jruderman> i hadn't heard about that
  114. # [03:48] <jruderman> Hixie: does html 5 parsing require that where tags go in the DOM depend on attribute values?
  115. # [03:48] <Hixie> it's about to start going down that slippery slope, yes
  116. # [03:48] <Hixie> bz and othermaciej have asked that <input type=hidden> be given special status in <table>
  117. # [03:49] <jruderman> hmm
  118. # [03:49] <Philip`> jruderman: [citation needed]
  119. # [03:49] <jruderman> https://bugzilla.mozilla.org/show_bug.cgi?id=327796#c5 makes me think that will be unpopular
  120. # [03:49] <jruderman> Philip`: hehe
  121. # [03:50] <othermaciej> I don't exactly love the idea of that rule but it seems to matter for compatibility
  122. # [03:50] <Hixie> jruderman: https://bugzilla.mozilla.org/show_bug.cgi?id=390565
  123. # [03:54] * Joins: ramsey (n=ramsey@pdpc/supporter/active/ramsey)
  124. # [03:55] * Quits: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  125. # [04:01] <dbaron> Hixie, where do bug reports in acid3 go?
  126. # [04:01] <Hixie> ian@hixie.ch or the wasp alias, if you can find it
  127. # [04:01] <Hixie> i think that's acid3@webstandards.org
  128. # [04:01] <Hixie> not sure
  129. # [04:01] <Hixie> but ian@hixie.ch is fine
  130. # [04:02] <Hixie> and i try to give quick turnaround, so if you don't get a reply within 12 hours, ping me :-)
  131. # [04:02] <othermaciej> dbaron: what bug did you find?
  132. # [04:03] <dbaron> othermaciej, I think test 42 has an incorrect selector
  133. # [04:03] <dbaron> Fx trunk should pass that test
  134. # [04:03] <dbaron> and it looks wrong by inspection
  135. # [04:03] <Hixie> what failure number do you get?
  136. # [04:03] <dbaron> although I didn't test the modificication
  137. # [04:03] <dbaron> Hixie, the very last failure
  138. # [04:04] <Hixie> 39?
  139. # [04:04] * Hixie looks
  140. # [04:04] <dbaron> no, "rule did not start matching after change"
  141. # [04:04] <Hixie> oh the one between 12 and 14? ok
  142. # [04:04] * Hixie looks at that instead :-)
  143. # [04:05] <dbaron> oh, I see, the test continues after that function
  144. # [04:05] <dbaron> I think "#div1 ~ div div + div > div" should be "#div1 ~ div + div div > div"
  145. # [04:07] <Hixie> after 310 is in the tree, you get this DOM:
  146. # [04:07] <Hixie> <body><div1/><div2/><div3><div31><div310/><div311><div3111/></div311></div31></div3></body>
  147. # [04:07] <dbaron> oh
  148. # [04:07] <dbaron> hrm
  149. # [04:08] <dbaron> ignore me
  150. # [04:08] <dbaron> for now, anyway
  151. # [04:08] <Hixie> and "#div1 ~ div div + div > div" should match 3111 the same way that "div1 ~ div3 div310 + div311 > div3111" does
  152. # [04:08] <Hixie> seems valid to me :-)
  153. # [04:09] <dbaron> yeah
  154. # [04:09] <dbaron> for some reason I forgot to process the insertBefore mentally even though I saw it
  155. # [04:09] <dbaron> no idea why we fail, though
  156. # [04:09] <dbaron> I guess I'll have to ask someone to write a testcase
  157. # [04:10] <Hixie> it's basically a dynamic variant of your greedy matching test from css1, extended to use the css3 combinators
  158. # [04:10] <dbaron> though maybe it's not too hard to extract just the relevant bits
  159. # [04:12] <Hixie> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%20div1%20~%20div3%20div310%20%2B%20div311%20%3E%20div3111%20%7B%20border%3A%20solid%3B%20%7D%20%3C%2Fstyle%3E%0A%3Cbody%3E%3Cdiv1%3E%3C%2Fdiv1%3E%3Cdiv2%3E%3C%2Fdiv2%3E%3Cdiv3%3E%3Cdiv31%3E%3Cdiv311%3E%3Cdiv3111%3E%3C%2Fdiv3111%3E%3C%2Fdiv311%3E%3C%2Fdiv31%3E%3C%2Fdiv3%3E%3C%2Fbody%3E%0A%3Cscript%3E%0Avar%20div31%20%3D%20document.getElementsByTagName('div31')%5B0%5D%3B%0Adiv
  160. # [04:13] <Hixie> if that got truncated, go to http://software.hixie.ch/utilities/js/live-dom-viewer/ and hit "download" then "permalink" to get the uri
  161. # [04:13] * Quits: inimino (n=inimino@c-75-70-128-190.hsd1.co.comcast.net) ("WeeChat 0.2.6")
  162. # [04:13] <Hixie> i think that's the same test
  163. # [04:13] <Hixie> and it works fine if you do the mutation manually
  164. # [04:14] <Hixie> so it must be a dynamic thing
  165. # [04:14] <dbaron> yeah, I see the bug
  166. # [04:14] <dbaron> it's a one-liner
  167. # [04:14] <Hixie> cool
  168. # [04:14] <dbaron> now I need to find an excuse to check it in
  169. # [04:14] <dbaron> If only this test had been easier to parse the results of I'd have used it before I checked in my fix for those bugs, and been able to get it in easily...
  170. # [04:15] * dbaron hates overly complex tests
  171. # [04:15] <Hixie> i tried to make the tests as self-contained as possible
  172. # [04:15] <Hixie> but really acid tests aren't meant to be processed directly by engineers
  173. # [04:15] <Hixie> when acid2 came out i made minimised tests for each bug that opera had in acid2
  174. # [04:16] <Hixie> i'd expect any qa team to do the same for any acid test
  175. # [04:16] * Quits: weinig (n=weinig@17.203.15.180)
  176. # [04:16] <dbaron> er, no, I don't see the bug
  177. # [04:18] <dbaron> I better leave splitting these bugs up to people who actually think they have enough time to do it, instead of rushing...
  178. # [04:19] <Hixie> i wouldn't recommend trying to do it this late in a release cycle anyway
  179. # [04:19] <Hixie> best to work on standards bugs at the start of a cycle
  180. # [04:20] * Joins: SadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com)
  181. # [04:21] <dbaron> yeah, except you always release these acid tests a few months before the end of our release cycles
  182. # [04:22] <dbaron> and then we ship a not-much-improved release and look stupid
  183. # [04:23] <Hixie> what would you like me to do? wait til all the browser vendors' release schedules line up?
  184. # [04:23] <Hixie> acid3 has been in production since last april, and mostly came to a head recently because of the IE acid2 announcement
  185. # [04:23] <Hixie> i recommend shorter release cycles, that way you never have a problem like this :-)
  186. # [04:24] * Joins: Thezilch (i=fuz007@cpe-76-171-110-73.socal.res.rr.com)
  187. # [04:25] <Hixie> in fact, i'd argue that this is the best time for you for an acid test to come out, as it means that as the test finally gets all the bugs shaken out of it, you'll be at the best possible time to start working on standards bugs again
  188. # [04:25] <Hixie> (i.e. it'll be stable just as your release cycle starts)
  189. # [04:25] <dbaron> yeah, I've been pushing for shorter release cycles
  190. # [04:26] <dbaron> We may well do one.
  191. # [04:26] <dbaron> dare I ask where the function expect is defined?
  192. # [04:27] <Hixie> for which test?
  193. # [04:27] <dbaron> er, never mind
  194. # [04:28] <dbaron> The closures confused me about what was calling what
  195. # [04:28] <dbaron> I'm just annoyed about this particular test because I thought I fixed all the bugs that would have caused it to fail.
  196. # [04:28] <Hixie> heh
  197. # [04:37] <dbaron> ah, it's a matching bug, not a dynamic change handling bug
  198. # [04:43] <othermaciej> the next Safari release won't look so good on Acid3
  199. # [04:43] <othermaciej> not as good as current nightlies
  200. # [04:47] <Hixie> dbaron: really? it only seems to occur with a dynamic change.
  201. # [04:48] <dbaron> Hixie, not sure why you think that -- I tried removing and reinserting the body and the bug was still present
  202. # [04:48] <dbaron> Hixie, simple testcase in https://bugzilla.mozilla.org/show_bug.cgi?id=420814
  203. # [04:49] <Hixie> odd, i couldn't get the test to fail without dynamic changes
  204. # [04:49] <Hixie> oh well
  205. # [04:49] <Hixie> oh i guess i didn't have elements named the same thing in my version of the test
  206. # [04:49] <Hixie> so maybe there are two bugs here
  207. # [04:50] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  208. # [04:50] * Quits: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca) ("http://www.csarven.ca/")
  209. # [04:55] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Read error: 110 (Connection timed out))
  210. # [04:57] * Joins: franksalim (n=franksal@cpe-72-130-134-143.san.res.rr.com)
  211. # [05:05] * Joins: heycam (n=cam@124-168-103-84.dyn.iinet.net.au)
  212. # [05:28] * Quits: franksalim (n=franksal@cpe-72-130-134-143.san.res.rr.com)
  213. # [05:53] * Quits: roc (n=roc@202.0.36.64)
  214. # [06:15] * Joins: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  215. # [06:15] * Quits: gavin (n=gavin@firefox/developer/gavin) (kornbluth.freenode.net irc.freenode.net)
  216. # [06:20] * Joins: gavin (n=gavin@firefox/developer/gavin)
  217. # [06:40] * Quits: SadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com) ("Konversation terminated!")
  218. # [06:52] * Quits: jruderman (n=jruderma@guest-228.mountainview.mozilla.com)
  219. # [06:55] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  220. # [06:56] * Joins: inimino (n=inimino@c-75-70-128-190.hsd1.co.comcast.net)
  221. # [06:56] * Joins: SadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com)
  222. # [07:20] * Joins: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  223. # [07:24] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  224. # [07:40] * Joins: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de)
  225. # [07:59] * Joins: jgraham (n=james@81-86-215-67.dsl.pipex.com)
  226. # [08:01] * Quits: jgraham (n=james@81-86-215-67.dsl.pipex.com) (Client Quit)
  227. # [08:09] * Joins: madmoose (i=madmoose@chef.nerp.net)
  228. # [08:10] <Hixie> if this upcoming change doesn't break something, i'll be impressed
  229. # [08:22] * Joins: webben_ (n=benh@nat/yahoo/x-c90ad205e6789235)
  230. # [08:23] * Quits: SadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com) (Remote closed the connection)
  231. # [08:31] <Hixie> so anyone got any hot ideas on how to handle <table><td>x</td> <select><option>a<option>b <td>y</td> in a compatible way?
  232. # [08:31] <Hixie> Philip`?
  233. # [08:38] * Quits: webben (n=benh@91.84.250.225) (Read error: 110 (Connection timed out))
  234. # [08:39] * Joins: roc (n=roc@121.72.160.41)
  235. # [08:56] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
  236. # [08:56] * Quits: MikeSmith (n=MikeSmit@58.157.21.205) (Remote closed the connection)
  237. # [08:56] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  238. # [09:06] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  239. # [09:15] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Read error: 110 (Connection timed out))
  240. # [09:16] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  241. # [09:26] * Joins: tndH_ (n=Rob@87.102.22.136)
  242. # [09:26] * tndH_ is now known as tndH
  243. # [09:29] <hsivonen_> annevk: regarding "UA-specific crap" on the tracker: I'm using the annotations.
  244. # [09:34] <hsivonen_> I think the "ordered" is a red herring when it comes to <ol> and <ul>. It really is about showing the counters. A bulleted list can still have a deliberate order.
  245. # [09:42] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  246. # [09:43] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  247. # [09:44] * weinig is now known as weinig|away
  248. # [09:51] <othermaciej> hsivonen_: don't let tantek hear you say that
  249. # [09:53] <hsivonen_> heh
  250. # [09:59] <virtuelv> I haven't read it thoroughly yet, but did Microsoft just turn completely around on the x-ua-compatible stuff?
  251. # [10:02] <Philip`> virtuelv: Not completely - just on the default
  252. # [10:02] <virtuelv> :/
  253. # [10:03] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Read error: 110 (Connection timed out))
  254. # [10:03] <Philip`> (which is the part people were most complaining about)
  255. # [10:05] * hsivonen_ sees the Osama image at http://ln.hixie.ch/?start=1066145333&count=1
  256. # [10:08] <virtuelv> hsivonen_: :D :D :D
  257. # [10:09] <virtuelv> the image is based on Hixie's last entry, so you'll see it on all pages
  258. # [10:20] * Joins: virtuelv_ (n=virtuelv@213.236.208.247)
  259. # [10:20] <Lachy> wow!!!! "We’ve decided that IE8 will, by default, interpret web content in the most standards compliant way it can."
  260. # [10:20] <Lachy> http://blogs.msdn.com/ie/archive/2008/03/03/microsoft-s-interoperability-principles-and-ie8.aspx
  261. # [10:22] <zcorpan> Lachy: yes, very good news
  262. # [10:25] <zcorpan> Hixie: dammit, you're working too fast. i can't keep up :P
  263. # [10:26] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Read error: 104 (Connection reset by peer))
  264. # [10:27] * Joins: webben (n=benh@91.84.250.225)
  265. # [10:29] * Quits: webben (n=benh@91.84.250.225) (Client Quit)
  266. # [10:30] <Hixie> zcorpan: :-D
  267. # [10:31] <Hixie> i guess i'll have to have a "last insertion mode" variable to do the <table><select><td> thing
  268. # [10:31] <Hixie> anyway bed time
  269. # [10:33] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) ("This computer has gone to sleep")
  270. # [10:33] <zcorpan> aha! the precedent is set for looking at attribute values in the tree builder
  271. # [10:35] <hsivonen_> scary
  272. # [10:35] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  273. # [10:35] <hsivonen_> ah. it's type=hidden
  274. # [10:36] * Joins: Camaban (n=adrianle@host81-133-60-253.in-addr.btopenworld.com)
  275. # [10:36] <hsivonen_> that's good
  276. # [10:36] <zcorpan> why is it good?
  277. # [10:36] * Joins: ROBOd (n=robod@89.122.216.38)
  278. # [10:39] <hsivonen_> zcorpan: compat. and in the case of input, the conceptual reality is that the type attribute creates practically separate element types
  279. # [10:39] <zcorpan> hsivonen_: ok. and yep
  280. # [10:43] * Quits: virtuelv_ (n=virtuelv@213.236.208.247) (Read error: 110 (Connection timed out))
  281. # [10:44] * Quits: webben_ (n=benh@nat/yahoo/x-c90ad205e6789235) (Read error: 110 (Connection timed out))
  282. # [10:50] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  283. # [10:52] * Joins: annevk2 (n=annevk@77.163.243.203)
  284. # [10:53] * Quits: annevk (n=annevk@77.163.243.203) (Connection reset by peer)
  285. # [11:01] <Philip`> Hixie: Maybe handle it by copying what WebKit or Gecko does?
  286. # [11:01] <Philip`> I don't really know what they do, though
  287. # [11:02] <Philip`> (except I vaguely remember WebKit running the normal parsing sequence but with an 'is being inserted into table' flag that changes the processing of table elements)
  288. # [11:05] * Joins: webben (n=benh@dip5-fw.corp.ukl.yahoo.com)
  289. # [11:07] <annevk2> '<p>Ignore the token.</p> <!-- :-( -->' :)
  290. # [11:10] * Joins: MikeSmith (n=MikeSmit@58.157.21.205)
  291. # [11:17] * Quits: Thezilch (i=fuz007@cpe-76-171-110-73.socal.res.rr.com) (Read error: 104 (Connection reset by peer))
  292. # [11:21] * Quits: Camaban (n=adrianle@host81-133-60-253.in-addr.btopenworld.com) (Read error: 104 (Connection reset by peer))
  293. # [11:25] * Joins: Camaban (n=adrianle@host81-133-60-253.in-addr.btopenworld.com)
  294. # [11:26] * Parts: Camaban (n=adrianle@host81-133-60-253.in-addr.btopenworld.com)
  295. # [11:31] * Joins: Camaban (n=adrianle@host81-133-60-253.in-addr.btopenworld.com)
  296. # [11:34] * annevk2 is now known as annevk
  297. # [11:57] <Hixie> Philip`: it's not that simple; <table><tr><select><tbody> has to do different things than <table><select><tbody>
  298. # [11:58] <annevk> are we now figuring out the parser architecture is not good enough?
  299. # [11:58] * annevk hopes not
  300. # [11:58] <Hixie> no, it can be hacked to do this in various ways
  301. # [11:58] <Hixie> i'm just trying to work out which way
  302. # [11:58] <Hixie> i can remember the last mode and treat <select> specially "in table"
  303. # [11:59] <Hixie> and have a bunch of new states "in select"
  304. # [11:59] <Hixie> i can just have a bunch of new states "in select" with those states doing non-trivial examination of the stack
  305. # [11:59] <Hixie> i can have one "in select" state per table state
  306. # [11:59] <Hixie> ("in select in table row", etc)
  307. # [12:00] <annevk> if the last one is not more verbose than the others i might prefer it
  308. # [12:00] <Hixie> i'm leaning towards the seoond of those so far
  309. # [12:00] <Hixie> the last one is massively more verbose
  310. # [12:00] <annevk> k
  311. # [12:02] * Quits: Yudai (n=Yudai@p9258c3.kngwnt01.ap.so-net.ne.jp) ("SIGTERM received; exit")
  312. # [12:03] * Joins: Yudai (n=Yudai@p9258c3.kngwnt01.ap.so-net.ne.jp)
  313. # [12:09] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Leaving")
  314. # [12:14] * Joins: myakura (n=myakura@p1215-ipbf3008marunouchi.tokyo.ocn.ne.jp)
  315. # [12:16] <Hixie> christ, acid3 just hit something with a lot of readers
  316. # [12:19] <Hixie> http://www.neowin.net/forum/index.php?showtopic=623574
  317. # [12:22] <annevk> I wonder if everytime MS makes some kind of Web standards announcement there will be another significant announcement related to Web standards on the same day...
  318. # [12:28] <Hixie> heh
  319. # [12:31] <zcorpan> what was announced at the same time as the ie8 versioning switch thing (first time around)? the acid3 competition?
  320. # [12:31] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  321. # [12:33] <annevk> zcorpan, HTML5
  322. # [12:33] <annevk> (it was published as FPWD)
  323. # [12:34] <takkaria> how strange, Ff3b3 got 60/100 the first time I ran it and 59 the next
  324. # [12:35] <takkaria> though it's Fx now, I live in the past
  325. # [12:35] <zcorpan> annevk: ah, right
  326. # [12:35] <Hixie> sure getting a lot of hits from http://pro.tweakers.net/nieuws/52227/web-standards-project-geeft-acid3-test-vrij.html
  327. # [12:36] <annevk> tweakers.net is pretty huge yeah
  328. # [12:39] <annevk> http://browsershots.org/http://acid3.acidtests.org/ is nice
  329. # [12:40] * Joins: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
  330. # [12:41] <takkaria> heh, poor old MSIE4
  331. # [12:42] <Hixie> i hear NS4 crashes
  332. # [12:42] <annevk> how unexpected :)
  333. # [12:42] <annevk> it's funny how many people wonder how the reference rendering was made
  334. # [12:43] <zcorpan> obviously Hixie made a superbrowser that perfectly implements html5 and css2.1 to create the reference rendering
  335. # [12:43] <annevk> it's not like anything else would make sense
  336. # [12:44] * Quits: roc (n=roc@121.72.160.41)
  337. # [12:45] * Joins: Camaban_ (n=adrianle@host81-135-169-203.in-addr.btopenworld.com)
  338. # [12:45] * Quits: Camaban (n=adrianle@host81-133-60-253.in-addr.btopenworld.com) (Nick collision from services.)
  339. # [12:45] * Camaban_ is now known as Camaban
  340. # [12:46] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  341. # [12:59] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
  342. # [13:23] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  343. # [13:31] <Philip`> Hixie: Could you have a generic "in select in <var>T</var>" and then say "process the token as if the insertion mode was 'in select in <var>table row</var>' etc? Then then text wouldn't be verbose, and it would be clear that you can implement it as lots of states instead of needing another variable to remember where you were
  344. # [13:31] <Philip`> s/' /'" /
  345. # [13:32] <Philip`> (I don't like variables, because it makes it hard to work out what's going on)
  346. # [13:53] <Philip`> It's a little odd how everyone seems to be congratulating/thanking Microsoft for deciding to make IE8 act like how everyone used to take for granted it was going to act
  347. # [13:58] <zcorpan> it's not uncommon to be thankful when someone decides against doing something bad even if you didn't expect the bad thing being planned from the beginning
  348. # [13:59] <zcorpan> but the questions on how the rendering engines interact across frames still remain
  349. # [13:59] <zcorpan> and security or crash fixes to the old engine
  350. # [14:01] <Philip`> They would have to do security fixes to IE6 and IE7 and IE8, regardless of the modes within each browser release, so I'd guess they will share code between IE7 and IE8's IE7-compatibility mode, so it's no more work than they'd need anyway
  351. # [14:14] <Philip`> Hixie: Is http://www.whatwg.org/specs/web-apps/current-work/multipage/section-parsing.html#determining broken, like where it says "2. Otherwise, return to step 2 in these inner steps." that seems to be an infinite loop?
  352. # [14:14] <Philip`> and the "two step" algorithm goes up to step 5
  353. # [14:29] <Philip`> hsivonen_: Does your MetaSniffer code accurately / partially / not at all match the current spec?
  354. # [14:53] <hsivonen_> Philip`: it matches the spec as of June 2007
  355. # [15:07] * Joins: aroben (n=aroben@unaffiliated/aroben)
  356. # [15:10] * Joins: myakura_ (n=myakura@p1215-ipbf3008marunouchi.tokyo.ocn.ne.jp)
  357. # [15:16] <Philip`> http://www.modellbausieghard.de/ - <meta http-equiv="content-style-type" content="text/css; charset=iso-8859-1" /> - the meta charset detection thing will get misled by that
  358. # [15:18] <Philip`> About 60% of sniffable charsets can be sniffed from the first 256 bytes, 85% from 512 bytes, 93% from 1024 bytes
  359. # [15:21] <Philip`> http://groups.msn.com/GraftonRifleClub/ sends "Content-Type: text/html; charset=utf-8;" which HTML5 thinks is a charset named "utf-8;"
  360. # [15:23] <annevk> what does HTML5 do with Content-Type:text/html;foo=bar;charset=utf-8;foo=bar; ?
  361. # [15:23] <Philip`> http://www.whatwg.org/specs/web-apps/current-work/multipage/section-content-type-sniffing.html#algorithm3 - it returns nothing if the first parameter is not charset
  362. # [15:25] <Philip`> I don't see any pages sending anything quite like that, but there's one group with "text/html;ISO-8859-1; charset=UTF-8"
  363. # [15:25] * Quits: myakura (n=myakura@p1215-ipbf3008marunouchi.tokyo.ocn.ne.jp) (Read error: 110 (Connection timed out))
  364. # [15:26] <Philip`> (and one page with "text/html;image/gif;image/jpeg; Charset=iso-8859-1;text/javascript")
  365. # [15:27] <Philip`> (That one page is only half the number that use apostrophes)
  366. # [15:27] <Philip`> (and only 21 use double-quotes)
  367. # [15:27] <Philip`> (around the charset string)
  368. # [15:28] <zcorpan> in emails, the charset parameter is often not the first one
  369. # [15:29] <zcorpan> and it would be nice if the same code could be used for parsing content-type for emails and for content-type of resources in a browsing context
  370. # [15:31] <annevk> heh, Hixie used a dotted line in http://www.whatwg.org/issues/data.html
  371. # [15:31] <Philip`> It would be nice if it parsed valid HTTP headers correctly when there's no reason not to
  372. # [15:32] <Philip`> Hixie: Is it a bug in your code that http://www.whatwg.org/issues/data.html gets the mouse position wrong if you scroll down the page, or is that Firefox's fault?
  373. # [15:33] <annevk> fault of the script
  374. # [15:33] <annevk> it should use pageX/Y instead of clientX/Y
  375. # [15:35] <annevk> or alternatively it could use getBoundingClientRect().top and getBoundingClientRect().left instead of offsetTop and offsetLeft
  376. # [15:36] * Philip` finishes processing his pages, and find's it more like 57% getting sniffed in the first 256 bytes, 82% in 512, 92% in 1024
  377. # [15:39] <Philip`> Does HTML5 say that if the server sends HTTP charset=utf-16, it should be ignored?
  378. # [15:40] <Philip`> Oops, I don't mean that
  379. # [15:40] <Philip`> I was looking at the meta charset thing, which does say that...
  380. # [15:42] <Philip`> http://www.vorem.com - "Content-Type: text/html; charset=UTF-32"
  381. # [15:42] * Joins: phsiao (n=shawn@c-71-232-12-131.hsd1.ma.comcast.net)
  382. # [15:42] <annevk> shit
  383. # [15:43] <annevk> i hoped utf-32 could be dropped
  384. # [15:43] <Philip`> The page is actually iso-8859-15
  385. # [15:44] <Philip`> (or something close to that)
  386. # [15:44] <Philip`> The top unknown charsets are "", "none", "x-windows-874" and "iso-8559-1"
  387. # [15:44] <annevk> that makes it nice
  388. # [15:45] * Philip` wonders who was trying to make a page with no character set
  389. # [15:47] <annevk> oh I see
  390. # [15:47] <Philip`> Oh, looks like it's probably Apache users with "AddDefaultCharset none" instead of "AddDefaultCharset Off"
  391. # [15:47] <annevk> vorem.com has two Content-Type headers
  392. # [15:47] <Philip`> I only see one...
  393. # [15:48] <annevk> never mind
  394. # [15:48] <annevk> GET -ed is not trustworthy
  395. # [15:48] <annevk> i should remember that
  396. # [15:49] <Philip`> Ah, that's probably the LWP module doing fancy automatic meta-http-equiv extraction
  397. # [15:49] * Philip` uses 'HEAD http://www.vorem.com' instead
  398. # [15:51] <annevk> why does Firefox 3 not show it as UTF-32?
  399. # [15:52] <Philip`> Does FF3 support utf-32?
  400. # [15:53] <annevk> the encoding meny claims it does
  401. # [15:53] <annevk> but maybe it's not enabled for Web content
  402. # [15:57] <Philip`> http://www.liniehoeve.nl/ - <meta name="Title" charset="Beagle Kennel van der Liniehoeve"> - ?
  403. # [15:57] <Philip`> I'm not sure how they managed to mix up 'charset' and 'content'
  404. # [15:58] <annevk> heh
  405. # [16:03] <zcorpan> so vorem.com is an example of where it would be better to not support utf-32
  406. # [16:03] <zcorpan> that's interesting
  407. # [16:05] <Philip`> http://www.rotondadepacifico.com/ has <META http-equiv="Content-Type" content="text/html; charset=UTF-32">
  408. # [16:05] <Philip`> Those are the only two I've found that claim to use UTF-32
  409. # [16:05] <Philip`> (There's also two claiming to use UTF-9)
  410. # [16:06] <Philip`> (and also one ISO-10646-UTF-1 which actually seems to be a real encoding)
  411. # [16:13] <zcorpan> that uses a window-1252 copyright sign, so utf-32 doesn't need to be an alias for utf-8 like utf-16 is when found in <meta charset>
  412. # [16:14] <annevk> just needs to be ignored
  413. # [16:14] <Philip`> It's hard to make good decisions about how to handle UTF-32 pages based on a sample size of one :-)
  414. # [16:15] <Philip`> s/one/about two/
  415. # [16:15] <zcorpan> indeed :)
  416. # [16:16] <virtuelv> is the feed for http://reddit.com/r/browsers/ something that should/could go on planet html5?
  417. # [16:17] <virtuelv> (that's also a general request to post HTML5-related contents that doesn't go on the planet there)
  418. # [16:22] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Leaving")
  419. # [16:28] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  420. # [16:39] <annevk> http://www.unicode.org/Public/MAPPINGS/ is interesting
  421. # [16:39] <annevk> virtuelv, talk to MikeSmith
  422. # [16:40] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) ("Verlassend")
  423. # [16:40] <MikeSmith> annevk, virtuelv - I can go ahead and add it
  424. # [16:42] <annevk> virtuelv, btw, planet HTML5 does do a content substring so not all entries would show up
  425. # [16:44] <virtuelv> annevk: I'd guess tagging entries with "HTML5" should suffice?
  426. # [16:44] <virtuelv> fwiw, everyone is free to post there
  427. # [16:44] <virtuelv> I just think it's a good place to catch what doesn't get caught by the planet
  428. # [16:47] <virtuelv> btw, I think the filtering on planet html5 may be a bit strict
  429. # [16:47] <virtuelv> for instance, it totally missed MS' announcment
  430. # [16:48] <annevk> how is that HTML5 news?
  431. # [16:48] <virtuelv> hm, you might be right
  432. # [16:49] <virtuelv> I guess I just think the planet is a bit unpopulated
  433. # [16:50] <annevk> true, but html5 is not exactly daily news
  434. # [16:50] <annevk> well, except in this channel :)
  435. # [16:54] <MikeSmith> virtuelv - I added it
  436. # [16:54] <MikeSmith> btw, filtering on Planet HTML5 is very simple
  437. # [16:55] <MikeSmith> it looks for the strings "HTML5" or "HTML 5" anywhere in the content of feed item
  438. # [16:55] <virtuelv> MikeSmith: notede
  439. # [16:55] <virtuelv> -e
  440. # [16:55] <MikeSmith> so I guess the MS announcement didn't mention HTML5 at all
  441. # [16:55] <virtuelv> it didn't
  442. # [16:57] <zcorpan> MikeSmith: what about "HTML&nbsp;5"?
  443. # [16:57] * Quits: myakura_ (n=myakura@p1215-ipbf3008marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  444. # [16:58] <zcorpan> <abbr>HTML</abbr> 5
  445. # [16:58] <Philip`> HTML<ins> </ins>5
  446. # [16:58] <MikeSmith> any blog posting that does <abbr>HTML</abbr> will be summarily rejected
  447. # [16:59] <zcorpan> so much for semantics ;)
  448. # [17:00] <Philip`> abbr/acronym are fatally flawed since they can't represent recursive acronyms
  449. # [17:01] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
  450. # [17:02] * Joins: dveditz (n=dveditz@dsl-63-249-104-137.cruzio.com)
  451. # [17:04] <Philip`> We need <abbr name="gnu">GNU</abbr> (<expansion for="gnu"><abbr name="gnu">GNU</abbr>'s not <abbr name="unix">UNIX</abbr></expansion>) ...
  452. # [17:06] <zcorpan> "GNU (GNU's not UNIX)" ...
  453. # [17:07] <Philip`> Plain English won't work for mutually recursive acronyms Hurd - you'd need to add ugly explanations around it to say what's going on, rather than elegantly encoding the expansion graph using metadata markup
  454. # [17:07] <Philip`> s/ / like /
  455. # [17:07] * Joins: eseidel (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net)
  456. # [17:08] * Joins: eseidel_ (n=eseidel@72.14.224.1)
  457. # [17:09] <zcorpan> who's going to benefit from the metadata markup?
  458. # [17:09] <zcorpan> and is it easier to understand than plain english?
  459. # [17:10] <Philip`> Google could use the metadata so you can ask it for "define:hurd" and it will give you the correct answer
  460. # [17:10] <virtuelv> outside of GNU and (historically) PHP, how many recursive initialisms are there?
  461. # [17:10] <zcorpan> Philip`: what is the answer?
  462. # [17:10] <Philip`> http://en.wikipedia.org/wiki/Recursive_acronym - lots :-)
  463. # [17:11] <virtuelv> "The GNU Hurd project is named with a mutually recursive acronym: "Hurd" stands for "Hird of Unix-Replacing Daemons," and "Hird" stands for "Hurd of Interfaces Representing Depth."
  464. # [17:11] <Philip`> zcorpan: It's "<a href=search?q=define:Hird>Hird</a> of Unix-Replacing Daemons"
  465. # [17:11] <virtuelv> I think I can live with not being able to express those :P
  466. # [17:12] * Joins: gsnedders (n=gsnedder@host86-142-194-45.range86-142.btcentralplus.com)
  467. # [17:13] <Philip`> virtuelv: But there may be other people in the world who cannot live with such a dire situation
  468. # [17:14] <zcorpan> <dl><dt><dfn><abbr>Hurd</abbr></dfn><dd><abbr>Hird</abbr> of Unix-Replacing Daemons<dt><dfn><abbr>Hird</abbr></dfn><dd><abbr>Hird</abbr> of Interfaces Representing Depth</dl>
  469. # [17:15] <zcorpan> elsewhere: <p>... <abbr>Hurd</abbr> ...
  470. # [17:16] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  471. # [17:17] <Philip`> That breaks down if Hird can stand for multiple things on the same page
  472. # [17:18] <Philip`> and e.g. for feed readers which don't know if one term is going to be used multiple times, so they have to expand everything out into title attributes just in case
  473. # [17:18] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  474. # [17:18] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  475. # [17:19] <Philip`> (Er, feed aggregators in particular)
  476. # [17:19] <zcorpan> use title='' to disambiguate
  477. # [17:19] * zcorpan doesn't read carefully
  478. # [17:20] <Philip`> <abbr title='Hurd of ...'>Hird</abbr> would lose the markup around Hurd
  479. # [17:20] <Philip`> so I don't see how you'd disambiguate it
  480. # [17:21] <zcorpan> <span title><abbr>
  481. # [17:21] <zcorpan> :P
  482. # [17:21] <Philip`> Oh, it seems <dfn title="hurd-1"><abbr>Hurd</abbr></dfn> would do useful things
  483. # [17:21] <Philip`> (in terms of disambiguating)
  484. # [17:22] <Philip`> Automatic cross-referencing still seems a bad idea since it introduces lots of invisible dependencies between separate parts of the page, though
  485. # [17:23] <zcorpan> why would they be invisible?
  486. # [17:23] <Philip`> They're invisible in the source
  487. # [17:23] <zcorpan> i guess
  488. # [17:23] <Philip`> and so they're likely to break if you copy-and-paste chunks of one document into another
  489. # [17:24] <Philip`> or if you concatenate two documents
  490. # [17:24] * Quits: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  491. # [17:24] * Quits: eseidel (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  492. # [17:24] <zcorpan> seems like we're searching for problems to make our solution more complicated, when what we really need is gloves
  493. # [17:25] <Philip`> The indirection between elements and <style>s causes enough problems when you're trying to mix documents, so I'd probably be happier if no more indirections were added
  494. # [17:26] * hsivonen_ is now known as hsivonen
  495. # [17:29] <annevk> did IE support UTF-32?
  496. # [17:29] <zcorpan> no
  497. # [17:29] <zcorpan> afaict
  498. # [17:30] <zcorpan> it rendered vorem.com like firefox
  499. # [17:51] <gsnedders> I wonder how much broken XHTML we'll get if IE8 supports it.
  500. # [17:52] <webben> well, MS already have a halfway usable XML parser and a halfway usable MSAA DOM representation and a quarter-way usable DOM
  501. # [17:53] <webben> so I wouldn't have thought it would be all that bad
  502. # [17:53] <webben> oh wait, you mean broken XHTML from authors
  503. # [17:53] <gsnedders> webben: yeah
  504. # [17:53] <webben> I guess that depends on what IE did with borked XHTML
  505. # [17:54] <gsnedders> I mean, every man and his dog will probably try and jump on XHTML
  506. # [17:54] <gsnedders> even with fatal error handling I bet a heckuva lot of broken XHTML will appear
  507. # [17:54] <webben> producing non-broken XHTML isn't an especially difficult task, if you're producing XHTML at all.
  508. # [17:55] <webben> I suspect many of the situations where you're doomed to produce broken XHTML, you're going to produce it sooner rather than later
  509. # [17:55] <webben> e.g. as soon as you have a page with an ad.
  510. # [17:56] <webben> at which point you're probably going to revert to text/html
  511. # [17:56] <gsnedders> I wait with abated breath
  512. # [17:57] <webben> I suspect very few people will switch because so few people understand that serving XHTML tends to involve server configuration as well as just changing a META element.
  513. # [17:59] * Quits: phsiao (n=shawn@c-71-232-12-131.hsd1.ma.comcast.net)
  514. # [18:00] <annevk> "producing non-broken XHTML isn't an especially difficult task, if you're producing XHTML at all." you should check with the very few people who try
  515. # [18:03] <webben> I have tried, I switched back to HTML because it was pointless.
  516. # [18:03] <webben> I still don't think it's especially difficult, FWIW.
  517. # [18:04] <webben> the problem is one of quality control more generally; XHTML just exposes how appalling poor quality control on the web is
  518. # [18:05] <webben> (that is, it was pointless for me, as I don't need Ruby/SVG/MathML, etc.)
  519. # [18:13] <zcorpan> using xhtml because of needing ruby annotations is a bit backwards
  520. # [18:20] * Joins: met_ (n=Hassman@r5bx220.net.upc.cz)
  521. # [18:20] <webben> zcorpan: Other than the fact that Moz only supports them with a plugin and IE only supports them in text/html, I don't see how.
  522. # [18:21] * Joins: phsiao (n=shawn@nat/ibm/x-3dca3fa427bfff19)
  523. # [18:23] <zcorpan> webben: those were the reasons i had in mind
  524. # [18:23] <webben> I wouldn't call that "backwards" exactly.
  525. # [18:24] <zcorpan> ie is the only browser with native ruby support, ie doesn't support xhtml
  526. # [18:24] <zcorpan> hence, using ruby in xhtml doens't work for anyone
  527. # [18:24] <zcorpan> using ruby in html works for ie
  528. # [18:24] <webben> where anyone excludes people with Fx and the Ruby extension?
  529. # [18:24] <zcorpan> (assuming that "no-one" uses mozilla with the plugin)
  530. # [18:25] <webben> I don't think that's a sensible assumption.
  531. # [18:25] <zcorpan> in any case, i bet firefox with the extension supports ruby in both html and xhtml
  532. # [18:26] <webben> Probably, but then one could just content-negotiate for IE.
  533. # [18:26] <zcorpan> and so using xhtml *because* of ruby (like i said) is, if not backwards, very unnecessary
  534. # [18:26] * Quits: dveditz (n=dveditz@dsl-63-249-104-137.cruzio.com) (Read error: 110 (Connection timed out))
  535. # [18:26] <webben> XHTML is the only standard way to publish ruby annotations.
  536. # [18:26] * weinig|away is now known as weinig
  537. # [18:27] <webben> I'd be happy to use a non-standard way as a hack to support the most popular browser on earth.
  538. # [18:27] <zcorpan> that will be fixed in due course when html5 includes ruby
  539. # [18:28] <webben> That day is not today.
  540. # [18:29] <webben> and a couple years is a long time
  541. # [18:29] <zcorpan> meanwhile you can be non-compliant with useless specs :)
  542. # [18:29] <webben> It's no more or less useless than HTML5 will be.
  543. # [18:29] <webben> A spec's a spec.
  544. # [18:30] <zcorpan> specs can surely be useless
  545. # [18:30] <zcorpan> html4 is useless
  546. # [18:30] * webben doesn't agree.
  547. # [18:30] <zcorpan> let's leave it at that
  548. # [18:31] * zcorpan should go home
  549. # [18:35] <Philip`> webben: It appears to be very difficult to produce non-broken XHTML when you include content from potentially-malicious users
  550. # [18:35] <Philip`> e.g. if you commit to a Git repository with a message that contains U+FFFE, then the web interface will become ill-formed and only IE users will be able to read it
  551. # [18:36] <webben> Philip`: Yes, but once you've included malicious content your site is probably a public health hazard.
  552. # [18:36] <webben> that's what I mean by grouping this stuff under general quality control
  553. # [18:36] <webben> if you're not in control of your markup, then you're probably not effectively stopping XSS etc
  554. # [18:37] <Philip`> This is when people just do s/&/&amp;/ and s/</&lt;/ (like what their language / template system's HTML escape function does)
  555. # [18:37] <Philip`> which is perfectly safe in HTML
  556. # [18:37] <Philip`> s/people/developers/
  557. # [18:38] <Philip`> and maybe replace funny characters with &#nnn; too
  558. # [18:38] <webben> I'm not sure what "This" refers to
  559. # [18:38] <webben> but this all sounds like it comes under the rubric of input validation
  560. # [18:38] <webben> which as we all know is generally poorly done
  561. # [18:39] <webben> XHTML just makes that visible in a really annoying way.
  562. # [18:39] <Philip`> "This" = "The situation where malicious users can break the web site of someone who's tried to be careful at escaping input, but hasn't been quite careful enough for XML"
  563. # [18:39] * Joins: SadEagle (n=maksim@cpe-69-202-89-106.twcny.res.rr.com)
  564. # [18:39] <webben> hmm yes, well, there's been a lot more energy put into developing solutions for escaping HTML than XML.
  565. # [18:40] <webben> for understandable reasons
  566. # [18:40] <Philip`> XML escaping requires much more energy than HTML, because there are more ways it can go wrong
  567. # [18:41] <webben> I'm not sure that's true.
  568. # [18:42] <Dashiva> Well, you need some way to ensure it's well-formed, that's a big step up just by itself
  569. # [18:42] <webben> if you're parsing the input anyways, I'm not sure it is.
  570. # [18:42] * Joins: kingryan (n=ryan@c-67-164-15-57.hsd1.ca.comcast.net)
  571. # [18:43] * Quits: zcorpan (n=zcorpan@pat.se.opera.com) (Read error: 145 (Connection timed out))
  572. # [18:43] <Dashiva> If
  573. # [18:44] <annevk> that would require the usage of a compliant XML parser
  574. # [18:44] <annevk> that's a big step up
  575. # [18:44] <Philip`> I'm mostly thinking of just plain text (not trying to allow a 'safe' subset of HTML or anything fancy like that), like when you say "You search for <? escape_html(query) ?> returned <? n ?> results", and escape_html in HTML is quite trivial because you care about & and <, but in XHTML it's hard because there's lots of forbidden characters
  576. # [18:44] <Philip`> s/You/Your/
  577. # [18:45] <webben> annevk: For input validation? Depends on the sort of input; for (X)HTML-esque input I'd probably use a tag soup parser, strip unwanted stuff, and then reserialize into the database.
  578. # [18:46] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  579. # [18:47] <webben> annevk: and I'd do that whether I was going to serve HTML or XHTML.
  580. # [18:48] <Philip`> (and escape_xhtml is clearly hard because I haven't yet found a web site that does it correctly - they all forget about some of the characters that can make their output ill-formed)
  581. # [18:48] <webben> Has anyone compiled a simple list of them?
  582. # [18:48] <webben> (of the characters ...)
  583. # [18:49] <annevk> it's not about what you do, it's about what people are doing now and where they have to move
  584. # [18:49] <annevk> unless you changed the rules
  585. # [18:50] <Philip`> webben: There's http://www.w3.org/International/questions/qa-forms-utf-8 but that's wrong because it misses FFFE and FFFF
  586. # [18:50] <webben> annevk: Most people aren't producing XHTML now.
  587. # [18:50] <Philip`> (according to http://www.intertwingly.net/blog/2008/01/02/Keeping-On-Your-Toes )
  588. # [18:51] <webben> annevk: Even if you were to count the people who produce tag soup XHTML, which I don't really.
  589. # [18:51] <annevk> that's besides the point
  590. # [18:51] <annevk> (both)
  591. # [18:51] * Joins: maikmerten (n=maikmert@T615f.t.pppool.de)
  592. # [18:52] <webben> what are the people who are producing real XHTML doing now?
  593. # [18:52] <annevk> they fail and plug holes, mostly
  594. # [18:55] <webben> Philip`: I don't fully grok that ... the W3C page looks like a regex for sniffing UTF-8 rather than a simple list of characters not allowed in XHTML.
  595. # [18:56] <webben> annevk: Sounds similar to what happens when we try to produce HTML.
  596. # [18:57] <webben> just with a different failure result.
  597. # [18:58] <annevk> sure, but it doesn't affect the end user
  598. # [18:58] <webben> yes it does
  599. # [18:58] <webben> when their data is stolen it definitely does!
  600. # [18:59] <webben> when the page renders but doesn't work properly
  601. # [18:59] <webben> when characters are rendered incorrectly
  602. # [18:59] <webben> etc.
  603. # [19:00] <annevk> those are not the result of using HTML incorrectly
  604. # [19:00] <gsnedders> webben: they can equally happen with XHTML
  605. # [19:00] <annevk> that too
  606. # [19:01] <webben> gsnedders: Of course. That's not my point.
  607. # [19:01] <annevk> your point got lost to me 10 minutes ago
  608. # [19:01] * Joins: eseidel (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net)
  609. # [19:01] <webben> gsnedders: My point is rather that publishers' problems with XHTML are in part a warning signal that they don't have enough control over markup quality to protect user experience and data.
  610. # [19:02] * Joins: phsiao_ (n=shawn@nat/ibm/x-ea33d5e9932a1677)
  611. # [19:03] <webben> XHTML doesn't cure the problem or anything.
  612. # [19:05] * Parts: Camaban (n=adrianle@host81-135-169-203.in-addr.btopenworld.com)
  613. # [19:06] <Philip`> webben: About regex thing: Hmm, true, I guess it's not entirely relevant - it does forbid the control characters below 0x20 that XML doesn't allow, but it doesn't say it's doing that on purpose, and it wouldn't work in a proper Unicode string environment
  614. # [19:06] <Philip`> http://www.w3.org/TR/REC-xml/#charsets lists the actual characters that are allowed, which is more useful when trying to write code
  615. # [19:07] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  616. # [19:08] * Quits: eseidel_ (n=eseidel@72.14.224.1) (Read error: 104 (Connection reset by peer))
  617. # [19:09] <webben> Philip`: Right, and if folks just used /that/ then they wouldn't have probs with FFE and FFFF.
  618. # [19:09] <webben> *FFFE
  619. # [19:10] <Philip`> It seems that in practice people don't use that, or they use it on the wrong side of a UTF-8 <-> Unicode conversion, or do something else wrong
  620. # [19:11] <Philip`> Maybe it's just something that the world needs to be taught before using XHTML
  621. # [19:11] <Philip`> and which hasn't been taught yet
  622. # [19:11] <webben> well, it's not just XHTML
  623. # [19:11] <webben> also RSS etc
  624. # [19:12] <Philip`> (the same as how it's taken a while for people to realise that SQL injection and XSS etc are problems, but they're fairly well known now among certain groups of people)
  625. # [19:12] <webben> Indeed.
  626. # [19:12] <webben> That's very much along the lines of what I was saying.
  627. # [19:14] <webben> I wonder how much of the problem does or doesn't stem from poor language support for unicode too.
  628. # [19:14] <webben> And bad defaults.
  629. # [19:14] <webben> e.g. PHP now has filter: http://uk.php.net/filter
  630. # [19:14] <webben> but it's off by default because turning it on would break a lot of the web
  631. # [19:18] * Joins: jgraham (n=james@81-86-215-67.dsl.pipex.com)
  632. # [19:19] * Joins: dveditz (i=dveditz@dsl-63-249-104-137.cruzio.com)
  633. # [19:21] * Quits: phsiao (n=shawn@nat/ibm/x-3dca3fa427bfff19) (Read error: 110 (Connection timed out))
  634. # [19:26] <gsnedders> what's browser support of IRIs like (esp. in paths)?
  635. # [19:29] * Philip` sees that Opera doesn't like http://.../...#%65 etc, but Firefox does, and wonders who's wrong
  636. # [19:29] <annevk> Opera
  637. # [19:29] <annevk> known issue
  638. # [19:29] <Philip`> Oh, works in 9.5
  639. # [19:29] * Philip` doesn't fix his code, in that case
  640. # [19:30] <annevk> fixed issue, even, nice :)
  641. # [19:30] * annevk needs to keep up
  642. # [19:39] * Quits: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  643. # [19:47] * Joins: roc (n=roc@121.72.160.41)
  644. # [19:49] * Quits: phsiao_ (n=shawn@nat/ibm/x-ea33d5e9932a1677)
  645. # [20:03] * Joins: jruderman (n=jruderma@guest-228.mountainview.mozilla.com)
  646. # [20:03] * Joins: dbaron (n=dbaron@guest-228.mountainview.mozilla.com)
  647. # [20:11] * Joins: peepo (n=Jay@host86-147-236-233.range86-147.btcentralplus.com)
  648. # [20:15] * Joins: phsiao (n=shawn@nat/ibm/x-93085173ddb3f99e)
  649. # [20:19] * Joins: webben_ (n=benh@91.84.250.225)
  650. # [20:25] * Quits: webben (n=benh@dip5-fw.corp.ukl.yahoo.com) (Success)
  651. # [20:26] * Quits: peepo (n=Jay@host86-147-236-233.range86-147.btcentralplus.com) ("later")
  652. # [20:30] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Read error: 104 (Connection reset by peer))
  653. # [20:31] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  654. # [20:31] * Parts: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Leaving")
  655. # [20:32] * Quits: roc (n=roc@121.72.160.41)
  656. # [20:34] * Quits: phsiao (n=shawn@nat/ibm/x-93085173ddb3f99e) (Read error: 110 (Connection timed out))
  657. # [20:46] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) ("This computer has gone to sleep")
  658. # [20:49] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  659. # [21:00] * Quits: dbaron (n=dbaron@guest-228.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  660. # [21:06] <Hixie> Philip`: i can't find a step 2 that says to go to step 2, and the two step algorithm does have two steps. (well 7, if you include the 5 inner steps of step 1)
  661. # [21:06] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
  662. # [21:10] <Philip`> Hixie: It's "1. If position points to: <stuff with two "a sequence" things, the second with 5 steps> 2. Otherwise, return to step 2 in these inner steps."
  663. # [21:11] <Philip`> and then it has "A sequence of bytes starting with a 0x3C byte (ASCII '<'), optionally a 0x2F byte (ASCII '/'), and finally a byte in the range 0x41-0x5A or 0x61-0x7A (an ASCII letter)" outside the list it should probably be in (introduced by "If position points to:")
  664. # [21:12] <Hixie> uh
  665. # [21:12] <Hixie> yes clearly that step 2 is wrong
  666. # [21:12] <Philip`> perhaps because the "case-insensitive ASCII '&lt;meta' followed by a space or slash" bit has an <ol> with a <p> child
  667. # [21:12] <Hixie> oh
  668. # [21:12] <Hixie> i see
  669. # [21:12] <Hixie> massive markup error
  670. # [21:12] <Hixie> will gix
  671. # [21:12] <Hixie> fix
  672. # [21:14] <annevk> not catched by the validator?
  673. # [21:14] <Hixie> the preprocessor "fixed" it
  674. # [21:15] <annevk> ah yeah, that happens
  675. # [21:15] <annevk> maybe run it over the source?
  676. # [21:15] <Philip`> http://validator.nu?doc=http://www.whatwg.org/specs/web-apps/current-work/source
  677. # [21:15] <Philip`> annevk: Oh, good idea
  678. # [21:15] <annevk> well, you need to prefix the source with something first I guess
  679. # [21:16] <Philip`> I assume it'd recover after complaining it was missing the doctype and title
  680. # [21:16] * Joins: roc (n=roc@202.0.36.64)
  681. # [21:16] <Hixie> ok i should have fixed that list issue
  682. # [21:16] <Hixie> looks now
  683. # [21:16] <Hixie> i'll fix the rest later
  684. # [21:17] <Philip`> so just ignore the first four messages and fix the next near-infinite errors
  685. # [21:17] <Philip`> Hixie: Okay, thanks!
  686. # [21:17] <annevk> Philip`, true
  687. # [21:18] <annevk> heh
  688. # [21:18] <annevk> "Fatal Error: Too many messages."
  689. # [21:18] <annevk> hsivonen, could you add "HTML is hard." to that as easter egg? :)
  690. # [21:19] <Hixie> hsivonen: you output three messages when one end tag has been substituted for another
  691. # [21:19] <Hixie> as in, <span>...</code>...</p>
  692. # [21:20] <Hixie> missing </span>, unexpected </code>, and <span> still open at </p>.
  693. # [21:20] * Joins: eseidel_ (n=eseidel@72.14.224.1)
  694. # [21:32] * Joins: weinig (n=weinig@17.203.15.180)
  695. # [21:33] * Quits: maikmerten (n=maikmert@T615f.t.pppool.de) ("Leaving")
  696. # [21:37] * Quits: eseidel (n=eseidel@c-69-181-78-198.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  697. # [21:40] <Hixie> in fact the >1000 errors are only at most 50 or so
  698. # [21:40] <Hixie> all fixed now
  699. # [21:45] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  700. # [21:45] <Hixie> is there an output format for the validator that outputs text/plain?
  701. # [21:46] <annevk> there's documentation on the whatwg wiki
  702. # [21:46] <annevk> (there is, just not sure how to get it)
  703. # [21:46] <takkaria> Hixie: http://wiki.whatwg.org/wiki/Validator.nu_Web_Service_Interface
  704. # [21:47] <Hixie> cool thanks
  705. # [21:47] <Philip`> &out=text
  706. # [21:47] <Hixie> out=gnu is probably what i want
  707. # [21:47] <Hixie> well maybe out=text is ok
  708. # [21:49] <annevk> for out=gnu you could simply check if the amount of lines is greater than 4
  709. # [21:49] <Hixie> out=text uses wacky ass quotation marks
  710. # [21:50] <Hixie> annevk: ?
  711. # [21:50] <annevk> if the return value has more than 4 lines you have hit a regression
  712. # [21:50] <annevk> and need to fix your markup
  713. # [21:50] <Hixie> nope. out=text still uses silly quotation marks
  714. # [21:50] <Hixie> hsivonen: any chance i can get a US-ASCII output mode? :-)
  715. # [21:51] <Hixie> heh, the validator caught my en-GB-hixie error
  716. # [21:51] <Hixie> guess i'd better fix it
  717. # [21:53] <annevk> Hixie, I'm talking about out=gnu, it uses those quotation marks too, but i'm not sure why that's relevant if you simply want to catch regressions
  718. # [21:54] <hsivonen> Hixie: out=gnu is an UTF-8 output mode. (It'll change a bit soon as the GNU spec is amended.) UTF-8 is the new US-ASCII. ;-)
  719. # [21:55] <hsivonen> Hixie: out=text is for human reading. you shouldn't try to write a program to parse it.
  720. # [21:55] * Hixie accidentally outputs the w3c version to the whatwg site
  721. # [21:56] <Hixie> annevk: yeah i was just confused about why you wanted to skip 4 lines? shouldn't i want zero errors?
  722. # [21:57] <hsivonen> Hixie: how seriously do you need a US-ASCII mode and what should it do with non-ASCII characters?
  723. # [21:57] <annevk> Hixie, oh, I was assuming you wouldn't prefix the source file with the WHATWG header file
  724. # [21:57] <Hixie> hsivonen: i don't want to parse it. i have my emacs configured to US-ASCII with any 8 bit bytes displayed in octal, so that i can easily edit test cases with malformed byte sequences
  725. # [21:57] <Hixie> hsivonen: so your quotation marks look like \123\123\123
  726. # [21:57] <Hixie> really it's just a "no fancy quotes" mode that i'd like :-)
  727. # [21:58] <Hixie> annevk: in my script it's already done, so that's not a problem
  728. # [21:59] <hsivonen> Hixie: out=gnu is meant to be emacs-friendly, but only when emacs is configured to do UTF-8
  729. # [22:00] <Hixie> specifically i get:
  730. # [22:00] <Hixie> http://www.whatwg.org/specs/web-apps/current-work/source-whatwg:1.51-2.25: error: Bad value \342\200\234en-GB-hixie\342\200\\
  731. # [22:00] <Hixie> 235 for attribute \342\200\234lang\342\200\235 on element \342\200\234html\342\200\235: Bad variant subtag.
  732. # [22:00] * Joins: cgriego (n=cgriego@cpe-76-183-49-187.tx.res.rr.com)
  733. # [22:00] <Hixie> i guess it's not a big deal, just looks ugly and makes it hard to work out what the error is
  734. # [22:00] * Parts: cgriego (n=cgriego@cpe-76-183-49-187.tx.res.rr.com)
  735. # [22:01] <hsivonen> Hixie: can you give me a spec for some processing magic before the UTF-16 to UTF-8 conversion?
  736. # [22:01] <hsivonen> Hixie: just replacing the quotes?
  737. # [22:01] * Joins: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  738. # [22:02] <hsivonen> Hixie: out of curiosity, what code do you use for integrating emacs and the Web service?
  739. # [22:04] * Quits: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net) (Client Quit)
  740. # [22:04] * Quits: eseidel_ (n=eseidel@72.14.224.1)
  741. # [22:06] <Hixie> curl
  742. # [22:06] <Hixie> and yeah, just replacing quotes with " would solve my immediate problem
  743. # [22:09] * Quits: gsnedders (n=gsnedder@host86-142-194-45.range86-142.btcentralplus.com)
  744. # [22:11] <met_> checking acid3 in last Webkit, strange that test 78 sometimes fails, otherwise not. So I have 87/100, but from time to time it ends 86/100
  745. # [22:11] <met_> from console it's Test 78: expected: 90, got: 0 - getRotationOfChar(0) failed.
  746. # [22:11] <hsivonen> Hixie: ok.
  747. # [22:12] <Hixie> met_: yeah it's probably not always loading the font
  748. # [22:13] <hsivonen> Hixie: it's http://bugzilla.validator.nu/show_bug.cgi?id=135 now
  749. # [22:14] <Hixie> do the fancy quotes provide any direct benefit to users?
  750. # [22:14] <Hixie> apart from looking arguably prettier in certain contexts?
  751. # [22:15] <Hixie> because frankly they also cause me other problems, like i can't easily copy and paste them across ssh sessions
  752. # [22:15] <hsivonen> Hixie: they disambiguate start and end better and they don't themselves occur in XML/HTML syntax
  753. # [22:16] <Hixie> fair enough
  754. # [22:21] * Joins: gsnedders (n=gsnedder@host86-142-194-45.range86-142.btcentralplus.com)
  755. # [22:21] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  756. # [22:22] <met_> Hixie, yeh and it differs from time to time, now failed other svg test -79. It's difficult co compare, when other browsers doesn't support remote fonts
  757. # [22:22] * Joins: eseidel (n=eseidel@adsl-75-36-143-230.dsl.pltn13.sbcglobal.net)
  758. # [22:23] <annevk> met_, Opera 9.5 does, no? Although we have some failures there as well I think
  759. # [22:24] <met_> annevk, Opera 9.5 support remote fonts? Holly father, I have missed it.
  760. # [22:25] <gsnedders> interesting. I have hits from a browser claiming to be Firefox 9.0
  761. # [22:25] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  762. # [22:31] <annevk> met_, I believe we do, but I no next to nothing about SVG
  763. # [22:31] <annevk> s/no/know/
  764. # [22:32] <met_> annevk, just downloading last opera weekly to check
  765. # [22:40] * Quits: kingryan (n=ryan@c-67-164-15-57.hsd1.ca.comcast.net)
  766. # [22:41] <met_> annevk, no examples from http://www.alistapart.com/articles/cssatten still don't work in public build
  767. # [22:42] * gsnedders decides he better not describe himself as Hixie's minion protégé in a silly autobiography, as someone is bound to take it seriously
  768. # [22:43] <annevk> met_, I thought you were talking about SVG specifically
  769. # [22:43] <annevk> met_, there's no "generic" support for downloadable fonts
  770. # [22:43] <met_> from the acid test yes, i have tried it generally now, so for svg should work?
  771. # [22:43] <met_> ok
  772. # [22:48] <roc> hmm, should I fix IFRAME drawing inside SVG filters on Mac, just so I can adapt reftest-analyzer to work with live testcases?
  773. # [22:48] <roc> yeah!
  774. # [23:02] <eseidel> ?
  775. # [23:02] <eseidel> ah, he's talking about FF SVG
  776. # [23:03] <jgraham> eseidel: With that kind of enthusiasm, who cares about the tangentialness of the relevance ;)
  777. # [23:05] * eseidel would like someone to fix rightsizing in webkit
  778. # [23:06] <roc> oops wrong channel
  779. # [23:06] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  780. # [23:07] <roc> but it *is* kind of cool that with SVG filters, IFRAMEs and foreignobject you can create a pixel-level page comparison tool in a Web app
  781. # [23:07] <annevk> rightsizing?!
  782. # [23:07] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  783. # [23:07] * annevk was hoping that terminology would not be used outside the CDF WG
  784. # [23:08] <roc> oh, have they got a spec for that?
  785. # [23:08] * jgraham wonders what rightsizing is if it's not a euphemism for sacking everyone
  786. # [23:08] <eseidel> annevk: we need a term for those bugs
  787. # [23:09] <roc> I think it means "give IFRAMEs a meaningful intrinsic size" (or height at least)
  788. # [23:09] <eseidel> so I stole the CDF WG's term
  789. # [23:09] <eseidel> oh, no that's another set of bugs roc
  790. # [23:09] <eseidel> roc: that's just implementing CSS 2.1 :)
  791. # [23:09] <roc> what is?
  792. # [23:10] <eseidel> CSS 2.1 requires inline replaced elements to support relative intrinsic sizes
  793. # [23:10] <eseidel> which we in webkit at least don't support
  794. # [23:10] <roc> you mean the aspect-ratio-preserving stuff?
  795. # [23:10] <eseidel> so things like <object> don't corretly pick up the height="100%" off of their svg child doc
  796. # [23:10] * Joins: kingryan (n=ryan@12.153.255.213)
  797. # [23:10] <othermaciej> I don't think current browsers ever give <iframe> a useful intrinsic size
  798. # [23:10] <eseidel> roc: the aspect-ratio-preserving stuff is "right sizing"
  799. # [23:10] * Quits: kingryan (n=ryan@12.153.255.213) (Remote closed the connection)
  800. # [23:10] <othermaciej> even if you put a fixed-size raster image in it
  801. # [23:11] <othermaciej> so it's not really the same issue as <object?
  802. # [23:11] <othermaciej> >
  803. # [23:11] <roc> CSS2.1 specifies that IFRAME intrinsic sizes should depend on the child document? news to me
  804. # [23:11] * Joins: kingryan (n=ryan@12.153.255.213)
  805. # [23:11] * Quits: kingryan (n=ryan@12.153.255.213) (Remote closed the connection)
  806. # [23:11] <annevk> eseidel, aspect ratio is also CSS 2.1
  807. # [23:11] <othermaciej> (it would be handy if <iframme> could size appropriately to a child HTML document, but you'd need some way to ask for that in CSS)
  808. # [23:11] <annevk> eseidel, in fact, if it's not, rightsizing would be a violation of CSS 2.1, which is not what you want...
  809. # [23:12] <roc> yeah, that's what I want (and the Web needs I think)
  810. # [23:12] <annevk> (having said that, CSS 2.1 should just say whatever is most fancy and works)
  811. # [23:12] <roc> I actually had a patch for it in Gecko, but there's a concern about information leakage
  812. # [23:12] <roc> for cross-domain frames
  813. # [23:13] <eseidel> rightsizing entered into my lingo from the WICD tests http://bugs.webkit.org/show_bug.cgi?id=15836... I might be using it wrong though
  814. # [23:13] <eseidel> annevk: this is the CSS 2.1 bug of which I speak: http://bugs.webkit.org/show_bug.cgi?id=15849
  815. # [23:13] <eseidel> which causes us to fail hixie's tests: http://bugs.webkit.org/show_bug.cgi?id=15473
  816. # [23:21] * Joins: eseidel_ (n=eseidel@72.14.224.1)
  817. # [23:26] <gsnedders> Hixie: with <http://bugs.webkit.org/show_bug.cgi?id=17023> you better paste it all again with the changes :P
  818. # [23:27] * Quits: gsnedders (n=gsnedder@host86-142-194-45.range86-142.btcentralplus.com) ("Partying in teh intarwebs")
  819. # [23:31] * Parts: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  820. # [23:34] * Quits: met_ (n=Hassman@r5bx220.net.upc.cz) ("Chemists never die, they just stop reacting.")
  821. # [23:36] * Quits: eseidel (n=eseidel@adsl-75-36-143-230.dsl.pltn13.sbcglobal.net) (Read error: 110 (Connection timed out))
  822. # [23:37] * eseidel_ is now known as eseidel
  823. # [23:58] * Joins: jwalden (n=waldo@STRATTON-FIVE-EIGHTY-EIGHT.MIT.EDU)
  824. # Session Close: Wed Mar 05 00:00:00 2008

The end :)