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

Options:

  1. # Session Start: Fri Jun 22 00:00:00 2007
  2. # Session Ident: #whatwg
  3. # [00:20] * Quits: mitsuhiko (n=blackbir@ubuntu/member/mitsuhiko) ("Terminated with extreme prejudice - dircproxy 1.0.5")
  4. # [00:25] * Quits: tantek (n=tantek@204-16-155-89-static.ipnetworksinc.net)
  5. # [00:25] * Joins: mitsuhiko (n=blackbir@hammett.srv.pocoo.org)
  6. # [00:25] <Hixie> christ, how hard can this versioning thing be
  7. # [00:26] <Hixie> right, afk, bbiab
  8. # [00:38] * Quits: gsnedders (n=gsnedder@host86-140-190-99.range86-140.btcentralplus.com) ("Don't touch /dev/null…")
  9. # [00:46] * Joins: hendry_ (i=hendry@conference/debconf/x-27f2438213075cef)
  10. # [00:58] * Quits: hendry_ (i=hendry@conference/debconf/x-27f2438213075cef) ("leaving")
  11. # [01:06] * Joins: tantek (n=tantek@m010f36d0.tmodns.net)
  12. # [01:10] * Quits: hendry (i=hendry@conference/debconf/x-55f505aa7723ad81) (Read error: 110 (Connection timed out))
  13. # [01:13] * Joins: aroben_ (n=adamrobe@17.203.15.248)
  14. # [01:14] * Quits: billmason (n=billmaso@ip156.unival.com) (".")
  15. # [01:16] * Joins: MikeSmith (n=MikeSmit@u-211130160036.hotspot.ne.jp)
  16. # [01:31] * Quits: aroben (n=adamrobe@17.255.98.199) (Read error: 110 (Connection timed out))
  17. # [01:35] * Quits: duryodhan (n=chatzill@221-128-139-53.static.exatt.net) (Read error: 110 (Connection timed out))
  18. # [01:42] <Hixie> woot, i'm up to the parsing comments that were sent earlier this month!
  19. # [01:48] * Joins: duryodhan_ (n=chatzill@221-128-173-169.static.exatt.net)
  20. # [01:48] * duryodhan_ is now known as duryodhan
  21. # [01:49] * Quits: jgraham (n=jgraham@81-86-214-247.dsl.pipex.com) (Read error: 110 (Connection timed out))
  22. # [01:55] * Quits: tantek (n=tantek@m010f36d0.tmodns.net)
  23. # [02:04] * Joins: karlUshi (n=karl@dhcp-247-173.mag.keio.ac.jp)
  24. # [02:35] * Joins: weinigLap_ (i=weinig@nat/apple/x-a93171dd8026d601)
  25. # [02:37] * Quits: weinigLap (i=weinig@nat/apple/x-44cbd237ff7d8886) (Read error: 104 (Connection reset by peer))
  26. # [02:48] <Philip`> Woah, the HTML4 DTD has attributes 'datasrc', 'datafld', 'dataformatas' and 'datapagesize' as "reserved for possible future use" - I wonder what they were meant for...
  27. # [02:48] <othermaciej> weird
  28. # [02:48] <othermaciej> <object>?
  29. # [02:50] <Philip`> The first three are in span, div, object, input, select, textarea, button, table
  30. # [02:51] <Philip`> datapagesize is in table
  31. # [02:56] <Hixie> IE supports 'datasrc', 'datafld', 'dataformatas' and 'datapagesize'
  32. # [03:04] * Joins: tantek (n=tantek@corp.technorati.com)
  33. # [03:08] <Hixie> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%5B%26%23xd840%3B%26%23xdc00%3B%5D
  34. # [03:09] <Hixie> how sad
  35. # [03:09] <othermaciej> what do they do?
  36. # [03:10] <Hixie> all browsers except the latest firefox seem to treat &#xd840;&#xdc00; as U+20000
  37. # [03:11] <jruderman> mmm, surrogates
  38. # [03:13] <Hixie> dunno what to do about this
  39. # [03:14] <Hixie> i guess it's unlikely to be a compat problem
  40. # [03:14] <Hixie> i'll just make firefox3's behaviour the spec
  41. # [03:16] <jruderman> thanks, how nice of you :)
  42. # [03:16] <othermaciej> what's wrong with the all other browser behavior?
  43. # [03:16] <othermaciej> I'm guessing that's separate NCRs for the two parts of a surrogate pair for a single char?
  44. # [03:17] <Hixie> yeah
  45. # [03:18] <Hixie> actually the spec already requires this
  46. # [03:21] <Hixie> wtf are High Private Use Surrogates
  47. # [03:24] * weinigLap_ is now known as weinigLap
  48. # [03:24] * Joins: jcgregorio (n=chatzill@adsl-072-148-043-048.sip.rmo.bellsouth.net)
  49. # [03:45] * Quits: tantek (n=tantek@corp.technorati.com)
  50. # [03:47] * Quits: othermaciej (n=mjs@17.255.96.159)
  51. # [03:48] * Joins: aroben (n=adamrobe@17.203.15.248)
  52. # [03:48] * Quits: aroben_ (n=adamrobe@17.203.15.248) (Read error: 104 (Connection reset by peer))
  53. # [03:49] * Joins: othermaciej (n=mjs@17.255.96.159)
  54. # [03:49] <Lachy> Hey Hixie, while you're looking at unicode stuff, I made a test page to test the upper/lowercasing algorithms. It seems that browsers get it wrong sometimes (though, my test could be wrong as well)
  55. # [03:50] <Lachy> http://lachy.id.au/temp/Unicode/case.html (it may take a while to load, XHR has to load a 1MB unicode data file)
  56. # [03:50] * Quits: othermaciej (n=mjs@17.255.96.159) (Client Quit)
  57. # [03:50] * Joins: jgraham (n=jgraham@81-86-214-247.dsl.pipex.com)
  58. # [03:52] <Hixie> Lachy: i'm not really looking at unicode stuff, i'm just going down through the e-mail pile
  59. # [03:52] <Lachy> just ignore all the results for chars above U+10000, there's a limitation with JS
  60. # [03:52] <Hixie> happened to get to an e-mail of someone complaining about surrogates
  61. # [03:52] <Lachy> ok
  62. # [03:52] * Quits: h3h (n=w3rd@66-162-32-234.static.twtelecom.net) ("|")
  63. # [03:53] <Hixie> wow, firefox sucks on that test
  64. # [03:54] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  65. # [03:54] <Lachy> woah, Opera doesn't render the table properly
  66. # [03:59] <Hixie> hsivonen?
  67. # [04:00] <Hixie> hsivonen requested that we drop spaces that are around the <html> element, because XML drops them
  68. # [04:00] <Hixie> and he was concerned about round-tripping HTML5-XHTML5-HTML5
  69. # [04:00] <Hixie> but dropping them makes the round-tripping through _HTML5_ much worse
  70. # [04:01] <Lachy> why?
  71. # [04:01] <Hixie> e.g. "<!-- --> <!DOCTYPE HTML> <html>...</html> <!-- -->" becomes "<!-- --><!DOCTYPE HTML><html>... </html><!-- -->"
  72. # [04:01] <Hixie> (in particular, imagine those as newlines)
  73. # [04:01] * Joins: tantek (n=tantek@12.43.57.218)
  74. # [04:04] <Hixie> well
  75. # [04:04] <Hixie> based on my tests with the live dom inspector
  76. # [04:04] <Hixie> i'm the only who cares!
  77. # [04:04] <Lachy> that depends on how you serialise it, not whether those spaces are presentin the DOM
  78. # [04:05] <Lachy> and since the DOM doesn't retain text nodes outside the root anyway
  79. # [04:05] <Hixie> it used to :-)
  80. # [04:05] * Hixie checks in a change to drop whitespace outside the DOM
  81. # [04:05] <Lachy> it used to in the spec, or in some implementation?
  82. # [04:06] <Hixie> spec
  83. # [04:24] <Hixie> wow, well here's a solid argument like none before it:
  84. # [04:24] <Hixie> Deprecating the embed element would make the standard more consistent and
  85. # [04:24] <Hixie> would make me feel better about the standard eventually.
  86. # [04:24] <Hixie> Not that I feel bad right now, that is.
  87. # [04:27] * Quits: aroben (n=adamrobe@17.203.15.248) (Read error: 104 (Connection reset by peer))
  88. # [04:28] * Joins: aroben (n=adamrobe@17.203.15.248)
  89. # [04:47] * Quits: weinigLap (i=weinig@nat/apple/x-a93171dd8026d601) (Read error: 104 (Connection reset by peer))
  90. # [04:47] * Joins: weinigLap_ (i=weinig@nat/apple/x-ee2ecae75a939a79)
  91. # [05:13] * Joins: duryodhan_ (n=chatzill@221-128-139-79.static.exatt.net)
  92. # [05:14] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  93. # [05:17] * Quits: duryodhan (n=chatzill@221-128-173-169.static.exatt.net) (Read error: 110 (Connection timed out))
  94. # [05:18] * duryodhan_ is now known as duryodhan
  95. # [05:25] * Quits: tantek (n=tantek@12.43.57.218)
  96. # [05:39] * Quits: aroben (n=adamrobe@17.203.15.248)
  97. # [05:44] * weinigLap_ is now known as weinigLap
  98. # [05:45] <Hixie> othermaciej, you might need to do another IANAL-but e-mail, this time explaining trademark law... :-)
  99. # [05:52] <othermaciej> Hixie: the legal standing of the W3C's trademark is so many steps removed from relevance to the discussion...
  100. # [05:52] <othermaciej> Hixie: but I'll explain it if I have to
  101. # [05:52] <Hixie> i was mostly kidding :-)
  102. # [05:53] <Hixie> they lost that trademark long ago, when they didn't sue me for calling the web apps spec's language "html5" and "xhtml5"
  103. # [05:55] <othermaciej> they don't claim a trademark on HTML
  104. # [05:55] <othermaciej> and yes, I doubt most of the language trademarks on that page would hold up
  105. # [05:55] <othermaciej> CSS, DOM, SVG, XHTML, no one cites their trademark when referring to those
  106. # [05:55] <Hixie> yeah, they used to claim the trademark but stopped around 2001
  107. # [05:55] <Hixie> iirc
  108. # [05:56] <Hixie> probably had a lawyer laugh at them :-)
  109. # [05:56] * othermaciej is now known as om_out
  110. # [05:56] * Quits: jcgregorio (n=chatzill@adsl-072-148-043-048.sip.rmo.bellsouth.net) ("ChatZilla 0.9.78.1 [Firefox 2.0.0.4/2007060115]")
  111. # [06:14] <Lachy> Hixie, regarding your last post about versioning on public-html, I wouldn't call consistency with previous HTML versions a valid reason for versioning at all because it assumes that consistency actually achieves something useful
  112. # [06:15] <Hixie> it was consistency with future versions that was being suggested i think
  113. # [06:16] <Hixie> but as a general rule, it's good to give the "other side" in a debate the impression of having won something... admitting defeat on an irrelevant and worthless argument is a good way to win the argument overall.
  114. # [06:16] <Lachy> then it's even less valid, because the assumption is the future revisions will need to add versioning
  115. # [06:16] <Lachy> ok
  116. # [06:16] <Hixie> i agree that it's a ridiculuous argument. that's why's it a good one to agree about.
  117. # [06:16] <Hixie> :-)
  118. # [06:17] <Hixie> (that's one reason to never give the other side _all_ your arguments -- only to give the strong ones -- because then they are forced to either disagree with everything, or to give you a strong argument if they do what i just described)
  119. # [06:18] <Hixie> (and if they disagree with everything, then they look like they're being unreasonable, and then the clueless people who come in and try to be "reasonable" by giving "compromises" invariably take one of the things you said as a way to give you an argument
  120. # [06:18] <Hixie> which is then a strong argument, since you didn't give them the weak ones to pick from)
  121. # [06:18] * Lachy is confused
  122. # [06:23] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  123. # [06:53] <Hixie> so... someone pointed out that "character entity reference" was being misused in the HTML5 spec
  124. # [06:53] <Hixie> since there's no DTD or anything
  125. # [06:53] <Hixie> what should we call them instead?
  126. # [07:02] <Lachy> just call them character references
  127. # [07:03] <Hixie> and drop the word "entity"?
  128. # [07:03] <Hixie> hmm, that could work
  129. # [07:04] <Lachy> the problem is calling &#nnnn; and &#xnnnn; entities is wrong. In SGML and XML, &foo; is an general entity ref. &amp;, for example, is commonly called a character entity ref because it only contains 1 char
  130. # [07:05] <Lachy> but officially, there is no such thing as a character entity ref in SGML or XML
  131. # [07:05] <Hixie> yeah, mike explained that on the list
  132. # [07:05] <Lachy> ok
  133. # [07:05] <Hixie> there's a numeric character reference and a character entity reference
  134. # [07:05] <Lachy> yeah
  135. # [07:06] <Lachy> I recommend only using entity when you need to distinguish between &#...; and &foo;
  136. # [07:07] <Hixie> well, we'll see what replies i get to the thread
  137. # [07:10] * Quits: dbaron (n=dbaron@corp-242.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  138. # [07:14] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  139. # [07:15] * Quits: duryodhan (n=chatzill@221-128-139-79.static.exatt.net) (Read error: 110 (Connection timed out))
  140. # [07:43] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  141. # [07:46] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  142. # [07:50] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  143. # [07:50] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  144. # [08:01] * Joins: kfish (n=conrad@61.194.21.25)
  145. # [08:01] <Hixie> ok how the hell do i do this
  146. # [08:01] <Hixie> complete this sentence:
  147. # [08:01] <Hixie> <p>The contents of CDATA and RCDATA elements must...
  148. # [08:02] <Hixie> ...in a way that defines that they can contain pairs of <!-- and --> (which can overlap) and that </endtags> that aren't escaped by those pairs are not ok
  149. # [08:05] * Quits: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  150. # [08:06] <jruderman> why does it have to be a sentence, rather than a paragraph, and why does it have to start that way?
  151. # [08:06] <Hixie> it doesn't. in fact i'm up to three paragraphs so far.
  152. # [08:07] <Hixie> i was just phrasing it as a quiz show question :-)
  153. # [08:07] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  154. # [08:09] <karlUshi> just for the record. Hixie didn't decide to call it html5
  155. # [08:09] <karlUshi> in fact it has been suggested by someone else
  156. # [08:09] <karlUshi> :) anyway
  157. # [08:09] <karlUshi> childish
  158. # [08:10] <Hixie> ?
  159. # [08:10] <Hixie> didn't decide to call what html5?
  160. # [08:11] * om_out is now known as othermaciej
  161. # [08:11] <karlUshi> webapps 1.0
  162. # [08:11] <Hixie> the whatwg language was called html5 before the whatwg was announced
  163. # [08:11] <Hixie> in fact howcome suggested it to me when we had dinner after my interview at opera back in 2003
  164. # [08:11] <Hixie> or 2002
  165. # [08:11] <Hixie> 2003 i think
  166. # [08:11] <Hixie> which was about a year before we started web apps 1.0
  167. # [08:13] * karlUshi will abstain to talk :) for the benefits of everyone.
  168. # [08:13] <Hixie> the spec itself was called "web apps 1.0" (as opposed to "html5" as it is now) for various political reasons, but it claimed to define html5 since the very start, as far as i recall
  169. # [08:14] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  170. # [08:19] <jruderman> Hixie: https://bugzilla.mozilla.org/show_bug.cgi?id=385434
  171. # [08:19] <Hixie> interesting idea
  172. # [08:24] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  173. # [08:32] <othermaciej> that is a good idea
  174. # [08:32] <othermaciej> especially with the fragment ID being used to simulate "AJAX history"
  175. # [08:32] <Hixie> woot, the HTML parser folder is empty!
  176. # [08:32] <Hixie> now for the input-for-whatwg-html-parsing-rules-encoding folder.
  177. # [08:33] <Hixie> maybe i should go home first
  178. # [08:33] <Lachy> I just checked in a whole bunch of new and revised examples. http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.src.html?content-type=text/html;%20charset=utf-8
  179. # [08:33] <othermaciej> that would be advisable yes
  180. # [08:33] <othermaciej> I am happy with the way HTML5 is coming along
  181. # [08:33] <Hixie> glad to hear it
  182. # [08:33] <othermaciej> (though I have only been able to pay ~3% of my attention to it the past few weeks)
  183. # [08:37] <Hixie> bbl
  184. # [08:39] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  185. # [08:44] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  186. # [08:45] * Quits: jruderman (n=jruderma@c-67-169-24-116.hsd1.ca.comcast.net)
  187. # [09:20] <Hixie> hsivonen: yt? i was wondering if you had any opinions on whether we should continue the way we have for the encoding detection or if we should require the algorithm you suggested back in march last year where we basically do the encoding detection in the main parser and then rewind if necessary
  188. # [09:23] <Lachy> Hixie, do you mean this one? http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-March/005989.html
  189. # [09:25] <Hixie> yeah
  190. # [09:25] <Hixie> it
  191. # [09:25] <Hixie> er
  192. # [09:25] <Hixie> it's tempting to just use that, but it's more complicated to implement
  193. # [09:25] <Hixie> also i'm not really sure how you would handle event handlers and stuff like that
  194. # [09:26] <Hixie> i mean, we'd need to raise the REWIND flag in a _lot_ of places
  195. # [09:26] <othermaciej> what would REWIND do? reparse from scratch?
  196. # [09:27] <Hixie> yeah
  197. # [09:27] <Hixie> see the algorithm proposed in the e-mail above
  198. # [09:27] * othermaciej reads
  199. # [09:27] <Hixie> how does safari actually implement encoding detection?
  200. # [09:28] * Joins: duryodhan_ (n=chatzill@221.128.138.145)
  201. # [09:29] * duryodhan_ is now known as duryodhan
  202. # [09:29] <othermaciej> it's changed semi-recently so my knowledge of it may be out of date
  203. # [09:29] * Joins: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  204. # [09:30] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  205. # [09:30] <Hixie> what source file is it in?
  206. # [09:31] * Quits: aroben_ (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net) (Remote closed the connection)
  207. # [09:31] * Joins: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  208. # [09:31] <othermaciej> (reading the algorithm)
  209. # [09:31] <othermaciej> it's in WebCore/loader/TextResourceDecoder.cpp
  210. # [09:32] <othermaciej> (mostly)
  211. # [09:32] * Quits: karlUshi (n=karl@dhcp-247-173.mag.keio.ac.jp) (""time for real life, leaving behind the geekocracy stupidity"")
  212. # [09:33] <othermaciej> One part of hsivonen's algorithm definitely needs changing
  213. # [09:33] <othermaciej> "If the tentative encoding name does not identify a rough ASCII
  214. # [09:33] <othermaciej> superset supported by the UA, emit a hard parse error and perform
  215. # [09:33] <othermaciej> implementation-specific heuristics."
  216. # [09:33] * Quits: weinigLap (i=weinig@nat/apple/x-ee2ecae75a939a79)
  217. # [09:33] <othermaciej> UTF-16 needs to be handled as UTF-8 in such cases for web compatibility
  218. # [09:34] <othermaciej> I guess you could call that an implementation-specific heuristic
  219. # [09:34] <Hixie> good to know
  220. # [09:34] <othermaciej> I know we discovered at some point that Firefox appears to do a full parse and rewind
  221. # [09:35] <othermaciej> we used to have a dumbed-down preparse, and I think we still do, but we are considering changing
  222. # [09:35] <othermaciej> or maybe doing the preparse but also rewinding parsing if we hit a <meta charset>
  223. # [09:35] <Lachy> yes, regardless of how big the file is, a <meta charset=""> anywhere will cause a reparse if the declared encoding is incompatible with Win 1252
  224. # [09:35] <Lachy> (or something like that)
  225. # [09:37] <Hixie> but is the reparse done despite scripts having run?
  226. # [09:37] <Lachy> yes
  227. # [09:37] <Hixie> lovely
  228. # [09:39] <Hixie> sounds like what we want to do is have an optional dumb preparse, then if that was skipped or if it didn't find an encoding, default to some encoding and start parsing, and if you hit a charset declaration that disagrees with the current one (notwithstanding UTF-16) then you start over (only doing that for the first charset seen)
  229. # [09:40] <Lachy> hmm. I can't get FF to execute the script twice, but IE will
  230. # [09:40] <Hixie> really?
  231. # [09:40] <Hixie> how are you testing?
  232. # [09:42] <Hixie> also i guess you would only reparse if one of the bytes you saw was incomptaible
  233. # [09:42] <Lachy> yes
  234. # [09:42] <Hixie> no point reparsing if you've not seen a disagreeable byte, as it were
  235. # [09:42] <Lachy> <!DOCTYPE html>©<script>alert("Hi");</script><meta charset="ISO-8859-2"> (save as ISO-8859-1)
  236. # [09:43] <Lachy> also, IE remembers the last encoding it used for the file, so it won't do a reparse if you hit reload
  237. # [09:43] <Hixie> does the byte in mozilla when you do that look like (c)?
  238. # [09:44] <Lachy> no, it interprets it as 8859-2: Š
  239. # [09:44] <Hixie> without running the script twice? it must have some sort of dumb preparser
  240. # [09:44] <Hixie> try sticking 2k of text before the byte
  241. # [09:44] <Hixie> i saw something about a 2k buffer when i was just browsing the mozilla code a few minutes ago
  242. # [09:46] <Lachy> yes, it reparsed it that time
  243. # [09:47] <Hixie> does it also do it if you don't have the (c) byte?
  244. # [09:49] <Lachy> yes
  245. # [09:49] <Hixie> interesting
  246. # [09:50] <Hixie> thanks
  247. # [09:50] <Hixie> i think this will work pretty well
  248. # [09:50] <Hixie> it's compatible with what browsers do, and allows for interesting optimisations
  249. # [09:51] <Hixie> this = what i proposed above, slightly tweaked to take into account what you've found out
  250. # [09:51] <Lachy> I prefer the algorithm in the spec already since it's much saner and easier to implement
  251. # [09:52] <Lachy> would hsivonen's algorithm handle cases like <script>document.write("<meta charset='ISO-8859-2'>");</script>?
  252. # [09:58] <Hixie> yeah, we would keep the algorithm in the spec
  253. # [09:58] <Hixie> we'd just add that if you hit a <meta> later, you reparse in certain cases
  254. # [09:58] <Hixie> i don't propose using henri's idea
  255. # [09:59] <Hixie> my notes are as follows:
  256. # [09:59] <Hixie> have an optional dumb preparse, allow it to use more than 512 bytes
  257. # [09:59] <Hixie> if it found an encoding, let "tentative" be that encoding
  258. # [09:59] <Hixie> if it was skipped, or if it didn't find an encoding,
  259. # [09:59] <Hixie> let "tentative" be the last encoding used for this page,
  260. # [09:59] <Hixie> or some other default
  261. # [09:59] <Hixie> begin parsing using "tentative" as the encoding
  262. # [09:59] <Hixie> if you hit a <meta> tag that defines the encoding
  263. # [09:59] <Hixie> which disagrees with the current,
  264. # [09:59] <Hixie> reparse with that encoding (except treat "UTF-16" as "UTF-8")
  265. # [09:59] <Hixie> optionally: if no bytes that differ between the encodings has yet been
  266. # [09:59] <Hixie> found, just replace the decoder in place and don't reparse
  267. # [10:00] <Hixie> to reparse, use the session history things that save state
  268. # [10:01] <Hixie> i wonder if people realise that a version="" attribute won't help XHTML2 since the DOM node interfaces are decided by tagname and namespace, unaffected by attributes
  269. # [10:02] <Hixie> unless they want to play with HTMLHtmlElement as well
  270. # [10:02] * Joins: zcorpan (n=zcorpan@81-233-253-112-no13.tbcn.telia.com)
  271. # [10:02] * Joins: ROBOd (n=robod@86.34.246.154)
  272. # [10:03] <othermaciej> I would be more worried about this if there were any sign of anyone wanting to implement XHTML2
  273. # [10:04] <Hixie> indeed
  274. # [10:04] <zcorpan> Hixie: is it possible to build a dom with "=" as attribute name?
  275. # [10:05] <Hixie> it is in HTML5, sure
  276. # [10:05] <Hixie> <x =>
  277. # [10:05] <zcorpan> but not with dom apis like setAttribute?
  278. # [10:06] * Quits: aroben (n=adamrobe@c-67-160-250-192.hsd1.ca.comcast.net)
  279. # [10:06] <Hixie> seems browsers raise an exception for that
  280. # [10:07] <zcorpan> ok
  281. # [10:09] * Joins: jgraham_ (n=jgraham@81-86-219-66.dsl.pipex.com)
  282. # [10:11] <zcorpan> Hixie: i know some entities require a semi-colon even in attributes -- that's what i wrote ("a third column that says which entities always require a semi-colon", i.e. both in attributes and in content)
  283. # [10:11] <Lachy> for <x =>, couldn't it just drop the attribute entirely?
  284. # [10:11] * Quits: jgraham (n=jgraham@81-86-214-247.dsl.pipex.com) (Read error: 110 (Connection timed out))
  285. # [10:12] <Lachy> actually, for that IE creates an attribute with no name and no value
  286. # [10:13] <Lachy> FF drops it
  287. # [10:13] <zcorpan> Lachy: old news ;)
  288. # [10:13] <Hixie> zcorpan: ah ok
  289. # [10:19] * Joins: weinigLap (n=weinig@c-67-188-89-242.hsd1.ca.comcast.net)
  290. # [10:20] * Quits: weinigLap (n=weinig@c-67-188-89-242.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  291. # [10:21] * Joins: weinigLap (n=weinig@c-67-188-89-242.hsd1.ca.comcast.net)
  292. # [10:24] <zcorpan> Hixie: although what is specced now has the same result as what i proposed, so the spec is fine
  293. # [10:27] <zcorpan> Hixie: btw, the innerHTML algorithm is used when scripting is disabled... iirc Genshi implements the innerHTML algorithm for serializing to html
  294. # [10:35] <Hixie> the html fragment serialising algorithm?
  295. # [10:35] <Hixie> hm
  296. # [10:35] <Hixie> wonder if that works well
  297. # [10:35] * Quits: weinigLap (n=weinig@c-67-188-89-242.hsd1.ca.comcast.net)
  298. # [10:36] <Hixie> might be a problem if you have <noscript>&lt/noscript> ... </noscript> in a document
  299. # [10:40] * Joins: ddfreyne (n=ddfreyne@d54C57894.access.telenet.be)
  300. # [10:42] <zcorpan> it probably doesn't, but i wouldn't be surprised if more people implement the fragment serialising algorithm for no scripting contexts... so if the algorithm took it into account then it might lead to less buggy tools
  301. # [10:45] <Hixie> yeah
  302. # [10:45] <Hixie> might just need two modes
  303. # [11:16] * Joins: BenWard (i=BenWard@nat/yahoo/x-d1e3c0ba8f9b3aa5)
  304. # [11:32] * Hixie waits for othermaciej to explain that having "html|*:not([version=2]) " at the start of every selector in the UA stylesheet isn't going to scale well
  305. # [11:32] <othermaciej> Hixie: I hope that's a joke
  306. # [11:33] <Hixie> i take it you haven't seen the reply to your last mail
  307. # [11:33] * othermaciej facepalms
  308. # [11:33] <Hixie> it was put quite that way
  309. # [11:34] <mpt> You're almost making me wish I was subscribed to the html-wg mailing list
  310. # [11:35] <mpt> but doubtless there are more efficient sources of humor
  311. # [11:36] <Hixie> yeah, public-xhtml2 has a much higher humor-per-mail quotient
  312. # [11:36] <Hixie> oops, did i say that out loud
  313. # [11:40] <annevk> <meta http-equiv> requirements are a bit odd
  314. # [11:40] <Hixie> yeah i wondered if i should allow <meta charset> in there too
  315. # [11:40] <Hixie> but that seemed dangerous
  316. # [11:40] <annevk> "it must be either in a <code>head</code> element" "Otherwise, it must be in a <code>head</code> element."
  317. # [11:40] <annevk> is what I meant
  318. # [11:41] <Hixie> hm?
  319. # [11:41] * Hixie looks
  320. # [11:42] <Hixie> what's the problem?
  321. # [11:42] <annevk> it says the same thing twice?
  322. # [11:42] <Hixie> oh, i see, the "otherwise" clause is unclear
  323. # [11:42] <Hixie> i'll change it to just "if it doesn't have..."
  324. # [11:43] <othermaciej> I pointed Jirka to the mozilla and webkit source code
  325. # [11:43] <othermaciej> in case he'd like to make comments about what is doable in browsers that are actually informed
  326. # [11:44] <Hixie> i'm sure that will go down well
  327. # [11:45] <othermaciej> I also gave a more concrete example where a version attribute cannot possibly help resolve a namespace clash
  328. # [11:46] <Hixie> annevk: fixed
  329. # [11:46] <zcorpan> Hixie: i can't think of use-cases for <noscript><meta name>, however i don't see a good reason to disallow it either
  330. # [11:47] <Hixie> othermaciej: nice example
  331. # [11:47] <Hixie> zcorpan: shouldn't the metadata not change based on whether scripting is enabled?
  332. # [11:47] <zcorpan> dunno
  333. # [11:47] <zcorpan> perhaps
  334. # [11:48] <Hixie> if you feel it should change, send mail, it wouldn't take much to make me change the spec
  335. # [11:48] <Hixie> i agree with your mail about entities
  336. # [11:48] <Hixie> i wonder what the people who care will say
  337. # [11:54] <zcorpan> Hixie: why are the <!-- and --> in (R)CDATA allowed to overlap when they are not allowed to overlap in PCDATA? (i.e. from a conformance POV)
  338. # [11:56] <annevk> we're seriously debating <html version=> now?
  339. # [11:56] <annevk> wow
  340. # [11:56] <othermaciej> annevk: mainly whether it would miraculously allow XHTML5 and XHTML2 to share the same namespace
  341. # [11:57] <annevk> http://www.itwriting.com/blog/?p=257 is interesting
  342. # [11:58] <zcorpan> xhtml2 already has the version attribute. if they think it's enough to trigger different handling of xhtml2, then all is well already.
  343. # [12:02] <Hixie> sweet! only 371 days to go!
  344. # [12:02] <Hixie> http://www.apple.com/trailers/disney/walle/hd/
  345. # [12:02] * Hixie does a little dance
  346. # [12:03] <othermaciej> so you're not as interested in ratatouille?
  347. # [12:15] <annevk> is 0x0D equal to CR?
  348. # [12:18] <othermaciej> yes
  349. # [12:18] <othermaciej> (man ascii)
  350. # [12:18] <Hixie> othermaciej: i'm ecstatic about ratatouille. But I knew the release date last year. http://ln.hixie.ch/?start=1149918352&count=1
  351. # [12:19] <Hixie> how can you not know that 0x0D / 13 is CR :-P
  352. # [12:19] <othermaciej> so you like to keep your countdowns one ahead?
  353. # [12:19] <Hixie> othermaciej: i just countdown as far as i can :-)
  354. # [12:19] <Hixie> othermaciej: more things to be excited about that way
  355. # [12:20] <Hixie> amusingly, june 29th is the release date of 3 things, two of which steve-jobs-related, and two of which movies
  356. # [12:20] <Hixie> only one of which i care about
  357. # [12:20] <annevk> so why does 0x0D become LF now?
  358. # [12:21] * annevk thought browsers did not fix it up
  359. # [12:21] <Hixie> 0x0D wher?
  360. # [12:21] <Hixie> where, even
  361. # [12:21] <annevk> as character reference
  362. # [12:22] <Hixie> opera doesn't fix it up, ie drops it altogether, firefox and safari fix it up, css expects it to be fixed up
  363. # [12:22] <Hixie> (iirc)
  364. # [12:22] <annevk> k
  365. # [12:24] * Joins: maikmerten (n=maikmert@T656b.t.pppool.de)
  366. # [12:25] * Quits: zcorpan (n=zcorpan@81-233-253-112-no13.tbcn.telia.com) (Read error: 110 (Connection timed out))
  367. # [12:25] <Hixie> i have to say it amazes me that pixar can set release dates more than a year ahead
  368. # [12:25] <Hixie> and hit them, year after year
  369. # [12:26] <Hixie> i'm lucky if i can set release dates a week ahead, and i'm just one person with one little set of tasks
  370. # [12:28] * Joins: Jero (n=Jero@d207230.upc-d.chello.nl)
  371. # [12:32] <annevk> news just in: readyState = 2 -> HEADERS_RECEIVED
  372. # [12:32] <annevk> or does someone have a better name?
  373. # [12:34] <Jero> and HEADERS_RECEIVED is an array of all the headers the object received?
  374. # [12:34] <annevk> it's a state
  375. # [12:35] <Hixie> what was it before?
  376. # [12:35] <Jero> oh ok, i see what you mean now
  377. # [12:35] <Jero> sorry for the misunderstanding
  378. # [12:35] <annevk> currently we have UNSENT, OPEN, SENT, LOADING, DONE
  379. # [12:35] <annevk> SENT -> HEADERS_RECEIVED
  380. # [12:36] <annevk> but it would be nice if it was a little bit shorter
  381. # [12:36] <Hixie> what did i use for the media elements?
  382. # [12:37] <annevk> FRAME_AVAILABLE or something? or PLAY_THROUGH
  383. # [12:37] <annevk> but that's slightly different
  384. # [12:37] <Hixie> i thought i had one for headers only
  385. # [12:38] <Hixie> LOADED_METADATA
  386. # [12:38] <Hixie> i have EMPTY, (no equivalent for OPEN), LOADING, LOADED_METADATA, LOADED_FIRST_FRAME, LOADED
  387. # [12:38] <annevk> ok, UNSENT, OPEN, LOADED_METADATA, LOADING, DONE
  388. # [12:39] <annevk> mjs suggested that EMPTY was not quite the same for XHR or so iirc
  389. # [12:39] <annevk> and DONE is there because it's also readyState = 4 when the request failed
  390. # [12:39] <Hixie> the problem with XHR having LOADED_METADATA, LOADING is that it's the opposite order
  391. # [12:39] <Hixie> which would be confusing
  392. # [12:39] <annevk> yeah, that too
  393. # [12:39] <Hixie> oh well
  394. # [12:40] <annevk> LOADED_HEADERS maybe?
  395. # [12:40] * Joins: hendry (i=hendry@conference/debconf/x-a16b2b77b4c94338)
  396. # [12:40] <Hixie> similar though, with a LOADING after a LOADED, bit confusing
  397. # [12:40] <Hixie> how about just HEADERS?
  398. # [12:41] <Hixie> UNSENT, OPEN, HEADERS, LOADING, DONE
  399. # [12:41] <annevk> sure
  400. # [12:41] <Hixie> not a verb, i guess
  401. # [12:41] <annevk> hmm
  402. # [12:41] <Hixie> or adjective
  403. # [12:41] <Hixie> or whatever those are
  404. # [12:41] <annevk> HEADERS_IN
  405. # [12:42] <Hixie> HEADERS_RECEIVED and HEADERS are my favourites so far
  406. # [12:46] <Philip`> About serialising: The HTML5 spec splitter uses the innerHTML fragment serialising algorithm too (or at least the version of the algorithm from ages ago)
  407. # [12:51] <annevk> http://lists.w3.org/Archives/Public/public-html/2007Jun/0543.html has that guy even remotely considered DOM interfaces?
  408. # [12:54] <annevk> besides the fact that the charter mentions to align more with browsers as opposed to diverging from them in weird ways
  409. # [12:58] * Quits: duryodhan (n=chatzill@221.128.138.145) (Read error: 110 (Connection timed out))
  410. # [13:24] * Quits: MikeSmith (n=MikeSmit@u-211130160036.hotspot.ne.jp) ("Less talk, more pimp walk.")
  411. # [13:39] * Joins: hallvors (n=hallvord@pat-tdc.opera.com)
  412. # [13:41] <Lachy> Hixie, what is ratatouille and why are you so ecstatic about it?
  413. # [13:41] * Lachy is downloading the trailer for Wall-E
  414. # [13:42] <annevk> hixie &heart; pixar
  415. # [13:42] <Lachy> is there a trailer for ratatouille somewhere?
  416. # [13:43] <Lachy> found it
  417. # [14:03] * Joins: duryodhan_ (n=chatzill@221.128.138.136)
  418. # [14:03] * duryodhan_ is now known as duryodhan
  419. # [14:05] * Philip` wonders if it's cruel to write tests that require globalCompositeOperation = darker to be unrecognised
  420. # [14:06] <annevk> weren't there proposals to keep that in?
  421. # [14:07] <Philip`> Yes, but it's not in the list at the moment so it mustn't be supported
  422. # [14:07] * Philip` also checks for globalCompositeOperation=over being unrecognised, just so that Firefox fails
  423. # [14:08] <annevk> I suppose
  424. # [14:08] * Philip` checks if anyone else is secretly supporting non-standard values
  425. # [14:16] <Philip`> Oh, FF does 'clear' too
  426. # [14:17] <Philip`> and WebKit does 'clear' and 'highlight'
  427. # [14:19] * Quits: hendry (i=hendry@conference/debconf/x-a16b2b77b4c94338) (Read error: 110 (Connection timed out))
  428. # [14:26] <Philip`> Hmm, interesting that 'clear' is supported in two of the three main browsersa, and it's the only Porter-Duff operator missing from the spec... I can't think of any possible use cases at all, though
  429. # [14:27] <annevk> maybe it was easy to implement?
  430. # [14:29] <Philip`> "CANVAS_OP_TO_CAIRO_OP("clear", CLEAR)" - the implementation in Gecko doesn't look that tricky
  431. # [14:30] * Joins: hendry (i=hendry@conference/debconf/x-e29c7757ea062891)
  432. # [14:32] <Philip`> and the entirety of WebKit's 'clear' implementation is:
  433. # [14:32] <Philip`> "clear",
  434. # [14:32] <Philip`> which isn't too tricky either
  435. # [14:34] <annevk> what does it do?
  436. # [14:35] <Philip`> It takes the source image, and the destination image, and then discards both of them and outputs transparent black
  437. # [14:36] <Philip`> I believe you can get exactly the same effect by doing "globalAlpha = 0; globalCompositeOperation = 'copy'"
  438. # [14:37] <Philip`> (Ah, looks like Opera is nice and doesn't support anything non-standard except for "darker")
  439. # [14:40] <annevk> we're a likably product :p
  440. # [14:41] <Philip`> Opera does incorrectly accept strings like "source-over\0", though :-p
  441. # [14:43] <annevk> I suppose we strip \0 before it's passed...
  442. # [14:43] <annevk> hmm
  443. # [14:44] <Philip`> If I remember correctly, everything after the \0 gets stripped off too
  444. # [15:01] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  445. # [15:04] * Quits: ddfreyne (n=ddfreyne@unaffiliated/ddfreyne) ("kthxbai")
  446. # [15:10] * Quits: hendry (i=hendry@conference/debconf/x-e29c7757ea062891) (Read error: 110 (Connection timed out))
  447. # [15:17] * Joins: IRChimp (n=chatzill@81-86-171-99.dsl.pipex.com)
  448. # [15:21] * Philip` wonders what makes Opera dislike <canvas>x<canvas>y</canvas>z</canvas>
  449. # [15:30] <Dashiva> Would that ever be useful fallback?
  450. # [15:33] <Philip`> I'm not sure about 'useful', but it could be used - if you have non-interactive static visual media, and you paint on the inner canvas but not the outer one, then it would use the fallback content for the outer one and would display the inner one
  451. # [15:34] <Philip`> but as far as I can see, that's the only situation in which you'd ever see the inner canvas
  452. # [15:34] <Dashiva> I don't understand that example, what triggers fallback on the outer one?
  453. # [15:35] <Philip`> "In non-interactive, static, visual media, if the canvas element has been previously painted on ... then the canvas element must be treated as embedded content with the current image and size. Otherwise, the element's fallback content must be used instead."
  454. # [15:36] <Dashiva> So you'd have to paint on it somewhere else, and then adoptNode or similarly move it to the static media?
  455. # [15:38] <Philip`> I think you could just have a script that's run by the static-media UA and does getElementsByTagName('canvas')[1].getContext('2d').fillRect(0, 0, 300, 150) or whatever, in order for it to become "previously painted on"
  456. # [15:38] * Parts: citoyen (i=eira@synth.no)
  457. # [15:42] <Philip`> I can't think of any situations at all in which anyone would want to do that, though
  458. # [15:43] <Philip`> (but it'd be nice if it worked correctly anyway :-) )
  459. # [15:43] <Dashiva> Yeah, I have problems imagining "previously" combined with "static, non-interactive"
  460. # [15:44] <Philip`> As I understand it, it's the media that's static and non-interactive - you could have a real web browser that loads the page and runs scripts, and then renders the result to a (static, non-interactive) PDF file
  461. # [15:45] <Dashiva> Aha
  462. # [15:46] <Dashiva> That at least makes sense.
  463. # [15:52] <annevk> so what exactly do we do for nested <canvas> elements that is not expected?
  464. # [15:53] <annevk> actually, I believe we have some bugs in the way we parse <canvas> elements
  465. # [15:53] <annevk> "bugs" as parsing for HTML was not really defined until HTML5 came along
  466. # [15:54] <annevk> (Entity handling in html5lib is now per the specification.)
  467. # [15:54] <annevk> (Except for some special character range, fwiw.)
  468. # [15:55] <Philip`> That case gives a (empty) canvas element followed by a "y", when it should give one containing "x (canvas y) z" - presumbly it just looks for the first </canvas>, instead of actually parsing the content
  469. # [15:55] * Quits: duryodhan (n=chatzill@221.128.138.136) (Remote closed the connection)
  470. # [15:56] <annevk> followed by a "z" you mean?
  471. # [15:56] <Philip`> At least Opera is no more broken than IE/excanvas, which just looks for the first "/canvas" element :-)
  472. # [15:56] <Philip`> Oops, yes
  473. # [15:57] <annevk> we parse it similar to iframe I think
  474. # [15:57] <annevk> well, those type of elements
  475. # [15:58] <Philip`> Ah, okay - looks like it's handled like iframe, when (I think) it ought to be handled like object instead
  476. # [15:58] <annevk> i agree, we have some bug report on the matter
  477. # [15:59] <annevk> well, prolly not <object> exactly as <object> is quite hairy too iirc
  478. # [16:21] * Joins: jcgregorio (i=chatzill@nat/ibm/x-9d7e0c9c97b133a9)
  479. # [16:25] * Joins: SavageX (n=maikmert@L9cb5.l.pppool.de)
  480. # [16:28] * Quits: jcgregorio (i=chatzill@nat/ibm/x-9d7e0c9c97b133a9) (Remote closed the connection)
  481. # [16:33] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  482. # [16:34] * Joins: jcgregorio (i=chatzill@nat/ibm/x-42dd8288938872ce)
  483. # [16:40] <Lachy> Hixie, I just watched the trailers and preview for ratatouille. It looks like an awesome movie
  484. # [16:43] * Quits: maikmerten (n=maikmert@T656b.t.pppool.de) (Read error: 110 (Connection timed out))
  485. # [16:54] * Joins: hendry (i=hendry@conference/debconf/x-fdc868d45882f1de)
  486. # [16:54] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  487. # [17:10] * Quits: jcgregorio (i=chatzill@nat/ibm/x-42dd8288938872ce) ("ChatZilla 0.9.78.1 [Firefox 2.0.0.4/2007060115]")
  488. # [17:15] * Quits: hendry (i=hendry@conference/debconf/x-fdc868d45882f1de) ("leaving")
  489. # [17:17] * Joins: ddfreyne (n=ddfreyne@d54C57894.access.telenet.be)
  490. # [17:19] * Joins: duryodhan (n=chatzill@221.128.138.136)
  491. # [17:46] <Lachy> I have the selectors api naming narrowed down to 7 pairs of names, having written detailed justification for rejecting the other ~30 :-)
  492. # [17:49] * Quits: ddfreyne (n=ddfreyne@unaffiliated/ddfreyne)
  493. # [17:50] * Joins: briansuda (n=briansud@85-220-86-64.dsl.dynamic.simnet.is)
  494. # [17:51] <Dashiva> Lachy: In other words, all the good ones are gone :)
  495. # [17:51] <Lachy> no, the crap ones have been rejected
  496. # [17:52] <Lachy> These are the remaining choices:
  497. # [17:52] <Lachy> matchSingle() matchAll()
  498. # [17:52] <Lachy> matchOne() matchAll()
  499. # [17:52] <Lachy> getElement() getElementList()
  500. # [17:52] <Lachy> getElement() getElements()
  501. # [17:52] <Lachy> selectElement() selectElementList()
  502. # [17:52] <Lachy> selectOneElement() selectAllElements()
  503. # [17:52] <Lachy> chooseOne() chooseAll()
  504. # [17:54] <Lachy> anyone have any preferences from that list?
  505. # [17:56] <Philip`> Is selectElement+selectAllElements not a choice?
  506. # [17:57] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  507. # [17:58] <Lachy> Philip`: that's a close call. I had to reject some simply because they were very similar to other options that were considered equal, and I felt the slight inconsistency between the names was good reason at that point
  508. # [17:59] <Lachy> so it was only barely rejected
  509. # [18:03] <Philip`> I guess I kind of like 'select' since it looks easy to remember when I forget the exact name but know I want to find that function that's like CSS selectors; and 'selectOneElement' sounds unnecessarily verbose compared to 'selectElement'; and 'selectElementList' is vague whereas 'selectAllElements' is self-descriptive
  510. # [18:03] <Philip`> But I don't have any strong feelings :-)
  511. # [18:03] <Lachy> oh, good point
  512. # [18:04] <Lachy> ok, I'll switch selectOneElement for selectElement
  513. # [18:09] * Quits: Lachy (n=Lachy@203-158-59-119.dyn.iinet.net.au) (Read error: 104 (Connection reset by peer))
  514. # [18:12] * Quits: briansuda (n=briansud@85-220-86-64.dsl.dynamic.simnet.is)
  515. # [18:13] <hallvors> IMO 'selectElementList' is clearer than 'selectAllElements', I'd assume the latter did the same as getElementsByTagName('*')
  516. # [18:16] * Joins: Lachy (n=Lachy@203-158-59-119.dyn.iinet.net.au)
  517. # [18:18] <Philip`> hallvors: But you wouldn't normally see just the function name by itself - you'd see something like "selectAllElements('h1')" or "selectAllElements('[class|="shadow"]')", and then it'd be obvious that it's not just selecting all the elements in the document
  518. # [18:19] <Lachy> the other option is selectElement() and selectElements(), but I think they look too similar and make editing and reviiewing more difficult
  519. # [18:20] <Lachy> do you consider selectElement to be better than getElement?
  520. # [18:20] <Dashiva> Has overloading (e.g. function selectElement(selector, selectall=true)) been considered and rejected?
  521. # [18:21] <Philip`> (Assuming that [class|="shadow"] thing actually works, I guess that'd be nice for the Unobtrusive JavaScript people so they can just add class="shadow-25x25" and easily scriptise things)
  522. # [18:21] <Lachy> Dashiva: yes. That would require the method to change its return type based on a parameter, which isn't good
  523. # [18:21] <Dashiva> Ah right, JS match returns array in both cases
  524. # [18:21] <Lachy> document.evaluate() does that for DOM3 XPath, but I don't think that's particularly good design
  525. # [18:22] <Lachy> yeah, selectElement() would return a single element, selectAllElements() would return a static node list
  526. # [18:22] <annevk> hallvors on IRC, yay!
  527. # [18:22] <Philip`> getElement sounds vague again to me - with something like getElementById or (once you've heard of it at least once) selectElement, the name tells you how it decides which element you want, which makes it easier to remember
  528. # [18:23] <Dashiva> I agree, getSomething is too vague without a BySomething
  529. # [18:23] <Lachy> that rationale for getElement is that it's like a superset of all existing getElementBy* methods
  530. # [18:24] <Dashiva> But since it doesn't let you get an id without prefixing #, it's not a true superset
  531. # [18:24] <Lachy> a superset in functionality, not in syntax
  532. # [18:25] <Philip`> Will people still use the old getElementBy* functions? It seems slightly nicer to still say getElementById(variablething) rather than getElement('#'+variablething)
  533. # [18:26] <Philip`> (particularly if you have IDs with spaces in them)
  534. # [18:26] <annevk> IDs with spaces are non-conforming
  535. # [18:27] <Philip`> People might still use them, and be unhappy that it gets mangled by the CSS-selector parser when all they want is an exact string match
  536. # [18:27] <hallvors> Philip`: good point, I like the name with some more context
  537. # [18:27] <Lachy> IDs with spaces can be escaped as #foo\ bar
  538. # [18:28] <Lachy> hallvors: which name do you like?
  539. # [18:28] <Philip`> Lachy: But then you'd have to write a function to do CSS escaping, which is probably non-trivial and will probably be done wrong, and it's much safer to stick with getElementById when you just want to match IDs
  540. # [18:29] <Lachy> oh, does gEBId allow spaces?
  541. # [18:29] <Lachy> HTML doesn't allow spaces
  542. # [18:29] <Lachy> I don't know of any language that does
  543. # [18:29] <hallvors> At first I preferred selectElementList over selectAllElements, but the examples changed my mind.
  544. # [18:29] * Joins: weinigLap (i=weinig@nat/apple/x-1b7d6f085f10f6ae)
  545. # [18:30] <hallvors> so now I think selectAllElement is better of the two..
  546. # [18:30] <Lachy> do you think it's better than the other 5 alternatives as well?
  547. # [18:32] <Philip`> Lachy: id="x y" ... getElementById('x y') seems to work perfectly well in browsers, which is usually much more interesting than whether it's meant to be allowed :-)
  548. # [18:32] <Dashiva> I don't like match because it crosses over into regexp language. choose doesn't really fit. Among the rest, I prefer select over get, because it is about selectors after all.
  549. # [18:32] <annevk> getElement("#x\u20y") will also work likely
  550. # [18:32] <Lachy> I was more concerned about whether gEBId() threw an exception, than the validity if the syntax
  551. # [18:33] <annevk> given that \u20 is the correct escape
  552. # [18:33] <Philip`> Lachy: Ah, okay - seems to work happily with no exceptions
  553. # [18:33] <Philip`> annevk: Wouldn't that have to be getElement("#x\\u20y") ?
  554. # [18:33] <annevk> Philip`, btw, any chance you can e-mail me with the changes I missed in html4-differences and maybe also with the script you used?
  555. # [18:33] <Lachy> annevk: \u20 is a JS escape for a space char, that won't be seen by the selector parsor
  556. # [18:34] <Lachy> it would be equivalent to "#x y"
  557. # [18:34] <annevk> Philip`, yeah, fair enough
  558. # [18:35] <Philip`> IE throws exceptions on "x\u20y" because it wants "20y<EOF>" to be a hex string
  559. # [18:35] * Joins: tantek (n=tantek@204-16-155-90-static.ipnetworksinc.net)
  560. # [18:35] <Lachy> oh, you need \u0020
  561. # [18:38] <Lachy> you would actually need to use ("#x\\\u0020y"), though "#x\\ y" is easier
  562. # [18:39] <Philip`> annevk: http://krijnhoetmer.nl/irc-logs/html-wg/20070622#l-47 is all the bits I noticed originally that weren't mentioned
  563. # [18:39] <Philip`> http://canvex.lazyilluminati.com/misc/htmldiffs.pl is the script, though it's rather ugly and hacked-together and I gave up trying to keep it even vaguely clean when I was half way through
  564. # [18:39] <Philip`> (Should I email these links?)
  565. # [18:40] <annevk> preferably
  566. # [18:40] <annevk> maybe I'll just write a small python script that parses your results page though :)
  567. # [18:40] <annevk> and turns it into an HTML table
  568. # [18:41] <Philip`> The code in the bottom third of the script that produces the output should be relatively easy to read and modify into a different format, if you ignore the few lines that have too much syntax on them :-)
  569. # [18:43] <annevk> whoa, did the real Philip Taylor just post to publib-html? :D
  570. # [18:43] <annevk> Philip`, hmm, it's in Perl though
  571. # [18:44] * Joins: ROBOd (n=robod@86.34.246.154)
  572. # [18:44] <Philip`> The original list of non-mentioned things is probably missing a few bits since I fixed my code, so I'll re-check that this evening and send the list to you
  573. # [18:46] <Philip`> I did post, just so I can confuse everyone who doesn't realise there's two people with one name rather than one person with multiple personalities
  574. # [18:47] <Philip`> Perl isn't that bad, as long as you skip over the pieces like [@{$attrs4s{$e}||[]}, @{$attrs4t{$e}||[]}] :-p
  575. # [18:48] <Dashiva> You mean there are other pieces?
  576. # [18:48] <Lachy> Woo Hoo! I think I have made my final decision :-)
  577. # [18:49] <annevk> getElement and getAllElements?
  578. # [18:50] <annevk> match and matchAll?
  579. # [18:50] <Philip`> If it's a final decision, you shouldn't actually tell anyone what the decision was, because there's nothing they could do other than argue for changing the decision :-)
  580. # [18:50] <Lachy> I know, that's why I didn't say what it is yet
  581. # [18:50] * Dashiva sharpens axe
  582. # [18:51] <Lachy> you can all wait till I finish writing the rationale and send it to public-webapi
  583. # [18:54] * hallvors is patient
  584. # [18:54] <Lachy> now the final issue in the spec is to finish reviewing, editing and adding examples. Then I can get it republised as a WD and then hopefully go LC in a few weeks
  585. # [18:54] <Dashiva> How much of the total time has gone to name selection?
  586. # [18:55] <Lachy> a few hours per day over the last 3 days
  587. # [18:56] <Lachy> a lot of it was spent reading through about 300 emails on the topic
  588. # [18:59] * Joins: h3h (n=w3rd@66-162-32-234.static.twtelecom.net)
  589. # [19:01] <Dashiva> Where is the line between "If we /provide/ version information, we allow others to make use of it" and "we /encourage/ others to make use of it", I wonder
  590. # [19:02] <Philip`> Perhaps "If we provide version information, others are more likely to make use of it" - the consequences are important, rather than the direction of the motivation
  591. # [19:02] * Joins: aroben (n=adamrobe@17.203.15.248)
  592. # [19:04] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  593. # [19:13] * Quits: weinigLap (i=weinig@nat/apple/x-1b7d6f085f10f6ae) (Read error: 104 (Connection reset by peer))
  594. # [19:13] * Joins: weinigLap (i=weinig@nat/apple/x-e354cd6815facbc1)
  595. # [19:27] * Quits: BenWard (i=BenWard@nat/yahoo/x-d1e3c0ba8f9b3aa5) ("Fades out again…")
  596. # [19:28] * Joins: Wolfman2000 (n=Wolfman2@wvh5348rn.rh.ncsu.edu)
  597. # [19:59] * Quits: tantek (n=tantek@204-16-155-90-static.ipnetworksinc.net)
  598. # [20:04] * Joins: tantek (n=tantek@204-16-155-90-static.ipnetworksinc.net)
  599. # [20:16] * Lachy is trying to figure out if Sam Ruby is being serious with his proposal for a new HTML MIME type: application/html ???
  600. # [20:16] * othermaciej links
  601. # [20:17] <Lachy> http://www.w3.org/mid/467BE62A.3060102@us.ibm.com
  602. # [20:45] * Quits: weinigLap (i=weinig@nat/apple/x-e354cd6815facbc1)
  603. # [20:45] * Joins: weinigLap (i=weinig@nat/apple/x-6b5288178f4e295a)
  604. # [20:48] * Joins: dbaron (n=dbaron@corp-242.mountainview.mozilla.com)
  605. # [20:56] * moeffju is now known as moeffju[Away]
  606. # [21:53] * Quits: tantek (n=tantek@204-16-155-90-static.ipnetworksinc.net)
  607. # [22:00] * Joins: aa (i=aa@nat/google/x-05501b6c26b87f7c)
  608. # [22:01] <aa> Hello. I was looking at HTML5 timers, and I was wondering if there is documentation somewhere about which browsers currently support which features.
  609. # [22:01] * Joins: tantek (n=tantek@204-16-155-90-static.ipnetworksinc.net)
  610. # [22:06] * Quits: SavageX (n=maikmert@L9cb5.l.pppool.de) (Remote closed the connection)
  611. # [22:07] <Philip`> aa: The timers in http://www.whatwg.org/specs/web-apps/current-work/multipage/section-timers.html ?
  612. # [22:12] <aa> Philip`: yes, those are the ones
  613. # [22:13] <aa> like, for example, do all browsers currently support the extra args in the function pointer overload
  614. # [22:13] <aa> (I figure there must have been research on all these at some point)
  615. # [22:13] <Philip`> IE7 doesn't
  616. # [22:15] <Philip`> FF3 / Opera 9 do, and I expect much older versions of those supported it too, but I don't know if proper test results have been collected anywhere
  617. # [22:17] <aa> ok, thanks.
  618. # [22:19] <Philip`> (More specifically: I believe proper test results haven't been collected anywhere)
  619. # [22:20] * Joins: webben (n=benh@91.84.143.253)
  620. # [22:22] <hallvors> oh do we? I actually thought we didn't :-p off to test..
  621. # [22:22] <hallvors> javascript:void(setTimeout( function(a){alert(a)}, 100, 'hi' ));
  622. # [22:22] <hallvors> you're right :)
  623. # [22:22] <aa> We're going to put timers into Workers in Gears and was just wondering about support for comparison. We'll just do all of them.
  624. # [22:24] <Philip`> Firefox is fun because it passes an extra argument to the function, indicating how many milliseconds late it was
  625. # [22:24] <aa> yeah "fun". I have been bitten by that bug.
  626. # [22:25] <othermaciej> one thing that is weird about timers in browsers is that the rate at which they can fire is limited, due to OS limitations on windows and for compatibility on mac
  627. # [22:25] <othermaciej> dunno if the spec handles that
  628. # [22:26] <othermaciej> I think IE does not support the extra args in the function case and other browsers don't support the language parameter in the string case
  629. # [22:26] <Philip`> I believe browsers vary in terms of whether they run the function multiple times as fast as possible until it catches up with the requested rate, or if they just start dropping calls when they're too slow
  630. # [22:27] <Philip`> (Also, Firefox limits the time to be no less than 10msec)
  631. # [22:27] <aa> I think we are just going to implement it in terms of nsITimer on Firefox, so it will be whatever it does. Dunno about on windows.
  632. # [22:32] * Joins: weinigLap_ (n=weinig@17.255.100.42)
  633. # [22:33] * Joins: virtuelv_ (n=virtuelv@47.80-202-66.nextgentel.com)
  634. # [22:34] * Quits: weinigLap (i=weinig@nat/apple/x-6b5288178f4e295a) (Read error: 104 (Connection reset by peer))
  635. # [22:34] * Joins: weinigLap (i=weinig@nat/apple/x-9a0118f11cc9f51e)
  636. # [22:38] <Philip`> From some experiments I tried ages ago: On Windows (where various timer things have 16ms resolution), when doing setInterval(f, 1), everything (Opera, FF, Safari, IE) runs the function once every 16ms
  637. # [22:40] <Philip`> When the interval is larger, but the script takes a long time to run, FF remembers how far behind it is and then tries running once every 16ms until it has caught up. None of the other browsers do that - they always just wait another roundup(time, 16ms) before running the function again
  638. # [22:41] <virtuelv_> Philip`: You're _sure_ that's accurate?
  639. # [22:43] <othermaciej> Philip`: I think in Safari we only throttle to 10ms, not 16ms
  640. # [22:43] <othermaciej> Philip`: we don't rely on the Windows system call that would limit it to 16ms resolution IIRC
  641. # [22:44] <othermaciej> (could be wrong though)
  642. # [22:45] <Philip`> On Linux, Opera runs consistently at 10ms when I do setInterval(f, 1), and FF2 runs slightly less consistently at roughly 10-14ms
  643. # [22:45] <Philip`> (Hmm, looks like the interval-catchup has changed in FF3)
  644. # [22:46] <othermaciej> on windows the interval varies with the OS and whether you have a single CPU/core or multiple
  645. # [22:49] <Philip`> http://canvex.lazyilluminati.com/misc/timer.html - that does setInterval(f, 1), and does lots of computation for the first 64 repeats, then does nothing for the next 192, and reports the measured time intervals via Date()
  646. # [22:50] <Philip`> (On Windows, Date() is limited to 16ms resolution, but it should alternate between 16 and 0 if the function is being run more frequently than that)
  647. # [22:50] <virtuelv_> note that setInterval with lower than 15/16ms is wildly inaccurate
  648. # [22:50] <Philip`> In every browser in Windows (in VMware) I get lots of 16s at the end
  649. # [22:51] <virtuelv_> timers don't run more often either, fwiw
  650. # [22:52] <virtuelv_> The practical limit for Opera on Linux is 8
  651. # [22:52] <Philip`> virtuelv_: Yep, it's just trying to find the maximum frequency which the browser will run at - they all seem to be limited to 16ms on Windows (and less limited on Linux)
  652. # [22:53] <virtuelv_> 16ms is the safe bet on any platform
  653. # [22:54] * Quits: weinigLap_ (n=weinig@17.255.100.42) (Read error: 110 (Connection timed out))
  654. # [22:54] <Philip`> It's a bit of a pain when you're trying to write real-time games in a web browser :-(
  655. # [22:54] * Parts: hallvors (n=hallvord@pat-tdc.opera.com)
  656. # [22:54] <virtuelv_> if you're doing animation, I'd probably just specify something to reach an acceptable target framerate
  657. # [22:54] <virtuelv_> 20,25 or so
  658. # [22:55] <Philip`> ...though fortunately my game ended up running at about 8fps, so timers weren't the problem that I had anticipated :-)
  659. # [22:55] <virtuelv_> then again, I have some code for a presentation library where I break my own rule, by specifying 0
  660. # [22:55] <virtuelv_> for transitions and similar
  661. # [22:55] <virtuelv_> hm
  662. # [22:56] <virtuelv_> :)
  663. # [22:58] <Philip`> https://bugzilla.mozilla.org/show_bug.cgi?id=376643
  664. # [22:59] <Philip`> Looks like that's why they stopped the try-to-catch-up-when-running-too-slowly behaviour in FF3
  665. # [23:02] * Quits: Jero (n=Jero@d207230.upc-d.chello.nl) ("ChatZilla 0.9.78.1 [Firefox 2.0.0.4/2007051502]")
  666. # [23:04] <Philip`> http://msdn2.microsoft.com/en-us/library/ms536753.aspx - hmm, did they even try running the second example there?
  667. # [23:07] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  668. # [23:08] * Joins: Aidan_ (i=adrian54@aaog107.neoplus.adsl.tpnet.pl)
  669. # [23:08] * Aidan_ is now known as Aidan
  670. # [23:10] <Hixie> Lachy: of course, ratatouille is the best movie of the year
  671. # [23:14] * Philip` wonders if it's possible to get web browsers to load a 0x0 image
  672. # [23:14] <Philip`> (I don't think PNG can do that, but I'm not sure about other formats...)
  673. # [23:16] <Philip`> (Looks like JPEG probably can't do that either, given how it crashes when I try to save)
  674. # [23:18] * Quits: weinigLap (i=weinig@nat/apple/x-9a0118f11cc9f51e) (Read error: 104 (Connection reset by peer))
  675. # [23:18] * Joins: weinigLap (i=weinig@nat/apple/x-0be3c2ccefb3f1d9)
  676. # [23:28] * Parts: Aidan (i=adrian54@aaog107.neoplus.adsl.tpnet.pl)
  677. # [23:29] <Philip`> Hmm, looks like it's not possible at all - I can construct a 0x0 BMP but they refuse to load it
  678. # [23:29] <Hixie> rofl @ the e-mail in www-html
  679. # [23:32] <Hixie> http://lists.w3.org/Archives/Public/www-html/2007Jun/0008.html
  680. # [23:45] <othermaciej> My favorite line: "The Christians took 325 years to produce their spec, before declaring a Rec at the Council of Nicaea."
  681. # [23:47] <Hixie> there are definitely some places where i was misquoted
  682. # [23:47] <Hixie> for example, not killing people has to be a MUST, not a SHOULD
  683. # [23:49] <othermaciej> thou MUST NOT kill
  684. # [23:49] <Hixie> ironcially, "thou shalt not kill" is very close to rfc2119 terminology
  685. # [23:49] <othermaciej> but what about the exception list?
  686. # [23:49] <Hixie> because 2119 defines "shall not"
  687. # [23:49] <othermaciej> oh yeah
  688. # [23:49] <Hixie> what exceptions?
  689. # [23:49] <othermaciej> self-defense?
  690. # [23:50] <othermaciej> I think we want to support that, at least as an option
  691. # [23:50] <Hixie> you shouldn't kill, even in self-defence
  692. # [23:50] <Hixie> valid concern, though
  693. # [23:50] <Hixie> i think Bible5 will be easier than SVG5, which the article claims i'll have already done by 2008
  694. # [23:51] <othermaciej> with Bible5 you can just delete the mass of non-normative material and not much remains
  695. # [23:51] <Hixie> actually that was my first thought when i read it
  696. # [23:52] <Hixie> i was like "well that'll be a short book, if i write it"
  697. # [23:56] <jgraham_> Have you two considered a career in stand up if this web thing doesn't take off?
  698. # [23:57] <jgraham_> The feedline-punchline thing there worked for me anyway
  699. # [23:57] * jgraham_ goes back to packing
  700. # Session Close: Sat Jun 23 00:00:00 2007

The end :)