/irc-logs / freenode / #whatwg / 2007-05-25 / end

Options:

  1. # Session Start: Fri May 25 00:00:00 2007
  2. # Session Ident: #whatwg
  3. # [00:03] * zcorpan adds a link, if it shouldn't be there then revert it... :)
  4. # [00:09] <nickshanks> while you're att it, you can translate the page to swedish ;-)
  5. # [00:14] <zcorpan> lol
  6. # [00:24] <zcorpan> hsivonen: the expansions of XSD and XHTML5 in your thesis say "XML" in <abbr title> in your thesis
  7. # [00:25] * Quits: tantek (n=tantek@64.244.67.2)
  8. # [00:46] <mpt> The perils of invisible metadata
  9. # [00:49] <Dashiva> I wouldn't say title is invisible
  10. # [00:49] <jruderman> just hiding
  11. # [00:52] <mpt> well, yeah
  12. # [00:52] <mpt> Semi-visible
  13. # [00:52] <mpt> like <title> in most browsers
  14. # [00:52] <mpt> hence "Welcome to Adobe GoLive 5" etc
  15. # [00:54] <nickshanks> if title was in the body, would that be a Good Thing ?
  16. # [00:54] <nickshanks> (assuming it had been that way since HTML 1)
  17. # [00:54] <Hixie> it's not where in the markup that matters in this case
  18. # [00:54] <Hixie> since the element is by definition not rendered in the main page
  19. # [00:55] <Hixie> and the main page title (H1) is often not an appropriate <title>
  20. # [00:57] <mpt> I think probably the only way to fix that problem is for browsers to not have toolbars at the top of the window
  21. # [00:58] <Hixie> we kind of have that now with the tab bars
  22. # [00:58] <nickshanks> well, titles go in the tab bar, and that's only 20 chars wide or so
  23. # [00:58] <mpt> |That's not reall...|
  24. # [00:58] <Hixie> i don't see the toolbar going away
  25. # [00:58] <nickshanks> tabs are not real? what! waaaaaa
  26. # [00:59] * nickshanks holds his head in his hands*
  27. # [00:59] <mpt> -ly a solution :-)
  28. # [01:10] * Quits: jonbarnett (n=jbarnett@Flower-Shop-Network-Inc-1149542.cust-rtr.pacbell.net) (Remote closed the connection)
  29. # [01:19] * Quits: billmason (n=billmaso@ip156.unival.com) (".")
  30. # [01:31] * Joins: Welly (n=Welly@62-31-160-20.cable.ubr11.azte.blueyonder.co.uk)
  31. # [01:42] * Joins: tantek (n=tantek@64.244.67.2)
  32. # [01:47] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  33. # [01:48] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  34. # [02:12] * Quits: nickshanks (n=nickshan@home.nickshanks.com)
  35. # [02:15] * Quits: Welly (n=Welly@62-31-160-20.cable.ubr11.azte.blueyonder.co.uk) (Remote closed the connection)
  36. # [02:25] * Joins: zcorpan_ (n=zcorpan@84-216-43-110.sprayadsl.telenor.se)
  37. # [02:25] * Quits: tantek (n=tantek@64.244.67.2)
  38. # [02:33] * Quits: zcorpan (n=zcorpan@84-216-43-110.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  39. # [02:38] * Quits: bzed (n=bzed@dslb-084-059-113-028.pools.arcor-ip.net) ("Leaving")
  40. # [03:02] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca) (Read error: 110 (Connection timed out))
  41. # [03:20] * Joins: yod (n=ot@dhcp-246-155.mag.keio.ac.jp)
  42. # [03:20] * Quits: yod (n=ot@dhcp-246-155.mag.keio.ac.jp) (Remote closed the connection)
  43. # [03:21] * Joins: yod (n=ot@dhcp-246-155.mag.keio.ac.jp)
  44. # [03:42] * Quits: mpt (n=mpt@121-72-128-178.dsl.telstraclear.net) ("This computer has gone to sleep")
  45. # [04:09] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  46. # [04:13] * Joins: mpt (n=mpt@121-72-131-30.dsl.telstraclear.net)
  47. # [04:47] * Parts: zcorpan_ (n=zcorpan@84-216-43-110.sprayadsl.telenor.se)
  48. # [04:58] * Quits: psa (n=yomode@posom.com) (Read error: 104 (Connection reset by peer))
  49. # [05:14] * moeffju[Away] is now known as moeffju
  50. # [05:16] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  51. # [05:16] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Client Quit)
  52. # [05:17] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  53. # [05:57] * Joins: gavin__ (n=gavin@people.mozilla.com)
  54. # [06:01] * Quits: gavin (n=gavin@firefox/developer/gavin) (Read error: 104 (Connection reset by peer))
  55. # [06:01] * Quits: gavin__ (n=gavin@people.mozilla.com) (Read error: 104 (Connection reset by peer))
  56. # [06:14] * Joins: Toolskyn (n=Toolskyn@adsl-dc-266ef.adsl.wanadoo.nl)
  57. # [06:38] * Quits: dbaron (n=dbaron@corp-242.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  58. # [06:38] * Quits: Lachy (n=Lachlan@203-206-243-149.dyn.iinet.net.au) (Read error: 104 (Connection reset by peer))
  59. # [06:47] * Joins: gavin__ (n=gavin@people.mozilla.com)
  60. # [07:40] * Quits: KevinMarks (i=KevinMar@pdpc/supporter/active/kevinmarks) ("The computer fell asleep")
  61. # [08:01] <hsivonen> jgraham: btw, it is now official that my next work items after getting the conformance checker source code better out there are proper Java implementations of the character encoding sniffing algorithm and the tokenizer
  62. # [08:01] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  63. # [08:02] <hsivonen> I intend to write and independent implementation to spec instead of porting html5lib
  64. # [08:02] <hsivonen> should be good both for getting the Javaness right and for getting more review of the spec
  65. # [08:03] <hsivonen> s/write and/write an/
  66. # [08:03] <MikeSmith> hsivonen - how much work/time you estimate that will take?
  67. # [08:07] <hsivonen> MikeSmith: based on talking with jgraham and annevk and based on comparing # of lines of code against previous code, the expectation is that the first unpolished and untested version takes a week (after I'm done sharing the existing source code properly with build scripts) and testing and productization-quality polishing and testing is going to take a couple of weeks more.
  68. # [08:09] <hsivonen> basically, I expect the "get something running" take less time than all the productization polishing after it
  69. # [08:09] * moeffju is now known as moeffju[afk]
  70. # [08:09] <hsivonen> although it isn't clear yet how well the those parts can be polished before the tree-builders exist
  71. # [08:10] * Joins: tantek (n=tantek@adsl-71-141-106-222.dsl.snfc21.pacbell.net)
  72. # [08:10] <hsivonen> anyway, the goal is to produce a reusable library--not just to write the minimum that would allow the conformance checker to run
  73. # [08:26] <MikeSmith> hsivonen - are there others picking up your code so far? (that you're aware of)
  74. # [08:27] <hsivonen> MikeSmith: Jirka Kosek and Petr Nálevka will probably pick up the table integrity checker real soon now
  75. # [08:27] <hsivonen> MikeSmith: they are also interested in the parser
  76. # [08:27] <hsivonen> I'd advice against using my current parser, though
  77. # [08:28] <hsivonen> but once I'm done with writing a productized HTML5 parsing library with 4 tree builders, I'm all for others using it :-)
  78. # [08:28] <MikeSmith> yeah, I know you planning to update your parser to matech the spec
  79. # [08:38] * Joins: Lachy (n=Lachlan@203-206-243-149.dyn.iinet.net.au)
  80. # [08:55] * Quits: tantek (n=tantek@adsl-71-141-106-222.dsl.snfc21.pacbell.net)
  81. # [09:07] * moeffju[afk] is now known as moeffju[Work]
  82. # [09:19] * Joins: KevinMarks (n=KevinMar@h-68-164-93-9.snvacaid.dynamic.covad.net)
  83. # [09:32] * Quits: yod (n=ot@dhcp-246-155.mag.keio.ac.jp) ("Leaving")
  84. # [09:51] * Joins: Toolskyn88 (n=Toolskyn@adsl-dc-266ef.adsl.wanadoo.nl)
  85. # [10:08] * Quits: Toolskyn (n=Toolskyn@adsl-dc-266ef.adsl.wanadoo.nl) (Read error: 110 (Connection timed out))
  86. # [10:09] * Joins: met_ (n=Hassman@b14-4.vscht.cz)
  87. # [10:15] * Joins: billyjack (n=MikeSmit@58.157.21.205)
  88. # [10:15] * Quits: MikeSmith (n=MikeSmit@58.157.21.205) (Read error: 104 (Connection reset by peer))
  89. # [10:20] * Joins: annevk (n=annevk@pat-tdc.opera.com)
  90. # [10:23] * Joins: malware (n=MikeSmit@58.157.21.204)
  91. # [10:24] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  92. # [10:26] * Quits: billyjack (n=MikeSmit@58.157.21.205) (Read error: 104 (Connection reset by peer))
  93. # [10:26] * Joins: MikeSmith (n=MikeSmit@58.157.21.205)
  94. # [10:30] * Joins: BenWard (n=BenWard@cpc3-cmbg2-0-0-cust58.cmbg.cable.ntl.com)
  95. # [10:30] * Joins: billyjack (n=MikeSmit@58.157.21.197)
  96. # [10:30] * Quits: malware (n=MikeSmit@58.157.21.204) (Read error: 104 (Connection reset by peer))
  97. # [10:31] * Joins: malware (n=MikeSmit@58.157.21.204)
  98. # [10:36] * Quits: YaaL (i=yaal@hell.pl) (Remote closed the connection)
  99. # [10:37] * Quits: weinigLap (n=weinig@17.203.15.217)
  100. # [10:39] * Quits: BenWard (n=BenWard@cpc3-cmbg2-0-0-cust58.cmbg.cable.ntl.com) ("Fades out again…")
  101. # [10:48] * Quits: MikeSmith (n=MikeSmit@58.157.21.205) (Read error: 110 (Connection timed out))
  102. # [10:48] * Quits: billyjack (n=MikeSmit@58.157.21.197) (Read error: 110 (Connection timed out))
  103. # [10:50] <hsivonen> now that Vlad is suggesting dashing, it would be interesting to hear from the canvas implementors at Opera and Apple if they'd be ok with adding dashes
  104. # [10:50] <Hixie> adding this to canvas when canvas is so poorly implemented at this stage would be stupid
  105. # [10:50] <Hixie> every browser is swimming in bugs and unimplemented features already
  106. # [10:51] <Hixie> adding more stuff will just make it even less likely that we'll reach the sort of quality point we need for exiting CR
  107. # [10:56] <virtuelv> Hixie: agreed, canvas is suffering from poor interoperability
  108. # [11:00] * Joins: weinigLap (n=weinig@c-67-188-78-122.hsd1.ca.comcast.net)
  109. # [11:01] <hsivonen> which is interesting since in theory, canvas should be the area of the spec where you could get the most interop per unit of effort (because the back end imaging model is well understood and old)
  110. # [11:03] * malware is now known as MikeSmith
  111. # [11:04] * othermaciej is now known as om_sleep
  112. # [11:06] <Hixie> it's the area of the spec with the most interop, i think
  113. # [11:06] <Hixie> but it would only get worse if we added more features at this stage, imho
  114. # [11:06] <Hixie> i mean, if the vendors think we should, i'll bow to pressure, but it just seems stupid to me
  115. # [11:10] <virtuelv> hsivonen: Some of the interop problems in canvas are a result of different interpretations of spec text, I believe
  116. # [11:11] <met_> so we need some spec how to read the spec? 8-)
  117. # [11:12] <virtuelv> met_: you mean you want formal grammar for a spec language
  118. # [11:12] <virtuelv> good luck
  119. # [11:12] <annevk> the spec text is improving
  120. # [11:12] <virtuelv> indeed it is
  121. # [11:13] <hsivonen> met_: the spec already says that it should be read forwards, backwards and in pieces
  122. # [11:13] <met_> hsivonen: nice 8-)
  123. # [11:22] * Joins: ROBOd (n=robod@86.34.246.154)
  124. # [11:24] <ROBOd> good morning to all
  125. # [11:24] <ROBOd> Hixie: ping?
  126. # [11:31] <Hixie> hey
  127. # [11:35] <ROBOd> hey Hixie, i was surprised to read your replies to my very old emails
  128. # [11:35] <Hixie> yeah, i'm going through all the feedback we received
  129. # [11:36] <ROBOd> very good, thanks for the replies
  130. # [11:36] * Quits: weinigLap (n=weinig@c-67-188-78-122.hsd1.ca.comcast.net)
  131. # [11:49] <Hixie> ROBOd: btw in case i have other e-mails from you, i apologise in advance if i send the replies to the wrong address. i don't look at who wrote the e-mail when i reply to them, i just hit "reply all", write the reply, fix the spec if needed, and send the mail.
  132. # [11:50] <ROBOd> Hixie: absolutely no problem
  133. # [11:50] <ROBOd> i understand that
  134. # [11:51] <ROBOd> i just mentioned the email address change, in case others reply
  135. # [11:51] <ROBOd> i can no longer reply from the old email account - it's not subscribed to the ML
  136. # [11:52] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  137. # [11:52] <hsivonen> offtopic for the svn users: does svn integration actually work these days in eclipse?
  138. # [11:52] * annevk uses SVN but not Eclipse :)
  139. # [11:53] <met_> http://subclipse.tigris.org/ looks so
  140. # [11:53] <hsivonen> *working* Eclipse integration is a must-have for me. I'm considering whether I should put the new html parser code in the schema CVS repo or start a new svn repo
  141. # [11:54] <hsivonen> met_: have you tried subclipse lately?
  142. # [11:54] <met_> no
  143. # [11:54] <hsivonen> my experience of subclipse is from two years ago and back then it was unacceptably b0rked
  144. # [11:54] <met_> looks its from same people like tortoiseSVN which i am using
  145. # [11:54] <Hixie> right, bed time
  146. # [11:54] <Hixie> nn
  147. # [11:55] <ROBOd> good night Hixie :)
  148. # [11:55] <hsivonen> Hixie: g'night
  149. # [11:55] * met_ have lunchtime in 5 minutes
  150. # [11:56] <ROBOd> bon appètit met_
  151. # [11:57] <met_> thanks
  152. # [12:01] * Joins: mikeday (n=mikeday@CPE-60-224-50-129.vic.bigpond.net.au)
  153. # [12:02] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Leaving")
  154. # [12:04] * Joins: zcorpan_ (n=zcorpan@84-216-41-105.sprayadsl.telenor.se)
  155. # [12:30] <Philip`> The canvas implementations all seem to be fine at just drawing stuff - they do curves and lines and rotated bitmaps and gradients and everything - and it's only in the mapping between the JS API and the drawing bits that has lots of problems
  156. # [12:32] <mikeday> don't they draw stuff in response to JavaScript API calls?
  157. # [12:33] <Philip`> They do, but usually they don't draw the correct stuff
  158. # [12:33] <mikeday> different implementations behave slightly differently?
  159. # [12:34] <Philip`> They often behave totally differently :-)
  160. # [12:34] <mikeday> oh :)
  161. # [12:34] <mikeday> since SQL is now part of the HTML5 spec, why not base the canvas on the PDF/PostScript rendering model?
  162. # [12:35] <annevk> ...
  163. # [12:35] <Philip`> There are simple cases like "moveTo(0, 0); translate(10, 10); lineTo(20, 20); stroke()" that are handled very differently
  164. # [12:35] <mikeday> really? how differently?
  165. # [12:36] <Philip`> Some apply the transformation as points are being added to the path, and some apply it just before the stroke so it affects all the points equally
  166. # [12:36] <mikeday> oh, right
  167. # [12:37] <mikeday> problem with imperative interface I guess
  168. # [12:37] <mikeday> needs a well defined mapping to an SVG DOM, perhaps :)
  169. # [12:37] <Philip`> http://canvex.lazyilluminati.com/tests/tests/results.html shows lots of problems and I haven't even got around to testing radial gradients or patterns or paths, which are particularly bad
  170. # [12:37] <Philip`> The behaviour is well-defined already - it just doesn't match two thirds of the implementations :-)
  171. # [12:38] <mikeday> not really a specification problem, then :)
  172. # [12:39] * Philip` should write more tests and submit bug reports
  173. # [12:40] <Philip`> (and maybe write patches if they're not complicated and if everyone else wants to ignore them and add new features instead)
  174. # [12:41] * hsivonen wonders what happens in PostScript if you manipulate the CTM between adding path segments
  175. # [12:41] <mikeday> good question
  176. # [12:42] <mikeday> I thought it was illegal
  177. # [12:42] <Philip`> What happens when you do something illegal?
  178. # [12:43] <mikeday> ask ghostscript :)
  179. # [12:43] <zcorpan_> a SWAT team comes to get you
  180. # [12:44] <mikeday> hmm, at least in PDF, once you start constructing a path you can't do anything else until you paint it
  181. # [12:44] <hsivonen> zcorpan_: the Web lacks the SWAT team
  182. # [12:44] <mikeday> if you *do* do anything else the results are not defined by the specification
  183. # [12:45] <hsivonen> zcorpan_: thesis comment noted. thanks. however, if at all feasible, I'm treating the dated files as frozen
  184. # [12:46] <Philip`> Aha, undefined behaviour sounds an excellent strategy to follow ;-)
  185. # [12:46] <mikeday> "Note: A content stream whose operations violate these rules for describing graphics objects can produce unpredictable behavior, even though it may display and print correctly."
  186. # [12:47] <mikeday> that's PDF, but I think it inherited the restriction from PostScript.
  187. # [12:48] <hsivonen> iirc, adobe reader silently accepts some non-conforming files that Ghostscript accepts but complains about
  188. # [12:48] <hsivonen> iirc, there were some semi-prominent Macromedia or Corel legacy products outputting the non-conforming stuff
  189. # [12:50] <hsivonen> but fewer people author PDF by hand, so the problem is not as bad as with HTML/CSS
  190. # [12:50] <mikeday> when it comes to PDF, acrobat compatibility is more important than following the spec
  191. # [12:50] <hsivonen> mikeday: are there cases where you have to violate the spec to be compatible with acrobat?
  192. # [12:51] <hsivonen> on the producer side, that is
  193. # [12:51] <mikeday> not that I recall,
  194. # [12:51] <mikeday> but there are some cases where PDF files that follow the spec will not be accepted
  195. # [12:52] <mikeday> funny how similar the situation is to browsers, actually
  196. # [12:52] <mikeday> there are just fewer user agents in PDF world
  197. # [12:53] <hsivonen> actually, there's also the top gang of four on the PDF side
  198. # [12:53] <hsivonen> (Adobe, Apple, xpdf-based, Ghostscript)
  199. # [12:55] <mikeday> yes
  200. # [12:55] <mikeday> I guess you can map Acrobat -> IE
  201. # [12:56] <mikeday> in that if it doesn't work in Acrobat, you've lost 90% of your userbase
  202. # [12:57] <mikeday> must go
  203. # [12:57] * Quits: mikeday (n=mikeday@CPE-60-224-50-129.vic.bigpond.net.au) ("-")
  204. # [12:58] <annevk> Philip`, for that particular case I believe Opera matches the SVG model...
  205. # [12:58] <annevk> Philip`, and I think other vendors agreed it was more logical but they haven't updated their impl so far...
  206. # [13:01] <Philip`> annevk: Okay - I think the spec text matches Opera but it was waiting for implementor feedback when I last heard
  207. # [13:02] <annevk> yeah, Firefox and Safari still need to try to fix it...
  208. # [13:06] <hsivonen> annevk: http://tc.labs.opera.com/robots.txt isn't particularly friendly to people who try to locate the test suite
  209. # [13:06] <hsivonen> also, it suggest you don't want me to hit it with recursive wget
  210. # [13:06] <hsivonen> annevk: what's the right way to obtain a local copy of the test suite?
  211. # [13:09] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  212. # [13:14] <annevk> I suppose I could lift some restrictions
  213. # [13:15] <annevk> done
  214. # [13:16] <hsivonen> annevk: thanks
  215. # [13:23] * Quits: gsnedders (n=gsnedder@host86-139-123-225.range86-139.btcentralplus.com)
  216. # [13:34] <annevk> hsivonen, that's how text/plain loading is defined in HTML5...
  217. # [13:34] <annevk> using <plaintext>
  218. # [13:38] <Philip`> Does anyone happen to know how Safari probably does canvas shadows? It looks like it multiplies the shadow colour by the alpha value at each pixel, then does some blur (Gaussian with cutoff or something?) and composites stuff - maybe it's just the same as the PS / PDF definition, and hopefully that definition actually defines it...
  219. # [13:38] <annevk> heh
  220. # [13:39] <Philip`> Oh, PDF doesn't have shadows
  221. # [13:39] * Joins: gsnedders (n=gsnedder@host86-139-123-225.range86-139.btcentralplus.com)
  222. # [13:40] <Philip`> (and PostScript doesn't have shadows either)
  223. # [13:43] <annevk> maybe someone can make a <canvas> Acid test
  224. # [13:43] <Philip`> (and http://developer.apple.com/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_shadows/chapter_8_section_1.html is uselessly vague)
  225. # [13:44] <annevk> http://developer.apple.com/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_shadows/chapter_8_section_2.html#//apple_ref/doc/uid/TP30001066-CH208-DontLinkElementID_7 seems to have details
  226. # [13:44] <annevk> (linked from that page)
  227. # [13:45] <Philip`> It only has about one detail (that the default alpha is 1/3, which doesn't matter for canvas because you always override the default alpha) :-(
  228. # [13:45] <Philip`> Hmm, about colour spaces, does everyone implement canvas with sRGB? And should the spec state that?
  229. # [13:46] <annevk> doesn't CSS say something about that?
  230. # [13:46] <annevk> it should be the same as what CSS uses, anyway
  231. # [13:46] <Philip`> CSS3 Color says it's all in sRGB
  232. # [13:47] <Philip`> though I think canvas still needs to specify the colour space, so that e.g. linear interpolation along gradients makes sense
  233. # [13:47] <hsivonen> annevk: yes, but if you generate <plaintext> on the server, the sniffing does not kick in
  234. # [13:49] <hsivonen> Philip`: the sane way to spec it is that the canvas color space should be the same color space as what the UA uses for CSS colors in the absence of an explicit profile
  235. # [13:50] <hsivonen> Philip`: CSS says sRGB, but in reality browsers use the color space of the OS
  236. # [13:50] * Quits: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl) (Read error: 110 (Connection timed out))
  237. # [13:52] <zcorpan_> hsivonen: if you say text/plain; charset=utf-8, the sniffing doesn't kick in either (or it shouldn't)
  238. # [13:53] <zcorpan_> iirc
  239. # [13:53] * Philip` wonders if trying to draw gamma-corrected PNGs onto a canvas is likely to involve far too much pain and is best avoided
  240. # [13:53] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Leaving")
  241. # [13:53] <hsivonen> zcorpan_: even in real-word IE?
  242. # [13:53] <hsivonen> Philip`: I'd expect lots of bogosity and bugs in that area
  243. # [13:54] <zcorpan_> hsivonen: not sure
  244. # [13:54] <Philip`> http://trac.webkit.org/projects/webkit/browser/trunk/WebCore/html/HTMLCanvasElement.cpp#L238 - ah, that's using "DeviceRGB"
  245. # [13:55] <hsivonen> Philip`: yeah, but DeviceRGB isn't really the *device* but the OS.
  246. # [13:55] <Philip`> (Oh, did someone add Qt support to WebKit <canvas> recently?)
  247. # [13:55] <hsivonen> there's a transfer function between DeviceRGB and the real device
  248. # [13:56] <Philip`> (I guess that'll provide a whole 'nother set of bugs...)
  249. # [13:57] <hsivonen> Philip`: I wouldn't expect bug opportunities there. only miscalibratin opportunities
  250. # [13:57] <hsivonen> AFAIK, as far as apps are concerned, DeviceRGB is the "device"
  251. # [13:57] <krijnh> zcorpan_: IE does sniff when using Content-Type: text/plain;charset=utf-8
  252. # [13:58] <hsivonen> but what it really means is configurable system-wide
  253. # [13:58] <zcorpan_> krijnh: ok
  254. # [13:58] <krijnh> IE7 as well
  255. # [13:58] <Philip`> Oh, sorry, I was thinking of bugs in WebKit-Qt (since that has totally new rendering code)
  256. # [13:58] <Philip`> Colour spaces seem confusing enough that I'll probably ignore them for now and be happy :-)
  257. # [13:58] <zcorpan_> krijnh: in ie7, there's a security setting to disable content type sniffing
  258. # [13:59] * Joins: zcorpan (n=zcorpan@84-216-43-7.sprayadsl.telenor.se)
  259. # [14:00] * hsivonen wonders if apps can circumvent DeviceRGB via OpenGL on Mac OS X
  260. # [14:00] <krijnh> zcorpan_: What's it called?
  261. # [14:01] <zcorpan> krijnh: "Open files based on content, not file extension"
  262. # [14:01] <krijnh> Open files based on content, not file..
  263. # [14:01] <krijnh> Indeed :)
  264. # [14:01] <krijnh> Wow, that's a crappy label
  265. # [14:01] <zcorpan> yeah
  266. # [14:02] <krijnh> It has nothing to do with the extension
  267. # [14:02] <krijnh> And I don't think it checks on the extension
  268. # [14:02] <krijnh> Er, sniffs
  269. # [14:03] <hsivonen> probably a case of the UI folks not understanding the implementation
  270. # [14:03] <hsivonen> on Mac OS X "Rich Text" is translated to "RTF" in Finnish in Mail.app even though "Rich Text" in mail is HTML
  271. # [14:03] <krijnh> Rhat the fuck
  272. # [14:05] <hsivonen> krijnh: was that in response to what I said?
  273. # [14:05] <krijnh> Nah, I say rhat the fuck all the time
  274. # [14:06] <krijnh> I'll be silent again now ;)
  275. # [14:08] * hsivonen is slow. only gets it now
  276. # [14:15] <zcorpan> who has access to the whatwg blog source? ".navigation div { position:relative; }" needs to be added to the style sheet for opera
  277. # [14:18] * Quits: zcorpan_ (n=zcorpan@84-216-41-105.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  278. # [14:20] <zcorpan> Lachy: yt?
  279. # [14:25] <Lachy> yo
  280. # [14:25] <zcorpan> Lachy: see above :)
  281. # [14:25] <Lachy> yeah, I just noticed
  282. # [14:26] <zcorpan> perhaps i should also try to make a test case out of it, if it's actually a bug in opera
  283. # [14:26] <Lachy> it probably is a bug
  284. # [14:28] <Lachy> I don't see what the bug is
  285. # [14:28] <zcorpan> it's not always reproducable
  286. # [14:29] <Lachy> how can I reproduce it at all? I've tried reloading several times and don't see it
  287. # [14:30] <MikeSmith> hsivonen - you aware of any Linux PDF viewers that aren't based on xpdf? (just wondering if there are any)
  288. # [14:31] <zcorpan> Lachy: dunno. sometimes the links aren't clickable and then if you scroll down and up again the links disappear
  289. # [14:31] <Lachy> which version of Opera?
  290. # [14:31] <Lachy> I have 9.20
  291. # [14:32] <zcorpan> 9.21
  292. # [14:32] <Lachy> ok. updated stylesheet is published now
  293. # [14:33] <zcorpan> thanks
  294. # [14:43] <zcorpan> http://simon.html5.org/test/opera/unselectable-text.htm
  295. # [14:49] * Quits: annevk (n=annevk@pat-tdc.opera.com) (Remote closed the connection)
  296. # [14:50] * Joins: annevk (n=annevk@pat-tdc.opera.com)
  297. # [14:55] <zcorpan> submitted bug #266507
  298. # [14:59] * Lachy is about to publish a rather controversial blog post about the HTMLWG
  299. # [15:02] * annevk will go to reboot for a day!
  300. # [15:03] <met_> Lachy: about what? htmlwg dead? 8-)
  301. # [15:04] <Lachy> it's about the issues with the HTMLWG, giving an overview of all the major debates that have gone on
  302. # [15:04] <Lachy> it was originally an email to Molly that she asked me to write, and she requrested that I make it public
  303. # [15:09] <Philip`> Conclusion from testing <canvas> in WebKit-Qt: it's currently really quite broken (e.g. it doesn't even seem to do rotation correctly), and also I can't copy-and-paste the test results and then it had a segmentation fault and lost the data :-(
  304. # [15:10] * Joins: jonbarnett (n=jbarnett@Flower-Shop-Network-Inc-1149542.cust-rtr.pacbell.net)
  305. # [15:11] <annevk> what's WebKit-Qt?
  306. # [15:11] <Philip`> It's just WebKit, but compiled with Qt :-)
  307. # [15:11] <Philip`> (I don't know if it has an official name)
  308. # [15:11] <Philip`> and running on Linux
  309. # [15:12] <met_> sounds like khtml 8-)
  310. # [15:13] <Lachy> http://lachy.id.au/log/2007/05/htmlwg
  311. # [15:14] <Philip`> It sounds like there are plans to make it possible to use WebKit as the HTML component in KDE4, as an alternative to the normal KHTML
  312. # [15:14] <annevk> btw, the easiest way to make public record of an e-mail is to cc www-archive@w3.org
  313. # [15:15] <Lachy> I thought about that, but I decided marking it up and blogging it was more appropriate in this case
  314. # [15:15] <MikeSmith> annevk -
  315. # [15:15] <MikeSmith> http://dot.kde.org/1152645965/
  316. # [15:15] <MikeSmith> http://labs.trolltech.com/blogs/category/labs/internet/webkit/
  317. # [15:16] <MikeSmith> George Staikos and Zack Rusin
  318. # [15:17] <MikeSmith> and Lars Knoll
  319. # [15:18] * Joins: mw22 (n=chatzill@cc1057475-a.ls1.ov.home.nl)
  320. # [15:19] <annevk> looks interesting
  321. # [15:19] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  322. # [15:20] <annevk> http://www.reboot.dk/artefact-2493-en.html
  323. # [15:22] <annevk> btw
  324. # [15:22] <annevk> how about
  325. # [15:23] <annevk> r = new XMLHttpRequest(uri); r.onload = ...; r.onerror = ...
  326. # [15:23] <annevk> to do a simple asynchronous GET request without hassle
  327. # [15:24] <MikeSmith> I guess that when completed the WebKit Qt port can run within Trolltech's Qtopia (what used to be called Qt/Embedded) on mobile devices
  328. # [15:26] <jonbarnett> anne: would/coult any of those events have the XMLRequestObject as one of the *target properties of the event object passed to the handler?
  329. # [15:26] <annevk> this should refere to XHR in theory
  330. # [15:27] <annevk> and does in Opera
  331. # [15:27] <annevk> and I think it does in WebKit builds too
  332. # [15:28] <jonbarnett> the draft doesn't say so. which property (currentTarget?)
  333. # [15:28] <annevk> it's all implied by making XMLHttpRequest implement EventTarget
  334. # [15:28] <jonbarnett> got it
  335. # [15:29] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Leaving")
  336. # [15:49] <jonbarnett> anne: what version of Opera does so?
  337. # [15:49] <annevk> supports what, exactly?
  338. # [15:50] <jonbarnett> passes something to the event handler. I'm testing with 0
  339. # [15:50] <jonbarnett> 9
  340. # [15:50] <annevk> using request.onreadystatechange = function() { alert(this.readyState) }
  341. # [15:50] <annevk> should work
  342. # [15:51] <jonbarnett> I assumed that function(e) { alert(e); } should give something
  343. # [15:52] <annevk> I don't think we have made it an EventTarget yet
  344. # [15:54] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  345. # [16:12] * Quits: met_ (n=Hassman@b14-4.vscht.cz) ("Chemists never die, they just stop reacting.")
  346. # [16:25] * Joins: billmason (n=billmaso@ip156.unival.com)
  347. # [16:27] * Joins: bzed (n=bzed@dslb-084-059-102-058.pools.arcor-ip.net)
  348. # [16:27] <hsivonen> MikeSmith: ggv is Ghostscript-based and Adobe Reader is, of course, using Adobe's impl. But yeah, all the nice ones that are Free Software tend to be xpdf-based.
  349. # [16:28] <MikeSmith> hsivonen - k
  350. # [16:58] * Joins: jcgregorio (i=chatzill@nat/ibm/x-c654de21ac840535)
  351. # [17:03] * Quits: mw22 (n=chatzill@cc1057475-a.ls1.ov.home.nl) (Read error: 110 (Connection timed out))
  352. # [17:17] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  353. # [17:19] * Joins: weinigLap (n=weinig@17.203.15.217)
  354. # [17:25] * Quits: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com) (Remote closed the connection)
  355. # [17:26] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  356. # [17:29] * Quits: jonbarnett (n=jbarnett@Flower-Shop-Network-Inc-1149542.cust-rtr.pacbell.net) (Remote closed the connection)
  357. # [18:03] <hsivonen> HTML5 conformance checking is now on the XML radar: http://www.oreillynet.com/xml/blog/2007/05/fake_realtime_blog_from_xtech.html
  358. # [18:12] <MikeSmith> hsivonen - interesting -- especially part about error messages
  359. # [18:13] <MikeSmith> funny that he writes "they" in several places
  360. # [18:13] <MikeSmith> maybe he thinks you're not a real person ...
  361. # [18:13] <MikeSmith> but some kind of collective
  362. # [18:13] <MikeSmith> the Henri Sivonen Collective
  363. # [18:13] <hasather> hehe
  364. # [18:14] <MikeSmith> looking forward to seeing what he comes up with as far as trying to implement table-integrity checking solely in Schematron
  365. # [18:32] * Quits: MikeSmith (n=MikeSmit@58.157.21.204) (Read error: 110 (Connection timed out))
  366. # [18:33] * Joins: MikeSmith (n=MikeSmit@58.157.21.204)
  367. # [18:35] * moeffju[Work] is now known as moeffju[Away]
  368. # [18:37] * Joins: dbaron (n=dbaron@c-71-198-189-81.hsd1.ca.comcast.net)
  369. # [18:37] * Joins: h3h (n=w3rd@66-162-32-234.static.twtelecom.net)
  370. # [18:37] * Quits: dolphinling (n=chatzill@rbpool5-115.shoreham.net) (Read error: 110 (Connection timed out))
  371. # [18:39] * Joins: dolphinling (n=chatzill@rbpool1-27.shoreham.net)
  372. # [18:46] * Quits: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com) (Remote closed the connection)
  373. # [18:47] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  374. # [18:49] * Joins: aroben (i=adamrobe@nat/apple/x-85755300f417abb4)
  375. # [18:53] * Quits: jcgregorio (i=chatzill@nat/ibm/x-c654de21ac840535) (Excess Flood)
  376. # [18:53] * Quits: zcorpan (n=zcorpan@84-216-43-7.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  377. # [18:54] * Joins: jcgregorio (i=chatzill@nat/ibm/x-881a4e26da0a4670)
  378. # [19:02] * Quits: KevinMarks (n=KevinMar@pdpc/supporter/active/kevinmarks) ("The computer fell asleep")
  379. # [19:04] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  380. # [19:23] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  381. # [19:26] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
  382. # [19:29] * Quits: jcgregorio (i=chatzill@nat/ibm/x-881a4e26da0a4670) (Remote closed the connection)
  383. # [19:34] * Joins: zcorpan (n=zcorpan@84-216-41-249.sprayadsl.telenor.se)
  384. # [19:34] * Joins: jcgregorio (i=chatzill@nat/ibm/x-16ba8f1b0831056d)
  385. # [19:43] * Joins: tantek_ (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  386. # [19:43] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net) (Read error: 104 (Connection reset by peer))
  387. # [19:44] * tantek_ is now known as tantek
  388. # [20:05] * Disconnected
  389. # [20:06] * Attempting to rejoin channel #whatwg
  390. # [20:06] * Rejoined channel #whatwg
  391. # [20:06] * Topic is 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks!'
  392. # [20:06] * Set by Hixie on Tue Apr 03 04:10:22
  393. # [20:06] * Quits: krijnh (n=krijnhoe@ktk.xs4all.nl) (Read error: 104 (Connection reset by peer))
  394. # [20:12] * Joins: jonbarnett (n=jbarnett@Flower-Shop-Network-Inc-1149542.cust-rtr.pacbell.net)
  395. # [20:19] * Parts: zcorpan (n=zcorpan@84-216-41-249.sprayadsl.telenor.se)
  396. # [20:21] * Joins: kingryan (n=kingryan@corp.technorati.com)
  397. # [20:22] * Joins: KevinMarks (i=KevinMar@nat/google/x-cba22bf21be2720b)
  398. # [20:27] * Joins: zcorpan (n=zcorpan@84-216-41-249.sprayadsl.telenor.se)
  399. # [20:47] * Joins: Jero (n=Jero@d207230.upc-d.chello.nl)
  400. # [20:58] * Quits: KevinMarks (i=KevinMar@pdpc/supporter/active/kevinmarks) ("The computer fell asleep")
  401. # [21:04] * Joins: KevinMarks (i=KevinMar@nat/google/x-d978aaff7f607f3c)
  402. # [21:04] * Quits: aroben (i=adamrobe@nat/apple/x-85755300f417abb4)
  403. # [21:22] * Quits: jcgregorio (i=chatzill@nat/ibm/x-16ba8f1b0831056d) ("ChatZilla 0.9.78.1 [Firefox 2.0.0.3/2007040314]")
  404. # [21:24] <Jero> ok wtf, in my HTML5 parser the code "<a><p>X<a>Y</a>Z</p></a>" gets transformed to "<a><p>X</p><a>YZ</a></a>" instead of "<a></a><p><a>X</a><a>Y</a>Z</p>"
  405. # [21:25] <Jero> is that an error in parser the start tag token of the second A element, an error in parsing the adoption agency, or an error in reconstructing the active formatting elements?
  406. # [21:28] * Joins: iMagne (n=magne@ti231210a080-4981.bb.online.no)
  407. # [21:28] * Joins: colione (n=colione@c80-216-172-27.bredband.comhem.se)
  408. # [21:30] * Quits: colione (n=colione@c80-216-172-27.bredband.comhem.se) (Client Quit)
  409. # [21:30] * Joins: colione (n=colione@c80-216-172-27.bredband.comhem.se)
  410. # [21:30] * Joins: maikmerten (n=maikmert@T6a72.t.pppool.de)
  411. # [21:34] <Philip`> Jero: http://hasather.net/html5/parsetree/parsetree.py?source=%3Ca%3E%3Cp%3EX%3C%2Fp%3E%3Ca%3EYZ%3C%2Fa%3E%3C%2Fa%3E says it should give <a><p>X</p></a><a>YZ</a> which is neither of the ones you mentioned
  412. # [21:35] <Philip`> (but I don't understand the parser at all, so I have no idea why yours wouldn't be closing the first <a> at the right point)
  413. # [21:36] <gsnedders> Philip`: that tree looks correct, under my memory of the spec
  414. # [21:36] <Jero> interesting
  415. # [21:37] <Jero> http://html5lib.googlecode.com/svn/trunk/tests/tree-construction/tests1.dat gives my a different output tree (search for "<a><p>X<a>Y</a>Z</p></a>")
  416. # [21:43] <Philip`> Oh, okay - when I run with a (probably newer?) version of html5lib, it does give <a/><p><a>X</a><a>Y</a>Z</p> which matches that test
  417. # [21:50] * Quits: KevinMarks (i=KevinMar@pdpc/supporter/active/kevinmarks) ("The computer fell asleep")
  418. # [21:56] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net) (Read error: 104 (Connection reset by peer))
  419. # [21:56] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  420. # [21:58] <Jero> Step 3 of the adoption agency: If there is no furthest block ... pop all the nodes from the bottom of the stack of open elements, from the current node up to the formatting element...
  421. # [21:59] * Quits: jonbarnett (n=jbarnett@Flower-Shop-Network-Inc-1149542.cust-rtr.pacbell.net) (Remote closed the connection)
  422. # [22:00] <Jero> because of "up to the formatting element" i didn't include to pop the formatting element from the stack which resulted in not closing the first A element
  423. # [22:01] <Jero> so maybe it should explicitly say "including the formatting element"?
  424. # [22:02] <Hixie> if that would help please do send mail so i remember to fix it
  425. # [22:02] <Hixie> ian@hixie.ch or whatwh@whatwh.org
  426. # [22:02] <Hixie> whatwg.org
  427. # [22:07] <Jero> thanks, I will
  428. # [22:12] * om_sleep is now known as othermaciej
  429. # [22:15] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  430. # [22:17] <Jero> Philip`: my parser now treats "<a><p>X<a>Y</a>Z</p></a>" as "<a></a><p><a>X</a><a>Y</a>Z</p>", instead of "<a><p>X</p></a><a>YZ</a>" like http://hasather.net/html5/parsetree/ gives as output
  431. # [22:18] <Jero> oh, i see you updated the parser, sorry
  432. # [22:19] * Joins: KevinMarks (i=KevinMar@nat/google/x-47588e91fdf569d4)
  433. # [22:19] * Philip` wonders who controls that parsetree page and what version of html5lib it's running
  434. # [22:19] <Jero> oh, i thought you were :p
  435. # [22:21] <Philip`> At least it sounds like your one is correct now, if it matches the output from the test cases
  436. # [22:37] * Joins: aroben_ (i=adamrobe@nat/apple/x-92a835b34dfcb005)
  437. # [22:37] * Quits: aroben_ (i=adamrobe@nat/apple/x-92a835b34dfcb005) (Remote closed the connection)
  438. # [22:37] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  439. # [22:38] * Joins: aroben_ (i=adamrobe@nat/apple/x-87375f3bc47c6769)
  440. # [22:49] * Joins: psa (n=yomode@posom.com)
  441. # [23:07] * Joins: tantek (n=tantek@64.244.67.2)
  442. # [23:36] * Quits: KevinMarks (i=KevinMar@pdpc/supporter/active/kevinmarks) ("The computer fell asleep")
  443. # [23:39] <annevk> hasather, ping, see above
  444. # [23:39] <annevk> hasather, your parsetree is out of date
  445. # [23:40] * Quits: tantek (n=tantek@64.244.67.2)
  446. # [23:43] * Joins: tantek (n=tantek@64.244.67.2)
  447. # [23:45] * Quits: maikmerten (n=maikmert@T6a72.t.pppool.de) ("Leaving")
  448. # [00:00] <hasather> annevk: oh, I'll update it now
  449. # Session Close: Sat May 26 00:00:00 2007

The end :)