/irc-logs / w3c / #html-wg / 2007-08-23 / end


  1. # Session Start: Thu Aug 23 00:00:00 2007
  2. # Session Ident: #html-wg
  3. # [00:00] <robburns> jgraham: I just don't think it adds anything useful to the design principles to say: "Solve problems that can be solved" and "Solve problems worth solving". We might as well have "Make browsers work good"
  4. # [00:00] <jgraham> robburns: The design principles are for _us_ though, not for outside observers.
  5. # [00:01] <robburns> jgraham: ok even for us. What do those add to the conversation. How can they possibly help the deliberations we're going to have.
  6. # [00:02] <jgraham> I agree that the title could be improved; I think "Provide Real Improvements", with text indicating that all proposed solutions should be evaluated according to the needs of the constituents they are supposed to help and rejected if they don't meet those needs.
  7. # [00:02] <robburns> jgraham: when someone raises an issue for conversation, that person raises it because he thinks the problem it addresses is real, that it is a problem that can be solved, and that it is a problem worth solving.
  8. # [00:03] <jgraham> robburns: and, assuming the current design principles, if someone can demonstrate that they were mistaken to believe it was a real problem then we should not attempt to solve it.
  9. # [00:03] * Joins: Zeros (Zeros-Elip@
  10. # [00:03] <robburns> jgraham: we may, through our deliberations, decide otherwise. However, that design principle doesn't really add anything to the conversation. No one can guess before they propose something how it will be received by the WG
  11. # [00:04] <mjs> I'm thinking of renaming the more contentious principles
  12. # [00:04] <robburns> jgraham: if someone can demonstrate that the proposing WG member was mistaken, then the proposing WG member would withdraw the proposal, simply because it is the right thing do to. We don't need a design principle to remind them of that.
  13. # [00:04] <mjs> I think "Solve Real Problems" might better be named "Support Use Cases With Evidence"
  14. # [00:05] <mjs> of course, there's been at least one argument made that some things are so important that they shouldn't have to be justified with use cases
  15. # [00:05] <jgraham> ?
  16. # [00:06] <mjs> John Foliot argued that this is true of accessibility
  17. # [00:06] <robburns> mjs: it doesn't help to just rename the principle. The principle itself is fundamentally flawed. It doesn't add anything to the conversation (and it is open to all sorts of abuse)
  18. # [00:06] <jgraham> accessibility is itself a use case
  19. # [00:06] <jgraham> (loosly speaking)
  20. # [00:06] <mjs> jgraham: he argued that specific features that are claimed to be for accessibility shouldn't require use case justification
  21. # [00:07] <robburns> jgraham: I think disability is a use-case, as in visual impairment or hearing impairment etc.
  22. # [00:07] <mjs> disability isn't a use case
  23. # [00:07] <robburns> jgraham: but accessibility is properly used as design principle
  24. # [00:07] <jgraham> mjs: I think I remember.
  25. # [00:07] <mjs> making content that is accessible to people with that disability is a use case
  26. # [00:07] <jgraham> but I never understood his point of view
  27. # [00:07] <robburns> mjs: well disability is a use-case in the sense that there's some content I'd like to use and I can't use my eyes to see it.
  28. # [00:08] <mjs> robburns: can you imagine yourself agreeing with a rewritten principle whose theme is "Support Use Cases With Evidence"?
  29. # [00:08] <robburns> mjs: not really
  30. # [00:08] <mjs> you don't think use cases should be supported with evidence?
  31. # [00:08] <jgraham> robburns: Why ever not?
  32. # [00:08] <Philip`> What about an entirely new principle whose theme is "Support Use Cases With Evidence"? :-)
  33. # [00:09] <jgraham> I can see your problem with "Solve Real Problems", but I have no idea what you have against evidence
  34. # [00:09] <Zeros> Depends on what "evidence" means. Sometimes laying the groundwork for accessibility devices to implement support in the future is more important than being able to prove it helps users right now.
  35. # [00:09] <robburns> mjs: certainly they should. It's just I don't think anyone would actively try to avoid providing evidence. It's not like we have top-secret evidence we won't share with the WG. If member propose something then they'll do what's in their power to provide evidence for it. I have complete faith in that.
  36. # [00:09] <mjs> evidence doesn't have to be actual current use or practice
  37. # [00:10] <Zeros> That seems reasonable enough then.
  38. # [00:10] <mjs> robburns: I don't think people deliberately hide evidence, I think they sometimes fail to provide adequate evidence
  39. # [00:10] <mjs> either because they didn't try to look or because no evidence exists
  40. # [00:11] <mjs> without evidence, there is no way to evaluate the value of an argument, and therefore no objective way to make decisions
  41. # [00:11] <robburns> mjs: I just don't think these types of things belong in the design principles. Yes let's try to solve real problems. Let's try to solve problems that are solvable. Let's try to solve problems that are worth solving. Let's try to provide solutions that address the original problem. Let's investigate the problems and collect evidence that a solution will actually work.
  42. # [00:11] <jgraham> robburns: There have been dozens of threads just on public-html where it took _ages_ for people to start looking at testcases, examining current use, looking for sites that hacked around the lack of a feature, or similar
  43. # [00:11] <mjs> Zeros: specifically, significant expression of interest from the expected target audience would count as evidence
  44. # [00:12] <Zeros> It would be interesting to poll a large population of disabled users and see what their biggest gripes are, and observe their usage patterns to see where things could be improved.
  45. # [00:12] <robburns> mjs: let's do all those things. But let's not put those things in the design principles. Let's just stipulate that that's what a WG does.
  46. # [00:12] <mjs> robburns: that's not a very compelling argument
  47. # [00:12] <robburns> mjs: I don't think we have the means or the budget to collect that sort of evidence.
  48. # [00:12] <mjs> people do in fact make suggestions not backed by evidence all the time
  49. # [00:13] <mjs> evidence doesn't always have to take the form of statistical analysis of existing web content
  50. # [00:13] <jgraham> robburns: If we aren't planning to put those things in the design principles doesn't it rather devalue the document (since there will be a bunch of unstated rules that people will have to know about)
  51. # [00:13] <Zeros> mjs, I agree. We need to get a way to get such an audience's feedback though. Having that interest also better guarantees future implementation since the business aspect already has an interested audience.
  52. # [00:13] <robburns> mjs: those are suggestions or proposals. The evidence comes later.
  53. # [00:14] <mjs> Zeros: for browser vendors and search engine providers, we have good means of contact through the WG and otherwise
  54. # [00:14] <mjs> Zeros: I would say the biggest communication gap is with developers of assistive technologies
  55. # [00:14] <Philip`> I've seen complaints of a communication gap with web developers
  56. # [00:14] <robburns> mjs: we have developers of assistive technologies on our WG.f
  57. # [00:15] <robburns> s/f/
  58. # [00:15] <Zeros> is there someone from FS working with the wg?
  59. # [00:15] <Philip`> (which may be a more significant gap, since there are more web developers than there are AT users)
  60. # [00:15] <mjs> robburns: not of the two or three most popular screen readers on Windows, which are often cited as justification for accessibility-related things
  61. # [00:16] <Zeros> mjs, what about apple? Where does the department that works on VO get their feedback?
  62. # [00:16] <DanC> introductions... good idea, mjs. http://lists.w3.org/Archives/Public/public-forms-tf/2007Aug/0002.html
  63. # [00:16] <mjs> Philip`: well, many companies that do significant web development are represented, as are many individual web developers
  64. # [00:16] <Zeros> Seems like MS should have connections from working on MSAA too
  65. # [00:17] <Zeros> Or did they just drop the API on people and expect products to spring up?
  66. # [00:17] <robburns> mjs: screen readers only relate to our work to the extent that they become aural browsers or speaking applications. The developers of some of the leading aural browsers are already on this WG. Many of the screenreader developers have not show interest in also becoming aural browser developers.
  67. # [00:17] <mjs> Zeros: my team at Apple works pretty closely with the VoiceOver team and can communicate with them as needed
  68. # [00:18] <Zeros> mjs, okay, so if we wanted to see about what they think of the usefulness of a feature, you could find out?
  69. # [00:18] <mjs> robburns: in practice it seems that most blind users use Windows-Eyes or JAWS to access the web, so regardless of how it should be, those are the most relevant apps right now
  70. # [00:18] <DanC> +1 "Solve Real Problems" might better be named "Support Use Cases With Evidence"
  71. # [00:18] <mjs> Zeros: yes
  72. # [00:18] <Zeros> mjs, awesome
  73. # [00:19] <robburns> Zeros: VoiceOver aims mostly at just being a screen reader. I'm happy to get their feedback and I'd love to see them become more, but I just want us to be clear on the difference.
  74. # [00:19] <mjs> VoiceOver isn't really a screen reader
  75. # [00:19] <Zeros> anyway, while we're discussing the design principals, is there a specific accessibility feature that robburns thinks is being ignored?
  76. # [00:19] <mjs> it's a speaking interface for the whole OS
  77. # [00:19] <mjs> it uses semantic information from applications themselves
  78. # [00:19] <mjs> it does not just read the screen and doesn't do any poking into the framebuffer or interception of graphics calls
  79. # [00:19] <robburns> mjs: the currently available release is largely a screen reader (at least when it comes to web contetn)
  80. # [00:20] <robburns> mjs: it doesn't use the semantics inherent in HTML or CSS though
  81. # [00:20] <mjs> robburns: it certainly does - I've seen the code
  82. # [00:20] <robburns> mjs: which is what's relevant to the current discussion
  83. # [00:20] <robburns> mjs: itt certainly does not I've used it
  84. # [00:21] <mjs> it may not be using the markup in the way you expect
  85. # [00:21] <robburns> mjs: somehow that code must have not gotten implemented in the UI
  86. # [00:21] <mjs> but it does look at it
  87. # [00:22] <robburns> mjs: it doesn't use the markup in the way I expect. The way I expect is to use the semantic inherent in HTML and CSS. So, in other words it doesn't use the semantics inherent in HTML or CSS
  88. # [00:22] <Zeros> um huh?
  89. # [00:22] <robburns> mjs: which is what I said in the first place
  90. # [00:22] <Zeros> that's circular logic
  91. # [00:22] <Philip`> robburns: How do you expect it to use the semantics?
  92. # [00:23] <DanC> the "[HDP] Response to Review of HTML Design Principles Questionnaire" is unmanageable, for me. The message that started it has lots of good stuff, but the resulting discussion is about umpteen different things, all in one thread. hmm.
  93. # [00:23] <robburns> Philip: I would expect it to be aware of table data/header associations, table header abbreviations, CSS auarl/speech properties, etc. I can't think of one place where VoiceOver does that.
  94. # [00:23] <mjs> DanC: I hope that the person who started the thread can summarize it in the wiki
  95. # [00:23] <DanC> heh... I was just going to say that I hope the editor can follow the thread
  96. # [00:23] * jgraham notes that this is an ideal example of a case where asking the people who actually need the semantics i.e. the AT implementers is necessary
  97. # [00:23] <Zeros> I don't think many readers actually support the aural css properties
  98. # [00:24] <jgraham> s/asking/talking to/
  99. # [00:24] <robburns> VoiceOver speaks UI for the built in OS view classes. It doesn't speak the semantics of HTML and CSS.
  100. # [00:25] <jgraham> robburns: it is not impossible that implementing behaviour for some of those semantics provides a worse user experience than not implementing them
  101. # [00:25] <mjs> robburns: it's aware of links, form controls, elements with a click action, client-side image maps, blockquotes, headings...
  102. # [00:25] <robburns> Zeros: That's what I said before and the difference I want to make clear. Screen readers typically aren't concerned with HTML/CSS issues. Aural browsers and speaking web applications are. We have members on our WG already who represent the latter developers. The screen readers would only be interested in what we do to the extent that they become aural browsers.
  103. # [00:26] <mjs> robburns: list markers, block vs. inline...
  104. # [00:26] <Zeros> robburns, um okay. I'm confused. What exactly do you want implemented that mjs thinks requires more evidence?
  105. # [00:26] <mjs> Zeros: this isn't a discussion about evidence
  106. # [00:26] <Zeros> ah okay
  107. # [00:26] <robburns> Zeros: we were talking about the design principles
  108. # [00:26] <mjs> robburns claims that VoiceOver ignores the semantics of HTML and CSS
  109. # [00:26] <mjs> which is factually wrong
  110. # [00:27] <Philip`> It just ignores *some* of the semantics?
  111. # [00:27] <mjs> it doesn't make use of some of the semantics
  112. # [00:27] <robburns> mjs: OK, I'd agree with that characterization
  113. # [00:27] <mjs> it does make use of other aspects of the semantics
  114. # [00:28] <mjs> in fact, quite a lot - look at all the things I listed
  115. # [00:28] <Philip`> Is that because of technical limitations (i.e. it'd take too much effort to implement within its framework), or because the semantics are considered useless?
  116. # [00:28] <Philip`> (I assume the answer depends on the exact case)
  117. # [00:28] <Philip`> (in which case it's not a directly useful question)
  118. # [00:28] <Zeros> You missed the time answer
  119. # [00:28] <mjs> it's for kind of the same reason Safari has bugs in some standards support - it's not done yet, and will continue improving
  120. # [00:29] <Zeros> VoiceOver is quite a bit younger than JAWS
  121. # [00:29] <robburns> mjs: however those were many of the things it gets for free from the underling classes. Few of that extra stuff useful to the visually impaired has been implemented in those underlying classes (like aural CSS and HTML @abbr, @summary etc.)
  122. # [00:30] <mjs> robburns: I'm sure there's all sorts of additional features we can (and will) add
  123. # [00:30] <mjs> but saying that VoiceOver is only a screen reader for web content is wrong
  124. # [00:30] <mjs> both with regards to its current state and with regard to goals
  125. # [00:31] <Philip`> It would be useful if there was a list of what additional features you won't ever add (because they're useless / counterproductive), since those are the ones that are relevant for the design of HTML (in deciding what to keep or remove or replace with a better solution)
  126. # [00:31] <mjs> one thing that's been found with VoiceOver is that representing the things in the content that sighted users can see is more valuable over a wider range of content than features that are specific to non-sighted users
  127. # [00:32] <mjs> Philip`: I don't think anyone has made such a list - queries about specific features would be easier to answer
  128. # [00:32] <mjs> I think the market share of VoiceOver is pretty small to the top Windows screen readers though
  129. # [00:32] <Zeros> Does webkit implement the DOM mutation events?
  130. # [00:33] <mjs> yes, although we hate them
  131. # [00:33] <robburns> mjs: Ok understood. However, some of the other screend readers also aim to become more than screen readers. Perhaps OS readers would be a better name. It's a bit of a nebulous line, but many of these OS readers are focussed on general OS reading and do not necessarily extract the semantics in HTML and CSS aimed specifically at the disabled.
  132. # [00:33] <Zeros> mjs, does VoiceOver use them?
  133. # [00:33] <mjs> Zeros: no (though I'm not sure why that's relevant)
  134. # [00:33] <robburns> mjs: on the other hand, the speaking applications like Opera, Emacspeak and Fire Vox do aim at that. And all of those developers are represented in the WG
  135. # [00:33] <jgraham> mjs: One obvious query would be about the implicit table heading association algorithm in HTML 4. If I understood correctly this is not implemented by any major screenreaders
  136. # [00:34] <Zeros> mjs, the capacity for a reader to be able to know which parts of a page are changing is important
  137. # [00:34] <robburns> msj: as is Apple
  138. # [00:34] <mjs> Zeros: in general we try to use more efficient engine-specific change notifications when needed, both for accessibility and other things
  139. # [00:35] <mjs> jgraham: I can ask what plans, if any, they have for table headers
  140. # [00:35] <Zeros> mjs, hmm, so VO can tell when various parts of the page change due to JS?
  141. # [00:35] <Zeros> I really need to start browsing with VO on and listen to how it behaves
  142. # [00:35] <mjs> robburns: well, again, JAWS and Windows-Eyes are the major apps cited when it's said that some feature is unsupported by screen readers
  143. # [00:35] <mjs> Zeros: I'm not sure how good it is at detecting changes
  144. # [00:35] <Zeros> hmm
  145. # [00:35] <mjs> Zeros: or the granularity thereof
  146. # [00:36] <mjs> but, our efforts to improve that probably would not include using DOM mutation events
  147. # [00:36] <mjs> DOM mutation events have two problems:
  148. # [00:36] <robburns> mjs: I'm not sure what you're saying by that though (listing those apps)
  149. # [00:36] <mjs> 1) the event handler is allowed to do anything, including mutating the DOM
  150. # [00:37] <Zeros> Seems we need a better way to notify of changes then, if the DOM mutation events are that difficult to use/implement. I've read articles about throwing focus() at random elements to make the reader see it, but that can cause the reader to jump off what it's reading and other oddness (from what I've read, not tested).
  151. # [00:38] * Quits: heycam (cam@ (Ping timeout)
  152. # [00:38] <mjs> 2) the granularity of events is very small, so compound operations must send many events
  153. # [00:38] <mjs> for internal changes, we have more efficient ways of notifying
  154. # [00:38] <mjs> so that we can disallow mutation from the handler and/or coalesce notifications
  155. # [00:39] <mjs> anyway, I am not an expert on how well VoiceOver works - I hope to try using it sometime, though that is at present a back burner task
  156. # [00:39] <Zeros> It wouldn't make sense to convert those less problematic events into something all browsers could use?
  157. # [00:39] <mjs> well, these things aren't DOM events at all and aren't exposed to web content
  158. # [00:39] <Hixie> mjs: i hope your experience with it is better than my experience with jaws
  159. # [00:39] <Hixie> sheesh
  160. # [00:39] <mjs> better change notification events for web content might be useful
  161. # [00:40] <Zeros> yeah
  162. # [00:42] <robburns> Philip: yt?
  163. # [00:43] <Philip`> robburns: Yes
  164. # [00:44] <robburns> Philip : We were discussing the @axis attribute a while back and that is comma separated.
  165. # [00:44] <Philip`> And about comma-separation not being great for CSS selectors?
  166. # [00:44] <robburns> I was looking at HTML 4.01 and there's a few things comma separated and a few space-separated, but I couldn't glean any reason for the difference (and CSS3 does indeed only have a space-delimited selector).
  167. # [00:45] <robburns> any thoughts on why we have two delimiters?
  168. # [00:47] <robburns> Philip: comma-delimited ContentTypes, DediaDesc, Coords, MultiLengths, and axis, , ,
  169. # [00:47] <Philip`> Are there any space-separated other than @class and object@archive?
  170. # [00:47] <robburns> Philip: space-delimited: class, archives, Charsets, LinkTypes
  171. # [00:47] <Philip`> (How weird - object@archive is space-separated, applet@archive is comma-separated...)
  172. # [00:48] <robburns> weird
  173. # [00:48] <robburns> indeed
  174. # [00:49] <Philip`> http://www.w3.org/TR/html401/interact/forms.html#adef-accept-charset - "The value is a space- and/or comma-delimited list of charset values."
  175. # [00:49] <Philip`> Weirder :-)
  176. # [00:50] <Philip`> I can't see any particular reason for the choices
  177. # [00:51] <Zeros> and or?
  178. # [00:51] <Zeros> that sounds like it must be fun to select
  179. # [00:51] <Zeros> :p
  180. # [00:52] <Philip`> @charsets = split /[ ,]+/, $accept_charset;
  181. # [00:52] <Philip`> Easy :-)
  182. # [00:52] <Philip`> Or you could write a 22-step algorithm full of gotos to describe how to parse it
  183. # [00:52] <Zeros> with css
  184. # [00:52] <Philip`> Oh, okay
  185. # [00:52] * Quits: tH (Rob@ (Quit: ChatZilla [XULRunner])
  186. # [00:53] <Philip`> I guess if the person writing the CSS and the content are somewhat cooperative, they can just agree to use spaces all the time
  187. # [00:53] <robburns> Phlip: the DTD said only " a space-separated list of character encodings, as per [RFC2045]" for charsets
  188. # [00:53] <Philip`> Then again, I'm not sure why you'd ever want to style a form based on its charsets :-p
  189. # [00:53] <Zeros> lang is the odd one out because it uses a hyphen
  190. # [00:53] <Philip`> robburns: Are you expecting internal consistency in HTML4?
  191. # [00:54] <robburns> also some of these have the same syntax as the http headers I believe
  192. # [00:56] <Philip`> link@media and style@media are defined in HTML5 as CSS3 Media Queries, so that defines the syntax in that case
  193. # [00:56] <robburns> Philip: :=) No on the internal consistency. Just trying to understand to see where we might have other CSS handle problems (like axis)
  194. # [00:57] <robburns> but you're write the charsets is probably not one of those
  195. # [00:58] <robburns> Zeros: except the hyphen is to get at hierarchically arranged languages, not separately listed languages
  196. # [00:59] <robburns> Zeros: those attributes list just one language code. But the styling might be based on one part of that language code definition (like en-US where you're only interested in the en or the US).
  197. # [00:59] <Zeros> robburns, I know, I was just stating that there's other ways of separating data in html attributes as well
  198. # [01:00] <robburns> Zeros: I see
  199. # [01:01] <Zeros> CSS ended up with kind of half-assed regex selection because of all this
  200. # [01:01] * Philip` wonders if anyone on the web actually uses multiple axis values
  201. # [01:01] <robburns> Seems to me that either CSS should add a comma-separated attribute selector (preferred) or those should be avoided whenever possible(like moving more to specifying the and/or)
  202. # [01:01] <Zeros> ^= $= and what not, it's rather comical
  203. # [01:02] <Zeros> adding more selectors just complicates things, CSS needs a universal separator selector that lets you supply the separator.
  204. # [01:02] <Philip`> (I couldn't find anybody using @axis at all, so it's not terribly significant, but I don't know how many thousands or millions I missed, and how many of those use multiple values, and whether they accidentally use spaces instead of commas)
  205. # [01:02] <Zeros> [attr(sep)="value"] then again attr() is already used, but I don't think it applies in that context
  206. # [01:02] <robburns> Philip: As I said before, I think multiple axes would be rare. However, if using it is just a matter of being able to specify it with space instead of comma delimiters it would be worth pursuing it (I'm not saying that I know that's an easy move, just positing it).
  207. # [01:03] <Philip`> Just allow arbitrary JS expressions in CSS selectors :-)
  208. # [01:03] <Zeros> hah
  209. # [01:03] <Zeros> Was expression: ever proposed for CSS3?
  210. # [01:03] <Zeros> s/:/()/
  211. # [01:05] <Philip`> Like in IE?
  212. # [01:05] <Zeros> yes
  213. # [01:05] <Zeros> I was just curious
  214. # [01:05] <Philip`> That's not enough fun for implementors - it's got to be scripted selectors!
  215. # [01:05] <Zeros> oh okay
  216. # [01:06] <Zeros> why not just add @script {} blocks?
  217. # [01:06] * Philip` ignores the likely pain in evaluating every single selector after every single DOM change
  218. # [01:06] <Zeros> I've crashed IE before using expression()
  219. # [01:07] * Philip` has no idea if the slightly more feasible expression() was ever suggested seriously
  220. # [01:07] <Philip`> (I must admit to having used it in a real site once)
  221. # [01:07] <Philip`> (to fake max-width, if I remember correctly)
  222. # [01:07] <Zeros> yeah, that's all I've ever used it for
  223. # [01:08] <Zeros> Screwing with the width in IE6 in an expression() on the body causes a crash in some cases
  224. # [01:08] <Zeros> I think it locked up if you tried to force a min-width
  225. # [01:10] <Philip`> I guess it seemed like a good idea when they first implemented it
  226. # [01:12] <Zeros> It's certainly the next logical step in CSS to someone new to the language. "Why can't I set the value dynamically based on Y element's properties?" The implications it has on the implementors is not a common concern.
  227. # [01:12] <Philip`> It would work alright if you could be like XForms Transitional and specify that the expressions must not have side effects
  228. # [01:13] <Philip`> Write it in Haskell, perhaps
  229. # [01:26] * Joins: sbuluf (gdwwtrc@
  230. # [01:34] * Joins: heycam (cam@
  231. # [01:37] * Joins: mjs_ (mjs@
  232. # [01:38] * Quits: mjs (mjs@ (Ping timeout)
  233. # [01:39] * Joins: mjs (mjs@
  234. # [01:40] * Quits: mjs_ (mjs@ (Ping timeout)
  235. # [01:54] * Joins: mjs_ (mjs@
  236. # [01:56] * Quits: mjs (mjs@ (Ping timeout)
  237. # [02:00] * Quits: gavin (gavin@ (Ping timeout)
  238. # [02:04] * Joins: karl (karlcow@
  239. # [02:05] * Joins: gavin (gavin@
  240. # [02:12] * Quits: Zeros (Zeros-Elip@ (Quit: Leaving)
  241. # [02:13] * Quits: kingryan (rking3@ (Quit: kingryan)
  242. # [02:18] * Joins: mjs (mjs@
  243. # [02:19] * Quits: mjs_ (mjs@ (Ping timeout)
  244. # [02:40] * Joins: mjs_ (mjs@
  245. # [02:42] * Quits: mjs (mjs@ (Ping timeout)
  246. # [02:43] * Quits: robburns (robburns@ (Quit: robburns)
  247. # [02:47] * Joins: olivier (ot@
  248. # [02:49] * Quits: aroben (adamroben@ (Quit: aroben)
  249. # [02:51] * Joins: mjs (mjs@
  250. # [02:53] * Quits: mjs_ (mjs@ (Ping timeout)
  251. # [02:56] * Quits: mjs (mjs@ (Quit: mjs)
  252. # [03:01] * Joins: mjs (mjs@
  253. # [03:15] * Joins: robburns (robburns@
  254. # [03:26] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  255. # [03:34] * Joins: aroben (adamroben@
  256. # [03:34] * Quits: robburns (robburns@ (Quit: robburns)
  257. # [03:35] * Joins: robburns (robburns@
  258. # [03:37] * Quits: robburns (robburns@ (Quit: robburns)
  259. # [03:45] * Joins: robburns (robburns@
  260. # [04:07] * Quits: aroben (adamroben@ (Quit: aroben)
  261. # [04:08] * Quits: gavin (gavin@ (Ping timeout)
  262. # [04:13] * Joins: gavin (gavin@
  263. # [04:20] * Quits: billmason (billmason@ (Connection reset by peer)
  264. # [04:30] * Quits: mjs (mjs@ (Ping timeout)
  265. # [04:31] * Joins: mjs (mjs@
  266. # [04:32] * Joins: Zeros (Zeros-Elip@
  267. # [04:34] * Quits: robburns (robburns@ (Quit: robburns)
  268. # [04:34] * Quits: mjs (mjs@ (Ping timeout)
  269. # [04:38] * Joins: hyatt (hyatt@
  270. # [04:38] * Quits: hyatt (hyatt@ (Client exited)
  271. # [04:38] * Joins: mjs (mjs@
  272. # [04:39] * Joins: hyatt (hyatt@
  273. # [04:42] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
  274. # [04:42] * Joins: Lionheart (robin@
  275. # [04:43] * Quits: dbaron (dbaron@ (Quit: 8403864 bytes have been tenured, next gc will be global.)
  276. # [05:00] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  277. # [05:06] * Joins: robburns (robburns@
  278. # [05:12] * Quits: Lionheart (robin@ (Connection reset by peer)
  279. # [05:21] * Joins: Lionheart (robin@
  280. # [05:28] * Quits: heycam (cam@ (Quit: bye)
  281. # [05:28] * Joins: heycam (cam@
  282. # [05:33] * Quits: mjs (mjs@ (Connection reset by peer)
  283. # [05:33] * Joins: mjs (mjs@
  284. # [05:34] * Quits: hyatt (hyatt@ (Quit: hyatt)
  285. # [05:42] * Joins: hyatt (hyatt@
  286. # [05:44] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
  287. # [05:49] * Quits: Zeros (Zeros-Elip@ (Ping timeout)
  288. # [05:49] * Joins: Zeros (Zeros-Elip@
  289. # [05:51] * Quits: Zeros (Zeros-Elip@ (Quit: Leaving)
  290. # [05:59] * Joins: dbaron (dbaron@
  291. # [05:59] * Quits: dbaron (dbaron@ (Quit: 8403864 bytes have been tenured, next gc will be global.)
  292. # [06:04] * Quits: karl (karlcow@ (Client exited)
  293. # [06:04] * Joins: aroben (adamroben@
  294. # [06:05] * Joins: karl (karlcow@
  295. # [06:06] * Quits: robburns (robburns@ (Quit: robburns)
  296. # [06:06] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  297. # [06:07] * Joins: robburns (robburns@
  298. # [06:19] * Quits: karl (karlcow@ (Client exited)
  299. # [06:20] * Joins: karl (karlcow@
  300. # [06:22] * Quits: karl (karlcow@ (Client exited)
  301. # [06:48] * Joins: karl (karlcow@
  302. # [06:53] * Quits: robburns (robburns@ (Quit: robburns)
  303. # [07:11] * Joins: robburns (robburns@
  304. # [07:36] * Quits: gavin (gavin@ (Ping timeout)
  305. # [07:41] * Joins: gavin (gavin@
  306. # [07:45] <karl> http://vanirsystems.com/danielsblog/?p=193
  307. # [07:50] * Quits: mjs (mjs@ (Ping timeout)
  308. # [07:51] * Joins: mjs (mjs@
  309. # [07:58] <Lachy> "The XHTML2 document seems to be backed by a lot more people than the HTML5 working draft, and I hope that it stays that way" :-)
  310. # [08:00] * Quits: robburns (robburns@ (Quit: robburns)
  311. # [08:02] * Joins: robburns (robburns@
  312. # [08:02] * Joins: mjs_ (mjs@
  313. # [08:04] * Quits: Lachy (chatzilla@ (Ping timeout)
  314. # [08:04] * Quits: mjs (mjs@ (Ping timeout)
  315. # [08:11] * Quits: heycam (cam@ (Quit: bye)
  316. # [08:14] * Hixie comments
  317. # [08:25] <MikeSmith> about danielsblog -- In the spirit of trying to find something good to say: He is naivete is, uh, refreshing...
  318. # [08:26] <MikeSmith> "Some of the things they put in the document are so strange, especially as one of the authors is from Google and the other is from the Safari/WebKit team at Apple!" is the best part, I think
  319. # [08:27] <MikeSmith> I realize he qualifies that in the next sentence.
  320. # [08:28] <MikeSmith> But I think that sentence can also bring some enjoyment when read in isolation.
  321. # [08:48] <karl> MikeSmith: hixie replied
  322. # [08:51] * Quits: aroben (adamroben@ (Quit: aroben)
  323. # [08:53] <MikeSmith> karl - I see -- a much more tactful comment than I would have posted.
  324. # [08:53] * MikeSmith makes 1001st note to self to quit being a smartass all the time
  325. # [08:55] <MikeSmith> I guess my initial reaction when I read stuff like Daniel's post is just to either ignore it or, well, mock it
  326. # [08:58] <MikeSmith> I guess taking time to actually post a thoughtful/helpful comment to it instead is a tiny bit more constructive
  327. # [09:00] * Joins: Lachy (chatzilla@
  328. # [09:13] * Quits: olivier (ot@ (Quit: Leaving)
  329. # [09:22] * Quits: Lionheart (robin@ (Connection reset by peer)
  330. # [09:27] * Quits: karl (karlcow@ (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
  331. # [09:33] * Quits: mjs_ (mjs@ (Ping timeout)
  332. # [09:42] * Quits: gavin (gavin@ (Ping timeout)
  333. # [09:47] * Joins: gavin (gavin@
  334. # [09:47] <MikeSmith> What is the correct name for referring to the group of people working on the ECMAScript standard?
  335. # [09:48] <MikeSmith> Is it the ECMAScript working group, or something else?
  336. # [09:48] <MikeSmith> ECMAScript Committee?
  337. # [10:02] * Joins: heycam (cam@
  338. # [10:10] * Joins: zcorpan_ (zcorpan@
  339. # [10:20] * Joins: mjs (mjs@
  340. # [10:21] <Lachy> robburns, yt?
  341. # [10:22] <Lachy> don't undo my wiki edits. What I added were *real* use cases. The list of beneficiaries is *not*. That's just a list of consumers would would potentially benefit from it.
  342. # [10:23] <Lachy> A use case is a description of a case where some feature would be used, not a description of the people would would benefit when used in some unspecified case
  343. # [10:25] <robburns> Lachy: I think that list of beneficiaries are use cases. We can extrapolate from those how they would use the feature. If it needs more description, it's a wiki. Just add some more description.
  344. # [10:25] <Lachy> no, they're not.
  345. # [10:26] * Parts: zcorpan_ (zcorpan@
  346. # [10:26] <Lachy> A use case isn't about how an end use would use the feature when included, it's about how and why an author would use the featur
  347. # [10:26] <mjs> potential beneficiaries are not use cases
  348. # [10:26] <robburns> According to Wikipedia a use case is :A use case should:
  349. # [10:26] <robburns> describe how the system shall be used by an actor to achieve a particular goal.
  350. # [10:26] <robburns> have no implementation-specific language.
  351. # [10:26] <robburns> be at the appropriate level of detail.
  352. # [10:26] <robburns> Not include detail regarding user interfaces and screens. This is done in user-interface design.
  353. # [10:26] <robburns> http://en.wikipedia.org/wiki/Use_case
  354. # [10:26] <Lachy> the particular goal is what the author is trying to achieve
  355. # [10:26] <mjs> if I make plagiarism detection software, "teacher" and "professor" are not use cases
  356. # [10:27] <mjs> "detecting plagiarism in college papers" would be an example of a use case
  357. # [10:27] <robburns> so add more description to the use cases. Putting example pages in their under the heading use case does no make those use cases. The content that was under that heading was closer to use cases
  358. # [10:28] <Lachy> the box model diagram is a use case http://www.w3.org/TR/CSS21/box.html#box-dimensions - a description of who benefits from that is not
  359. # [10:29] <Lachy> Fine, I'll update it to call the use cases "Diagrams", "Photography" and "Screenshots"
  360. # [10:29] <robburns> is it really that hard to extrapolate from what was written there from "totally blind user" to "totally blind user uses keyboard navigation to navigate to an img; user invokes longdesc from a menu of options; user activates that option; user listens to a a speech synthesizer read the contents of the document or document fragment targeted by the longdesc URL. There now it's a use case.
  361. # [10:30] <mjs> that doesn't really match the wikipedia definition you cited
  362. # [10:31] <robburns> mjs: how does it not match
  363. # [10:31] <robburns> ?
  364. # [10:31] <mjs> it doesn't describe what goal is achieved, and it includes details regarding user interface and implementation
  365. # [10:31] <robburns> Lachy: the box model diagram is an example of an img with a longdesc. It's an example of a document that could be used for this use case
  366. # [10:31] <Lachy> robburns, a use case would be: a user encounters a diagram or flow chart, but cannot see it and need a description.
  367. # [10:32] <robburns> mjs: so should I just say the "system then audibly reads the target of the longdesc URL to the user" without mentioning a speech synthesizer?
  368. # [10:32] <Lachy> well, examples demonstrating use cases are closer to use cases than a description of a beneficiary
  369. # [10:33] <mjs> mentioning longdesc is an implementation detail, as far as the blind user is concerned
  370. # [10:33] <mjs> "get description of image" would be an example of a goal
  371. # [10:33] <robburns> mjs: but aren't we providing use cases for longdesc? If you'd like make it more generic. It's a wiki.
  372. # [10:34] <robburns> Lachy: I think the idea was that putting the beneficiaries in there would make it easy for the rest of us to surmise what the rest of the use case was
  373. # [10:34] <mjs> implementation technologies that might help a screen reader achieve that goal include alt, longdesc, using an <object> tag instead, a D-link like that box model diagram uses, <a rel="longdesc"> around or next to the image, or a text description of the diagram inline in visible content after the image
  374. # [10:35] <robburns> mjs: we have another wiki page devoted to that I believe
  375. # [10:36] * Joins: hendry (hendry@
  376. # [10:36] <mjs> I don't know what page you guys are talking about, and this issue is hardly my top priority
  377. # [10:36] <mjs> so I am not going to edit the wiki
  378. # [10:37] <mjs> but I do care that people understand what a use case actually is
  379. # [10:37] <mjs> enough to be able to generate one, and to understand what is and isn't one
  380. # [10:37] <Lachy> mjs, this page http://esw.w3.org/topic/HTML/LongdescRetention
  381. # [10:37] <robburns> mjs: Oh, I see its that same page. I thought you were saying that page lept to the longdesc solution
  382. # [10:37] <mjs> since that will come up again and again
  383. # [10:37] <robburns> mjs: you were just saying you wanted me to leave longdesc out of my impromptu use case
  384. # [10:37] <mjs> robburns: I'm not saying anything about the page, just that the expansion of "totally blind user" you provided is not a good example of a use case
  385. # [10:38] <robburns> mjs: that's fine. forget I mentioned longdesc or even urls
  386. # [10:38] <robburns> mjs: ok
  387. # [10:39] <robburns> mjs: but providing an even more specific instance of what I described (the CSS recommendation) is even more specific, so how can mine be too specific but Lachy's (which is more specific) is ok
  388. # [10:39] <mjs> when speaking of alternative content, you could think of use cases from both the user and the author perspective
  389. # [10:39] <mjs> example of a user use case:
  390. # [10:40] <mjs> - blind user using a screen reader encounters content that includes an image, and wants to hear a description of it
  391. # [10:40] <robburns> mjs: that's a bit silly. The author use case is an author wants to convey something to a blind user using our markup language
  392. # [10:40] <mjs> example of an author use case:
  393. # [10:41] <mjs> - author wants to include an image with alternative content for users that can't see the image, for reason of disability or technological limitation
  394. # [10:41] <robburns> mjs: I'd say those use cases on the page were about the same as what you described.
  395. # [10:42] <robburns> mjs: well those are much more general than providing examples of authors producing content that could potentially meet those use cases
  396. # [10:42] <mjs> you could refine the author one by giving more specific about cases where a long description specifically would be beneficial, and where you might want a separate short description
  397. # [10:43] <mjs> looking at the page now, the examples cited seem to me like different cases where a long description could be particularly beneficial
  398. # [10:43] <robburns> mjs: OK
  399. # [10:44] <mjs> they illustrate different kinds of complex content where a long description might be especially apt, because they are complex but could still be described in words
  400. # [10:44] <mjs> use cases from the user's perspective also often make sense
  401. # [10:44] <mjs> because they help you think about cases where the author didn't do a good job
  402. # [10:45] <robburns> mjs: are you talking about Lachy's use cases or the original use cases (what Lachy placed undere beneficiaries)
  403. # [10:46] <robburns> mjs: the example web pages that Lachy put up there are not use cases by any stretch of the imagination
  404. # [10:46] <robburns> mjs: they are example web pages making use of longdesc
  405. # [10:46] <mjs> they are illustrative examples of authoring use cases
  406. # [10:46] <robburns> mjs: as you pointed out, that page isn't about specifically longdesc
  407. # [10:46] <mjs> (IMO)
  408. # [10:46] <Lachy> robburns, how is an example/description of when a long description would be useful, not a use case?
  409. # [10:47] <robburns> mjs: no they're not by any stretch of the imagination
  410. # [10:47] <robburns> Lachy: I got chewed out for mentioning implementation details like a menu or an url or an attribute called longdesc. So examples are way way way too specific to be called use cases
  411. # [10:47] * Lachy updates the wiki to make them close to use cases
  412. # [10:48] <mjs> robburns, Lachy: IMO it would be better to first state the general category each one is meant to illustrate
  413. # [10:48] <robburns> Lachy: the page is devoted to alternate equivalent fallback text for non-text media. Those are some fine examples of pages using longdesc to solve that use case
  414. # [10:48] <Lachy> longdesc="" is an implementation detail. Describing cases where a description is valuable is a use case
  415. # [10:48] <mjs> "technical diagrams / flowcharts", "screenshots of user interface", etc
  416. # [10:49] <Lachy> robburns, the first doesn't only use longdesc and the second doesn't use longdesc at all
  417. # [10:49] <mjs> the CSS example actually doesn't use longdesc at all
  418. # [10:49] <mjs> and has somewhat stylistically poor alt text for that matter
  419. # [10:49] <robburns> mjs: I don't really find those categories all that useful. The point tis that for non-text content in general (if it's not merely decorative or iconic) requires a description (potentially long) for those unable to view the non-text media to make sense of the document.
  420. # [10:50] <Lachy> robburns, we need to know what kind of non-text content that applies to
  421. # [10:50] <mjs> robburns: tragically the page is titled LongdescRetention, which makes it seem like it's specifically about providing long descriptions, not just the kind of alternative content easily provided for by alt
  422. # [10:50] <robburns> Lachy: that's fine. And there good examples of documents using existing HTML features. They're just not use cases.
  423. # [10:51] <robburns> Lachy: it applies to all non-text content that is not merely decorative or iconic
  424. # [10:52] <robburns> mjs: that was the original page name. But it has been repurposed for this other broader problem/use case
  425. # [10:52] <robburns> Lachy: though the page is mostly focussed on still images
  426. # [10:53] <mjs> the page includes "Strategies for Exposing LONGDESC"
  427. # [10:53] <mjs> "Thoughts on LONGDESC and Inline Fallback Content"
  428. # [10:53] <mjs> it looks like it is all about longdesc and mechanisms with similar purposes
  429. # [10:54] <mjs> I don't think having <img alt=""> is controversial or debateable
  430. # [10:55] <mjs> so I think the interesting discussion to be had is whether there are situations where longdesc fulfills an important role that alt can't handle
  431. # [10:55] <mjs> (or some similar way to have a marked-up but possibly external description)
  432. # [10:57] <robburns> mjs: some of the discussion of longdesc predates the repurposing of the page (people are reluctant to edit or delete other's prose on the siki)
  433. # [10:57] <robburns> mjs: but yes it is about longdesc or mechanisms with similar purpose. That is the use case or problem statement the page is about.
  434. # [10:58] <robburns> mjs: on <img alt> you can see the pros and cons listed on the page. Many of those relate to the problems with <img alt>
  435. # [10:59] <mjs> robburns: so in that case, it seems very useful to give examples of content where a long description mechanism might give more benefits than alt
  436. # [10:59] <robburns> mjs: the problems with solving this for img is the reason embed should not be added to document conformance IMO
  437. # [10:59] <robburns> mjs: indeed the examples are great.
  438. # [11:00] <robburns> mjs: and some more would be good too
  439. # [11:00] <mjs> and if those examples are illustrations of general categories of the kind of content that would benefit, then those categories would be authoring use cases
  440. # [11:01] * Joins: beowulf (beowulf@
  441. # [11:02] <robburns> mjs: well that's what I called them (in parenthesis). I called them notable examples in the main heading. However, I have a hard tim construing those as author use cases after the discussion we just had where I used to many implementation details. These examples are fully specified implementation details. There's nothing left to specify.
  442. # [11:05] * Joins: olivier (ot@
  443. # [11:06] <mjs> I'm not calling them use cases - I think they are examples that could illustrate authoring use cases for a long description mechanism
  444. # [11:06] * Joins: tH (Rob@
  445. # [11:06] <mjs> I expect Lachy will be glad to improve the page, after all he already contributed to it
  446. # [11:07] <robburns> mjs: I would agree with that. Illustrative examples might be a good heading
  447. # [11:08] * Joins: zcorpan_ (zcorpan@
  448. # [11:09] <Lachy> robburns, I already updated them to describe use cases, giving those as examples. Is it acceptable now?
  449. # [11:16] <robburns> Lachy: I still don't think those are use cases. Those are notable examples of authors using existing HTML features to accomplish the use cases detailed on this page. The beneficiaries are closer to use cases. Except they require the reader to understand that those beneficiaries (the users in the use case) will then use a system to access alternate textual descriptions of still images.
  450. # [11:16] <Lachy> the beneficiaries aren't even close
  451. # [11:17] <Lachy> describing cases where it would be useful to provide long descriptions of images are the use cases that are really interesting.
  452. # [11:18] <robburns> Lachy: well I've long been saying that problem statement is a better way to approach this (in drafting a specification like HTML). Those bullets are the problem statement. How do we get meaningful content to blind users, legally blind users, vision impaired users and users of non-graphical browsers. I suppos they could use some rewording, but the look like use cases / problem statements to me.
  453. # [11:19] <robburns> Lachy: I'm not saying your examples are not interesting. And they definitely illustrate solutions to the problem (at least partial solutions). But that doesn't make them descriptions of the problem or descriptions of the use case
  454. # [11:19] <Lachy> robburns, we need to know which cases require longer descriptions than can be provided with alt="".
  455. # [11:21] <Lachy> the relevant use cases are the potential cases where an author could actually make good use of longdesc="" (or other solution)
  456. # [11:21] <Lachy> we need to be looking at the use cases from an authoring perspective
  457. # [11:22] * Parts: zcorpan_ (zcorpan@
  458. # [11:22] <robburns> Lachy: there's no hard and fast rule on the alt description. Sander proposes adding one for HTML5
  459. # [11:22] <robburns> http://esw.w3.org/topic/HTML/LongdescRetention#head-ef01c5377a967ead313aeecea431de086517670a
  460. # [11:23] <robburns> Lachy: I'm fine if you want to include the examples amidst the use cases. However, the part you're calling beneficiaries are descriptions of the cases where this use is needed. They are use case.
  461. # [11:24] <Lachy> no, they're not use cases at all and you haven't successfully explained how they even could be considered as such
  462. # [11:25] <Lachy> they're closer to problems that need to be addressed for the use cases
  463. # [11:26] <Lachy> where the use cases are diagrams, flowcharts, etc. i.e. cases where relevant images would be used. The descriptions of who can't see them and why they need alternative content are problems to be addressed
  464. # [11:28] <Lachy> Would you be happy with renaming Beneficiaries to Problem Statements or something like that?
  465. # [11:29] <robburns> Lachy: sure that would be fine. However, I think those should come first before the concrete examples.
  466. # [11:29] <Lachy> but then they'd need to be rephrased to explain why they are problems. e.g. why does a data mining tool need an additional description, beyond the context given in the page? Do search engines actually look at longdesc?
  467. # [11:29] <Lachy> use cases come before problems
  468. # [11:31] <robburns> Lachy: I don't know if search engines look at longdesc. From the sample pages looked at so far, I would say it may be too poorly understood by authors to be useful to a search engine. However, there is a problem that search engines cannot do a text index of an image that could get addressed by the same solution to this problem
  469. # [11:31] <robburns> On use cases, again from wikipedia (this time hopefully it pastes better): A use case should: 1) describe how the system shall be used by an actor to achieve a particular goal. 2) have no implementation-specific language. 3) be at the appropriate level of detail. 4) Not include detail regarding user interfaces and screens. This is done in user-interface design.
  470. # [11:33] <Lachy> the relevant *actor* is the author, not the end user in this case
  471. # [11:37] <robburns> Lachy: OK. But even for the author, then we're talking about a use case that describes how the author interacts with a system to produce content for consumption through text only or audible only means. Providing examples of documents that were authored through a fulfillment of that use case does not make them use cases.
  472. # [11:38] <Lachy> hold on, I'm updating the wiki again to describe them in technologically-independent terms (i.e. no implementation details)
  473. # [11:38] * Joins: icaaq (icaaaq@
  474. # [11:48] * Parts: icaaq (icaaaq@
  475. # [11:49] * Quits: gavin (gavin@ (Ping timeout)
  476. # [11:52] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
  477. # [11:54] * Joins: gavin (gavin@
  478. # [11:55] * Joins: ROBOd (robod@
  479. # [11:58] <Lachy> robburns, I updated it. Let me know if that's better
  480. # [12:00] * Quits: olivier (ot@ (Quit: Leaving)
  481. # [12:04] * Quits: gsnedders (gsnedders@ (Connection reset by peer)
  482. # [12:08] <robburns> Lachy: that's fine. perhaps I'll add a link to wikipedia or some more concrete description of a use case. However, I think prototypical users described there would be integral pars off any elaboration of a use case. You're parenthetical comment: makes it sound like that's not the case "(not a description of the people who would benefit from them)".
  483. # [12:10] <Lachy> I'm glad we can finally reached a compromise :-)
  484. # [12:27] <robburns> :-)
  485. # [12:35] * Quits: jmb (jmb@ (Quit: Reconnecting)
  486. # [12:35] * Joins: jmb (jmb@
  487. # [12:42] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  488. # [12:51] * Quits: sbuluf (gdwwtrc@ (Quit: sbuluf)
  489. # [13:02] * Joins: zcorpan_ (zcorpan@
  490. # [13:17] * Joins: matt (matt@
  491. # [13:26] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
  492. # [13:30] * Quits: Lachy (chatzilla@ (Quit: ChatZilla [Firefox])
  493. # [13:35] * Quits: ROBOd (robod@ (Quit: http://www.robodesign.ro )
  494. # [13:44] * Joins: ROBOd (robod@
  495. # [13:52] * Joins: Lachy (chatzilla@
  496. # [13:56] * Quits: gavin (gavin@ (Ping timeout)
  497. # [13:57] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  498. # [14:01] * Joins: gavin (gavin@
  499. # [14:07] * Quits: matt (matt@ (Quit: matt)
  500. # [14:21] * Joins: matt (matt@
  501. # [14:25] * Quits: matt (matt@ (Quit: matt)
  502. # [14:28] * Joins: thorny63 (thorny63@
  503. # [14:29] * Quits: thorny63 (thorny63@ (Quit: Terminated with extreme prejudice - dircproxy 1.0.5)
  504. # [14:34] * Joins: Lionheart (robin@
  505. # [14:42] * Quits: Lionheart (robin@ (Connection reset by peer)
  506. # [14:48] * Quits: robburns (robburns@ (Quit: robburns)
  507. # [14:50] * Joins: thorny63 (thorny63@
  508. # [14:50] * Parts: thorny63 (thorny63@
  509. # [14:52] * Joins: Lionheart (robin@
  510. # [14:56] * Joins: polin8 (polin8@
  511. # [14:57] * Quits: Lionheart (robin@ (Quit: Leaving.)
  512. # [15:12] * Joins: robburns (robburns@
  513. # [15:31] * Quits: polin8 (polin8@ (Quit: polin8)
  514. # [15:44] * Joins: matt (matt@
  515. # [15:53] * Quits: Lachy (chatzilla@ (Ping timeout)
  516. # [15:59] * Joins: Lachy (chatzilla@
  517. # [16:03] * Quits: Lachy (chatzilla@ (Ping timeout)
  518. # [16:03] * Quits: gavin (gavin@ (Ping timeout)
  519. # [16:08] * Joins: gavin (gavin@
  520. # [16:09] * Joins: Lachy (chatzilla@
  521. # [16:15] * Quits: Lachy (chatzilla@ (Ping timeout)
  522. # [16:21] * Joins: Lachy (chatzilla@
  523. # [16:31] * Quits: Lachy (chatzilla@ (Ping timeout)
  524. # [16:34] * Joins: Lachy (chatzilla@
  525. # [16:35] * Joins: billmason (billmason@
  526. # [16:38] * Quits: beowulf (beowulf@ (Ping timeout)
  527. # [16:57] * Joins: Lionheart (robin@
  528. # [16:59] * Joins: gsnedders (gsnedders@
  529. # [17:05] * Joins: billyjack (MikeSmith@mcclure.w3.org)
  530. # [17:07] * Quits: robburns (robburns@ (Ping timeout)
  531. # [17:07] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
  532. # [17:07] * Joins: myakura (myakura@
  533. # [17:09] * billyjack is now known as MikeSmith
  534. # [17:33] * Joins: robburns (robburns@
  535. # [17:35] * Joins: billyjack (MikeSmith@mcclure.w3.org)
  536. # [17:37] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
  537. # [17:37] * billyjack is now known as MikeSmith
  538. # [17:41] * Quits: gsnedders (gsnedders@ (Quit: Don't touch /dev/null…)
  539. # [17:42] * Quits: Lionheart (robin@ (Connection reset by peer)
  540. # [17:55] * Joins: Lionheart (robin@
  541. # [17:55] <MikeSmith> geez, do we want public-html to become a forum for open letters...
  542. # [17:56] * Joins: gsnedders (gsnedders@
  543. # [17:57] * Parts: Lionheart (robin@
  544. # [17:59] <Lachy> this link came to mind when I read that http://tantek.pbwiki.com/TrollTaxonomy#Bureaucraytroll
  545. # [18:00] <Lachy> what right does Philip have to question what someone posts on their own blog?
  546. # [18:00] <MikeSmith> Lachy, hey man, he's doing public service
  547. # [18:01] <MikeSmith> calling out Anne VK's "irresponsibility"
  548. # [18:01] * Quits: myakura (myakura@ (Quit: Leaving...)
  549. # [18:02] <Lachy> unfortunately, Anne's not here to defend himself, he's on holiday
  550. # [18:03] <gsnedders> and what was this about public-html being for technical issues? I see no copy of it on www-archive also sent to the chairs.
  551. # [18:04] <Philip`> Lachy: I don't see the problem with members of the group disagreeing with what someone posts on their own blog, if the post is related to the group
  552. # [18:05] <Lachy> nor do I, but it's the way he said it and called it irresponsible
  553. # [18:05] <MikeSmith> Philip` - but is public-html where we want a discussion about something like that to take place?
  554. # [18:06] <MikeSmith> Lachy - but he didn't explicitly call it irresponsible, he asked Anne if he thinks it's irresponsible...
  555. # [18:07] <MikeSmith> How many characters do you think it will take Anne to respond to that question?
  556. # [18:07] <MikeSmith> I say, 2
  557. # [18:07] <MikeSmith> 3, if he adds the optional period
  558. # [18:07] <Philip`> Lachy: You should qualify the "what right does Philip have to question what someone posts on their own blog?" statement to be explicit about what the actual problems with his email are, rather than just sounding like he should ignore everyone's blogs
  559. # [18:07] <gsnedders> MikeSmith: under the current rules from the chairs, he should've sent a copy to the chairs + www-archive asking to post it to public-html
  560. # [18:07] <Lachy> He didn't actually express any technical argument for or against <input usemap> or state whether or not he agrees with the decision. He just raised bureaucratic process issues
  561. # [18:08] <MikeSmith> gsnedders - true that
  562. # [18:08] <gsnedders> IMO it really should've been directly to Anne
  563. # [18:08] * Lachy agrees
  564. # [18:09] <gsnedders> it's not a WG issue. it's an issue of the behaviour of one person outside of the WG
  565. # [18:10] * Quits: gavin (gavin@ (Ping timeout)
  566. # [18:10] <Philip`> It's not really one person - it's all the 'WHATWG people' (not quite sure how that is defined) deciding (or agreeing with the decision) to drop something from HTML5
  567. # [18:11] <MikeSmith> well, it's hard to see what Webmaster expects the productive outcome of posting it to public-html to be
  568. # [18:11] <Philip`> (rather than discussing it with the 'outsiders' in the HTML WG)
  569. # [18:12] <MikeSmith> that it wouldn't have been if he had just sent it directly to AVK
  570. # [18:12] <Lachy> I think 'WHATWG people' is defined as Hixie, Anne, Henri, Simon, myself, etc. and anyone else who agrees with us.
  571. # [18:12] * Joins: polin8 (polin8@
  572. # [18:16] * Joins: gavin (gavin@
  573. # [18:18] * Joins: aroben (adamroben@
  574. # [18:20] * Joins: beowulf (beowulf@
  575. # [18:20] <Philip`> Some of his comments in the design principles survey appear to be arguing against the group's charter and its decision to adopt the WHATWG specs, which really doesn't seem helpful and doesn't suggest that he'll accept HTML WG decisions any more than WHATWG decisions
  576. # [18:21] <beowulf> does philip TAYLOR have an email quota to the html-wg to meet or something?
  577. # [18:21] <gsnedders> and isn't it the case that a closed issue cannot be reopened unless explicitly done so by the chairs?
  578. # [18:23] <Lachy> I find this surprising: "I strongly disagree that "We need to define processing requirements that remain compatible with the expected handling of such content."" - I wonder how he'd react if upgraded his browser and his favourite sites no longer worked
  579. # [18:24] <Philip`> I would expect his favourite sites are all valid HTML 4.01
  580. # [18:24] <Lachy> although, I shouldn't be too surprised, since he's not the only one to express that opinions
  581. # [18:24] <Lachy> I wonder which bank he uses? Or if he uses Google?
  582. # [18:25] <Lachy> I'm yet to see a bank use conforming HTML
  583. # [18:27] <MikeSmith> many bank sites only work in IE anyway, so they could just as well be written in VBML
  584. # [18:28] <Lachy> he's still clinging to the argument that "[<br/>] has totally different meanings in HTML and in XHTML"
  585. # [18:29] * Joins: polin8_ (polin8@
  586. # [18:29] <MikeSmith> Reading Richard Ishida's comment on the DPs, I think implementation-driven development of the spec has always been sort of a given
  587. # [18:30] <MikeSmith> not sure that "Collaborate with implementers" needs to be stated explicitly
  588. # [18:30] * Quits: polin8 (polin8@ (Ping timeout)
  589. # [18:31] <MikeSmith> but if it does, "collaborate" seems to me to not be a strong enough description of what the process is
  590. # [18:31] <gsnedders> MikeSmith: it's in our charter
  591. # [18:31] <gsnedders> "If fewer than three implementors (i.e., browser vendors) are participating in the Working Group, its charter should be re-examined by the W3C."
  592. # [18:33] <MikeSmith> gsnedders - yeah, there's that too
  593. # [18:33] <gsnedders> which kinda forces us to collaborate
  594. # [18:34] <gsnedders> and if we just define an SGML language, I doubt any implementors will stay
  595. # [18:34] <Lachy> ha! Apparently I'm not open to alternative points of view
  596. # [18:34] <gsnedders> Lachy: My name is Malcolm from hereon.
  597. # [18:34] <MikeSmith> no, the charter doesn't actually require us to pay any attention to implementors, we just need to keep them around in case they come in handy if we have stuff we want them to do
  598. # [18:34] <Lachy> gsnedders, what?
  599. # [18:35] <gsnedders> Lachy: your POV of my name is changing!
  600. # [18:35] <gsnedders> MikeSmith: ww'll leave if we don't pay attention to them though
  601. # [18:35] <gsnedders> *we
  602. # [18:36] <Lachy> gsnedders, am I supposed to object to you changing your name?
  603. # [18:36] <gsnedders> Lachy: no, you're just meant to be open to me changing my name, and you changing your POV of my name
  604. # [18:36] <Lachy> aargh! noooo! "I suggest Robert Burns <rob@robburns.com>, Joshue O Connor <joshue.oconnor@cfit.ie>, and Philip Taylor <P.Taylor@rhul.ac.uk> to work on this document."
  605. # [18:36] <gsnedders> Lachy: forget it. I've confused you too much :)
  606. # [18:36] <MikeSmith> let them go -- they we can start the fun all over again from scratch with a new charter
  607. # [18:37] <MikeSmith> Lachy, whose suggestion is that?
  608. # [18:37] <Lachy> though, if she didn't qualify that with the email address, I'd agree with the last nomination ;-)
  609. # [18:37] <Lachy> Laura Carlson
  610. # [18:37] <MikeSmith> well, on a more serious side...
  611. # [18:37] <gsnedders> "this document" == ?
  612. # [18:38] <Philip`> I'd be useless since I'm totally unprincipled :-p
  613. # [18:38] <gsnedders> Philip` Principles: obey your masters (e.g., each and every member of the WG)
  614. # [18:38] <MikeSmith> If I write a letter titled "An open letter to Philip Taylor (Webmaster) about his open letter to Anne van Kesteren", and I post that to public-html...
  615. # [18:39] <MikeSmith> can one of you please reply with an open letter to me about that?
  616. # [18:39] <gsnedders> MikeSmith: I wouldn't. Maybe do so, and CC it to www-archive, though.
  617. # [18:40] <Lachy> let's all write open letters to each other
  618. # [18:40] <beowulf> yay!
  619. # [18:40] <beowulf> open letter day
  620. # [18:40] <gsnedders> paper!
  621. # [18:40] <gsnedders> paper!
  622. # [18:40] <gsnedders> paper!
  623. # [18:40] <Lachy> ;-)
  624. # [18:40] <gsnedders> (on an unrelated note, I didn't get the top grade for practical computing at school)
  625. # [18:40] * Joins: jgraham_ (jgraham@
  626. # [18:41] <Lachy> gsnedders, did you get 2nd?
  627. # [18:41] <beowulf> can we also make sure to call html authors lazy and ignorant and any other elitist language you find...
  628. # [18:41] <gsnedders> Lachy: yes. probably lost marks for being better than the answers in parts :P
  629. # [18:41] * beowulf bites tongue
  630. # [18:41] <gsnedders> Lachy: well, not in the practical.
  631. # [18:42] <Lachy> beowulf, we should just say how irresponsible this discussion we're having is
  632. # [18:42] <gsnedders> the practical is done in such a way that being ill for nearly the entire course meant I had less than a week to do the entire practical. Have to do it all to get the top grade :(
  633. # [18:44] <DanC> re open letter... http://lists.w3.org/Archives/Public/www-archive/2007Aug/0042.html
  634. # [18:48] <MikeSmith> DanC - and I see he responded -
  635. # [18:48] <MikeSmith> http://lists.w3.org/Archives/Public/www-archive/2007Aug/0043.html
  636. # [18:49] <Lachy> I don't see what relevance him speaking positively of Anne in the survey is
  637. # [18:49] <beowulf> vendetta?
  638. # [18:49] <beowulf> huh?
  639. # [18:51] * MikeSmith wishes we could get this other Philip Taylor to join the #html-wg channel
  640. # [18:51] * beowulf also
  641. # [18:51] <MikeSmith> it might save him a lot of time posting stuff to the list
  642. # [18:51] <MikeSmith> if he could just talk to people directly here
  643. # [18:51] <Lachy> do you think it would productive for him?
  644. # [18:52] <Lachy> and for us?
  645. # [18:52] <MikeSmith> Lachy - yeah, definitely
  646. # [18:52] <Lachy> maybe, it is sometimes useful to discuss issues in real time to resolve them, instead of trying over email
  647. # [18:53] <MikeSmith> He could have direct discussions with everybody here
  648. # [18:54] <MikeSmith> And, I mean, if he were on the channel, it would become sorta absurd to consider posting an open letter to somebody he could just talk with directly here any time he wanted to
  649. # [18:54] <jgraham_> MikeSmith, direct discussions f2f are more human than via IRC so I guess more effective at solving personality conflicts
  650. # [18:54] <Lachy> but IRC is slightly more human than email is too, so it would probably be an improvment
  651. # [18:57] <Lachy> I wonder if it would be worthwhile talking to Philip about his accusation that I'm not open to other POVs, or whether I should just consider it flamebait
  652. # [18:57] <gavin_> I don't think IRC is any more "human" than email
  653. # [18:57] * Joins: Lionheart (robin@
  654. # [18:58] <gavin_> still impossible to use visual (or even auditory) cues to gauge emotion
  655. # [18:58] <beowulf> Lachy: flamebait
  656. # [18:58] <Lachy> gavin. that
  657. # [18:58] <Lachy> that's what emoticons are for
  658. # [18:59] <gavin_> emoticons are entirely insufficient :)
  659. # [19:00] <MikeSmith> jgraham_ - would that direct discussions f2f were practical for resolving these kinds of issues
  660. # [19:00] <gsnedders> <http://geoffers.uni.cc/archives/2007/03/12/desire/> — the meaning of that is actually totally lost, simply because the emotion behind it is completely unclear
  661. # [19:00] <gsnedders> text has limitations in any form
  662. # [19:00] <Lachy> they seem to cover the full range of emotions from sad: :-( to grumpy :-| to happy: :-)
  663. # [19:01] <MikeSmith> jgraham_ - I meant, that it were possible/practical to get people together more often
  664. # [19:01] <gavin_> I'm not expert, but I've read that the conscious and even subconscious cues you get watching someone's face as they speak are fairly significant
  665. # [19:01] <DanC> understatement
  666. # [19:01] <gsnedders> they can provide the entire context of something.
  667. # [19:02] <gsnedders> In what I just linked to, just seeing me crying would give the meaning back to it.
  668. # [19:02] <jgraham_> Lachy, "not everyone has the emotion range of a teaspoon"
  669. # [19:02] * jgraham_ misquotes? Harry Potter
  670. # [19:02] <Lachy> ;-)
  671. # [19:02] <gsnedders> jgraham: correct quote, I think
  672. # [19:03] <gsnedders> (I really shouldn't be admitting that I think that the quote is right)
  673. # [19:03] <Lachy> jgraham_, looks like it's the correct quote http://community.livejournal.com/hp_spoons/
  674. # [19:03] <jgraham_> MikeSmith, It's undoubtedly an issue we have to get past because ATM I think that mistrust is impeding the ability of the group to pull together
  675. # [19:05] <jgraham_> Lachy: Well I was pretty close anyway
  676. # [19:07] * Quits: Lionheart (robin@ (Connection reset by peer)
  677. # [19:15] <MikeSmith> jgraham_ - I guess that's true, but that's not an issue unique to this group. I think some other big groups of people have managed to get useful work done together primarily through e-mail discussion, without it degrading into name-calling and cat fighting.
  678. # [19:17] <MikeSmith> Anyway, I just e-mailed Philip to suggest he might want to join #html-wg some time
  679. # [19:17] <MikeSmith> http://www.w3.org/mid/20070823171155.GA7840@mikesmith
  680. # [19:19] <MikeSmith> I realize there is a downside to encouraging new people to join who may not be hip to the IRC culture and who the rest of us might not be well aligned with in terms of what are views are on how to solve the problems we need to solve...
  681. # [19:21] <MikeSmith> ...but it the plus side is reducing the amount of unproductive communication in public-html a bit, and helping people to actually get to know each other a little better (short of actually being able to meet f2f), well, I think (hope) it might be worth it
  682. # [19:21] <zcorpan_> today i've been writing test cases for... content-type sniffing... and processing of HTML color attributes. yay :)
  683. # [19:21] * Lachy looks forward to his response
  684. # [19:22] * Joins: kingryan (rking3@
  685. # [19:22] <zcorpan_> re the australian flag thing, one would just say "go to the australian site"
  686. # [19:23] <Lachy> that's what I thought
  687. # [19:23] <beowulf> a few of the alt text examples i've seen look more like captions to me, text that should be displayed with the image not instead of it
  688. # [19:24] <Lachy> I don't think someone would give visually oriented instructions to a friend, whom they would presumably know was blind
  689. # [19:24] <zcorpan_> i wouldn't give such instructions even to someone who can see
  690. # [19:25] <beowulf> actually, captions would be better than alt tags i think, that way you've a chance of us lazy html authors actually using them
  691. # [19:25] <Lachy> I would in addition to saying "go to the Australian site" if they were unable to figure it out. I've given instructions like that to my mum some times :-)
  692. # [19:26] <DanC> all this accessibility stuff... I never envied the chairs of WAI WGs. None of this stuff has crisp black/white answers. My training is in math and computer science. The whole toolbox I've built up over the years is largely useless on these issues.
  693. # [19:28] * Joins: Lionheart (robin@
  694. # [19:33] * Joins: tH_ (Rob@
  695. # [19:34] * Quits: tH (Rob@ (Ping timeout)
  696. # [19:34] * tH_ is now known as tH
  697. # [19:38] * Quits: zcorpan_ (zcorpan@ (Ping timeout)
  698. # [19:42] <mjs> Lachy: wow, people love reverting your edits to that longdesc page
  699. # [19:44] * Quits: mjs (mjs@ (Quit: mjs)
  700. # [19:44] <Lachy> wow! I made those edits to help improve that page. oh well, if they want to make it worse and not provide the use cases at the top, that's their problem
  701. # [19:45] * Quits: aroben (adamroben@ (Quit: aroben)
  702. # [19:45] <Lachy> Gregory completely removed my use cases, and shifted the examples right to the end
  703. # [19:45] * Joins: aroben (adamroben@
  704. # [19:50] <MikeSmith> ah, and now another message cross-posted to four different mailing lists, demanding a response
  705. # [19:50] <Lachy> and again it's directed at me!
  706. # [19:50] <Lachy> and Hixie
  707. # [19:50] * billmason is curious how many times Hixie has to announce how much email backlog he has before people get it
  708. # [19:51] <Philip`> http://canvex.lazyilluminati.com/misc/issueage.html
  709. # [19:51] <Philip`> (Don't ask me why one issue is apparently 491 months old)
  710. # [19:52] <MikeSmith> yeah, and if you respond to it, you get to enjoy perpetuating combative threads on four lists instead of just one
  711. # [19:52] <Lachy> I'm choosing not to respond this time
  712. # [19:52] <kingryan> Philip`: 491 months would be 1967. I'm sure there were html issues then. :)
  713. # [19:52] <Lachy> I don't see it doing any good
  714. # [19:53] <Philip`> Hixie: <19700101011405970191.5386b4d6@empyree.org> has a timestamp of 845 seconds since the epoch
  715. # [19:53] * MikeSmith contemplates replying to the sender with a "Have you considered trying #html-wg" message ...
  716. # [19:53] <MikeSmith> Lachy - you are making the right choice, I think
  717. # [19:54] <MikeSmith> at least not responding to it on the list(ssss)
  718. # [19:54] <MikeSmith> extra "s" for all the extra lists cross-posted to
  719. # [19:56] <Philip`> The mean age of the issues currently in the list is 10.1 months
  720. # [19:56] <Philip`> Oh, maybe I should get rid of the four-decade one first
  721. # [19:58] <Philip`> The mean age of the issues currently in the list is 10.0 months
  722. # [19:59] <Philip`> (longer that the HTML WG's lifetime)
  723. # [19:59] <gsnedders> big change for a mean
  724. # [19:59] <gsnedders> (with such an out of proportion item)
  725. # [19:59] <gsnedders> </sarcasm>
  726. # [19:59] <Philip`> (*Longer than the ...)
  727. # [20:09] <Lachy> hmm. It seems Gregory totally misunderstands what a use case is and misunderstood the reason I included his photo album.
  728. # [20:09] <Philip`> <p> sounds naughty - I think we should rename it to <para>
  729. # [20:09] * Lachy will respond tomorrow.
  730. # [20:09] <Lachy> good night all
  731. # [20:09] <MikeSmith> Philip` - or <pp>
  732. # [20:09] <MikeSmith> Lachy - 'night
  733. # [20:12] <MikeSmith> kingryan - I came up with idea of HTML back in 1967 while smoking grass with Abbie Hoffman in MacArthur Park
  734. # [20:13] <MikeSmith> but not the issues, because we weren't into "issues" and negativity back then
  735. # [20:15] * Quits: jgraham_ (jgraham@ (Quit: This computer has gone to sleep)
  736. # [20:15] <robburns> Lachy: I thought we established earlier that you did not understand what a use-case was. I pointed out the Wikipedia article and I thought we decided those were examples you provided and not use cases
  737. # [20:16] <Lachy> robburns, it is you who doesn't understand what a use case is
  738. # [20:16] <robburns> Lachy: OK (LOL)
  739. # [20:17] <MikeSmith> robburns - hi
  740. # [20:17] <Lachy> a use case is a situation in which a feature would be used. Describing those situations are use cases. Describing who benefits from the feature, or the people who require a certain feature are not.
  741. # [20:18] <robburns> MikeSmith: hi
  742. # [20:19] * Quits: gavin (gavin@ (Ping timeout)
  743. # [20:19] <robburns> Lachy: However to describe a situation in which a feature would be used one has to describe the prototypical user and how that user interacts with the system. Hence a totally blind user does a in order to achieve b.
  744. # [20:19] <MikeSmith> s/Abbie Hoffman/Al Gore/
  745. # [20:20] <robburns> Lachy: linking to a website that makes use of existing HTML 4.01 features is not a use-case
  746. # [20:20] <Lachy> it's an example that demonstrates the use case
  747. # [20:20] <robburns> OK., it's an example. That's what I thought we established before.
  748. # [20:21] <robburns> Lachy: the use case is the more abstract description of how a user interacts and what the needs of the user would be
  749. # [20:21] <MikeSmith> robburns - can I interject a question for a second here?
  750. # [20:21] <MikeSmith> a general question
  751. # [20:21] <robburns> Lachy: the stuff Gregory has there that you call beneficiaries is much closer to a use case than are the example web pages you provided.
  752. # [20:21] <Lachy> you're thinking in terms of the end user, whereas we need to be looking at it from the perspective of authors and their publishing needs
  753. # [20:21] <Lachy> no, it's not
  754. # [20:21] <robburns> MikeSmith: sure go ahead
  755. # [20:22] <Lachy> I'm not repeating this discussion with you, it won't get us anywhere because you're not listening
  756. # [20:22] <robburns> Lachy: in this case authors and their publishing needs are driven by the user and their using needs
  757. # [20:22] * Joins: hasather (hasather@
  758. # [20:22] <MikeSmith> robburns - As far as starting out a discussion with somebody by saying, " I thought we established earlier that you did not understand what a use-case was."
  759. # [20:24] * Joins: gavin (gavin@
  760. # [20:26] <robburns> MikeSmith: what was your question?
  761. # [20:27] <MikeSmith> I assume you intended that as a sort of joke?
  762. # [20:28] <MikeSmith> That comment, I mean.
  763. # [20:28] <robburns> MikeSmith: I thought the conversation started when Lachy said: "hmm. It seems Gregory totally misunderstands what a use case is and misunderstood the reason I included his photo album."
  764. # [20:29] * Quits: hyatt (hyatt@ (Quit: hyatt)
  765. # [20:29] <robburns> MkeSmith: or earlier today when Lachy and I had a long conversation where i t turned out Lachy wasn't using use case the way anyone else uses it.
  766. # [20:30] <MikeSmith> robburns - and ...?
  767. # [20:31] <robburns> MikeSmith: I guess I don't know what your question is. You used a question mark, but you haven't actually asked a question.
  768. # [20:31] <MikeSmith> My question was, did you intend that comment as a joke?
  769. # [20:32] <MikeSmith> Just asking
  770. # [20:33] <robburns> MikeSmith: there's certainly some humor in it, but I honestly believe Lachy knows he's wrong here and just isn't big enough to admit it.
  771. # [20:33] <robburns> MikeSmith: even mjs understood what I was saying, and though he made a feeble attempt to defend Lachy, it was clear his heart wasn't in it.
  772. # [20:34] <gsnedders> robburns: there are multiple ways of describing a use case — both what you and Lachy are arguing are valid
  773. # [20:35] <robburns> gsnedders: Lachy's are examples. If were just going to let the term mean anything, then we might as well call UAs use cases. I use Safari usually. Which use case do you use gsnedders?
  774. # [20:35] * Parts: billmason (billmason@
  775. # [20:36] <MikeSmith> So you figured by asking Lachy that question, he'd respond by saying... what? "Yeah, we established earlier that I don't understand what as use-case is."?
  776. # [20:37] <MikeSmith> I'm just sorta trying to understand here
  777. # [20:37] <gsnedders> robburns: a browser isn't a use case on its own. neither are sites. saying "<http://yyz.com/> shows a use-case for @longdesc" is completely valid.
  778. # [20:37] <robburns> \MikeSmith: I What, did I have too much faith in him?
  779. # [20:38] <robburns> gsnedders: even Lachy admitted the proper way to say that was: "<http://yyz.com/> shows an example of a use-case for @longdesc"
  780. # [20:39] <gsnedders> robburns: but on a page for use-cases for @longdesc (or under a heading, or whatever) the context and the rest of the sentance is implied
  781. # [20:39] <MikeSmith> robburns - and the "just isn't big enough to admit it" comment, is that in a similar "certainly some humor in it" vein?
  782. # [20:40] <robburns> gsnedders: not when Lachy arranges it under a different heading and puts it at the top of the page before the statement of the use cases Gregory put ther
  783. # [20:41] <robburns> gsnedders: Lachy said: "It's an example that demonstrates the use case"
  784. # [20:41] <robburns> MikeSmith: no
  785. # [20:41] <MikeSmith> robburns - so how would you characterize that comment, then?
  786. # [20:41] <robburns> MikeSmith: it definitely appears he's not big enough to admit it. No joke there.
  787. # [20:41] <Lachy> robburns, whereas "Blind users are unable to view the original image so need enough fallback content to replace the entire function of the image within the page." is not even close to a use case. It's a problem statement that applies to the use cases
  788. # [20:42] <robburns> Lachy: what needs to be added to that for it to be a use case?
  789. # [20:43] <Lachy> perhaps a description of the type of images that "the original image" is referring to! Like diagrams, flowcharts, photography or screenshots
  790. # [20:43] * Joins: mjs (mjs@
  791. # [20:44] * Parts: matt (matt@
  792. # [20:44] <Lachy> in other words, *describing the cases where a long description would be appropriate*
  793. # [20:44] <robburns> How about: "A blind users are unable to view the original image. a blind user uses a non-spatial user interface mechanism to move focus to the image. then another mechanism audibly reads the description of the image"
  794. # [20:44] <robburns> s/are/is
  795. # [20:45] <Lachy> no
  796. # [20:45] <robburns> Lachy: I don't think those categories are all that important. The important part is the role those categories o images play in the document (regardless of which of those categories it is)
  797. # [20:46] <robburns> It doesn't matter whether its a a diagram or a photograph. If it's non-text, non-decroative and non-iconic it fits the use case
  798. # [20:47] <robburns> perhaps another use case relates to an image used as an icon
  799. # [20:47] * Quits: hasather (hasather@ (Client exited)
  800. # [20:47] <robburns> I don't see much point in the other distinctions. At least not at the level it gets solved by HTML5
  801. # [20:47] <Lachy> it matters because we need to distinguish the categories of images for which long descriptions are appropriate, from those that aren't
  802. # [20:48] <robburns> Lachy: the only distinction then is the one I made between decorative (nothing needed), icon (focussing on the meaning and purpose of the icon) and others (a description of the content and it's place in the document if that's not already covered by the caption)
  803. # [20:49] <robburns> description of the visual content that is
  804. # [20:50] <robburns> Lachy: however it's a wiki. You could have edited those so-called beneficiaries and added the needed prose to round them out. I honestly didn't even notice anything was missing because I filled in the other details as I read.
  805. # [20:50] * Joins: hasather (hasather@
  806. # [20:51] <mjs> do I need to do another remedial class on "what is a use case"?
  807. # [20:51] <robburns> mjs: hi
  808. # [20:51] <robburns> mjs: I don't think it has to be remedial, Lachy's coming along pretty well now
  809. # [20:52] <DanC> I find that the term "use case" is not well known. I tend to use wikipedia as a yardstick. if the wikipedia article is good and says what you'd expect, then it's reasonable to expect the average WG member to know it.
  810. # [20:52] <DanC> but if you have to do a class, mjs, then it's not remedial.
  811. # [20:52] <mjs> DanC: I tried to help Lachy and robburns understand what constitutes a use case last night
  812. # [20:52] <mjs> I think both of them were getting it somewhat wrong
  813. # [20:52] <mjs> but they still seem to be arguing
  814. # [20:52] * DanC reads http://en.wikipedia.org/wiki/Use_case ...
  815. # [20:53] <robburns> DanC: I quoted that before
  816. # [20:53] <robburns> mjs: you thought I was being too specific in my use case. However, Lachy is providing examples where one couldn't get any more specific
  817. # [20:53] <robburns> mjs: so I'd say I had to be much close to the Wikipedia/shared understanding of a use case than Lachy
  818. # [20:54] <DanC> http://en.wikipedia.org/wiki/Use_case doesn't look like an exact match.
  819. # [20:54] <robburns> DanC: and it does largely match what I expected it to say
  820. # [20:54] * Joins: hyatt (hyatt@
  821. # [20:54] <mjs> robburns: there's nothing wrong with illustrating a use case with one or more examples
  822. # [20:54] <DanC> http://en.wikipedia.org/wiki/Use_case has a lot about UML and business rules
  823. # [20:54] <robburns> DanC: what issues would you take with it?
  824. # [20:55] * Parts: hasather (hasather@
  825. # [20:55] <mjs> the basic form of a use case is "in situation X, the relevant actor wants to achieve goal Y"
  826. # [20:56] <mjs> you want to specify the actor, the situation and the goal
  827. # [20:56] <DanC> wikipedia concurs: "Each use case describes how the actor will interact with the system to achieve a specific goal. "
  828. # [20:56] <mjs> you don't want to specify the details of how the goal is to be achieved
  829. # [20:56] <robburns> mjs: Agreed. However, given the scope of our project here I think the list of users Gregory provided gave us enough information to understand the use case (to fill in the blanks).
  830. # [20:56] * Joins: hasather (hasather@
  831. # [20:56] <robburns> mjs: except the details probably have something to do with HTML or it's out of scope.
  832. # [20:56] <mjs> a list of users is not a list of use cases
  833. # [20:57] <Philip`> The Wikipedia definition sounds like it's about describing what the actor does, which happens to result in the goal being reached
  834. # [20:57] <robburns> mjs: and it has something to do with a UA that consumes HTML
  835. # [20:57] * DanC wonders if it's worth sticking a working definition in an esw UseCase topic... wonders if there is already one there...
  836. # [20:57] <robburns> mjs: so we're already getting into more implementation details than the wikipedia article or you would allow and we haven't said anything other than the types of users.
  837. # [20:57] <mjs> I think I need to write something up
  838. # [20:57] <DanC> nop; no http://esw.w3.org/topic/UseCase yet ...
  839. # [20:58] <DanC> oh... UseCases...
  840. # [20:58] <DanC> but what's there isn't relevant
  841. # [20:58] <mjs> robburns: I would put the user-perspective use case like this:
  842. # [21:01] <mjs> "A user who can't make use of images for whatever reason visits a page that includes an image. She wants to understand the contents of the page, and the contents of the image are essential, but alt text is unlikely to be sufficient to convey the needed meaning."
  843. # [21:01] <robburns> mjs: that's a fine approach except that page is not so focussed.
  844. # [21:02] <robburns> It's focussed on alternate/equivalent/fallback in general so the last clause would go
  845. # [21:02] * DanC would need a more specific example in order to really engage my brain
  846. # [21:02] <robburns> The first sentence basically conveys what Gregory's list conveys
  847. # [21:02] <robburns> He didn't include the fact that the user wanted to understand the page
  848. # [21:03] <robburns> and perhaps he didin't mention that the images were essential
  849. # [21:03] <mjs> Now, you could make versions of those for "a totally blind user", "a legally blind user", "a user who has images turned off for bandwidth reasons"
  850. # [21:03] <robburns> I never thought to add those minor two facts, because I thought they were just too obvious
  851. # [21:03] <mjs> that's interesting only if you think you'd pick a different solution based on these constituencies
  852. # [21:03] <mjs> now, authoring-perspective use cases would look something like this:
  853. # [21:04] <robburns> So to each of the items Gregory has we just add: 1) the images are essential and 2) the user wants to understand the contents of the page.
  854. # [21:04] <DanC> somebody told me about some WAI documents with scenarios a bit like this... I think "business case" was the label.
  855. # [21:04] <robburns> for the last item (search engines), the user is just a bit more removed. The user is a search engine user. who wants to be able to find images that are essential to the content
  856. # [21:05] <DanC> I hope to find those "business case" documents because, as I recall, the examples in them were particularly motivating.
  857. # [21:05] <robburns> mjs: I think Gregory wanted to list them all to make it clear this wasn't just about someone with dark glasses and a cane.
  858. # [21:05] <mjs> "An author wants to publish a technical document including a flowchart that is essential to understanding the document. He wants his page to be accessible to users who can't make use of images, but the kind of short summary usually found in an alt attribute would not be adequate."
  859. # [21:06] <Lachy> mjs, the user perspective case would need to describe what type of image(s) for which alt text is insufficient
  860. # [21:06] <mjs> robburns: yes, but I think Gregory is also working with a built-in assumption that every image should have a longdesc
  861. # [21:06] <robburns> mjs: that sounds good. Except again the page is not just about longdesc anymore. It's about all text equivalents
  862. # [21:07] <robburns> mjs: I'm working from the same built-in assumption.
  863. # [21:07] <robburns> mjs: or at least the ones worth putting on a public website
  864. # [21:07] <robburns> mjs: the ones where the lens cap was left on probably don't need any description
  865. # [21:08] <mjs> robburns: that's problematic, because many people assume that for lots of images, alt text is enough, and that seems to be the general consensus in many accessibility circles as well
  866. # [21:08] <mjs> robburns: so making use cases that assume your desired conclusion is not fruitful to the discussion
  867. # [21:08] <robburns> mjs: but the lens cap photos won't be deemed good enough for the web page either
  868. # [21:09] <mjs> Lachy seems to have the point of view that some kinds of images might benefit from a long / marked up description, but for some images in some contexts, brief alt text gets the point across
  869. # [21:09] <mjs> I think the flag example is illlustrative of this point of view
  870. # [21:09] <robburns> mjs: it's a goal. I didn't say we'd achieve it. Also you keep making the alt longdesc distinction, but the topic is not about that distinction it's about all fallback
  871. # [21:09] <robburns> I think that brief alt text is sufficient for icons
  872. # [21:10] <mjs> if flag images are used only to select a country, and not to talk about the flag, then the country name is sufficient text equivalent for the given context
  873. # [21:10] <mjs> but Gregory would think such a flag image should have a longdesc giving a detailed description of what the flag looks like and its history
  874. # [21:10] <robburns> mjs: keep in mind for object, there is no distinction between alt and longdesc. There's only text equivalent. Which is what the page is about
  875. # [21:10] <mjs> that's a real example he posted in the past
  876. # [21:11] <robburns> mjs: in the select a country case that's what I'm referring to as an icon
  877. # [21:11] <mjs> robburns: for the use cases to be useful, they need to help us decide if <img alt=""> is sufficient or if we also need some other mechanism
  878. # [21:11] <robburns> mjs: I dont' think you know Gregory enough to make such claims. I can't tell you Gregory thinks about this topic
  879. # [21:12] <mjs> robburns: he posted that specific example (using the british flag) to public-html
  880. # [21:12] <robburns> mjs: many time images such as flags come from professional libraries. In that case I think they should have long descriptions already too.
  881. # [21:12] <mjs> robburns: I have no reason to believe he has changed his mind since then
  882. # [21:12] <mjs> I think having a long description in cases where the flag is not the point is actively harmful
  883. # [21:12] <mjs> because it's distracting from the user's goal
  884. # [21:13] <robburns> If an artist produces a collection of flag images for distribution to hundreds or thousands of users/authors, it would really make sense to describe the images with some text metadata
  885. # [21:13] <MikeSmith> robburns - How well do you know Gregory?
  886. # [21:13] <mjs> anyway
  887. # [21:14] <robburns> mjs: well if you keep making the alt/longdesc that problem is largely solved there. The longdesc is not a distraction because the user gets what they need from alt and if they want to know more they can opt to hear the longdesc
  888. # [21:14] <mjs> the way you make use of use cases to evaluate technical solutions is to see if the proposed solution would effectively satisfy the use cases
  889. # [21:14] <robburns> MikeSmith: not that well, but I have a feeling mjs doesn't have a adequate grasp of Gregory's views on this either
  890. # [21:14] <mjs> a list of different levels of visual impairment doesn't really help us decide if <img alt="" longdesc=""> is better than <img alt="">
  891. # [21:15] <mjs> robburns: I'm basing this specific example on a message he sent to the mailing list
  892. # [21:15] <robburns> mjs: but it doesn't really hurt either.
  893. # [21:16] * Joins: mjs_ (mjs@
  894. # [21:16] * Quits: mjs (mjs@ (Connection reset by peer)
  895. # [21:17] <robburns> mjs: However to say that we don't need to list the different users effected by this use case because there will likely be one solution for them all, neglects the fact that we were asked to not focus on solutions and just list use cases (so we're not supposed to presume anything about solutions)
  896. # [21:18] <robburns> mjs: I think if you looked at the example again, it doesn't support what you're thinking
  897. # [21:18] <mjs_> I don't think having the list is bad
  898. # [21:18] <robburns> mjs: that's good
  899. # [21:18] <mjs_> it's just not a list of use cases
  900. # [21:19] <robburns> mjs: I thought we established that it basically is a list of use cases. The only thing left out was that the user wanted to understand the document and the images were essential to understanding the document. Those seem so obvious to me that they hardly need to be mentioned
  901. # [21:19] <robburns> mjs: not that I'm against mentioning them
  902. # [21:21] * mjs_ is now known as mjs
  903. # [21:21] <mjs> let's look at an example
  904. # [21:22] <mjs> "Blind Users: Blind users are unable to view the original image so need enough fallback content to replace the entire function of the image within the page. Providing a short summary of the image in cases where its overall content is complex may allow them to choose to read a more detailed description if the image is of interest."
  905. # [21:23] <mjs> that one is not that bad, though it could certainly be improved
  906. # [21:23] <mjs> it seems to be assuming that both short and long descriptions are desirable just by stating it
  907. # [21:23] <mjs> instead of illustrating when that might be necessary
  908. # [21:24] <mjs> but then look at the "Legally Blind Users" example
  909. # [21:24] <mjs> it just describes what the term "Legally Blind" means
  910. # [21:25] <mjs> it doesn't say anything about what the user wants to do
  911. # [21:25] <mjs> or clarify how it differs from what a blind user might want to do, if at all
  912. # [21:27] <robburns> mjs: you keep ignoring me on this, but the page doesn't even assume the solution involves a distinction between short and long descriptions. That again leaps to the solution instead of focussing on the problem
  913. # [21:27] <robburns> mjs: there could even be a solution with short and medium and long descriptions. Again, that's apart o the solution it's not part of the use case
  914. # [21:27] <mjs> robburns: what do you mean? I just quoted what the page says for "Blind Users"
  915. # [21:28] <mjs> and it assumes a disctinction between "a short summary of the image" and "a more detailed description"
  916. # [21:28] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Client exited)
  917. # [21:28] <mjs> robburns: I guess the page is ignoring what you said about what the page says
  918. # [21:28] <robburns> mjs: no, I don't think it is
  919. # [21:28] <mjs> robburns: I guess you are saying the stated use case for Blind Users is bad
  920. # [21:28] <mjs> since it assumes details of the solution
  921. # [21:29] <mjs> or maybe you agree with it now that you know Gregory wrote it and not me
  922. # [21:29] <robburns> mjs: it's saying that the user should be able to get a short description, but that doesn't presume that there are two different mechanisms for providing short and long. Another wiki page deals with the use case of extracting short fallback from the full fallback (or just having different fallback as another solution)
  923. # [21:31] <robburns> mjs: I think that the short/long distinction is another problem we need to deal with. However, I don't think anything Gregory wrote presumes that this problem will be solved by providing necessarily @alt and @longdesc. If you look through the proposed solutions you'll see that some of them do not provide a structured difference between the two. That would have to be handled by UA heruistics or some other markup.
  924. # [21:32] <mjs> I gotta go to lunch
  925. # [21:32] <mjs> catch you later
  926. # [21:32] <robburns> mjs: catch you later
  927. # [21:32] <Hixie> wouldn't the only _problem_ here be "users who cannot view images are unable to get as much usefulness from a page using images that convey meaning not otherwise conveyed in the text as users who are able to see images"?
  928. # [21:34] <jgraham> Hixie: That sounds like a sensible problem description to me.
  929. # [21:36] <Lachy> it depends if you want to distinguish between cases where alt="" is sufficient and other cases where longer descriptions with richer markup are needed
  930. # [21:37] <jgraham> Lachy: I don't think the page does make that distinction
  931. # [21:37] <jgraham> (despite its title)
  932. # [21:37] <Lachy> well that's what I thought the whole longdesc page was about
  933. # [21:38] <jgraham> That's sort-of my fault; I edited that page to be about image equivalents rather than creating a new page with a sensible name
  934. # [21:38] <Lachy> I don't think its useful to think of alt and longdesc as being so similar, they each solve different (but related) problems
  935. # [21:38] <jgraham> I'm not so sure that's true.
  936. # [21:39] <robburns> Lachy: but when looked at from the perspective that includes the object element too, ti's a different problem (and it has its own wiki page)
  937. # [21:39] <jgraham> At least, not if I understand the problem that is trying to be addressed (which it is quite possible I do not since I almost always have access to images)
  938. # [21:40] <Hixie> i don't understand why there's a distinction between cases where a paragraph is sufficient and cases where you have to have a whole separate page
  939. # [21:40] <Hixie> it's still the same problem
  940. # [21:40] <robburns> part of the problem is that the page has gone through many lives and its now a bit off a mess. it has text that talks exclusively about longdesc mixed with the text that is more agnostic. I think the text added later moved it more and more to a problem/use-case focussed page away from the longdesc solution
  941. # [21:40] <Hixie> it's just that in the research section you include examples of all different kinds of images, including some which can only be helped by large amounts of off-page text
  942. # [21:41] <Lachy> because if the distinction isn't made, how can one tell if alt="" is sufficient for all the cases or not?
  943. # [21:42] <jgraham> Lachy: by evaluating alt as a solution and seeing if it covers all cases or not
  944. # [21:42] <Hixie> i'll look at the examples in turn
  945. # [21:42] <Hixie> and make sure the spec can handle them
  946. # [21:42] <Lachy> yeah, right, and we need to find and document those cases where it isn't
  947. # [21:42] <robburns> Hixie: I'm not clear where you're reading that in the page (i.e., I'm not clear what distinction you're talking about)
  948. # [21:43] <Hixie> i'm not reading anything
  949. # [21:43] <Hixie> i'm saying what it should be like
  950. # [21:43] <jgraham> Lachy: agreed. We also need to worry about whether any solution for providing more text is actually likely to have a useful level of uptake
  951. # [21:43] <robburns> Hixie: but are you talking about "whole separate page" as in where @longdesc points to another page?
  952. # [21:45] <robburns> Hixie: because I see that as simply a feature/bug of the longdesc solution. I don't know if anyone has actually made that distinction a part of the problem or the proposed solutions
  953. # [21:45] <robburns> not an inherent part anyway
  954. # [21:46] <Hixie> robburns: i'm not talking about any kind of solution, i'm just saying that the page that describes the problem of "users who cannot view images are unable to get as much usefulness from a page using..." should have a representative set of examples covering all the kinds of images and meaning conveyed by images that we need to address
  955. # [21:48] * Joins: dbaron (dbaron@
  956. # [21:48] <robburns> Hixie: ok
  957. # [21:51] * Joins: briansuda (briansuda@
  958. # [21:52] * Quits: kingryan (rking3@ (Ping timeout)
  959. # [21:52] * Quits: schepers (schepers@ (Ping timeout)
  960. # [21:58] * Quits: beowulf (beowulf@ (Ping timeout)
  961. # [22:13] * Quits: Lachy (chatzilla@ (Ping timeout)
  962. # [22:15] <DanC> what's the date of this change http://html5.org/tools/web-apps-tracker?from=996&to=997 ?
  963. # [22:16] <DanC> ah...
  964. # [22:16] <DanC> 2007-08-10 02:38
  965. # [22:19] * Joins: Zeros (Zeros-Elip@
  966. # [22:19] * Quits: Zeros (Zeros-Elip@ (Client exited)
  967. # [22:20] * Joins: Lachy (chatzilla@
  968. # [22:20] * Joins: kingryan (rking3@
  969. # [22:26] * Quits: gavin (gavin@ (Ping timeout)
  970. # [22:31] * Joins: gavin (gavin@
  971. # [22:40] * Quits: kingryan (rking3@ (Quit: kingryan)
  972. # [22:45] * Joins: zcorpan_ (zcorpan@
  973. # [22:49] * Quits: ROBOd (robod@ (Quit: http://www.robodesign.ro )
  974. # [22:59] * Quits: mjs (mjs@ (Ping timeout)
  975. # [23:03] * Parts: hasather (hasather@
  976. # [23:04] * Quits: briansuda (briansuda@ (Connection reset by peer)
  977. # [23:04] * Joins: briansuda (briansuda@
  978. # [23:11] * Quits: robburns (robburns@ (Quit: robburns)
  979. # [23:11] * Joins: mjs (mjs@
  980. # [23:14] * Joins: robburns (robburns@
  981. # [23:16] * Joins: mjs_ (mjs@
  982. # [23:19] * Quits: mjs (mjs@ (Ping timeout)
  983. # [23:23] * Quits: briansuda (briansuda@ (Quit: briansuda)
  984. # [23:23] * Quits: robburns (robburns@ (Ping timeout)
  985. # [23:25] * Joins: kingryan (rking3@
  986. # [23:44] * Quits: hober (ted@ (Quit: ERC Version 5.2 (IRC client for Emacs))
  987. # [23:44] * Quits: polin8_ (polin8@ (Ping timeout)
  988. # Session Close: Fri Aug 24 00:00:00 2007

The end :)