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

Options:

# Session Start: Thu Aug 23 00:00:00 2007
# Session Ident: #html-wg
# [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"
# [00:00] <jgraham> robburns: The design principles are for _us_ though, not for outside observers.
# [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.
# [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.
# [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.
# [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.
# [00:03] * Joins: Zeros (Zeros-Elip@67.154.87.254)
# [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
# [00:04] <mjs> I'm thinking of renaming the more contentious principles
# [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.
# [00:04] <mjs> I think "Solve Real Problems" might better be named "Support Use Cases With Evidence"
# [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
# [00:05] <jgraham> ?
# [00:06] <mjs> John Foliot argued that this is true of accessibility
# [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)
# [00:06] <jgraham> accessibility is itself a use case
# [00:06] <jgraham> (loosly speaking)
# [00:06] <mjs> jgraham: he argued that specific features that are claimed to be for accessibility shouldn't require use case justification
# [00:07] <robburns> jgraham: I think disability is a use-case, as in visual impairment or hearing impairment etc.
# [00:07] <mjs> disability isn't a use case
# [00:07] <robburns> jgraham: but accessibility is properly used as design principle
# [00:07] <jgraham> mjs: I think I remember.
# [00:07] <mjs> making content that is accessible to people with that disability is a use case
# [00:07] <jgraham> but I never understood his point of view
# [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.
# [00:08] <mjs> robburns: can you imagine yourself agreeing with a rewritten principle whose theme is "Support Use Cases With Evidence"?
# [00:08] <robburns> mjs: not really
# [00:08] <mjs> you don't think use cases should be supported with evidence?
# [00:08] <jgraham> robburns: Why ever not?
# [00:08] <Philip`> What about an entirely new principle whose theme is "Support Use Cases With Evidence"? :-)
# [00:09] <jgraham> I can see your problem with "Solve Real Problems", but I have no idea what you have against evidence
# [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.
# [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.
# [00:09] <mjs> evidence doesn't have to be actual current use or practice
# [00:10] <Zeros> That seems reasonable enough then.
# [00:10] <mjs> robburns: I don't think people deliberately hide evidence, I think they sometimes fail to provide adequate evidence
# [00:10] <mjs> either because they didn't try to look or because no evidence exists
# [00:11] <mjs> without evidence, there is no way to evaluate the value of an argument, and therefore no objective way to make decisions
# [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.
# [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
# [00:11] <mjs> Zeros: specifically, significant expression of interest from the expected target audience would count as evidence
# [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.
# [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.
# [00:12] <mjs> robburns: that's not a very compelling argument
# [00:12] <robburns> mjs: I don't think we have the means or the budget to collect that sort of evidence.
# [00:12] <mjs> people do in fact make suggestions not backed by evidence all the time
# [00:13] <mjs> evidence doesn't always have to take the form of statistical analysis of existing web content
# [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)
# [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.
# [00:13] <robburns> mjs: those are suggestions or proposals. The evidence comes later.
# [00:14] <mjs> Zeros: for browser vendors and search engine providers, we have good means of contact through the WG and otherwise
# [00:14] <mjs> Zeros: I would say the biggest communication gap is with developers of assistive technologies
# [00:14] <Philip`> I've seen complaints of a communication gap with web developers
# [00:14] <robburns> mjs: we have developers of assistive technologies on our WG.f
# [00:15] <robburns> s/f/
# [00:15] <Zeros> is there someone from FS working with the wg?
# [00:15] <Philip`> (which may be a more significant gap, since there are more web developers than there are AT users)
# [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
# [00:16] <Zeros> mjs, what about apple? Where does the department that works on VO get their feedback?
# [00:16] <DanC> introductions... good idea, mjs. http://lists.w3.org/Archives/Public/public-forms-tf/2007Aug/0002.html
# [00:16] <mjs> Philip`: well, many companies that do significant web development are represented, as are many individual web developers
# [00:16] <Zeros> Seems like MS should have connections from working on MSAA too
# [00:17] <Zeros> Or did they just drop the API on people and expect products to spring up?
# [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.
# [00:17] <mjs> Zeros: my team at Apple works pretty closely with the VoiceOver team and can communicate with them as needed
# [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?
# [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
# [00:18] <DanC> +1 "Solve Real Problems" might better be named "Support Use Cases With Evidence"
# [00:18] <mjs> Zeros: yes
# [00:18] <Zeros> mjs, awesome
# [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.
# [00:19] <mjs> VoiceOver isn't really a screen reader
# [00:19] <Zeros> anyway, while we're discussing the design principals, is there a specific accessibility feature that robburns thinks is being ignored?
# [00:19] <mjs> it's a speaking interface for the whole OS
# [00:19] <mjs> it uses semantic information from applications themselves
# [00:19] <mjs> it does not just read the screen and doesn't do any poking into the framebuffer or interception of graphics calls
# [00:19] <robburns> mjs: the currently available release is largely a screen reader (at least when it comes to web contetn)
# [00:20] <robburns> mjs: it doesn't use the semantics inherent in HTML or CSS though
# [00:20] <mjs> robburns: it certainly does - I've seen the code
# [00:20] <robburns> mjs: which is what's relevant to the current discussion
# [00:20] <robburns> mjs: itt certainly does not I've used it
# [00:21] <mjs> it may not be using the markup in the way you expect
# [00:21] <robburns> mjs: somehow that code must have not gotten implemented in the UI
# [00:21] <mjs> but it does look at it
# [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
# [00:22] <Zeros> um huh?
# [00:22] <robburns> mjs: which is what I said in the first place
# [00:22] <Zeros> that's circular logic
# [00:22] <Philip`> robburns: How do you expect it to use the semantics?
# [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.
# [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.
# [00:23] <mjs> DanC: I hope that the person who started the thread can summarize it in the wiki
# [00:23] <DanC> heh... I was just going to say that I hope the editor can follow the thread
# [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
# [00:23] <Zeros> I don't think many readers actually support the aural css properties
# [00:24] <jgraham> s/asking/talking to/
# [00:24] <robburns> VoiceOver speaks UI for the built in OS view classes. It doesn't speak the semantics of HTML and CSS.
# [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
# [00:25] <mjs> robburns: it's aware of links, form controls, elements with a click action, client-side image maps, blockquotes, headings...
# [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.
# [00:26] <mjs> robburns: list markers, block vs. inline...
# [00:26] <Zeros> robburns, um okay. I'm confused. What exactly do you want implemented that mjs thinks requires more evidence?
# [00:26] <mjs> Zeros: this isn't a discussion about evidence
# [00:26] <Zeros> ah okay
# [00:26] <robburns> Zeros: we were talking about the design principles
# [00:26] <mjs> robburns claims that VoiceOver ignores the semantics of HTML and CSS
# [00:26] <mjs> which is factually wrong
# [00:27] <Philip`> It just ignores *some* of the semantics?
# [00:27] <mjs> it doesn't make use of some of the semantics
# [00:27] <robburns> mjs: OK, I'd agree with that characterization
# [00:27] <mjs> it does make use of other aspects of the semantics
# [00:28] <mjs> in fact, quite a lot - look at all the things I listed
# [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?
# [00:28] <Philip`> (I assume the answer depends on the exact case)
# [00:28] <Philip`> (in which case it's not a directly useful question)
# [00:28] <Zeros> You missed the time answer
# [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
# [00:29] <Zeros> VoiceOver is quite a bit younger than JAWS
# [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.)
# [00:30] <mjs> robburns: I'm sure there's all sorts of additional features we can (and will) add
# [00:30] <mjs> but saying that VoiceOver is only a screen reader for web content is wrong
# [00:30] <mjs> both with regards to its current state and with regard to goals
# [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)
# [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
# [00:32] <mjs> Philip`: I don't think anyone has made such a list - queries about specific features would be easier to answer
# [00:32] <mjs> I think the market share of VoiceOver is pretty small to the top Windows screen readers though
# [00:32] <Zeros> Does webkit implement the DOM mutation events?
# [00:33] <mjs> yes, although we hate them
# [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.
# [00:33] <Zeros> mjs, does VoiceOver use them?
# [00:33] <mjs> Zeros: no (though I'm not sure why that's relevant)
# [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
# [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
# [00:34] <Zeros> mjs, the capacity for a reader to be able to know which parts of a page are changing is important
# [00:34] <robburns> msj: as is Apple
# [00:34] <mjs> Zeros: in general we try to use more efficient engine-specific change notifications when needed, both for accessibility and other things
# [00:35] <mjs> jgraham: I can ask what plans, if any, they have for table headers
# [00:35] <Zeros> mjs, hmm, so VO can tell when various parts of the page change due to JS?
# [00:35] <Zeros> I really need to start browsing with VO on and listen to how it behaves
# [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
# [00:35] <mjs> Zeros: I'm not sure how good it is at detecting changes
# [00:35] <Zeros> hmm
# [00:35] <mjs> Zeros: or the granularity thereof
# [00:36] <mjs> but, our efforts to improve that probably would not include using DOM mutation events
# [00:36] <mjs> DOM mutation events have two problems:
# [00:36] <robburns> mjs: I'm not sure what you're saying by that though (listing those apps)
# [00:36] <mjs> 1) the event handler is allowed to do anything, including mutating the DOM
# [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).
# [00:38] * Quits: heycam (cam@203.214.42.247) (Ping timeout)
# [00:38] <mjs> 2) the granularity of events is very small, so compound operations must send many events
# [00:38] <mjs> for internal changes, we have more efficient ways of notifying
# [00:38] <mjs> so that we can disallow mutation from the handler and/or coalesce notifications
# [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
# [00:39] <Zeros> It wouldn't make sense to convert those less problematic events into something all browsers could use?
# [00:39] <mjs> well, these things aren't DOM events at all and aren't exposed to web content
# [00:39] <Hixie> mjs: i hope your experience with it is better than my experience with jaws
# [00:39] <Hixie> sheesh
# [00:39] <mjs> better change notification events for web content might be useful
# [00:40] <Zeros> yeah
# [00:42] <robburns> Philip: yt?
# [00:43] <Philip`> robburns: Yes
# [00:44] <robburns> Philip : We were discussing the @axis attribute a while back and that is comma separated.
# [00:44] <Philip`> And about comma-separation not being great for CSS selectors?
# [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).
# [00:45] <robburns> any thoughts on why we have two delimiters?
# [00:47] <robburns> Philip: comma-delimited ContentTypes, DediaDesc, Coords, MultiLengths, and axis, , ,
# [00:47] <Philip`> Are there any space-separated other than @class and object@archive?
# [00:47] <robburns> Philip: space-delimited: class, archives, Charsets, LinkTypes
# [00:47] <Philip`> (How weird - object@archive is space-separated, applet@archive is comma-separated...)
# [00:48] <robburns> weird
# [00:48] <robburns> indeed
# [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."
# [00:49] <Philip`> Weirder :-)
# [00:50] <Philip`> I can't see any particular reason for the choices
# [00:51] <Zeros> and or?
# [00:51] <Zeros> that sounds like it must be fun to select
# [00:51] <Zeros> :p
# [00:52] <Philip`> @charsets = split /[ ,]+/, $accept_charset;
# [00:52] <Philip`> Easy :-)
# [00:52] <Philip`> Or you could write a 22-step algorithm full of gotos to describe how to parse it
# [00:52] <Zeros> with css
# [00:52] <Philip`> Oh, okay
# [00:52] * Quits: tH (Rob@87.102.85.245) (Quit: ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508])
# [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
# [00:53] <robburns> Phlip: the DTD said only " a space-separated list of character encodings, as per [RFC2045]" for charsets
# [00:53] <Philip`> Then again, I'm not sure why you'd ever want to style a form based on its charsets :-p
# [00:53] <Zeros> lang is the odd one out because it uses a hyphen
# [00:53] <Philip`> robburns: Are you expecting internal consistency in HTML4?
# [00:54] <robburns> also some of these have the same syntax as the http headers I believe
# [00:56] <Philip`> link@media and style@media are defined in HTML5 as CSS3 Media Queries, so that defines the syntax in that case
# [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)
# [00:57] <robburns> but you're write the charsets is probably not one of those
# [00:58] <robburns> Zeros: except the hyphen is to get at hierarchically arranged languages, not separately listed languages
# [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).
# [00:59] <Zeros> robburns, I know, I was just stating that there's other ways of separating data in html attributes as well
# [01:00] <robburns> Zeros: I see
# [01:01] <Zeros> CSS ended up with kind of half-assed regex selection because of all this
# [01:01] * Philip` wonders if anyone on the web actually uses multiple axis values
# [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)
# [01:01] <Zeros> ^= $= and what not, it's rather comical
# [01:02] <Zeros> adding more selectors just complicates things, CSS needs a universal separator selector that lets you supply the separator.
# [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)
# [01:02] <Zeros> [attr(sep)="value"] then again attr() is already used, but I don't think it applies in that context
# [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).
# [01:03] <Philip`> Just allow arbitrary JS expressions in CSS selectors :-)
# [01:03] <Zeros> hah
# [01:03] <Zeros> Was expression: ever proposed for CSS3?
# [01:03] <Zeros> s/:/()/
# [01:05] <Philip`> Like in IE?
# [01:05] <Zeros> yes
# [01:05] <Zeros> I was just curious
# [01:05] <Philip`> That's not enough fun for implementors - it's got to be scripted selectors!
# [01:05] <Zeros> oh okay
# [01:06] <Zeros> why not just add @script {} blocks?
# [01:06] * Philip` ignores the likely pain in evaluating every single selector after every single DOM change
# [01:06] <Zeros> I've crashed IE before using expression()
# [01:07] * Philip` has no idea if the slightly more feasible expression() was ever suggested seriously
# [01:07] <Philip`> (I must admit to having used it in a real site once)
# [01:07] <Philip`> (to fake max-width, if I remember correctly)
# [01:07] <Zeros> yeah, that's all I've ever used it for
# [01:08] <Zeros> Screwing with the width in IE6 in an expression() on the body causes a crash in some cases
# [01:08] <Zeros> I think it locked up if you tried to force a min-width
# [01:10] <Philip`> I guess it seemed like a good idea when they first implemented it
# [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.
# [01:12] <Philip`> It would work alright if you could be like XForms Transitional and specify that the expressions must not have side effects
# [01:13] <Philip`> Write it in Haskell, perhaps
# [01:26] * Joins: sbuluf (gdwwtrc@200.49.140.149)
# [01:34] * Joins: heycam (cam@130.194.72.84)
# [01:37] * Joins: mjs_ (mjs@17.255.104.81)
# [01:38] * Quits: mjs (mjs@17.203.14.224) (Ping timeout)
# [01:39] * Joins: mjs (mjs@17.203.14.224)
# [01:40] * Quits: mjs_ (mjs@17.255.104.81) (Ping timeout)
# [01:54] * Joins: mjs_ (mjs@17.255.104.81)
# [01:56] * Quits: mjs (mjs@17.203.14.224) (Ping timeout)
# [02:00] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [02:04] * Joins: karl (karlcow@128.30.52.30)
# [02:05] * Joins: gavin (gavin@74.103.208.221)
# [02:12] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Quit: Leaving)
# [02:13] * Quits: kingryan (rking3@208.66.64.47) (Quit: kingryan)
# [02:18] * Joins: mjs (mjs@17.203.14.224)
# [02:19] * Quits: mjs_ (mjs@17.255.104.81) (Ping timeout)
# [02:40] * Joins: mjs_ (mjs@17.255.104.81)
# [02:42] * Quits: mjs (mjs@17.203.14.224) (Ping timeout)
# [02:43] * Quits: robburns (robburns@98.193.22.194) (Quit: robburns)
# [02:47] * Joins: olivier (ot@128.30.52.30)
# [02:49] * Quits: aroben (adamroben@17.255.111.87) (Quit: aroben)
# [02:51] * Joins: mjs (mjs@17.203.14.224)
# [02:53] * Quits: mjs_ (mjs@17.255.104.81) (Ping timeout)
# [02:56] * Quits: mjs (mjs@17.203.14.224) (Quit: mjs)
# [03:01] * Joins: mjs (mjs@17.203.14.224)
# [03:15] * Joins: robburns (robburns@71.57.41.70)
# [03:26] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [03:34] * Joins: aroben (adamroben@17.203.15.195)
# [03:34] * Quits: robburns (robburns@71.57.41.70) (Quit: robburns)
# [03:35] * Joins: robburns (robburns@71.57.41.70)
# [03:37] * Quits: robburns (robburns@71.57.41.70) (Quit: robburns)
# [03:45] * Joins: robburns (robburns@71.57.41.70)
# [04:07] * Quits: aroben (adamroben@17.203.15.195) (Quit: aroben)
# [04:08] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [04:13] * Joins: gavin (gavin@74.103.208.221)
# [04:20] * Quits: billmason (billmason@69.30.57.156) (Connection reset by peer)
# [04:30] * Quits: mjs (mjs@17.203.14.224) (Ping timeout)
# [04:31] * Joins: mjs (mjs@17.255.104.81)
# [04:32] * Joins: Zeros (Zeros-Elip@69.140.40.140)
# [04:34] * Quits: robburns (robburns@71.57.41.70) (Quit: robburns)
# [04:34] * Quits: mjs (mjs@17.255.104.81) (Ping timeout)
# [04:38] * Joins: hyatt (hyatt@24.6.184.144)
# [04:38] * Quits: hyatt (hyatt@24.6.184.144) (Client exited)
# [04:38] * Joins: mjs (mjs@17.203.14.224)
# [04:39] * Joins: hyatt (hyatt@24.6.184.144)
# [04:42] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
# [04:42] * Joins: Lionheart (robin@66.57.69.65)
# [04:43] * Quits: dbaron (dbaron@63.245.220.241) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [05:00] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [05:06] * Joins: robburns (robburns@208.54.7.182)
# [05:12] * Quits: Lionheart (robin@66.57.69.65) (Connection reset by peer)
# [05:21] * Joins: Lionheart (robin@66.57.69.65)
# [05:28] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
# [05:28] * Joins: heycam (cam@130.194.72.84)
# [05:33] * Quits: mjs (mjs@17.203.14.224) (Connection reset by peer)
# [05:33] * Joins: mjs (mjs@17.203.14.224)
# [05:34] * Quits: hyatt (hyatt@24.6.184.144) (Quit: hyatt)
# [05:42] * Joins: hyatt (hyatt@24.6.184.144)
# [05:44] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
# [05:49] * Quits: Zeros (Zeros-Elip@69.140.40.140) (Ping timeout)
# [05:49] * Joins: Zeros (Zeros-Elip@67.154.87.254)
# [05:51] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Quit: Leaving)
# [05:59] * Joins: dbaron (dbaron@63.245.220.241)
# [05:59] * Quits: dbaron (dbaron@63.245.220.241) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [06:04] * Quits: karl (karlcow@128.30.52.30) (Client exited)
# [06:04] * Joins: aroben (adamroben@67.160.250.192)
# [06:05] * Joins: karl (karlcow@128.30.52.30)
# [06:06] * Quits: robburns (robburns@208.54.7.182) (Quit: robburns)
# [06:06] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [06:07] * Joins: robburns (robburns@208.54.7.182)
# [06:19] * Quits: karl (karlcow@128.30.52.30) (Client exited)
# [06:20] * Joins: karl (karlcow@128.30.52.30)
# [06:22] * Quits: karl (karlcow@128.30.52.30) (Client exited)
# [06:48] * Joins: karl (karlcow@128.30.52.30)
# [06:53] * Quits: robburns (robburns@208.54.7.182) (Quit: robburns)
# [07:11] * Joins: robburns (robburns@208.54.7.180)
# [07:36] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [07:41] * Joins: gavin (gavin@74.103.208.221)
# [07:45] <karl> http://vanirsystems.com/danielsblog/?p=193
# [07:50] * Quits: mjs (mjs@17.203.14.224) (Ping timeout)
# [07:51] * Joins: mjs (mjs@17.255.104.81)
# [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" :-)
# [08:00] * Quits: robburns (robburns@208.54.7.180) (Quit: robburns)
# [08:02] * Joins: robburns (robburns@208.54.7.180)
# [08:02] * Joins: mjs_ (mjs@17.203.14.224)
# [08:04] * Quits: Lachy (chatzilla@124.170.120.52) (Ping timeout)
# [08:04] * Quits: mjs (mjs@17.255.104.81) (Ping timeout)
# [08:11] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
# [08:14] * Hixie comments
# [08:25] <MikeSmith> about danielsblog -- In the spirit of trying to find something good to say: He is naivete is, uh, refreshing...
# [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
# [08:27] <MikeSmith> I realize he qualifies that in the next sentence.
# [08:28] <MikeSmith> But I think that sentence can also bring some enjoyment when read in isolation.
# [08:48] <karl> MikeSmith: hixie replied
# [08:51] * Quits: aroben (adamroben@67.160.250.192) (Quit: aroben)
# [08:53] <MikeSmith> karl - I see -- a much more tactful comment than I would have posted.
# [08:53] * MikeSmith makes 1001st note to self to quit being a smartass all the time
# [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
# [08:58] <MikeSmith> I guess taking time to actually post a thoughtful/helpful comment to it instead is a tiny bit more constructive
# [09:00] * Joins: Lachy (chatzilla@124.170.167.11)
# [09:13] * Quits: olivier (ot@128.30.52.30) (Quit: Leaving)
# [09:22] * Quits: Lionheart (robin@66.57.69.65) (Connection reset by peer)
# [09:27] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
# [09:33] * Quits: mjs_ (mjs@17.203.14.224) (Ping timeout)
# [09:42] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [09:47] * Joins: gavin (gavin@74.103.208.221)
# [09:47] <MikeSmith> What is the correct name for referring to the group of people working on the ECMAScript standard?
# [09:48] <MikeSmith> Is it the ECMAScript working group, or something else?
# [09:48] <MikeSmith> ECMAScript Committee?
# [10:02] * Joins: heycam (cam@203.214.42.247)
# [10:10] * Joins: zcorpan_ (zcorpan@88.131.66.80)
# [10:20] * Joins: mjs (mjs@64.81.48.145)
# [10:21] <Lachy> robburns, yt?
# [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.
# [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
# [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.
# [10:25] <Lachy> no, they're not.
# [10:26] * Parts: zcorpan_ (zcorpan@88.131.66.80)
# [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
# [10:26] <mjs> potential beneficiaries are not use cases
# [10:26] <robburns> According to Wikipedia a use case is :A use case should:
# [10:26] <robburns> describe how the system shall be used by an actor to achieve a particular goal.
# [10:26] <robburns> have no implementation-specific language.
# [10:26] <robburns> be at the appropriate level of detail.
# [10:26] <robburns> Not include detail regarding user interfaces and screens. This is done in user-interface design.
# [10:26] <robburns> http://en.wikipedia.org/wiki/Use_case
# [10:26] <Lachy> the particular goal is what the author is trying to achieve
# [10:26] <mjs> if I make plagiarism detection software, "teacher" and "professor" are not use cases
# [10:27] <mjs> "detecting plagiarism in college papers" would be an example of a use case
# [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
# [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
# [10:29] <Lachy> Fine, I'll update it to call the use cases "Diagrams", "Photography" and "Screenshots"
# [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.
# [10:30] <mjs> that doesn't really match the wikipedia definition you cited
# [10:31] <robburns> mjs: how does it not match
# [10:31] <robburns> ?
# [10:31] <mjs> it doesn't describe what goal is achieved, and it includes details regarding user interface and implementation
# [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
# [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.
# [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?
# [10:32] <Lachy> well, examples demonstrating use cases are closer to use cases than a description of a beneficiary
# [10:33] <mjs> mentioning longdesc is an implementation detail, as far as the blind user is concerned
# [10:33] <mjs> "get description of image" would be an example of a goal
# [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.
# [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
# [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
# [10:35] <robburns> mjs: we have another wiki page devoted to that I believe
# [10:36] * Joins: hendry (hendry@89.16.172.32)
# [10:36] <mjs> I don't know what page you guys are talking about, and this issue is hardly my top priority
# [10:36] <mjs> so I am not going to edit the wiki
# [10:37] <mjs> but I do care that people understand what a use case actually is
# [10:37] <mjs> enough to be able to generate one, and to understand what is and isn't one
# [10:37] <Lachy> mjs, this page http://esw.w3.org/topic/HTML/LongdescRetention
# [10:37] <robburns> mjs: Oh, I see its that same page. I thought you were saying that page lept to the longdesc solution
# [10:37] <mjs> since that will come up again and again
# [10:37] <robburns> mjs: you were just saying you wanted me to leave longdesc out of my impromptu use case
# [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
# [10:38] <robburns> mjs: that's fine. forget I mentioned longdesc or even urls
# [10:38] <robburns> mjs: ok
# [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
# [10:39] <mjs> when speaking of alternative content, you could think of use cases from both the user and the author perspective
# [10:39] <mjs> example of a user use case:
# [10:40] <mjs> - blind user using a screen reader encounters content that includes an image, and wants to hear a description of it
# [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
# [10:40] <mjs> example of an author use case:
# [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
# [10:41] <robburns> mjs: I'd say those use cases on the page were about the same as what you described.
# [10:42] <robburns> mjs: well those are much more general than providing examples of authors producing content that could potentially meet those use cases
# [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
# [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
# [10:43] <robburns> mjs: OK
# [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
# [10:44] <mjs> use cases from the user's perspective also often make sense
# [10:44] <mjs> because they help you think about cases where the author didn't do a good job
# [10:45] <robburns> mjs: are you talking about Lachy's use cases or the original use cases (what Lachy placed undere beneficiaries)
# [10:46] <robburns> mjs: the example web pages that Lachy put up there are not use cases by any stretch of the imagination
# [10:46] <robburns> mjs: they are example web pages making use of longdesc
# [10:46] <mjs> they are illustrative examples of authoring use cases
# [10:46] <robburns> mjs: as you pointed out, that page isn't about specifically longdesc
# [10:46] <mjs> (IMO)
# [10:46] <Lachy> robburns, how is an example/description of when a long description would be useful, not a use case?
# [10:47] <robburns> mjs: no they're not by any stretch of the imagination
# [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
# [10:47] * Lachy updates the wiki to make them close to use cases
# [10:48] <mjs> robburns, Lachy: IMO it would be better to first state the general category each one is meant to illustrate
# [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
# [10:48] <Lachy> longdesc="" is an implementation detail. Describing cases where a description is valuable is a use case
# [10:48] <mjs> "technical diagrams / flowcharts", "screenshots of user interface", etc
# [10:49] <Lachy> robburns, the first doesn't only use longdesc and the second doesn't use longdesc at all
# [10:49] <mjs> the CSS example actually doesn't use longdesc at all
# [10:49] <mjs> and has somewhat stylistically poor alt text for that matter
# [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.
# [10:50] <Lachy> robburns, we need to know what kind of non-text content that applies to
# [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
# [10:50] <robburns> Lachy: that's fine. And there good examples of documents using existing HTML features. They're just not use cases.
# [10:51] <robburns> Lachy: it applies to all non-text content that is not merely decorative or iconic
# [10:52] <robburns> mjs: that was the original page name. But it has been repurposed for this other broader problem/use case
# [10:52] <robburns> Lachy: though the page is mostly focussed on still images
# [10:53] <mjs> the page includes "Strategies for Exposing LONGDESC"
# [10:53] <mjs> "Thoughts on LONGDESC and Inline Fallback Content"
# [10:53] <mjs> it looks like it is all about longdesc and mechanisms with similar purposes
# [10:54] <mjs> I don't think having <img alt=""> is controversial or debateable
# [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
# [10:55] <mjs> (or some similar way to have a marked-up but possibly external description)
# [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)
# [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.
# [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>
# [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
# [10:59] <robburns> mjs: the problems with solving this for img is the reason embed should not be added to document conformance IMO
# [10:59] <robburns> mjs: indeed the examples are great.
# [11:00] <robburns> mjs: and some more would be good too
# [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
# [11:01] * Joins: beowulf (beowulf@87.198.168.38)
# [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.
# [11:05] * Joins: olivier (ot@128.30.52.30)
# [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
# [11:06] * Joins: tH (Rob@87.102.85.245)
# [11:06] <mjs> I expect Lachy will be glad to improve the page, after all he already contributed to it
# [11:07] <robburns> mjs: I would agree with that. Illustrative examples might be a good heading
# [11:08] * Joins: zcorpan_ (zcorpan@88.131.66.80)
# [11:09] <Lachy> robburns, I already updated them to describe use cases, giving those as examples. Is it acceptable now?
# [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.
# [11:16] <Lachy> the beneficiaries aren't even close
# [11:17] <Lachy> describing cases where it would be useful to provide long descriptions of images are the use cases that are really interesting.
# [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.
# [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
# [11:19] <Lachy> robburns, we need to know which cases require longer descriptions than can be provided with alt="".
# [11:21] <Lachy> the relevant use cases are the potential cases where an author could actually make good use of longdesc="" (or other solution)
# [11:21] <Lachy> we need to be looking at the use cases from an authoring perspective
# [11:22] * Parts: zcorpan_ (zcorpan@88.131.66.80)
# [11:22] <robburns> Lachy: there's no hard and fast rule on the alt description. Sander proposes adding one for HTML5
# [11:22] <robburns> http://esw.w3.org/topic/HTML/LongdescRetention#head-ef01c5377a967ead313aeecea431de086517670a
# [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.
# [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
# [11:25] <Lachy> they're closer to problems that need to be addressed for the use cases
# [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
# [11:28] <Lachy> Would you be happy with renaming Beneficiaries to Problem Statements or something like that?
# [11:29] <robburns> Lachy: sure that would be fine. However, I think those should come first before the concrete examples.
# [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?
# [11:29] <Lachy> use cases come before problems
# [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
# [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.
# [11:33] <Lachy> the relevant *actor* is the author, not the end user in this case
# [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.
# [11:38] <Lachy> hold on, I'm updating the wiki again to describe them in technologically-independent terms (i.e. no implementation details)
# [11:38] * Joins: icaaq (icaaaq@85.228.52.46)
# [11:48] * Parts: icaaq (icaaaq@85.228.52.46)
# [11:49] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [11:52] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
# [11:54] * Joins: gavin (gavin@74.103.208.221)
# [11:55] * Joins: ROBOd (robod@86.34.246.154)
# [11:58] <Lachy> robburns, I updated it. Let me know if that's better
# [12:00] * Quits: olivier (ot@128.30.52.30) (Quit: Leaving)
# [12:04] * Quits: gsnedders (gsnedders@86.145.188.203) (Connection reset by peer)
# [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)".
# [12:10] <Lachy> I'm glad we can finally reached a compromise :-)
# [12:27] <robburns> :-)
# [12:35] * Quits: jmb (jmb@152.78.71.152) (Quit: Reconnecting)
# [12:35] * Joins: jmb (jmb@152.78.71.152)
# [12:42] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [12:51] * Quits: sbuluf (gdwwtrc@200.49.140.149) (Quit: sbuluf)
# [13:02] * Joins: zcorpan_ (zcorpan@88.131.66.80)
# [13:17] * Joins: matt (matt@128.30.52.30)
# [13:26] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
# [13:30] * Quits: Lachy (chatzilla@124.170.167.11) (Quit: ChatZilla 0.9.78.1 [Firefox 2.0.0.6/2007072518])
# [13:35] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
# [13:44] * Joins: ROBOd (robod@86.34.246.154)
# [13:52] * Joins: Lachy (chatzilla@124.170.133.138)
# [13:56] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [13:57] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [14:01] * Joins: gavin (gavin@74.103.208.221)
# [14:07] * Quits: matt (matt@128.30.52.30) (Quit: matt)
# [14:21] * Joins: matt (matt@128.30.52.30)
# [14:25] * Quits: matt (matt@128.30.52.30) (Quit: matt)
# [14:28] * Joins: thorny63 (thorny63@193.71.42.135)
# [14:29] * Quits: thorny63 (thorny63@193.71.42.135) (Quit: Terminated with extreme prejudice - dircproxy 1.0.5)
# [14:34] * Joins: Lionheart (robin@66.57.69.65)
# [14:42] * Quits: Lionheart (robin@66.57.69.65) (Connection reset by peer)
# [14:48] * Quits: robburns (robburns@208.54.7.180) (Quit: robburns)
# [14:50] * Joins: thorny63 (thorny63@193.71.42.135)
# [14:50] * Parts: thorny63 (thorny63@193.71.42.135)
# [14:52] * Joins: Lionheart (robin@66.57.69.65)
# [14:56] * Joins: polin8 (polin8@64.81.134.176)
# [14:57] * Quits: Lionheart (robin@66.57.69.65) (Quit: Leaving.)
# [15:12] * Joins: robburns (robburns@66.149.74.142)
# [15:31] * Quits: polin8 (polin8@64.81.134.176) (Quit: polin8)
# [15:44] * Joins: matt (matt@128.30.52.30)
# [15:53] * Quits: Lachy (chatzilla@124.170.133.138) (Ping timeout)
# [15:59] * Joins: Lachy (chatzilla@124.170.133.138)
# [16:03] * Quits: Lachy (chatzilla@124.170.133.138) (Ping timeout)
# [16:03] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [16:08] * Joins: gavin (gavin@74.103.208.221)
# [16:09] * Joins: Lachy (chatzilla@124.170.133.138)
# [16:15] * Quits: Lachy (chatzilla@124.170.133.138) (Ping timeout)
# [16:21] * Joins: Lachy (chatzilla@124.170.133.138)
# [16:31] * Quits: Lachy (chatzilla@124.170.133.138) (Ping timeout)
# [16:34] * Joins: Lachy (chatzilla@124.170.133.138)
# [16:35] * Joins: billmason (billmason@69.30.57.156)
# [16:38] * Quits: beowulf (beowulf@87.198.168.38) (Ping timeout)
# [16:57] * Joins: Lionheart (robin@66.57.69.65)
# [16:59] * Joins: gsnedders (gsnedders@86.145.188.203)
# [17:05] * Joins: billyjack (MikeSmith@mcclure.w3.org)
# [17:07] * Quits: robburns (robburns@66.149.74.142) (Ping timeout)
# [17:07] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
# [17:07] * Joins: myakura (myakura@58.88.44.99)
# [17:09] * billyjack is now known as MikeSmith
# [17:33] * Joins: robburns (robburns@98.193.22.194)
# [17:35] * Joins: billyjack (MikeSmith@mcclure.w3.org)
# [17:37] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
# [17:37] * billyjack is now known as MikeSmith
# [17:41] * Quits: gsnedders (gsnedders@86.145.188.203) (Quit: Don't touch /dev/null…)
# [17:42] * Quits: Lionheart (robin@66.57.69.65) (Connection reset by peer)
# [17:55] * Joins: Lionheart (robin@66.57.69.65)
# [17:55] <MikeSmith> geez, do we want public-html to become a forum for open letters...
# [17:56] * Joins: gsnedders (gsnedders@86.145.188.203)
# [17:57] * Parts: Lionheart (robin@66.57.69.65)
# [17:59] <Lachy> this link came to mind when I read that http://tantek.pbwiki.com/TrollTaxonomy#Bureaucraytroll
# [18:00] <Lachy> what right does Philip have to question what someone posts on their own blog?
# [18:00] <MikeSmith> Lachy, hey man, he's doing public service
# [18:01] <MikeSmith> calling out Anne VK's "irresponsibility"
# [18:01] * Quits: myakura (myakura@58.88.44.99) (Quit: Leaving...)
# [18:02] <Lachy> unfortunately, Anne's not here to defend himself, he's on holiday
# [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.
# [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
# [18:05] <Lachy> nor do I, but it's the way he said it and called it irresponsible
# [18:05] <MikeSmith> Philip` - but is public-html where we want a discussion about something like that to take place?
# [18:06] <MikeSmith> Lachy - but he didn't explicitly call it irresponsible, he asked Anne if he thinks it's irresponsible...
# [18:07] <MikeSmith> How many characters do you think it will take Anne to respond to that question?
# [18:07] <MikeSmith> I say, 2
# [18:07] <MikeSmith> 3, if he adds the optional period
# [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
# [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
# [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
# [18:08] <MikeSmith> gsnedders - true that
# [18:08] <gsnedders> IMO it really should've been directly to Anne
# [18:08] * Lachy agrees
# [18:09] <gsnedders> it's not a WG issue. it's an issue of the behaviour of one person outside of the WG
# [18:10] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [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
# [18:11] <MikeSmith> well, it's hard to see what Webmaster expects the productive outcome of posting it to public-html to be
# [18:11] <Philip`> (rather than discussing it with the 'outsiders' in the HTML WG)
# [18:12] <MikeSmith> that it wouldn't have been if he had just sent it directly to AVK
# [18:12] <Lachy> I think 'WHATWG people' is defined as Hixie, Anne, Henri, Simon, myself, etc. and anyone else who agrees with us.
# [18:12] * Joins: polin8 (polin8@64.81.134.176)
# [18:16] * Joins: gavin (gavin@74.103.208.221)
# [18:18] * Joins: aroben (adamroben@17.203.15.195)
# [18:20] * Joins: beowulf (beowulf@87.198.168.38)
# [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
# [18:21] <beowulf> does philip TAYLOR have an email quota to the html-wg to meet or something?
# [18:21] <gsnedders> and isn't it the case that a closed issue cannot be reopened unless explicitly done so by the chairs?
# [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
# [18:24] <Philip`> I would expect his favourite sites are all valid HTML 4.01
# [18:24] <Lachy> although, I shouldn't be too surprised, since he's not the only one to express that opinions
# [18:24] <Lachy> I wonder which bank he uses? Or if he uses Google?
# [18:25] <Lachy> I'm yet to see a bank use conforming HTML
# [18:27] <MikeSmith> many bank sites only work in IE anyway, so they could just as well be written in VBML
# [18:28] <Lachy> he's still clinging to the argument that "[<br/>] has totally different meanings in HTML and in XHTML"
# [18:29] * Joins: polin8_ (polin8@64.81.134.176)
# [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
# [18:30] <MikeSmith> not sure that "Collaborate with implementers" needs to be stated explicitly
# [18:30] * Quits: polin8 (polin8@64.81.134.176) (Ping timeout)
# [18:31] <MikeSmith> but if it does, "collaborate" seems to me to not be a strong enough description of what the process is
# [18:31] <gsnedders> MikeSmith: it's in our charter
# [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."
# [18:33] <MikeSmith> gsnedders - yeah, there's that too
# [18:33] <gsnedders> which kinda forces us to collaborate
# [18:34] <gsnedders> and if we just define an SGML language, I doubt any implementors will stay
# [18:34] <Lachy> ha! Apparently I'm not open to alternative points of view
# [18:34] <gsnedders> Lachy: My name is Malcolm from hereon.
# [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
# [18:34] <Lachy> gsnedders, what?
# [18:35] <gsnedders> Lachy: your POV of my name is changing!
# [18:35] <gsnedders> MikeSmith: ww'll leave if we don't pay attention to them though
# [18:35] <gsnedders> *we
# [18:36] <Lachy> gsnedders, am I supposed to object to you changing your name?
# [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
# [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."
# [18:36] <gsnedders> Lachy: forget it. I've confused you too much :)
# [18:36] <MikeSmith> let them go -- they we can start the fun all over again from scratch with a new charter
# [18:37] <MikeSmith> Lachy, whose suggestion is that?
# [18:37] <Lachy> though, if she didn't qualify that with the email address, I'd agree with the last nomination ;-)
# [18:37] <Lachy> Laura Carlson
# [18:37] <MikeSmith> well, on a more serious side...
# [18:37] <gsnedders> "this document" == ?
# [18:38] <Philip`> I'd be useless since I'm totally unprincipled :-p
# [18:38] <gsnedders> Philip` Principles: obey your masters (e.g., each and every member of the WG)
# [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...
# [18:39] <MikeSmith> can one of you please reply with an open letter to me about that?
# [18:39] <gsnedders> MikeSmith: I wouldn't. Maybe do so, and CC it to www-archive, though.
# [18:40] <Lachy> let's all write open letters to each other
# [18:40] <beowulf> yay!
# [18:40] <beowulf> open letter day
# [18:40] <gsnedders> paper!
# [18:40] <gsnedders> paper!
# [18:40] <gsnedders> paper!
# [18:40] <Lachy> ;-)
# [18:40] <gsnedders> (on an unrelated note, I didn't get the top grade for practical computing at school)
# [18:40] * Joins: jgraham_ (jgraham@131.111.69.116)
# [18:41] <Lachy> gsnedders, did you get 2nd?
# [18:41] <beowulf> can we also make sure to call html authors lazy and ignorant and any other elitist language you find...
# [18:41] <gsnedders> Lachy: yes. probably lost marks for being better than the answers in parts :P
# [18:41] * beowulf bites tongue
# [18:41] <gsnedders> Lachy: well, not in the practical.
# [18:42] <Lachy> beowulf, we should just say how irresponsible this discussion we're having is
# [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 :(
# [18:44] <DanC> re open letter... http://lists.w3.org/Archives/Public/www-archive/2007Aug/0042.html
# [18:48] <MikeSmith> DanC - and I see he responded -
# [18:48] <MikeSmith> http://lists.w3.org/Archives/Public/www-archive/2007Aug/0043.html
# [18:49] <Lachy> I don't see what relevance him speaking positively of Anne in the survey is
# [18:49] <beowulf> vendetta?
# [18:49] <beowulf> huh?
# [18:51] * MikeSmith wishes we could get this other Philip Taylor to join the #html-wg channel
# [18:51] * beowulf also
# [18:51] <MikeSmith> it might save him a lot of time posting stuff to the list
# [18:51] <MikeSmith> if he could just talk to people directly here
# [18:51] <Lachy> do you think it would productive for him?
# [18:52] <Lachy> and for us?
# [18:52] <MikeSmith> Lachy - yeah, definitely
# [18:52] <Lachy> maybe, it is sometimes useful to discuss issues in real time to resolve them, instead of trying over email
# [18:53] <MikeSmith> He could have direct discussions with everybody here
# [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
# [18:54] <jgraham_> MikeSmith, direct discussions f2f are more human than via IRC so I guess more effective at solving personality conflicts
# [18:54] <Lachy> but IRC is slightly more human than email is too, so it would probably be an improvment
# [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
# [18:57] <gavin_> I don't think IRC is any more "human" than email
# [18:57] * Joins: Lionheart (robin@66.57.69.65)
# [18:58] <gavin_> still impossible to use visual (or even auditory) cues to gauge emotion
# [18:58] <beowulf> Lachy: flamebait
# [18:58] <Lachy> gavin. that
# [18:58] <Lachy> that's what emoticons are for
# [18:59] <gavin_> emoticons are entirely insufficient :)
# [19:00] <MikeSmith> jgraham_ - would that direct discussions f2f were practical for resolving these kinds of issues
# [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
# [19:00] <gsnedders> text has limitations in any form
# [19:00] <Lachy> they seem to cover the full range of emotions from sad: :-( to grumpy :-| to happy: :-)
# [19:01] <MikeSmith> jgraham_ - I meant, that it were possible/practical to get people together more often
# [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
# [19:01] <DanC> understatement
# [19:01] <gsnedders> they can provide the entire context of something.
# [19:02] <gsnedders> In what I just linked to, just seeing me crying would give the meaning back to it.
# [19:02] <jgraham_> Lachy, "not everyone has the emotion range of a teaspoon"
# [19:02] * jgraham_ misquotes? Harry Potter
# [19:02] <Lachy> ;-)
# [19:02] <gsnedders> jgraham: correct quote, I think
# [19:03] <gsnedders> (I really shouldn't be admitting that I think that the quote is right)
# [19:03] <Lachy> jgraham_, looks like it's the correct quote http://community.livejournal.com/hp_spoons/
# [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
# [19:05] <jgraham_> Lachy: Well I was pretty close anyway
# [19:07] * Quits: Lionheart (robin@66.57.69.65) (Connection reset by peer)
# [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.
# [19:17] <MikeSmith> Anyway, I just e-mailed Philip to suggest he might want to join #html-wg some time
# [19:17] <MikeSmith> http://www.w3.org/mid/20070823171155.GA7840@mikesmith
# [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...
# [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
# [19:21] <zcorpan_> today i've been writing test cases for... content-type sniffing... and processing of HTML color attributes. yay :)
# [19:21] * Lachy looks forward to his response
# [19:22] * Joins: kingryan (rking3@208.66.64.47)
# [19:22] <zcorpan_> re the australian flag thing, one would just say "go to the australian site"
# [19:23] <Lachy> that's what I thought
# [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
# [19:24] <Lachy> I don't think someone would give visually oriented instructions to a friend, whom they would presumably know was blind
# [19:24] <zcorpan_> i wouldn't give such instructions even to someone who can see
# [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
# [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 :-)
# [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.
# [19:28] * Joins: Lionheart (robin@66.57.69.65)
# [19:33] * Joins: tH_ (Rob@87.102.90.11)
# [19:34] * Quits: tH (Rob@87.102.85.245) (Ping timeout)
# [19:34] * tH_ is now known as tH
# [19:38] * Quits: zcorpan_ (zcorpan@88.131.66.80) (Ping timeout)
# [19:42] <mjs> Lachy: wow, people love reverting your edits to that longdesc page
# [19:44] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
# [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
# [19:45] * Quits: aroben (adamroben@17.203.15.195) (Quit: aroben)
# [19:45] <Lachy> Gregory completely removed my use cases, and shifted the examples right to the end
# [19:45] * Joins: aroben (adamroben@17.203.15.195)
# [19:50] <MikeSmith> ah, and now another message cross-posted to four different mailing lists, demanding a response
# [19:50] <Lachy> and again it's directed at me!
# [19:50] <Lachy> and Hixie
# [19:50] * billmason is curious how many times Hixie has to announce how much email backlog he has before people get it
# [19:51] <Philip`> http://canvex.lazyilluminati.com/misc/issueage.html
# [19:51] <Philip`> (Don't ask me why one issue is apparently 491 months old)
# [19:52] <MikeSmith> yeah, and if you respond to it, you get to enjoy perpetuating combative threads on four lists instead of just one
# [19:52] <Lachy> I'm choosing not to respond this time
# [19:52] <kingryan> Philip`: 491 months would be 1967. I'm sure there were html issues then. :)
# [19:52] <Lachy> I don't see it doing any good
# [19:53] <Philip`> Hixie: <19700101011405970191.5386b4d6@empyree.org> has a timestamp of 845 seconds since the epoch
# [19:53] * MikeSmith contemplates replying to the sender with a "Have you considered trying #html-wg" message ...
# [19:53] <MikeSmith> Lachy - you are making the right choice, I think
# [19:54] <MikeSmith> at least not responding to it on the list(ssss)
# [19:54] <MikeSmith> extra "s" for all the extra lists cross-posted to
# [19:56] <Philip`> The mean age of the issues currently in the list is 10.1 months
# [19:56] <Philip`> Oh, maybe I should get rid of the four-decade one first
# [19:58] <Philip`> The mean age of the issues currently in the list is 10.0 months
# [19:59] <Philip`> (longer that the HTML WG's lifetime)
# [19:59] <gsnedders> big change for a mean
# [19:59] <gsnedders> (with such an out of proportion item)
# [19:59] <gsnedders> </sarcasm>
# [19:59] <Philip`> (*Longer than the ...)
# [20:09] <Lachy> hmm. It seems Gregory totally misunderstands what a use case is and misunderstood the reason I included his photo album.
# [20:09] <Philip`> <p> sounds naughty - I think we should rename it to <para>
# [20:09] * Lachy will respond tomorrow.
# [20:09] <Lachy> good night all
# [20:09] <MikeSmith> Philip` - or <pp>
# [20:09] <MikeSmith> Lachy - 'night
# [20:12] <MikeSmith> kingryan - I came up with idea of HTML back in 1967 while smoking grass with Abbie Hoffman in MacArthur Park
# [20:13] <MikeSmith> but not the issues, because we weren't into "issues" and negativity back then
# [20:15] * Quits: jgraham_ (jgraham@131.111.69.116) (Quit: This computer has gone to sleep)
# [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
# [20:16] <Lachy> robburns, it is you who doesn't understand what a use case is
# [20:16] <robburns> Lachy: OK (LOL)
# [20:17] <MikeSmith> robburns - hi
# [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.
# [20:18] <robburns> MikeSmith: hi
# [20:19] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [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.
# [20:19] <MikeSmith> s/Abbie Hoffman/Al Gore/
# [20:20] <robburns> Lachy: linking to a website that makes use of existing HTML 4.01 features is not a use-case
# [20:20] <Lachy> it's an example that demonstrates the use case
# [20:20] <robburns> OK., it's an example. That's what I thought we established before.
# [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
# [20:21] <MikeSmith> robburns - can I interject a question for a second here?
# [20:21] <MikeSmith> a general question
# [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.
# [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
# [20:21] <Lachy> no, it's not
# [20:21] <robburns> MikeSmith: sure go ahead
# [20:22] <Lachy> I'm not repeating this discussion with you, it won't get us anywhere because you're not listening
# [20:22] <robburns> Lachy: in this case authors and their publishing needs are driven by the user and their using needs
# [20:22] * Joins: hasather (hasather@80.202.164.152)
# [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."
# [20:24] * Joins: gavin (gavin@74.103.208.221)
# [20:26] <robburns> MikeSmith: what was your question?
# [20:27] <MikeSmith> I assume you intended that as a sort of joke?
# [20:28] <MikeSmith> That comment, I mean.
# [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."
# [20:29] * Quits: hyatt (hyatt@24.6.184.144) (Quit: hyatt)
# [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.
# [20:30] <MikeSmith> robburns - and ...?
# [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.
# [20:31] <MikeSmith> My question was, did you intend that comment as a joke?
# [20:32] <MikeSmith> Just asking
# [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.
# [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.
# [20:34] <gsnedders> robburns: there are multiple ways of describing a use case — both what you and Lachy are arguing are valid
# [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?
# [20:35] * Parts: billmason (billmason@69.30.57.156)
# [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."?
# [20:37] <MikeSmith> I'm just sorta trying to understand here
# [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.
# [20:37] <robburns> \MikeSmith: I What, did I have too much faith in him?
# [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"
# [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
# [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?
# [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
# [20:41] <robburns> gsnedders: Lachy said: "It's an example that demonstrates the use case"
# [20:41] <robburns> MikeSmith: no
# [20:41] <MikeSmith> robburns - so how would you characterize that comment, then?
# [20:41] <robburns> MikeSmith: it definitely appears he's not big enough to admit it. No joke there.
# [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
# [20:42] <robburns> Lachy: what needs to be added to that for it to be a use case?
# [20:43] <Lachy> perhaps a description of the type of images that "the original image" is referring to! Like diagrams, flowcharts, photography or screenshots
# [20:43] * Joins: mjs (mjs@17.203.14.224)
# [20:44] * Parts: matt (matt@128.30.52.30)
# [20:44] <Lachy> in other words, *describing the cases where a long description would be appropriate*
# [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"
# [20:44] <robburns> s/are/is
# [20:45] <Lachy> no
# [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)
# [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
# [20:47] <robburns> perhaps another use case relates to an image used as an icon
# [20:47] * Quits: hasather (hasather@80.202.164.152) (Client exited)
# [20:47] <robburns> I don't see much point in the other distinctions. At least not at the level it gets solved by HTML5
# [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
# [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)
# [20:49] <robburns> description of the visual content that is
# [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.
# [20:50] * Joins: hasather (hasather@80.202.164.152)
# [20:51] <mjs> do I need to do another remedial class on "what is a use case"?
# [20:51] <robburns> mjs: hi
# [20:51] <robburns> mjs: I don't think it has to be remedial, Lachy's coming along pretty well now
# [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.
# [20:52] <DanC> but if you have to do a class, mjs, then it's not remedial.
# [20:52] <mjs> DanC: I tried to help Lachy and robburns understand what constitutes a use case last night
# [20:52] <mjs> I think both of them were getting it somewhat wrong
# [20:52] <mjs> but they still seem to be arguing
# [20:52] * DanC reads http://en.wikipedia.org/wiki/Use_case ...
# [20:53] <robburns> DanC: I quoted that before
# [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
# [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
# [20:54] <DanC> http://en.wikipedia.org/wiki/Use_case doesn't look like an exact match.
# [20:54] <robburns> DanC: and it does largely match what I expected it to say
# [20:54] * Joins: hyatt (hyatt@17.203.15.154)
# [20:54] <mjs> robburns: there's nothing wrong with illustrating a use case with one or more examples
# [20:54] <DanC> http://en.wikipedia.org/wiki/Use_case has a lot about UML and business rules
# [20:54] <robburns> DanC: what issues would you take with it?
# [20:55] * Parts: hasather (hasather@80.202.164.152)
# [20:55] <mjs> the basic form of a use case is "in situation X, the relevant actor wants to achieve goal Y"
# [20:56] <mjs> you want to specify the actor, the situation and the goal
# [20:56] <DanC> wikipedia concurs: "Each use case describes how the actor will interact with the system to achieve a specific goal. "
# [20:56] <mjs> you don't want to specify the details of how the goal is to be achieved
# [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).
# [20:56] * Joins: hasather (hasather@80.202.164.152)
# [20:56] <robburns> mjs: except the details probably have something to do with HTML or it's out of scope.
# [20:56] <mjs> a list of users is not a list of use cases
# [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
# [20:57] <robburns> mjs: and it has something to do with a UA that consumes HTML
# [20:57] * DanC wonders if it's worth sticking a working definition in an esw UseCase topic... wonders if there is already one there...
# [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.
# [20:57] <mjs> I think I need to write something up
# [20:57] <DanC> nop; no http://esw.w3.org/topic/UseCase yet ...
# [20:58] <DanC> oh... UseCases...
# [20:58] <DanC> but what's there isn't relevant
# [20:58] <mjs> robburns: I would put the user-perspective use case like this:
# [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."
# [21:01] <robburns> mjs: that's a fine approach except that page is not so focussed.
# [21:02] <robburns> It's focussed on alternate/equivalent/fallback in general so the last clause would go
# [21:02] * DanC would need a more specific example in order to really engage my brain
# [21:02] <robburns> The first sentence basically conveys what Gregory's list conveys
# [21:02] <robburns> He didn't include the fact that the user wanted to understand the page
# [21:03] <robburns> and perhaps he didin't mention that the images were essential
# [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"
# [21:03] <robburns> I never thought to add those minor two facts, because I thought they were just too obvious
# [21:03] <mjs> that's interesting only if you think you'd pick a different solution based on these constituencies
# [21:03] <mjs> now, authoring-perspective use cases would look something like this:
# [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.
# [21:04] <DanC> somebody told me about some WAI documents with scenarios a bit like this... I think "business case" was the label.
# [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
# [21:05] <DanC> I hope to find those "business case" documents because, as I recall, the examples in them were particularly motivating.
# [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.
# [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."
# [21:06] <Lachy> mjs, the user perspective case would need to describe what type of image(s) for which alt text is insufficient
# [21:06] <mjs> robburns: yes, but I think Gregory is also working with a built-in assumption that every image should have a longdesc
# [21:06] <robburns> mjs: that sounds good. Except again the page is not just about longdesc anymore. It's about all text equivalents
# [21:07] <robburns> mjs: I'm working from the same built-in assumption.
# [21:07] <robburns> mjs: or at least the ones worth putting on a public website
# [21:07] <robburns> mjs: the ones where the lens cap was left on probably don't need any description
# [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
# [21:08] <mjs> robburns: so making use cases that assume your desired conclusion is not fruitful to the discussion
# [21:08] <robburns> mjs: but the lens cap photos won't be deemed good enough for the web page either
# [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
# [21:09] <mjs> I think the flag example is illlustrative of this point of view
# [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
# [21:09] <robburns> I think that brief alt text is sufficient for icons
# [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
# [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
# [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
# [21:10] <mjs> that's a real example he posted in the past
# [21:11] <robburns> mjs: in the select a country case that's what I'm referring to as an icon
# [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
# [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
# [21:12] <mjs> robburns: he posted that specific example (using the british flag) to public-html
# [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.
# [21:12] <mjs> robburns: I have no reason to believe he has changed his mind since then
# [21:12] <mjs> I think having a long description in cases where the flag is not the point is actively harmful
# [21:12] <mjs> because it's distracting from the user's goal
# [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
# [21:13] <MikeSmith> robburns - How well do you know Gregory?
# [21:13] <mjs> anyway
# [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
# [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
# [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
# [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="">
# [21:15] <mjs> robburns: I'm basing this specific example on a message he sent to the mailing list
# [21:15] <robburns> mjs: but it doesn't really hurt either.
# [21:16] * Joins: mjs_ (mjs@17.203.14.224)
# [21:16] * Quits: mjs (mjs@17.203.14.224) (Connection reset by peer)
# [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)
# [21:18] <robburns> mjs: I think if you looked at the example again, it doesn't support what you're thinking
# [21:18] <mjs_> I don't think having the list is bad
# [21:18] <robburns> mjs: that's good
# [21:18] <mjs_> it's just not a list of use cases
# [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
# [21:19] <robburns> mjs: not that I'm against mentioning them
# [21:21] * mjs_ is now known as mjs
# [21:21] <mjs> let's look at an example
# [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."
# [21:23] <mjs> that one is not that bad, though it could certainly be improved
# [21:23] <mjs> it seems to be assuming that both short and long descriptions are desirable just by stating it
# [21:23] <mjs> instead of illustrating when that might be necessary
# [21:24] <mjs> but then look at the "Legally Blind Users" example
# [21:24] <mjs> it just describes what the term "Legally Blind" means
# [21:25] <mjs> it doesn't say anything about what the user wants to do
# [21:25] <mjs> or clarify how it differs from what a blind user might want to do, if at all
# [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
# [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
# [21:27] <mjs> robburns: what do you mean? I just quoted what the page says for "Blind Users"
# [21:28] <mjs> and it assumes a disctinction between "a short summary of the image" and "a more detailed description"
# [21:28] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Client exited)
# [21:28] <mjs> robburns: I guess the page is ignoring what you said about what the page says
# [21:28] <robburns> mjs: no, I don't think it is
# [21:28] <mjs> robburns: I guess you are saying the stated use case for Blind Users is bad
# [21:28] <mjs> since it assumes details of the solution
# [21:29] <mjs> or maybe you agree with it now that you know Gregory wrote it and not me
# [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)
# [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.
# [21:32] <mjs> I gotta go to lunch
# [21:32] <mjs> catch you later
# [21:32] <robburns> mjs: catch you later
# [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"?
# [21:34] <jgraham> Hixie: That sounds like a sensible problem description to me.
# [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
# [21:37] <jgraham> Lachy: I don't think the page does make that distinction
# [21:37] <jgraham> (despite its title)
# [21:37] <Lachy> well that's what I thought the whole longdesc page was about
# [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
# [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
# [21:38] <jgraham> I'm not so sure that's true.
# [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)
# [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)
# [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
# [21:40] <Hixie> it's still the same problem
# [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
# [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
# [21:41] <Lachy> because if the distinction isn't made, how can one tell if alt="" is sufficient for all the cases or not?
# [21:42] <jgraham> Lachy: by evaluating alt as a solution and seeing if it covers all cases or not
# [21:42] <Hixie> i'll look at the examples in turn
# [21:42] <Hixie> and make sure the spec can handle them
# [21:42] <Lachy> yeah, right, and we need to find and document those cases where it isn't
# [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)
# [21:43] <Hixie> i'm not reading anything
# [21:43] <Hixie> i'm saying what it should be like
# [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
# [21:43] <robburns> Hixie: but are you talking about "whole separate page" as in where @longdesc points to another page?
# [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
# [21:45] <robburns> not an inherent part anyway
# [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
# [21:48] * Joins: dbaron (dbaron@63.245.220.241)
# [21:48] <robburns> Hixie: ok
# [21:51] * Joins: briansuda (briansuda@85.220.84.60)
# [21:52] * Quits: kingryan (rking3@208.66.64.47) (Ping timeout)
# [21:52] * Quits: schepers (schepers@128.30.52.30) (Ping timeout)
# [21:58] * Quits: beowulf (beowulf@87.198.168.38) (Ping timeout)
# [22:13] * Quits: Lachy (chatzilla@124.170.133.138) (Ping timeout)
# [22:15] <DanC> what's the date of this change http://html5.org/tools/web-apps-tracker?from=996&to=997 ?
# [22:16] <DanC> ah...
# [22:16] <DanC> 2007-08-10 02:38
# [22:19] * Joins: Zeros (Zeros-Elip@69.140.40.140)
# [22:19] * Quits: Zeros (Zeros-Elip@69.140.40.140) (Client exited)
# [22:20] * Joins: Lachy (chatzilla@124.170.133.138)
# [22:20] * Joins: kingryan (rking3@208.66.64.47)
# [22:26] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [22:31] * Joins: gavin (gavin@74.103.208.221)
# [22:40] * Quits: kingryan (rking3@208.66.64.47) (Quit: kingryan)
# [22:45] * Joins: zcorpan_ (zcorpan@84.216.40.15)
# [22:49] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
# [22:59] * Quits: mjs (mjs@17.203.14.224) (Ping timeout)
# [23:03] * Parts: hasather (hasather@80.202.164.152)
# [23:04] * Quits: briansuda (briansuda@85.220.84.60) (Connection reset by peer)
# [23:04] * Joins: briansuda (briansuda@85.220.84.60)
# [23:11] * Quits: robburns (robburns@98.193.22.194) (Quit: robburns)
# [23:11] * Joins: mjs (mjs@17.255.100.25)
# [23:14] * Joins: robburns (robburns@98.193.22.194)
# [23:16] * Joins: mjs_ (mjs@17.203.14.224)
# [23:19] * Quits: mjs (mjs@17.255.100.25) (Ping timeout)
# [23:23] * Quits: briansuda (briansuda@85.220.84.60) (Quit: briansuda)
# [23:23] * Quits: robburns (robburns@98.193.22.194) (Ping timeout)
# [23:25] * Joins: kingryan (rking3@208.66.64.47)
# [23:44] * Quits: hober (ted@68.107.112.172) (Quit: ERC Version 5.2 (IRC client for Emacs))
# [23:44] * Quits: polin8_ (polin8@64.81.134.176) (Ping timeout)
# Session Close: Fri Aug 24 00:00:00 2007

The end :)