/irc-logs / freenode / #whatwg / 2008-07-18 / end

Options:

  1. # Session Start: Fri Jul 18 00:00:00 2008
  2. # Session Ident: #whatwg
  3. # [00:14] * mpt is now unpleasantly surprised that <aside> doesn't work in Firefox 2
  4. # [00:15] <Philip`> Upgrade to FF3 :-)
  5. # [00:15] <mpt> I have, but ~11% of our page hits come from FF2
  6. # [00:17] <Philip`> Wait a few months
  7. # [00:17] <Philip`> and then everyone else should have upgraded
  8. # [00:18] <Dashiva> Not unless it gets backported to fifteen million linux distros
  9. # [00:19] <Philip`> Fourteen point many-nines of those Linux distros have no users, so they don't matter
  10. # [00:20] <Philip`> Uh
  11. # [00:20] <Philip`> Fourteen point many-nines millions
  12. # [00:20] <Philip`> and Ubuntu already has FF3 and who cares about anything else
  13. # [00:20] <mpt> So you're saying I should buy Alexander Sack lunch tomorrow, then? :-)
  14. # [00:21] <Dashiva> Philip`: Ubuntu newer than some version, yes
  15. # [00:21] <mpt> (for shipping Ubuntu 8.04 with FF3 beta instead of FF2)
  16. # [00:22] * Philip` sees that Gentoo has mozilla-firefox-3.0 and mozilla-firefox-bin-3.0, but not marked as stable yet :-(
  17. # [00:22] * Joins: webben (n=benh@dip5-fw.corp.ukl.yahoo.com)
  18. # [00:23] <mpt> 63% of our page hits are from people using Linux, but still FF2 is at 12%
  19. # [00:25] <mpt> <div class="aside"> is looking tempting ;-)
  20. # [00:26] * Quits: hasather (n=hasather@ti0034a380-2730.bb.online.no) (Remote closed the connection)
  21. # [00:27] * Joins: hasather (n=hasather@ti0034a380-2730.bb.online.no)
  22. # [00:30] * Parts: hasather (n=hasather@ti0034a380-2730.bb.online.no)
  23. # [00:34] * Quits: heycam (n=cam@124-168-84-21.dyn.iinet.net.au) ("bye")
  24. # [00:37] * Joins: mcarter (n=mcarter@li4-186.members.linode.com)
  25. # [00:38] <gsnedders> Philip`: Well get a better distro yourself :P
  26. # [00:49] <Lachy> JohnResig, yt?
  27. # [00:56] <gsnedders> Yay!
  28. # [00:56] <gsnedders> I've made sense of the status detection done by the spec-gen, at last
  29. # [00:57] <Hixie> mpt: <div class="aside"> is what i would recommend for now anyway
  30. # [00:57] <gsnedders> It stops looking at "latest version"
  31. # [00:57] <mpt> ok
  32. # [01:00] * Joins: kingryan (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net)
  33. # [01:03] * Joins: othermaciej_ (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  34. # [01:03] * Quits: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  35. # [01:05] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
  36. # [01:14] * othermaciej_ is now known as othermaciej
  37. # [01:18] * Quits: csarven (n=csarven@modemcable144.140-202-24.mc.videotron.ca) (Read error: 110 (Connection timed out))
  38. # [01:20] <gsnedders> Lachy: I now have <!--begin-link-->http://example.com<!--end-link--> working
  39. # [01:22] <Lachy> is there some more abbreviated syntax you could use insted? Perhaps wiki style: [http://example.com/]
  40. # [01:22] <Philip`> I suggest <a href="http://example.com">
  41. # [01:23] <gsnedders> Philip`: Heh. The entire point is to _AVOID_ that.
  42. # [01:23] <gsnedders> We want something to become the content of a link
  43. # [01:23] <Lachy> Philip`, we want to avoid using that because it's for the situations where the link text is the URL itself
  44. # [01:23] <gsnedders> i.e., that above example becomes <a href=http://example.com>http://example.com</a>
  45. # [01:24] <Philip`> Ah, I can see how it's a terrible burden to have to copy-and-paste a bit of text onto the same line
  46. # [01:24] <gsnedders> Lachy: Is [DATE] a relative URL, or is it wanting the current date?
  47. # [01:24] <Lachy> maybe it would have to be [URL http://.../]
  48. # [01:25] * Quits: toolskyn (n=toolskyn@apher.xlshosting.com) (Remote closed the connection)
  49. # [01:26] <Lachy> gsnedders, it's just the current date
  50. # [01:26] <Lachy> that's why [URL ...] would work
  51. # [01:26] <gsnedders> Yeah, sure
  52. # [01:27] <gsnedders> I'd suggest [[]], but then we hit issues with biblio
  53. # [01:27] <Lachy> yep, that's why I didn't suggest it
  54. # [01:27] <Lachy> the W3C processor seems to accept random crap within "[DATE ... ]"
  55. # [01:28] <gsnedders> It needs a colon, does it not?
  56. # [01:28] <gsnedders> (at least it does if you believe the docs)
  57. # [01:28] <Lachy> dunno, will test
  58. # [01:28] <Lachy> no colon needed
  59. # [01:29] * Joins: csarven (n=csarven@modemcable144.140-202-24.mc.videotron.ca)
  60. # [01:36] * Quits: Lachy (n=Lachlan@85.196.122.246) ("Leaving")
  61. # [01:37] * Joins: Lachy (n=Lachlan@85.196.122.246)
  62. # [01:38] <Hixie> man, this preprocessor does way more than i use it for :-)
  63. # [01:39] <gsnedders> Yeah, you barely use it :)
  64. # [01:39] <gsnedders> It also does all kinds of stuff that people rely upon that aren't in the docs
  65. # [01:39] <gsnedders> like [LONGSTATUS]
  66. # [01:39] <Hixie> wtf is longstatus
  67. # [01:40] <gsnedders> "W3C Working Draft", for example
  68. # [01:40] <Hixie> i remember trying to use that stuff and it would never work
  69. # [01:40] <Hixie> i actually have to escape one of the stylesheet URLs to prevent it from screwing it up
  70. # [01:40] <gsnedders> (opposed to [STATUS] which would give "WD")
  71. # [01:40] <gsnedders> Hixie: Because it changes it? Yeah, it's weird.
  72. # [01:40] <Hixie> maybe that was before ED was supported
  73. # [01:41] <Hixie> anyway WHATWG drafts don't have that problem
  74. # [01:41] <Hixie> :-)
  75. # [01:41] <gsnedders> Hixie: I can tell you how it gets the status, after several hours of trying to work that out :P
  76. # [01:42] <Hixie> :-)
  77. # [01:42] <gsnedders> Hint: Everything the docs says about [STATUS] is wrong.
  78. # [01:42] <Hixie> i take it it is a completely different way than the way the pubrules checker gets it?
  79. # [01:42] <Hixie> there are docs?
  80. # [01:42] <gsnedders> dunno. Haven't tried :)
  81. # [01:43] <gsnedders> insofar as http://www.w3.org/Style/Group/css3-src/bin/README.html is a doc, yes
  82. # [01:43] <Hixie> oh hey what was it you wanted me to change in html5?
  83. # [01:43] <gsnedders> Not that I have a copy of that, obviously
  84. # [01:43] <gsnedders> Hixie: I can't remember.
  85. # [01:43] <Hixie> k
  86. # [01:43] <gsnedders> Hixie: We can try and work that out once it's done: run the spec through in w3c-compat and not, then diff it
  87. # [01:45] <Hixie> ok well just let me know when you know :-)
  88. # [01:45] <gsnedders> Hixie: Ah, it was that you rely on "setInterval(...)" being the same as "setInterval" for xref
  89. # [01:45] <Hixie> oh that's gonna be all over the place
  90. # [01:46] <gsnedders> I was guessing that :P
  91. # [01:46] <gsnedders> I don't like that behaviour, so it's w3c-compat only :D
  92. # [01:47] <gsnedders> Lachy: I could just check that [foo] was an absolute URL
  93. # [01:48] <Hixie> oh actually that doesn't happen as much as i expected
  94. # [01:48] <gsnedders> I can give you something that will show everywhere where it does :P
  95. # [01:48] <Hixie> fixed those i could find
  96. # [01:48] <Hixie> sure
  97. # [01:52] <gsnedders> Wow. that's a lot.
  98. # [01:54] <gsnedders> Actually, no, that's me being stupid.
  99. # [01:55] <gsnedders> http://pastebin.ca/1074875 — these are all the terms that are changed by the aggressive normalisation
  100. # [01:56] <Lachy> gsnedders, I don't mind how you do it. Just make it simple to use.
  101. # [01:58] <gsnedders> Hixie: cleartimeout and clearinterval and setinterval
  102. # [02:00] <gsnedders> Hixie: those are the only ones used in such a way that breaks without the normalisation
  103. # [02:01] * Quits: aaronlev (n=chatzill@e180239115.adsl.alicedsl.de) (Read error: 110 (Connection timed out))
  104. # [02:03] <gsnedders> Hixie: Actually, no, that's still wrong
  105. # [02:08] <gsnedders> No, I think that's right.
  106. # [02:08] * gsnedders shuts up
  107. # [02:08] * gsnedders goes to sleep
  108. # [02:11] * Joins: KevinMarks (n=KevinMar@nat/google/x-4d7595fba870afd2)
  109. # [02:16] * Quits: mcarter (n=mcarter@li4-186.members.linode.com) (Remote closed the connection)
  110. # [02:23] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  111. # [02:26] <Hixie> gsnedders: couldn't find any occurances of cleartimeout and clearinterval and setinterval that didn't have a title="" attribute
  112. # [02:43] <Hixie> i am minting URL_MISMATCH_ERR exception code 19
  113. # [03:07] <Hixie> holy crap this is going to be complicated
  114. # [03:07] <Hixie> what happens if you create a worker, but the script takes a long time to download
  115. # [03:07] <Hixie> and in the meantime, the user has navigated the window
  116. # [03:08] <Hixie> but the user agent hasn't expired the document, merely suspended it and its global object and scripts in session history
  117. # [03:08] <Hixie> and then you go back
  118. # [03:11] * Quits: billmason (n=billmaso@ip175.unival.com) (".")
  119. # [03:17] * Quits: KevinMarks (n=KevinMar@nat/google/x-4d7595fba870afd2) ("The computer fell asleep")
  120. # [03:23] * Joins: mcarter (n=mcarter@li4-186.members.linode.com)
  121. # [03:24] <Hixie> heycam: yt?
  122. # [03:25] <Hixie> heycam: i got a problem with workes and webidl
  123. # [03:25] <heycam> hi Hixie
  124. # [03:25] <Hixie> heycam: WebIDL 4.3 Interfaces says "For every interface that is not declared with the [NoInterfaceObject] extended attribute, a corresponding property must exist on the ECMAScript global object whose name is the identifier of the interface."
  125. # [03:25] <Hixie> heycam: but now there are two types of global objects, those that implement WindowBrowsingContext and those that implement WindowWorker
  126. # [03:26] <Hixie> (and those that implement neither, e.g. as the global object of the script in <img src="javascript:...">)
  127. # [03:26] <Hixie> we need a way to say which global objects these things end up visible in
  128. # [03:26] * Joins: tantek (n=tantek@70-13-204-170.area2.spcsdns.net)
  129. # [03:27] <heycam> hmm, so you need to scope a bunch of IDL to cause interfaces to exist on a particular global object
  130. # [03:27] <Hixie> or multiple objects
  131. # [03:28] <heycam> pointer to the WindowBrowsingContext / WindowWorker stuff?
  132. # [03:28] <Hixie> e.g. new WebSocket() needs to be in both WindowWorker and WindowBrowsingContext global objects, but not the null global object
  133. # [03:28] <Hixie> http://www.whatwg.org/specs/web-workers/current-work/#windowworker and http://www.whatwg.org/specs/web-apps/current-work/#windowbrowsingcontext
  134. # [03:29] <Hixie> http://www.whatwg.org/specs/web-workers/current-work/#apis-available shows how this is getting complicated in other senses too
  135. # [03:30] <Hixie> i need to go get food, but i'll be back online later. feel free to mention any ideas you may have and i'll read them when i get back.
  136. # [03:30] <heycam> ok
  137. # [03:32] * Joins: sverrej (n=sverrej@062016159204.customer.alfanett.no)
  138. # [03:43] <heycam> Hixie, is the main case that interface objects should appear on all global objects?
  139. # [03:43] <heycam> i'm wondering whether putting [GlobalObject=<identifier-list>] on those you want to restrict would be too onerous
  140. # [03:44] * Quits: scotfl (n=scotfl@S0106001b114f914a.ss.shawcable.net) (Read error: 104 (Connection reset by peer))
  141. # [03:44] <heycam> and then in your specs you'd say how those identifiers map to the different global objects you have
  142. # [03:44] * Joins: scotfl (n=scotfl@S0106001b114f914a.ss.shawcable.net)
  143. # [03:44] * Quits: tantek (n=tantek@70-13-204-170.area2.spcsdns.net)
  144. # [03:51] * Quits: sverrej (n=sverrej@062016159204.customer.alfanett.no) (Read error: 110 (Connection timed out))
  145. # [03:59] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  146. # [04:13] * Quits: csarven (n=csarven@modemcable144.140-202-24.mc.videotron.ca) ("http://www.csarven.ca/")
  147. # [04:18] * Quits: mcarter (n=mcarter@li4-186.members.linode.com) (Remote closed the connection)
  148. # [04:19] * Joins: dbaron (n=dbaron@c-71-198-188-254.hsd1.ca.comcast.net)
  149. # [04:19] * Joins: csarven (n=csarven@modemcable144.140-202-24.mc.videotron.ca)
  150. # [04:36] * Joins: mcarter (n=mcarter@li4-186.members.linode.com)
  151. # [05:21] * Joins: jacobolus (n=jacobolu@pool-71-104-114-242.lsanca.dsl-w.verizon.net)
  152. # [05:46] * Quits: jacobolus (n=jacobolu@pool-71-104-114-242.lsanca.dsl-w.verizon.net)
  153. # [05:53] * Quits: mcarter (n=mcarter@li4-186.members.linode.com) (Nick collision from services.)
  154. # [05:54] * Joins: mcarter (n=mcarter@li4-186.members.linode.com)
  155. # [06:00] * Quits: mcarter (n=mcarter@li4-186.members.linode.com) (Remote closed the connection)
  156. # [06:12] * Quits: kingryan (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net)
  157. # [06:28] * Joins: jacobolus (n=jacobolu@pool-71-119-200-174.lsanca.dsl-w.verizon.net)
  158. # [06:47] * Joins: eseidel (n=eseidel@c-67-176-133-229.hsd1.il.comcast.net)
  159. # [06:56] * Quits: csarven (n=csarven@modemcable144.140-202-24.mc.videotron.ca) (Read error: 110 (Connection timed out))
  160. # [07:00] <MikeSmith> "the Window object's browsing context's active document's effective script origin" is quite a mouthful
  161. # [07:02] <MikeSmith> though it conveniently forms a pronounceable acronym
  162. # [07:02] <MikeSmith> the WOBCADESO
  163. # [07:11] * Joins: bradeeoh (n=bradeeoh@web7.webfaction.com)
  164. # [07:13] * Quits: weinig (n=weinig@nat/apple/x-0a0ab1152d9175e0)
  165. # [07:14] * Quits: bradee-oh (n=bradeeoh@web7.webfaction.com) (kornbluth.freenode.net irc.freenode.net)
  166. # [07:14] * Joins: harig (n=harig_in@122.160.12.230)
  167. # [07:16] * Joins: bradee-oh (n=bradeeoh@web7.webfaction.com)
  168. # [07:16] * Quits: bradee-oh (n=bradeeoh@web7.webfaction.com) (Read error: 104 (Connection reset by peer))
  169. # [07:26] * Joins: eseidel_ (n=eseidel@c-67-176-133-229.hsd1.il.comcast.net)
  170. # [07:27] * Quits: eseidel (n=eseidel@c-67-176-133-229.hsd1.il.comcast.net) (Connection reset by peer)
  171. # [07:40] <Hixie> heycam: actually no, the common case is that the interfaces are only visible to global objects that implement WindowBrowsingContext
  172. # [07:41] <Hixie> pretty much nothing (only ECMA262-defined types) are visible to the "empty" global object, for instance
  173. # [07:41] <heycam> where's this empty one defined? i tried searching for "null global object" but didn't get anywhere.
  174. # [07:42] * Joins: hdh (n=hdh@118.71.121.99)
  175. # [07:43] <Hixie> http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#script0
  176. # [07:44] <Hixie> and http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-javascript paragraph 3
  177. # [07:45] <heycam> so "script browsing context" means the global script object?
  178. # [07:46] <Hixie> there's an open bug on figuring out what it means exactly
  179. # [07:46] <Hixie> global objects are very complex
  180. # [07:46] <Hixie> since the global object has to change when you navigate, but there's only one Window object per window
  181. # [07:47] <Hixie> so you get pschyzophrenic code
  182. # [07:50] <heycam> so is it possible for script to be running, the page navigates to something else, but that same script is running, and its global object is now a different object?
  183. # [07:50] * Joins: john_fallows (n=j_r_fall@ip-12-22-56-126.hqglobal.net)
  184. # [07:51] <Hixie> the global object is the same, but the 'window' attribute on that global object no longer points to the global object, even though the value it used to have is === the value that it had when it _was_ equal to the global object
  185. # [07:52] <heycam> ah, interesting
  186. # [07:52] <heycam> i never realised they could be different
  187. # [07:52] <Hixie> the web is a crazy crazy platform
  188. # [07:53] <Hixie> basically the Window object reflects the properties of the global object of the active document
  189. # [07:53] <Hixie> and you can never get a pointer to the actual global object
  190. # [07:53] <Hixie> as i understand it
  191. # [07:54] <heycam> huh?
  192. # [07:54] <heycam> so you don't consider the Window object to be the actual global object?
  193. # [07:56] <Hixie> well right now none of this is defined
  194. # [07:56] <Hixie> but yeah
  195. # [07:57] <heycam> that's kind of strange
  196. # [07:57] <heycam> i mean, always though the Window object was exactly the same object that 'this' refers to at the top level of your script
  197. # [07:57] <heycam> s/always though/i &t/
  198. # [07:58] <Hixie> it is
  199. # [07:58] <Hixie> the 'this' is not the actual global object, it turns out
  200. # [07:58] <Hixie> but an object pretending to be it
  201. # [07:58] <Hixie> as i understand it
  202. # [07:59] <heycam> then i resign
  203. # [07:59] <Hixie> see also http://www.w3.org/Bugs/Public/show_bug.cgi?id=5850
  204. # [07:59] <heycam> :)
  205. # [07:59] <Hixie> q.v. topic :-)
  206. # [08:03] <heycam> so html5 will says something like: "when you go to run a script, instead of evaluating it with the ecma-262 global object as the 'this' value, evaluate it with this strange Window object that mostly reflects the ecma-262 global object as the 'this' value"?
  207. # [08:03] * Joins: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de)
  208. # [08:04] * Quits: eseidel_ (n=eseidel@c-67-176-133-229.hsd1.il.comcast.net)
  209. # [08:04] <Hixie> dunno, haven't figured it out yet
  210. # [08:06] <heycam> let me know when you do :)
  211. # [08:06] <heycam> (well, i'll see the mails from the bug anyway)
  212. # [08:07] <heycam> then i'll think more about idl support for this stuff
  213. # [08:07] * heycam out
  214. # [08:07] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) ("bye")
  215. # [08:08] <Hixie> thanks
  216. # [08:08] <Hixie> later
  217. # [08:21] * Quits: john_fallows (n=j_r_fall@ip-12-22-56-126.hqglobal.net) (Remote closed the connection)
  218. # [08:26] * Joins: eseidel (n=eseidel@c-67-176-133-229.hsd1.il.comcast.net)
  219. # [08:32] * Quits: MikeSmith (n=MikeSmit@58.157.21.205) ("Less talk, more pimp walk.")
  220. # [08:42] * Joins: jacobolus1 (n=jacobolu@pool-71-119-200-174.lsanca.dsl-w.verizon.net)
  221. # [08:44] * Joins: heycam (n=cam@124-168-84-21.dyn.iinet.net.au)
  222. # [08:51] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  223. # [09:02] * Quits: jacobolus (n=jacobolu@pool-71-119-200-174.lsanca.dsl-w.verizon.net) (Read error: 110 (Connection timed out))
  224. # [09:04] * Quits: dbaron (n=dbaron@c-71-198-188-254.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  225. # [09:42] <Lachy> damn, Andrew is really quite annoying to deal with on www-style. He's so damn persistent, and fails to understand problems I clearly describe to him.
  226. # [09:43] <Lachy> though, unfortunately, he does have a point about the use cases. I can't think of any compelling ones that need to have a selector evaluated against the whole documet; only technical problems with what he needs, that need to be solved.
  227. # [09:49] <Hixie> what's the question?
  228. # [09:50] <Lachy> what question?
  229. # [09:52] <Lachy> this is the mail I was talking about http://lists.w3.org/Archives/Public/www-style/2008Jul/0419.html
  230. # [09:53] <Hixie> i mean, what's the thing you need a use case for?
  231. # [09:54] <Hixie> i don't read www-style these days unless html5 or acid3 is in the body :-)
  232. # [09:54] <Hixie> yay for keyword filtering
  233. # [09:54] * Quits: eseidel (n=eseidel@c-67-176-133-229.hsd1.il.comcast.net)
  234. # [09:55] <Lachy> oh, with the way querySelector() is defined div.querySelector("body p") would still match, even though body is an ancestor of the div. I need a use case for when that would actually be necessary, rather than just restricting all selectors to match descendants of the element itself.
  235. # [09:56] <Lachy> the solution that is actually needed is a way to say things like querySelector(">p");, but that requries changes to selector parsing and for an implicit :scope to be prepended to the beginning.
  236. # [09:57] <Lachy> and for querySelector("+p"); to work, it needs to match the element's siblings as well.
  237. # [09:59] <Lachy> if Andrew is right (which would be a huge surprise), I wonder if it's too late to change it now.
  238. # [10:03] <gDashiva> Regular querySelector evaluates against entire document and only returns matches inside scope, right?
  239. # [10:04] <Lachy> yes
  240. # [10:04] <gDashiva> If there's an implicit :scope in the scopedQuerySelector the result filtering wouldn't need to happen
  241. # [10:05] <gDashiva> Since it would limit itself to matching descendants and siblings anyhow
  242. # [10:05] <Lachy> yeah, the problem is how to get the implicit :scope there in cases like this: ">em, >strong"
  243. # [10:05] <Lachy> it's possible, I wrote up a proposed pre-parse algorithm to do it, but not sure how reliable it is in all cases yet
  244. # [10:05] <gDashiva> But assuming the parser manages to insert :scope properly, it's all in the green?
  245. # [10:06] <Lachy> the other issue is that querySelector is only defined to check its descendant elements. It would also need to be changed to check its sibling elements
  246. # [10:07] <Lachy> but they would only ever match in the case of :scope+p
  247. # [10:07] <Lachy> or ~p
  248. # [10:07] <gDashiva> Couldn't you just remove the restriction entirely? Surely when the browser itself prepends :scope it also knows where to avoid matching :)
  249. # [10:08] <Lachy> I guess it could just be left up to browser's own optimisations
  250. # [10:09] <Lachy> so then document.querySelector() and element.querySelector() would be handled very differently from each other.
  251. # [10:09] <gDashiva> Scope is applied in both cases. For regular querySelector it limits the return, for scoped querySelect it limits the match.
  252. # [10:09] <gDashiva> (Although it might be necessary to give them separate names, for clarity)
  253. # [10:10] <Lachy> gDashiva, but what are the use cases for keeping the current querySelector around?
  254. # [10:10] <Lachy> the only somewhat compelling reason I have at the moment is that implementations are getting ready to ship, and such a huge change could delay things
  255. # [10:11] <Lachy> though, perhaps that's not a huge problem, since IE8 is still only beta 1, Firefox 3 only just shipped and probably won't ship with support in a final product for months
  256. # [10:11] <Lachy> same for Opera
  257. # [10:12] <Lachy> dunno, will need to check with implementers and re-evaluate the whole situation
  258. # [10:12] <gDashiva> Hmm... the old one is the scoped one on document + filtering, since scoping to document on the match is no scoping. So it's document.scoedQuerySelector().removeNonDescendantOf(element). And the question is a use case for the filtering.
  259. # [10:13] * Quits: webben (n=benh@dip5-fw.corp.ukl.yahoo.com)
  260. # [10:13] <Lachy> what?
  261. # [10:13] <gDashiva> The old element.querySelector matches against the whole document, but only returns results inside the element's scope, right?
  262. # [10:14] <Lachy> it evaluates elements in the context of the whole document, but only returns descendant elements. So it doesn't bother checking for matches outside
  263. # [10:14] * weinig is now known as weinig|zZz
  264. # [10:15] <gDashiva> True, using separate filtering would be a performance problem
  265. # [10:15] * Joins: virtuelv (n=virtuelv@192.80-203-77.nextgentel.com)
  266. # [10:16] <Hixie> Lachy: the use case is going through a CSS style sheet and making sure you match all the nodes that the style sheet matches
  267. # [10:16] <Hixie> Lachy: or the use case is if you want to do something to <h2> elements that are inside <aside> elements, it doesn't matter if the <aside> is in the scope or not
  268. # [10:16] <Lachy> Hixie, when would anyone ever do that?
  269. # [10:17] <Hixie> Lachy: i'm not really sure when anyone would do any of this
  270. # [10:17] <Lachy> in that case, you could do document.querySelector("aside h2")
  271. # [10:17] <Lachy> which is the same problem I'm having.
  272. # [10:17] <Hixie> no i mean for the entire feature
  273. # [10:17] <Hixie> i don't know why people ever want to select multiple elements
  274. # [10:18] <Lachy> oh, well, people do it with JS libraries, so they must have a reason
  275. # [10:18] <Hixie> or do anything scoped
  276. # [10:18] <Hixie> so, look at those reasons
  277. # [10:18] <Hixie> you can't write a spec without knowing what the spec will be used for
  278. # [10:18] <Lachy> yeah, but those all work the way queryScopedSelector() would work, rather than how querySelector() works now.
  279. # [10:19] <Hixie> so i guess that's what we should have
  280. # [10:19] <Lachy> which is why I need to know if things should stay as they are, or be changed to match what Andrew, and what JohnResig had asked for earlier.
  281. # [10:19] <gDashiva> Lachy: Well, apart from some unquantified performance loss, you can emulate querySelector using queryScopedSelector and filtering
  282. # [10:20] <gDashiva> So the use cases would still be satisfied
  283. # [10:20] <Hixie> if everyone is asking for X, and you can't find any reasons for Y, then it seems likely X is the way to go
  284. # [10:20] <Lachy> I know. I just don't know if it's too late to change things
  285. # [10:20] * Joins: Copyman (n=ano@82-204-22-72.dsl.bbeyond.nl)
  286. # [10:20] <Hixie> why would it be too late?
  287. # [10:20] <Lachy> because back when all this was discussed previously, we didn't have solutions to the technical problems
  288. # [10:20] <Hixie> ?
  289. # [10:21] <gDashiva> The :scope prepending
  290. # [10:21] * Copyman is now known as Maurice
  291. # [10:21] <Lachy> because implementers are already working on getting the current spec implemented and could be close to shipping. But if they're willing to change at this stage, it won't be too late
  292. # [10:21] <Lachy> I will write up a proposal for how it could be redefined and ask
  293. # [10:22] <Hixie> well you already have four methods, right? just add two more and be done with it
  294. # [10:22] <Hixie> it's trivial to define
  295. # [10:22] <Hixie> you just don't ever match any simple selectors on nodes outside the scope
  296. # [10:23] <Lachy> that simple approach doesn't solve the use cases though. That's described in solution 3 or 4 in http://lists.w3.org/Archives/Public/public-webapi/2008May/0057.html
  297. # [10:23] <Hixie> wait do you even have queryScopedSelector and queryScopedSelectorAll in the draft at all? i can't find them
  298. # [10:23] <Lachy> not yet
  299. # [10:24] <Lachy> we're just discussing whether to add them, or whether to redefine querySelector to be what they would have been
  300. # [10:25] <Hixie> well it can't be too late if they don't exist yet :-)
  301. # [10:25] <Hixie> oh i see, because you have the element and document ones on the same interface
  302. # [10:25] <Lachy> yes
  303. # [10:26] <Hixie> seems like for these use cases what you want is a non-scoped variant that sets the context node, actually
  304. # [10:26] <Lachy> what do you mean?
  305. # [10:27] <Hixie> someRandomElement.queryContextSelector(":context + p")
  306. # [10:27] <Hixie> matching someRandomElement.nextSibling if that's a <p>
  307. # [10:27] <Hixie> i.e. scope is Document, context node is someRandomElement
  308. # [10:28] <Lachy> oh, yeah, but to do what JS libraries do, we would need to make the :context (or :scope now) implicit
  309. # [10:28] <Hixie> screw that
  310. # [10:28] <Hixie> people can put in a pseudo-class, that's not a big deal.
  311. # [10:29] <Hixie> for a few versions the libraries can have a shim, they already have CSS parsers after all
  312. # [10:30] <Lachy> othermaciej argued that we should do it with implicit scope because:
  313. # [10:30] <Lachy> <othermaciej> Lachy: I think there are two reasons we may still want it:
  314. # [10:30] <Lachy> <othermaciej> 1) otherwise JS libraries have to do rewriting of their incoming
  315. # [10:30] <Lachy> selectors, which is both slower and more error-prone in JS code than in native
  316. # [10:30] <Lachy> code
  317. # [10:30] <Lachy> <othermaciej> 2) without a way to access those syntax features directly, it
  318. # [10:30] <Lachy> becomes harder for authors to ever switch off the library wrappers to the
  319. # [10:30] <Lachy> native version, even once all browsers support it
  320. # [10:31] <Lachy> currently, JQuery and other libraries have to change jquery(">div, >p") into ":scope>div, :scope>p" by themselves. The proposal is to make the browser to that in a standardised way
  321. # [10:32] <Hixie> the existing pages will keep using the existing libraries. new pages can use new libraries. it's not like there's a massive number of people who have existing code who will upgrade their libraries without upgrading their code to use new APIs in those libraries.
  322. # [10:32] <Hixie> so i call bs on othermaciej's reasons
  323. # [10:33] <Lachy> also, with your suggestion, would element.queryContextSelector("p"); only match descendant p elements, or all elements in the whole document?
  324. # [10:33] <Hixie> it would match the first <p> in the document
  325. # [10:33] <Lachy> that is unintuitive
  326. # [10:33] <Hixie> if you want the first in the subtree, use the filtered version (Element.querySelector())
  327. # [10:33] <Hixie> it's queryContextSelector() because it's for using :context
  328. # [10:33] <Lachy> which is worse than we have now, and authors are already complaining we did it wrong
  329. # [10:35] <Hixie> i'd have six methods, two each of Document.querySelector, Element.querySelector, and Element.queryContextSelector, with those three being document-wide selector matching, with the second one being filtered to the element, and the last two having the element as the :context node
  330. # [10:35] <Hixie> that handles all the use cases pretty simply
  331. # [10:36] <Hixie> and doesn't require any silly breaking of Selector rules like scoping what simple selectors can match on
  332. # [10:36] <Hixie> nor redefining what selectors mean by adding pseudo-classes in or whatever
  333. # [10:38] <Lachy> so element.querySelector(":scope p"); would match the same as element.queryContextSelector(":scope p"); but they would differ in their handling of ":scope+p". Is that right?
  334. # [10:39] <Hixie> i wouldn't call it :scope if you do this, but yes
  335. # [10:39] <Lachy> queryContextSelector() might be more intuitive as document.querySelector(":scope p", contextNode);
  336. # [10:39] <Hixie> that would be fine too
  337. # [10:39] <Hixie> (i still wouldn't call it :scope though)
  338. # [10:39] <Lachy> fine, the name isn't important.
  339. # [10:41] <Lachy> so your proposal is to keep exactly what we have now and add queryContextSelector or equivalent. But that doesn't help me deal with the problems people are having with querySelector now.
  340. # [10:42] <Hixie> sure, just tell them to give a contextNode
  341. # [10:43] * Joins: harig_ (n=harig_in@122.160.12.230)
  342. # [10:46] * Quits: harig (n=harig_in@122.160.12.230) (Nick collision from services.)
  343. # [10:46] * harig_ is now known as harig
  344. # [10:50] * Joins: webben (n=benh@nat/yahoo/x-e7683f44867ff003)
  345. # [10:52] <othermaciej> Hixie: why is your rebuttal relevant to my reasons?
  346. # [10:53] * Joins: ROBOd (n=robod@89.122.216.38)
  347. # [10:53] <othermaciej> Hixie: both library authors and web developers appear to like the scoped semantics (in some case, to the degree of apoplectic rage at the suggestion of anything else)
  348. # [10:53] <othermaciej> I would call it queryScopedSelector not queryContextSelector btw
  349. # [10:53] <Hixie> for 1, because i'm saying there's no rewriting needed, and for 2, because i'm saying we should offer those features (albeit not with a compatible syntax).
  350. # [10:54] <othermaciej> "context selector" doesn't make sense
  351. # [10:54] <Hixie> it's not scoped
  352. # [10:54] <othermaciej> I guess it depends on what you mean by it
  353. # [10:54] <Hixie> if ":context + p" matches something, then clearly you're not scoped to :context
  354. # [10:54] <Hixie> since a node's sibling is outside the node
  355. # [10:54] <Hixie> this would become even more relevant with something like :has() or, worse, :matches().
  356. # [10:55] <othermaciej> that's true, the + version would in fact be unscoped relative to the normal version
  357. # [10:55] <othermaciej> I hadn't imagined catering to the + exception
  358. # [10:55] <Hixie> it was in lachy's list of what people do/need
  359. # [10:55] <Hixie> if we're not worrying about what they need, then we should screw the whole scoped thing and keep the spec as is :-)
  360. # [10:56] <othermaciej> I recall from past discussions that people were less fervent about that than "div span" only matching if the div is the element queried on or inside it, and not if the whole thing happens to be contained in a div
  361. # [10:57] <othermaciej> (in fact I recall at least one JS library author conceding that "+ p" didn't entirely make sense)
  362. # [10:57] <Lachy> othermaciej, which JS author?
  363. # [10:58] <Hixie> if we give them "div:context span" then that use case is handled fine
  364. # [10:58] <othermaciej> I can't remember
  365. # [10:58] <othermaciej> Hixie: I am sure JS libraries will rewrite their current pseudo-selector syntax into that, and their clients will continue to just write "div span"
  366. # [10:59] <Lachy> Hixie, sure, :context as currently defined can handle every use case except the +p case.
  367. # [10:59] <othermaciej> incidentally "div:context span" would not mean the same thing
  368. # [10:59] <othermaciej> ":context div span" would
  369. # [10:59] <Hixie> othermaciej: why would they?
  370. # [10:59] * Joins: aaronlev (n=chatzill@e180239115.adsl.alicedsl.de)
  371. # [11:00] * Joins: sverrej (n=sverrej@pat-tdc.opera.com)
  372. # [11:00] <othermaciej> Hixie: at least some library authors have said they feel obligated to (and in some cases deeply enthusiastic about) maintaining their current syntax
  373. # [11:00] <Hixie> sure but that doesn't preclude them providing new APIs
  374. # [11:00] <othermaciej> presumably they are in touch with their clients
  375. # [11:00] <Hixie> basically the way i see it the current installed base pales in comparison to the future uses
  376. # [11:01] <Hixie> it's not like we're breaking back compat, we're just not making the back compat faster.
  377. # [11:01] <othermaciej> sure, but why not give them what they want?
  378. # [11:01] <othermaciej> is there a downside?
  379. # [11:01] <Lachy> Hixie, what future uses are we addressing by failing to directly meet their needs, instead of indirectly via :context as we are now?
  380. # [11:01] <othermaciej> one more method plus one more selector parser or preprocessor is not a big deal implementation-wise
  381. # [11:01] <othermaciej> the only reason not to do it as far as I can tell is a sense of purity
  382. # [11:02] <Lachy> othermaciej, should we keep querySelector() as defined, or just redefine it to what queryScopedSelector() would have been?
  383. # [11:02] <Hixie> what they want is a new selector syntax
  384. # [11:02] <Lachy> yes, which has been my argument against them till now
  385. # [11:02] <Hixie> that's a whole ton more speccing, developing, and testing work than what i think we want to do
  386. # [11:03] <othermaciej> Lachy: I think querySelector may already be used enough to preclude completely redefining it
  387. # [11:03] <Hixie> so that's the reason for not doing what they are asking for
  388. # [11:03] <gsnedders> Something is going oddly wrong in my spec-gen
  389. # [11:03] <Hixie> we can cater for the exact same use cases with a much cleaner mechanism
  390. # [11:03] <othermaciej> the cost seems low compared to the benefit of making them happy
  391. # [11:04] <othermaciej> and the cost will be borne mostly by Lachy and by implementors
  392. # [11:04] <Hixie> well, it's not me who has to pay the cost, so if you can get the css group to define a new syntax for selectors, along with creating a new test suite, and implementors are up for it, go for it
  393. # [11:05] <Hixie> personally i think that's a high cost for making people feel happy when we could address their same use cases in a much cleaner and simpler way that, once they realised it addressed their use cases, would likely make them just as happy
  394. # [11:05] <Hixie> (not to mention it's more powerful going forward)
  395. # [11:05] <othermaciej> if the new syntax is defined by translation to the canonical selector syntax then I see no need to involve the CSS WG
  396. # [11:05] <Lachy> Hixie, the proposed solution addresses it with a pre-parse that inserts :context (or whatever) in the appropriate places before parsing as a normal selector
  397. # [11:05] <othermaciej> I do like :scope/:context and I think it should probably be done first
  398. # [11:06] <othermaciej> that will give us more information on whether JS library authors or Web developers in general are inclined to switch
  399. # [11:06] <Lachy> othermaciej, can you respond to Andrew on www-style or public-webapps and help me explain to him why the current solution is good?
  400. # [11:06] <gsnedders> Ah! I've found teh bug!
  401. # [11:06] * Hixie has a low opinion of specs that define things in terms of transforming one syntax into another
  402. # [11:06] <Hixie> seems like a hack to me
  403. # [11:07] <Hixie> but it's not my problem :-)
  404. # [11:07] <Lachy> Hixie, sure, it is a hack
  405. # [11:07] <Hixie> the platform has enough hackiness without adding more
  406. # [11:08] <Hixie> it's not like any sane implementor will actually implement it as a preparse
  407. # [11:08] <Hixie> parsing selectors is slow enough as it is
  408. # [11:08] <Hixie> without having to do it twice each time
  409. # [11:08] <Hixie> given that these methods are likely to be called in tight loops
  410. # [11:08] <othermaciej> I would guess parsing is a trivial fraction of the cost of querySelector
  411. # [11:08] <Hixie> so whether the csswg is involved or not, it's still a new syntax
  412. # [11:08] <Lachy> Hixie, the other solution was to slightly modify the grammar of selectors as described here http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0181.html
  413. # [11:08] <othermaciej> (that's a pretty well educated guess)
  414. # [11:09] <Hixie> othermaciej: on scoped trees with caching? i'm surprised.
  415. # [11:10] <othermaciej> Shark don't lie
  416. # [11:10] <othermaciej> we only use caching for the most trivial of selectors (otherwise maintaining correctness of the cache would be too complicated to be worth the benefit in the unlikely case that you redo the identical query on the same subtree)
  417. # [11:11] <gsnedders> teh webs are teh weirdness.
  418. # [11:17] * Quits: Lachy (n=Lachlan@85.196.122.246) ("This computer has gone to sleep")
  419. # [11:18] <gsnedders> Hixie: I think title=">HTML documents" is a bug
  420. # [11:18] <Hixie> fixed
  421. # [11:20] <gsnedders> Hixie: http://pastebin.ca/1075314 — That's a diff of everything going from the aggressive normalisation to next to none
  422. # [11:20] <gsnedders> (obviously the top change isn't to do with that)
  423. # [11:24] <Hixie> fixed
  424. # [11:29] * Joins: MikeSmith (n=MikeSmit@58.157.21.205)
  425. # [11:34] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  426. # [11:35] <Hixie> othermaciej: btw i ended up using "attach" instead of "join" -- but that's not much better. do you have any better ideas for terminology for what to call it when a new client registers with a worker?
  427. # [11:35] * Quits: jruderman (n=jruderma@c-67-180-39-55.hsd1.ca.comcast.net)
  428. # [11:35] <Hixie> http://www.whatwg.org/specs/web-workers/current-work/ is mostly ready now, though it's missing some of the APIs it should have
  429. # [11:35] <Hixie> like database APIs
  430. # [11:47] * Joins: hdh0 (n=hdh@58.187.60.86)
  431. # [12:00] * Quits: hdh (n=hdh@118.71.121.99) (Read error: 110 (Connection timed out))
  432. # [12:01] <MikeSmith> Hixie: fwiw, "attach" doesn't seem so bad to me.
  433. # [12:01] <MikeSmith> since it's used in other ways to describe interactions with processes
  434. # [12:02] <Hixie> attaching to a thread somewhat implies a debugger actually monitoring the thread
  435. # [12:02] <MikeSmith> ah
  436. # [12:02] <Hixie> which is not what this is
  437. # [12:02] <MikeSmith> right, I see
  438. # [12:02] <Hixie> but in the absence of a better term...
  439. # [12:03] <MikeSmith> hmm, only other word I can think of is "tether", and that probably sucks more
  440. # [12:03] <Hixie> heh
  441. # [12:04] <Hixie> i used join, but joining a thread means waiting for it to complete, which isn't the same thing at all :-)
  442. # [12:04] <Hixie> so attach is a step in the right direction
  443. # [12:04] <Hixie> but merely a small step
  444. # [12:04] <Philip`> "connect"?
  445. # [12:05] <Hixie> could work
  446. # [12:06] <MikeSmith> hook, tie, bind, pin, fasten, harness
  447. # [12:06] <MikeSmith> and "hog tie"
  448. # [12:07] <Hixie> connect is winning so far
  449. # [12:08] <Philip`> "tether"
  450. # [12:09] <Philip`> "tractor beam"
  451. # [12:10] <MikeSmith> bear hug
  452. # [12:10] <gDashiva> assimilate
  453. # [12:11] * gDashiva ponders <p><label>Text <input></p>
  454. # [12:12] <othermaciej> connect is best, since what you get back is a message port
  455. # [12:12] <othermaciej> connectToNamedWorker
  456. # [12:13] <Hixie> it's still createNamedWorker() for consistency with createWorker()
  457. # [12:13] <Hixie> the name 'connect' is the event name
  458. # [12:14] <gDashiva> How about assign?
  459. # [12:14] <Hixie> unless you think it should be connectToNamedWorker() and connectToWorker(), or connectToNamedWorker() and createWorker() ?
  460. # [12:15] <Hixie> why assign?
  461. # [12:16] <gDashiva> connect makes me think of connections and pipes and such
  462. # [12:16] <Hixie> well the message ports did used to be called pipes
  463. # [12:18] <gDashiva> But that's for inter-worker communication, isn't it? Not for task-to-worker
  464. # [12:18] * Quits: jacobolus1 (n=jacobolu@pool-71-119-200-174.lsanca.dsl-w.verizon.net) (Read error: 60 (Operation timed out))
  465. # [12:22] <Hixie> i don't understand what you mean
  466. # [12:22] <Hixie> message ports are how any two things communicate
  467. # [12:22] <Hixie> whether they be in different workers, same worker, different frames, whatever
  468. # [12:25] <gDashiva> Just me being confused, then.
  469. # [12:27] <gsnedders> gDashiva: Like normal.
  470. # [12:28] <gDashiva> I should add it to my OKRs
  471. # [12:31] <Hixie> something else we could use <browserbutton> for is the ability to move a page into the background completely
  472. # [12:31] <Hixie> so e.g. you could hide google calendar and it could still be doing toast notifications of your events
  473. # [12:32] * Joins: jacobolus (n=jacobolu@pool-71-119-200-174.lsanca.dsl-w.verizon.net)
  474. # [12:37] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("Leaving")
  475. # [12:37] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  476. # [12:49] * Quits: hdh0 (n=hdh@58.187.60.86) (Remote closed the connection)
  477. # [12:54] * Joins: hdh (n=hdh@58.187.60.86)
  478. # [13:03] * Joins: aaronlev_ (n=chatzill@g230224018.adsl.alicedsl.de)
  479. # [13:10] * gsnedders wants a copy of ISO 2145
  480. # [13:11] <Hixie> which is that one>
  481. # [13:11] <Hixie> ?
  482. # [13:12] <gsnedders> Hixie: numbering of divisions and subdivisions in written documents
  483. # [13:12] <Hixie> aah
  484. # [13:12] <gsnedders> It's an entire two pages long :P
  485. # [13:12] <gsnedders> And I bet the first is just the cover page.
  486. # [13:13] <Hixie> http://www.w3.org/mid/E906BBE0-6737-4C8D-9D7F-D3ADF99BFE5D@btinternet.com -- wouldn't it make more sense to just teach peopel to read?
  487. # [13:13] <gsnedders> Wikipedia claims to give the definition, but is it "can" or must it be?
  488. # [13:14] <gsnedders> Hixie: Peh! Standards are more fun than school anyway!
  489. # [13:14] <gsnedders> </sarcasm>
  490. # [13:14] <Hixie> ok, <browserbutton> or .makeStandalone() or whatever we decide to do is what i'm working on tomorrow
  491. # [13:16] <gsnedders> Lachy: I can't really get any other syntax that doesn't become really rather complex to parse
  492. # [13:16] <gsnedders> Lachy: [URL: http://exam<em>ple</em>.com] would be complete hell to parse
  493. # [13:17] <jgraham> Hixie: Why are workers JS only? And which version of JS?
  494. # [13:18] <jgraham> I presume ECMAScript 4 still requires an out of band indicator that the file is ECMAScript4?
  495. # [13:18] <Hixie> the js folk need to realise that out of band versioning is a bad idea
  496. # [13:19] <Hixie> anyway bed time
  497. # [13:19] <gsnedders> g'nite
  498. # [13:19] <gsnedders> I'll try and have nicer generated IDs by when you awaken
  499. # [13:20] <Lachy> gsnedders, just find /\[URL:?\s([^\])]\]/
  500. # [13:20] * Quits: aaronlev (n=chatzill@e180239115.adsl.alicedsl.de) (Read error: 110 (Connection timed out))
  501. # [13:20] <jgraham> Hixie: Sure, but I still don't understand why they are, in principle, JS only
  502. # [13:20] <Lachy> then escape special characters in the result
  503. # [13:20] <gsnedders> Lachy: That's hard when you have an XML document, and I don't want therefore to be a bozo
  504. # [13:21] <jgraham> (and it seems like trying to force the hand of the ECMA people this way is bad)
  505. # [13:21] <Lachy> oh, right
  506. # [13:21] <Hixie> jgraham: they're JS only because i didn't write the bit that says how to handle the content-type headers
  507. # [13:22] <Lachy> gsnedders, but no-one is going to put markup in the middle of a URL like this. Remember, it's not random stupid people using your tool, it's spec writers who at least have basic understanding of what they're doing.
  508. # [13:22] <gsnedders> Lachy: Robustness ftw.
  509. # [13:22] <gsnedders> :P
  510. # [13:22] <Lachy> so just require that the whole [URL: ...] this is in a single text node
  511. # [13:22] <Lachy> if it's not, output it as plain text
  512. # [13:22] <gsnedders> Yeah, I could do that
  513. # [13:22] <Philip`> Preprocess the document with regular expressions
  514. # [13:23] <gsnedders> Philip`: No. :P
  515. # [13:23] <gDashiva> Use sed
  516. # [13:23] <Hixie> just make people use <a href="...">...</a>
  517. # [13:23] <Hixie> require that the ... bits be equal, to confirm that they did actually intend it
  518. # [13:23] <gsnedders> Hixie: But people are lazy!
  519. # [13:23] <Hixie> if they're not equal, then just leave it unchanged
  520. # [13:23] <gsnedders> Hixie: huh?
  521. # [13:23] <Philip`> gsnedders: Lazy people don't write specs
  522. # [13:24] <Hixie> and if they're equal, then output <a href="...">...</a>
  523. # [13:24] <gsnedders> Philip`: No, we do, just slowly :)
  524. # [13:24] <Hixie> should be pretty easy to implement!
  525. # [13:24] <Philip`> gsnedders: That just means you're insufficiently lazy
  526. # [13:24] <Lachy> Hixie, there are other links in the spec where they shouldn't be equal, so how would you distinguish between those cases?
  527. # [13:24] <gsnedders> Hixie: So what? Just require an ellipsis in one place, or what do you mena?
  528. # [13:24] <gsnedders> *mean
  529. # [13:25] * Hixie wishes lachy would fix http://www.w3.org/Bugs/Public/show_bug.cgi?id=5852 so it wasn't on his list :-)
  530. # [13:25] <gDashiva> I could picture a lazy person writing a spec because they're too lazy to implement themselves, but writing some text is okay
  531. # [13:25] * Hixie is too lazy to fix his search query
  532. # [13:25] <Hixie> Lachy, gsnedders: i was saying "do nothing" basically
  533. # [13:25] <Philip`> Lachy: If the link text is equal to the href, then you treat it as the equal case; and if it isn't, you treat it as the unequal case
  534. # [13:25] <gsnedders> Hixie: ah :P
  535. # [13:25] * Hixie just wants spec gen 1.2 :-P
  536. # [13:26] <gsnedders> :D
  537. # [13:26] <Hixie> look at all the big green thick underlines in http://whatwg.org/ww
  538. # [13:26] <Lachy> Hixie, we're trying to solve the cases where the URL is the same URL is used in both the href and link text to avoid the duplication.
  539. # [13:26] <Hixie> all of those would go away if i had 1.2!
  540. # [13:26] <Hixie> Lachy: i know, i'm just not convinced it's a problem :-)
  541. # [13:27] <Lachy> Hixie, it's just a minor problem when updating the header of the document where the Previous Version links are. When I copy and paste, I want to make it easier to avoid forgetting to change one of the links when I copy and paste
  542. # [13:27] * gsnedders hugs Hixie. It'll be all right!
  543. # [13:28] <Lachy> I also wanted an easier, markup free syntax to make that whole spec header easier to fill out and generate
  544. # [13:28] <Lachy> but gsnedders said no to that
  545. # [13:28] <Hixie> heh
  546. # [13:28] * Quits: webben (n=benh@nat/yahoo/x-e7683f44867ff003)
  547. # [13:28] <gsnedders> (because he's an asshole)
  548. # [13:28] <Lachy> gsnedders, who? me or you?
  549. # [13:28] * Hixie spends very little time on the header of his specs
  550. # [13:28] <gsnedders> Lachy: Me :P
  551. # [13:29] <Lachy> ok, good
  552. # [13:29] * gsnedders is listening to Look At Your Son Now by The F-Ups from The F-Ups
  553. # [13:29] <Lachy> maybe I could solve the problem by making a template generator where I can fill out that info in a form and have it all generated for me
  554. # [13:29] <gsnedders> I love how we're writing code so we can _then_ be lazy.
  555. # [13:30] <gsnedders> It'd probably be quicker to just not be lazy in the first place.
  556. # [13:30] <Philip`> Lachy: You could do it all with XSLT
  557. # [13:30] <Lachy> Hixie, re bug 5852, I suppose I could work on it. Any suggestions for how to mark it up and present it in a user friendly way?
  558. # [13:30] <Lachy> Philip`, I'd rather not do anything with XSLT
  559. # [13:30] * Quits: jacobolus (n=jacobolu@pool-71-119-200-174.lsanca.dsl-w.verizon.net) (Read error: 110 (Connection timed out))
  560. # [13:31] <Hixie> Lachy: no idea
  561. # [13:31] <Hixie> Lachy: i generate the table automatically though
  562. # [13:31] <Hixie> Lachy: so something that does the same is probably best :-)
  563. # [13:31] <Hixie> anyway
  564. # [13:31] <Lachy> Hixie, I know. I already got the script to do that from you
  565. # [13:31] <Hixie> bed time now
  566. # [13:31] <Hixie> nn
  567. # [13:32] <Philip`> You should make the table user friendlier by deleting most of it
  568. # [13:32] <Philip`> (The full table just has too much data for anyone to ever make sense of)
  569. # [13:33] <Philip`> Approximately nobody uses MathML entities, so just get rid of them and tell people to use &#n; instead
  570. # [13:33] <Philip`> (*get rid of them in the author-oriented version of the table, even if they're still supported by UAs)
  571. # [13:33] <gsnedders> I thought we only needed to address 80% of use-cases, so why do we need them at all?
  572. # [13:34] * Joins: richardigel (n=chatzill@p4FD53940.dip0.t-ipconnect.de)
  573. # [13:34] <richardigel> hello! how good is the web forms 2.0 support of current browsers?
  574. # [13:35] <Philip`> richardigel: http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML_5)#Web_Forms_2.0 might be relevant and might be roughly correct
  575. # [13:38] <richardigel> Philip`: hmm. pretty much nothing is implemented.
  576. # [13:38] <jgraham> MathML entities are very useful if you are trying to enter maths
  577. # [13:39] <gsnedders> LaTeX ftw.
  578. # [13:40] <Philip`> jgraham: Why not just copy-and-paste the Unicode symbols directly?
  579. # [13:40] <jgraham> Philip`: For the same reason that's inconvenient when when entering LaTeX
  580. # [13:41] <Philip`> jgraham: It's inconvenient when entering LaTeX because LaTeX doesn't support Unicode properly, whereas HTML and HTML editors do
  581. # [13:42] <jgraham> \Phi is easier than finding gnome character map, typing ctrl+f (or whatever it is) entering capital phi copying the result switching back to the editor and pasting
  582. # [13:42] <jgraham> the unicode support of LaTeX has very little to do with it
  583. # [13:44] <Philip`> \Phi is not much easier than finding the place where you used Φ on the previous line of equation or a few paragraphs earlier and then copying-and-pasting it
  584. # [13:47] <Lachy> Omitting entity refs just because they're silly isn't an option. The intention is to cover everything that authors would ever need to know about HTML5, including all useless features
  585. # [13:47] <jgraham> Philip`: It really is
  586. # [13:48] <gsnedders> Philip`: You're just a silly comp.sci. student. Anyone who does real maths knows it is easier.
  587. # [13:48] <jgraham> Having to scan back through stuff breaks your concentration on what you're actually trying to do
  588. # [13:48] <gsnedders> (and that'll probably be my only comment today with my physics hat on)
  589. # [13:48] <jgraham> Which (in the case of Latex) is try not to end up with the wrong number of \lefts compared to your \rights
  590. # [13:49] <Lachy> This is really nice, but I don't want to just copy it http://www.digitalmediaminute.com/reference/entity/index.php
  591. # [13:49] <Philip`> Lachy: That seems a worse intention than trying to make something that is as useful as possible to authors (and hence has to be as easy to read as possible)
  592. # [13:50] * Joins: svl (n=me@203.161.98.118.static.amnet.net.au)
  593. # [13:50] <Lachy> Philip`, making it as thorough as possible and being useful and easy to read aren't mutually exclusive goals
  594. # [13:51] <Philip`> The HTML 5 spec already has everything authors could ever need to know, and is unreadable to authors because of it
  595. # [13:52] * Quits: harig (n=harig_in@122.160.12.230) (Read error: 110 (Connection timed out))
  596. # [13:52] * Philip` often uses the HTML 4 spec when trying to look up how some element works
  597. # [13:53] <Philip`> Lachy: But they are not absolutely compatible goals, so you'll have to make some tradeoffs between them
  598. # [13:53] <Lachy> the HTML5 spec is not very readable by authors because it's targetted at implementers
  599. # [13:54] <Philip`> Look at e.g. the <img alt> definition - that's targetted at authors, with lots of examples and stuff, and it covers everything in excruciating detail, and so no author is going to bother reading it all and if they do then they're not going to understand it all properly
  600. # [14:05] * Joins: hdh0 (n=hdh@118.71.123.5)
  601. # [14:11] * Joins: webben (n=benh@nat/yahoo/x-2061d46e48cfac86)
  602. # [14:11] * Joins: hasather (n=davidh@pat-tdc.opera.com)
  603. # [14:13] <gsnedders> Hmm, anyone got a clue why re.compile(u"[\U0001FFFF-\U0002FFFF]") causes an exception
  604. # [14:14] <Philip`> >>> import re
  605. # [14:14] <Philip`> >>> re.compile(u"[\U0001FFFF-\U0002FFFF]")
  606. # [14:14] <Philip`> <_sre.SRE_Pattern object at 0xb7c43640>
  607. # [14:19] * Quits: hdh (n=hdh@58.187.60.86) (Read error: 110 (Connection timed out))
  608. # [14:29] <gsnedders> hmm.
  609. # [14:29] <Philip`> Maybe it causes an exception because you didn't import re? :-p
  610. # [14:30] <gsnedders> sre_constants.error: bad character range
  611. # [14:30] * Quits: aaronlev_ (n=chatzill@g230224018.adsl.alicedsl.de) (Connection timed out)
  612. # [14:32] * Quits: svl (n=me@203.161.98.118.static.amnet.net.au) (Read error: 110 (Connection timed out))
  613. # [14:32] <Philip`> What version of Python?
  614. # [14:32] <Philip`> Is len(u"[\U0001FFFF-\U0002FFFF]") == 5?
  615. # [14:33] <Philip`> (Is it a UCS-2 build of Python?)
  616. # [14:33] <Philip`> etc
  617. # [14:34] <gsnedders> 2.5.1
  618. # [14:34] <gsnedders> No, it isn't. len() = 7
  619. # [14:38] <Philip`> That sounds like it's doing something silly
  620. # [14:38] * Philip` has UCS-4 Python, and len() == 5
  621. # [14:40] <gDashiva> Works in my 2.4.3, len=5
  622. # [14:51] * Joins: aaronlev_ (n=chatzill@g230224018.adsl.alicedsl.de)
  623. # [14:51] * aaronlev_ is now known as aaronlev
  624. # [14:55] <Lachy> JohnResig, I've just got a few issues to sort out with selectors api
  625. # [14:56] <Lachy> I just gotta find the link...
  626. # [14:56] <Lachy> http://lists.w3.org/Archives/Public/www-style/2008Jul/0419.html and ...
  627. # [14:57] <Lachy> http://krijnhoetmer.nl/irc-logs/whatwg/20080718#l-225
  628. # [14:58] <Lachy> basically, I need to sort out whether going with the more flexible :context/:scope was the right approach, and work out how to deal with the complaints
  629. # [14:59] <Lachy> skim the IRC logs to catch up first though
  630. # [15:01] <Lachy> the thing is, document.querySelector(":context+p", contextNode); would address all the use cases that JQuery handles, but it does require an explicit :context/:scope pseudo-class
  631. # [15:02] <Lachy> whereas, element.queryScopedSelector("+p"); which would be defined to imply :context at the beginning, and do a document wide search for all matching elements (which would be effectively limited to descendants and siblings anyway)
  632. # [15:03] <Lachy> the latter requires hacking the Selector parser in browsers, the former is easier to define and implement, but places a small burdon on authors/js libraries
  633. # [15:04] <Lachy> JohnResig, any thoughts?
  634. # [15:05] <JohnResig> Lachy: I'm reading through the log at the moment...
  635. # [15:05] <Lachy> ok
  636. # [15:05] <JohnResig> Lachy: I'm fine with the :root proposal, as well - just changing its meaning when it's within a context
  637. # [15:05] <JohnResig> taht may be easier to spec out?
  638. # [15:05] <JohnResig> *that
  639. # [15:07] <Lachy> there are problems with the :root proposal that I'm not comfortable with
  640. # [15:08] <Lachy> since it's defined to be the root of the document, and div.querySelector("body :root p") would then work, which is silly.
  641. # [15:08] <Lachy> but :context/:scope is the same as what people have asked to do with :root, just a different name.
  642. # [15:11] <Philip`> Lachy: The priority of constituencies says that spec writers and implementors should be burdened instead of authors, so that seems like an easy answer to your concern :-)
  643. # [15:11] <Lachy> hmm, if we had document.querySelector(":context+p", contextNode); then element.queryScopedSelector("+p"); could be defined to automatically imply :context and then behave as if the former had been called instead.
  644. # [15:11] <Lachy> Philip`, I know.
  645. # [15:12] <JohnResig> phew... this is a lot of logs - still reading
  646. # [15:12] <Lachy> Philip`, but I don't think adding an extra pseudo-class is that much of a problem
  647. # [15:13] <Lachy> wow, it went for over an hour :-)
  648. # [15:19] * Parts: hdh0 (n=hdh@118.71.123.5) ("Konversation terminated!")
  649. # [15:29] <JohnResig> Lachy: you keep mentioning a document.querySelector("...", contextNode) - I'm not sure where this is coming from
  650. # [15:30] <Lachy> JohnResig, it's just one of the possible solutions
  651. # [15:30] <Lachy> not specced yet
  652. # [15:31] <Lachy> it was originally mentioned as a possible alternative at the end of this email http://lists.w3.org/Archives/Public/public-webapi/2008May/0057.html
  653. # [15:31] <Lachy> and it is an alternative method to do what Hixie's proposed queryContextSelector() did.
  654. # [15:34] * Joins: svl (n=me@203.161.98.118.static.amnet.net.au)
  655. # [15:35] <Lachy> this is where it was first mentioned in the logs http://krijnhoetmer.nl/irc-logs/whatwg/20080718#l-329
  656. # [15:36] * Joins: harig (n=harig_in@122.160.12.230)
  657. # [15:40] * Quits: richardigel (n=chatzill@p4FD53940.dip0.t-ipconnect.de) (Read error: 60 (Operation timed out))
  658. # [15:44] <JohnResig> Lachy: it seems like there's two issues at play here
  659. # [15:45] <JohnResig> hmm, wait
  660. # [15:45] <Lachy> yeah, there could be a few
  661. # [15:46] * Quits: svl (n=me@203.161.98.118.static.amnet.net.au) ("And back he spurred like a madman, shrieking a curse to the sky.")
  662. # [15:47] <Lachy> the big issue is that I see both sides of the issue and I'm indecisive :-(
  663. # [16:00] * Joins: hdh (n=hdh@118.71.123.5)
  664. # [16:02] * Quits: scotfl (n=scotfl@S0106001b114f914a.ss.shawcable.net)
  665. # [16:06] * Joins: csarven (n=csarven@modemcable144.140-202-24.mc.videotron.ca)
  666. # [16:13] * Joins: smedero (n=smedero@mdp-nat251.mdp.com)
  667. # [16:15] * Quits: aaronlev (n=chatzill@g230224018.adsl.alicedsl.de) (Read error: 110 (Connection timed out))
  668. # [16:20] * Joins: billmason (n=billmaso@ip156.unival.com)
  669. # [16:32] <Philip`> Are there mail readers that handle deeply nested threads less stupidly than Thunderbird (which indents the subject line by more than the width of the column it's in, hence making it disappear entirely)?
  670. # [16:33] <Lachy> Philip`, Mail.app has a broken threading implementation that doesn't indent like Thunderbird.
  671. # [16:34] <Lachy> but it's threading is more like a list, just grouped together
  672. # [16:36] <Philip`> I have a thread with maybe two hundred messages, including big chunks that are mostly-independent forks from the main thread, and it'd be nice if those were handled sensibly instead of all being mushed together
  673. # [16:38] <Lachy> describe what you would consider sensible?
  674. # [16:38] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) (Remote closed the connection)
  675. # [16:40] <Philip`> Maybe it could let me select a certain message and say that I want it (and all its descendants) to be displayed as if they were a new thread, instead of being nested under its parent
  676. # [16:58] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
  677. # [17:06] <gsnedders> Yeah, my build must be a UCS-2 of Python
  678. # [17:08] <gsnedders> or a UTF-16 one rather
  679. # [17:08] <gsnedders> hmm
  680. # [17:09] * Joins: Lachy (n=Lachlan@85.196.122.246)
  681. # [17:26] <gsnedders> <em<b>foo creates a different result in html5lib than it does in any browser, as far as I can see
  682. # [17:29] * Quits: weinig|zZz (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  683. # [17:36] * Quits: harig (n=harig_in@122.160.12.230) (Read error: 110 (Connection timed out))
  684. # [17:39] <gsnedders> Philip`: What do you get for len(u"\U0001FFFF")?
  685. # [17:41] <Philip`> gsnedders: 1
  686. # [17:41] <gsnedders> Philip`: Yeah, it's a UTF-16 copy I have
  687. # [17:45] * Joins: richardigel (n=chatzill@p4FD53940.dip0.t-ipconnect.de)
  688. # [17:47] * Joins: myakura (n=myakura@p1216-ipbf601marunouchi.tokyo.ocn.ne.jp)
  689. # [17:51] <MikeSmith> Philip`: mutt
  690. # [18:04] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  691. # [18:07] * Joins: svl (n=me@203.161.98.118.static.amnet.net.au)
  692. # [18:13] * Joins: eseidel (n=eseidel@c-67-176-133-229.hsd1.il.comcast.net)
  693. # [18:13] * Quits: svl (n=me@203.161.98.118.static.amnet.net.au) ("And back he spurred like a madman, shrieking a curse to the sky.")
  694. # [18:29] * Joins: eseidel_ (n=eseidel@72.14.228.1)
  695. # [18:34] * Quits: virtuelv (n=virtuelv@192.80-203-77.nextgentel.com) (Read error: 110 (Connection timed out))
  696. # [18:41] * Joins: john_fallows (n=j_r_fall@ip-12-22-56-126.hqglobal.net)
  697. # [18:42] * Joins: john_r_fallows (n=j_r_fall@ip-12-22-56-126.hqglobal.net)
  698. # [18:42] * Quits: john_r_fallows (n=j_r_fall@ip-12-22-56-126.hqglobal.net) (Client Quit)
  699. # [18:42] * Quits: john_fallows (n=j_r_fall@ip-12-22-56-126.hqglobal.net) (Client Quit)
  700. # [18:42] * Joins: john_fallows (n=j_r_fall@ip-12-22-56-126.hqglobal.net)
  701. # [18:42] * Joins: john_r_fallows (n=j_r_fall@ip-12-22-56-126.hqglobal.net)
  702. # [18:42] * Quits: john_fallows (n=j_r_fall@ip-12-22-56-126.hqglobal.net) (Client Quit)
  703. # [18:47] * Quits: eseidel (n=eseidel@c-67-176-133-229.hsd1.il.comcast.net) (Read error: 110 (Connection timed out))
  704. # [18:54] * Joins: maikmerten (n=maikmert@La746.l.pppool.de)
  705. # [18:59] * Quits: webben (n=benh@nat/yahoo/x-2061d46e48cfac86) (Read error: 110 (Connection timed out))
  706. # [19:03] * Quits: richardigel (n=chatzill@p4FD53940.dip0.t-ipconnect.de) (Read error: 113 (No route to host))
  707. # [19:04] * Quits: john_r_fallows (n=j_r_fall@ip-12-22-56-126.hqglobal.net) (Read error: 110 (Connection timed out))
  708. # [19:08] * Joins: john_fallows (n=j_r_fall@ip-12-22-56-126.hqglobal.net)
  709. # [19:10] * Quits: john_fallows (n=j_r_fall@ip-12-22-56-126.hqglobal.net) (Remote closed the connection)
  710. # [19:16] * Joins: virtuelv (n=virtuelv@192.80-203-77.nextgentel.com)
  711. # [19:17] * Joins: john_fallows (n=j_r_fall@ip-12-22-56-126.hqglobal.net)
  712. # [19:17] * Joins: KevinMarks (n=KevinMar@nat/google/x-7ec9b3a635949dc7)
  713. # [19:22] * Quits: sverrej (n=sverrej@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  714. # [20:30] <gsnedders> Does anyone care enough about the postprocessor's stupid ID generation enough to want me to copy it?
  715. # [20:30] <gsnedders> (in w3c-compat, at least)
  716. # [20:41] <Dashiva> If you care enough to make a compat mode, it should be compatible
  717. # [20:44] * Joins: sverrej (n=sverrej@89.10.27.86)
  718. # [20:50] * Quits: virtuelv (n=virtuelv@192.80-203-77.nextgentel.com) ("Ex-Chat")
  719. # [20:52] <gsnedders> Dashiva: It never will be completely compatible, because what I do is too logical.
  720. # [20:52] <gsnedders> Dashiva: It just needs to be compatible enough in the real world
  721. # [20:52] <gsnedders> And as with the postprocessor the IDs change half the time because the ID gen is so bad…
  722. # [21:01] <gsnedders> /text()[contains(normalize-space(translate(., 'AEILNORSTV', 'aeilnorstv')), 'latest version') or contains(., 'http://www.w3.org/TR/')] — lovely xpath!
  723. # [21:06] <Dashiva> Isn't there a lower()?
  724. # [21:07] <gsnedders> Nope.
  725. # [21:07] <gsnedders> In XPath 2.0 there is lower-case, but next to nothing actually implements 2.0
  726. # [21:07] <Dashiva> How wonderful
  727. # [21:07] <gsnedders> Yeah, it really is.
  728. # [21:08] <gsnedders> But when dealing with something as large as HTML 5, it tends to be quicker if you can get away with a single XPath statement than doing a whole iter of the tree
  729. # [21:08] <gsnedders> Especially when looking at text nodes
  730. # [21:09] <Dashiva> Gee. No case changing, but they have starts-with, substring-before and substring-after
  731. # [21:09] <jcranmer> XPath is so wonderful, it's a shame that more people don't implement more of it
  732. # [21:10] <jcranmer> although the spec could be made a little easier to digest for people trying to use it
  733. # [21:10] <gsnedders> Yeah, the spec is rather horrible
  734. # [21:11] <gsnedders> You have to be careful how much you use it when performance matters though
  735. # [21:11] <jcranmer> it's more useful (IMHO) than SAX or DOM when you're trying to scrape information from something with varying structure
  736. # [21:12] <gsnedders> Easier? I'd say so. Useful? No more so.
  737. # [21:13] <Dashiva> More convenient, but not really easier than DOM
  738. # [21:13] <jcranmer> Dashiva: what if you have something that can either be a dl, ul, ol, or table?
  739. # [21:14] <Dashiva> That's the convenient part
  740. # [21:14] <jcranmer> or, to be more precise, a specific row or item of any of those
  741. # [21:14] <Dashiva> tableref.rows[i].cols[j]
  742. # [21:14] <Dashiva> *cells
  743. # [21:14] <jcranmer> yes, but I have to store whether or not I'm querying the list or table
  744. # [21:15] <Dashiva> Yes, we already agreed it's more convenient with xpath
  745. # [21:16] <Dashiva> But the basic DOM functions are lot easier to learn than all the xpath incantations
  746. # [21:16] <jcranmer> I have to use a reference either way, but I guess I don't do enough HTML/XML-based development to matter
  747. # [21:17] <gsnedders> http://hg.gsnedders.com/spec-gen/file/tip/specGen/processes/sub.py#l101 — yay :\
  748. # [21:17] <gsnedders> I'm probably better at dealing with XPath, but mainly because I don't use the DOM much at all
  749. # [21:22] * Quits: maikmerten (n=maikmert@La746.l.pppool.de) (Remote closed the connection)
  750. # [21:30] <gsnedders> WTH is the point of <!--status-->?
  751. # [21:31] <gsnedders> It only outputs anything apart from "[Sorry, the postprocessor doesn't yet have the boilerplate text for this status]" when the status is ED.
  752. # [21:31] <gsnedders> Lachy, Hixie?
  753. # [21:31] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
  754. # [21:36] <Lachy> gsnedders
  755. # [21:36] <gsnedders> Yes, that's me
  756. # [21:36] <Lachy> you called?
  757. # [21:36] <gsnedders> See the above question
  758. # [21:37] <Lachy> hmm, let me see...
  759. # [21:37] <takkaria> Philip`: how did you go about obtaining your corpus of dmoz data? did you write a script to download the files, and if so, any chance I could have it? (for performance benchmarking reasons)
  760. # [21:40] <gsnedders> It seems to be the same thing in every status apart from ED de-facto anyway
  761. # [21:41] <gsnedders> I dunno if MOs are the same, as I can't see any, though
  762. # [21:42] <Lachy> gsnedders, I get "This is a public copy of the editors' draft. It is provided for discussion only and may change at any moment. It probably contains errors. Its publication here does not imply endorsement of its contents by W3C"
  763. # [21:42] <gsnedders> Lachy: Yeah, that's what I get. It's just that no other status gives anything (apart from the note that there is no boilerplate text)
  764. # [21:43] <Lachy> oh, ok. let me try other ones...
  765. # [21:43] * gsnedders has already tried them all
  766. # [21:43] <Lachy> ok
  767. # [21:44] <gsnedders> Lachy: What use is it when it doesn't give anything normally?
  768. # [21:44] <gsnedders> That's what I want to know.
  769. # [21:44] <Lachy> it's probably because other statuses need custom status text
  770. # [21:44] <gsnedders> They don't. They all always have the same.
  771. # [21:44] <gsnedders> This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
  772. # [21:47] * Quits: eseidel_ (n=eseidel@72.14.228.1)
  773. # [21:47] <smedero> for whatever reason the geo api spec differs, but not by much....
  774. # [21:47] <smedero> "This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the most recently formally published revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/."
  775. # [21:48] <smedero> "recently formally published"
  776. # [21:48] <smedero> http://dev.w3.org/geo/api/spec-source.html
  777. # [21:48] <gsnedders> Ahah!
  778. # [21:49] <gsnedders> You get status text if you set the WG to "CSS WG"
  779. # [21:49] * Parts: hdh (n=hdh@118.71.123.5) ("Konversation terminated!")
  780. # [21:49] * gsnedders refuses to copy that
  781. # [21:50] <gsnedders> I am _NOT_ adding WG specific stuff.
  782. # [21:51] <Lachy> gsnedders, have you checked the pubrules document to find out the requirements?
  783. # [21:56] <gsnedders> Lachy: It changes for almost every status, and I don't want to do any more than the postprocessor does here. I'm not adding any W3C specific stuff without good reason
  784. # [22:00] <Lachy> gsnedders, if it's boiler plate text that is standard for each status level, then it should be included to make it easier for spec writers
  785. # [22:00] <gsnedders> Lachy: But it's non-backwards-compatible
  786. # [22:00] <Lachy> what do you mean?
  787. # [22:01] <gsnedders> Lachy: Documents designed for the postprocessor have it in them themselves
  788. # [22:01] <Lachy> so? Documents designed for the post processor also typically omit <!--status-->, and if that isn't there, then don't include it.
  789. # [22:02] <gsnedders> Lachy: it ought to be compatible in the compat. mode, within reason, so I can't do that.
  790. # [22:03] <Lachy> sure you can.
  791. # [22:03] <Lachy> I don't see how updating a feature that wasn't properly implemented in the old processor will break anything.
  792. # [22:23] <Philip`> takkaria: I just downloaded dmoz's RDF site listing, used Perl regexps to extract the URLs and to s/&amp;/&/ etc, then passed it through 'sort' and 'uniq', and then 'sort -R' to randomise it, and then took the first n from that list
  793. # [22:24] <Philip`> takkaria: and then used a Java program to download and analyse the pages (using HttpClient, and around a hundred simultaneous threads)
  794. # [22:25] <Philip`> takkaria: and the Java program cached the downloaded headers/content to disk so it wouldn't have to download them when I ran it a second time
  795. # [22:26] <Philip`> takkaria: I could upload the Java thing somewhere, but it's big and ugly, and if you just want a collection of page bodies then it'd probably be easier to just pass the page list into wget or curl
  796. # [22:27] * Philip` goes away for a bit
  797. # [22:28] <Philip`> (Oh, I also limited the downloads to something like 256K per page, because there was at least one infinitely long radio stream and I didn't want all of it)
  798. # [22:28] <Philip`> *256KB
  799. # [22:28] <smedero> heh
  800. # [22:35] * gsnedders implements something he really doesn't want to
  801. # [22:38] * Quits: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net) (Read error: 54 (Connection reset by peer))
  802. # [22:38] * Joins: othermaciej (n=mjs@c-24-5-43-151.hsd1.ca.comcast.net)
  803. # [22:40] <gsnedders> http://hg.gsnedders.com/spec-gen/rev/f10347e98d3c
  804. # [22:43] <gsnedders> time to upload a few files from the latest spec-gen
  805. # [22:45] <gsnedders> http://stuff.gsnedders.com/spec-gen/ — find bugs in those files, plz.
  806. # [22:47] <takkaria> Philip`: ah, thanks. I'll just grab the RDF and curl it
  807. # [22:49] * gsnedders is tempted to add a --w3c-compat-crazy-subsitutions option
  808. # [22:51] <Lachy> gsnedders, for which features?
  809. # [22:51] <gsnedders> Lachy: rewriting http://www.w3.org/StyleSheets/TR/W3C-(MO|ED|WD|CR|PR|REC|PER|NOTE|RSCND|Member-SUBM)
  810. # [22:54] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  811. # [22:57] <MikeSmith> gsnedders: fwiw, I don't like the automated ID generation
  812. # [22:57] <MikeSmith> I don't like the fact that the IDs can change
  813. # [22:58] <gsnedders> MikeSmith: in the existing postprocessor?
  814. # [22:58] <MikeSmith> I mean in general
  815. # [22:58] <MikeSmith> It doesn't seem like much of hardship to me for editors to manually maintain IDs
  816. # [23:00] <gsnedders> MikeSmith: ah
  817. # [23:01] <MikeSmith> having stable IDs is a much more valuable feature in a spec
  818. # [23:01] <MikeSmith> the ID-generation feature is the wrong kind of optimization
  819. # [23:02] <takkaria> I guess that isssue only shows up when the spec is going to take a long time to finish and is being written in public
  820. # [23:02] <MikeSmith> of marginal and questionable value to editors, of zero value to readers and other consumers of the doc
  821. # [23:03] <MikeSmith> takkaria: true
  822. # [23:04] * Joins: weinig (n=weinig@nat/apple/x-723ebf9f9031b50c)
  823. # [23:05] <Hixie> i don't want the ids in the source document if i can help it, but i'm certainly in agreement in principle and would love to see the generator keep state or something to not change IDs
  824. # [23:06] <Hixie> generally if you use the title="" attribute to generate the IDs you should be fine i think
  825. # [23:07] <gsnedders> (which the postprocessor doesn't)
  826. # [23:07] <Hixie> i don't mind if the IDs change as a one time thing when we're switching generators
  827. # [23:08] <Hixie> if that means more stability going forward
  828. # [23:10] <gsnedders> Yeah, the way I generate IDs should be far more stable
  829. # [23:10] <Hixie> how do you do it?
  830. # [23:11] * Joins: jruderman (n=jruderma@c-67-180-39-55.hsd1.ca.comcast.net)
  831. # [23:12] <gsnedders> from @title or the textContent, lowercase it, strip leading/trailing whitespace, replace internal whitespace with -
  832. # [23:13] <gsnedders> (the postprocessor does all kinds of crazy stuff, but basically stops after it gets to the first space after taking five characters)
  833. # [23:13] <gsnedders> and a longer ID should make it more stable
  834. # [23:14] <Hixie> cool
  835. # [23:22] * gsnedders never knew ID gen could be cool
  836. # [23:22] <Hixie> i'm not a good benchmark for determining objective coolness.
  837. # [23:24] <Philip`> I hate the crunching noise made by interaction of shoe and snail
  838. # [23:25] <Philip`> If you can create a file mapping from old IDs to new IDs, it could be added into the multipage spec's magical redirection thingy so that old links get redirected to the right place
  839. # [23:26] <Hixie> good idea
  840. # [23:26] <takkaria> Hixie: oh, btw, any chance of getting the tokeniser states upgraded to TOC-visible headers? would make linking to states easier
  841. # [23:29] * Joins: kangax (n=kangax@209.10.106.40)
  842. # [23:29] <Hixie> file a bug
  843. # [23:29] <takkaria> k
  844. # [23:29] <Hixie> or send e-mail if it's not urgent
  845. # [23:29] <Hixie> either way
  846. # [23:31] <kangax> html tidy complains that canvas tag is not recognized
  847. # [23:32] <kangax> interesting...
  848. # [23:33] <Philip`> kangax: I expect it only understands elements from HTML4, so it won't include any HTML5 ones like <canvas>
  849. # [23:33] <kangax> that makes sense
  850. # [23:36] * Quits: kangax (n=kangax@209.10.106.40) ("http://scripteka.com - all prototype extensions at your fingertips")
  851. # Session Close: Sat Jul 19 00:00:00 2008

The end :)