/irc-logs / freenode / #whatwg / 2008-09-06 / end

Options:

  1. # Session Start: Sat Sep 06 00:00:00 2008
  2. # Session Ident: #whatwg
  3. # [00:01] * annevk added it to http://wiki.whatwg.org/wiki/Namespace_confusion
  4. # [00:09] * Quits: weinig (n=weinig@17.203.15.172) (Read error: 60 (Operation timed out))
  5. # [00:23] * aroben|meeting is now known as aroben
  6. # [00:25] <Hixie> we want to test implementations and not the concept
  7. # [00:26] <Hixie> because users interact with the implementations, not the concepts
  8. # [00:28] <Lachy> Hixie, yeah. But we should let them use the optimal implementation. If the beta of jaws 10 notifies the user by default as webben said, then that's fair enough
  9. # [00:29] <Lachy> making them use implementations they know to be flawed isn't likely to be accepted
  10. # [00:29] <webben> Hixie: Testing implementations is a worthwhile activity as long as one is clear about what that actually means.
  11. # [00:31] <Lachy> but I agree, modifying the implementation well beyond would be considered a typical setup to could bias the results too much, so there needs to be limits
  12. # [00:32] <webben> I suspect that radical implementations aren't necessary, but I'm not quite sure what other people's view of an optimal implementation would be.
  13. # [00:33] <Lachy> I would prefer it to be a near default setup, with additional options only set based on each users' normal configuration
  14. # [00:34] <webben> e.g. I think JAWS 10 Beta seems reasonable for a blind user (not sure about deafblind) and iCab 4.x seems reasonable for a mouse-wielding sighted fellow.
  15. # [00:34] <webben> the problem with JAWS 10 Beta is ... it's beta.
  16. # [00:34] <Lachy> how is iCab considered assistive technology?
  17. # [00:36] <webben> From my perspective, these are just tools and sets of tools users with various abilities use to consume content.
  18. # [00:36] <Lachy> but they need to be users for whom long descriptions are considered the most useful
  19. # [00:37] * Joins: weinig (n=weinig@nat/apple/x-37da19d947e68696)
  20. # [00:37] <webben> I don't think long descriptions are necessarily more useful to blind people than colorblind people etc.
  21. # [00:37] <Lachy> John's complaint is that since no-one uses longdesc on the web, and because it's a relatively new feature in ATs, most users don't know about it, nor query for it.
  22. # [00:38] <Lachy> While I see that as a fundamental flaw with its design, he seems to think there is hope for it
  23. # [00:39] <webben> longdesc (as opposed to long descriptions) is useful (well, in _theory_) to people navigating non-linearly or any other case where you might want automatic extraction
  24. # [00:40] <Lachy> but if the default configuration was to notify the user about its presence, then that could potentially fix one of the problems. But I'm still not sure how to fix the problem of authors not using it
  25. # [00:41] <webben> I think that's like trying to fix the problem of Flickr not using alt.
  26. # [00:41] <webben> Lachy: In so far as authors might _want_ to use it, they've repeatedly been given guidance not to use it because of broken implementations.
  27. # [00:42] <webben> I think that guidance was wrong (because facilitating programmatic association is helpful, I think).
  28. # [00:42] <webben> I also agree that providing links to things or including descriptions on the page is good.
  29. # [00:44] <Lachy> I'm just not convinced that longdesc has any advantages over ordinary links, and ordinary links have the benefit of being available to everyone
  30. # [00:46] <webben> Lachy: I'm quite interested, on behalf of _future_ user agents, in potential mechanisms to avoid redundancy during linear processing while still facilitating the automatic addition of context during non-linear processing.
  31. # [00:46] <webben> though I think link text is a much more important case for this than img/longdesc
  32. # [00:46] <Hixie> authors do use longdesc
  33. # [00:46] <Hixie> but they almost uniformly use it in harmful ways
  34. # [00:47] <webben> Hixie: I suspect if more implementations were like iCab there would have been less harmful use. Hard to prove though :)
  35. # [00:48] <webben> Hixie: It might be interesting to know why authors who did things wrong, did things wrong.
  36. # [00:49] <webben> the most confusing aspect of longdesc seems to be that it's a URI. I guess better naming might have helped there - descriptionref or something.
  37. # [00:50] <Lachy> what does iCab do exactly?
  38. # [00:51] <webben> Lachy: 1. If you hover over an img with longdesc it changes the cursor to a arrow with a little doc icon. (iCab uses cursor hints for various things.)
  39. # [00:54] <webben> 2. If you open the context menu on such an img, one of the options is Show long description of Image. If you click that, it opens the referenced URL in a new window. (not that keen on the new window as opposed to new tab business myself, but there we go)
  40. # [00:54] <webben> So it's roughly similar to (say) viewing an image in its own tab in Firefox.
  41. # [00:54] <Hixie> is the description more useful than just zooming the image and giving a high-contrast vie?
  42. # [00:54] <Hixie> view
  43. # [00:55] <webben> Hixie: I'd imagine that would depend on the image and the user.
  44. # [00:56] <Hixie> can you name a case where an author would create a description that was detailed enough that it was more useful than zooming the picture?
  45. # [00:57] <webben> well, where the picture isn't very good to start with would be one example.
  46. # [00:57] <webben> i'm not sure how good high-contrast conversions are.
  47. # [00:57] * Quits: smedero (n=smedero@mdp-nat251.mdp.com)
  48. # [00:57] <Hixie> wouldn't a description in such cases be better given inline for everyone to enjoy?
  49. # [00:57] <webben> i.e. how bad the information loss is
  50. # [00:58] <Hixie> seems to me that whenever an image could be described in detail, that the description becomes generally useful and should just be an integral part of the page, not hidden away in a dedicated attribute
  51. # [00:58] <Lachy> webben, I don't think low such quality images are a typical use case
  52. # [00:59] <webben> Hixie: dedicated attributes are an integral part of the page.
  53. # [00:59] <webben> Hixie: Where are the visible links to open images in their own tab? Or print them? Or download them? Or copy them to the clipboard?
  54. # [00:59] <Lachy> I agree with Hixie. I think it would be better to encourage authors to provide information about images designed for everyone, which has the effect of helping those who can't see the image well either
  55. # [00:59] <Hixie> webben: there's no markup for those either
  56. # [01:00] <webben> Hixie: Sure there is. It's called src.
  57. # [01:00] <Hixie> webben: well then linking to a description on another page is called <a href=""> and including a description inline is called <p>...</p>.
  58. # [01:01] <Lachy> sure, but src isn't meant to be human consumable information. The image is
  59. # [01:01] <webben> Lachy: likewise with the description.
  60. # [01:01] <Hixie> webben: basic language design -- accessibility should be inherent, people don't think about it and if you make it separate they will screw it up.
  61. # [01:01] <Hixie> anyway
  62. # [01:01] <Lachy> <a href="description"><img src="foo"></a>
  63. # [01:01] <Hixie> longdesc="" has been shown to be a lost cause
  64. # [01:02] <Hixie> unless new information comes along, there's no point arguing it
  65. # [01:03] <webben> Hixie: Well, yeah I just don't buy the "shown" bit. Can't really help that. :)
  66. # [01:03] <Hixie> have you read http://blog.whatwg.org/the-longdesc-lottery ?
  67. # [01:03] <webben> yeah
  68. # [01:03] <Hixie> well if you don't think that shows it's a lost cause, i don't know what to tell you
  69. # [01:04] <webben> Hixie: Yes, I don't see how you can separate the concept from the implementations and the guidance given.
  70. # [01:04] <webben> *how you can't, rather
  71. # [01:05] <Hixie> doesn't matter what the implementations do
  72. # [01:05] <Hixie> over 96% _of images with longdesc_ have bogus longdesc
  73. # [01:05] <webben> I think that statistic is heavily determined by the implementations and the guidance given.
  74. # [01:05] <Hixie> there is no implementation stategy that can turn crap into usable content
  75. # [01:06] <Hixie> that statistic is actual web content.
  76. # [01:06] <Hixie> doesn't matter what causes it
  77. # [01:06] <Hixie> it's already caused.
  78. # [01:06] <Hixie> we could argue about whether to introduce a _new_ attribute
  79. # [01:06] <Hixie> and maybe implementations could support that better and we could avoid this problem
  80. # [01:06] <webben> Hixie: Oh, yeah, when I'm talking about the "concept", I'm talking about the "concept".
  81. # [01:07] <Hixie> however, one has to wonder why it would take 10 years for implementations of longdesc="" to come along, if it's such a great idea
  82. # [01:07] <webben> Hixie: iCab's implementation has been around longer than that.
  83. # [01:07] <webben> it's not a recent innovation I mean
  84. # [01:07] <webben> what i'm not clear about is when JAWS didn't read longdesc by default and why
  85. # [01:08] <webben> looking at the manual when they introduced it, seems it originally was read by default
  86. # [01:08] <Lachy> It'll be interesting to see if anyone actually volunteers to carry out that study, or whether they're just going to continue saying the study is flawed and push for longdesc anyway
  87. # [01:08] <webben> then they stopped, and now they've started again
  88. # [01:08] * Quits: jruderman (n=jruderma@c-67-180-39-55.hsd1.ca.comcast.net)
  89. # [01:09] <Lachy> either way, I'm confident that the study would show that longdesc is useless regardless of the implementation used
  90. # [01:09] <Hixie> having seen blind users browse the web, i agree
  91. # [01:11] <webben> Hixie: fwiw looking at the lottery article again, looks like one could repair a lot of the longdesc attributes by (a) fixing Wikipedia and (b) not exposing a UI for certain machine-detectable cases where it's wrong.
  92. # [01:12] <webben> e.g. "not a valid url", "blank", 404
  93. # [01:15] <webben> Hixie: I suppose you'd also have to look at how much of the incorrect content is useful content anyways to get an idea of how much it would affect people.
  94. # [01:15] <webben> wikipedia is definitely useful content.
  95. # [01:15] <Hixie> even when you ignored those, the fraction of useful longdesc values was still below 1%
  96. # [01:15] <Hixie> (based on a hand inspection of the remaining pages)
  97. # [01:16] * Quits: Maurice (i=copyman@cc90688-a.emmen1.dr.home.nl) ("Disconnected...")
  98. # [01:17] <webben> Hixie: sorry, 1% of what?
  99. # [01:17] <webben> the article mentions a 1% figure, but that's of all longdescs in the sample.
  100. # [01:18] <Hixie> if you discard all pages that didn't have longdesc, then discard all pages that had mechanically-observably-bad longdesc, and then look at the remaining pages (a tiny fraction of the web) and examine the longdescs by hand, you find that it is still below 1% of _those_ that are actually useful.
  101. # [01:18] * Joins: othermaciej (n=mjs@17.203.15.156)
  102. # [01:18] <Hixie> we're talking about an insanely small fraction of the web here
  103. # [01:18] * Parts: annevk (n=annevk@77.163.243.203)
  104. # [01:19] <Hixie> certainly far below the nominal 80% that we normally target for features
  105. # [01:19] <othermaciej> hello all
  106. # [01:19] <webben> I may just be tired, but I can't reconcile that with the article's stats
  107. # [01:19] <Hixie> i don't think the article mentions the final step
  108. # [01:19] <Hixie> i didn't talk to mark about that iirc
  109. # [01:20] * Quits: dglazkov (n=dglazkov@nat/google/x-3cfb09f17972bae3)
  110. # [01:20] * Quits: eseidel (n=eseidel@nat/google/x-b179464eaa5fb79c)
  111. # [01:20] <webben> Hixie: is that sample still extant somewhere? could it still be documented?
  112. # [01:21] * Lachy remembers stargate is on tonight :-)
  113. # [01:22] <webben> it might actually change between now and HTML5 being finished actually.
  114. # [01:23] <webben> if Wikipedia got fixed and large sites started using it for programmatic associations to diagrams.
  115. # [01:23] <Hixie> webben: it was on the web somewhere, probably one of the files on junkyard.damowmow.com
  116. # [01:23] <Hixie> webben: it might be linked from the whatwg wiki
  117. # [01:26] <Philip`> http://wiki.whatwg.org/wiki/Longdesc_usage ?
  118. # [01:27] <Philip`> (That's not from Hixie's data set, but it's the only detailed manual analysis I remember being done)
  119. # [01:27] <Hixie> not the one i was thinking of, but that shows much the same result
  120. # [01:27] <Hixie> ok, gotta go, meeting
  121. # [01:28] <blooberry> Philip`: I've got some results that might be interesting there too.
  122. # [01:28] <webben> some of those are machine detectable and some I wouldn't regard as a problem
  123. # [01:31] * Joins: eseidel (n=eseidel@nat/google/x-b8056ce0aa541fd4)
  124. # [01:33] <takkaria> oo, I did that analysis
  125. # [01:33] <takkaria> always meant to do more
  126. # [01:34] <webben> takkaria: do you still have a link to it?
  127. # [01:35] <takkaria> that was the one Philip pointed at
  128. # [01:35] <Philip`> blooberry: Have you published any of the results so far?
  129. # [01:36] <webben> the problem with these numbers is they're very susceptible to changes in authoring practices from small codebases.
  130. # [01:36] <blooberry> philip`: Trying to get that done presently. Hoping to have it out soon. 8-}
  131. # [01:38] <takkaria> webben: yeah, well. Hixie gave me a larger sample which I need to investigate at some point
  132. # [01:39] <blooberry> Philip`: Would a summary be more interesting or the actual longdesc data?
  133. # [01:40] <Philip`> blooberry: I'm not interested in longdesc at all, so someone else might have a better idea of what'd be good :-)
  134. # [01:41] <blooberry> Philip`: ok. Good point. ;-}
  135. # [01:41] * blooberry reads back and notices where the confusion arose
  136. # [01:52] * Quits: hallvord (n=hallvord@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  137. # [01:54] * Quits: webben (n=benh@nat/yahoo/x-290a5a65554838be) (Read error: 110 (Connection timed out))
  138. # [01:58] * Joins: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  139. # [02:06] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  140. # [02:11] * Quits: blooberry (n=brian@c-76-126-196-253.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  141. # [02:12] * Joins: blooberry (n=brian@c-76-126-196-253.hsd1.ca.comcast.net)
  142. # [02:14] * Joins: hdh (n=hdh@118.71.120.84)
  143. # [02:20] * Joins: gsnedders (n=gsnedder@213.235.51.141)
  144. # [02:21] * Quits: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com) (Read error: 110 (Connection timed out))
  145. # [02:30] * Quits: eseidel (n=eseidel@nat/google/x-b8056ce0aa541fd4)
  146. # [02:31] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  147. # [02:33] * Philip` wonders whether a Jython program using Protocol Buffers should use the Java version of the library or the Python version
  148. # [02:35] * Quits: gsnedders (n=gsnedder@213.235.51.141)
  149. # [02:50] * Joins: othermaciej_ (n=mjs@17.244.17.16)
  150. # [02:52] * Quits: othermaciej (n=mjs@17.203.15.156)
  151. # [02:52] * othermaciej_ is now known as othermaciej
  152. # [03:03] * Quits: billmason (n=billmaso@ip75.unival.com) (".")
  153. # [03:04] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  154. # [03:10] * Quits: weinig (n=weinig@nat/apple/x-37da19d947e68696) (Read error: 104 (Connection reset by peer))
  155. # [03:19] * Joins: weinig (n=weinig@nat/apple/x-d951bc8a2662071d)
  156. # [03:35] * Joins: nessy (n=nessy@124-171-27-224.dyn.iinet.net.au)
  157. # [03:37] * Parts: blooberry (n=brian@c-76-126-196-253.hsd1.ca.comcast.net)
  158. # [03:45] * Joins: weinig_ (n=weinig@17.203.15.172)
  159. # [03:48] * Quits: weinig_ (n=weinig@17.203.15.172) (Client Quit)
  160. # [04:00] * Quits: weinig (n=weinig@nat/apple/x-d951bc8a2662071d) (Read error: 110 (Connection timed out))
  161. # [04:00] * Joins: aboodman2 (n=aboodman@216.239.45.19)
  162. # [04:02] * Quits: aboodman2 (n=aboodman@216.239.45.19) (Client Quit)
  163. # [04:04] * Quits: aboodman (n=aboodman@nat/google/x-33e7d9ef8f22a198) (Read error: 110 (Connection timed out))
  164. # [04:16] * Joins: jdandrea (n=jdandrea@ool-44c09d7b.dyn.optonline.net)
  165. # [04:17] * Joins: eseidel (n=eseidel@nat/google/x-6eb4932f498e524f)
  166. # [04:24] * Joins: dglazkov (n=dglazkov@c-24-130-116-76.hsd1.ca.comcast.net)
  167. # [04:24] * Quits: eseidel (n=eseidel@nat/google/x-6eb4932f498e524f)
  168. # [04:28] * Quits: jdandrea (n=jdandrea@ool-44c09d7b.dyn.optonline.net)
  169. # [04:37] * Joins: webben (n=benh@91.85.151.141)
  170. # [05:24] * Joins: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  171. # [05:31] * Joins: weinig (n=weinig@17.203.15.172)
  172. # [05:39] * Joins: kingryan (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net)
  173. # [05:59] * Quits: dglazkov (n=dglazkov@c-24-130-116-76.hsd1.ca.comcast.net)
  174. # [05:59] * Quits: othermaciej (n=mjs@17.244.17.16)
  175. # [06:00] * Joins: othermaciej (n=mjs@17.244.17.16)
  176. # [06:09] * Quits: weinig (n=weinig@17.203.15.172) (Read error: 104 (Connection reset by peer))
  177. # [06:21] * Quits: nessy (n=nessy@124-171-27-224.dyn.iinet.net.au) ("This computer has gone to sleep")
  178. # [06:47] * Joins: weinig (n=weinig@17.203.15.172)
  179. # [07:25] * Joins: aboodman (n=aboodman@dsl081-073-212.sfo1.dsl.speakeasy.net)
  180. # [07:31] * Joins: kingryan_ (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net)
  181. # [07:31] * Quits: kingryan (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net) (Read error: 54 (Connection reset by peer))
  182. # [07:31] * Quits: kingryan_ (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  183. # [07:31] * Joins: kingryan (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net)
  184. # [08:06] * Quits: codedread (n=schiller@c-24-13-43-191.hsd1.il.comcast.net) (Remote closed the connection)
  185. # [08:15] * Quits: weinig (n=weinig@17.203.15.172)
  186. # [08:28] * Quits: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  187. # [08:36] * Quits: hdh (n=hdh@118.71.120.84) (Remote closed the connection)
  188. # [08:54] * Joins: jruderman (n=jruderma@c-67-180-39-55.hsd1.ca.comcast.net)
  189. # [08:56] * Quits: othermaciej (n=mjs@17.244.17.16)
  190. # [08:57] * Joins: othermaciej (n=mjs@nat/apple/x-e1adfc993008d428)
  191. # [08:58] * Joins: gsnedders (n=gsnedder@213.235.51.141)
  192. # [09:08] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  193. # [09:14] * Quits: gsnedders (n=gsnedder@213.235.51.141)
  194. # [09:18] * Joins: GregHouston (n=ghouston@adsl-66-139-107-93.dsl.spfdmo.swbell.net)
  195. # [09:19] * Quits: othermaciej (n=mjs@nat/apple/x-e1adfc993008d428)
  196. # [09:26] <hsivonen> I like it how XMLPorn.jpg was from a talk called "Practical RDF"
  197. # [09:26] <hsivonen> I tend to send a link to XMLPorn.jpg when friends are having trouble with Namespaces
  198. # [09:28] <gavin> google doesn't know about XMLPorn.jpg - link?
  199. # [09:28] * Joins: Maurice (i=copyman@cc90688-a.emmen1.dr.home.nl)
  200. # [09:31] <hsivonen> gavin: http://www.tbray.org/ongoing/When/200x/2003/12/13/MegaXML
  201. # [09:31] <hsivonen> gavin: actually, it's XMLporn.jpg
  202. # [09:31] * Joins: myakura (n=myakura@p4188-ipbf6103marunouchi.tokyo.ocn.ne.jp)
  203. # [09:31] <gavin> heh
  204. # [10:01] * Joins: othermaciej (n=mjs@nat/apple/x-e4990d8760487865)
  205. # [10:16] * Joins: annevk (n=annevk@77.163.243.203)
  206. # [10:21] * Joins: kingryan_ (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net)
  207. # [10:21] * Quits: kingryan (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  208. # [10:28] * Joins: roc (n=roc@121-72-184-5.dsl.telstraclear.net)
  209. # [10:29] * Parts: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  210. # [10:30] * Joins: nessy (n=nessy@124-171-27-224.dyn.iinet.net.au)
  211. # [10:38] * Quits: roc (n=roc@121-72-184-5.dsl.telstraclear.net)
  212. # [10:38] * Joins: roc (n=roc@121-72-184-5.dsl.telstraclear.net)
  213. # [10:42] * Joins: zcorpan (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  214. # [10:50] * Quits: zcorpan (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Remote closed the connection)
  215. # [10:56] * Joins: ROBOd (n=robod@89.122.216.38)
  216. # [10:57] * Quits: othermaciej (n=mjs@nat/apple/x-e4990d8760487865)
  217. # [10:59] <annevk> http://www.google.com/chrome/intl/en/webmasters-faq.html#html5 o_O
  218. # [10:59] * Quits: aboodman (n=aboodman@dsl081-073-212.sfo1.dsl.speakeasy.net) (Read error: 110 (Connection timed out))
  219. # [11:04] <annevk> "w.document.location" (where w is a Window object)
  220. # [11:06] <Dashiva> grgr
  221. # [11:06] <Dashiva> Using location directly is a pox on the internet
  222. # [11:09] <annevk> see also: http://ejohn.org/blog/javascript-in-chrome/#comment-320344 (re link above)
  223. # [11:17] * Joins: tndH (i=Rob@adsl-77-86-6-71.karoo.KCOM.COM)
  224. # [11:28] * Joins: othermaciej (n=mjs@17.244.17.16)
  225. # [11:34] * Quits: othermaciej (n=mjs@17.244.17.16)
  226. # [11:51] * Joins: hdh (n=hdh@118.71.120.84)
  227. # [12:09] * Joins: jdandrea (n=jdandrea@ool-44c09d7b.dyn.optonline.net)
  228. # [12:27] * Joins: othermaciej (n=mjs@c-69-181-42-194.hsd1.ca.comcast.net)
  229. # [12:51] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  230. # [12:53] * Joins: eseidel (n=eseidel@c-24-130-13-197.hsd1.ca.comcast.net)
  231. # [12:56] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (Read error: 110 (Connection timed out))
  232. # [12:59] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
  233. # [13:22] <hsivonen> btw, if anyone has a solution for scaling Validator.nu hosting up in a way that could handle spikes from Google Blog, digg or somesuch without raising the fixed cost to the level of paying for the peak capacity all the time, I'd like to hear it
  234. # [13:34] <Dashiva> If they're all validating the same site(s), caching might help. But I suppose that's not the common case.
  235. # [13:37] * Joins: virtuelv (n=virtuelv@163.80-202-65.nextgentel.com)
  236. # [13:37] <hsivonen> Dashiva: in general, though, making a validator cache input is a sure way to cause confusion when author edits and revalidates but has a bug in cache control
  237. # [13:38] <hsivonen> it would be interesting to see, though, what the limits of the current setup are
  238. # [13:38] <hsivonen> since I got rid of Schematron on the HTML5 side, there haven't been cases where the server would have died due to load
  239. # [13:39] <Dashiva> Well, if the same IP submits twice, you could invalidate. Or you could hash the markup or something to detect changes. I'm not a caching expert, but it should be doable. :)
  240. # [13:39] <hsivonen> and the previous load deaths were on the Apache side--not in the Java process
  241. # [13:40] <Dashiva> Less time per request would help the apache end as well, though
  242. # [13:42] <hsivonen> I guess the first step of serious scaling would be to have 3 IP addresses each with a separate process: Apache for static files. Jetty for html5.validator.nu. Jetty for validator.nu and parsetree.validator.nu
  243. # [13:43] <hsivonen> Gandi's pricing scales down better than Amazon's
  244. # [13:43] <hsivonen> on my current host, changing the VM setup cost money and takes 24 hours
  245. # [13:44] <hsivonen> but so far, I haven't seen any system for any hosting provider that automated allocation of extra resources during a peak for Java hosting
  246. # [13:44] <hsivonen> like App Engine does for Python hosting
  247. # [13:44] <hsivonen> Amazon doesn't scale down well
  248. # [13:45] <hsivonen> because you have to host your persistent instance elsewhere
  249. # [13:45] <hsivonen> and it sucks that everyone has to reinvent infrastructural solutions for detecting the need for capacity and instructing EC2 to allocate it
  250. # [13:54] <hsivonen> perhaps in the future, automatically spawnable Xen VMs and Amazon ESB functionality becomes commoditized, and App Engine-like software on top of those becomes commoditized, too
  251. # [14:01] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  252. # [14:09] * Joins: tusho (n=tusho@91.105.98.27)
  253. # [14:09] <tusho> Why can't I put <nav> in <header>...?
  254. # [14:10] <tusho> My navigation bar is in my header.
  255. # [14:10] <tusho> Like this:
  256. # [14:10] <tusho> <header><h1>Site name</h1> <nav><ul>...</ul></nav></header>
  257. # [14:13] * Quits: GregHouston (n=ghouston@adsl-66-139-107-93.dsl.spfdmo.swbell.net) ("...")
  258. # [14:18] <tusho> :\
  259. # [14:25] <hsivonen> tusho: I'm just implementing what Hixie wrote in the spec here.
  260. # [14:25] <tusho> Yea, but I'm asking why
  261. # [14:25] <tusho> It seems very silly
  262. # [14:27] <tusho> If nobody gives me a good justification then I'll just be invalid until it's fixed ;)
  263. # [14:27] * Quits: eseidel (n=eseidel@c-24-130-13-197.hsd1.ca.comcast.net)
  264. # [14:31] * Joins: maikmerten (n=maikmert@L9416.l.pppool.de)
  265. # [14:38] * Quits: webben (n=benh@91.85.151.141) (Client Quit)
  266. # [14:39] * Joins: webben (n=benh@91.85.151.141)
  267. # [14:43] <tusho> Nobody want to offer an explanation? :P
  268. # [14:43] * othermaciej is now known as om_sleep
  269. # [14:43] <Philip`> Probably everyone who knows (e.g. Hixie) is asleep :-)
  270. # [14:44] * tusho throws a bucket of water onto Hixie
  271. # [14:45] <tusho> Hmm.
  272. # [14:45] <hsivonen> Philip`: perhaps s/e.g./i.e./ in this case? :-)
  273. # [14:45] <tusho> I wonder how many invalid pagers there are claiming to be HTML5 in the world.
  274. # [14:45] <tusho> *pages
  275. # [14:45] <tusho> (I mean, unintentionally)
  276. # [14:45] * Joins: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com)
  277. # [14:45] <tusho> Probably very little, as only the kind of people who would know about & actually use HTML 5 are the ones who would validate their pages as a matter of routine
  278. # [14:46] <hsivonen> tusho: an infinite number of Google Maps pages
  279. # [14:46] <tusho> google maps pages claim to be html5?
  280. # [14:46] <tusho> weird
  281. # [14:46] <tusho> yes they do
  282. # [14:46] <tusho> is that intentionally claiming to be html5?
  283. # [14:46] <Philip`> Infinite? I thought they only mapped a finite area
  284. # [14:46] <tusho> or just coincidence of the doctype
  285. # [14:47] <hsivonen> Philip`: I'd expect possible Google Maps URIs to be infinite, but there might be limits
  286. # [14:47] <tusho> Philip`: you can navigate outside of the map
  287. # [14:47] <tusho> and it also loops
  288. # [14:47] <Philip`> tusho: But that might just be a client-side effect, with the server only recognising a fixed-size rectangular set of coordinates
  289. # [14:47] <tusho> Philip`: Well, no, navigating outside the map doesn't wall in that
  290. # [14:48] <tusho> http://maps.google.com/?ie=UTF8&ll=89.999508,-127.96875&spn=0.001249,113.554688&z=3
  291. # [14:48] <tusho> *fall in that
  292. # [14:49] <tusho> But yea, is that intentional?
  293. # [14:49] <tusho> The doctype being HTML5's.
  294. # [14:49] <hsivonen> tusho: I suspect it's intentional
  295. # [14:49] <Philip`> I don't think the client sends a request to some URL asking for a piece of the map that is off the edge of the world, and gets back a blank response - it just doesn't send the request at all, since it knows how big the world is
  296. # [14:49] * Quits: myakura (n=myakura@p4188-ipbf6103marunouchi.tokyo.ocn.ne.jp) (Read error: 110 (Connection timed out))
  297. # [14:49] <tusho> hsivonen: Why would they do that?... Claim to be HTML5 (for no particular gain, as far as I can see, they don't use any of its features) and then be _invalid_ HTML5
  298. # [14:49] <tusho> Philip`: It's still a unique page.
  299. # [14:50] <hsivonen> tusho: perhaps they want the Standards Mode in Gecko, WebKit, Opera and IE <= 7
  300. # [14:50] <tusho> hsivonen: use an html4 doctype?
  301. # [14:50] <hsivonen> (it seems they want IE8 to emulate IE7)
  302. # [14:50] <hsivonen> tusho: costs more bytes
  303. # [14:51] <tusho> hsivonen: I'm sure even google could handle <!DOCTYPE html "-//W3C//DTD HTML 4.01//EN"> :P
  304. # [14:51] <tusho> But yea, it just seems odd to me.
  305. # [14:51] <Philip`> tusho: Oh, right, the actual maps.google.com URI itself?
  306. # [14:51] <Philip`> Sorry, I'm a bit slow :-p
  307. # [14:51] <tusho> Philip`: I think the HTML source will change too a bit
  308. # [14:52] <tusho> relating to the query params
  309. # [14:53] <Philip`> Why does Google send <meta http-equiv=X-UA-Compatible content="IE=EmulateIE7" /> instead of (a) saving space by omitting the quotes and the trailing slash, or (b) sending it via HTTP instead?
  310. # [14:53] <Philip`> They're really quite profligate with their bandwidth
  311. # [14:54] <tusho> a script is run through the theme on http://eso-std.org/ before it's uploaded
  312. # [14:54] <tusho> that strips all the whitespace from the php & css files
  313. # [14:54] <tusho> to make it go a little faster :P
  314. # [14:54] <tusho> Probably misguided.
  315. # [14:54] <tusho> Seemed to have an effect, although likely just a placebo
  316. # [14:55] <tusho> But yeah.
  317. # [14:55] <tusho> It's a bit odd for google to waste space like that
  318. # [14:55] <Philip`> Browsers need a pretty-printing 'view source' feature
  319. # [14:55] <hsivonen> perhaps next to YouTube, nothing else matters
  320. # [14:55] <hsivonen> Philip`: indeed
  321. # [14:56] <hsivonen> Philip`: and JS debuggers operating on the pretty-printed line numbers
  322. # [14:56] <jgraham> tusho: The reason you can't put <nav> in <header> is that <header> doesn't quite mean "page header"
  323. # [14:56] <tusho> jgraham: Yes, but it means 'header of the containing element', right?
  324. # [14:56] <jgraham> It means something like "title box"
  325. # [14:56] <tusho> So <header> in <body>...
  326. # [14:59] <jgraham> <header> is designed for things like <heading><h1>Yet Another Weblog</h1><h2>With a witty subtitle</h2></header> where you want to associate the title and the subtitle but don't want to have the subtitle appear in a table of contents
  327. # [14:59] <tusho> Hm.
  328. # [14:59] <tusho> jgraham: Well, how would you improve this?
  329. # [14:59] <tusho> <nav><ul><li id="site-name"><a href="http://eso-std.org"><h1>ESO</h1></a></li><li><a href="http://eso-std.org/archive">Archive</a></li></ul></nav>
  330. # [15:01] * Quits: webben (n=benh@91.85.151.141) (Read error: 110 (Connection timed out))
  331. # [15:02] <jgraham> tusho: What is wrong with what you have?
  332. # [15:02] <tusho> jgraham: I dunno, the placement of the <h1> just seems a bit weird.
  333. # [15:03] <tusho> In a list item.
  334. # [15:03] <tusho> And tbh if you look at http://eso-std.org/ I'm not sure it belongs in the <anv>
  335. # [15:03] <tusho> Archive, and any other links that are displayed on the right, are the nav bar to me
  336. # [15:03] <tusho> I think header{h1,nav{ul}} would be more appropriate
  337. # [15:03] <tusho> but as I said & you expalined, that's incorrect
  338. # [15:03] <tusho> (and invalid)
  339. # [15:05] <jgraham> I think that only makes sense under a different definition of "header" than the one HTML 5 is currently aiming for. You could s/header/section/ I guess
  340. # [15:06] <jgraham> FWIW I have a crappy tool for producing outlines of HTML5 documents here http://james.html5.org/outliner.html
  341. # [15:07] <hsivonen> jgraham: does it have random access to the tree or does it just sweep it in document order?
  342. # [15:08] <jgraham> hsivonen: The tool? It has random access. I don't remember if it uses it ore not
  343. # [15:08] <jgraham> s/ore/or/
  344. # [15:10] <hsivonen> jgraham: ok
  345. # [15:10] <tusho> jgraham: so you'd reccomend <section id="header">?
  346. # [15:13] * Joins: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
  347. # [15:13] <jgraham> tusho: Well there is a disdvantage that <section><h1>ESO</h1></section><article><h2>Foo</h2></article> won't have ESO as a parent of Foo in the outline
  348. # [15:14] <tusho> Ah.
  349. # [15:14] <tusho> jgraham: Should I just do <div id="header"> then?
  350. # [15:14] <jgraham> So just <body><h1>ESO</h1><nav></nav><article><h2>Foo</h2></article> seems OK
  351. # [15:14] <jgraham> tusho: Or use div if you need it
  352. # [15:14] <tusho> jgraham: I do need it, if you take a look at the page I need to group the header and the nav bar
  353. # [15:16] <tusho> Alrighty.
  354. # [15:16] <tusho> Done.
  355. # [15:21] * Joins: gsnedders (n=gsnedder@213.235.51.141)
  356. # [15:30] * Joins: roc_ (n=roc@121-72-184-5.dsl.telstraclear.net)
  357. # [15:30] * gsnedders updates <http://stuff.gsnedders.com/spec-gen/>
  358. # [15:32] * Joins: deane (n=deane@121-72-170-61.dsl.telstraclear.net)
  359. # [15:33] * Quits: gsnedders (n=gsnedder@213.235.51.141) ("Killin' teh intarwebs")
  360. # [15:37] * Quits: roc (n=roc@121-72-184-5.dsl.telstraclear.net) (Read error: 110 (Connection timed out))
  361. # [15:38] * Quits: deane (n=deane@121-72-170-61.dsl.telstraclear.net) (Remote closed the connection)
  362. # [15:45] * Quits: hdh (n=hdh@118.71.120.84) (Remote closed the connection)
  363. # [16:02] * Quits: virtuelv (n=virtuelv@163.80-202-65.nextgentel.com) ("Leaving")
  364. # [16:09] * Quits: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com) (Read error: 110 (Connection timed out))
  365. # [16:09] * Joins: csarven (n=csarven@modemcable144.140-202-24.mc.videotron.ca)
  366. # [16:11] <csarven> Is @longdesc dropped in HTML5?
  367. # [16:11] * Quits: kingryan_ (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  368. # [16:11] * Joins: kingryan (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net)
  369. # [16:14] <Philip`> csarven: Yes, in the sense that it's not in the current draft
  370. # [16:15] <Philip`> (since it's very rarely used, and when it is used it's almost always used wrongly, so it doesn't seem to be a good solution to whatever the problem is)
  371. # [16:27] <jgraham> I thought the point of @longdesc was to act as flamebait for public-html
  372. # [16:27] <jgraham> I seriously don't understand any of the arguments that have been going on around it
  373. # [16:29] <jgraham> Like the ones that go: 1) Users never encounter longdesc 2) Therefore it is hard to tell if they would find it useful 3) Therefore we must leave it in so that it can be used more
  374. # [16:30] <jgraham> 4) Even though we have no expectation of that happening any time soon
  375. # [16:30] <jgraham> I mean, as far as I can tell that is an exact summary of one of David's emails
  376. # [16:31] <annevk> I believe the argument is that it's the fault of user agents that the feature failed. So that we should first have good implementations of it before we can determine whether the feature is actually bad.
  377. # [16:32] <jgraham> That didn't seem to be what David was arguning, but I find him quite difficult to follow sometimes so I might be wrong
  378. # [16:33] <annevk> Oh ok, well, that's one of the arguments I hear now and then anyway. If an accessibility feature failed, it's because of UAs, not because it's simply a bad feature.
  379. # [16:33] <jgraham> Also, since very few authors actually test with AT it seems very unlikely that better AT support would lead to substantially more widespead usage
  380. # [16:33] <annevk> (It's also so wrong to think of things as "accessibility features", but whatever.)
  381. # [16:34] <jgraham> annevk: The "accessibility features" thing seems to be one of the fundamental points of disagreement
  382. # [16:38] * Joins: myakura (n=myakura@p4188-ipbf6103marunouchi.tokyo.ocn.ne.jp)
  383. # [16:39] <hsivonen> it seems to me that there's also tacit disagreement on how long the trial window for a given feature is
  384. # [16:40] <hsivonen> that is, it seems that some people think that 10 years should be enough
  385. # [16:40] <hsivonen> and others want to give the feature a chance still
  386. # [16:42] * Quits: jdandrea (n=jdandrea@ool-44c09d7b.dyn.optonline.net)
  387. # [16:46] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  388. # [16:52] * Joins: dglazkov (n=dglazkov@c-24-130-116-76.hsd1.ca.comcast.net)
  389. # [16:56] * Quits: dglazkov (n=dglazkov@c-24-130-116-76.hsd1.ca.comcast.net) (Client Quit)
  390. # [17:06] * Quits: roc_ (n=roc@121-72-184-5.dsl.telstraclear.net) (Read error: 60 (Operation timed out))
  391. # [17:07] <takkaria> heh, that is madness
  392. # [17:07] <takkaria> "Many of us have done real work on issues like @headers, @alt, @summary, including but not limited to: ... Attending teleconferences"
  393. # [17:09] * Joins: roc (n=roc@121-72-162-122.dsl.telstraclear.net)
  394. # [17:13] * Joins: gsnedders (n=gsnedder@213.235.51.141)
  395. # [17:20] <Philip`> I hope I can count "making snide comments on IRC" as real work
  396. # [17:31] * Joins: jdandrea (n=jdandrea@ool-44c09d7b.dyn.optonline.net)
  397. # [17:31] <jgraham> I think I'm making a more useful contribution by not making all the snide comments I can think of on IRC
  398. # [17:35] <takkaria> I have nowhere else to express incredulity :/
  399. # [17:37] * Philip` isn't complaining about it :-)
  400. # [17:41] <jgraham> takkaria: I'm not complaining.
  401. # [17:42] <jgraham> It's just the "scientists are corrupt" post somewhat riled me
  402. # [17:44] * Philip` must have skipped over that post
  403. # [17:44] <jgraham> "It has been known for some time that some scientists skew their
  404. # [17:44] <jgraham> research to gain favor in the eyes of their peers and to gain fame"
  405. # [17:45] <jgraham> "When there is an economic interest involved one can be virtually
  406. # [17:45] <jgraham> guaranteed that the full facts will not come out, it's naive to
  407. # [17:45] <jgraham> suppose otherwise."
  408. # [17:46] <Philip`> The first statement is true but I don't see any justification for the second
  409. # [17:47] <jgraham> Indeed. It's a crazy generalization
  410. # [17:47] * jgraham notes that these are not the snide comments
  411. # [17:48] <Philip`> Fortunately I'm only a computer scientist so I don't have to even pretend to do real science
  412. # [17:50] * Philip` can't remember when he last read a paper that was based on a hypothesis - it always seems to be "we built this system because we thought it'd be interesting, and here's how we did it, and look how neat it is"
  413. # [17:52] <jgraham> Many astrophysics papers are "We did these observations and got these cool results. Maybe it works like this." where "this" is not necessarily a unique explaination
  414. # [17:55] <jgraham> (you generallly need a hypothesis to get telescope time in the first place though)
  415. # [17:59] <Philip`> Nowadays anyone can get virtually unlimited computer time with no justification from the box sitting under their desk, so we don't even need to do that :-(
  416. # [18:00] <Philip`> and if you have greater requirements and need a dozen machines, you can just run them all as VMs in the box sitting under your desk
  417. # [18:10] * Quits: nessy (n=nessy@124-171-27-224.dyn.iinet.net.au) ("This computer has gone to sleep")
  418. # [18:10] * Joins: malde_ (n=chatzill@c183187.adsl.hansenet.de)
  419. # [18:12] <Philip`> http://marketshare.hitslink.com/report.aspx?sample=21&qprid=43&qpcustom=Chrome+0.2 - that doesn't seem to have taken long to have mostly flattened off
  420. # [18:16] <takkaria> I wonder what the figure will be in a month
  421. # [18:18] <Philip`> (http://getclicky.com/global-marketshare-statistics gives a significantly different absolute value, but seems to have the same one-day growth and then a slow decline)
  422. # [18:19] <takkaria> nice to see that 7% of people are on ff3 so soon after release
  423. # [18:20] <Philip`> Automatic updates are a great idea :-)
  424. # [18:20] * Philip` nudges the Opera people
  425. # [18:20] <takkaria> I didn't think ff2 automatically updated to ff3 yet
  426. # [18:20] <Philip`> (Actually it's fine for me since Gentoo upgrades Opera automatically)
  427. # [18:21] <Philip`> takkaria: Well, it's automatic once you click the right button in the automatically-popped-up dialog, I think
  428. # [18:22] <takkaria> I thought I read in meeting minutes somewhere that it was being delayed until 3.0.2 or something
  429. # [18:23] <Philip`> Oh
  430. # [18:23] * Philip` isn't at all sure
  431. # [18:24] <takkaria> https://wiki.mozilla.org/Firefox3.1/StatusMeetings/2008-08-12#Firefox_2.0.0.17_.2F_3.0.2
  432. # [18:25] <takkaria> "3.0.2 will be the version which we eventually offer as a major update"
  433. # [18:26] <Philip`> Fair enough
  434. # [18:26] <Philip`> I'm sure I've heard people complaining that they're using FF2 and it keeps nagging them to update to FF3, though :-)
  435. # [18:27] <takkaria> ah well
  436. # [18:27] <takkaria> who knows? :)
  437. # [18:27] * Quits: Amorphous (i=jan@unaffiliated/amorphous) ("shutdown")
  438. # [18:29] * Joins: dglazkov (n=dglazkov@c-24-130-116-76.hsd1.ca.comcast.net)
  439. # [18:30] <Philip`> Hmm, someone should have told me the Chromium SVN repository was going to use 1.9GB of space, before I downloaded it
  440. # [18:33] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
  441. # [18:33] * Quits: dglazkov (n=dglazkov@c-24-130-116-76.hsd1.ca.comcast.net) (Client Quit)
  442. # [18:48] * Joins: malde__ (n=chatzill@d077082.adsl.hansenet.de)
  443. # [18:51] <tusho> well
  444. # [18:51] <tusho> i just got a report from someone that their firefox was "all different"
  445. # [18:51] <tusho> sure enough it was ff3
  446. # [18:51] <tusho> they said it did an update thingy
  447. # [18:51] <tusho> so...
  448. # [18:58] * Quits: malde_ (n=chatzill@c183187.adsl.hansenet.de) (Read error: 110 (Connection timed out))
  449. # [19:01] * Quits: maikmerten (n=maikmert@L9416.l.pppool.de) (Remote closed the connection)
  450. # [19:14] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (Read error: 110 (Connection timed out))
  451. # [19:16] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
  452. # [19:23] * Quits: myakura (n=myakura@p4188-ipbf6103marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  453. # [19:25] <gsnedders> Lachy: Can you live with straight hair, not green hair?
  454. # [19:27] <Philip`> Straight hair is not quite as extreme nor as likely to result in people laughing at you in the street :-(
  455. # [19:27] <gsnedders> Okay okay okay…
  456. # [19:36] * Quits: malde__ (n=chatzill@d077082.adsl.hansenet.de) ("ChatZilla 0.9.83 [Firefox 3.0.1/2008070206]")
  457. # [19:49] <gsnedders> Lachy: Will having it green and straight do?
  458. # [19:49] * Joins: maikmerten (n=maikmert@L9416.l.pppool.de)
  459. # [19:49] <gsnedders> I've been bullied into this for tonight.
  460. # [20:03] * gsnedders changes topic to 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks! -- gsnedders has green hair, photos coming really soon :-)'
  461. # [20:10] <Philip`> hsivonen: You should make your validator into a Java applet, so you can support any number of users just by serving a static file and not having to worry about server load
  462. # [20:28] <Philip`> http://www.xkcd.com/ - <img ... alt="&lt;span style=&quot;color: #0000ED&quot;&gt;House&lt;/span&gt; of Pancakes" /> - oops
  463. # [20:31] <Lachy> gsnedders, green hair is non-negotiable. But why does it have to be straight?
  464. # [20:31] <gsnedders> Lachy: It is green now
  465. # [20:31] <gsnedders> And curly
  466. # [20:31] <gsnedders> Well, not entirely green
  467. # [20:31] <gsnedders> But mostly
  468. # [20:31] <Lachy> good
  469. # [20:34] * Joins: dglazkov (n=dglazkov@c-24-130-116-76.hsd1.ca.comcast.net)
  470. # [20:36] <Philip`> s/good/crazy/
  471. # [20:40] <Lachy> Philip`, crazy is good.
  472. # [20:41] <Lachy> we're all crazy in here
  473. # [20:41] * Philip` wonders about correlation vs causation
  474. # [20:42] <Philip`> (Are we here because we're crazy, or are we crazy because we're here, or is there an external cause of both situations, or no cause at all?)
  475. # [20:42] <takkaria> this place doesn't make you crazy, just slowly more realistic
  476. # [20:42] <takkaria> so my guess is option three or four
  477. # [20:47] * Quits: dglazkov (n=dglazkov@c-24-130-116-76.hsd1.ca.comcast.net)
  478. # [20:51] <Lachy> I think we only stick around because we're crazy. The non-crazy people tend leave pretty quickly when they see the kind of nonsense we talk about in here
  479. # [20:52] * jgraham wonders why the photos are taking so long
  480. # [20:53] <Lachy> gsnedders could be using a non-digitial camera and I hear those can take a little while to develop.
  481. # [20:54] <Lachy> but I don't know, I haven't used one of those for years
  482. # [21:01] <jgraham> I know for a fact that gsnedders has a digital camera. However I guess he might be using a manual camera and developing in his kitchen. In black and white.
  483. # [21:01] <Philip`> That would somewhat defeat the point
  484. # [21:02] <Lachy> w00t! gsnedders will look hilarious with black hair :-)
  485. # [22:03] * Lachy adds more people to his list of people to whom never to respond
  486. # [22:03] <Lachy> it's interesting how people's responses to me have ignored the real issue, and instead focussed on irrelevant crap
  487. # [22:04] <Lachy> on public-html
  488. # [22:04] <Lachy> and how Laura took what I said way out of context
  489. # [22:06] * om_sleep is now known as othermaciej
  490. # [22:29] <Dashiva> "Because the author did not know how to make the @longdesc attribute accessible for sighted users."
  491. # [22:29] <Dashiva> Why put it in a hidden attribute if you want to make it visible?
  492. # [22:39] <Dashiva> "Those AT tools that *do* support @longdesc are generally configured so that announcing @longdesc is a toggle ON setting; it is toggled off by default."
  493. # [22:40] * Dashiva facepalms
  494. # [22:42] <Lachy> Dashiva, that was my reaction too
  495. # [22:43] <Lachy> in fact, that was pretty much my reaction to the messages from Laura, PTW, David and John
  496. # [22:44] <Dashiva> webben mentioned yesterday that longdesc announcement was on by default when JAWS first added it, and it was later turned off
  497. # [22:44] <Dashiva> Which is pretty much unconditional surrender
  498. # [22:45] <jruderman> turned off by default *in jaws*?
  499. # [22:45] <Lachy> apparently it's on by default in the jaws 10 beta though
  500. # [22:46] <Dashiva> <webben> Dashiva: JAWS has exposed it since version 4.something.
  501. # [22:46] <Dashiva> <webben> although in some recent versions, you've had to enable announcements for it.
  502. # [22:46] <Dashiva> <webben> Dashiva: that behavior appears to have changed back to announcing by default in current JAWS 10 Beta.
  503. # [22:47] <Dashiva> (and I wouldn't be surprised if it's off by default in v10 final)
  504. # [22:54] * tusho is now known as TuTheSho
  505. # [23:11] * Quits: jdandrea (n=jdandrea@ool-44c09d7b.dyn.optonline.net) ("ciao")
  506. # [23:11] * Joins: jdandrea (n=jdandrea@ool-44c09d7b.dyn.optonline.net)
  507. # [23:11] * jgraham wonders if gsnedders parents are making him shave his head
  508. # [23:25] * Joins: jdandrea_ (n=jdandrea@ool-44c09d7b.dyn.optonline.net)
  509. # [23:26] * Joins: eseidel (n=eseidel@c-24-130-13-197.hsd1.ca.comcast.net)
  510. # [23:30] * Quits: starjive (i=beos@213-66-217-32-no30.tbcn.telia.com)
  511. # [23:39] <Lachy> wow, finally John has sent some real evidence to support his case. http://lists.w3.org/Archives/Public/public-html/2008Sep/0222.html
  512. # [23:41] * Quits: jdandrea (n=jdandrea@ool-44c09d7b.dyn.optonline.net) (Read error: 110 (Connection timed out))
  513. # [23:42] * jdandrea_ is now known as jdandrea
  514. # [23:43] * Quits: maikmerten (n=maikmert@L9416.l.pppool.de) (Remote closed the connection)
  515. # Session Close: Sun Sep 07 00:00:00 2008

The end :)