/irc-logs / freenode / #whatwg / 2007-06-29 / end

Options:

  1. # Session Start: Fri Jun 29 00:00:00 2007
  2. # Session Ident: #whatwg
  3. # [00:01] <met_> hsivonen: it's the blue rectagles test? (according to safari, there is no note about Konq)
  4. # [00:03] <hsivonen> Philip`: oops. I've forgotten to act on that report
  5. # [00:03] <hsivonen> Philip`: sorry
  6. # [00:03] <met_> probably not exactly, I see some differences from the Konq 3.2 you have there
  7. # [00:03] <hsivonen> met_: the blue rectangles tests full standards vs. something else
  8. # [00:05] <hsivonen> Philip`: fixed
  9. # [00:05] <hsivonen> Philip`: thanks
  10. # [00:05] * Quits: othermaciej (n=mjs@17.255.100.184) (Read error: 104 (Connection reset by peer))
  11. # [00:05] <met_> donot work, If I went throug Konq3.2 column I see different results even for some quirks
  12. # [00:06] <hsivonen> met_: do you still have Konq 3.2?
  13. # [00:07] <met_> no 3.5.5 (mentioned above), there was something fixed probably
  14. # [00:07] <met_> not usefull for you
  15. # [00:07] <hsivonen> met_: most likely they landed the code hyatt adapted from Gecko way back in the Safari 1.0 cycle
  16. # [00:08] <hsivonen> or 0.9 rather
  17. # [00:10] <met_> I see even difference between XHTML transitional and strict, you have both Q
  18. # [00:14] <hsivonen> met_: Konq 3.2 is 3.2. Moz & Safari is 3.5
  19. # [00:15] <met_> yes I have just tested whole table Konq 3.5.5 is exactly like Moz+Saf column
  20. # [00:27] <met_> 2004-10-28 Stephan Kulow <coolo@kde.org>
  21. # [00:27] <met_> * html/html_documentimpl.cpp (determineParseMode): adding a fixed list of
  22. # [00:27] <met_> doctypes to enable quirks mode on (derived from Webcore, but majorly revised)
  23. # [00:27] <met_> * enable strict CSS parsing also for transitional doctypes
  24. # [00:27] <met_> from http://websvn.kde.org/branches/KDE/3.5/kdelibs/khtml/ChangeLog?view=markup&pathrev=632575
  25. # [00:28] <met_> 2004 it's pretty old
  26. # [00:28] <hsivonen> met_: thanks
  27. # [00:29] <hsivonen> I wonder how the ICU4J encoding detector differs from Mozilla chardet
  28. # [00:30] <met_> and here is the KHTML source function HTMLDocumentImpl::determineParseMode http://websvn.kde.org/branches/KDE/3.5/kdelibs/khtml/html/html_documentimpl.cpp?revision=628618&view=markup
  29. # [00:31] <met_> khml has even different file names from webkit source - it has to be nightmare with merging
  30. # [00:32] <hsivonen> why the difference in file names?
  31. # [00:32] * Quits: annevk (n=annevk@6.80-203-24.nextgentel.com) (Read error: 110 (Connection timed out))
  32. # [00:34] * Joins: weinig (i=weinig@nat/apple/x-884aa6ec88ff8999)
  33. # [00:36] <met_> html_documentimpl.cpp from KHTML is HTMLDocument.cpp in webkit
  34. # [00:36] <met_> different convention probably
  35. # [00:39] * Quits: virtuelv_ (n=virtuelv@47.80-202-66.nextgentel.com) ("Leaving")
  36. # [00:41] <met_> Does anyone know, why Safari sents to flick and yahoo different uastring?
  37. # [00:43] <met_> it tries to look as older version for this domains, it's harcoded in http://www.koders.com/noncode/fid469663037C7D987803483ECADC6068A0AD6B40F2.aspx#L3579
  38. # [00:45] <hsivonen> met_: I don't know but it isn't hard to guess why. most likely Yahoo is doing bad UA sniffing
  39. # [00:46] <hsivonen> or then they are doing good UA sniffing to work around a WebKit bug and the new WebKit doesn't fix the bug
  40. # [00:46] <met_> hsivonen: it is much different
  41. # [00:47] <hsivonen> yes
  42. # [00:47] <met_> only in version number
  43. # [00:47] * Joins: aroben_ (n=adamrobe@17.203.15.248)
  44. # [00:47] <met_> and also send Macintosh even if i work on Windows
  45. # [00:48] <met_> oh so late, going to sleep, bye
  46. # [00:48] * Quits: met_ (n=Hassman@r5bx220.net.upc.cz) ("Chemists never die, they just stop reacting.")
  47. # [00:56] * Quits: kingryan (n=kingryan@corp.technorati.com)
  48. # [00:59] * Quits: the_mart (n=Martin@host86-135-9-158.range86-135.btcentralplus.com) ("Leaving")
  49. # [01:01] * Quits: aroben (n=adamrobe@17.255.96.162) (Read error: 110 (Connection timed out))
  50. # [01:02] * Quits: briansuda (n=briansud@85-220-95-76.dsl.dynamic.simnet.is)
  51. # [01:08] * Quits: weinig (i=weinig@nat/apple/x-884aa6ec88ff8999)
  52. # [01:16] * Joins: weinig (i=weinig@nat/apple/x-4a550716618d07fa)
  53. # [01:20] * Quits: billmason (n=billmaso@ip156.unival.com) (Read error: 104 (Connection reset by peer))
  54. # [01:20] * Joins: othermaciej (n=mjs@17.255.100.184)
  55. # [01:30] * Quits: hendry (n=hendry@91.84.62.62) ("leaving")
  56. # [01:34] * Quits: tndH (i=Rob@adsl-87-102-84-66.karoo.KCOM.COM) ("ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  57. # [01:38] <Hixie> so... determining if headers="" is correctly-used or not
  58. # [01:41] * Quits: jgraham (n=jgraham@81-86-213-130.dsl.pipex.com) (Read error: 110 (Connection timed out))
  59. # [01:44] * aroben_ is now known as aroben
  60. # [01:46] * Joins: webben (i=benh@nat/yahoo/x-1c400d2309481780)
  61. # [01:46] <Hixie> http://www.brera.unimi.it/old/CAELUM/MUSEO/Schede/rif32.html
  62. # [01:46] <Hixie> i know it says "old" in the URL, but uh, were there even _computers_ in 1939?!
  63. # [01:47] <othermaciej> do ENIGMA-cracking machines count?
  64. # [01:47] <Hixie> only if the data on those machines was written in HTML
  65. # [01:47] <Hixie> (that HTML file has a "last modified" date of 1939)
  66. # [01:50] * Quits: webben (i=benh@nat/yahoo/x-1c400d2309481780) (Client Quit)
  67. # [01:56] * Joins: karlUshi (n=karl@dhcp-247-173.mag.keio.ac.jp)
  68. # [02:07] <zcorpan_> typo of 1993?
  69. # [02:08] <Hixie> why would you type the last modified date?
  70. # [02:08] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net) (Read error: 104 (Connection reset by peer))
  71. # [02:08] <zcorpan_> dunno
  72. # [02:09] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  73. # [02:09] * Joins: weinig_ (i=weinig@nat/apple/x-fe21fb2f962635f6)
  74. # [02:10] * Quits: weinig (i=weinig@nat/apple/x-4a550716618d07fa) (Read error: 104 (Connection reset by peer))
  75. # [02:11] * weinig_ is now known as weinig
  76. # [02:29] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  77. # [02:34] <hober> ImproperlyConfigured: Error loading MySQLdb module: No module named MySQLdb
  78. # [02:34] <hober> whoops, sorry for the noise.
  79. # [02:36] <zcorpan_> hmm, i think firefox has funny handling of -- in doctypes
  80. # [02:37] <Hixie> not "funny"
  81. # [02:37] <Hixie> "compliant to SGML"
  82. # [02:37] <Hixie> i opted to drop that in the spec's version, you'll be glad to notice
  83. # [02:38] <zcorpan_> not quite compliant to sgml... <!doctype html --> foo -- system>
  84. # [02:39] <Hixie> heh
  85. # [02:39] <Hixie> fair enough
  86. # [02:39] <Lachy> zcorpan_: are comments allowed in DOCTYPEs like that? I don't think so
  87. # [02:39] <zcorpan_> Lachy: per sgml, yes
  88. # [02:40] <Lachy> I thought only within the internal subset, not before the sys ident like that
  89. # [02:40] <Hixie> in any sgml declaration
  90. # [02:40] <Hixie> the doctype is an sgml declaration
  91. # [02:40] <zcorpan_> what Hixie said
  92. # [02:40] <Hixie> at least that's my understanding
  93. # [02:40] <Hixie> it's mostly academic in practice
  94. # [02:40] <Lachy> oh, right. anyway, doesn't matter
  95. # [02:41] <zcorpan_> indeed
  96. # [02:43] <Hixie> ok so for my study of longdesc="", i'm looking for these things:
  97. # [02:43] <Hixie> * does the <img> not have a longdesc at all?
  98. # [02:43] <Hixie> * is its longdesc blank?
  99. # [02:43] <Hixie> * does its longdesc have a spec character in it?
  100. # [02:43] <Hixie> * does its longdesc value match the href="" of an ancestor <a> element?
  101. # [02:43] <Hixie> anything else i should look for?
  102. # [02:44] <zcorpan_> * does it's longdesc point to the same page or a fragment on the same page?
  103. # [02:44] <Lachy> could you also check if it matches an href anywhere in the document, if there isn't an ancestor link?
  104. # [02:44] <Lachy> or at least nearby\
  105. # [02:45] <zcorpan_> given jaws implementation, same-page fragments with longdesc aren't usable at all
  106. # [02:45] <Lachy> the idea is to see if most people are willing to put [D] links, or equivalent in, despite having fairly wide AT support now
  107. # [02:46] <Hixie> ok i added a check to see if the attribute's value matches the page's url
  108. # [02:46] <Hixie> and a check to see if the value doesn't have a space in it but starts with a #
  109. # [02:46] <Hixie> do i need a check for whether the value is url+# ?
  110. # [02:47] <zcorpan_> probably not
  111. # [02:47] <Lachy> what could you conclude from url+#?
  112. # [02:47] <Hixie> i mean, the page's url + #
  113. # [02:47] <Hixie> ok
  114. # [02:47] <Hixie> now headers=""
  115. # [02:47] <Hixie> lordy
  116. # [02:47] <Lachy> oh, ok, I thought you meant just any URL. But that would tell you longdescs to the same page
  117. # [02:49] * Quits: weinig (i=weinig@nat/apple/x-fe21fb2f962635f6)
  118. # [02:51] * Joins: yod (n=ot@softbank221018155222.bbtec.net)
  119. # [02:52] <csarven> occording to this http://www.w3.org/TR/2006/REC-xml-20060816/#NT-EmptyElemTag the trailing space on empty/null elements is optional. i can't remember correctly but was there anything about IE not interpreting the empty elements if there were no trailing spaces?
  120. # [02:53] <csarven> s/occording/according
  121. # [02:53] <Hixie> in XHTML? or in raw XML?
  122. # [02:53] <Hixie> IE doesn't support XHTML.
  123. # [02:53] <Hixie> but it handles raw XML pretty much per spec.
  124. # [02:54] <csarven> well XHTML is useless for IE so it doesn't make a difference either way right
  125. # [02:54] <csarven> im probably mistaken about this
  126. # [02:54] <zcorpan_> the trailing space mentioned in xhtml 1.0 appendix c is for NN4
  127. # [02:55] <Lachy> does NN4 really choke on it?
  128. # [02:55] <csarven> for some reason i thought that the trailing space that developers were putting on XHTML documents (served with text/html for IE) contained the trailing spaces.. i thought it was because IE didn't treat them properly when there was no trailing space
  129. # [02:55] <Lachy> I thought it was pre-NN4 browsers
  130. # [02:55] <zcorpan_> it treats it as part of the tag name
  131. # [02:55] <Lachy> they do because of the appendix c guideline, not because of IE
  132. # [02:56] <Lachy> there are no known widely used browsers that need the space these days
  133. # [02:56] <zcorpan_> <br foo=""/> probably works fine in nn4 though (it would just treat it as an attribute)
  134. # [02:58] <csarven> interesting. http://www.w3.org/TR/2006/REC-xml-20060816/#NT-EmptyElemTag states its optional but appendix C suggests to use the trailing space
  135. # [02:59] <Lachy> There are, unfortunately, still some people in the world who use NN4. There was a question on the WSG list recently by someone with a project that had to support Windows 3.1 and NN4 :-/
  136. # [02:59] <Lachy> I think it was some intranet project
  137. # [02:59] <Hixie> csarven: i highly recommend using text/html and forgetting about XML for the purposes of XHTML :-)
  138. # [03:00] <Lachy> csarven: keep in mind that appendix c is non-normative and is based upon unknown research on ancient browsers.
  139. # [03:01] <zcorpan_> ...and has conflicting guidelines
  140. # [03:01] <csarven> perhaps this is the unclear part for me.. is XHTML not entirely XML? :S
  141. # [03:01] <zcorpan_> (don't use PIs, use PIs)
  142. # [03:01] <Lachy> it is, but it just has guidlines for authors wanting to make it compatible with legacy UAs as text/html
  143. # [03:01] <csarven> Hixie oh this is just for curiosity :)
  144. # [03:01] <Hixie> ah :-)
  145. # [03:02] <csarven> good point Lachy
  146. # [03:02] <csarven> zcorpan_ :)
  147. # [03:02] <Lachy> the guidlines can be mostly ignored, though
  148. # [03:02] <Lachy> zcorpan_: the conflict is that it says to use <?xml?> decl, but don't use PIs because of the <?foo?> syntax
  149. # [03:04] <zcorpan_> Lachy: C.1 vs C.14
  150. # [03:04] <Lachy> yeah, I think so
  151. # [03:04] * Quits: YaaL (i=yaal@hell.pl) (Remote closed the connection)
  152. # [03:04] * Joins: YaaL (i=yaal@hell.pl)
  153. # [03:04] <zcorpan_> though C.14 is about when serving as xml, not text/html
  154. # [03:05] <Lachy> oh, I see, I got it backwards.
  155. # [03:05] <Lachy> It says don't use <?xml?>, but use <?xml-stylesheet?>
  156. # [03:06] <Lachy> then there's also the issue that <?xml-stylesheet?> doesn't define how to process stylesheets identified with a fragment ident.
  157. # [03:06] * Quits: h3h (n=w3rd@66-162-32-234.static.twtelecom.net) ("|")
  158. # [03:07] <zcorpan_> we need an Associating Style Sheets with XML documents 5
  159. # [03:08] <zcorpan_> or perhaps annevk will define that as part of xml5
  160. # [03:10] * Joins: polin8 (n=brian@ool-18b8cc06.dyn.optonline.net)
  161. # [03:13] <zcorpan_> <?xml-stylesheet href="&#x41;"?>
  162. # [03:13] <csarven> zcorpan_ ASS?
  163. # [03:13] <zcorpan_> :)
  164. # [03:13] <csarven> has a nice ring to it
  165. # [03:13] <zcorpan_> ASS5
  166. # [03:14] * Quits: aroben (n=adamrobe@17.203.15.248) (Read error: 110 (Connection timed out))
  167. # [03:19] <othermaciej> obviously you should name it Canonical ASS instead
  168. # [03:21] <zcorpan_> well there you go: opera expands NCRs in the pseudo-attributes, firefox doesn't
  169. # [03:21] <zcorpan_> not that the spec doesn't define that case though
  170. # [03:27] <Lachy> zcorpan_: which way does XML define it?
  171. # [03:27] <Hixie> sigh
  172. # [03:28] <Hixie> i'm gonna have to implement the Forming a Table algorithm aren't i
  173. # [03:28] <Lachy> Hixie, yeah
  174. # [03:29] <Hixie> so
  175. # [03:30] <Hixie> once i have these two tables constructed (one with headers and one without)
  176. # [03:30] <Hixie> how do i quantitatively compare them?
  177. # [03:30] <Hixie> just 1 for different and 0 for the same?
  178. # [03:32] * Joins: aroben_ (n=adamrobe@17.203.15.248)
  179. # [03:39] * Quits: polin8 (n=brian@ool-18b8cc06.dyn.optonline.net)
  180. # [03:40] <othermaciej> perhaps -1 for cases where the uses of headers is illegal and so might just confuse AT
  181. # [03:40] <Hixie> ah yes
  182. # [03:41] <Hixie> so i can count "incorrect", "redundant" and "interesting"
  183. # [03:41] * Joins: jgraham (n=jgraham@81-86-213-130.dsl.pipex.com)
  184. # [03:45] * Quits: zcorpan_ (n=zcorpan@84-216-42-249.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  185. # [03:57] <Lachy> Hixie, that low quality and high quality conformance idea you had gives a possible solution to the requirement of alt="". Make it required in high quality, optional, but recommended, in low quality
  186. # [03:59] <Lachy> and probably call them Strict and Loose conformance
  187. # [04:00] * Joins: weinig (i=weinig@nat/apple/x-d14fb9a166164745)
  188. # [04:02] * Joins: h3h (n=w3rd@cpe-70-95-195-36.san.res.rr.com)
  189. # [04:05] * Quits: aroben_ (n=adamrobe@17.203.15.248)
  190. # [04:37] <Hixie> Lachy: the names were carefuly chosen (and a big part of the proposal)
  191. # [04:37] <Lachy> ok
  192. # [04:50] * Quits: dbaron (n=dbaron@corp-242.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  193. # [05:03] * Joins: jcgregorio (n=chatzill@adsl-072-148-043-048.sip.rmo.bellsouth.net)
  194. # [05:15] * Quits: jgraham (n=jgraham@81-86-213-130.dsl.pipex.com) (Read error: 110 (Connection timed out))
  195. # [05:34] * Joins: tantek_ (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  196. # [05:38] * Quits: h3h (n=w3rd@cpe-70-95-195-36.san.res.rr.com)
  197. # [05:46] * Joins: wakaba (n=w@118.166.210.220.dy.bbexcite.jp)
  198. # [05:53] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net) (Read error: 110 (Connection timed out))
  199. # [06:05] * Quits: wakaba_ (n=w@118.166.210.220.dy.bbexcite.jp) (Read error: 110 (Connection timed out))
  200. # [06:14] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  201. # [06:15] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Remote closed the connection)
  202. # [06:16] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  203. # [06:38] <Lachy> I just realised that selectors api doesn't define a feature string for hasFeature(), while most (if not all) other DOM related specs do. I'm not sure if it matters though.
  204. # [06:39] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  205. # [06:46] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  206. # [06:52] * Joins: kfish (n=conrad@61.194.21.25)
  207. # [06:55] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  208. # [06:56] * Quits: tantek_ (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net) (Read error: 110 (Connection timed out))
  209. # [06:59] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca) ("http:/www.csarven.ca")
  210. # [07:07] * Joins: tantek_ (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  211. # [07:12] * Quits: tantek_ (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net) (Read error: 104 (Connection reset by peer))
  212. # [07:13] * Joins: tantek_ (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  213. # [07:17] * Joins: gavin_ (n=gavin@people.mozilla.com)
  214. # [07:19] * Quits: kfish (n=conrad@61.194.21.25) (kubrick.freenode.net irc.freenode.net)
  215. # [07:19] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net) (kubrick.freenode.net irc.freenode.net)
  216. # [07:19] * Quits: yod (n=ot@softbank221018155222.bbtec.net) (kubrick.freenode.net irc.freenode.net)
  217. # [07:19] * Quits: gavin__ (n=gavin@people.mozilla.com) (kubrick.freenode.net irc.freenode.net)
  218. # [07:19] * Quits: hober (n=ted@unaffiliated/hober) (kubrick.freenode.net irc.freenode.net)
  219. # [07:19] * Quits: deltab (n=deltab@82-36-30-34.cable.ubr02.smal.blueyonder.co.uk) (kubrick.freenode.net irc.freenode.net)
  220. # [07:19] * Quits: Toolskyn (i=toolskyn@amy.bdick.de) (kubrick.freenode.net irc.freenode.net)
  221. # [07:25] * Joins: yod (n=ot@softbank221018155222.bbtec.net)
  222. # [07:27] <Hixie> Lachy: see the whatwg spec for commentary on how useless that feature is :-)
  223. # [07:28] <Lachy> I know it's useless in JS, that's why I'm not rushing to add it.
  224. # [07:28] <Lachy> but I notice you include it for HTML5 and also XBL
  225. # [07:29] * Joins: Toolskyn (i=toolskyn@amy.bdick.de)
  226. # [07:30] <othermaciej> hasFeature sucks
  227. # [07:30] <othermaciej> Selectors API is best tested for by property testing, at least in JS
  228. # [07:31] <othermaciej> but maybe less dynamic languages like Java don't have that luxury
  229. # [07:31] <Lachy> othermaciej: yeah, that's what I was wondering in #webapi
  230. # [07:32] * Joins: kfish (n=conrad@61.194.21.25)
  231. # [07:32] * Joins: gavin__ (n=gavin@people.mozilla.com)
  232. # [07:32] * Joins: hober (n=ted@unaffiliated/hober)
  233. # [07:32] * Joins: deltab (n=deltab@82-36-30-34.cable.ubr02.smal.blueyonder.co.uk)
  234. # [07:32] * Quits: hober (n=ted@unaffiliated/hober) (Success)
  235. # [07:32] * Quits: deltab (n=deltab@82-36-30-34.cable.ubr02.smal.blueyonder.co.uk) (Success)
  236. # [07:32] * Joins: deltab_ (n=deltab@82-36-30-34.cable.ubr02.smal.blueyonder.co.uk)
  237. # [07:33] * Joins: fishkandy (n=conrad@61.194.21.25)
  238. # [07:33] * Quits: gavin__ (n=gavin@people.mozilla.com) (Read error: 104 (Connection reset by peer))
  239. # [07:36] * Joins: h3h (n=w3rd@cpe-70-95-195-36.san.res.rr.com)
  240. # [07:36] * Quits: kfish (n=conrad@61.194.21.25) (No route to host)
  241. # [07:37] * Quits: tantek_ (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net) (Read error: 110 (Connection timed out))
  242. # [08:03] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Remote closed the connection)
  243. # [08:03] * Quits: h3h (n=w3rd@cpe-70-95-195-36.san.res.rr.com)
  244. # [08:03] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  245. # [08:23] * Joins: webben (n=benh@91.84.143.253)
  246. # [08:23] <Lachy> for those of you who don't know yet, http://lachy.id.au/log/2007/06/opera :-)
  247. # [08:26] <fishkandy> Lachy, onya
  248. # [08:48] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  249. # [08:51] * Quits: duryodhan (n=chatzill@221.128.138.202) (Read error: 110 (Connection timed out))
  250. # [08:52] * Joins: duryodhan (n=chatzill@221.128.139.13)
  251. # [08:53] * Quits: weinig (i=weinig@nat/apple/x-d14fb9a166164745)
  252. # [08:54] * Quits: dolphinling (n=chatzill@rbpool4-59.shoreham.net) (Read error: 110 (Connection timed out))
  253. # [08:56] * Joins: dolphinling (n=chatzill@rbpool1-86.shoreham.net)
  254. # [08:58] * Joins: tndH (i=Rob@adsl-87-102-84-66.karoo.KCOM.COM)
  255. # [09:13] <jruderman> Lachy: what percentage of opera's new hires for the oslo office have to move from another country?
  256. # [09:19] <Lachy> jruderman: I have no idea
  257. # [09:20] <jruderman> Lachy: just wondering since i keep hearing about people moving to norway to work for opera
  258. # [09:20] <othermaciej> well, it's not like the world's top web experts already live in norway
  259. # [09:21] <Lachy> I've been told there's people from 41 different nationalities working there
  260. # [09:21] <jruderman> haha both apple and opera love The New York Times as an example site to show on a mobile phone
  261. # [09:22] <othermaciej> you should see how most phone browsers render it :-)
  262. # [09:24] <jruderman> hehe
  263. # [09:25] <jruderman> what do opera and safari do with simple fixed-width pages? do you have to scroll left and right as you read each line of a paragraph?
  264. # [09:25] <jruderman> (on phones)
  265. # [09:25] <othermaciej> in Mobile Safari you can pinch-zoom, pan, and double-tap to zeem a block of text to fit
  266. # [09:25] <othermaciej> *zoom
  267. # [09:25] <othermaciej> dunno what Opera does
  268. # [09:25] <othermaciej> I hate fixed-width pages
  269. # [09:26] <othermaciej> even on the desktop
  270. # [09:26] <Lachy> Opera has small screen rendering, which you can simulate in the desktop browser
  271. # [09:26] <jruderman> i don't want to zoom to fit the width of the block if that means each letter is 4px..
  272. # [09:27] <Lachy> I thinkthere's a video that demonstrates the web browser somewhere on the apple site
  273. # [09:27] <jruderman> they always demo with the new york times
  274. # [09:27] <jruderman> or google
  275. # [09:28] <othermaciej> jruderman: you'll have to try one or get someone to demo if you want to see
  276. # [09:29] <othermaciej> jruderman: could probably expense it for "competitive analysis"
  277. # [09:30] <Lachy> hmm. the apple site says the video is 175MB to download. It's actually 318MB http://www.apple.com/iphone/usingiphone/guidedtour.html
  278. # [09:31] * Quits: karlUshi (n=karl@dhcp-247-173.mag.keio.ac.jp) ("Where dwelt Ymir, or wherein did he find sustenance?")
  279. # [09:33] * Joins: Jero (n=Jero@d207230.upc-d.chello.nl)
  280. # [09:34] * Joins: weinig (n=weinig@c-67-188-89-242.hsd1.ca.comcast.net)
  281. # [09:36] * Quits: weinig (n=weinig@c-67-188-89-242.hsd1.ca.comcast.net) (Remote closed the connection)
  282. # [09:37] * Joins: weinig (n=weinig@c-67-188-89-242.hsd1.ca.comcast.net)
  283. # [09:51] * Quits: othermaciej (n=mjs@17.255.100.184)
  284. # [10:02] * Joins: zcorpan_ (n=zcorpan@84-216-42-220.sprayadsl.telenor.se)
  285. # [10:10] * Joins: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com)
  286. # [10:19] * Joins: annevk (n=annevk@pat-tdc.opera.com)
  287. # [10:25] * Quits: webben (n=benh@91.84.143.253) (Read error: 110 (Connection timed out))
  288. # [10:34] <zcorpan_> Lachy: only the five entities are expanded in xml-stylesheet pseudo-attributes per ASS
  289. # [10:35] <Lachy> yeah, I only expected the 5 predefined entities to be expanded
  290. # [10:35] <Lachy> but is that true even if there's a doctype with an internal subset?
  291. # [10:36] <Fuzzy76> Lachy: Congratulations on your new job :)
  292. # [10:36] <Lachy> thanks
  293. # [10:36] <zcorpan_> Lachy: yes
  294. # [10:36] <Lachy> is that a browser limitation, or per spec?
  295. # [10:36] <zcorpan_> spec
  296. # [10:36] <Lachy> ok
  297. # [10:37] * Joins: polin8 (n=brian@ool-18b8cc06.dyn.optonline.net)
  298. # [10:37] <zcorpan_> haven't tested throughly what browsers do, just did one basic test (with the NCR) and found that firefox and opera did different things
  299. # [10:38] * Quits: weinig (n=weinig@c-67-188-89-242.hsd1.ca.comcast.net)
  300. # [10:38] <zcorpan_> i might try to get the spec updated too... it's not sane and leaves things undefined
  301. # [10:41] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  302. # [10:42] * Joins: ROBOd (n=robod@86.34.246.154)
  303. # [10:44] * Quits: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com) (Client Quit)
  304. # [10:44] <Lachy> I have to write a 40 minute presentation on HTML5 before the 20th, and I'll be away from the 7th to the 15th.
  305. # [10:44] <hsivonen> Lachy: congrats on the job
  306. # [10:44] <Lachy> thanks
  307. # [10:46] <Lachy> ... and I'll be working on the XBL primer on the 4th and 5th. I am really going to struggle to find the time :-/
  308. # [10:46] * Joins: webben (n=benh@91.84.143.253)
  309. # [10:49] * Quits: polin8 (n=brian@ool-18b8cc06.dyn.optonline.net)
  310. # [10:49] <hsivonen> Hixie: Re: survey on longdesc: you should probably dereference the URI and check the content type of what is found
  311. # [10:49] <hsivonen> Hixie: considering the bogosity of longdesc pointing to an image
  312. # [10:51] <zcorpan_> hsivonen: could perhaps be checked by checking if it's the same as src=""? (there already is a check for same as parent <a href>)
  313. # [10:52] <zcorpan_> hmm. <!doctype html public ">">
  314. # [10:52] <zcorpan_> all browsers terminate the doctype at the first >
  315. # [10:55] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  316. # [10:57] <annevk> that'd be easy to fix in the spec
  317. # [10:57] <zcorpan_> yeah
  318. # [11:02] <annevk> "Clarify who is in charge of dropping BOMs. Hint: it's not the air force." :)
  319. # [11:03] * Quits: yod (n=ot@softbank221018155222.bbtec.net) ("Leaving")
  320. # [11:04] <hsivonen> are 512 byte boundary charset meta tests available as individual files somewhere?
  321. # [11:05] * Joins: met_ (n=Hassman@b14-4.vscht.cz)
  322. # [11:05] * Joins: BenWard (i=BenWard@nat/yahoo/x-2ec7962cae63c345)
  323. # [11:05] <hsivonen> extra points if there are tests where a broken UTF-8 bytes requence lies across the 512 byte boundary
  324. # [11:05] <hsivonen> byte sequence even
  325. # [11:06] <zcorpan_> hsivonen: i think Hixie has some tests on that
  326. # [11:06] <Hixie> hsivonen: i can't, i have no network in this environment
  327. # [11:06] * Quits: webben (n=benh@91.84.143.253) (Read error: 110 (Connection timed out))
  328. # [11:06] <hsivonen> Hixie: ok. not even metadata from Google cache?
  329. # [11:07] <annevk> http://hixie.ch/tests/adhoc/html/parsing/encoding/ has some tests
  330. # [11:08] <hsivonen> annevk: ok. I'll see if some of those are what I'm looking for
  331. # [11:10] <Hixie> hsivonen: not with the way i'm doing it
  332. # [11:10] <hsivonen> Hixie: ok
  333. # [11:11] <Hixie> when you start trying to do scans of billions of documents, things like looking up information in a database becoomes unscalable
  334. # [11:13] <hsivonen> I wonder if ia_archiver searches the Web depth first, breadth first or something else
  335. # [11:13] <hsivonen> for surveys you want to do breadth first, right, to diversify results given finite time?
  336. # [11:14] <Hixie> almost certainly (c), since when you run a spider of that scale you have to take into account rate of retrieval per-server
  337. # [11:15] <annevk> how about collecting the set of referenced docs and checking those later?
  338. # [11:15] <Hixie> annevk: re Jirka's "Parse errors are allowed to be corrected by parser:
  339. # [11:15] <hsivonen> it would be interesting to hook up my Java parser (once ready) to the IA crawler so that people outside google with reasonable CPU and network could do smallish surveys
  340. # [11:15] <Hixie> "
  341. # [11:15] <Hixie> annevk: HTML4 allowed it too
  342. # [11:15] <zcorpan_> <!doctypehtmlpublic"x">
  343. # [11:16] <annevk> Hixie, yeah, I don't think I'm going to bother though
  344. # [11:16] <zcorpan_> ...has the name "HTML" and the FPI "x" in firefox
  345. # [11:16] <Hixie> zcorpan_: has the name "htmlpublic"a"" in the spec
  346. # [11:16] <zcorpan_> yeah
  347. # [11:17] <hsivonen> I wonder if any of the people who volunteered to survey the top sites are interested if getting the framework ready if I give an API spec for using the conformance checker development version
  348. # [11:17] <Hixie> bed time
  349. # [11:17] <Hixie> nn
  350. # [11:17] <annevk> night
  351. # [11:17] <zcorpan_> nn
  352. # [11:24] <hsivonen> ok. Hixie's tests 044, 045 and 046 are what I wanted
  353. # [11:26] <zcorpan_> ha! <!doctype html public "x>"> triggers standards mode in firefox (yet renders the "> characters in body), but <!doctype html public "x> triggers quirks mode
  354. # [11:26] <annevk> that shows the preparsing I guess
  355. # [11:26] <zcorpan_> yeah
  356. # [11:30] <hsivonen> w00t! Passed the tests on the first try after implementing something as complex as doing the buffering trickery around the 512 byte boundary
  357. # [11:30] <zcorpan_> hsivonen: nice :)
  358. # [11:34] <zcorpan_> hsivonen: why would you drop them on the floor?
  359. # [11:35] <hsivonen> zcorpan_: depends on whether you want to report null or a string that has prematurely ended
  360. # [11:35] <hsivonen> zcorpan_: on the face of it, reporting null makes sense if the string wasn't properly terminated
  361. # [11:36] <hsivonen> I now got the IBM UTF-8 decoder loaded instead of the Sun version. and now my code crashes
  362. # [11:36] <hsivonen> I wonder why
  363. # [11:37] <zcorpan_> hsivonen: well, the doctype's correctness flag is set to incorrect anyway...
  364. # [11:38] <hsivonen> Aargh. the IBM decoder does really wrong things when reporting UTF-8 errors
  365. # [11:42] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  366. # [11:45] * deltab_ is now known as deltab
  367. # [11:46] <zcorpan_> oops
  368. # [11:47] <zcorpan_> ie doesn't terminate at > in FPI
  369. # [11:47] <zcorpan_> or in quotes anywhere
  370. # [11:47] * Joins: webben (i=benh@nat/yahoo/x-3eba70ebadb21b4c)
  371. # [11:47] <annevk> anywhere?
  372. # [11:47] <annevk> <! ">"?
  373. # [11:47] <annevk> <!-- "-->" --> ?
  374. # [11:47] <zcorpan_> those are not doctypes
  375. # [11:48] <annevk> no kididng
  376. # [11:48] <zcorpan_> but seems to apply to <! ">" >
  377. # [11:48] <zcorpan_> not <!-- "-->" -->
  378. # [11:49] <zcorpan_> applies to <? ">" > and </ ">" > too
  379. # [11:50] <zcorpan_> <^_^>
  380. # [11:50] <annevk> fancy
  381. # [11:50] <annevk> seems like IE has the same handling for all of those
  382. # [11:50] <annevk> as it doesn't really support DOCTYPEs
  383. # [11:51] <zcorpan_> indeed
  384. # [11:53] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  385. # [11:58] * Joins: hendry (n=hendry@91.84.62.62)
  386. # [11:59] <hsivonen> I wonder if Java 6 fixes the UTF-8 decoder holes
  387. # [11:59] <hsivonen> anyway, as of Java 5, both the JDK and ICU4J are b0rked
  388. # [12:12] * Joins: the_mart (n=Martin@host86-135-9-158.range86-135.btcentralplus.com)
  389. # [12:17] * Joins: peepo (n=Jay@86.157.113.34)
  390. # [12:17] * Quits: webben (i=benh@nat/yahoo/x-3eba70ebadb21b4c) (Read error: 110 (Connection timed out))
  391. # [12:20] * Quits: fishkandy (n=conrad@61.194.21.25) ("pike!")
  392. # [12:40] * othermaciej is now known as om_sleep
  393. # [12:56] <annevk> I wonder if the new encoding sniffer works for <meta> 512 bytes <meta> 512 bytes <meta> ...
  394. # [12:57] * Quits: jcgregorio (n=chatzill@adsl-072-148-043-048.sip.rmo.bellsouth.net) ("ChatZilla 0.9.78.1 [Firefox 2.0.0.4/2007060115]")
  395. # [13:00] <hsivonen> annevk: "the new"?
  396. # [13:02] <annevk> the one that works together with the parser
  397. # [13:02] <annevk> and has this confident flag
  398. # [13:02] <hsivonen> annevk: is there a spec change?
  399. # [13:02] <hsivonen> annevk: or is this about html5lib?
  400. # [13:02] <annevk> there was a spec change
  401. # [13:03] <annevk> r955
  402. # [13:06] <hsivonen> what? did Hixie remove the magic 512 boundary?
  403. # [13:06] <hsivonen> just when I got it working
  404. # [13:07] <annevk> I think that boundary is still there for authors
  405. # [13:08] <annevk> actually
  406. # [13:08] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Leaving")
  407. # [13:10] <annevk> i think he did
  408. # [13:10] * hsivonen is rather miffed
  409. # [13:11] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  410. # [13:15] <zcorpan_> hsivonen: you can perhaps use the code to emit a warning, suggesting that encoding declarations should be as early as possible in the source to improve perf (and interop?)
  411. # [13:16] <hsivonen> perhaps
  412. # [13:16] <hsivonen> I'm going to stop chasing encoding and tokenization spec changes for a while
  413. # [13:17] <hsivonen> I'd love to see a realistic spec on how much data to feed to chardet
  414. # [13:18] <hsivonen> that is, should I buffer the entire stream or n first bytes
  415. # [13:19] <annevk> i think guessing 512 bytes is reasonable
  416. # [13:19] <annevk> if you then later encounter a different encoding you'd have to switch
  417. # [13:20] <hsivonen> annevk: Gecko seems to run chardet on the first buffer the html parser gets from the channel but I have no idea how big that buffer is
  418. # [13:21] * hsivonen hopes someone else finds out so that I don't need to find out using a debugger
  419. # [13:21] <hsivonen> what does IE do?
  420. # [13:21] <hsivonen> will a future WebKit use the ICU detector once it is ported to C?
  421. # [13:33] <zcorpan_> so the spec allows first a preparse, then a real parse, and then a real parse again if the first real parse found conflicting encoding information?
  422. # [13:35] <zcorpan_> e.g. <style><meta charset=utf-8></style><meta charset=windows-1252>
  423. # [13:36] <annevk> it seems to allow only a single preparse (optional) and only a single reparse
  424. # [13:36] <hsivonen> zcorpan_: but is the first "real" parse running scripts?
  425. # [13:39] <hsivonen> I don't trust that the current spec is the last word on this topic
  426. # [13:39] * Quits: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp) ("Less talk, more pimp walk.")
  427. # [13:40] <zcorpan_> why is the preparse specced at all, if it yealds the same result as not preparsing (modulo perf)?
  428. # [13:40] <hsivonen> It would be nice if the people in charge of the relevant code in Trident, Gecko, WebKit and Presto just disclosed what exactly it is they do and what they want to do
  429. # [13:42] <zcorpan_> or wait, it doesn't yeald the same result. not preparsing doesn't catch encoding declarations in cdata elements
  430. # [13:42] <zcorpan_> so if it's optional and different how can we achieve interop?
  431. # [13:43] * hsivonen would be interested in learning Hixie's thinking here
  432. # [13:44] <hsivonen> where does svn keep passwords? does the working copy have any private data?
  433. # [13:46] <Philip`> If you checked out from a http://name:password@... then it'll store that in .svn/entries, which (I've found) becomes annoying when you don't notice
  434. # [13:47] <Philip`> If you don't do that, I think it's up to the SVN client how it asks you for passwords or remembers the previous entries, and it shouldn't store that in the working copy anywhere
  435. # [13:48] <Philip`> (No idea where it does store it, though)
  436. # [13:48] <annevk> can you make it store it?
  437. # [13:48] <hsivonen> Philip`: thanks
  438. # [13:49] <hsivonen> I guess I'll sanitize the svn-specific directories then
  439. # [13:49] <Philip`> I guess it also depends if it's http:// vs svn+ssh://, since the SVN client will log in in different ways and would differ on whether/how it saves passwords
  440. # [13:50] <hsivonen> the Java http://java.sun.com/j2se/1.4.2/docs/api/java/io/InputStream.html#mark(int) contract doesn't allow saying that the mark should never become invalid...
  441. # [13:50] <hsivonen> which totally sucks considering arbitrary rewinding
  442. # [13:50] <Philip`> 'svn export' seems to be a convenient way of removing the .svn directories
  443. # [13:51] <hsivonen> OTOH, if the underlying stream *does* support arbitrary rewinding, implementing my own is bad for perf
  444. # [13:52] <hsivonen> do browsers act on a meta charset even if there's a <body> first?
  445. # [13:57] * Joins: maikmerten (n=maikmert@Lb626.l.pppool.de)
  446. # [13:58] * Quits: peepo (n=Jay@86.157.113.34) ("later")
  447. # [13:59] * Joins: polin8 (n=brian@time.digitalpulp.com)
  448. # [14:15] * Quits: polin8 (n=brian@time.digitalpulp.com) (":wq")
  449. # [14:31] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  450. # [15:06] <hsivonen> zcorpan_: one thing you could test is putting upper or lower case Turkish i in various places where the spec requires a literal string that contains an i
  451. # [15:07] <hsivonen> zcorpan_: Opera has a history of making comparisons where the Turkish i equals an ASCII i
  452. # [15:09] * Quits: bewest (n=ben@httpcraft/bewest) (Read error: 110 (Connection timed out))
  453. # [15:16] <zcorpan_> hsivonen: ok. thanks
  454. # [15:19] <zcorpan_> U+0130 (İ) and U+0131 (ı)
  455. # [15:33] * Joins: BenneWarde (i=BenWard@nat/yahoo/x-c56be86fd6f231d8)
  456. # [15:33] * Joins: jcgregorio (i=chatzill@nat/ibm/x-488effaae3a1855a)
  457. # [15:48] * Quits: BenWard (i=BenWard@nat/yahoo/x-2ec7962cae63c345) (Read error: 113 (No route to host))
  458. # [16:17] * Quits: jcgregorio (i=chatzill@nat/ibm/x-488effaae3a1855a) ("ChatZilla 0.9.78.1 [Firefox 2.0.0.4/2007060115]")
  459. # [16:22] * Joins: h3h (n=w3rd@cpe-70-95-195-36.san.res.rr.com)
  460. # [16:24] * Joins: ROBOd (n=robod@86.34.246.154)
  461. # [16:25] * Quits: h3h (n=w3rd@cpe-70-95-195-36.san.res.rr.com) (Client Quit)
  462. # [16:25] * Joins: billmason (n=billmaso@ip156.unival.com)
  463. # [16:34] * Parts: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl)
  464. # [16:43] * Quits: maikmerten (n=maikmert@Lb626.l.pppool.de) (Read error: 113 (No route to host))
  465. # [16:44] * Joins: maikmerten (n=maikmert@T77eb.t.pppool.de)
  466. # [16:45] * Joins: MikeSmith (n=MikeSmit@p62059-adsau18honb3-acca.tokyo.ocn.ne.jp)
  467. # [17:02] <zcorpan_> why is Node.localName uppercased?
  468. # [17:04] <annevk> because there are people relying on it I guess?
  469. # [17:04] <zcorpan_> hmm... wouldn't think so
  470. # [17:05] <annevk> because it returns undefined in IE?
  471. # [17:06] <zcorpan_> yeah. and if you use .localName you probably also check .namespaceURI or so. and i wouldn't expect it to be uppercased
  472. # [17:08] <annevk> it would be nice if there was a canonical property available
  473. # [17:08] <zcorpan_> you might do something like if ((elm.tagName == "A" && !elm.namespaceURI) || (elm.localName == "a" && elm.namespaceURI == "http://www.w3.org/1999/xhtml"))
  474. # [17:09] <zcorpan_> where the former is for legacy HTML UA and the second is for HTML5 UA and for XHTML
  475. # [17:13] * Joins: h3h (n=w3rd@66-162-32-234.static.twtelecom.net)
  476. # [17:17] * Joins: weinig (i=weinig@nat/apple/x-056bb4db4e065e17)
  477. # [17:19] <annevk> hmm, document.createElementNS("A", xhtmlNS) is interesting
  478. # [17:19] <annevk> it will claim "a" yet not implement HTMLAnchorElement
  479. # [17:20] <zcorpan_> createElementNS is case-changing? in what impl?
  480. # [17:20] <annevk> the English prose of HTML5?
  481. # [17:20] <annevk> for HTML Elements (elements in the XHTML namespace) in HTML documents .tagName etc. will return lowercase
  482. # [17:21] <annevk> however, document.createElementNS will not have its first argument lowercased
  483. # [17:21] <annevk> which gives you the aforementioned edge case
  484. # [17:21] <zcorpan_> ah. ok. then createElementNS isn't case-changing (and html5 doesn't say it is)
  485. # [17:23] <zcorpan_> .tagName will return uppercase btw
  486. # [17:28] * Quits: met_ (n=Hassman@b14-4.vscht.cz) ("Chemists never die, they just stop reacting.")
  487. # [17:35] <hsivonen> zcorpan_: +1 on localName returning lower case in text/html DOM
  488. # [17:37] * Parts: zcorpan_ (n=zcorpan@84-216-42-220.sprayadsl.telenor.se)
  489. # [17:51] * Joins: briansuda (n=briansud@85-220-95-76.dsl.dynamic.simnet.is)
  490. # [17:56] * Quits: tndH (i=Rob@adsl-87-102-84-66.karoo.KCOM.COM) (Read error: 104 (Connection reset by peer))
  491. # [17:57] * Joins: tndH (i=Rob@adsl-87-102-89-234.karoo.KCOM.COM)
  492. # [17:58] <duryodhan> isn't drawWindow part of the HTML5 specs?
  493. # [17:58] <duryodhan> (canvas)
  494. # [17:58] <annevk> no
  495. # [18:01] * Joins: zcorpan_ (n=zcorpan@84-216-42-220.sprayadsl.telenor.se)
  496. # [18:03] <duryodhan> so is it supported only by mozilla firefox?
  497. # [18:03] <duryodhan> or by opera/safari ?
  498. # [18:04] <annevk> I believe only by Firefox
  499. # [18:04] <annevk> and only for priveleged JavaScript
  500. # [18:06] * Quits: BenneWarde (i=BenWard@nat/yahoo/x-c56be86fd6f231d8) ("Fades out again…")
  501. # [18:08] * Quits: zcorpan_ (n=zcorpan@84-216-42-220.sprayadsl.telenor.se) (kubrick.freenode.net irc.freenode.net)
  502. # [18:08] * Quits: briansuda (n=briansud@85-220-95-76.dsl.dynamic.simnet.is) (kubrick.freenode.net irc.freenode.net)
  503. # [18:08] * Quits: maikmerten (n=maikmert@T77eb.t.pppool.de) (kubrick.freenode.net irc.freenode.net)
  504. # [18:08] * Quits: billmason (n=billmaso@ip156.unival.com) (kubrick.freenode.net irc.freenode.net)
  505. # [18:08] * Quits: Lfe (n=lfe@bergstroem.nu) (kubrick.freenode.net irc.freenode.net)
  506. # [18:12] * Quits: MikeSmith (n=MikeSmit@p62059-adsau18honb3-acca.tokyo.ocn.ne.jp) (Read error: 110 (Connection timed out))
  507. # [18:14] * Joins: tndH_ (i=Rob@adsl-87-102-89-234.karoo.KCOM.COM)
  508. # [18:15] <Philip`> duryodhan: Yep, it's Firefox-only (so it really should be in a getContext('moz-2d') or something, though it isn't, which is perhaps annoying if the spec added something like drawWindow (e.g. to handle the text-drawing issue) with different semantics)
  509. # [18:16] <duryodhan> text-drawing issue?
  510. # [18:17] <Philip`> You can't (currently) draw text onto the canvas easily, and I think one proposed solution was to have something like drawWindow so you could set up an HTML element with CSS formatting and everything, and stick text into that and then draw it onto the canvas
  511. # [18:19] <duryodhan> hmm ... then might as well implement the moz drawWindow ...
  512. # [18:21] <Philip`> Hmm, I guess it would have to be more like drawElement rather than drawWindow
  513. # [18:22] <Philip`> (or just another drawImage overload)
  514. # [18:23] <Philip`> since drawing whole windows is a fairly limited functionality (unless you're very careful and cut out precisely the section surrounding the element you want), so maybe it doesn't matter that they stole the drawWindow name already
  515. # [18:25] <duryodhan> the problem with drawElement would be ... it is painful to know where the element is exactly ...
  516. # [18:25] <duryodhan> mean to say a form ...
  517. # [18:25] <duryodhan> one could start off a form anywhere and end it anywhere ...
  518. # [18:26] <duryodhan> the code for some buttons might be in between the <form > and </form>
  519. # [18:26] <duryodhan> but the button may be in some god forsaken place ...
  520. # [18:28] <Philip`> The form element is always defining a subtree in the DOM, so you can just do drawElement(getElementById('some-form'), 200, 100, 0, 0) and the browser can work out how to render that piece of the document (with all its contained elements, and affected by stylesheets) in a 200x100 container with a transparent background, then paint it onto the canvas at posiion 0,0, perhaps
  521. # [18:29] <Philip`> s/ii/iti/
  522. # [18:30] * Quits: tndH (i=Rob@adsl-87-102-89-234.karoo.KCOM.COM) (Read error: 113 (No route to host))
  523. # [18:32] <duryodhan> so it will basically draw so that everything in between <form> </form> is rendered?
  524. # [18:34] * Joins: briansuda (n=briansud@85-220-95-76.dsl.dynamic.simnet.is)
  525. # [18:35] <Philip`> Yep - kind of like extracting the whole <form>...</form> into a new clean document and rendering that, ignoring all the extra stuff from the original page (except probably keeping all the stylesheets that applied to that element (and its contents) from the original page). But maybe that's totally impossible to implement - I have no idea really :-)
  526. # [18:36] <duryodhan> yeah...
  527. # [18:36] <duryodhan> I was trying to do something like that in scripts ...
  528. # [18:36] <duryodhan> offsetLeft etc....
  529. # [18:37] <duryodhan> but I am pretty sure that the co-ords would be wrong for a weird form
  530. # [18:40] <Philip`> It does sound hard (/impossible) in general to work out what rectangle on the page corresponds to a certain element, particularly if there's stylesheets moving everything around
  531. # [18:41] <Philip`> and perhaps that would be simplified by just defining the rectangle first, and then telling the content to draw itself inside there (the same as what happens when drawing stuff into the screen rectangle, except directly onto the canvas rather than the screen)
  532. # [18:44] <duryodhan> I don't think I understand ... if the content is drawn into the canvas .. user can
  533. # [18:44] <duryodhan> 't interface with it
  534. # [18:47] <Philip`> Why would you want an interactive form in the canvas, rather than just drawn as normal HTML?
  535. # [18:53] <duryodhan> I mean to ask .... why would you directly write to canvas?
  536. # [18:53] <duryodhan> instead of writing to HTML ?
  537. # [18:53] <duryodhan> I dont know what I am talking
  538. # [18:53] <duryodhan> :)
  539. # [18:57] <Philip`> Oh, as in why would you draw the element as a new separate thingy onto the canvas, rather than cutting out an existing part of the rendered HTML page?
  540. # [18:57] <Philip`> Probably the main reason is that you'd want to draw things without them being part of the HTML page
  541. # [18:58] <Philip`> like drawElement(document.createTextNode('Hello world')) or something
  542. # [18:58] <Philip`> else you'd end up with loads of rubbish stuck all over your page, when you only ever wanted to draw it into the canvas
  543. # [19:02] * Joins: billmason (n=billmaso@ip156.unival.com)
  544. # [19:02] * Joins: maikmerten (n=maikmert@T77eb.t.pppool.de)
  545. # [19:06] <duryodhan> yeah.. I am still stuck with the notion of drawing stuff already existing on the page ....i.e clicking a snap ...
  546. # [19:06] * duryodhan is a little confused and talking through his hat
  547. # [19:06] * Philip` doesn't really know about the actual technical details about how any of this could work
  548. # [19:07] <duryodhan> hehe
  549. # [19:07] <duryodhan> two ppl who don't know anything ... discussing stuff ...
  550. # [19:08] <Hixie> hsivonen: the current spec on encoding was what it is now before you asked me if i was going to make any more changes, and the changes were made in response to your e-mail
  551. # [19:24] * Joins: aroben (n=adamrobe@17.255.96.162)
  552. # [19:25] * Joins: aroben_ (n=adamrobe@17.203.15.248)
  553. # [19:29] * Quits: YaaL (i=yaal@hell.pl) (Read error: 110 (Connection timed out))
  554. # [19:34] * Joins: hober (n=ted@unaffiliated/hober)
  555. # [19:37] * Quits: aroben (n=adamrobe@17.255.96.162) (Nick collision from services.)
  556. # [19:37] * Quits: aroben_ (n=adamrobe@17.203.15.248) (Remote closed the connection)
  557. # [19:37] * Joins: aroben (n=adamrobe@17.203.15.248)
  558. # [19:37] <Hixie> annevk: there are people discussing XHR in the whatwg list
  559. # [19:42] * Joins: met_ (n=Hassman@r5bx220.net.upc.cz)
  560. # [19:51] * Joins: YaaL (i=yaal@hell.pl)
  561. # [20:02] * Joins: kingryan (n=kingryan@corp.technorati.com)
  562. # [20:08] <met_> http://www.0x000000.com/?i=365
  563. # [20:12] * Joins: zcorpan_ (n=zcorpan@84-216-42-220.sprayadsl.telenor.se)
  564. # [20:37] <gsnedders> how do browsers deal with LF separated HTTP headers?
  565. # [20:42] * Quits: the_mart (n=Martin@host86-135-9-158.range86-135.btcentralplus.com) ("Leaving")
  566. # [20:58] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Leaving")
  567. # [21:00] <hsivonen> Hixie: yeah, that email was from the time when I thought that a single pass over the document and changing decoders on the fly was feasible. :-(
  568. # [21:11] * Quits: aroben (n=adamrobe@17.203.15.248)
  569. # [21:12] * Joins: tantek_ (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  570. # [21:14] * Quits: maikmerten (n=maikmert@T77eb.t.pppool.de) ("Leaving")
  571. # [21:17] <Hixie> hsivonen: i think what the spec does now is pretty much what is required for web compat. note that the 512 byte thing isn't wasted, it's actually still there it's just that you get to pick the number (and it can be zero or the whole file)
  572. # [21:17] <Hixie> (or anywhere in between, including 512)
  573. # [21:18] <hsivonen> Hixie: ok. I'll cool down a bit and implement the tree builder spec
  574. # [21:18] <Hixie> heh
  575. # [21:18] <hsivonen> (obviously, I should have paid closer attention to the sniffing section. I was tracking the changes to tokenization)
  576. # [21:19] <Hixie> well my point is there weren't really any changes
  577. # [21:19] <Hixie> just additions
  578. # [21:19] <Hixie> i don't think it should have made any code you wrote obsolete
  579. # [21:20] <hsivonen> Hixie: I think the main issue is if we can get browsers to agree how many bytes to examine. if not, everyone will have to scan the entire file or risk incompatibility with someone else
  580. # [21:20] <Hixie> no the current system is that you scan as many bytes as you like, and then do the real parser, and if the real parser finds a conflicting encoding, you start over using that instead.
  581. # [21:20] <Hixie> which is what browsers do, basically
  582. # [21:20] <Hixie> it makes the prescan optional for interop, effectively
  583. # [21:21] <Hixie> gotta go, lunch, brt
  584. # [21:21] <Hixie> bbl, rather
  585. # [21:21] <hsivonen> Hixie: another thing: since the sniffing can now proceed past the first 512 bytes, the perf penalty for not declaring the encoding is potentially serious.
  586. # [21:21] <hsivonen> Hixie: so it would make sense to encourage even the ASCII-only folk to declare
  587. # [21:22] <hsivonen> Hixie: also, always making the undeclared case non-conforming helps sanity checking CMSs even if it is a tad drastic for individual docs
  588. # [21:27] * Joins: BenWard (n=BenWard@cpc3-cmbg2-0-0-cust58.cmbg.cable.ntl.com)
  589. # [21:28] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net) (Read error: 110 (Connection timed out))
  590. # [21:28] * Quits: hendry (n=hendry@91.84.62.62) ("leaving")
  591. # [21:35] * Quits: BenWard (n=BenWard@cpc3-cmbg2-0-0-cust58.cmbg.cable.ntl.com)
  592. # [21:38] <Lachy> this is cool http://iphonetester.com/
  593. # [21:44] * om_sleep is now known as othermaciej
  594. # [21:52] * Joins: hasather (n=hasather@22.80-203-71.nextgentel.com)
  595. # [22:00] <hsivonen> are head and body the only node that get attributes appended to them after the initial insertion to the document?
  596. # [22:05] * Joins: aroben (n=adamrobe@17.203.15.248)
  597. # [22:08] * tantek_ is now known as tantek
  598. # [22:09] <mpt> annevk, "misnormers" is a misnomer
  599. # [22:09] * Quits: met_ (n=Hassman@r5bx220.net.upc.cz) ("Chemists never die, they just stop reacting.")
  600. # [22:14] <zcorpan_> hmmm... now that i test again, ie seems to skip past CDATA and RCDATA elements when looking for encoding declarations
  601. # [22:15] <zcorpan_> or it uses its real parser, with the content model flags
  602. # [22:23] <zcorpan_> the problem with the current spec is that the preparser can find things that the real parser doesn't
  603. # [22:24] <zcorpan_> also, safari, firefox and opera don't change their mind after they've found an encoding decl with the preparser
  604. # [22:25] <zcorpan_> afaict
  605. # [22:28] <zcorpan_> i.e., ie does what the spec says but preparses 0 bytes. the others do what the spec says but preparses the whole thing and sets the confidence flag to certain when it has found a meta charset
  606. # [22:30] * Joins: othermaciej_ (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  607. # [22:32] * Joins: bzed (n=bzed@dslb-084-059-110-122.pools.arcor-ip.net)
  608. # [22:32] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net) (Read error: 113 (No route to host))
  609. # [22:35] <zcorpan_> mpt: misspelled or wrongly used?
  610. # [22:36] <zcorpan_> (or both)
  611. # [22:36] <mpt> possibly both
  612. # [22:36] <mpt> The passive voice makes the statement unexplained, so it's difficult to tell
  613. # [22:38] * Quits: mpt (n=mpt@121-72-128-43.dsl.telstraclear.net) ("Leaving")
  614. # [22:39] * Joins: met_ (n=Hassman@r5bx220.net.upc.cz)
  615. # [22:39] <zcorpan_> iirc, the earlier draft said that results="" assumed a particular UI or something like that
  616. # [22:44] <Hixie> hsivonen: well, UAs are gonna have to work out what the right tradeoff is for the encoding detection (how long to prescan before just doing the heavy duty parse)
  617. # [22:45] <hsivonen> Hixie: what about interop?
  618. # [22:45] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  619. # [22:45] <Hixie> hsivonen: the preparse never sets a confident encoding
  620. # [22:45] <Hixie> hsivonen: you always verify the encoding with the real parser
  621. # [22:45] <hsivonen> oh
  622. # [22:46] <zcorpan_> Hixie: does the real parser undo tentative encoding information if it doesn't find any?
  623. # [22:46] <zcorpan_> Hixie: <style><meta charset=utf-8></style>
  624. # [22:47] <Hixie> ah, good point
  625. # [22:47] <Hixie> then again, it's already non-compliant to not have an encoding declaration if you're not using pure ascii
  626. # [22:48] <zcorpan_> being non-compliant doesn't make implementations interoperate ;)
  627. # [22:48] <hsivonen> Hixie: why isn't to not have an encoding declaration. Period.?
  628. # [22:49] <hsivonen> s/isn't to/isn't non-compliant to/
  629. # [22:49] <met_> Should html5 drag&drop model work across domains or only in the same domain? cannot find it in the spec
  630. # [22:51] <Hixie> hsivonen: because I don't want "<!DOCTYPE HTML><title>Hello</title><p>Hello" to be invalid.
  631. # [22:52] * Joins: mpt (n=mpt@121-72-128-43.dsl.telstraclear.net)
  632. # [22:52] <zcorpan_> Hixie: if we want encoding detection to be interoperable, then i think we either should go the ie route (use the real parser for the whole file to find encoding information) or the firefox/opera/safari route (use the pre-parser for the whole file to find encoding information)
  633. # [22:53] <Hixie> i do not believe that firefox uses the pre-parser over the whole file
  634. # [22:53] <Hixie> that would imply they don't do incremental parsing, which is demonstrably false.
  635. # [22:54] <zcorpan_> it finds encoding declarations inside <style>, and it doesn't change its mind later on with encoding declarations that the real parser would find
  636. # [22:54] <Hixie> yeah, i think they should fix that
  637. # [22:58] <hsivonen> Hixie: you could make it valid by adding the UTF-8 BOM
  638. # [22:58] <Hixie> i can't easily type the UTF-8 BOM
  639. # [22:59] * Joins: zcorpan__ (n=zcorpan@84-216-42-220.sprayadsl.telenor.se)
  640. # [22:59] <hsivonen> Hixie: do I understand correctly that "reconstruct the active formatting elements" is a no-op if only character tokens have been processed since the last "reconstruct the active formatting elements"?
  641. # [22:59] <Hixie> i believe that to be the case, yes
  642. # [22:59] <hsivonen> Hixie: thanks
  643. # [22:59] <zcorpan__> ok. so the ie route then. with an optional preparse. but then the real parser needs to undo tentative encoding information when it doesn't find any. no?
  644. # [23:00] <Hixie> hsivonen: in fact you can always treat runs of non-whitespace character tokens and runs of whitespace character tokens as single tokens.
  645. # [23:00] <Hixie> (the same is not true for runs of whitespace and non-whitespace)
  646. # [23:00] <Hixie> zcorpan_: well, what would it "undo" it to?
  647. # [23:00] <hsivonen> Hixie: that's what I'm asking, yes. And "in body" I can treat them both as a single token, right?
  648. # [23:01] <Hixie> i believe that's what i do in my parser, yes
  649. # [23:01] <hsivonen> ok. I'll optimize the "in body" case
  650. # [23:02] * Joins: aroben_ (n=adamrobe@17.255.96.162)
  651. # [23:03] <zcorpan__> Hixie: whatever it would have used if it didn't preparse
  652. # [23:04] <Hixie> it would have used some random guess
  653. # [23:05] * othermaciej_ is now known as othermaciej
  654. # [23:05] <zcorpan__> yeah. fair enough
  655. # [23:06] * Quits: briansuda (n=briansud@85-220-95-76.dsl.dynamic.simnet.is)
  656. # [23:06] <Hixie> i mean i see what you're saying, but i don't really see how you could check to see if a UA did "undo" it or not
  657. # [23:06] <Hixie> i don't really have a good solution to this
  658. # [23:07] <Hixie> we can't really limit how much you preparse, or require it to be a certain minimum, because that has big perf implications
  659. # [23:07] <Hixie> and browsers would just ignore us
  660. # [23:07] <zcorpan__> you can check by comparing with a test that doesn't have any encoding declaration
  661. # [23:08] <zcorpan__> however, i don't think there is content that relies on encoding declarations in (r)cdata elements applying, since ie doesn't see them
  662. # [23:08] <Hixie> well, the problem is you are allowed to pick a different default each time
  663. # [23:08] <Hixie> as you "learn"
  664. # [23:09] <zcorpan__> ah. yeah that's true
  665. # [23:09] * Quits: met_ (n=Hassman@r5bx220.net.upc.cz) ("Chemists never die, they just stop reacting.")
  666. # [23:11] <hsivonen> Hixie: under "in table" anything else you say "If the current node is a table, tbody, tfoot, thead, or tr element, then, whenever a node would be inserted into the current node, it must instead be inserted into the foster parent element." How can the current node be anything other than a table element?
  667. # [23:12] <Hixie> <table><i>
  668. # [23:12] <Hixie> at this point, the current element is an <i>
  669. # [23:12] <Hixie> but you're "in table"
  670. # [23:13] <hsivonen> I see
  671. # [23:13] <hsivonen> but I don't see the consequences
  672. # [23:14] <Hixie> consider <table><i>X</i>Y
  673. # [23:14] <Hixie> the <i> goes into the foster parent
  674. # [23:14] <Hixie> then the X goes into the <i>, because the <i> is the current node
  675. # [23:14] * Quits: zcorpan_ (n=zcorpan@84-216-42-220.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  676. # [23:14] <Hixie> then you close the <i> with the </i>, so the current node is the <table> again
  677. # [23:14] <Hixie> so the Y goes into the foster parent
  678. # [23:14] <hsivonen> Hixie: but the foster parent is the table itself, right?
  679. # [23:15] <Hixie> no, the foster parent is the element the table is in
  680. # [23:15] <hsivonen> ooh
  681. # [23:15] <Hixie> assuming no dom mutations are going on
  682. # [23:15] <Hixie> so <div><br 1><table><p><br 2></table><br 3> results in <div><br 1><p><br 2><table></table><br 3></div>
  683. # [23:16] <hsivonen> ok
  684. # [23:17] * Quits: aroben (n=adamrobe@17.203.15.248) (Connection timed out)
  685. # [23:17] <hsivonen> basically, insertToFosterParent will throw in the streaming mode
  686. # [23:18] * zcorpan__ is now known as zcorpan
  687. # [23:18] <Hixie> fwiw what i did was use a function pointer as my "append to tree" function, and most of the time it's just the straight forward add to tree, but when "in table" in points to a function that does the check
  688. # [23:18] <Hixie> that way you don't pay for the cost all the time
  689. # [23:19] <Hixie> yes, in streaming mode i don't have a solution for tables
  690. # [23:19] <Hixie> what i recommend is actually to buffer up all the content that would be appended before the table
  691. # [23:19] <Hixie> and then when you leave the table, fire a non-SAX event of everything you collected
  692. # [23:20] <Hixie> or just delay all those events til after the table
  693. # [23:20] <Hixie> so the content that normally would go before the table goes after it instead
  694. # [23:20] <hsivonen> Hixie: I didn't follow: what saving did the function pointer give?
  695. # [23:21] <Hixie> wherever i would have called appendChild(), instead dereferenced the function and called that instead
  696. # [23:21] <Hixie> so it's just a pointer dereference each time
  697. # [23:21] <Hixie> instead of being a comparison to the current node each time
  698. # [23:21] <Hixie> maybe it's not cheap to do that in java
  699. # [23:21] <Hixie> in the language i was using a function pointer is exactly as cheap as a function call
  700. # [23:22] <Hixie> since all functions are actually function pointers
  701. # [23:22] <hsivonen> I don't see why the pointer thing wouldn't be masked by other branches anyway
  702. # [23:22] <Hixie> how do you mean?
  703. # [23:23] <hsivonen> If I check for "in table", doesn't that mask the pointer issue
  704. # [23:23] <Hixie> where?
  705. # [23:23] <hsivonen> or did you implement each phase as a set of function pointers that you plug in?
  706. # [23:23] <hsivonen> like html5lib has a class for each phase
  707. # [23:23] <Hixie> i just have a massive set of nested switch() statements
  708. # [23:24] <hsivonen> me too
  709. # [23:24] <Hixie> my implementation is basically a literal implementation of the spec
  710. # [23:24] <hsivonen> are your tokens objects or callbacks?
  711. # [23:24] <Hixie> they're tuples, which is basically a struct (object)
  712. # [23:25] <hsivonen> my tokens are callbacks, so the code order of the tree builder goes against the grain of the spec, which sucks
  713. # [23:25] <Hixie> my tokeniser is a function that runs until it returns a token
  714. # [23:25] <Hixie> ah
  715. # [23:25] <Hixie> why did you do it that way?
  716. # [23:25] <Hixie> i think the ideal way of implementing the tokeniser is a generator function a la python's yield
  717. # [23:26] <hsivonen> Hixie: because the "emit a token" model mentally matched SAX
  718. # [23:26] <hsivonen> Hixie: does yield store the current continuation?
  719. # [23:26] <Hixie> yes
  720. # [23:26] <Hixie> i've never used it but it seems perfect for the input stream and the tokeniser
  721. # [23:27] <hsivonen> no luck with storing continuations in Java without doing it by blocking a thread
  722. # [23:27] <Hixie> yeah, same in sawzall
  723. # [23:27] <Hixie> except you have no threads :-)
  724. # [23:28] <hsivonen> Hixie: anyway, doing the tokenizer the way I've seen SAX parsers written was a perfect match for the spec
  725. # [23:28] <Hixie> cool
  726. # [23:28] <Hixie> sounds less than perfect for the tree part :-(
  727. # [23:28] <hsivonen> Hixie: but now I need to group tree building by token instead of by phase/mode
  728. # [23:28] <Hixie> ah
  729. # [23:28] <Hixie> makes sense
  730. # [23:28] <hsivonen> yeah
  731. # [23:28] <Hixie> i've seen other implementations of the tree part that work that way
  732. # [23:29] <Hixie> so it's certainly possible
  733. # [23:29] <hsivonen> I haven't seen anything impossible yet. the random access to the spec just sucks
  734. # [23:29] <Hixie> random access to the spec?
  735. # [23:29] * Joins: briansuda (n=briansud@85-220-95-76.dsl.dynamic.simnet.is)
  736. # [23:29] <Hixie> oh you mean the way the spec doesn't match it?
  737. # [23:29] <Hixie> yeah
  738. # [23:30] <hsivonen> Hixie: having to seek the right piece of spec when I go over my code stubs instead of making a sequential pass over the spec
  739. # [23:30] <Hixie> yeah
  740. # [23:31] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  741. # [23:34] * Parts: hasather (n=hasather@22.80-203-71.nextgentel.com)
  742. # [23:36] <hsivonen> Hixie: Do I understand correctly that <div>foo<table>bar baz</table></div> parses to <div>foobarbaz<table> </table></div>
  743. # [23:36] <Hixie> yes but that's a bug in the spec
  744. # [23:36] <Hixie> not sure what it should do yet
  745. # [23:36] <Hixie> in particular, <div>foo<table> bar</table></div> vs <div>foo<table> <tr><td></table></div> is a tough one
  746. # [23:37] <hsivonen> hmm. perhaps I make that part horrendously inefficient then
  747. # [23:37] <hsivonen> no point in optimizing something that will be discarded
  748. # [23:44] * Joins: KevinMarks (i=KevinMar@nat/google/x-b00208e2d2c148a5)
  749. # [23:45] <zcorpan> Hixie: hmm. afaict, ie, opera and safari all put the text inside the table. firefox handles that case as equivalent to <div>foobar<table> </table></div>
  750. # [23:46] <Hixie> which case?
  751. # [23:46] <zcorpan> <div>foo<table> bar</table></div>
  752. # [23:48] <zcorpan> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Cdiv%3Efoo%3Ctable%3E%20bar%3C/table%3E%3C/div%3E
  753. # [23:49] <Hixie> anything that results in the text appearing but while inside the <table> is wrong
  754. # [23:49] <Hixie> since it isn't compatible with the css model
  755. # [23:51] <Hixie> looks like we might be able to get away with just setting a flag that saves whitespace
  756. # [23:51] <Hixie> and reset the flag when you hit a table-related element
  757. # [23:51] <Hixie> i.e. when you "clear the stack..."
  758. # [23:52] <zcorpan> yep
  759. # [23:52] <zcorpan> safari treats <div>foo<table> <tr></tr>bar</table></div> as <div>foobar<table> <tr></tr></table></div>
  760. # [23:53] <zcorpan> opera and ie seem to put the text inside the table somehow. in ie, text inside table is inside an element with the tag name ""
  761. # [23:54] <Hixie> IE creates "fake caption" elements
  762. # [23:54] <Hixie> i spoke to the ie guys about it
  763. # [23:54] <zcorpan> ah
  764. # [23:54] <Hixie> they're having all kinds of trouble implementing the css table model on top of their parsing model
  765. # [23:55] <hsivonen> Hixie: the CSS table model has to handle crazy XML and DOM modifications anyway, right?
  766. # [23:55] <zcorpan> wonder how opera deals with it, since it has text nodes as child of table in the dom afaict
  767. # [23:55] <Hixie> hsivonen: the problem is that css wraps cells around unexpected elements in the table
  768. # [23:55] <Hixie> hsivonen: whereas we want to move all the content to before the table
  769. # [23:57] * Quits: Jero (n=Jero@d207230.upc-d.chello.nl) ("ChatZilla 0.9.78.1 [Firefox 2.0.0.4/2007051502]")
  770. # Session Close: Sat Jun 30 00:00:00 2007

The end :)