/irc-logs / freenode / #whatwg / 2008-05-28 / end

Options:

  1. # Session Start: Wed May 28 00:00:00 2008
  2. # Session Ident: #whatwg
  3. # [00:03] <annevk> Lachy, you want http://www.flickr.com/photos/f8dy/347023948/
  4. # [00:03] * Joins: virtuelv (n=virtuelv@46.80-203-100.nextgentel.com)
  5. # [00:07] <Lachy> ah, right. I think I saw a better one of those last week
  6. # [00:08] * Quits: othermaciej (n=mjs@17.255.103.110) (Read error: 104 (Connection reset by peer))
  7. # [00:09] <hober> takkaria: my linguist wife said, re: the link that terrifies you, "uugggggggh. this guy needs to go back to Lojban land."
  8. # [00:09] <Lachy> wtf? I don't get this one. http://www.flickr.com/photos/jotape_es/384293705/in/pool-htmljokes
  9. # [00:10] <takkaria> hober: heh
  10. # [00:11] <takkaria> Lachy: http://en.wikipedia.org/wiki/Font_(disambiguation)
  11. # [00:11] * Joins: othermaciej (n=mjs@17.255.103.110)
  12. # [00:11] <annevk> a whole new WG just for geolocation?
  13. # [00:12] <Lachy> takkaria, oh, so it's old word for fountain
  14. # [00:12] <Lachy> which still doesn't make that much sense, since I would call that a bubbler
  15. # [00:12] <annevk> imagine if we needed separate WGs for HTML syntax, SQL storage, persistent storage, offline/online events, offline application cache, sandboxing, "origin", etc.
  16. # [00:12] * Philip` has never heard the term "bubbler" for fountains before
  17. # [00:13] <Lachy> http://en.wikipedia.org/wiki/Bubbler
  18. # [00:13] * Joins: weinig (n=weinig@17.255.107.120)
  19. # [00:13] <Philip`> (Actually, I'm not sure I've heard the term "bubbler" ever used seriously for anything)
  20. # [00:13] <Philip`> Crazy foreigners :-p
  21. # [00:14] <hober> Philip`: heh. /me speaks en_US-x-boston
  22. # [00:20] * Quits: phsiao (n=shawn@nat/ibm/x-f081baef9c8d58ad)
  23. # [00:22] <Philip`> Is it intentional that I get 13 errors when running the html5lib tests?
  24. # [00:23] <Dashiva> Hixie isn't shiny enough, he doesn't reflect the WG
  25. # [00:25] <takkaria> let's replace him with an inanimate piece of shiny silver
  26. # [00:26] <Hixie> i can tell i'm going to have fun when i read today's htmlwg mail
  27. # [00:26] <Dashiva> No, just the one by RB, Hixie :)
  28. # [00:26] <Dashiva> Then again, that one mail is plenty
  29. # [00:27] <Dashiva> Well, there's also the different accessibility guys contradicting each other left and right, but that's nothing new
  30. # [00:27] * Joins: csarven (n=csarven@modemcable130.251-202-24.mc.videotron.ca)
  31. # [00:28] <takkaria> and MMM's latest post is amusing
  32. # [00:28] * Quits: virtuelv (n=virtuelv@46.80-203-100.nextgentel.com) (Remote closed the connection)
  33. # [00:29] <Dashiva> "Do you expect UAs to implement acutal useful features? This is an outrage!"
  34. # [00:29] <Dashiva> (Not part of today's mail)
  35. # [00:29] <annevk> Hixie, do you know if sicking is just replying to the AC questions one by one?
  36. # [00:30] <annevk> Hixie, he had objections to all three, but he's only starting a new thread on one
  37. # [00:30] <Hixie> no idea
  38. # [00:30] <annevk> sigh
  39. # [00:30] <Hixie> i propose you ignore feedback that has had no reasoning
  40. # [00:30] <Hixie> and say so
  41. # [00:31] <Philip`> (Hmm, my html5lib now parses the spec (and discards the output) 15% faster than before, and doesn't fail any tests that it didn't fail yesterday)
  42. # [00:31] <annevk> sure, i just don't want to get bits and piece feedback for the next few weeks
  43. # [00:32] <annevk> Mozilla has surprisingly similar stalling tactics to Microsoft, though I guess it's not intentional
  44. # [00:32] <Dashiva> Maybe MS should file a patent
  45. # [00:32] <annevk> Actually, I know it's not intentional (at least until now), sorry about that
  46. # [00:33] <Philip`> Nobody apologises when accusing Microsoft of anything :-p
  47. # [00:35] <Dashiva> Philip`: Well, there's enough reasonable accusations to make that there's seldom a need to make unreasonable ones ;)
  48. # [00:36] <annevk> It's kind of frustrating though. sicking says he'll give feedback the same day. Then waits three days and provides only a third of what he promised.
  49. # [00:37] <gavin_> have you asked him about it?
  50. # [00:38] <annevk> Hixie did
  51. # [00:40] * Quits: weinig (n=weinig@17.255.107.120)
  52. # [00:42] * Quits: qwert666 (n=qwert666@acbk42.neoplus.adsl.tpnet.pl) ("Leaving")
  53. # [00:49] * Joins: weinig (n=weinig@17.255.107.120)
  54. # [00:52] * Joins: gsnedders (n=gsnedder@host217-44-35-200.range217-44.btcentralplus.com)
  55. # [00:56] <Lachy> What picture should I use to represent software like html5lib and validator.nu?
  56. # [00:58] * Quits: heycam (n=cam@124-168-33-67.dyn.iinet.net.au) ("bye")
  57. # [00:59] <Lachy> are there any other software projects I should mention besides those two?
  58. # [00:59] <gsnedders> Don't _ever_ forget to install Boot Camp 2.1 before upgrading to XP SP3 on Apple hardware.
  59. # [00:59] * gsnedders has just spent hours digging himself out of that hole
  60. # [01:00] <Dashiva> Lachy: The test case projects?
  61. # [01:01] <Lachy> Dashiva, stuff that's relevant to develpers
  62. # [01:01] <Lachy> test cases are only relevant to implementers
  63. # [01:01] * Quits: weinig (n=weinig@17.255.107.120)
  64. # [01:02] <gsnedders> Lachy: I'm not relevant to developers :P
  65. # [01:02] <Dashiva> I suppose most of the other language implementations are personal projects
  66. # [01:02] <Lachy> gsnedders, your photo is the main attraction ;-)
  67. # [01:03] <gsnedders> Lachy: :D
  68. # [01:03] <takkaria> Lachy: if you want html5lib as a library, then maybe a library...
  69. # [01:03] <takkaria> if you mean html5lib as a suite of tools, I dunno
  70. # [01:03] <Lachy> I'd prefer something that represents it as a development tool
  71. # [01:04] <Dashiva> A toolbox is a bit cliche :)
  72. # [01:04] <takkaria> bricks and mortar are a traditional kind of development tool icon
  73. # [01:04] <takkaria> at least where I come from
  74. # [01:04] * Quits: Windstoss_ (n=wind@mnhm-4d01bfae.pool.mediaWays.net) ("*plonk*")
  75. # [01:04] <Hixie> lachy: http://www.buytikitorches.com/images/funnel-copper_1.jpg
  76. # [01:04] <Hixie> with random garbage pouring in the top
  77. # [01:04] <Hixie> and tiny beautiful trees coming out of the bottom
  78. # [01:04] * Joins: weinig (n=weinig@17.255.107.120)
  79. # [01:05] <Lachy> Hixie, assume I don't have the time or skills to make such modifications
  80. # [01:05] <Philip`> http://www.accessibility.nl/files/images/tag-soup2-035.jpg
  81. # [01:05] <Dashiva> accessibility isn't a tag!
  82. # [01:06] <Dashiva> "Waiter, there're buzzwords in my tag soup"
  83. # [01:06] <Lachy> hah :-D
  84. # [01:06] <Philip`> When's Google going to make image search that actually works, and shows me tag soup instead of American 'football' players with tins of CHUNKY Savory Pot Roast and suchlike?
  85. # [01:07] <Hixie> Dashiva: i'm sure there are pages with <accessibility> tags!
  86. # [01:07] <Dashiva> <accessibility><html>...</html></accessibility> solves everything
  87. # [01:07] <takkaria> no, making alt mandatory solves everything
  88. # [01:08] <Hixie> dashiva: though ironically, and possible presciently, it gets parsed as <html><accessibility>...</accessibility></html> :-)
  89. # [01:09] <Dashiva> I did have fun at one time with <invisible>
  90. # [01:09] <Lachy> Dashiva, you forgot the level="AAA" attribugte
  91. # [01:09] <Lachy> *attribute
  92. # [01:09] <Lachy> maybe this http://en.wikipedia.org/wiki/Image:HTML.svg
  93. # [01:09] <Lachy> if I edit it to use an HTML5 DOCTYPE
  94. # [01:10] <Dashiva> You put <invisible>The content of this page is hidden to protect the author's rights.</invisible> followed by 100 newlines at the top of the document
  95. # [01:10] <Hixie> heh
  96. # [01:11] <Philip`> http://www.newtacoma.com/ has some <hidden input="...">, which is peculiar
  97. # [01:11] * Quits: weinig (n=weinig@17.255.107.120)
  98. # [01:11] <Philip`> Looks like a failed SEO attempt
  99. # [01:11] * Parts: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
  100. # [01:15] <Hixie> i still haven't finished dealing with e-mail
  101. # [01:15] <Hixie> sheesh
  102. # [01:15] <Hixie> today is an especially bad day for e-mail
  103. # [01:17] <Dashiva> There was one mail where someone claimed to read all the public-html mail, and also claimed there had never been a mail from you about @alt alternatives
  104. # [01:17] <Hixie> i saw that
  105. # [01:17] <Hixie> that was funny
  106. # [01:17] <Dashiva> I wonder if anyone's going to call him out on that
  107. # [01:17] * takkaria notes hixie now has a zzz folder as well as an aaa-productivity folder :)
  108. # [01:18] <takkaria> I was going to, but I couldn't find the post that wasn't made
  109. # [01:19] * Joins: weinig (n=weinig@17.255.107.120)
  110. # [01:19] <Hixie> i've had zzz for a while, though until recently it only had notes from myself to myself in there (which don't appear on the issues list)
  111. # [01:19] * Quits: smedero (n=smedero@mdp-nat251.mdp.com)
  112. # [01:19] <Hixie> zzz is for things that i don't want to deal with until after we're in CR
  113. # [01:19] <Hixie> or at least near going to CR
  114. # [01:19] * Quits: weinig (n=weinig@17.255.107.120) (Client Quit)
  115. # [01:19] <Dashiva> takkaria: This one? http://lists.w3.org/Archives/Public/public-html/2008May/0073.html
  116. # [01:19] * Philip` never noticed that part of the email, since he gave up reading it long before that point
  117. # [01:20] <takkaria> Dashiva: yeah, that one
  118. # [01:22] <Philip`> Since nobody raised any decent objections to that proposal, it is clearly perfect and should be implemented
  119. # [01:23] <webben> objections were raised in this channel (mainly along the lines of what attribute to use)
  120. # [01:23] <webben> IIRC
  121. # [01:24] <annevk> oh crap, it's 1:20
  122. # [01:24] <Philip`> webben: Ah, I'm not counting minor syntax details, because if I did count them then my statement would be proved false
  123. # [01:24] * annevk blames HTML5
  124. # [01:24] <webben> using some other attribute to square the circle does seem to meet most of the raised concerns
  125. # [01:24] <Dashiva> At some point, we'll have to get a shed just tok keep all our bikesheds in
  126. # [01:24] <Hixie> HTML5 takes the blame for time advancing
  127. # [01:24] <Hixie> anything of the size of HTML5 is bound to have effects on the time space continuum
  128. # [01:25] <webben> Well, it does include a TIME element, doesn't it? ;)
  129. # [01:25] <annevk> in this case it was more having to deal with comments from shepers because of fear of the html5 dependency
  130. # [01:25] <annevk> and how it would badly affect vendors
  131. # [01:25] <Hixie> you'd think he'd let the vendors raise their own concerns
  132. # [01:25] <annevk> apparently he doesn't trust me when i say that vendors have requested that so i actually had to dig up an e-mail from maciej
  133. # [01:26] <Dashiva> The vendors need to start using that backroom channel nobody gets to see :)
  134. # [01:26] <annevk> would be nice if he read the thread about it first before starting a new one on the same subject
  135. # [01:27] <Philip`> Dashiva: We'd have to teach them the secret handshake first
  136. # [01:27] * Joins: othermaciej_ (n=mjs@17.255.103.110)
  137. # [01:27] <annevk> Dashiva, moving everything to a less bureaucratic forum would be fine with me, but WHATWG doesn't have a PP yet
  138. # [01:27] * Quits: othermaciej (n=mjs@17.255.103.110) (Connection reset by peer)
  139. # [01:28] <takkaria> Philip`: hmm, somehow lolzapolooza doesn't work when typed...
  140. # [01:28] <Hixie> yeah we really need a patent policy
  141. # [01:28] <takkaria> uh, that backfired
  142. # [01:28] <Hixie> annevk: get your lawyer people to write down what they would want a patent policy to cover, and mail it to me
  143. # [01:28] <annevk> PP involves lawyers, that's scary
  144. # [01:29] <Hixie> opera's lawyers aren't too bad
  145. # [01:30] <Dashiva> It was a bit disconcerting to get an office in the middle of legal. Suddenly there are suits all around you
  146. # [01:30] <Dashiva> Go one floor up, and it's shorts and t-shirts
  147. # [01:32] <Philip`> Several people where I work don't even wear socks or shoes, which doesn't seem a great idea to me given the stuff I know I've dropped on the floor
  148. # [01:33] <annevk> maybe you should tell them :)
  149. # [01:34] * aroben is now known as aroben|meeting
  150. # [01:36] * Joins: weinig (n=weinig@nat/apple/x-a14452b139301dbf)
  151. # [01:36] <annevk> (that was in reply to Philip`, not Hixie, fwiw)
  152. # [01:37] * annevk tries to be extra careful now he mentioned lawyers
  153. # [01:39] <roc> dbaron: did you make any progress on the spurious menu command firing bug?
  154. # [01:40] <dbaron> roc, no... but did you mean to ask that in #developers ?
  155. # [01:40] <roc> yes I did!
  156. # [01:41] <MikeSmith> lastlog mike
  157. # [01:41] <MikeSmith> oops
  158. # [01:41] <MikeSmith> heh
  159. # [01:42] <MikeSmith> "<Lachy> though I still have to fit the drunk MikeSmith photo in somewhere too"
  160. # [01:42] <Dashiva> Checking if we talk behind your back? :)
  161. # [01:43] <annevk> hehe, we could use that as a gimmick
  162. # [01:43] <annevk> "works on your mobile: <picture>"
  163. # [01:43] <MikeSmith> Dashiva: making my IRC client show me if anybody was trying to ping me while I was asleep..
  164. # [01:46] * Joins: KevinMarks (n=KevinMar@72-254-41-214.client.stsn.net)
  165. # [01:47] * Joins: psa (n=yomode@71.93.19.66)
  166. # [01:49] <Hixie> annevk: btw, i could live with the hardcoded client-side limitation on the path component containing "..\"
  167. # [01:49] <takkaria>
  168. # [01:50] <takkaria> I accidentally send \0s to IRC far too often, I wonder if I can make my client stop me
  169. # [01:51] <Hixie> how??
  170. # [01:51] * Joins: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com)
  171. # [01:51] <takkaria> I'm not sure, I think I manage it by hitting the wrong button when switching tabs in irssi
  172. # [01:52] <annevk> yeah, it seemed sort of reasonable to me too, although it's amazingly ugly and i wonder if it'll ever fly
  173. # [01:52] <Hixie> why wouldn't it fly?
  174. # [01:52] <Hixie> html5 has far worth things
  175. # [01:52] <Hixie> worse
  176. # [01:52] <annevk> it may also be a slippery slope, not sure
  177. # [01:52] <Hixie> well if you find yourself going down the slope, just say no and remove it
  178. # [01:53] <annevk> i'd like to hear from the webkit guys if they feel this is needed
  179. # [01:53] <othermaciej_> if we feel what is needed?
  180. # [01:54] <othermaciej_> the crazy IIS workaround?
  181. # [01:54] <othermaciej_> I haven't studied it enough to know
  182. # [01:54] * othermaciej_ is now known as othermaciej
  183. # [01:54] <Hixie> yeah
  184. # [01:54] <Hixie> not much to study really
  185. # [01:54] <Dashiva> When Doug says "commercial browser vendors", who does he mean?
  186. # [01:54] <Lachy> gsnedders, first draft of your slide http://lachy.id.au/temp/gsnedders.jpg :-)
  187. # [01:54] <annevk> (another option would be to simply disable the whole feature for IIS based on the Server response header from the OPTIONS request)
  188. # [01:55] * Joins: aroben (n=aroben@c-71-58-57-150.hsd1.pa.comcast.net)
  189. # [01:55] <annevk> (but that seems worse)
  190. # [01:55] <shepazu> Dashiva: like, mobile vendors... Opera, for one :)
  191. # [01:55] <othermaciej> Dashiva: probably vendors of per-unit licensed mobile browsers
  192. # [01:55] <othermaciej> though I don't think Opera specifically objects to referencing HTML5
  193. # [01:56] <Dashiva> Yeah, I didn't see Opera objecting to that...
  194. # [01:56] <othermaciej> also I am not sure why charging a license fee is related to needing to market something, or how that relates to specification cross-references
  195. # [01:56] <annevk> I put it in the spec...
  196. # [01:56] <annevk> so far, no viable alternative has been propposed, so this is a non-issue
  197. # [02:00] <annevk> I'm also a bit confused with shepazu asking me to provide a reference for where implementors have requested that, and he, spokesman of the commercial browser vendors, has not done the same...
  198. # [02:00] * annevk -> bed
  199. # [02:01] <shepazu> annevk: it's a simple question
  200. # [02:02] <shepazu> where do your requirements come from?
  201. # [02:02] <annevk> public-webapi
  202. # [02:02] <Philip`> Hmm, Google Code does autolinking between issues and commit messages, but it doesn't seem to do clever stuff like in Trac where you can close an issue via a commit message :-(
  203. # [02:02] <Philip`> (*autolinking of references of the form "issue 123" and "r123")
  204. # [02:03] <annevk> shepazu, I hope you followed the pointers I provided and snipped in your reply
  205. # [02:04] <shepazu> annevk: of course, but it's not much of a "requirement", and doesn't refute removal from HTML5
  206. # [02:06] <Dashiva> I'm a bit surprised that there are commercial browser vendors who don't plan on implementing HTML5
  207. # [02:06] * Quits: webben (n=benh@81.168.78.157) (Read error: 110 (Connection timed out))
  208. # [02:07] <annevk> shepazu, nothing does, it's just that nobody has done that yet
  209. # [02:07] <annevk> shepazu, and because nobody has done that yet, there's no incentive to change references
  210. # [02:07] <annevk> shepazu, as the current references serve implementors best
  211. # [02:13] * Philip` discovers the 'pv' tool, which is quite neat
  212. # [02:13] <Philip`> since I can use it to e.g. feed a big HTML file to html5lib, and get a progress bar and estimated-time-to-completion and everything
  213. # [02:17] <Dashiva> If Hixie added alt="_none" as the missing value to the spec today, what would the responses be? Discuss
  214. # [02:18] <Philip`> I'd complain that it doesn't degrade gracefully
  215. # [02:18] <shepazu> alt="_blank"
  216. # [02:18] <Dashiva> Would you? Would you really revive the whole debacle when it might be over?
  217. # [02:18] <Philip`> Nobody would want their page littered with "_none" tooltips
  218. # [02:18] <Philip`> Dashiva: Yes, since I'd like to have the best possible solution :-)
  219. # [02:19] <annevk> Dashiva, the whole point of the debacle is that people have different views; if one party just gives in to the other of course it would be over...
  220. # [02:19] <annevk> anyway, should really go to bed now
  221. # [02:19] * Quits: billmason (n=billmaso@ip66.unival.com) (".")
  222. # [02:20] <Dashiva> It's a dual-sided question, I suppose. Who would think it was a good solution, and who would realize it's a bad solution yet remain silent.
  223. # [02:21] <Philip`> Only crazy people would think it's a good solution ;-)
  224. # [02:22] <Dashiva> Yet people are suggesting it on this very day :)
  225. # [02:22] <Philip`> I never suggested that people are not crazy
  226. # [02:23] <Dashiva> But if you believe there are crazy people on the list, should you not feel obliged to attempt to rectify this?
  227. # [02:23] <Philip`> I don't feel any need to argue against people who are suggesting crazy things, only against the crazy things that are currently in the spec
  228. # [02:24] <Philip`> (unless it seems likely that the crazy suggestions are going to be put into the spec, in which case it'd be good to pre-emptively argue against the craziness)
  229. # [02:25] <Dashiva> Even though the crazy people are claiming a lot of bandwidth and other finite resources?
  230. # [02:25] * Joins: eseidel (n=eseidel@c-67-171-36-188.hsd1.wa.comcast.net)
  231. # [02:25] * Joins: eseidel_ (n=eseidel@72.14.224.1)
  232. # [02:26] <Philip`> "You are currently using 102 MB (1%) of your 6767 MB." - that's equivalent to, like, 5 pence of bandwidth? I'm not too concerned about that particular resource
  233. # [02:27] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
  234. # [02:27] <Philip`> Arguing against crazy people won't stop the arguments - only arguing against the spec's craziness and getting that fixed will stop them
  235. # [02:27] <Dashiva> I meant mental bandwidth, e.g. how much of the mailing list discussion is about it :)
  236. # [02:28] <Philip`> (I think the spec's view on alt is crazy, since it forces information loss by making important images and lazy-author images indistinguishable)
  237. # [02:30] <Hixie> it would be an interesting exercise to have a spec editor just agree to every request
  238. # [02:30] <Hixie> and see what you end up with
  239. # [02:30] <Dashiva> Hixie: Remember, you aren't reflecting the WG
  240. # [02:30] <Dashiva> That means everyone!
  241. # [02:30] <Hixie> i hope i'm not!
  242. # [02:31] <Philip`> You should reflect the majority of the WG, by doing nothing whatsoever
  243. # [02:31] <Hixie> hah
  244. # [02:31] <roc> "alt" is supposed to be shown in tooltips now?
  245. # [02:31] <roc> I thought I won that battle 7 years ago
  246. # [02:31] <Hixie> the spec in fact says it is not
  247. # [02:32] <Philip`> roc: No, but pages need to degrade gracefully in IE6/7/etc
  248. # [02:33] <Philip`> Then again, you can just do <img src=... alt="_none" title=""> to avoid the tooltip, though then it'll look ugly while the page is loading and displays the image placeholder thing
  249. # [02:41] * Quits: eseidel (n=eseidel@c-67-171-36-188.hsd1.wa.comcast.net) (Read error: 110 (Connection timed out))
  250. # [02:41] * Quits: aroben (n=aroben@unaffiliated/aroben)
  251. # [02:43] * Quits: aroben|meeting (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  252. # [02:47] * Quits: tndH_ (i=Rob@adsl-87-102-114-53.karoo.KCOM.COM) ("ChatZilla 0.9.82.1-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  253. # [02:51] <Hixie> i really don't understand this obsession from shepazu and julian about not referencing html5
  254. # [02:52] <shepazu> "obsession"?
  255. # [02:52] <shepazu> I'm not obsessed, I just don't think it's a good idea to normatively reference something so early in the Rec track, with years to go
  256. # [02:53] <Hixie> btw john wanted me to remind you all that he did apologize for not remembering my post proposing to make alt="" mandatory
  257. # [02:53] <Dashiva> shepazu: It's even harder to reference implementations
  258. # [02:54] <Hixie> shepazu: why not?
  259. # [02:54] <Hixie> shepazu: it's by far the most detailed and complete definition so far
  260. # [02:54] <Hixie> shepazu: by all previous standards of quality, html5 is already far beyond REC
  261. # [02:54] * Philip` assumes shepazu does not believe the timeline in the HTML WG charter, that suggests CR by 2008 Q3 and REC by 2010 Q3
  262. # [02:55] <shepazu> Hixie: not in terms of stability
  263. # [02:55] <Hixie> shepazu: REC doesn't mean jack with respect to stability, just look at CSS2
  264. # [02:55] <Hixie> shepazu: or HTML4
  265. # [02:55] <shepazu> Philip`: the editor doesn't believe it, why should I?
  266. # [02:55] <Philip`> shepazu: I think that's quite sensible :-)
  267. # [02:55] <shepazu> :)
  268. # [02:56] <Dashiva> I think more and more people are caring less and less about REC :)
  269. # [02:56] <Hixie> also it's not like the stuff anne is referencing can actually change
  270. # [02:56] <Lachy> damn, I really should finish reading the whole thread before responding :-(
  271. # [02:56] <othermaciej> it would be great to switch to a better reference if there were one, but currently there isn't
  272. # [02:56] <Hixie> since it's all just describing actual implementations
  273. # [02:56] <othermaciej> referencing a document that doesn't yet contain the right info does not seem like a wise move
  274. # [02:56] <othermaciej> if the goal is to improve progress
  275. # [02:56] <shepazu> Dashiva: I think your sample may not be representative :)
  276. # [02:57] <Dashiva> shepazu: Really? I'd think CSS2.1 and CSS3 would be elsewhere on the track if so
  277. # [02:57] <shepazu> I'm not proposing dereferencing it, I'm proposing allocating resources to redirect it
  278. # [02:58] <shepazu> Dashiva: CSS is not a sane measure :)
  279. # [02:58] <shepazu> that's a good example of a bad example
  280. # [02:59] <shepazu> but that WG is getting its act together recently
  281. # [02:59] <Dashiva> Well, the other example being that HTML was left on the backburner for how many years? And javascript, to close the trinity.
  282. # [03:01] <Hixie> wow, http://www.w3.org/mid/OF7B780188.FAF5B9D6-ON85257456.00453CE0-86257456.0045F764@us.ibm.com was totally ignored
  283. # [03:01] <Hixie> so much for caring about the blind
  284. # [03:03] <Philip`> Why does the lack of responses within 12 hours to an email that didn't raise any obvious questions indicate that people don't care about the blind?
  285. # [03:04] <Hixie> well, lots of other e-mails got replies
  286. # [03:04] <Philip`> That's not answering the question at all :-p
  287. # [03:05] <Hixie> e-mails that, just like that one, suggested allowing alt to be optional
  288. # [03:05] <Hixie> so why did they get replies and not this one?
  289. # [03:06] <Philip`> That one doesn't suggest allowing alt to be optional, as far as I can tell
  290. # [03:06] <Hixie> hey, nobody picked up JF on his false claim that html5 requires a DTD
  291. # [03:06] <Philip`> (I interpreted "DTD" as a typo for "doctype")
  292. # [03:06] <Hixie> ah, maybe
  293. # [03:06] <Hixie> he's saying that flickr is irrelevant to accessibility, basically
  294. # [03:07] <Hixie> (at least for the totally blind)
  295. # [03:07] <Dashiva> And that valid html is useless, since google is doing fine
  296. # [03:07] <Philip`> That email seems to just suggest that it's not particularly interesting what alt text Flickr uses, so it could use alt="" or alt="_none" or alt="14097651074651076.jpeg" or [nothing] and we should instead consider the effect that the conformance requirements will have on other web pages
  297. # [03:08] <Hixie> fair enough
  298. # [03:08] <Philip`> (*That email == the 0F7B one)
  299. # [03:08] <Philip`> (Uh, OF7B)
  300. # [03:08] <Hixie> (of course we do still have to consider flickr in non-blind cases, e.g. text browsers)
  301. # [03:08] <Hixie> (and other threads go into that in more detail)
  302. # [03:10] <Hixie> http://www.w3.org/mid/012301c8c056$7d03ca60$6d01a8c0@stanford.edu is probably the clearest statement of john's opinion that i have seen so far
  303. # [03:10] <Philip`> "300 Multiple Choices" - that's far too many to choose from :-(
  304. # [03:11] <Dashiva> <movie title/>
  305. # [03:12] <Hixie> woot, i finally got to an e-mail actually discussing my proposal
  306. # [03:12] <Dashiva> Hixie: As I read it, he's got two concerns. One is that there must be some kind of presence, and the other like RB that he wants different image roles.
  307. # [03:12] <Dashiva> Anything I'm missing?
  308. # [03:12] <Hixie> not sure what you mean by either of those
  309. # [03:13] <Philip`> "Complete this sentence: This is ______: (A) orange (B) an elephant (C) madness (D) Greece"
  310. # [03:14] <Dashiva> Philip`: If you had said my name in that line, it would've been orange.
  311. # [03:15] * Quits: eseidel_ (n=eseidel@72.14.224.1) (Read error: 110 (Connection timed out))
  312. # [03:15] <Dashiva> Hixie: As in, he wants there to be an explicit statement of missing alt data. And, like RB, he wants to subdivide the missing alt data images into several classes.
  313. # [03:15] <Hixie> Dashiva: ah. well that's what importantimage="" does.
  314. # [03:16] <Hixie> wish i could come up with a better name for it
  315. # [03:16] <Philip`> importantimage only subdivides into two classes
  316. # [03:16] <Philip`> which isn't quite the same
  317. # [03:17] <Philip`> (I'm not sure how any UA would make use of the extra subdivisions, though)
  318. # [03:18] <Dashiva> I wonder if <img src missingalt="personal photo"> would be acceptable, or if it would need alt="" (some value, not necessarily empty) as well
  319. # [03:19] <Hixie> Philip`: no it changes the alt="" attribute into something that categorises (freeform) the image
  320. # [03:20] <Hixie> Dashiva: my proposal is <img src alt="personal photo" important>
  321. # [03:20] <Hixie> well, src="..."
  322. # [03:21] <Philip`> Dashiva: <img alt="personal photo" almostmissingalt> conveys the same information but degrades better in existing UAs, and means you don't have to worry about what <img alt="foo" missingalt="bar"> means
  323. # [03:21] <Philip`> Hixie: Ah, I assumed it was just a boolean attribute
  324. # [03:21] <Lachy> Hixie, is the intended purpose of importantimage="" only for images where there is no good alt text, and whatever is there is a just a poor substitue, or for all images that are important content, regardless of their alt text quality?
  325. # [03:22] <Hixie> it's only for the images that right now can have alt="" omitted
  326. # [03:22] <Hixie> it says "the alt attribute isn't an alternative, it just tells you what kind of photo it is"
  327. # [03:22] <Dashiva> Philip`: I'm not sure if it's better or not, to give legacy browsers the same information-less alt text over and over. As in, I'm not sure either way.
  328. # [03:22] <Lachy> ok. Then that makes the name importantimage really bad.
  329. # [03:22] <Hixie> yes
  330. # [03:23] <Hixie> it allows UAs to change from rendering the image as "%s" where %s = alt, to rendering the image as "[IMAGE: %s]" where %s = alt and "[IMAGE: ... ]" is rendered in some UA-specific way
  331. # [03:23] <Hixie> different voice, different color, etc
  332. # [03:23] <Hixie> showing an icon
  333. # [03:23] <Dashiva> onlyimage, missingalt
  334. # [03:23] <Philip`> Dashiva: It's not informationless - it shows that the image is a personal photo, and not a graph or whatever, and it ensures legacy browsers won't pretend the image doesn't exist or display it as "[10496518746051746506.jpeg]"
  335. # [03:24] <Dashiva> Philip`: If the values are fine-grained enough
  336. # [03:24] <Hixie> <img src="..." alt-just-say-what-kind-of-image-it-is-and-doesn't-provide-a-replacement alt="photo">
  337. # [03:25] <Hixie> maybe that attribute name is a bit long
  338. # [03:25] <Dashiva> descriptive-alt :D
  339. # [03:25] <Hixie> it's not descriptive
  340. # [03:25] <Hixie> that's the problem!
  341. # [03:25] <Hixie> nondescript="" maybe
  342. # [03:25] <Dashiva> alternate-alt
  343. # [03:25] <Philip`> Seems more useful if it is descriptive, rather than just saying what kind it is
  344. # [03:25] <Hixie> the point is it can't be descriptive
  345. # [03:25] <Hixie> you don't know what the image is!
  346. # [03:28] <Philip`> You can use metadata like Flickr titles, which has a non-zero chance of describing the photo better than just saying "photo", and UAs can automatically detect and remove repetition if they've recently read the same text from the page title/heading/etc
  347. # [03:29] <Hixie> uh huh
  348. # [03:29] <Philip`> (That's much more plausible than them containing advanced image analysis algorithms :-p )
  349. # [03:30] <Dashiva> I think the feature is very different depending on how specific the alt-replacing value is
  350. # [03:30] <Dashiva> If it's just "image" or "photo" or "icon", compared to "personal photo" and "graph or chart"
  351. # [03:31] <Dashiva> The latter case borders on descriptive, but would it ever occur in practice?
  352. # [03:31] <Hixie> could be either
  353. # [03:31] <Philip`> Nobody's going to use this new attribute so it doesn't need to be particularly easy to type
  354. # [03:31] <Dashiva> There's a point
  355. # [03:32] <Hixie> (i'm not sure how you could end up with it being a graph or chart)
  356. # [03:32] <Dashiva> Hixie: If it's a middle management chart sharing photo site
  357. # [03:32] <Hixie> fair enough
  358. # [03:32] <othermaciej> how about calling the attribute noalt
  359. # [03:32] <othermaciej> that is at least brief
  360. # [03:32] <Dashiva> Or some kind of CMS where you know the usage of a subarea of the content
  361. # [03:32] <othermaciej> and all it would be is a conformance checker silencer
  362. # [03:33] <Hixie> having an attribute noalt="" which requires alt="" to be present would at a very minimum make us the butt of several jokes over the next few years.
  363. # [03:33] <Lachy> othermaciej, noalt would be somewhat confusing for authors because, in this case, it would still require authors to provide alt="something"
  364. # [03:33] <othermaciej> I don't think it should require alt to be present
  365. # [03:33] <Hixie> oh, then you're proposing something else
  366. # [03:33] <Dashiva> othermaciej: Then you're making a different proposal
  367. # [03:33] <othermaciej> yeah
  368. # [03:34] <Hixie> noalt="" as just an alternative to alt="" is just dumb imho
  369. # [03:34] <Dashiva> Do you plan <img src noalt="personal photo">?
  370. # [03:34] <Hixie> it doesn't solve anything
  371. # [03:34] <Philip`> othermaciej: If (alt XOR noalt) was required, that would incentivise inappropriate insertion of noalt just to silence conformance checkers, whereas requiring (alt OR (alt AND importantimage)) would remove that harmful incentive since you'd have to come up with alt text anyway
  372. # [03:34] <Hixie> and adds a number of new error conditions
  373. # [03:34] <othermaciej> I think the conformance checker insisting that you say <img src="foo.jpg" very-long-terrible-attribute-name alt="something useless"> then no one will respect the conformance checker
  374. # [03:34] <Hixie> that's why we're looking for a nice short name for very-long-terrible-attribute-name
  375. # [03:34] <othermaciej> Philip`: it would create an incentive to add alt="" just as now
  376. # [03:34] <Philip`> othermaciej: How could the conformance checker insist on that? All it knows is whether you've got an alt attribute or not
  377. # [03:35] <Philip`> and it has no idea whether you need the very-long-etc attribute or not
  378. # [03:35] <Philip`> so it has to assume you don't
  379. # [03:35] <othermaciej> in that case it wouldn't solve the problem of incentive to add alt="" incorrectly
  380. # [03:35] <othermaciej> though I will agree it does not give materially more or less incentive than now
  381. # [03:35] <Lachy> but why would authors bother using <img alt="something" importantimage=""> when they can just as easily use <img alt="something">, especially since most authors won't notice the difference unless they test in non-visual browsers
  382. # [03:35] <Dashiva> Are there use cases for this attribute in hand-written content (and not counting templateish html for generated content)
  383. # [03:36] <Philip`> Dashiva: I could hand-write <img src="random-image.cgi" alt="???">
  384. # [03:36] <Dashiva> That counts as templateish in my book
  385. # [03:36] <othermaciej> the only semi-sane reason to insist on mandatory alt, even if it is bad, is to make it harder to accidentally omit alt
  386. # [03:37] <Dashiva> Philip`: Basically, are there cases where you'd be writing the attribute name often
  387. # [03:37] <othermaciej> if the way to say "I omitted alt on purpose" is longer to type than alt="", then authors will either ignore it or use alt="" anyway, which was the original problem the spec wanted to solve
  388. # [03:38] <Hixie> so we need a solution that's 6 letters or less
  389. # [03:38] <Hixie> badalt?
  390. # [03:38] <hdh> not-alt(ernate) sounds better than noalt, being a bool
  391. # [03:38] <Philip`> Do they have to be ASCII letters?
  392. # [03:38] <Hixie> yes
  393. # [03:38] <Philip`> :-(
  394. # [03:38] <Hixie> :-P
  395. # [03:38] <Dashiva> alt0
  396. # [03:39] <Dashiva> Hmm... x-alt, maybe
  397. # [03:39] <Philip`> <img src=... alt="Some kind of photo, I don't know really" altsucks>
  398. # [03:40] <Hixie> the effect i would expect this attribute to have on visual (graphical) browsers is that when they have images disabled, they'd show icons only for images with this attribute set (and maybe also those without alt="" set at all)
  399. # [03:40] <Hixie> so maybe an attribute name that plays on that?
  400. # [03:41] <Philip`> And they'd show the alt text (but no icon) for other images?
  401. # [03:41] <Hixie> <img src="..." alt="photo" icon> is confusing since the image isn't an icon...
  402. # [03:41] <Hixie> Philip`: right
  403. # [03:41] * Quits: weinig (n=weinig@nat/apple/x-a14452b139301dbf) (Read error: 104 (Connection reset by peer))
  404. # [03:41] * Joins: weinig (n=weinig@nat/apple/x-3f7fcb47824e0978)
  405. # [03:44] <Philip`> othermaciej: Hmm, I thought it was more about making sure conscientious authors are able to write conforming content - I don't see how we can do anything with lazy authors, since all the useful things we could do would be requiring the authors to give us more information, which they won't because they're lazy
  406. # [03:44] <Philip`> (Nearly all authors (except the most conscientious) will just write non-conforming content anyway, so we can't do anything to them)
  407. # [03:45] <othermaciej> Philip`: well, there's two different issues for conscientious authors
  408. # [03:46] <othermaciej> ok let me backtrack
  409. # [03:47] <othermaciej> is it better for an author who is serving a truly random unknown image to say <img alt="image" src="random.cgi" altsucks> or <img alt="" src="random.cgi" altsucks> or <img src="random.cgi" noalt>?
  410. # [03:47] <othermaciej> (though perhaps arguably all of these may be worse than saying nothing)
  411. # [03:48] <othermaciej> I would argue that saying "image" is worse in current AT, since it is likely worse than the localized image indicator, and alt="" is worse in current AT because it will make many screen readers skip the image entirely
  412. # [03:48] <Hixie> with my proposed attribute alt="" would be required to be non-empty
  413. # [03:48] <othermaciej> future AT would presumably ignore alt="" on such images so it won't be a benefit in that case
  414. # [03:49] <Philip`> othermaciej: The first option seems to produce the best output in current UAs, since the second is often entirely skipped and the user will never know there was an image, and the third is sometimes read as "random.cgi" (which is uglier than "image") or as "image" (which is no better than "image")
  415. # [03:49] <othermaciej> but alt="image" may well still be worse than letting the AT do its normal image identification heuristic
  416. # [03:49] <othermaciej> Philip`: reading as "image" is better because it is localized
  417. # [03:49] <othermaciej> and can use a distinguished voice
  418. # [03:49] <Philip`> It seems hard to be much worse than ATs' normal image identification heuristics :-)
  419. # [03:50] <Dashiva> I think we all know existing AT is not quite optimal in many ways
  420. # [03:50] <Hixie> we're not targetting today's ATs
  421. # [03:50] <Hixie> (by definition)
  422. # [03:50] <Hixie> though it is important that contain degrade well in today's ATs
  423. # [03:50] <Hixie> which is the main argument against making alt="" optional
  424. # [03:50] <othermaciej> future ATs would not benefit from saying alt="image" and may well do worse than if it is not specified (unless they hardcode a big list of alt text that is too generic to be helpful)
  425. # [03:51] <Philip`> Future UAs can read <img alt="image" altsucks> in a distinguished voice, and it will be localised consistently with the rest of the page's textual content
  426. # [03:51] <Dashiva> Only image is spelled correctly
  427. # [03:51] <Dashiva> :)
  428. # [03:52] <Dashiva> As I see it, AT needs to cope with images missing alt. That's a fact of life. So if we give them a missing alt and the magic future-supported new attribute, they will do no worse than they would with most images, and they will do better in the future
  429. # [03:52] <othermaciej> <img alt="image"> would degrade worse than <img> with no alt attribute in at least some current AT (e.g. VoiceOver)
  430. # [03:52] <Philip`> othermaciej: In what ways is it worse?
  431. # [03:53] <Philip`> (At least by default, VO says "image" in the same voice as normal page content, if I remember correctly)
  432. # [03:53] <othermaciej> because it is not localized to the user's OS language
  433. # [03:53] * Philip` has no idea how many people reconfigure those voices
  434. # [03:53] <Philip`> Is that much of a problem, given that the entire page is not localised to the user's OS language either?
  435. # [03:54] <othermaciej> (localizing to the page content is not the same; we don't translate all the menus to French if you visit a French web page on a German system)
  436. # [03:55] <Philip`> If you don't understand French, you might not understand it saying "image" in a French accent (or whatever the translation is), but you also wouldn't understand anything else on the page so the image part is a relatively trivial inconvenience
  437. # [03:56] <Dashiva> The utility of this attribute in the first place is rather minimal
  438. # [03:56] <Hixie> http://junkyard.damowmow.com/325 btw if people want to play around with various UAs
  439. # [03:56] <Philip`> You'd just want to be able to find the <img src=german-flag.gif alt=Deustch> and then you'd be happy
  440. # [03:57] <Philip`> Hixie: Try them in <a href>s too, since that gives different behaviour
  441. # [03:57] <Dashiva> But ironically enough, I have a design & usability exam in a few hours, so I gotta sleep. :)
  442. # [03:57] <Hixie> can't right now. may later.
  443. # [03:57] <Hixie> bbiab
  444. # [03:57] <gavin_> "image" is "image" in french
  445. # [03:58] * Quits: weinig (n=weinig@nat/apple/x-3f7fcb47824e0978) (Connection timed out)
  446. # [03:59] <Philip`> Oh, bed is a good idea
  447. # [04:02] <Philip`> About attributes names: For consistency with <img src alt>, it ought to be a hard-to-understand few-letter abbreviation
  448. # [04:05] <hdh> mpa, missing-proper-alt, just not from one word
  449. # [04:06] * Philip` fails to think of an expansion for "lol" that can fit in front of "cat(egory)"
  450. # [04:24] * Quits: KevinMarks (n=KevinMar@72-254-41-214.client.stsn.net) ("The computer fell asleep")
  451. # [04:24] * Joins: billyjack (n=MikeSmit@58.157.21.205)
  452. # [04:24] * Quits: billyjack (n=MikeSmit@58.157.21.205) (Read error: 104 (Connection reset by peer))
  453. # [04:25] <MikeSmith> Lachy: you there?
  454. # [04:32] * Joins: hdh_ (n=hdh@118.71.125.176)
  455. # [04:35] * Joins: aroben (n=aroben@unaffiliated/aroben)
  456. # [04:41] * Quits: othermaciej (n=mjs@17.255.103.110)
  457. # [04:47] * Joins: jdandrea (n=jdandrea@ool-44c09c49.dyn.optonline.net)
  458. # [04:47] * Quits: hdh (n=hdh@118.71.126.53) (Read error: 110 (Connection timed out))
  459. # [04:48] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.3 (IRC client for Emacs)")
  460. # [05:35] * Quits: MikeSmith (n=MikeSmit@58.157.21.205) ("Less talk, more pimp walk.")
  461. # [05:48] * Quits: jdandrea (n=jdandrea@ool-44c09c49.dyn.optonline.net) ("ciao")
  462. # [06:14] * Joins: othermaciej (n=mjs@adsl-70-137-131-51.dsl.snfc21.sbcglobal.net)
  463. # [06:16] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  464. # [06:23] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  465. # [06:35] * Quits: jruderman (n=jruderma@guest-226.mountainview.mozilla.com)
  466. # [06:37] * Joins: eseidel (n=eseidel@c-67-171-36-188.hsd1.wa.comcast.net)
  467. # [06:46] * Quits: eseidel (n=eseidel@c-67-171-36-188.hsd1.wa.comcast.net) (Read error: 104 (Connection reset by peer))
  468. # [06:47] * Joins: eseidel (n=eseidel@c-67-171-36-188.hsd1.wa.comcast.net)
  469. # [06:58] * Parts: hdh_ (n=hdh@118.71.125.176) ("Konversation terminated!")
  470. # [06:59] * Quits: roc (n=roc@202.0.36.64)
  471. # [06:59] * Joins: roc (n=roc@202.0.36.64)
  472. # [07:03] * Joins: jruderman (n=jruderma@c-67-180-39-55.hsd1.ca.comcast.net)
  473. # [07:06] * Quits: eseidel (n=eseidel@c-67-171-36-188.hsd1.wa.comcast.net) (Read error: 110 (Connection timed out))
  474. # [07:11] * Joins: dbaron (n=dbaron@c-71-204-153-3.hsd1.ca.comcast.net)
  475. # [07:28] <Dashiva> Philip`: "lazy or lacking"
  476. # [07:39] * Quits: csarven (n=csarven@modemcable130.251-202-24.mc.videotron.ca) ("http://www.csarven.ca/")
  477. # [07:48] * Joins: bzed_ (n=bzed@devel.recluse.de)
  478. # [07:52] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  479. # [08:02] * Quits: othermaciej (n=mjs@adsl-70-137-131-51.dsl.snfc21.sbcglobal.net) (Read error: 110 (Connection timed out))
  480. # [08:11] * Quits: bzed (n=bzed@debian/developer/bzed) (Read error: 111 (Connection refused))
  481. # [08:11] * bzed_ is now known as bzed
  482. # [08:16] * Quits: roc (n=roc@202.0.36.64)
  483. # [08:23] * Joins: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de)
  484. # [08:43] * Joins: othermaciej (n=mjs@adsl-70-137-131-51.dsl.snfc21.sbcglobal.net)
  485. # [08:58] * Joins: MikeSmith (n=MikeSmit@EM60-254-222-10.pool.e-mobile.ne.jp)
  486. # [09:00] * Joins: htmlfivedotnet (n=dcostali@c-67-162-99-121.hsd1.il.comcast.net)
  487. # [09:00] * Parts: htmlfivedotnet (n=dcostali@c-67-162-99-121.hsd1.il.comcast.net)
  488. # [09:01] <MikeSmith> Lachy: ping me when you back around
  489. # [09:01] <MikeSmith> please
  490. # [09:10] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) ("bye")
  491. # [09:12] * Joins: qwert666 (n=qwert666@acaj223.neoplus.adsl.tpnet.pl)
  492. # [09:15] <Lachy> ping
  493. # [09:15] <Lachy> MikeSmith,
  494. # [09:15] <MikeSmith> Lachy: hei
  495. # [09:15] <MikeSmith> wanted to ask if you had seen Thomas Roessler's HTML5 slides yet
  496. # [09:15] <Lachy> no
  497. # [09:16] <MikeSmith> http://www.owasp.org/index.php/AppSecEU08_HTML5
  498. # [09:16] <MikeSmith> PDF slides: http://www.w3.org/2008/Talks/0521-owasp-html5-tlr/0521-owasp-html5-tlr.pdf
  499. # [09:17] <MikeSmith> he has some fun images in there
  500. # [09:17] <MikeSmith> maybe some that you could repurpose
  501. # [09:18] * Quits: psa (n=yomode@71.93.19.66) (kornbluth.freenode.net irc.freenode.net)
  502. # [09:18] * Quits: Toolskyn (n=root@apher.xlshosting.com) (kornbluth.freenode.net irc.freenode.net)
  503. # [09:19] * Joins: psa (n=yomode@71.93.19.66)
  504. # [09:19] * Joins: Toolskyn (n=root@apher.xlshosting.com)
  505. # [09:22] <Lachy> nothing suitable in there
  506. # [09:22] <Lachy> I'm looking for a spirit level or something similar to represent validation
  507. # [09:22] <Lachy> and maybe a hammer or some other tool for html5lib
  508. # [09:23] * Joins: billyjack (n=MikeSmit@EM60-254-222-10.pool.e-mobile.ne.jp)
  509. # [09:23] * Quits: billyjack (n=MikeSmit@EM60-254-222-10.pool.e-mobile.ne.jp) (Read error: 104 (Connection reset by peer))
  510. # [09:39] * Quits: dbaron (n=dbaron@c-71-204-153-3.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  511. # [09:49] <hsivonen> Lachy: Re: photo representing tools: http://flickr.com/photos/geishaboy500/100043823/
  512. # [09:50] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  513. # [09:52] <Lachy> hsivonen, nice!
  514. # [09:53] * Joins: tantek_ (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  515. # [09:55] <virtuelv> heh, what's this supposed to mean? http://twitter.com/mollydotcom/statuses/821528080
  516. # [09:57] * Joins: heycam (n=cam@124-168-33-67.dyn.iinet.net.au)
  517. # [10:04] * Joins: aaronlev (n=chatzill@g226141055.adsl.alicedsl.de)
  518. # [10:04] * Quits: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com)
  519. # [10:04] * Quits: sverrej_ (n=sverrej@89.10.27.86) (Read error: 110 (Connection timed out))
  520. # [10:05] <hsivonen> whoa. lots of irc log about noalt
  521. # [10:06] <annevk> I skipped it
  522. # [10:06] <annevk> just like some of the e-mails :)
  523. # [10:07] <othermaciej> so can anyone help me find a good CC-licensed (or otherwise reusable) photo of a beaker or flask of acid (or some chemical that could pass for such)?
  524. # [10:07] <othermaciej> I could use a presentation picture for "acid tests"
  525. # [10:07] <hsivonen> fwiw, I agree with othermaciej that the only semi-sane reason for noalt is helping forgetful authors, but I think the Image Report already covers that case
  526. # [10:07] <othermaciej> I think the image report covers it too
  527. # [10:07] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  528. # [10:07] <othermaciej> hsivonen: although, there is value to a warning that you can drive down to 0
  529. # [10:07] <othermaciej> compared to a long list you must review on every change
  530. # [10:08] <othermaciej> (that's why WebKit builds with -Werror even though it causes us no end of pain in central builds for Mac OS X)
  531. # [10:08] <Philip`> hsivonen: Forgetful authors will forget to turn the image report on, or if they do turn it on then they'd forget to look at it
  532. # [10:09] <hsivonen> Philip`: will they forget to run a validator at all?
  533. # [10:09] <hsivonen> (that's what I forget occasionally when updating an existing page)
  534. # [10:10] <Philip`> (and it doesn't provide any immediate feedback like "you forgot to put alt on 3 images here and here and here", so it takes a reasonable amount of effort and concentration to work out where you've gone wrong)
  535. # [10:10] <hsivonen> (leading to comical stuff like validator documentation being invalid)
  536. # [10:10] <hsivonen> the Image Report has a group for missing alt that you can drive to zarro and links to source locations
  537. # [10:11] <Philip`> hsivonen: Not all people will forget to validate at all, and some of those who remember will fail to use the fancy options
  538. # [10:12] <othermaciej> hsivonen: but that's no good if you have cases where missing alt is the right thing
  539. # [10:12] <Philip`> hsivonen: It takes effort and concentration to find that group, since it looks the same as all the other groups of images
  540. # [10:12] <othermaciej> hsivonen: thus, noalt to tag such locations
  541. # [10:12] <hsivonen> othermaciej: yeah, that's a semi-sane use case for noalt
  542. # [10:13] <Philip`> <!-- #pragma warning(disable:missing-alt) --><img src=random.cgi>
  543. # [10:13] <hsivonen> Philip`: shouldn't authors maximize the effort and concentration on accessibility??????
  544. # [10:13] <zcorpan_> i don't see why missing alt is worse than alt='' when the right thing should be alt='something else'
  545. # [10:14] <Hixie> it's not
  546. # [10:14] <Hixie> it's better :-)
  547. # [10:14] <zcorpan_> both authors and tools emit alt='' out of cargo cult fasion
  548. # [10:14] <Philip`> hsivonen: Yes, but we should maximise the return for a given level of (typically quite low) effort
  549. # [10:15] <hsivonen> Philip`: sure ( ?????? means :-) )
  550. # [10:16] * Joins: sverrej (n=sverrej@pat-tdc.opera.com)
  551. # [10:16] <hsivonen> what does XXX4 mean on tlr's slide of window props?
  552. # [10:18] <MikeSmith> hsivonen: referring to http://www.whatwg.org/specs/web-apps/current-work/#xxx4index
  553. # [10:18] <MikeSmith> I guess
  554. # [10:18] <othermaciej> it is surprisingly hard to find a good free picture of a beaker or flask of acid
  555. # [10:18] <Philip`> (Also the Image Report has way too many words in it, partly because the alt requirements are too hard to explain, and so people simplify to "alt is optional" (which isn't what we want since in almost all cases alt is required))
  556. # [10:19] <hsivonen> MikeSmith: thanks
  557. # [10:19] <MikeSmith> hsivonen: placeholder method name from Window interface
  558. # [10:19] <MikeSmith> hsivonen: np
  559. # [10:19] <hsivonen> sometimes the Web is so weird that I'm not sure if there's an implemented property named XXX4
  560. # [10:19] <MikeSmith> othermaciej: we should consider other image metaphors for acid
  561. # [10:20] <MikeSmith> blotter-paper, windowpane
  562. # [10:20] <MikeSmith> Sandox Labs ampule
  563. # [10:21] <annevk> lol, XXX4 is a reference to Web IDL for something that's not defined yet
  564. # [10:21] <othermaciej> MikeSmith: I don't want people to get the impression that this is an electric kool-aid acid text
  565. # [10:22] <othermaciej> now I want to add window.XXX4 to WebKit
  566. # [10:22] <othermaciej> but I need to figure out what is should do
  567. # [10:22] <Hixie> http://www.whatwg.org/specs/web-apps/current-work/#xxx4index
  568. # [10:22] <Hixie> it's the index getter on Window
  569. # [10:23] <othermaciej> maybe this picture for "acid test": http://www.dkimages.com/discover/previews/967/65020227.JPG ?
  570. # [10:23] * Joins: roc (n=roc@121-72-170-39.dsl.telstraclear.net)
  571. # [10:23] <othermaciej> or maybe this one looks friendlier: http://www.koh-development.com/Images/erlenmeyer_flask.jpg
  572. # [10:23] <Hixie> use the pictures on acidtests.org/images
  573. # [10:23] <Hixie> :-)
  574. # [10:23] <MikeSmith> othermaciej: that first one says "noxious odor" to me
  575. # [10:24] <MikeSmith> othermaciej: second one says, "beaker full of brandy"
  576. # [10:24] <othermaciej> how about this: http://z.about.com/d/chemistry/1/0/B/T/flask.jpg
  577. # [10:24] <othermaciej> does that one say, "this web stuff is totally scientific"?
  578. # [10:25] <hsivonen> tlr has an interesting photo choice for introducing the HTML WG
  579. # [10:25] <othermaciej> or this: http://www.koh-development.com/Images/filtration_flask.jpg
  580. # [10:26] <annevk> heh, that presentation is great
  581. # [10:26] <annevk> (the one from thomas)
  582. # [10:26] <hsivonen> (the photo introducing the WG is http://www.flickr.com/photos/lassmatazz/325437141 )
  583. # [10:27] <annevk> hsivonen, isn't that a photo about what will happen with registerContentHandler ?
  584. # [10:27] <annevk> hsivonen, web sites fighting over who will get the media type?
  585. # [10:28] <hsivonen> annevk: oh
  586. # [10:28] <annevk> hsivonen, could be your way as well I suppose
  587. # [10:28] * annevk thought http://www.flickr.com/photos/nathansnider/497536082/ was introducing HTML5
  588. # [10:31] * Joins: tndH_ (i=Rob@adsl-87-102-114-53.karoo.KCOM.COM)
  589. # [10:31] * tndH_ is now known as tndH
  590. # [10:36] <MikeSmith> fwiw, while taking a look at the following page I came across an issue that seems to me to illustrate to authors one of unintended consequences of serving XHTML content as text/html
  591. # [10:36] <MikeSmith> page is this:
  592. # [10:37] <MikeSmith> http://www.w3.org/TR/xmlschema-1/
  593. # [10:37] <MikeSmith> I looked at it because David Storey from Opera pointed out a CSS mistake in it
  594. # [10:37] <MikeSmith> http://www.w3.org/TR/xmlschema-1/#c-selector-xpath
  595. # [10:37] <MikeSmith> the table there
  596. # [10:38] <MikeSmith> has negative text-indent set on it
  597. # [10:38] <MikeSmith> which causes the text to overflow the left edge of the table
  598. # [10:38] <MikeSmith> in Opera and in Webkit
  599. # [10:39] <MikeSmith> but in looking at that, the other thing I noticed was duplicate <a name>s with the same ID values all over the place
  600. # [10:39] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  601. # [10:40] <MikeSmith> in Web Inspector
  602. # [10:40] <othermaciej> blech
  603. # [10:42] <MikeSmith> http://www.w3.org/2008/05/dup-a-name.png
  604. # [10:42] <MikeSmith> so I filed a bug:
  605. # [10:42] <MikeSmith> https://bugs.webkit.org/show_bug.cgi?id=19282
  606. # [10:42] <Philip`> http://code.google.com/p/aza/source/browse/trunk/SocialHistory/SocialHistory.js - that detecting-visited-links thing is catching on
  607. # [10:42] <MikeSmith> knowing pretty much what the answer would
  608. # [10:43] <Philip`> "The best part is that this information leak will never be plugged because it’s a fundamental feature of the browser.", apparently
  609. # [10:43] <annevk> MikeSmith, it's an Appendix C violation
  610. # [10:43] <MikeSmith> Philip`: hmm, that's Aza Raskin's stuff
  611. # [10:44] <Philip`> MikeSmith: Indeed
  612. # [10:44] <MikeSmith> annevk: yeah. I guess it must have been generated from xmlspec source
  613. # [10:45] <MikeSmith> so maybe same problem will occur with anything generated from xmlspc
  614. # [10:45] <annevk> there are other specs with the same issue, yeah
  615. # [10:46] <annevk> or some issue like that anyway
  616. # [10:46] * Joins: webben (n=benh@nat/yahoo/x-2564507c769a056d)
  617. # [10:46] <annevk> W3C is just as much responsible for TAG soup as the rest of the Web :p
  618. # [10:46] <MikeSmith> heh
  619. # [10:47] <MikeSmith> well, particular end result of that problem, in Webkit at least, is duplicate IDs (and fragment identifiers) all the hell all over the place in the DOM
  620. # [10:48] <annevk> maybe you guys should deploy validator.nu ;)
  621. # [10:48] * Philip` had the same problem when his spec-annotation code produced <span style="background:red">%s</span> and then %s = '' and then it was serialised as XML and interpreted as HTML, so he had to write an HTML serialiser instead
  622. # [10:49] <Philip`> The problems tend to be annoyingly subtle
  623. # [10:50] * Joins: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net)
  624. # [10:51] <hsivonen> annevk: validator.nu doesn't catch duplicate IDs in text/html at the moment
  625. # [10:54] <annevk> the specific issue is <a/> not duplicate IDs
  626. # [10:54] <hsivonen> oh ok
  627. # [10:56] <Lachy> I need one more picture for the How to Contribute slide, and I'm done!
  628. # [10:58] <Lachy> what's an animal that's typically known for working together in a community, or could otherwise convey teamwork?
  629. # [10:58] <Philip`> A human?
  630. # [10:58] <Lachy> Philip`, other than a human
  631. # [10:58] <hsivonen> Lachy: an ant
  632. # [10:58] <hsivonen> Lachy: but I read somewhere that ants are actually pretty chaotic
  633. # [10:59] <Philip`> Teamwork is often chaotic :-)
  634. # [10:59] <MikeSmith> Lachy: a jackal
  635. # [10:59] <Lachy> what's a jackal?
  636. # [10:59] <hsivonen> Lachy: a lone assassin
  637. # [11:00] <MikeSmith> pack of jackals
  638. # [11:00] <hsivonen> the lone gunmen?-)
  639. # [11:01] <Lachy> http://en.wikipedia.org/wiki/The_Lone_Gunmen ?
  640. # [11:01] <Philip`> http://www.flickr.com/photos/kasimetcalfe/118471837/
  641. # [11:02] <hsivonen> Lachy: http://en.wikipedia.org/wiki/The_Jackal_(fictional_character)
  642. # [11:02] <Hixie> i wouldn't liken this community to ants
  643. # [11:03] <Lachy> what about bees?
  644. # [11:03] <Philip`> But they're so cute
  645. # [11:04] <Hixie> nor bees
  646. # [11:04] <Hixie> sharks, maybe...
  647. # [11:04] <roc> piranhas
  648. # [11:05] <Hixie> yeah, or piranhas
  649. # [11:05] <Hixie> do they school?
  650. # [11:05] <annevk> http://upload.wikimedia.org/wikipedia/en/6/69/New_FOXHOUND.jpg
  651. # [11:05] <roc> "It is not rare to find individuals with one eye missing due to a previous attack."
  652. # [11:05] <annevk> though not everyone might get the reference
  653. # [11:07] <Lachy> annevk, I don't get it
  654. # [11:07] <Lachy> what about http://en.wikipedia.org/wiki/Image:School_of_reef_fish_at_Rapture_Reef%2C_French_Frigate_Shoals.jpg
  655. # [11:08] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  656. # [11:08] <Lachy> http://commons.wikimedia.org/wiki/Image:School_of_Chaetodon_ulietensis.jpg
  657. # [11:09] <roc> Piranhas seem more appropriate, for their tendency to mutilate and cannibalize each other
  658. # [11:10] <MikeSmith> biker gang
  659. # [11:11] <Lachy> roc, I could only find photos of individual piranhas
  660. # [11:11] <hsivonen> roc: we don't do that
  661. # [11:12] <roc> the alt-fest sounds pretty painful for everyone
  662. # [11:13] <othermaciej> how about beavers?
  663. # [11:13] <othermaciej> they cooperate in a way that doesn't exactly signal hive mind
  664. # [11:13] <othermaciej> and are productive
  665. # [11:13] <Lachy> I almost forgot, I need to find a higher resolution photo of the rosetta stone with an appropriate licence
  666. # [11:14] <othermaciej> I still haven't found good acid
  667. # [11:14] <othermaciej> a picture thereof I mean
  668. # [11:14] <othermaciej> not gonna complain about drug sourcing here
  669. # [11:18] <hsivonen> roc: I think the alt and the ARIA colon threads are making people careful to avoid discussing accessibility topics
  670. # [11:20] <annevk> Lachy, http://www.oceanlab.abdn.ac.uk/blog/wp-content/pw-tight-family-cri.jpg
  671. # [11:21] <hsivonen> annevk: are those orcas?
  672. # [11:22] * Quits: jruderman (n=jruderma@c-67-180-39-55.hsd1.ca.comcast.net)
  673. # [11:22] <annevk> they're described as whales on the page
  674. # [11:24] <annevk> i found them on
  675. # [11:24] <annevk> http://www.oceanlab.abdn.ac.uk/blog/?p=236
  676. # [11:25] <hsivonen> should I make the XML side of Validator.nu match character encoding names according to the HTML5 rules?
  677. # [11:26] * Joins: ROBOd (n=robod@89.122.216.38)
  678. # [11:32] <hsivonen> are SVG WG meeting minutes public these days?
  679. # [11:34] <Lachy> This one will do http://flickr.com/photos/nathanphilpot/458372179/
  680. # [11:34] <annevk> should be, http://lists.w3.org/Archives/Public/public-svg-wg/latest
  681. # [11:35] <hsivonen> annevk: thanks. so many lists to choose from
  682. # [11:36] <annevk> hsivonen, I think that's their new list but they seem to be using the member-only one as well sometimes
  683. # [11:53] <gsnedders> Lachy: LOL
  684. # [11:54] <gsnedders> Lachy: (that's re: my slide)
  685. # [11:54] * Joins: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
  686. # [11:54] * Joins: aaronlev_ (n=chatzill@g226139154.adsl.alicedsl.de)
  687. # [11:55] <gsnedders> Philip`: That commit took around six seconds off parsing HTML 5's source (as opposed to the postprocessed index)
  688. # [11:55] <gsnedders> Philip`: (on my local machine, taking it down to 11s)
  689. # [12:03] <Lachy> gsnedders, I changed it. I'm just going to say that funny bit
  690. # [12:03] <Lachy> I'm publishing the slides now
  691. # [12:11] <Lachy> http://lachy.id.au/dev/presentation/hands-on-html5/hands-on-html5.pdf
  692. # [12:12] <Lachy> keynotes slides are still uploading
  693. # [12:12] <gsnedders> 31.4MB!?
  694. # [12:12] * Quits: aaronlev (n=chatzill@g226141055.adsl.alicedsl.de) (Read error: 110 (Connection timed out))
  695. # [12:13] <Lachy> yeah. If I zip the PDF, then it only reduces it to 30.4
  696. # [12:13] <Lachy> the keynote slides are only 14
  697. # [12:14] <Lachy> http://lachy.id.au/dev/presentation/hands-on-html5/hands-on-html5.zip
  698. # [12:15] <gsnedders> Lachy: Where are you giving it, anyway?
  699. # [12:15] <Hixie> i see you agreed with my Gill Sans suggestion :-)
  700. # [12:16] <Hixie> i think your "solve real problems" picture is ironic
  701. # [12:16] <Hixie> and should have a "no" symbol over it :-)
  702. # [12:16] <Hixie> (circle with a slash)
  703. # [12:18] <Lachy> it's supposed to convey the concept of solving things, not be technically accurate :-)
  704. # [12:20] <gsnedders> Lachy: html5lib only has complete parsers in Python and Ruby, and has a incomplete tokeniser in C. There is no C++
  705. # [12:20] <Dashiva> It seems Lachy ignored all my comments *sob*
  706. # [12:20] <Lachy> ok, I'll fix that
  707. # [12:21] <gsnedders> ah. @media. Mols was trying to con me into going there
  708. # [12:21] <Lachy> gsnedders, I just changed it to "Python, Ruby, C"
  709. # [12:21] <Dashiva> Are there supposed to be two identical kitteh blog slides?
  710. # [12:22] <Lachy> they're not identical
  711. # [12:22] <Lachy> oh, I see. the PDF printed each individual step, rather than the whole slide
  712. # [12:22] <Dashiva> I can't tell the difference between the two first in the pdf.
  713. # [12:22] <Lachy> I'll fix that later
  714. # [12:22] <Dashiva> oh
  715. # [12:25] * Quits: roc (n=roc@121-72-170-39.dsl.telstraclear.net)
  716. # [12:30] <hsivonen> Hixie: do you intend the HTML5 encoding matching to be normative over XHTML5?
  717. # [12:35] <hsivonen> Lachy: "C++" under "html5lib"?
  718. # [12:36] <Hixie> gsnedders: is she the one who is working with microsoft?
  719. # [12:37] <Hixie> or is this another molly
  720. # [12:37] <Hixie> i get them all so confused
  721. # [12:37] <Hixie> hsivonen: um
  722. # [12:37] <Hixie> hsivonen: elabroate?
  723. # [12:38] <hsivonen> Hixie: the step where punctuation is ignored when finding a decoder to instantiate
  724. # [12:38] <hsivonen> Hixie: is that supposed to apply Web platform wide
  725. # [12:38] <hsivonen> to XML, CSS, text/plain, etc.?
  726. # [12:38] <gsnedders> Hixie: yes, that Molly
  727. # [12:38] <gsnedders> Hixie: as in "molly" on IRC :P
  728. # [12:39] <gsnedders> Hixie: and molly.com
  729. # [12:39] <Hixie> hsivonen: oh. dunno. what do UAs do? Does XML define anything?
  730. # [12:39] <Hixie> or CSS?
  731. # [12:39] <hsivonen> Hixie: I thought you'd have it figured out :-)
  732. # [12:40] <Hixie> i just wrote the html5 spec, not the others :-P
  733. # [12:40] <Hixie> it probably should apply platform-wide, but the validator should complain about anything not matching the real names in any case
  734. # [12:40] <hsivonen> ok
  735. # [12:45] <Lachy> hsivonen, yeah, I know. I looked at the html5lib repo and saw python, ruby and C, but I accidentally wrote C++ instead.
  736. # [12:51] <hsivonen> I think I'll just let the punctuation weirdness fall under the "not the preferred name" error
  737. # [12:54] <annevk> "Who thinks they know more about it than we do?" is slightly arrogant
  738. # [12:54] <annevk> and makes me want to come over and make fun of you :p
  739. # [12:54] * hsivonen agrees it is arrogant
  740. # [12:56] <Dashiva> Remove "thinks they"
  741. # [12:56] <Dashiva> And then they can see if it's anne before mocking them
  742. # [12:57] * Joins: webben_ (n=benh@nat/yahoo/x-a85fa8d3caa66a28)
  743. # [12:58] * Quits: webben (n=benh@nat/yahoo/x-2564507c769a056d) (Read error: 104 (Connection reset by peer))
  744. # [13:04] * Quits: webben_ (n=benh@nat/yahoo/x-a85fa8d3caa66a28)
  745. # [13:06] <annevk> hsivonen, I think the SVG WG is going to proppose using an XML parser in text/html in some way
  746. # [13:06] <Lachy> hsivonen, annevk, what should I use instead?
  747. # [13:06] <annevk> (glancing over their minutes)
  748. # [13:06] <annevk> Lachy, just drop it
  749. # [13:06] <Lachy> ok
  750. # [13:07] <Dashiva> annevk: That'll be fun
  751. # [13:07] <hsivonen> annevk: I'm eager to see their implementation
  752. # [13:08] <hsivonen> annevk: also, I'm eager to see an explanation how it solves a Real Problem
  753. # [13:09] <Hixie> annevk: if they manage to find a way to do that while addressing the constaints we have to work with, that'd be great!
  754. # [13:09] <Hixie> i totally failed to do so
  755. # [13:09] <othermaciej> having an implementation is merely an implementation issue
  756. # [13:10] <othermaciej> no need to be concerned with that sort of thing
  757. # [13:10] <annevk> Hixie, I'm personally not that intrigued by the idea of doubling the complexity of the HTML parser, but we'll see
  758. # [13:11] <othermaciej> annevk: obviously a worthwhile tradeoff for the benefit of dracanoian error handling in text/html, plus the all-important ability to cut & paste source fragments into illustration tools
  759. # [13:11] <Hixie> if they seriously find a way to do it while not violating the constratints, i'm definitely interested
  760. # [13:11] <Hixie> however, i'm 99% sure that's not possible, so that may be a moot point
  761. # [13:12] <Hixie> i wonder if i wrote down the constraints anywhere convenient
  762. # [13:12] <Hixie> other than irc logs...
  763. # [13:13] <annevk> I think they're scattered around on varoius wiki pages, e-mail archives and IRC
  764. # [13:13] <Hixie> pity
  765. # [13:15] <annevk> given that including a new vocabulary is something we don't expect to happen often it's probably not much of an issue to repeat them now and then, though having them somewhere on a wiki would be preferred of course
  766. # [13:22] * Quits: mlpug (n=mlpug__@a88-115-166-231.elisa-laajakaista.fi) (Connection timed out)
  767. # [13:22] <Hixie> http://krijnhoetmer.nl/irc-logs/whatwg/20080417 has the constraints
  768. # [13:27] <zcorpan> Hixie: could you click on one or more of those yellow boxes so i know where to look?
  769. # [13:30] * zcorpan found
  770. # [13:31] <annevk> starts about here: http://krijnhoetmer.nl/irc-logs/whatwg/20080417#l-238
  771. # [13:34] <Lachy> I've fixed all the issues with the slides and uploaded new copies
  772. # [13:35] <Hixie> http://wiki.whatwg.org/wiki/Constraints_for_New_Vocabularies
  773. # [13:36] * annevk downloads a new copy
  774. # [13:36] <gsnedders> Someone will be happy about <http://hg.gsnedders.com/http-parsing/rev/dc816eb2bc3a> :P
  775. # [13:38] <annevk> Lachy, it's not too clear on where people should go to join this stuff, e.g. whatwg.org / w3.org/html
  776. # [13:40] * Quits: sverrej (n=sverrej@pat-tdc.opera.com) (Remote closed the connection)
  777. # [13:40] <Hixie> well crap. i can't find why i added rel=contact.
  778. # [13:41] <hsivonen> Hixie: XFN?
  779. # [13:41] <Hixie> nope, that's the problem
  780. # [13:41] <Hixie> it clashes with xfn
  781. # [13:41] <Hixie> i need to work out whether to nuke it altogether, or rename it
  782. # [13:42] <hsivonen> I've finally seen a reasonable use case for a subset of XFN
  783. # [13:42] <annevk> hmm, it's not in http://www.w3.org/TR/html4/types.html#type-links
  784. # [13:42] <annevk> though I remember using it way before XFN
  785. # [13:42] <hsivonen> social network portability by scraping XFN+hCard-enabled profile pages
  786. # [13:44] <Hixie> oh well, i guess i'll comment it out
  787. # [13:45] <Hixie> oh wait, i see why i have it
  788. # [13:45] <Hixie> it's the 8th mode used rel= value
  789. # [13:45] <annevk> s/mode/most/
  790. # [13:47] <hsivonen> does WordPress emit it on blogrolls or something?
  791. # [13:47] <Lachy> annevk, I added this as the second last slide just before the credits http://lachy.id.au/temp/links.jpg
  792. # [13:48] <Lachy> is that ok?
  793. # [13:48] <Lachy> or should I left align it like the others?
  794. # [13:48] <Lachy> or center align the other links for blog, etc.
  795. # [13:49] <annevk> that's great
  796. # [13:49] <annevk> though'd put it as the last slide
  797. # [13:50] <Lachy> ok
  798. # [13:54] * Joins: sverrej (n=sverrej@pat-tdc.opera.com)
  799. # [13:56] <hsivonen> hmm. WAI really like to use "Best Practices" instead of "Guide" or "Primer"
  800. # [13:59] <Lachy> those changes have been made and are uploading now. if anyone finds any more problems with the slides, email me and I'll try and fix them tonight or tomorrow morning.
  801. # [13:59] <Lachy> gotta go. bye
  802. # [14:00] * Quits: Lachy (n=Lachlan@85.196.122.246) ("Leaving")
  803. # [14:02] <gsnedders> annevk: is there any way to get something like responseHTML?
  804. # [14:04] <annevk> it's called responseXML
  805. # [14:05] <gsnedders> annevk: Without using XML? :P
  806. # [14:05] <annevk> responseXML is a misnomer for responseDocument
  807. # [14:05] <gsnedders> what does IE do if it gets something for XHR that's app/xhtml+xml?
  808. # [14:06] <annevk> I forgot
  809. # [14:06] * Quits: aaronlev_ (n=chatzill@g226139154.adsl.alicedsl.de) ("ChatZilla 0.9.82.1 [Firefox 3.0/2008051206]")
  810. # [14:06] <gsnedders> annevk: See, I'm trying to work from XHR1 — that makes it clear that responseXML is XML :P
  811. # [14:08] * Quits: MikeSmith (n=MikeSmit@EM60-254-222-10.pool.e-mobile.ne.jp) ("Less talk, more pimp walk.")
  812. # [14:08] <gsnedders> bbiab
  813. # [14:08] * Quits: gsnedders (n=gsnedder@host217-44-35-200.range217-44.btcentralplus.com) ("Partying in teh intarwebs")
  814. # [14:11] * Joins: MikeSmith (n=MikeSmit@58.157.21.205)
  815. # [14:12] <Hixie> ah, our platform is so quirky
  816. # [14:12] <Hixie> responseXML contains HTML, innerHTML contains XML...
  817. # [14:13] <annevk> and no vendor lock in
  818. # [14:13] <annevk> it's amazing that it survives
  819. # [14:14] <annevk> wait, in retrospect, that's contradictory :)
  820. # [14:18] <Hixie> the img-alt folder has risen to the top of the list of folders sorted by number of e-mails, ignoring folders that i am intentionally delaying handling of
  821. # [14:18] <Hixie> (e.g. wf2, rendering, aria)
  822. # [14:19] <Hixie> dom-focus is the next biggest non-delayed folder
  823. # [14:19] <Hixie> and that's mostly about tabindex and friends
  824. # [14:19] <Hixie> no idea what to do with that...
  825. # [14:20] <annevk> I thought there was a proposal for having some kind of focus model
  826. # [14:20] <Hixie> i guess i'll find out when i read the folder
  827. # [14:21] <annevk> Hixie, use 'set' for unordered and 'list' for ordered?
  828. # [14:21] * Hixie points at the topic
  829. # [14:21] <Hixie> :-P
  830. # [14:21] <hsivonen> Hixie: tabindex is considered part of the aria folder these days, isn't it?
  831. # [14:21] <Hixie> aria is about what you report to the AT, not what the non-AT-user sees
  832. # [14:22] <annevk> Hixie, meh, that's what Python does and it's quite understandable :)
  833. # [14:22] <Hixie> :-)
  834. # [14:23] * Joins: webben (n=benh@nat/yahoo/x-3fdd57a3bba978cf)
  835. # [14:24] <Hixie> actually it seems i've already resolved tabindex="" in the spec
  836. # [14:24] <Hixie> these comments are just minor editorial things, mostly
  837. # [14:24] <Hixie> or requests for new features
  838. # [14:26] <annevk> the e-mail I thought of is titled "Focus management" from May 2007
  839. # [14:29] <Hixie> yeah that's just new ideas and fixes
  840. # [14:30] <hsivonen> hmm. does one become an implementor by writing a Cocoa app that embeds WebKit?
  841. # [14:30] <Hixie> how to do notifications (toasts, bouncing the dock icon, etc) is also in this folder
  842. # [14:30] <Hixie> i wonder how to do that without opening it up to abuse
  843. # [14:31] <Hixie> hsivonen: if you just use it as a black box and write pages for it, you become an author and likely an unimportant one, since that's not an interop case)
  844. # [14:31] <annevk> hsivonen, yeah...
  845. # [14:31] <Hixie> hsivonen: if you write a browser with it, you become an implementor
  846. # [14:32] <Hixie> hsivonen: if you actually hack on webkit itself, you are an implementor.
  847. # [14:32] * annevk wonders if we're investing too much time discussing pointless e-mails
  848. # [14:33] <annevk> probably not
  849. # [14:35] * Joins: roc (n=roc@121-72-170-39.dsl.telstraclear.net)
  850. # [14:38] <Hixie> stress relief :-)
  851. # [14:38] <Hixie> ok bed time
  852. # [14:38] <Hixie> nn
  853. # [14:38] <hsivonen> nn
  854. # [14:46] <annevk> g'night
  855. # [14:49] * Philip` sees http://lists.w3.org/Archives/Public/public-html-diffs/
  856. # [14:49] <hsivonen> who is "TZ" in http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJun/0057.html ?
  857. # [14:50] * Philip` assumes it's a bad list to subscribe to, if it's going to get ~2.5MB diff-marked emails for every commit
  858. # [14:51] <hsivonen> the minuted claims about Gecko's parsing behavior don't look right
  859. # [14:52] <annevk> Tony Zlatinski I think
  860. # [14:53] <annevk> (samsung)
  861. # [14:53] <hsivonen> annevk: thanks
  862. # [14:55] <MikeSmith> Philip`: about the diffs list, yeah, you probably would not want to subscribe to thaat
  863. # [14:55] <MikeSmith> but it may be moot
  864. # [14:55] <MikeSmith> for the time being at least
  865. # [14:55] <roc> hum
  866. # [14:56] <MikeSmith> because I've not actually been able to deliver to it
  867. # [14:56] <roc> what Opera developer is in favour of switching to XML parsing in the middle of an HTML document
  868. # [14:56] <MikeSmith> not able to deliver the diffs to it (because I'm running into delivery issues with the W3C mail server)
  869. # [14:56] * Joins: gsnedders_mibbit (i=d92c23c8@gateway/web/ajax/mibbit.com/x-93a811e28d958307)
  870. # [14:56] <Philip`> Do they also want to switch back to an HTML parser for doing inline HTML in SVG?
  871. # [14:57] <roc> I can tell you for sure that we do not switch between our HTML parser and our XML parser
  872. # [14:58] <annevk> I think their idea is having something like the <style> or <script> element for XML
  873. # [14:59] * Joins: myakura (n=myakura@p5047-ipbf1403marunouchi.tokyo.ocn.ne.jp)
  874. # [14:59] <Philip`> Like IE's <xml>?
  875. # [15:00] <annevk> I guess so, yes
  876. # [15:01] <gsnedders_mibbit> they've sent anything yet?
  877. # [15:01] <annevk> I believe the aforementioned Tony is tasked with writing a proposal
  878. # [15:01] * Philip` wonders how many of their concerns would be satisfied by using the spec's old SVG-in-HTML parsing behaviour, but with conformance requirements such that any conforming SVG-in-HTML is trivially copy-and-pasteable into well-formed XML
  879. # [15:01] <annevk> From their minutes, anyway
  880. # [15:02] <shepazu> Philip`: that was indeed my initial thought, and it's possible that that's a way forward
  881. # [15:04] <shepazu> Philip`: but that's a rather big long road to walk (with roadblocks and minefields), and while it's worth looking into, a certain time pressure's been put on the SVG WG (the looming threat of "well, if they don't propose something soon, we'll put this back in")
  882. # [15:05] <roc> oh boy
  883. # [15:06] <Philip`> shepazu: XML-style error handling seems likely to face far more roadblocks and minefields than tightening the conformance requirements would
  884. # [15:06] <shepazu> note that that's not why we're looking at this alternative... Samsung has direct implementation experience that we're drawing from
  885. # [15:06] <roc> just propose something and the whatwgistas will debug it for you
  886. # [15:07] <shepazu> roc, I've been proposing something for months, and that's not the case.... it's met with unreasonable resistence
  887. # [15:07] <shepazu> resistance
  888. # [15:07] <annevk> well, iirc, it didn't meet the constraints: http://wiki.whatwg.org/wiki/Constraints_for_New_Vocabularies
  889. # [15:07] <shepazu> ... case in point.
  890. # [15:07] <annevk> anyway, back to merging xhr1 / xhr2
  891. # [15:08] <roc> shepazu: the constraints are unreasonable?
  892. # [15:09] * Quits: gsnedders_mibbit (i=d92c23c8@gateway/web/ajax/mibbit.com/x-93a811e28d958307) ("http://www.mibbit.com ajax IRC Client")
  893. # [15:09] <shepazu> roc: not necessarily, but the interpretation seems to be
  894. # [15:10] <shepazu> I don't see how my proposal fails any of those constraints
  895. # [15:10] <Philip`> shepazu: Do you have a link to your proposal?
  896. # [15:10] <roc> I'm not well enough informed to comment on the substance
  897. # [15:10] <roc> unfortunately
  898. # [15:11] <shepazu> http://wiki.whatwg.org/wiki/Extensions#Proposal_2:_Extensibility_Element
  899. # [15:12] <shepazu> Philip`: but the bit about adding an element is not necessary to the proposal (merely to allowing fallback content, which I also think is necessary)
  900. # [15:13] <Philip`> shepazu: That doesn't "Fail gracefully in the face of ignorant author copy/paste", because someone will copy-and-paste the <ext> into the top of their document and test it in a legacy UA and it will break nastily in <ext>-supporting UAs
  901. # [15:13] <shepazu> Philip`: explain how?
  902. # [15:14] * Philip` realises he didn't read the whole of the proposal
  903. # [15:16] <roc> interesting
  904. # [15:16] <Philip`> shepazu: How they would copy-and-paste it, or how it would break nastily?
  905. # [15:16] <shepazu> the latter
  906. # [15:17] <Philip`> Depending on how the error handling is defined, it would probably result in parts of the page disappearing (e.g. if the HTML content after an unclosed <ext><svg>... is misinterpreted as SVG)
  907. # [15:18] <shepazu> so, there are 2 parts to my proposal: one, the <ext> element (and the fallback element child), and the parsing aspects (which say, essentially, parse this in HTML5 but with XML constraints)
  908. # [15:18] * Joins: gsnedders (n=gsnedder@host217-44-35-200.range217-44.btcentralplus.com)
  909. # [15:18] <shepazu> Philip`: no, the parser should be able to handle that, just as it does overlapping elements, etc., in the current HTML5 spec
  910. # [15:18] * Philip` has to go for an hour
  911. # [15:19] <roc> I have to go to sleep
  912. # [15:19] <roc> but it seems like this wiki page is where energy should be focused
  913. # [15:19] <roc> for now
  914. # [15:20] <roc> regarding "Note also that the fallback idea doesn't work."
  915. # [15:23] <roc> the main danger seems to be that SVG script nodes would be executed by legacy UAs
  916. # [15:23] <shepazu> interesting
  917. # [15:23] <roc> which isn't that big a deal IMHO
  918. # [15:24] <shepazu> without an SVG context, most of those scripts would merely fail silently, no?
  919. # [15:24] <roc> probably
  920. # [15:24] <shepazu> still, worth noting
  921. # [15:24] <roc> but no approach to this problem is going to be able to avoid this
  922. # [15:24] <shepazu> right
  923. # [15:25] <shepazu> we want to concentrate the most effort on enabling good functionality, not recovering funky stuff
  924. # [15:25] <roc> some weird stuff might happen with <font> tags too
  925. # [15:25] <shepazu> though of course we have to consider failure cases, as well...
  926. # [15:25] <roc> but I think you should probably ditch the <fallback> idea since it's a bit leaky
  927. # [15:25] <roc> and it seems that resource constraints on speccing this out are an issue
  928. # [15:26] <shepazu> roc: I'd like to talk more when you have more time
  929. # [15:26] <shepazu> not sure what you mean by "leaky"
  930. # [15:26] <roc> I mean, no approach to this can be foolproof
  931. # [15:26] <roc> except, perhaps, putting all the SVG markup in an attribute
  932. # [15:27] <roc> which I do not recommend :-)
  933. # [15:27] <shepazu> heh
  934. # [15:27] * Joins: aaronlev (n=chatzill@g226139154.adsl.alicedsl.de)
  935. # [15:28] <annevk> <iframe doc=... type=text/xml></iframe> ...
  936. # [15:28] <roc> exactly
  937. # [15:28] <annevk> we might get that anyway btw for sandboxing
  938. # [15:28] <roc> right
  939. # [15:29] <roc> I don't think of that as a satisfactory solution here though :-)
  940. # [15:29] <annevk> agreed
  941. # [15:29] <roc> shepazu: in my ignorance, it seems to me that your proposal could be made to work, i.e. that Hixie's comments could be addressed
  942. # [15:30] <shepazu> roc: well, at least you admit that you're ignorant ;) humility is an important personal attribute :)
  943. # [15:30] <shepazu> jk
  944. # [15:30] <roc> as long as things are defined so that any malformed content, such an unexpected tag end, bails out of <ext> immediately
  945. # [15:30] <shepazu> roc: that was my intent
  946. # [15:30] <roc> you're absolutely right :-)
  947. # [15:31] <shepazu> :)
  948. # [15:32] <roc> so one comment that would really help to address is "What elements/attributes are known?"
  949. # [15:32] * Joins: hdh (n=hdh@118.71.125.176)
  950. # [15:32] <roc> and probably "What are you considering an error in tree construction?"
  951. # [15:32] <roc> since for example
  952. # [15:32] <roc> given <p>foo bar <ext>baz qux <p>foo bar
  953. # [15:33] <roc> it would be good to bail out of <ext> when we hit the next <p>
  954. # [15:33] <roc> I should also point out that implementing full-on XML parsing inside the HTML parser could be painful, despite what TZ may think
  955. # [15:34] <roc> /could be/would be/
  956. # [15:34] <annevk> this bailing out would require reparsing in some way to not lose content
  957. # [15:35] <roc> in which case?
  958. # [15:35] <annevk> that's probably not acceptable
  959. # [15:35] <annevk> but it's not really clear to me how the XML parsing works
  960. # [15:36] <annevk> (when nested inside text/html)
  961. # [15:36] <annevk> say you have <p><ext>X</p><p>Y</p>
  962. # [15:36] <annevk> what would happen?
  963. # [15:37] <roc> I would leave <ext> at the </p>
  964. # [15:37] <roc> the XML parser would parse "X" as a DOM text node
  965. # [15:37] <roc> then you would leave <ext> mode and parse </p> as HTML
  966. # [15:37] <roc> I guess retokenization would be necessary
  967. # [15:38] <roc> but this is the discussion that you and shepazu should be having, instead of the pistols at dawn impression I'm getting
  968. # [15:38] <annevk> <p><ext><x>...</p>
  969. # [15:38] <shepazu> probably
  970. # [15:38] <annevk> roc, heh
  971. # [15:39] <annevk> there's also issues with decoding, incorrect byte sequences, etc., incremental display
  972. # [15:39] <shepazu> roc: I believe I've been acting in good faith... this is something I've been asking for for a while
  973. # [15:39] <roc> I'm not accusing anyone of bad faith
  974. # [15:39] <annevk> someone putting <ext> at the start of a well-formed fragment and changing the semantics of all the elements it includes
  975. # [15:40] <shepazu> annevk: that's an interesting point
  976. # [15:40] <annevk> (elements might end up in the wrong namespae, <image> would no longer be treated as <img>, etc.)
  977. # [15:40] <roc> incremental display?
  978. # [15:40] <shepazu> roc: progressive rendering
  979. # [15:40] <shepazu> (I assume)
  980. # [15:41] * Joins: phsiao (n=shawn@c-71-233-78-251.hsd1.ma.comcast.net)
  981. # [15:41] <annevk> yeah, depending on specifics that could be affected
  982. # [15:41] <annevk> the fallback proposal is pretty badly for that
  983. # [15:41] <shepazu> annevk: it's possible, but not a necessity
  984. # [15:42] <shepazu> annevk: the fallback proposal wouldn't have any effect there
  985. # [15:42] <annevk> sure, it's not really clear to me what exactly the use cases are people envision with this
  986. # [15:42] <annevk> shepazu, i think it would
  987. # [15:42] <annevk> shepazu, document sitll downloading, you're displaying some XML, at the end you suddenly hit a parse error...
  988. # [15:43] <roc> I think the fallback proposal should be tossed over the side, it is a lot less important than the problem we're trying to solve here
  989. # [15:46] <shepazu> roc: as an author, I disagree that it's unimportant... there were many times I'd have liked to provide a PNG or text fallback if SVG wasn't supported
  990. # [15:46] <annevk> isn't the assumption that going forward all UAs support SVG natively?
  991. # [15:46] <roc> you can probably cobble together some <switch> and <img xmlns="..."> to get fallback that actually works
  992. # [15:47] <roc> and not only work in legacy UAs that don't support <ext>, but also in UAs that support <ext> but not SVG
  993. # [15:48] <annevk> that's seems like a rather odd case to optimize for imo
  994. # [15:49] <roc> I'm not saying we should optimize for it
  995. # [15:50] <roc> just commenting that it (probably) falls naturally out of shepazu's direction
  996. # [15:50] <shepazu> annevk: I'm not assuming that IE will support SVG (though it would be great if it did)... and in the meantime, I'd like for authors to use SVG with confidence that the user will see *something*
  997. # [15:51] <shepazu> roc: <switch> only works if the UA supports <switch>, which is a bad fallback assumption :)
  998. # [15:51] <annevk> for IE people can use some library that plugs into silverlight in the meantime
  999. # [15:51] <annevk> assuming IE will implement <ext> but not SVG also seems like an odd case to optimize for
  1000. # [15:51] <roc> optimizing for UAs that support <ext> and SVG but not <switch> seems like a very silly thing to do
  1001. # [15:51] <shepazu> annevk: the <ext> proposal doesn't assume that <ext> will be implemented... it works anyway
  1002. # [15:52] <roc> or even thinking about them for one second
  1003. # [15:52] <hsivonen> shepazu: <desc> can be used for fallback
  1004. # [15:54] <shepazu> hsivonen: that's not the intended use (it breaks the semantics), and it's not robust anyway
  1005. # [15:54] <shepazu> there can be many <desc> elements in a file
  1006. # [15:54] <shepazu> svg file
  1007. # [15:59] <annevk> yeah, <desc> is prolly best for that if needed
  1008. # [16:00] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) ("Verlassend")
  1009. # [16:01] <zcorpan> <svg><fallback><img>
  1010. # [16:01] * Quits: qwert666 (n=qwert666@acaj223.neoplus.adsl.tpnet.pl) ("Leaving")
  1011. # [16:03] <roc> so
  1012. # [16:03] <shepazu> zcorpan: that makes it a feature of SVG, not of HTML, and it would need to be added as a feature of every language that is intended to work in HTML (mathml, etc.)... and I don't think it solves any problems that <ext><fallback> doesn't
  1013. # [16:04] <roc> shepazu: your intent is that browsers would do strict XML conformance checking on the <ext> fragment, right?
  1014. # [16:05] <shepazu> roc: depends what you mean by "strict"
  1015. # [16:05] <shepazu> but generally, yes
  1016. # [16:05] <zcorpan> shepazu: right but fallback would be nice to have in xhtml too, not just text/html
  1017. # [16:05] <shepazu> zcorpan: I'd like <ext> to be added to XHTML, too
  1018. # [16:06] <zcorpan> shepazu: ah
  1019. # [16:06] <shepazu> roc, until such time as there is an infrastructure of parsers and toolchains that understand a looser parser for XML, which I think is likely
  1020. # [16:07] <shepazu> roc: it's a matter of deployment strategies, in part
  1021. # [16:07] <roc> wouldn't you consider that a disaster?
  1022. # [16:07] <shepazu> consider what a disaster?
  1023. # [16:09] <roc> loose XML parsing
  1024. # [16:09] <roc> anyway
  1025. # [16:09] <shepazu> if inkscape, and validators, and XML generators and parsers all had a looser parser that recovers particular validity and certain well-formedness "errors", and if it were widely deployed, I would be totally comfortable with having SVG use that syntax
  1026. # [16:10] <shepazu> just not as it stands
  1027. # [16:10] <roc> it seems that the biggest problem you're going to have is convincing people that browser should parse the <ext> fragment in strict XML syntax
  1028. # [16:10] <shepazu> yeah :)
  1029. # [16:11] <shepazu> well, not all people, just certain ones :)
  1030. # [16:11] * Joins: csarven (n=csarven@on-irc.csarven.ca)
  1031. # [16:11] <roc> it seems that your wiki proposal doesn't even mention that
  1032. # [16:11] <roc> directly
  1033. # [16:11] <shepazu> hmmm... yeah, maybe I assumed that, it had been my stance for a while and it was talked about on IRC... I'll add it
  1034. # [16:11] <shepazu> thanks
  1035. # [16:12] <roc> in fact it says "Inside you can use XML or another format. "
  1036. # [16:12] <hsivonen> shepazu: I wouldn't be too surprised if down the road Inkscape had an HTML5 parser
  1037. # [16:13] <annevk> parsers are cheap
  1038. # [16:13] <hsivonen> annevk: depends on how contorted they are
  1039. # [16:13] <roc> hsivonen: is that true?
  1040. # [16:13] <roc> :-)
  1041. # [16:14] <hsivonen> roc: parsers are not exactly cheap :-)
  1042. # [16:14] <roc> so until people agree on whether it's permissible or required to have strict XML parsing inside HTML, there's not much point in discussing <ext>
  1043. # [16:14] <roc> so I advise you to focus on that...
  1044. # [16:14] <roc> now I really have to sleep because North Americans are waking up and giving me work to do
  1045. # [16:14] <annevk> well, HTML parsers until now have been pretty expensive, but now that it is properly defined they're relatively cheap
  1046. # [16:15] <roc> I hope that's true
  1047. # [16:15] <annevk> roc, hah
  1048. # [16:15] <roc> we may not really know until a major browser implements HTML5 parsing
  1049. # [16:15] <annevk> (re: sleep/work)
  1050. # [16:15] <hsivonen> annevk: chances are that an HTML5 parser will be cheap for Inkscape
  1051. # [16:16] <hsivonen> annevk: however, for Mozilla not as cheap
  1052. # [16:17] <hsivonen> anyway, I think the SVG WG's copy-paste concern is much better solved by a serializer than by complicating parsing, in my opinion
  1053. # [16:18] <hsivonen> I think Hixie's solution is remarkably elegant and (relatively) low-impact on the parser
  1054. # [16:19] <gsnedders> annevk: I would throw a fatal error when <ext> doesn't start with an element
  1055. # [16:19] <gsnedders> I'd rather <ext> was special like <script>: the only thing that ended it was another <ext>
  1056. # [16:19] <annevk> hsivonen, true, if you have an existing HTML parser it might be relatively expensive on the short term
  1057. # [16:19] <gsnedders> This is why I really expect making <ext> CDATA easier
  1058. # [16:19] <gsnedders> <try> <except>? :P
  1059. # [16:19] <gsnedders> (And no, that isn't a serious suggestion)
  1060. # [16:19] <annevk> the first bit was?
  1061. # [16:21] * Quits: gsnedders (n=gsnedder@host217-44-35-200.range217-44.btcentralplus.com) ("Partying in teh intarwebs")
  1062. # [16:21] * Joins: gsnedders (n=gsnedder@host217-44-35-200.range217-44.btcentralplus.com)
  1063. # [16:23] * Joins: billmason (n=billmaso@ip66.unival.com)
  1064. # [16:24] <shepazu> http://www.securityfocus.com/bid/29386/exploit
  1065. # [16:31] <Philip`> shepazu: Hixie is concerned about cases like http://www.cocopahrv.com/map.html where extension elements like <svg> contain HTML elements that must still be treated as HTML elements by the error recovery system, which is a bit of a pain
  1066. # [16:31] * Quits: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net) ("The computer fell asleep")
  1067. # [16:32] * Joins: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net)
  1068. # [16:32] <Philip`> and I'm not sure how that could be handled correctly by only using abort-on-XML-ill-formedness (instead of abort-on-HTML-elements)
  1069. # [16:34] <Philip`> (particularly since people seem to dislike unwinding and reparsing upon detecting errors (like with unclosed <script> elements))
  1070. # [16:35] <Philip`> (It'd still be possible to do abort-on-XML-ill-formedness-and-on-HTML-elements and have that work, though)
  1071. # [16:38] <Philip`> (though if it was actual real XML-ill-formedness, that'd be irritating since it'd prevent copying output from SVG tools directly into HTML, because SVG tool output sometimes has crazy namespace doctype stuff and you couldn't copy the doctype into the HTML document)
  1072. # [16:39] <hsivonen> does the SVG WG have other stated issues with Hixie's approach except for copy-paste?
  1073. # [16:40] <annevk> prolly namespaces
  1074. # [16:40] <hsivonen> annevk: do you mean round-tripping Inkscape cruft?
  1075. # [16:40] * Joins: aroben (n=aroben@unaffiliated/aroben)
  1076. # [16:41] <annevk> yeah, or author created namespaces to work around the lack of data-
  1077. # [16:41] <Philip`> http://www.w3.org/Graphics/SVG/WG/wiki/SVG_in_text-html has various SVG WG comments, in case you haven't seen that
  1078. # [16:41] <Philip`> (Hmm, that page looks far less ugly now that I have appropriate fonts (Gill Sans?) installed)
  1079. # [16:42] <hsivonen> annevk: it seems to me that adding that feature to Hixie's design would be less disruptive than requiring an XML tokenizer mode
  1080. # [16:42] <hsivonen> "SVG should remain XML when inline in HTML." is not a use case
  1081. # [16:42] <hsivonen> as a requirement, it lacks rationale
  1082. # [16:43] <annevk> i suppose, it's not really clear to me at all, so far it's all rather vague and people seem very focused on specific solutions rather than what we actually need (likely on both sides)
  1083. # [16:43] <Philip`> We need to compete with VML-in-text/html
  1084. # [16:44] <hsivonen> "Should allow for unrestricted growth of the SVG language by the SVG specifications" having legacy restrictions comes with the text/html territory. that's tough, but that's the way it is
  1085. # [16:47] <Philip`> gsnedders: How do you parse the spec in 11 seconds? It seems to take me at least 17, and your computer shouldn't be 50% faster than mine :-(
  1086. # [16:47] <Philip`> (on the latest version of 'source')
  1087. # [16:48] * Quits: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net) (Connection timed out)
  1088. # [16:48] <hsivonen> I disagree with even more stuff under "Use Cases and Requirements Discussion"
  1089. # [16:48] <gsnedders> Philip`: I has leet computer.
  1090. # [16:49] <gsnedders> Philip`: I just run `python parse.py --no-html --profile --treebuilder=lxml ../../html5`
  1091. # [16:49] * gsnedders shrugs
  1092. # [16:51] <Philip`> gsnedders: Hmm, if I run that then it takes minutes and says "25.673 CPU seconds"
  1093. # [16:52] * hsivonen strongly disagrees with "Already used for SVG, so small cost of implementation " under "XML Parser"
  1094. # [16:53] * gsnedders tries time … to see if that agrees with the number of CPU seconds
  1095. # [16:55] <Philip`> (I'm using a C2D 2.0GHz, with frequency scaling locked at maximum, so it ought to be pretty hard to get 50% better single-threaded performance, unless it's just because my python is slow or something)
  1096. # [17:03] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  1097. # [17:07] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  1098. # [17:08] * Joins: webben_ (n=benh@nat/yahoo/x-078b692d125a3cb2)
  1099. # [17:10] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net) (Client Quit)
  1100. # [17:10] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Ex-Chat")
  1101. # [17:21] * Quits: webben (n=benh@nat/yahoo/x-3fdd57a3bba978cf) (Connection timed out)
  1102. # [17:24] * Joins: KevinMarks (n=KevinMar@65.sub-75-208-98.myvzw.com)
  1103. # [17:35] * Joins: smedero (n=smedero@mdp-nat251.mdp.com)
  1104. # [17:39] * Joins: lightyear (n=lightyea@nat/fluendo/x-a6a77e7ef022be74)
  1105. # [17:39] <lightyear> good evening everybody
  1106. # [17:40] <lightyear> who can I ask some questions about the python html5lib?
  1107. # [17:42] <Philip`> lightyear: It may be best to just ask the question here, and somebody will reply if they know the answer
  1108. # [17:43] <zcorpan> are the requirements on sizes='' testable?
  1109. # [17:43] <lightyear> k
  1110. # [17:44] <lightyear> I was wondering if there is any nice API to search something in a tree that I get from html5lib
  1111. # [17:44] <jgraham> lightyear: It depends which treebuilder you use
  1112. # [17:44] <jgraham> I suggest using lxml with python
  1113. # [17:44] <lightyear> like lets say, I want to have the element "html->body->div" with the attribute "class" set to ".my_class"
  1114. # [17:45] <jgraham> If you use lxml you can use xpath to express that constraint
  1115. # [17:45] <lightyear> I was using beautifulsoup before but that fails with a "maximum recursion depth exceeded" on my content
  1116. # [17:45] <lightyear> lxml... sounds good
  1117. # [17:45] <jgraham> like /html/body/div[@class='my_class' or something
  1118. # [17:46] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  1119. # [17:46] <jgraham> lightyear: Is the maximum recursion depth being exceeded only when you try to find stuff?
  1120. # [17:46] <lightyear> yeah... that sound pretty good
  1121. # [17:47] <lightyear> jgraham: no, when I try to parse it with the bsoup parser
  1122. # [17:47] <jgraham> lightyear: Oh, that may be a html5lib bug. Can you file an issue and attach a testcase for which that happens please
  1123. # [17:47] * Joins: eseidel (n=eseidel@c-67-171-36-188.hsd1.wa.comcast.net)
  1124. # [17:47] <Philip`> http://code.google.com/p/html5lib/issues/detail?id=59 ?
  1125. # [17:48] <lightyear> read this, so I guess it the problem...
  1126. # [17:48] <lightyear> but that one works here...
  1127. # [17:48] <jgraham> Philip`: Could be. I was secretly hoping people weren't hitting the issue. I guess I need to prioritize fixing it then
  1128. # [17:50] <jgraham> lightyear: It would be really useful to see a testcase if your issue is distinct from that one
  1129. # [17:50] <lightyear> I try to parse http://tvshack.net
  1130. # [17:50] <lightyear> the homepage
  1131. # [17:50] * Quits: eseidel (n=eseidel@c-67-171-36-188.hsd1.wa.comcast.net) (Read error: 104 (Connection reset by peer))
  1132. # [17:50] <hsivonen> I'm tempted to write a TreeBuilder subclass for the GWT DOM wrapper
  1133. # [17:51] * Joins: eseidel (n=eseidel@c-67-171-36-188.hsd1.wa.comcast.net)
  1134. # [17:51] <jgraham> On a differnt topic, has anything interesting happened in the last 3 days? The email subject lines on public-html don't look promising...
  1135. # [17:51] <jgraham> lightyear: Thanks
  1136. # [17:51] * Quits: eseidel (n=eseidel@c-67-171-36-188.hsd1.wa.comcast.net) (Client Quit)
  1137. # [17:51] <zcorpan> Hixie: was adding ruby now in response to robert burns in http://www.w3.org/2002/09/wbs/40318/wd-html5-may/results ? :)
  1138. # [17:52] <jgraham> (I guess Ruby is quite interesting)
  1139. # [17:53] <Philip`> "Date: 2008-05-26 03:12:10 -0700; [cit] (2) <ruby> support."
  1140. # [17:53] <Philip`> "Robert Burns: last responded on 26, May 2008 at 16:09 (UTC)"
  1141. # [17:54] <Philip`> zcorpan: Presumably it wasn't in response, since it was done six hours earlier :-)
  1142. # [17:54] <zcorpan> Philip`: ah, so good timing them :)
  1143. # [17:54] <zcorpan> then
  1144. # [17:54] <lightyear> jgraham: that is the way I can reproduce it everytime: http://pastebin.com/m4cd3b2be
  1145. # [17:54] <Philip`> jgraham: There was, uh, some discussion of alt
  1146. # [17:55] <jgraham> Philip`: That's why I said interesting ;)
  1147. # [17:55] <Philip`> jgraham: Also I made inputstream a bit faster, which may be handy
  1148. # [17:55] <jgraham> Philip`: Wow, cool.
  1149. # [17:56] <Philip`> (but the effect is only tens of percents, not orders of magnitude)
  1150. # [17:57] <hsivonen> GWT's JDK class library is much more limited than I thought :-(
  1151. # [17:58] <jgraham> Still, nice to have :) Did you consider pre-populating the regexp cache with common regexps? I guess that might not make much difference since you have to compile them at least once anyway
  1152. # [17:59] <Philip`> I'm not sure how that would help, since it would not decrease (and might increase) the number of regexp compilations, and anyway they take about zero time to compile
  1153. # [18:00] <jgraham> It would make excepting the try/except less common which afaik is relatively slow
  1154. # [18:01] * Joins: dbaron (n=dbaron@c-71-204-153-3.hsd1.ca.comcast.net)
  1155. # [18:02] <Philip`> There's only six regexps ever used (at least when parsing the spec), so that case seems pretty rare, although I wonder if precompiling ['A', 'B', ...] to /[A-Za-z]/ would make the regexp execution faster...
  1156. # [18:03] <takkaria> I imagine it would, assuming python uses the pcre library
  1157. # [18:03] * Quits: webben_ (n=benh@nat/yahoo/x-078b692d125a3cb2) (Read error: 113 (No route to host))
  1158. # [18:04] <Philip`> Um, it would help if the regexp cache didn't totally ignore 'opposite'
  1159. # [18:05] * Joins: Steve_f (n=chatzill@82-44-69-8.cable.ubr02.nmal.blueyonder.co.uk)
  1160. # [18:06] * Quits: myakura (n=myakura@p5047-ipbf1403marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  1161. # [18:07] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  1162. # [18:08] * Quits: KevinMarks (n=KevinMar@65.sub-75-208-98.myvzw.com) ("The computer fell asleep")
  1163. # [18:08] * Joins: myakura (n=myakura@p5047-ipbf1403marunouchi.tokyo.ocn.ne.jp)
  1164. # [18:09] <Philip`> Hmm, /[A-Za-z]/ makes no measurable difference according to my measurements
  1165. # [18:11] * Quits: sverrej (n=sverrej@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  1166. # [18:11] * Joins: jdandrea (n=jdandrea@ool-44c09c49.dyn.optonline.net)
  1167. # [18:13] <jgraham> takkaria: I think python has its own regexp engine
  1168. # [18:13] * Quits: aaronlev (n=chatzill@g226139154.adsl.alicedsl.de) (Read error: 110 (Connection timed out))
  1169. # [18:18] * Quits: myakura (n=myakura@p5047-ipbf1403marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  1170. # [18:18] <takkaria> evidence I should learn python, really, so I don't keep on giving out counterfactual advice
  1171. # [18:19] <hsivonen> Philip`: do you have experience with GWT?
  1172. # [18:22] <hsivonen> it seems that the Validator.nu parser is not quite ready for GWT use, but with a little refactoring it could become suitable for use inside the GWT
  1173. # [18:37] <Philip`> hsivonen: None at all
  1174. # [18:40] <hsivonen> ok
  1175. # [18:41] <hsivonen> it seems awesome in principle, but in practice it would be a lot more awesome if it supported a larger subset of the JDK class library
  1176. # [18:43] * Joins: hober (n=ted@unaffiliated/hober)
  1177. # [18:44] <Philip`> gsnedders: Oh, whoops, I'd limited my CPU to 1.67GHz a while ago when trying to avoid it overheating while upgrading Gentoo - it goes a bit faster when I remove that limit
  1178. # [18:47] <gsnedders> Philip`: That doesn't help.
  1179. # [18:51] <Philip`> Also it seems I can save ~10% in the tokeniser by improving the entity matcher
  1180. # [18:55] * Philip` commits that and wonders how much it really helps
  1181. # [18:57] <Philip`> Hmm, seems like around 7% in parsing the spec
  1182. # [18:58] <gsnedders> The only problem with trying with the spec is there are very few people who actually care about paring the spec.
  1183. # [18:58] <gsnedders> (or anything of the size)
  1184. # [18:58] <gsnedders> I mean, one of Hixie's requirements for the spec-gen was speed. "speed is the most important."
  1185. # [18:59] <gsnedders> Philip`: It seems to have regressed here
  1186. # [18:59] <gsnedders> Philip`: 12.5s ow
  1187. # [18:59] <gsnedders> *now
  1188. # [18:59] <Philip`> It's not particularly non-representative of all HTML content, and the performance should be proportional to shorter documents
  1189. # [18:59] <Philip`> gsnedders: Oh. That's not good
  1190. # [18:59] <Philip`> Does it give the same result when you run multiple times?
  1191. # [19:00] * gsnedders is just trying a second time
  1192. # [19:00] * Joins: KevinMarks (n=KevinMar@72-254-28-90.client.stsn.net)
  1193. # [19:00] <gsnedders> Back down to 11s
  1194. # [19:00] * gsnedders shrugs
  1195. # [19:00] <gsnedders> Probably just CPU throttling
  1196. # [19:00] <Philip`> Ah
  1197. # [19:00] <Philip`> That's why I disable the frequency scaling :-)
  1198. # [19:01] <Philip`> ('cpufreq-set -g performance' etc)
  1199. # [19:01] <gsnedders> On what? A laptop?
  1200. # [19:01] <Philip`> Yes
  1201. # [19:01] * gsnedders cares too much about battery life :)
  1202. # [19:01] <gsnedders> My next laptop (that I'll probably get end of next summer) will be specifically bought for its battery life
  1203. # [19:02] <Philip`> That's why I only disable the frequency scaling temporarily while doing performance testing, and also have the AC power plugged in all the time :-)
  1204. # [19:02] <gsnedders> I'm lazy :)
  1205. # [19:02] <Philip`> (It resets automatically from 'performance' to 'ondemand' whenever I suspend the machine, so it doesn't matter if I forget)
  1206. # [19:03] <Philip`> (Oops, no, I think it resets whenever I put the AC adapter in/out)
  1207. # [19:04] <Philip`> (since that's what /etc/acpi/actions/ac_adapter.sh is set to do)
  1208. # [19:04] * Quits: zcorpan (n=zcorpan@pat.se.opera.com) (Read error: 60 (Operation timed out))
  1209. # [19:04] * Quits: Steve_f (n=chatzill@82-44-69-8.cable.ubr02.nmal.blueyonder.co.uk) ("ChatZilla 0.9.82.1 [Firefox 3.0b5/2008032620]")
  1210. # [19:06] <Philip`> gsnedders: Is battery life now considered more valuable than a 17" screen?
  1211. # [19:06] <gsnedders> Philip`: Certainly.
  1212. # [19:07] <gsnedders> If I was to buy one now, I'd likely get the Dell XPS M1330
  1213. # [19:11] * Joins: eseidel (n=eseidel@72.14.227.1)
  1214. # [19:12] * Quits: eseidel (n=eseidel@72.14.227.1) (Client Quit)
  1215. # [19:20] * gsnedders stares
  1216. # [19:20] * Joins: weinig (n=weinig@17.203.15.182)
  1217. # [19:20] <gsnedders> Mail.app is at 784MB RAM usage
  1218. # [19:20] <gsnedders> and increasing at 1MB/s
  1219. # [19:26] * Joins: weinig_ (n=weinig@17.255.103.92)
  1220. # [19:26] * Joins: eseidel (n=eseidel@72.14.227.1)
  1221. # [19:27] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  1222. # [19:32] * Quits: dbaron (n=dbaron@c-71-204-153-3.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  1223. # [19:32] * Quits: gsnedders (n=gsnedder@host217-44-35-200.range217-44.btcentralplus.com)
  1224. # [19:34] * Quits: phsiao (n=shawn@c-71-233-78-251.hsd1.ma.comcast.net)
  1225. # [19:34] * Joins: weinig__ (n=weinig@nat/apple/x-915c7896caa43fe4)
  1226. # [19:40] * Quits: KevinMarks (n=KevinMar@72-254-28-90.client.stsn.net) ("The computer fell asleep")
  1227. # [19:40] * Quits: aroben (n=aroben@unaffiliated/aroben) ("Leaving")
  1228. # [19:41] * Joins: aroben (n=aroben@c-71-58-57-150.hsd1.pa.comcast.net)
  1229. # [19:42] * Quits: weinig (n=weinig@17.203.15.182) (Read error: 110 (Connection timed out))
  1230. # [19:49] * Quits: weinig_ (n=weinig@17.255.103.92) (Read error: 110 (Connection timed out))
  1231. # [19:50] <zcorpan_> btw, has something interesting happened in this space since friday?
  1232. # [19:50] * zcorpan_ hasn't been around
  1233. # [19:51] <Dashiva> Yes
  1234. # [19:51] <Dashiva> Log reading recommended
  1235. # [19:52] <zcorpan_> Dashiva: can you summarize? :P
  1236. # [19:52] <Dashiva> If I could, I would :)
  1237. # [19:53] <zcorpan_> then i'm going to assume that nothing interesting happened and do other things :)
  1238. # [19:53] * Quits: weinig__ (n=weinig@nat/apple/x-915c7896caa43fe4) (Read error: 104 (Connection reset by peer))
  1239. # [19:53] * Joins: weinig (n=weinig@nat/apple/x-125cca75b2f396a4)
  1240. # [19:54] * Joins: phsiao (n=shawn@nat/ibm/x-129616cde7132234)
  1241. # [19:54] <Dashiva> There was some constructive talk on @alt, for one.
  1242. # [19:55] <zcorpan_> that's cool
  1243. # [19:55] <zcorpan_> although i think i should try to ignore alt discussions altogether
  1244. # [19:55] <Dashiva> Commentary on the SVG group's plans to use XML for SVG in HTML
  1245. # [19:56] <zcorpan_> oh that might be interesting
  1246. # [19:56] <Dashiva> A little ruby here and there. Feedback on Lachy's upcoming slideshow.
  1247. # [19:57] <zcorpan_> k
  1248. # [19:57] <zcorpan_> thanks
  1249. # [19:58] * Parts: lightyear (n=lightyea@nat/fluendo/x-a6a77e7ef022be74)
  1250. # [20:01] * Joins: csarven- (n=csarven@on-irc.csarven.ca)
  1251. # [20:01] <hober> I think I missed the constructive @alt discussion... it got completely drowned in the, err, other parts of the @alt threads
  1252. # [20:01] * Quits: csarven (n=csarven@on-irc.csarven.ca) (Read error: 110 (Connection timed out))
  1253. # [20:02] * aroben is now known as aroben|meeting
  1254. # [20:02] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
  1255. # [20:03] <takkaria> there were a good five or six posts which advanced the discussion
  1256. # [20:03] <takkaria> I still don't see it ever being resolved though
  1257. # [20:11] * Joins: wakaba (n=w@171.163.210.220.dy.bbexcite.jp)
  1258. # [20:13] * Joins: wakaba__ (n=w@58.164.210.220.dy.bbexcite.jp)
  1259. # [20:14] * Joins: wakaba___ (n=w@3.164.210.220.dy.bbexcite.jp)
  1260. # [20:21] * Joins: gsnedders (n=gsnedder@host217-44-35-200.range217-44.btcentralplus.com)
  1261. # [20:22] <gsnedders> I need to blog something before this month ends
  1262. # [20:27] * Joins: qwert666 (n=qwert666@acaj223.neoplus.adsl.tpnet.pl)
  1263. # [20:28] * csarven- is now known as csarven
  1264. # [20:29] * Quits: wakaba_ (n=w@135.137.148.210.dy.bbexcite.jp) (Read error: 110 (Connection timed out))
  1265. # [20:30] * Parts: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  1266. # [20:32] * Quits: wakaba (n=w@171.163.210.220.dy.bbexcite.jp) (Read error: 110 (Connection timed out))
  1267. # [20:32] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  1268. # [20:33] * Quits: wakaba__ (n=w@58.164.210.220.dy.bbexcite.jp) (Read error: 113 (No route to host))
  1269. # [20:34] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  1270. # [20:34] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
  1271. # [20:42] <takkaria> heh, a whole string of proposals from RB have just hit the issue tracker
  1272. # [20:43] <hsivonen> takkaria: also http://www.w3.org/mid/AFB93528-A1CA-49EC-B342-5A8CD2B4080B@robburns.com
  1273. # [20:43] * Dashiva checks
  1274. # [20:43] <smedero> gregory rosmaita opened a few too.
  1275. # [20:44] <takkaria> smedero: he opened them for RB
  1276. # [20:44] <smedero> ahh, I see now
  1277. # [20:45] <takkaria> hsivonen: oh, lord, I wonder if the tag and xhtml2 know what they're in for
  1278. # [20:47] <Dashiva> "I, Robert - One man saw it coming."
  1279. # [20:50] <takkaria> I find the summaries and proposals RB puts forward thoroughly confusing
  1280. # [20:51] <takkaria> I'm never quite sure what he sets out to achieve because he never gives a real problem statement
  1281. # [20:52] <jgraham> Please someone make it stop
  1282. # [20:53] <Philip`> takkaria: The problems are that his proposed features are not supported
  1283. # [20:54] * takkaria grins
  1284. # [20:55] <Philip`> They're nice problems since they have an easy obvious solution (i.e. supporting the proposed features)
  1285. # [20:55] <takkaria> also, putting all these things on the wiki makes it very hard to discuss them
  1286. # [20:57] <Philip`> At least the wiki pages do give problem statements
  1287. # [21:01] <Philip`> Do Python profilers exist with timings per line/statement/etc rather than per method?
  1288. # [21:02] * Quits: tndH (i=Rob@adsl-87-102-114-53.karoo.KCOM.COM) ("ChatZilla 0.9.82.1-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  1289. # [21:20] * Quits: weinig (n=weinig@nat/apple/x-125cca75b2f396a4) (Read error: 104 (Connection reset by peer))
  1290. # [21:20] * Joins: weinig (n=weinig@nat/apple/x-6f63af40e8aa083c)
  1291. # [21:21] * Quits: aroben|meeting (n=aroben@unaffiliated/aroben)
  1292. # [21:22] * Joins: aroben (n=aroben@unaffiliated/aroben)
  1293. # [21:26] * Quits: weinig (n=weinig@nat/apple/x-6f63af40e8aa083c)
  1294. # [21:27] <takkaria> the entry for ISSUE-49 on the wiki appears to contain parts of another proposal
  1295. # [21:29] * Quits: eseidel (n=eseidel@72.14.227.1)
  1296. # [21:35] * Joins: jruderman (n=jruderma@c-67-180-39-55.hsd1.ca.comcast.net)
  1297. # [21:37] <annevk> damn, he hijacked ISSUE-42
  1298. # [21:40] * Joins: aaronlev (n=chatzill@g226139154.adsl.alicedsl.de)
  1299. # [21:40] <gsnedders> The answer to the first question in the physics exam last week was (I hope) 42.
  1300. # [21:40] <gsnedders> Therefore, I now know the ultimate question!
  1301. # [21:41] <jmb> is it any good? :)
  1302. # [21:41] <takkaria> if it was on a physics paper, I doubt it
  1303. # [21:41] <gsnedders> It's quite long
  1304. # [21:42] <gsnedders> It's all about how far Q is from P, given a car breaking in the area to a complete rest with a given mass and initial speed, IIRC
  1305. # [21:42] <takkaria> mm, I miss physics
  1306. # [21:43] <gsnedders> I need to decide whether to do phys at uni
  1307. # [21:44] <Philip`> Utilising the uncertainty principle, you could simultaneously do and also not do physics
  1308. # [21:44] <takkaria> but only if gsnedders was in a quantum state and we weren't observing him :)
  1309. # [21:44] * gsnedders headdesks
  1310. # [21:45] <takkaria> as soon as we observed him he'd have done one or the other
  1311. # [21:45] <Philip`> As soon as we observe him, we just get entangled with him
  1312. # [21:45] <Philip`> so it's only a problem if somebody then observes us
  1313. # [21:45] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  1314. # [21:46] <takkaria> I ended up doing philosophy
  1315. # [21:46] <takkaria> don't do that
  1316. # [21:46] <Dashiva> ISSUE-50 (associate-attributions-citations-quotations-and-references)
  1317. # [21:46] * Dashiva winces
  1318. # [21:47] * Philip` avoids thinking about it
  1319. # [21:47] <gsnedders> takkaria: Don't worry, I wasn't planning on it
  1320. # [21:49] <Dashiva> takkaria: You'd have to make him completely oblivious to himself as well, since he's macroscopic enough to be his own observer
  1321. # [21:53] * Philip` wonders if calling somebody "macroscopic" could be considered an insult
  1322. # [21:59] <takkaria> hm, I'm going to reply to RB's use-cases for one of the issues
  1323. # [21:59] <takkaria> let's see how this goes
  1324. # [21:59] <Philip`> Uh oh
  1325. # [22:00] * Joins: weinig (n=weinig@nat/apple/x-e94a1dab9cc706d9)
  1326. # [22:04] * Joins: eseidel (n=eseidel@72.14.227.1)
  1327. # [22:05] * Quits: aaronlev (n=chatzill@g226139154.adsl.alicedsl.de) (Remote closed the connection)
  1328. # [22:05] <annevk> interesting, the TAG starts talking about solving real problems
  1329. # [22:06] <annevk> that could be a slippery slope for them :D
  1330. # [22:07] <takkaria> where?
  1331. # [22:07] * takkaria runs to look
  1332. # [22:08] * Quits: eseidel (n=eseidel@72.14.227.1) (Client Quit)
  1333. # [22:10] * Quits: csarven (n=csarven@on-irc.csarven.ca) (Read error: 110 (Connection timed out))
  1334. # [22:12] * Quits: weinig (n=weinig@nat/apple/x-e94a1dab9cc706d9) (Read error: 104 (Connection reset by peer))
  1335. # [22:13] * Joins: weinig (n=weinig@nat/apple/x-a2b99feef1b7ac2d)
  1336. # [22:13] <annevk> http://www.pacificspirit.com/blog/2008/05/28/xri_solves_what_real_problems is one thing (linked from www-tag)
  1337. # [22:16] * Joins: aaronlev (n=chatzill@g226139154.adsl.alicedsl.de)
  1338. # [22:20] * Quits: roc (n=roc@121-72-170-39.dsl.telstraclear.net)
  1339. # [22:21] <takkaria> well, that's sent. probably the worst decision I've ever made to reply to that, but there we go
  1340. # [22:23] <annevk> you mean so far?
  1341. # [22:23] <Dashiva> Your sacrifice will not be forgotten
  1342. # [22:23] <annevk> :p
  1343. # [22:24] <annevk> takkaria, btw, non-hierarchy use case is the bible iirc
  1344. # [22:25] <takkaria> oh?
  1345. # [22:25] <Dashiva> the reason why
  1346. # [22:25] <Dashiva> they want to why they want to
  1347. # [22:25] <Dashiva> Isn't the bible very hierarchical?
  1348. # [22:25] <takkaria> I edit my own mail, did you know?
  1349. # [22:25] <takkaria> I still think it's nuts to try and put non-hierarchical data in a hierarchical data format, regardless of use-cases
  1350. # [22:26] <takkaria> it's like wanting to embed binary video data in an Atom feed
  1351. # [22:26] <annevk> Dashiva, I remember being explained it overlapping things
  1352. # [22:26] <Dashiva> I'd think hyperlinks would handle that
  1353. # [22:26] <annevk> I haven't looked into a bible in a while
  1354. # [22:29] <smedero> http://lists.w3.org/Archives/Public/public-html/2008May/0690.html
  1355. # [22:30] <smedero> he's a busy man today
  1356. # [22:31] <annevk> fortunately e-mail clients have filters
  1357. # [22:32] <annevk> he prepared this stuff sometime in advance (see html4all archives)
  1358. # [22:33] <Dashiva> What on earth is IDENT supposed to do?
  1359. # [22:35] <Dashiva> It looks like class v2
  1360. # [22:35] <takkaria> will he stop bloody pretending that wikis are good places to propose things?
  1361. # [22:36] <Dashiva> You should tell him so, if you feel strongly about it
  1362. # [22:36] <annevk> Dashiva, I thought it would be some DTD thing, but I can't find it
  1363. # [22:36] <Dashiva> The wiki page says it would only need to be unique within siblings
  1364. # [22:36] <takkaria> Dashiva: I already have
  1365. # [22:36] <Dashiva> So like some kind of local subtree id... but that removes the whole purpose of having a _unique_ value
  1366. # [22:37] <annevk> Dashiva, seems best to not invest much time in this
  1367. # [22:37] * Quits: jruderman (n=jruderma@c-67-180-39-55.hsd1.ca.comcast.net)
  1368. # [22:38] <Dashiva> Well, some time at least. Wouldn't want to dismiss him only because of precedent :)
  1369. # [22:40] <takkaria> you say that, but...
  1370. # [22:43] <takkaria> I can imagine that few people reply to any/most of his points and then he complains in six months time that the editor hasn't done what he said
  1371. # [22:44] <takkaria> anyway, this isn't productive, bbl
  1372. # [22:44] <annevk> that's ok, it's not possible to do what everyone wants it seems
  1373. # [22:48] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  1374. # [22:48] <takkaria> I lied about being back later
  1375. # [22:48] <takkaria> the idea of providing a mechanism for describing the semantics of styling is amazing
  1376. # [22:54] * Quits: weinig (n=weinig@nat/apple/x-a2b99feef1b7ac2d) (Read error: 104 (Connection reset by peer))
  1377. # [22:54] * Joins: weinig (n=weinig@nat/apple/x-dc3839096b53a537)
  1378. # [22:54] <Dashiva> Maybe there should be a dogfood requirement for proposals
  1379. # [22:54] <Dashiva> E.g. if you want a new attribute, you have to use that attribute yourself for 6 months first
  1380. # [22:55] * Joins: sverrej (n=sverrej@89.10.27.86)
  1381. # [22:57] * Joins: virtuelv (n=virtuelv@46.80-203-100.nextgentel.com)
  1382. # [23:00] * Joins: weinig_ (n=weinig@nat/apple/x-fe396bf2ca17b46b)
  1383. # [23:00] * Quits: weinig (n=weinig@nat/apple/x-dc3839096b53a537) (Read error: 104 (Connection reset by peer))
  1384. # [23:03] * Joins: jruderman (n=jruderma@guest-226.mountainview.mozilla.com)
  1385. # [23:05] * Joins: csarven (n=csarven@on-irc.csarven.ca)
  1386. # [23:05] <Hixie> woot, my VP is publicly pimping HTML5: http://www.techcrunch.com/2008/05/28/live-from-google-io/
  1387. # [23:06] <Dashiva> Hixie: I think RB means "page authors" when he says implementors
  1388. # [23:06] <Hixie> well then he's misusing the word
  1389. # [23:06] <Dashiva> Specifically "me"
  1390. # [23:07] <csarven> Is there a way to mix multiple encodings in the same document? e.g., Document being UTF-8 and a component in ISO58859-1
  1391. # [23:07] <Hixie> i'm not ignoring rob burns
  1392. # [23:07] <Hixie> heck i even have a special filter set up to prioritise his e-mails!
  1393. # [23:07] <Hixie> it marks them AAA-Productivity!
  1394. # [23:07] <Hixie> what more can he possibly want
  1395. # [23:08] <csarven> *ISO8859-1
  1396. # [23:08] <Dashiva> I can't seem to find that folder in /issues/, Hixie :)
  1397. # [23:09] <Philip`> csarven: There isn't
  1398. # [23:09] <Hixie> it's a prioritisation level that happens before sorting feedback into feedback issue folders
  1399. # [23:10] <csarven> Philip` Thanks
  1400. # [23:10] <Philip`> csarven: Convert everything to UTF-8 on the server, and then the world will be happy :-)
  1401. # [23:11] <csarven> That's almost the case but there is a 3rd party component which is in iso8859-1 :S
  1402. # [23:11] <Philip`> Can't you add some kind of filter to translate that component's output?
  1403. # [23:12] <Dashiva> What kind of component? iframe? json?
  1404. # [23:12] <csarven> I probably could
  1405. # [23:12] <csarven> Just an external JavaScript
  1406. # [23:12] <annevk> Hixie, WHATWG was also pimped on the google blog
  1407. # [23:12] <annevk> well, mentioned
  1408. # [23:13] <Hixie> oh?
  1409. # [23:13] <Philip`> csarven: As in <script src="some-iso-8859-1-file.js"></script>?
  1410. # [23:13] <Hixie> oh today you mean
  1411. # [23:13] <csarven> Yes
  1412. # [23:13] <Hixie> yes
  1413. # [23:14] <annevk> http://googleblog.blogspot.com/2008/05/happy-birthday-google-gears.html
  1414. # [23:14] <Hixie> yeah
  1415. # [23:14] <Hixie> that was today :-)
  1416. # [23:14] <Hixie> part of the same push, i imagine
  1417. # [23:14] <Philip`> csarven: I guess <script src="..." charset="iso-8859-1"></script> might work for that
  1418. # [23:14] <Hixie> as in, part of the Google I/O stuff
  1419. # [23:14] <annevk> i see
  1420. # [23:15] <csarven> Philip` More like <script>document.write("<script>..)</script>
  1421. # [23:15] <annevk> you there as well?
  1422. # [23:15] <Hixie> nah
  1423. # [23:15] <annevk> seems that Chris Wilson is around
  1424. # [23:15] <annevk> (from twitter)
  1425. # [23:15] <Hixie> Gears had several announcements today, though, and so it makes sense they'd mention HTML5 in that context
  1426. # [23:15] <Philip`> csarven: Hmm, I'm not entirely certain what the problematic situation is
  1427. # [23:19] <csarven> Philip` http://www.lebelage.ca/argent_et_droits/vos_droits/ -- Contest links, bottom right
  1428. # [23:19] * Joins: roc (n=roc@202.0.36.64)
  1429. # [23:20] * gsnedders is trying to write the exact kind of email he hates writing
  1430. # [23:21] <Hixie> in the latest tag minutes tbl says ignoring rdf for html5 is unacceptable
  1431. # [23:21] <Hixie> http://www.w3.org/mid/m2ej7mwhed.fsf@nwalsh.com
  1432. # [23:22] * Hixie looks forward to saying that technologies have to prove themselves _before_ html5's design is warped to handle them
  1433. # [23:22] <Hixie> aha, there's the google alert for the google blog mentioning whatwg :-)
  1434. # [23:25] <Philip`> csarven: Ah - are you allowed to change it to <script>document.write("<script charset='iso-8859-1' ... ?
  1435. # [23:25] * Philip` doesn't actually have any idea whether browsers respect <script charset>
  1436. # [23:26] <Hixie> they do
  1437. # [23:27] <Philip`> Does it take precedence over Content-Type charset?
  1438. # [23:28] <roc> hmm
  1439. # [23:28] <Hixie> it does whatever the spec says, roughly
  1440. # [23:28] <Hixie> though brosers differ in various complicated ways
  1441. # [23:29] * gsnedders wonders whether the HTTP of "HTTP/1.1" needs to be case-insensitive
  1442. # [23:30] <gsnedders> In everything except CFNetwork (WebKit/OS X) and HTTP.sys (IIS) it is
  1443. # [23:30] <Philip`> Ah, I missed the part of the spec where it said what to do with charset
  1444. # [23:30] <csarven> Philip` Hixie Yes, it works! :)
  1445. # [23:31] <roc> shepazu: you arond?
  1446. # [23:31] <Hixie> gsnedders: is it really case insensitive? or is it ignored?
  1447. # [23:32] <gsnedders> Hixie: case-insensitive
  1448. # [23:32] <csarven> Although, I don't know how stable that is cross-browsres as Hixie says
  1449. # [23:32] <gsnedders> Hixie: I think, from what I can see
  1450. # [23:32] <gsnedders> Hixie: In Fx it is certainly
  1451. # [23:33] <annevk> I thought you could also omit it
  1452. # [23:33] <gsnedders> annevk: In what? Responses? Only if you're HTTP/0.9, which isn't used any more, so is irrelevant
  1453. # [23:34] * gsnedders discovers for compat. you can't use HTTP/5.0 :(
  1454. # [23:35] <annevk> yeah, in the response
  1455. # [23:35] <Hixie> ...and that's why version numbers are bad. :-)
  1456. # [23:35] <gsnedders> HTTP/1.5 it'll have to be :P
  1457. # [23:35] <Philip`> How about "HTTP/1.<backspace><backspace>5.0"?
  1458. # [23:36] <gsnedders> Philip`: 400 Bad Request
  1459. # [23:36] <Philip`> Hmph
  1460. # [23:36] * gsnedders wonders
  1461. # [23:36] <annevk> do we need a new version number?
  1462. # [23:37] <annevk> don't browsers have rules when you omit it altogether?
  1463. # [23:37] <gsnedders> Should I keep non-strict parsers (which are meant to be used for responses) as close to RFC2616 as possible while still being useful in the real world, or just go for lax as hell?
  1464. # [23:38] <gsnedders> annevk: In Fx at least if it doesn't start with "HTTP/" it is treated as HTTP/0.9
  1465. # [23:38] <gsnedders> annevk: Which is to say that the entire response is the body
  1466. # [23:38] <annevk> gsnedders, what does "lax as hell" mean? compatible with the real world?
  1467. # [23:38] * Quits: othermaciej (n=mjs@adsl-70-137-131-51.dsl.snfc21.sbcglobal.net) (Read error: 110 (Connection timed out))
  1468. # [23:39] <annevk> gsnedders, I see, so we need HTTP/ as a flag at the start to indicate headers are part of the response?
  1469. # [23:39] <gsnedders> annevk: It doesn't throw any sort of error, even when the real world doesn't rely on it, and it isn't allowed as part of RFC2616
  1470. # [23:40] <gsnedders> annevk: Currently if you send something really odd to a non-strict parser you can get a fatal error (it really has to be really mucked up to get that to happen, though)
  1471. # [23:40] <annevk> gsnedders, does that happen with browsers?
  1472. # [23:41] <gsnedders> annevk: In some, yes
  1473. # [23:41] <annevk> if it has to be something really odd you might as well never get a fatal error...
  1474. # [23:42] * gsnedders wonders what causes it currently
  1475. # [23:44] <gsnedders> It's far easier to cause when you're dealing with a request and a strict parser.
  1476. # [23:45] <gsnedders> annevk: Basically the response line needs to be invalid at the start (i.e., the "HTTP/1.1 200" part)
  1477. # [23:46] <gsnedders> annevk: Or if it doesn't have a blank line before the body
  1478. # [23:46] <gsnedders> annevk: I think that's all that currently causes a fatal error in a non-strict response parser
  1479. # [23:47] <annevk> wow, http://www.builderau.com.au/program/html/soa/HTML-5-A-change-in-course-straight-for-the-iceberg/0,339028420,339289373,00.htm?feed=rss is quite confused
  1480. # [23:48] <takkaria> we need a crack PR team to get blog posts like that sorted out
  1481. # [23:51] * Quits: phsiao (n=shawn@nat/ibm/x-129616cde7132234)
  1482. # [23:51] <Hixie> annevk: that's old
  1483. # [23:52] <Hixie> annevk: came out in january
  1484. # [23:52] <Hixie> i do like the bit that says that html5 is a 15 year step backwards
  1485. # [23:52] <Hixie> that basically puts the web back at where it started
  1486. # [23:52] <Hixie> which would be impressive
  1487. # [23:52] <gsnedders> and HTTP/0.9!
  1488. # [23:52] <gsnedders> I mean, that didn't even have headers, or status codes :P
  1489. # [23:52] <annevk> Hixie, maybe they republished some content
  1490. # [23:53] <Hixie> yeah
  1491. # [23:54] * Quits: aaronlev (n=chatzill@g226139154.adsl.alicedsl.de) ("ChatZilla 0.9.82.1 [Firefox 3.0/2008051206]")
  1492. # Session Close: Thu May 29 00:00:00 2008

The end :)