/irc-logs / freenode / #whatwg / 2009-03-25 / end

Options:

  1. # Session Start: Wed Mar 25 00:00:00 2009
  2. # Session Ident: #whatwg
  3. # [00:00] * Quits: annodomini (n=lambda@wikipedia/lambda)
  4. # [00:04] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  5. # [00:05] * heycam wonders why he was CCed on the "localStorage and IE8" thread
  6. # [00:07] * gsnedders asks "Why not?"
  7. # [00:08] <heycam> i really need to sort out my .procmailrc so that multiple copies of the same mail get put in different maildirs for the appropriate mailing lists
  8. # [00:08] <heycam> on that mail, all three copies (via public-html, via public-webapps, and the CCed one) just get dumped in my public-html maildir :/
  9. # [00:09] <shepazu> Hixie: I'm not gainsaying what SVG Tiny 1.2 says, but note that that is much more specific than SVG 1.1, and the SVG WG might be willing to adopt a different script processing model for SVG-in-text/html and SVG 2.0 than in SVG Tiny 1.2
  10. # [00:11] <shepazu> the goal for script processing in SVGT1.2 was to make it simpler and clearer, and I believe Opera had quite a lot of input there
  11. # [00:11] <heycam> and also to do effectively the same thing as html
  12. # [00:11] <shepazu> but if that causes problems for SVG-in-text/html, please feel free to make a proposal, and we will review it
  13. # [00:11] <heycam> if something's wrong there, i think we'd be pretty open to making an erratum for it
  14. # [00:12] <shepazu> yeah, I can't speak for everyone, but I'd tend to agree
  15. # [00:12] <heycam> Hixie, can you explain how the script blocking in HTML differs from that in SVG?
  16. # [00:12] <Hixie> shepazu: i don't think it causes any problems unless we actually want to support synchronous document.write()
  17. # [00:13] <Hixie> heycam: you were cc'ed because you contributed to some thread on the same topic over on the whatwg list
  18. # [00:13] <heycam> don't even remember saying anything about localStorage :)
  19. # [00:13] <heycam> Hixie, so SVG's script handling is not reentrant or something?
  20. # [00:13] <Hixie> let's see if i can construct an example
  21. # [00:13] <shepazu> this might be a relatively painless change, since there is unlikely to be content that relies heavily on the script processing model, and since browsers are really getting clearer on that, it would be a big win for SVG to align here
  22. # [00:14] <Hixie> (i can guarantee that this won't be painless, the text/html model is unbelievably complicated and brittle)
  23. # [00:14] <shepazu> oh, all the better
  24. # [00:14] <Hixie> imagine you have the following document:
  25. # [00:15] <Hixie> <html><script>A</script></html>
  26. # [00:15] <Hixie> and imagine the script A does the following:
  27. # [00:15] <Hixie> 1. document.write an external <script src="1"></script> block followed by an inline <script>2</script> block
  28. # [00:15] <Hixie> 2. document.append()s an inline <script>3</script> block
  29. # [00:16] <Hixie> the execution order will be, iirc, A, then 3, then 1, then 2
  30. # [00:16] <heycam> oh
  31. # [00:16] <Hixie> and in the DOM, the script nodes will be in the order 1, 3, 2
  32. # [00:16] <heycam> that is different from SVG then
  33. # [00:17] <shepazu> hmmm, well... at least this way, we'll be so numb with pain that we won't notice the order of processing
  34. # [00:17] * Quits: xcombelle (n=chatzill@AToulouse-158-1-21-252.w90-50.abo.wanadoo.fr) (Remote closed the connection)
  35. # [00:18] <Hixie> if we do as i propose, namely say that document.write() is not synchronous from an SVG script block, then if you replace <html> with <svg> in the text/html snippet above, the execution order would be A, 3, 1, 2
  36. # [00:18] <Hixie> and the DOM order will also be A, 3, 1, 2
  37. # [00:19] <heycam> if it's not synchronous, would it still be defined the order things get inserted/run? (a queue of them is maintained or something?)
  38. # [00:19] <Hixie> if you switch 1 and 2 around so that 1 is inline and 2 is external instead, then in HTML, the execution order, iirc, becomes A, 1, 3, 2 and the DOM order becomes A, 1, 2, 3
  39. # [00:19] <Hixie> but along my proposed model, in SVG it would still be A, 3, 1, 2 both in execution and DOM
  40. # [00:19] <shepazu> so, this sucks... honestly, I think the latter way is cleaner and more predictable, but paradoxically unintuitive because HTML does it the other way...
  41. # [00:20] <heycam> Hixie, does script processing differ in XHTML?
  42. # [00:20] <shepazu> then again, I don't know how much authors rely on execution order... any data?
  43. # [00:20] <Hixie> heycam: yeah, it's still all well-defined; you just end up parsing/executing all the document.written() stuff after the script ends
  44. # [00:20] <Hixie> heycam: in XHTML, document.write() throws.
  45. # [00:20] <heycam> awesome
  46. # [00:20] <heycam> :)
  47. # [00:20] <Hixie> yes.
  48. # [00:21] <shepazu> Hixie: can't you apply the same rules as you apply for SVG to XHTML?
  49. # [00:21] <Hixie> SVG in text/html?
  50. # [00:21] <shepazu> sorry, yes.
  51. # [00:21] <shepazu> (whichever those rules end up being)
  52. # [00:22] * Philip` isn't sure it's worth adding support for XHTML in text/html
  53. # [00:22] <Hixie> not really, because an SVG <script> block could just invoke an HTML <script> block and then we'd be back in the same world
  54. # [00:23] * shepazu is going to suggest a silly suggestion he will be crucified for: how about a new method, similar to .write(), that works async in all languages?
  55. # [00:23] <Hixie> we have that
  56. # [00:23] <Hixie> it's called document.appendChild()
  57. # [00:23] <Hixie> :-)
  58. # [00:23] <shepazu> oh.
  59. # [00:23] <shepazu> lol
  60. # [00:23] <shepazu> ok
  61. # [00:23] <heycam> given that the SVG spec only deals with SVG/XML, i wonder what the best way to define SVG script processing in text/html is -- i.e., in the SVG spec? or only in the HTML spec?
  62. # [00:23] <heycam> what changes would you need from the SVG spec for this?
  63. # [00:23] <Hixie> none
  64. # [00:24] <Hixie> if we want to just make document.write() async in SVG <script>
  65. # [00:24] <heycam> ok a secondary question then: does script processing in SVG/XML different from script processing in XHTML?
  66. # [00:24] <heycam> (my guess is yes?)
  67. # [00:24] <Hixie> if we want to make SVG use the same crazy-ass stuff HTML does, which we presumably would one if we ever want to support async="" or defer="" in SVG, then, uh, a lot. i dunno. see the <script> element definition in HTML5.
  68. # [00:24] <shepazu> sorry to stray here, but what about .innnerHTML()?
  69. # [00:25] <Hixie> innerHTML conveniently disables script execution.
  70. # [00:25] <shepazu> Hixie: we've already planned to add @async and @defer
  71. # [00:25] <Hixie> heycam: yes, though not in any particularly painful way other than SVG requiring sync I/O on the UI thread
  72. # [00:25] <Hixie> shepazu: oh.
  73. # [00:25] <Hixie> well that ought to be fun.
  74. # [00:25] * Quits: dimich (n=dimich@72.14.227.1)
  75. # [00:26] <heycam> Hixie, could you explain why sync I/O on the UI thread follows from the current script processing definitions in SVG?
  76. # [00:26] <Hixie> shepazu: in that case we really should just have svg and html use the same mechanism with the event loop and everything
  77. # [00:26] <shepazu> just so authors are dealing with the same platform
  78. # [00:26] <heycam> what i would like is for scripts in SVG/XML to act the same as those in XHTML
  79. # [00:27] <shepazu> I think it would be useful to summarize this in an email, if you don't mind...
  80. # [00:27] <Hixie> heycam: well, parsing and script execution block, and parsing happens as part of processing a task on the event loop.
  81. # [00:27] * Quits: aroben (n=aroben@unaffiliated/aroben) ("Leaving")
  82. # [00:27] <heycam> perhaps then it is just a matter of poor wording on my part then in that script processing section
  83. # [00:28] <Hixie> shepazu: summarise what?
  84. # [00:28] <heycam> it should just block the parser, no?
  85. # [00:28] <Hixie> heycam: the parser is on the ui thread (well, on the event loop)
  86. # [00:28] <Hixie> heycam: put it this way:
  87. # [00:29] <Hixie> heycam: what happens if an external SVG <script> is inserted, does the appendChild() call return before or after the script runs?
  88. # [00:30] <heycam> by the current text, i think it is after
  89. # [00:30] <Hixie> oh. that's different than html.
  90. # [00:30] <heycam> ok
  91. # [00:30] <Hixie> so if i appendChild() two <Script> blocks back to back
  92. # [00:30] <Hixie> the second will be inserted before the first executes?
  93. # [00:30] <Hixie> when will it execute?
  94. # [00:30] <Hixie> i don't understand the model anymore. :-/
  95. # [00:31] * Joins: annodomini (n=lambda@wikipedia/lambda)
  96. # [00:32] * heycam brb
  97. # [00:34] * Quits: dglazkov (n=dglazkov@nat/google/x-7806233b6d1c0733)
  98. # [00:35] * Quits: nessy (n=nessy@124-168-165-203.dyn.iinet.net.au) (Remote closed the connection)
  99. # [00:49] <heycam> i think my intention was for the first to be inserted, then executed, then the second is inserted, then executed
  100. # [00:50] <heycam> if you want to mail www-svg with suggestions on making it saner / more compatible with XHTML, that'd be appreciated
  101. # [00:51] <Hixie> i don't really know what to suggest, short of just referencing html5's processing model and defining everything either in terms of tasks and event loops or the scripting lists
  102. # [00:51] <heycam> :)
  103. # [00:51] <Hixie> but i don't see much point in saying that in e-mail
  104. # [00:52] <heycam> maybe i need to take a closer read of the html5 model
  105. # [00:52] <Hixie> ("hi please depend on my spec that i've said isn't going to be ready for a decade k thx bye" isn't likely to go down well)
  106. # [00:52] <heycam> ha
  107. # [00:52] <heycam> anyway, for the svg script in text/html case, i think you can just do whatever is sensible
  108. # [00:53] <Hixie> (to be honest though i think long term we probably will have to use a common event loops model)
  109. # [00:53] <heycam> sounds sensible
  110. # [00:54] <heycam> that'd be one of those things that would go into a split out "Web platform" spec (with things like Window, etc.)
  111. # [00:54] <annevk3> If I define XMLHttpRequest in terms of event loops SVG would need to be defined in it too for it to work "right"... In theory anyway.
  112. # [00:54] <Hixie> heycam: yeah... let me know when you find someone to do that! :-)
  113. # [00:54] <heycam> :)
  114. # [00:55] <Hixie> i know it wouldn't be a popular suggestion but i'm somewhat of the opinion that at this point html and the core dom stuff are so tightly bound together that we should just keep them in one spec and have everything depend on html
  115. # [00:55] <Hixie> but i know that would offend the purists
  116. # [00:55] <heycam> indeed i think it wouldn't be a popular suggestion :)
  117. # [00:56] <Hixie> so right now the web sockets, web storage, web workers, html5, and event source specs are all generated from one source document
  118. # [00:57] <heycam> those other things seem much more easily separable than "web platform" stuff though
  119. # [00:57] <Hixie> yes, absolutely
  120. # [00:57] <heycam> at least from a single-source-document-generating-them PoV
  121. # [00:57] <Hixie> if it wasn't for hte obvious process issues with it, and the difficulty of coordinating work, it would be interesting to consider putting svg, dom core and dom events, http, and pretty much everything else into that same document
  122. # [00:58] <heycam> it might make certain things easier (cross references e.g.)
  123. # [00:58] <Hixie> i'm considering hosting a spec on the whatwg site that is web sockets, web storage, web workers, html5, and event source in one doc
  124. # [00:58] <Hixie> heycam: yeah, exactly
  125. # [00:58] <Hixie> anyway realistically this has zero chance of happening
  126. # [00:58] <annevk3> it's also an awful lot of work
  127. # [00:59] <Hixie> yeah
  128. # [00:59] <Hixie> thing is
  129. # [00:59] <Hixie> we already have to do that work
  130. # [00:59] <Hixie> zcorpan is rewriting dom core
  131. # [00:59] <annevk3> i.e. I can't even begin to imagine rewriting CSS the HTML5 way though I think it should be done :)
  132. # [00:59] <Hixie> dom events is probably going to need a rewrite at some point
  133. # [00:59] <Hixie> css needs a rewrite now that 2.1 has nailed down the behavior, so that it actually is defined in a sane way
  134. # [01:00] * Quits: wakaba_ (n=wakaba@87.162.210.220.dy.bbexcite.jp) ("Leaving...")
  135. # [01:00] <heycam> dom 3 events is being worked on at the moment. maybe you can comment on it?
  136. # [01:00] <Hixie> range and traversal desperately need rewrites
  137. # [01:00] <Hixie> svg is pretty vague, as noted by the questions we just had about <script> behavior
  138. # [01:00] <Hixie> etc
  139. # [01:00] <annevk3> and everyone is inventing new features on top of the undefined stuff
  140. # [01:00] <annevk3> yay
  141. # [01:01] * fakeolliej is now known as olliej
  142. # [01:02] <Hixie> heycam: my comments on dom3 events would be along the same lines as my comments on svg
  143. # [01:02] <Hixie> heycam: and thus likely just as unpopular
  144. # [01:02] <annevk3> and in ten years we'll prolly discuss mistakes similar to cross-origin <script>, global object mess, etc.
  145. # [01:02] <heycam> "whine whine this isn't defined well enough blah blah" :)
  146. # [01:02] <annevk3> "and please drop the namespace crap"
  147. # [01:03] <Hixie> heycam: (i'd recommend splitting out the events into a separate doc that actually defines when they fire, i'd recommend rewriting all the dom api definitions to actually be phrased as requirements not descriptions, and i'd suggest making everything be defined in terms of the event loop mechanism)
  148. # [01:04] <heycam> shepazu, ↑
  149. # [01:04] <Hixie> heh
  150. # [01:04] <Hixie> i'm sure i've discussed this with him before :-)
  151. # [01:04] <heycam> ok
  152. # [01:04] <Hixie> i had similar comments on the progress spec with chaals
  153. # [01:05] <Hixie> e.g. the dom apis are vague, the spec has far too many redundant or untestable requirements, the spec shouldn't have conforming requirements defined for author scripts, and there are no or few hooks defined for specs using the technology
  154. # [01:05] <Hixie> chaals disagrees :-)
  155. # [01:05] <Hixie> and who's to say he's not right and i'm not wrong
  156. # [01:06] <annevk3> I'd say he's wrong, but I'm biased
  157. # [01:07] <heycam> biased against him because he's your boss? :)
  158. # [01:07] <Hixie> i'd say if you had a bias you'd be biased in his favour but ok :-)
  159. # [01:08] <atw> MessagePorts are supposed to implement EventTarget - does that mean that if I register an onmessage listener on a port, that my onmessage listener can get a reference to the port via the event.target attribute? Or is that only for DOM events?
  160. # [01:08] <Hixie> yes, it does mean that
  161. # [01:08] <annevk3> well yeah, I'm biased both ways, but chaals appreciates honesty
  162. # [01:08] <Hixie> annevk3: feel free to support me on the list then :-P
  163. # [01:09] <annevk3> Hixie, since when are we doing +1 emails? :p
  164. # [01:09] <Hixie> :-P
  165. # [01:09] <atw> That implies that we can't GC message ports if there are any messages in-flight even if there are no references to either endpoint's message port, since the messages themselves contain an inherent reference to the port. I could ping-pong messages back and forth between two ports using only listeners, with no active references to the ports.
  166. # [01:10] <Hixie> atw: correct, the spec even explicitly says that iirc
  167. # [01:11] <atw> Not so - the spec says: "Thus, a message port can be received, given an event listener, and then forgotten, and so long as that event listener could receive a message, the channel will be maintained.
  168. # [01:11] <atw> Of course, if this was to occur on both sides of the channel, then both ports would be garbage collected, since they would not be reachable from live code, despite having a strong reference to each other."
  169. # [01:11] <atw> Ah, but.
  170. # [01:11] <atw> The next line :)
  171. # [01:12] <atw> It does say that you can't GC a port while there's a message in flight, and the previous paragraph implies that this would keep the entangled port from being GC'd. OK, thnx.
  172. # [01:12] <atw> I for some reason couldn't hold those two facts in my brain at once.
  173. # [01:12] <Hixie> i can make it clearer if you want
  174. # [01:12] <Hixie> drop me a mail?
  175. # [01:12] <Hixie> i'm in the middle of the svg edits right now
  176. # [01:12] <Hixie> so can't make changes
  177. # [01:12] <atw> Sure, but in retrospect I think it's plenty clear. Thx.
  178. # [01:13] * Joins: bgalbraith (n=bgalbrai@corp-241.mountainview.mozilla.com)
  179. # [01:15] * Parts: ojan (n=ojan@72.14.229.81)
  180. # [01:16] * Quits: MikeSmith (n=MikeSmit@EM114-48-133-202.pool.e-mobile.ne.jp) (Read error: 104 (Connection reset by peer))
  181. # [01:29] * Quits: olliej (n=oliver@nat/apple/x-211fdd897d34a195)
  182. # [01:30] <annevk3> Hixie, SVG is going to be commented "in"?
  183. # [01:30] <annevk3> (I guess the quotemarks should have been around commented....)
  184. # [01:31] * annevk3 clearly needs to go to sleep; night all!
  185. # [01:31] * Joins: olliej (n=oliver@nat/apple/x-9fa25b7c394cb0e7)
  186. # [01:35] * Quits: bgalbraith (n=bgalbrai@corp-241.mountainview.mozilla.com)
  187. # [01:42] * Parts: olliej (n=oliver@nat/apple/x-9fa25b7c394cb0e7)
  188. # [01:42] * Quits: tantek__ (n=tantek@c-67-160-236-52.hsd1.ca.comcast.net)
  189. # [01:46] * Joins: olliej (n=oliver@nat/apple/x-78722e6bd9d2d6d7)
  190. # [01:50] * Quits: olliej (n=oliver@nat/apple/x-78722e6bd9d2d6d7) (Client Quit)
  191. # [01:51] <Lachy> Hixie, personally, I think supporting <![CDATA[]]> sections in SVG scripts, but not in HTML scripts is silly. I would prefer that we just made <script> parse as CDATA for both HTML and SVG, as that makes it easier for authors
  192. # [01:51] <Lachy> well, at least, it makes it more consistent
  193. # [01:51] <Hixie> we can't do that while satisfying the svgwg's goal
  194. # [01:51] <Lachy> I don't agree with the SVG WG's goal
  195. # [01:52] <Hixie> neither do i, but we can't just throw out people's requirements willy nilly just because we don't like them
  196. # [01:52] <Lachy> I think making SVG as XML entirely compatible with text/html, including XML's syntactic sugar, is a non-goal
  197. # [01:52] <Lachy> er, I don't think I said that quite right. But you should get what I mean
  198. # [01:52] * Joins: olliej (n=oliver@nat/apple/x-29175c3d6ffb901d)
  199. # [01:53] <Hixie> their goal is to be able to take svg documents created by xml serialisers and paste them into text/html docs
  200. # [01:53] <Lachy> yeah. I don't agree with that
  201. # [01:53] <Hixie> you think we should prevent it, or you think it's not important?
  202. # [01:53] <Hixie> i.e. do you think it's an anti-goal, or a non-goal?
  203. # [01:53] <Lachy> I think text/html SVG and XML SVG should be just as compatible as HTML and XHTML
  204. # [01:54] * Joins: MikeSmith (n=MikeSmit@EM114-48-191-34.pool.e-mobile.ne.jp)
  205. # [01:54] <Hixie> that's a fine goal too, but it conflicts with their goal
  206. # [01:54] <Lachy> I know. i don't care about their goal
  207. # [01:55] <Hixie> they do
  208. # [01:55] <Lachy> I care about making the authoring requirements consistent for authors
  209. # [01:56] <Hixie> they care about being able to paste svg images into text/html
  210. # [01:57] <Hixie> wtf, windows is actually forcing me to reboot with a 30 minute countdown
  211. # [01:58] <Lachy> sure. But I don't think it's necessary to be able to do that with SVG designed for XML processing to be copy and pasteable entirely without modification. I think requiring authors to strip (or comment out) unsupported XML syntactic sugar like CDATA sections
  212. # [01:58] <Hixie> and they disagree
  213. # [01:58] <Lachy> so the same way authors do <script>/*<![CDATA[ */ ... /* ]]> */</script> for XHTML as text/html, so should they for SVG as text/html
  214. # [01:58] <Hixie> this is why opinion-based arguments don't work. there's no way to win them.
  215. # [01:59] <Lachy> mine isn't opinion based. It's based on making rules consistent for authors
  216. # [01:59] <Lachy> so hand coding is easier
  217. # [02:01] <shepazu> what about sicking's suggestion for script/css CDATA parsing?
  218. # [02:01] <Hixie> and theirs isn't opinion based, it's based on making authoring easier for authors
  219. # [02:01] <Hixie> so hand coding is easier
  220. # [02:01] <Hixie> (they're both opinions)
  221. # [02:01] <Hixie> shepazu: that breaks your goal
  222. # [02:02] <shepazu> hmmm... how so?
  223. # [02:02] <heycam> the opinion part of it is which is more important: hand authoring, or paste authoring from existing SVG authoring tools
  224. # [02:02] <shepazu> sorry if I'm being dense, but it seemed to solve the issue...
  225. # [02:02] * Quits: weinig (n=weinig@17.246.16.246)
  226. # [02:03] <Hixie> shepazu: making text/html not use xml-like parsing means that you can't guarantee that an xml svg file will work in text/html, no?
  227. # [02:04] <Lachy> Hixie, the SVG WG's goals seem to be to try and maintain as much XML-like strictness as possible. I have not seen any suggestion from the SVG WG specifically designed to optimise hand coding
  228. # [02:04] * Quits: tndH (n=Rob@adsl-77-86-107-105.karoo.KCOM.COM) ("ChatZilla 0.9.84-rdmsoft [XULRunner 1.9.0.1/2008072406]")
  229. # [02:05] <Lachy> anyway, I'm not looking forward to try and explain the rules for dealing with script elements to authors now that the rules differ for HTML and SVG fragments.
  230. # [02:05] <shepazu> I thought sicking suggested supporting <![CDATA[]]> sections in HTML scripts and SVG scripts?
  231. # [02:05] * Joins: xydyx (n=hdh@118.71.77.216)
  232. # [02:06] <Hixie> i don't see any sane way to support <![CDATA[ ]]> in regular HTML given the crazy "magic <!-- -->" processing
  233. # [02:06] <shepazu> <![CDATA[]]> is not strictly necessary with SVG scripts... just when Offending Characters might be present, right?
  234. # [02:06] <Hixie> <![CDATA[ ]]> is never necessary in XML
  235. # [02:07] <Hixie> it's just a syntactic alternative to escaping characters using numeric character references ("entities")
  236. # [02:07] <heycam> i think it was a mistake for CDATA sections to be exposed in the DOM
  237. # [02:07] <shepazu> right
  238. # [02:08] <Lachy> shepazu, the problem is when authors using XML don't use CDATA sections and encode <, >, and & as character refs
  239. # [02:08] <Hixie> heycam: me too, but that's actually academic here
  240. # [02:08] <Lachy> when they do use them, the solution to make the script compatible with both XML and text/html is to comment out the <![CDATA[ ]]> markup. with /* */ or //
  241. # [02:09] <Hixie> the best thing would be to have a browser with significant market share implement a consistent mechanism (whatever that might be), and prove that it doesn't break sites and is implementable
  242. # [02:10] <Hixie> changing html parsing rules is a very dangerous sport
  243. # [02:10] <Hixie> and not one i particularly enjoy
  244. # [02:10] <shepazu> I thought that sicking seemed to say that you *could* do CDATA in script and style?
  245. # [02:10] <Hixie> sicking: can you explain to me how you would do it?
  246. # [02:10] <Hixie> i didn't see anything that wasn't rather handwavy
  247. # [02:11] <Hixie> and the parsing of CDATA blocks in text/html (not <![CDATA[ ]]> blocks) is significantly non-trivial right now
  248. # [02:11] <shepazu> (Hixie, did you BCC me on that email? I got 3 copies)
  249. # [02:11] <Hixie> yeah, i bcc'ed anyone who wrote an e-mail on the thread
  250. # [02:11] <shepazu> ok, thanks, mystery solved
  251. # [02:14] * Quits: heycam (n=cam@zot.infotech.monash.edu.au) ("bye")
  252. # [02:14] <Lachy> ah, that explains why I got an extra copy, even though I wasn't quoted. Though I don't remember writing anything in that thread
  253. # [02:21] * Quits: hdh (n=hdh@118.71.77.119) (Read error: 113 (No route to host))
  254. # [02:22] * Joins: heycam (n=cam@zot.infotech.monash.edu.au)
  255. # [02:34] * Quits: davidb (n=davidb@bas4-toronto06-1242458518.dsl.bell.ca)
  256. # [02:47] * Quits: jwalden (n=waldo@corp-241.mountainview.mozilla.com) (Remote closed the connection)
  257. # [03:08] * Joins: taf2 (n=taf2@c-68-49-245-59.hsd1.dc.comcast.net)
  258. # [03:10] * Joins: dglazkov (n=dglazkov@c-98-207-88-44.hsd1.ca.comcast.net)
  259. # [03:15] * Joins: kig (i=ilmarihe@melkki.cs.helsinki.fi)
  260. # [03:15] * Quits: erlehmann (n=erlehman@86.59.25.121) (Read error: 110 (Connection timed out))
  261. # [03:17] * Quits: mpilgrim (n=mark@rrcs-96-10-240-189.midsouth.biz.rr.com) (Read error: 113 (No route to host))
  262. # [03:37] * Quits: dglazkov (n=dglazkov@c-98-207-88-44.hsd1.ca.comcast.net)
  263. # [03:41] * Quits: taf2 (n=taf2@c-68-49-245-59.hsd1.dc.comcast.net)
  264. # [03:41] * Quits: dave_levin (n=dave_lev@72.14.227.1)
  265. # [03:42] * Joins: taf2 (n=taf2@c-68-49-245-59.hsd1.dc.comcast.net)
  266. # [03:43] * Joins: erlehmann (n=erlehman@86.59.25.121)
  267. # [03:43] * Joins: dglazkov (n=dglazkov@c-98-207-88-44.hsd1.ca.comcast.net)
  268. # [03:48] <gsnedders> http://code.google.com/p/html5lib/source/list — there's far too much me there
  269. # [03:52] * Joins: karlcow (n=karl@nerval.la-grange.net)
  270. # [03:58] * Parts: erlehmann (n=erlehman@86.59.25.121)
  271. # [04:03] * Quits: heycam (n=cam@zot.infotech.monash.edu.au) ("bye")
  272. # [04:11] * Joins: Kuruma (n=Kuruman@www1664.sakura.ne.jp)
  273. # [04:11] * Joins: dave_levin (n=dave_lev@72.14.224.1)
  274. # [04:19] * Joins: heycam (n=cam@zot.infotech.monash.edu.au)
  275. # [04:24] * Quits: taf2 (n=taf2@c-68-49-245-59.hsd1.dc.comcast.net)
  276. # [04:26] * Joins: slightlyoff (n=slightly@67.218.105.209)
  277. # [04:29] * Joins: tantek (n=tantek@c-67-160-236-52.hsd1.ca.comcast.net)
  278. # [04:52] * Joins: hdh (n=hdh@118.71.77.216)
  279. # [04:53] * Quits: roc (n=roc@202.0.36.64)
  280. # [04:53] * Joins: roc (n=roc@202.0.36.64)
  281. # [04:54] * Quits: slightlyoff (n=slightly@67.218.105.209)
  282. # [05:10] * Quits: xydyx (n=hdh@118.71.77.216) (Success)
  283. # [05:15] * Quits: tantek (n=tantek@c-67-160-236-52.hsd1.ca.comcast.net)
  284. # [05:20] <gsnedders> Weee… from 136s (r1274) to 50s (HEAD) to tokenize the spec
  285. # [05:20] * Quits: hdh (n=hdh@118.71.77.216) (Remote closed the connection)
  286. # [05:41] * Quits: roc (n=roc@202.0.36.64)
  287. # [05:45] * Quits: dglazkov (n=dglazkov@c-98-207-88-44.hsd1.ca.comcast.net)
  288. # [05:50] * Joins: nessy (n=nessy@124-168-165-203.dyn.iinet.net.au)
  289. # [06:06] * Quits: doublec (n=doublec@202.0.36.64) ("Leaving")
  290. # [06:57] * Quits: annodomini (n=lambda@wikipedia/lambda)
  291. # [07:05] * Quits: heycam (n=cam@zot.infotech.monash.edu.au) ("bye")
  292. # [07:06] * Joins: olliej_ (n=oliver@c-67-164-125-23.hsd1.ca.comcast.net)
  293. # [07:14] * Joins: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  294. # [07:37] * Quits: MikeSmith (n=MikeSmit@EM114-48-191-34.pool.e-mobile.ne.jp) ("Tomorrow to fresh woods, and pastures new.")
  295. # [07:40] * Joins: jwalden (n=waldo@c-76-102-160-171.hsd1.ca.comcast.net)
  296. # [07:45] * Joins: heycam (n=cam@124-168-80-126.dyn.iinet.net.au)
  297. # [07:49] * Joins: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de)
  298. # [07:58] * Joins: itpastorn (n=itpastor@139.57.227.87.static.th.siw.siwnet.net)
  299. # [08:04] * Parts: itpastorn (n=itpastor@139.57.227.87.static.th.siw.siwnet.net)
  300. # [08:06] * Joins: danbri (n=danbri@s55927ef8.adsl.wanadoo.nl)
  301. # [08:07] * Quits: nessy (n=nessy@124-168-165-203.dyn.iinet.net.au) ("This computer has gone to sleep")
  302. # [08:10] * Joins: zalan (n=kvirc@80.99.193.98)
  303. # [08:20] * Joins: ap (n=ap@194.154.88.41)
  304. # [08:22] <hsivonen> lots of scrollback :-(
  305. # [08:32] <shepazu> here's the summary, hsivonen: SVG script is easier and more consistent than HTML script, so we will probably go with HTML's model, and Hixie rejected all the SVG WG's feedback for SVG-in-HTML
  306. # [08:33] <hsivonen> shepazu: thanks. I also read the logs at krijnhoetmer.nl. writing email now
  307. # [08:33] <shepazu> the speed with which he did so suggests a remarkably organized mind with a singular coherency of thought
  308. # [08:44] * Joins: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl)
  309. # [08:45] * Quits: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  310. # [08:47] * Joins: pesla (n=retep@procurios.xs4all.nl)
  311. # [09:02] * Joins: itpastorn (n=itpastor@ne.keryx.se)
  312. # [09:14] * Quits: dave_levin (n=dave_lev@72.14.224.1)
  313. # [09:23] * Quits: itpastorn (n=itpastor@ne.keryx.se) (Read error: 104 (Connection reset by peer))
  314. # [09:24] * Joins: itpastorn (n=itpastor@ne.keryx.se)
  315. # [09:37] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  316. # [09:37] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Read error: 104 (Connection reset by peer))
  317. # [09:37] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  318. # [09:41] * Quits: ap (n=ap@194.154.88.41)
  319. # [09:47] * Joins: pesla\work (n=retep@78-27-53-137.dsl.alice.nl)
  320. # [09:56] * Quits: mpt (n=mpt@canonical/launchpad/mpt) ("Ex-Chat")
  321. # [10:04] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  322. # [10:05] * Quits: pesla (n=retep@procurios.xs4all.nl) (Read error: 110 (Connection timed out))
  323. # [10:06] * Quits: pesla\work (n=retep@78-27-53-137.dsl.alice.nl) (Read error: 110 (Connection timed out))
  324. # [10:30] <annevk3> http://www.w3.org/mid/1e3451610903250034g69513bdvedd39f04dc270339@mail.gmail.com o_O
  325. # [10:31] * Joins: doublec (n=doublec@118-93-172-205.dsl.dyn.ihug.co.nz)
  326. # [10:35] * Joins: mat_t (n=mattomas@nat/canonical/x-495adc23aea44c9a)
  327. # [10:43] * annevk3 was hoping hsivonen would run the sane script story campaign :)
  328. # [10:55] <Hixie> ok bed time nn
  329. # [10:55] * jgraham wonders what the sane script story campaign is
  330. # [10:55] <jgraham> gn
  331. # [10:55] <hsivonen> nn
  332. # [10:56] <annevk3> jgraham, run scripts the same way in text/html regardless of whether they are SVG or HTML <script> elements
  333. # [10:57] <jgraham> Ah, OK. I thought by "sane" you might mean doing something other than html behaviour
  334. # [10:57] <jgraham> (which would be silly but could be described as "sane")
  335. # [10:58] <jgraham> (as the opposite to "insane script handling required by html")
  336. # [10:58] <annevk3> I'm not necessarily saying that's what in the spec now is insane. I just needed to name my campaign :p
  337. # [10:59] <jgraham> Well I agree doing anything inconsistent is insane
  338. # [10:59] <jgraham> More insane than just copying whatever HTML already does
  339. # [10:59] <jgraham> However weird
  340. # [11:05] * Quits: itpastorn (n=itpastor@ne.keryx.se) ("Leaving.")
  341. # [11:08] * Joins: ROBOd (n=robod@89.122.216.38)
  342. # [11:11] * Joins: svl (n=chatzill@a194-109-2-36.dmn.xs4all.nl)
  343. # [11:14] * Joins: itpastorn (n=itpastor@ne.keryx.se)
  344. # [11:20] * Quits: olliej_ (n=oliver@c-67-164-125-23.hsd1.ca.comcast.net)
  345. # [11:21] <jgraham> For someone who thinks that it is a wate of time to discuss rsayre is really fast to reply
  346. # [11:24] * Joins: MikeSmith (n=MikeSmit@EM114-48-77-51.pool.e-mobile.ne.jp)
  347. # [11:25] <MikeSmith> hsivonen: you around?
  348. # [11:28] <hsivonen> MikeSmith: yes
  349. # [11:28] <hsivonen> MikeSmith: I saw the scrollback. Haven't processed the Schematron part yet.
  350. # [11:29] <MikeSmith> hsivonen: I made a minor change just to some message strings in the Assertions.java source
  351. # [11:29] <MikeSmith> built and tested it with my local v.nu instance and no problems and works as expected
  352. # [11:30] <hsivonen> MikeSmith: great. feel free to check in
  353. # [11:30] <MikeSmith> OK
  354. # [11:30] <MikeSmith> will do
  355. # [11:30] <hsivonen> MikeSmith: thanks!
  356. # [11:31] <MikeSmith> and I'm looking at the Assertions.java source now to try go see if I can add the label@for constraints
  357. # [11:44] * Quits: MikeSmith (n=MikeSmit@EM114-48-77-51.pool.e-mobile.ne.jp) ("Tomorrow to fresh woods, and pastures new.")
  358. # [11:47] * Joins: nessy (n=nessy@124-168-165-203.dyn.iinet.net.au)
  359. # [11:49] * Joins: ap (n=ap@194.154.88.41)
  360. # [12:01] * Quits: Lachy (n=Lachlan@85.196.122.246) ("This computer has gone to sleep")
  361. # [12:17] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  362. # [12:21] * Joins: mstange (n=markus@pD9579410.dip0.t-ipconnect.de)
  363. # [12:27] * Joins: tndH (n=Rob@adsl-77-86-107-105.karoo.KCOM.COM)
  364. # [12:29] * Joins: myakura (n=myakura@122.29.116.63)
  365. # [12:32] * Joins: taf2 (n=taf2@c-68-49-245-59.hsd1.dc.comcast.net)
  366. # [12:36] * Parts: kig (i=ilmarihe@melkki.cs.helsinki.fi)
  367. # [12:41] * Joins: pauld (n=pauld@host86-133-17-49.range86-133.btcentralplus.com)
  368. # [13:05] * Quits: nessy (n=nessy@124-168-165-203.dyn.iinet.net.au) ("This computer has gone to sleep")
  369. # [13:19] * Quits: taf2 (n=taf2@c-68-49-245-59.hsd1.dc.comcast.net)
  370. # [13:22] * Joins: aroben (n=aroben@unaffiliated/aroben)
  371. # [13:23] * Quits: doublec (n=doublec@118-93-172-205.dsl.dyn.ihug.co.nz) ("Leaving")
  372. # [13:36] * Quits: mat_t (n=mattomas@nat/canonical/x-495adc23aea44c9a) ("This computer has gone to sleep")
  373. # [14:29] * Joins: taf2 (n=taf2@65.210.82.235)
  374. # [14:31] * Parts: annevk3 (n=annevk@77.163.243.203)
  375. # [14:32] * Joins: davidb (n=davidb@76.64.59.165)
  376. # [14:32] * Joins: mpilgrim (n=mark@155.229.51.170)
  377. # [14:34] * Joins: mat_t (n=mattomas@nat/canonical/x-9ec96ea626317a01)
  378. # [14:36] * Joins: annevk3 (n=annevk@77.163.243.203)
  379. # [14:36] * Joins: annodomini (n=lambda@wikipedia/lambda)
  380. # [14:37] * Quits: annodomini (n=lambda@wikipedia/lambda) (Client Quit)
  381. # [14:43] * Parts: itpastorn (n=itpastor@ne.keryx.se)
  382. # [14:54] * Quits: mstange (n=markus@pD9579410.dip0.t-ipconnect.de) ("ChatZilla 0.9.84-2009030221 [Firefox 3.6a1pre/20090324030703]")
  383. # [15:04] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Remote closed the connection)
  384. # [15:06] * Joins: mstange (n=markus@pD9579410.dip0.t-ipconnect.de)
  385. # [15:07] * Quits: zalan (n=kvirc@80.99.193.98) (Read error: 110 (Connection timed out))
  386. # [15:07] * Joins: dglazkov (n=dglazkov@c-98-207-88-44.hsd1.ca.comcast.net)
  387. # [15:09] * Joins: zdobersek (n=zan@cpe-92-37-68-207.dynamic.amis.net)
  388. # [15:14] * Joins: annodomini (n=lambda@wikipedia/lambda)
  389. # [15:22] * Quits: mpilgrim (n=mark@155.229.51.170) (Read error: 104 (Connection reset by peer))
  390. # [15:50] <Lachy> it seems really strange that attempting to get the insertId attribute can potentially raise an exception. http://dev.w3.org/html5/webstorage/#dom-sqlresultset-insertid
  391. # [15:54] * Joins: sid0_ (n=sid0@unaffiliated/sid0)
  392. # [16:01] * Quits: dglazkov (n=dglazkov@c-98-207-88-44.hsd1.ca.comcast.net)
  393. # [16:03] * Joins: hdh (n=hdh@58.187.21.114)
  394. # [16:04] <jgraham> Should contentEditable elements be focusable?
  395. # [16:05] <Philip`> Hmm, my laptop's CPU fan seems to have become noisy, and the only way I can find to fix it is to run "perl -e'fork; 1 while 1'" for a minute so my CPU gets really hot and the fan goes to maximum speed, and then press the Tab or Caps lock or Q key, which makes the fan stop annoyingly whirring, and then it's fine once I let it cool down
  396. # [16:05] * jgraham wonders how Philip` managed to find that methodology
  397. # [16:06] * Philip` wonders if there's a more direct solution, that doesn't involve disassembling his laptop using screwdrivers that he doesn't have
  398. # [16:06] <Philip`> jgraham: It seemed a pretty obvious plan to me
  399. # [16:07] <jgraham> Philip`: Hit your laptop with a large hammer. Hard. It will soon stop making any annoying noise
  400. # [16:07] <Philip`> The whirring changed when I pressed down on the keyboard directly over the fan, so it seemed reasonable to try changing the fan speed and seeing if it spun itself back into a quiet state
  401. # [16:08] <Philip`> (The problem came back after I switched it off and on again, so I had an opportunity to discover the solution was repeatable)
  402. # [16:08] <Philip`> jgraham: Don't have a hammer
  403. # [16:09] <Philip`> and if I went to a store to purchase a hammer, I should purchase some screwdrivers too
  404. # [16:09] * Quits: sid0 (n=sid0@unaffiliated/sid0) (Remote closed the connection)
  405. # [16:09] <jgraham> Philip`: A brick? A tin of beans?
  406. # [16:10] <Philip`> I suppose I could bash it with another laptop
  407. # [16:14] * Joins: zdobersek1 (n=zan@cpe-92-37-72-115.dynamic.amis.net)
  408. # [16:16] * Joins: dglazkov (n=dglazkov@nat/google/x-841424654c544763)
  409. # [16:19] * Quits: dglazkov (n=dglazkov@nat/google/x-841424654c544763) (Client Quit)
  410. # [16:19] * Joins: dglazkov (n=dglazkov@216.239.45.4)
  411. # [16:20] * Joins: zalan (n=kvirc@80.99.193.98)
  412. # [16:22] <svl> http://ilia.ws/archives/196-IE8-X-UA-Compatible-Rant.html :/
  413. # [16:29] * Quits: zdobersek (n=zan@cpe-92-37-68-207.dynamic.amis.net) (Read error: 110 (Connection timed out))
  414. # [16:29] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (Read error: 110 (Connection timed out))
  415. # [16:29] * Joins: sid0 (n=sid0@unaffiliated/sid0)
  416. # [16:32] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
  417. # [16:41] * Joins: mlpug (n=mlpug@a91-156-60-13.elisa-laajakaista.fi)
  418. # [16:43] * Quits: sid0_ (n=sid0@unaffiliated/sid0) (Remote closed the connection)
  419. # [16:54] * Joins: weinig (n=weinig@67.180.35.124)
  420. # [17:04] * Quits: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl) ("Disconnected...")
  421. # [17:04] * Joins: bgalbraith (n=bgalbrai@corp-241.mountainview.mozilla.com)
  422. # [17:07] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Read error: 60 (Operation timed out))
  423. # [17:19] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  424. # [17:21] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
  425. # [17:25] * Quits: mstange (n=markus@pD9579410.dip0.t-ipconnect.de) ("ChatZilla 0.9.84-2009030221 [Firefox 3.6a1pre/20090325032457]")
  426. # [17:25] * Quits: sid0 (n=sid0@unaffiliated/sid0) (Remote closed the connection)
  427. # [17:29] * Joins: sid0 (n=sid0@unaffiliated/sid0)
  428. # [17:32] * Quits: sid0 (n=sid0@unaffiliated/sid0) (Client Quit)
  429. # [17:35] * Joins: davidb_ (n=davidb@bas4-toronto06-1279277989.dsl.bell.ca)
  430. # [17:35] * Quits: davidb (n=davidb@76.64.59.165) (Read error: 104 (Connection reset by peer))
  431. # [17:36] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Read error: 113 (No route to host))
  432. # [17:39] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  433. # [17:47] * Joins: dave_levin (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net)
  434. # [17:54] * Quits: myakura (n=myakura@122.29.116.63) ("Leaving...")
  435. # [17:56] * Joins: Maurice (n=copyman@5ED548D4.cable.ziggo.nl)
  436. # [18:04] * Quits: weinig (n=weinig@67.180.35.124)
  437. # [18:13] * Joins: smaug (n=chatzill@cs181146100.pp.htv.fi)
  438. # [18:17] * Quits: dave_levin (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net)
  439. # [18:17] * Quits: hdh (n=hdh@58.187.21.114) (Remote closed the connection)
  440. # [18:20] * Joins: Lachy (n=Lachlan@85.196.122.246)
  441. # [18:38] * Quits: pauld (n=pauld@host86-133-17-49.range86-133.btcentralplus.com)
  442. # [18:39] <atw> The chrome team is wondering about the behavior of window.postMessage() - since the destination window/iframe may not be loaded yet, what is the expected behavior if I post a message to a window whose contents aren't yet loaded. Should the message get dropped on the floor, or queued?
  443. # [18:39] <atw> Both Safari and Chrome just drop it on the floor now, which seems unideal.
  444. # [18:54] * Joins: dave_levin (n=dave_lev@72.14.227.1)
  445. # [18:56] * Joins: mstange (n=markus@pD9579410.dip0.t-ipconnect.de)
  446. # [19:02] * Quits: mat_t (n=mattomas@nat/canonical/x-9ec96ea626317a01) ("This computer has gone to sleep")
  447. # [19:04] * Quits: svl (n=chatzill@a194-109-2-36.dmn.xs4all.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  448. # [19:10] <gsnedders> Philip`: How many tags have mixed case names?
  449. # [19:10] * Joins: dimich (n=dimich@72.14.227.1)
  450. # [19:11] <jwalden> atw: why is this a problem? I always understood postMessage to be for establishing communication with an already-loaded window, most particularly an iframe during the parent window's onload
  451. # [19:12] * Joins: weinig (n=weinig@17.246.16.246)
  452. # [19:14] <Philip`> gsnedders: About six
  453. # [19:15] <Philip`> gsnedders: I see 4580419 tags matching [a-z], 594677 [A-Z], and 5585 matching both
  454. # [19:15] <jwalden> atw: that's also interoperable with Gecko, fwiw; IE is too much effort for me to test right now
  455. # [19:16] * Quits: dave_levin (n=dave_lev@72.14.227.1)
  456. # [19:16] <atw> jwalden: Why would postMessage() not be useful for communicating with other windows?
  457. # [19:17] <gsnedders> Philip`: thx
  458. # [19:17] <jwalden> atw: um, please rephrase to ask what you meant to ask :-)
  459. # [19:17] <atw> Also, is the implication that onload on a parent window is invoked only after all iframes have been fully loaded? I have to admit I'm not 100% up on the semantics of onload.
  460. # [19:17] <jwalden> yes
  461. # [19:17] <jwalden> to the latter
  462. # [19:17] <gsnedders> Philip`: huh… "six" being the number of unique values?
  463. # [19:19] <atw> That use case makes sense to me (send messages on onload()) - I guess the intent of postMessage() is that the behavior is undefined if you are sending it to another window while that window's content is still loading?
  464. # [19:20] <Philip`> gsnedders: No, six being a number I made up off the top of my head, which turned out to not be a good approximation of 5585
  465. # [19:20] * Joins: dave_levin (n=dave_lev@72.14.227.1)
  466. # [19:20] <jwalden> "intent" I think is putting it a bit strongly, but I don't think it was considered a serious limitation
  467. # [19:20] <jwalden> atw: do consider that all the hash-and-poll hacks already required the target window to be loaded
  468. # [19:21] <gsnedders> Philip`: ah
  469. # [19:22] <jwalden> also seems to me that making early messages get queued is mostly unneeded complexity in the implementation, and sites can work around the "problem" without much trouble
  470. # [19:22] <jwalden> a limitation, but not pejoratively
  471. # [19:23] <atw> jwalden: Sure. We do that work for MessagePorts (queue messages before the port is started) so this seemed like an analogous situation, which is why the behavior surprised me.
  472. # [19:24] <atw> But I'm not arguing that it's unreasonable.
  473. # [19:25] <jwalden> messageports came along after I last really looked at postMessage, so I don't know the details of how they work
  474. # [19:25] * aroben is now known as aroben|meeting
  475. # [19:25] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  476. # [19:26] * Joins: davidb (n=davidb@bas4-toronto06-1279277989.dsl.bell.ca)
  477. # [19:26] * Quits: davidb_ (n=davidb@bas4-toronto06-1279277989.dsl.bell.ca) (Read error: 104 (Connection reset by peer))
  478. # [19:36] * Quits: weinig (n=weinig@17.246.16.246)
  479. # [19:52] * Quits: dolske (n=dolske@firefox/developer/dolske)
  480. # [19:54] * Quits: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de) (Remote closed the connection)
  481. # [19:55] * aroben|meeting is now known as aroben
  482. # [20:00] * Joins: weinig (n=weinig@17.246.16.246)
  483. # [20:03] * Quits: weinig (n=weinig@17.246.16.246) (Client Quit)
  484. # [20:06] * Quits: jwalden (n=waldo@c-76-102-160-171.hsd1.ca.comcast.net) ("ChatZilla 0.9.82.1-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  485. # [20:10] * Joins: pauld (n=pauld@host86-133-17-49.range86-133.btcentralplus.com)
  486. # [20:14] * Quits: mstange (n=markus@pD9579410.dip0.t-ipconnect.de) ("ChatZilla 0.9.84-2009030221 [Firefox 3.6a1pre/20090325032457]")
  487. # [20:15] * Joins: hdh (n=hdh@58.187.21.114)
  488. # [20:16] * Quits: pauld (n=pauld@host86-133-17-49.range86-133.btcentralplus.com)
  489. # [20:18] * aroben is now known as aroben|meeting
  490. # [20:28] * Joins: weinig (n=weinig@17.246.16.246)
  491. # [20:30] <Philip`> gsnedders: "This gives a fair performance boost on the spec (~12s)" - you should run your tests on a slower computer, then you could easily get a ~24s performance boost from the same patch
  492. # [20:31] * Joins: jwalden (n=waldo@corp-241.mountainview.mozilla.com)
  493. # [20:35] <gsnedders> :D
  494. # [20:36] * Joins: dolske (n=dolske@c-76-103-40-203.hsd1.ca.comcast.net)
  495. # [20:40] * Joins: olliej_ (n=oliver@c-67-164-125-23.hsd1.ca.comcast.net)
  496. # [20:44] * Joins: pauld (n=pauld@host86-133-17-49.range86-133.btcentralplus.com)
  497. # [20:45] * Quits: ap (n=ap@194.154.88.41)
  498. # [20:46] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  499. # [20:51] * Quits: smaug (n=chatzill@cs181146100.pp.htv.fi) (Remote closed the connection)
  500. # [20:55] * Joins: weinig_ (n=weinig@17.246.16.246)
  501. # [20:55] * Quits: weinig (n=weinig@17.246.16.246) (Read error: 104 (Connection reset by peer))
  502. # [20:58] * Quits: pauld (n=pauld@host86-133-17-49.range86-133.btcentralplus.com)
  503. # [20:59] * Quits: Lachy (n=Lachlan@85.196.122.246) ("This computer has gone to sleep")
  504. # [21:23] * Joins: nessy (n=nessy@124-168-165-203.dyn.iinet.net.au)
  505. # [21:34] * Quits: olliej_ (n=oliver@c-67-164-125-23.hsd1.ca.comcast.net)
  506. # [21:37] * Joins: itpastorn (n=itpastor@139.57.227.87.static.th.siw.siwnet.net)
  507. # [21:52] <gsnedders> Man, I really am awesome at procrastinating.
  508. # [21:57] * Joins: rubys1 (n=rubys@213.sub-75-211-158.myvzw.com)
  509. # [21:59] <nessy> lol
  510. # [22:01] * Quits: mlpug (n=mlpug@a91-156-60-13.elisa-laajakaista.fi) (Remote closed the connection)
  511. # [22:01] <jgraham> gsnedders: Or you're just arrogant ;)
  512. # [22:06] * Quits: zalan (n=kvirc@80.99.193.98) ("KVIrc 3.4.0 Virgo http://www.kvirc.net/")
  513. # [22:06] <annevk3> svl, did you verify that? it sounds weird
  514. # [22:07] <svl> annevk3: I didn't.
  515. # [22:07] <svl> Just stumbled across it in the midst of doing other things
  516. # [22:08] <annevk3> atw, waiting for <iframe onload> seems like a long time; though I don't really have a better solution (other than the <iframe> pinging the parent)
  517. # [22:15] * Joins: pauld_ (n=pauld@host86-133-17-49.range86-133.btcentralplus.com)
  518. # [22:21] * Quits: pauld_ (n=pauld@host86-133-17-49.range86-133.btcentralplus.com)
  519. # [22:23] * Quits: weinig_ (n=weinig@17.246.16.246)
  520. # [22:24] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  521. # [22:28] * Quits: heycam (n=cam@124-168-80-126.dyn.iinet.net.au) ("bye")
  522. # [22:28] * Joins: doublec (n=doublec@202.0.36.64)
  523. # [22:33] <annevk3> rubys1, while <b><i>x</b></i> is a somewhat simple example and "works", adding a character (e.g. <b><i>x</b>x</i>) already gives you a DOM that authors would not expect
  524. # [22:34] <annevk3> I'm not sure if it's worth distinguishing between the two as it's likely that the cost of implementing in validators would be so high that the resulting messages would be terribly confusing to authors.
  525. # [22:35] <annevk3> (And validators are already confusing. E.g. validator.nu is a multi-year project and still has a lot of error messages that are quite confusing.)
  526. # [22:35] <annevk3> (Not to speak of validator.w3.org...)
  527. # [22:35] * Joins: pauld (n=pauld@host86-133-17-49.range86-133.btcentralplus.com)
  528. # [22:35] * Joins: roc (n=roc@202.0.36.64)
  529. # [22:37] * Quits: itpastorn (n=itpastor@139.57.227.87.static.th.siw.siwnet.net) ("Leaving.")
  530. # [22:37] <annevk3> As for "<meta charset=utf-8>". I think zcorpan suggested it might have been that older browsers just looked for the string "charset". That actually seems more plausible than that they tried to work with content that didn't work in any browser whatsoever. (And because they did that authors didn't have to care about quotes...)
  531. # [22:48] * Joins: zdobersek (n=zan@cpe-92-37-72-115.dynamic.amis.net)
  532. # [22:48] * Quits: zdobersek1 (n=zan@cpe-92-37-72-115.dynamic.amis.net) (Read error: 104 (Connection reset by peer))
  533. # [22:48] * Quits: taf2 (n=taf2@65.210.82.235)
  534. # [22:50] * Joins: zdobersek1 (n=zan@cpe-92-37-68-80.dynamic.amis.net)
  535. # [22:51] <Philip`> annevk3: Maybe a better example is <meta name=description content=an unquoted sentence>
  536. # [22:51] * Quits: zdobersek1 (n=zan@cpe-92-37-68-80.dynamic.amis.net) (Client Quit)
  537. # [22:51] <Philip`> annevk3: It looks like about 1% of <meta name=description>s have that error
  538. # [22:51] <Philip`> (and about 1% of <meta name=keywords>s too)
  539. # [22:52] <Philip`> (Some of those are because people accidentally use fancy Word quotes, or put double quotes inside the double quoted attribute value, but I think many are from intentionally unquoted attributes)
  540. # [22:53] <annevk3> Philip`, what affect did that have on browsers? The ability to handle lots of attributes?
  541. # [22:53] <annevk3> effect, geez
  542. # [22:54] <Dashiva> Death to fancy quotes
  543. # [22:56] * Philip` saw one site with two thousand attributes on its <meta name=keywords>
  544. # [22:57] <Philip`> annevk3: I wasn't thinking of the effect on authors - I was just thinking of it as evidence that unquoted attributes encourage authoring errors, and so perhaps they should be discouraged
  545. # [22:58] <Dashiva> Know of any cases where meta @keywords is actually used as keywords, and not just treated as normal text or ignored?
  546. # [22:59] <Hixie> Philip`: that's very common
  547. # [22:59] <Hixie> <meta name=keywords content=a, b, c, ... for megabytes>
  548. # [22:59] <Hixie> i had to make serious changes to my parser to handle this case
  549. # [22:59] <annevk3> Philip`, I thought rubys1 was talking about fallout
  550. # [23:00] <annevk3> oh help, <br> and 'clear' is brought up again on www-style
  551. # [23:01] * annevk3 remembers a certain F2F where that was discussed for more than 10min
  552. # [23:01] <Hixie> only 10min?
  553. # [23:02] <annevk3> I'm being conservative here. My recollection has it on 1h :)
  554. # [23:02] <Hixie> that sounds more like it
  555. # [23:03] * annevk3 goes to read AC minutes
  556. # [23:04] * rubys1 is now known as rubys
  557. # [23:04] * annevk3 didn't know AC meetings where also for chairs
  558. # [23:04] <annevk3> s/where/were
  559. # [23:05] * Joins: ojan (n=ojan@nat/google/x-91ad1fc8aee6f677)
  560. # [23:05] <annevk3> hmm, I write English phonetically and I'm pretty bad at it too :)
  561. # [23:05] <rubys> Philip` got my intent. I agree that misnested closes are often indication of an error, and that dropping quotes can lead to errors... the line between the two is fuzzy.
  562. # [23:08] <annevk3> Historically the line has been pretty clear :)
  563. # [23:09] <rubys> ???
  564. # [23:09] <rubys> not to me.
  565. # [23:09] <annevk3> I'm not that opposed to requiring quotes everywhere personally. It's an easy XSS target. However, seems a bit burdersome for existing content and XSS should likely be checked using dedicated tools (e.g. a public version of scanmus) as there are many other potential holes.
  566. # [23:10] <annevk3> rubys, quotes have always been optional and misnested inlines have always been disallowed
  567. # [23:10] <rubys> My problem is more basic than that: What would "requiring" mean? What does "disallowed" mean?
  568. # [23:11] <rubys> Will Opera refuse to show a page that doesn't meet one or the other criteria?
  569. # [23:11] <rubys> (that was rhetorical, the answer is "of course not")
  570. # [23:11] <annevk3> (right)
  571. # [23:11] <annevk3> That has also been pretty consistent from a historical perspective :)
  572. # [23:12] <annevk3> I was talking about authoring requirements. Much like the SVG WG was.
  573. # [23:12] <rubys> Is it best practice to nest corectly? To always use quotes? I can see arguments for both.
  574. # [23:13] * Joins: weinig (n=weinig@64.168.229.50)
  575. # [23:14] <annevk3> I don't really know about best practice. Sounds fuzzy :)
  576. # [23:15] <karlcow> [17:54] <Dashiva> Know of any cases where meta @keywords is actually used as keywords, and not just treated as normal text or ignored?
  577. # [23:15] <karlcow> spotlight on mac os x
  578. # [23:15] <annevk3> If it's really that unclear, I was simply talking about what prior HTML specifications required from authors. E.g. HTML4.
  579. # [23:16] <Hixie> wilhelm_: any news on the timeout spec?
  580. # [23:16] * Quits: zdobersek (n=zan@cpe-92-37-72-115.dynamic.amis.net) (Read error: 110 (Connection timed out))
  581. # [23:17] * rubys really, really, really didn't want to use the "alt" attribute as my example, which is a case where HTML5 attempts to legislate "best practices" in a way that differs from HTML4
  582. # [23:17] * Hixie wonders what to do with setTimeout() and company
  583. # [23:20] <karlcow> Yahoo too it seems if the claim is right http://help.yahoo.com/l/us/yahoo/search/ranking/ranking-02.html
  584. # [23:22] <annevk3> rubys, I'm not saying we can't make changes either way. As I said, I'd be happy with required quotes. I'm just saying that historically allowing unquoted attributes and disallowing misnested tags has been the way to go.
  585. # [23:23] <gsnedders> What's an example of something where all browsers interoperably break the spec?
  586. # [23:25] <annevk3> <datagrid>
  587. # [23:25] <annevk3> :)
  588. # [23:25] <Hixie> i don't think "don't implement any of it" counts as "breaking the spec" :-P
  589. # [23:25] <annevk3> (actually, I guess there are parsing differences in text/html)
  590. # [23:26] <rubys> gsnedders: http://www.w3.org/TR/html4/appendix/notes.html#h-B.3.3
  591. # [23:27] <rubys> In particular, shorthand markup.
  592. # [23:27] * gsnedders was trying to avoid SGMLisms
  593. # [23:28] <gsnedders> rubys: Also, where in HTML 4.01 does it require an SGML parser to be used?
  594. # [23:28] <gsnedders> rubys: If there isn't such a thing, as I believe to be the case, then it isn't breaking the spec.
  595. # [23:29] <rubys> OK, here's a non GML HTML5 issue: "'Boolean attributes in HTML5 can't use the values "true" or "false" and I can't get myself to accept that fact." -- http://www.w3.org/QA/2009/03/a_rough_view_of_the_future.html
  596. # [23:31] * Quits: Maurice (n=copyman@5ED548D4.cable.ziggo.nl) ("Disconnected...")
  597. # [23:31] <annevk3> I guess he never used HTML4 :)
  598. # [23:32] * gsnedders would like a better thing which is certainly against the spec
  599. # [23:32] * Quits: nessy (n=nessy@124-168-165-203.dyn.iinet.net.au) (Read error: 60 (Operation timed out))
  600. # [23:33] <annevk3> (Boolean attributes came pretty much straight from HTML4 although we removed the silly SGMLism that you specify the value rather than the attribute.)
  601. # [23:34] <Hixie> yeah that's not new in HTML5
  602. # [23:35] <gsnedders> So PHP html5lib tokenizer is currently at 10.2s to tokenize the spec
  603. # [23:35] <gsnedders> Compared with 7.46s for Python
  604. # [23:39] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  605. # [23:44] * jcranmer is now known as jcranmer|away
  606. # [23:44] * jcranmer|away is now known as jcranmer
  607. # [23:53] * Quits: weinig (n=weinig@64.168.229.50)
  608. # [23:59] * aroben|meeting is now known as aroben
  609. # Session Close: Thu Mar 26 00:00:00 2009

The end :)