/irc-logs / w3c / #html-wg / 2007-10-01 / end

Options:

# Session Start: Mon Oct 01 00:00:00 2007
# Session Ident: #html-wg
# [00:01] * Joins: schepers (schepers@128.30.52.30)
# [00:16] * Quits: timbl (timbl@70.108.26.144) (Quit: timbl)
# [00:20] * Quits: dbaron (dbaron@71.204.145.103) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [01:02] * Quits: heycam (cam@203.214.33.166) (Ping timeout)
# [01:19] * Quits: gavin_ (gavin@99.226.75.20) (Ping timeout)
# [01:23] * Joins: gavin_ (gavin@99.226.75.20)
# [01:25] * Joins: heycam (cam@130.194.72.84)
# [01:58] * Joins: karl (karlcow@128.30.52.30)
# [02:07] * Joins: Lionhear1 (robin@66.57.69.65)
# [02:07] * Quits: Lionheart (robin@66.57.69.65) (Ping timeout)
# [03:51] * Joins: olivier (ot@128.30.52.30)
# [04:23] * Joins: Lachy (chatzilla@124.171.26.6)
# [04:25] * Parts: Shunsuke (Shunsuke@123.176.107.50)
# [04:26] * Quits: gavin_ (gavin@99.226.75.20) (Ping timeout)
# [04:31] * Joins: gavin_ (gavin@99.226.75.20)
# [05:33] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
# [05:33] * Quits: Lachy (chatzilla@124.171.26.6) (Quit: ChatZilla 0.9.78.1 [Firefox 2.0.0.6/2007072518])
# [06:16] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [06:22] * Joins: heycam (cam@203.214.33.166)
# [06:34] * Quits: gavin_ (gavin@99.226.75.20) (Ping timeout)
# [06:39] * Joins: gavin_ (gavin@99.226.75.20)
# [06:58] * Joins: Shunsuke (Shunsuke@123.176.107.50)
# [07:30] * Quits: emeriste (emeriste@69.22.229.84) (Ping timeout)
# [07:32] * Joins: emeriste (emeriste@69.22.229.84)
# [07:45] * Joins: hyatt (hyatt@209.173.92.142)
# [07:46] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
# [07:55] * Quits: heycam (cam@203.214.33.166) (Ping timeout)
# [08:13] * Joins: heycam (cam@203.214.114.92)
# [08:42] * Quits: gavin_ (gavin@99.226.75.20) (Ping timeout)
# [08:42] * Quits: aroben (aroben@67.160.250.192) (Quit: Leaving)
# [08:44] * Quits: hyatt (hyatt@209.173.92.142) (Quit: hyatt)
# [08:47] * Joins: gavin_ (gavin@99.226.75.20)
# [08:54] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [09:15] * Joins: aaronlev (chatzilla@209.6.168.245)
# [09:25] * Quits: olivier (ot@128.30.52.30) (Quit: Leaving)
# [09:27] * Quits: heycam (cam@203.214.114.92) (Ping timeout)
# [09:31] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
# [09:40] * Joins: Steve_f (chatzilla@82.44.69.8)
# [10:09] * Joins: heycam (cam@203.214.114.92)
# [10:27] * Quits: aaronlev (chatzilla@209.6.168.245) (Ping timeout)
# [10:27] * Joins: ROBOd (robod@89.122.216.38)
# [10:34] * Quits: heycam (cam@203.214.114.92) (Quit: bye)
# [10:39] * Joins: zcorpan_ (zcorpan@88.131.66.80)
# [10:50] * Quits: gavin_ (gavin@99.226.75.20) (Ping timeout)
# [10:55] * Joins: gavin_ (gavin@99.226.75.20)
# [11:53] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
# [12:57] * Quits: gavin_ (gavin@99.226.75.20) (Ping timeout)
# [13:02] * Joins: gavin_ (gavin@99.226.75.20)
# [13:02] * Quits: ROBOd (robod@89.122.216.38) (Quit: http://www.robodesign.ro )
# [13:47] <anne> maybe "afterthought" should be "after-the-fact"
# [13:58] <zcorpan_> hmm, i'm not sure i get the aol-buddylist fallback example
# [13:59] <zcorpan_> would the aol-buddylist have an accessibility API mapping of its own?
# [14:00] <hsivonen> zcorpan_: either yes, or you have just uncovered a chunk of failed communication on the ARIA topic
# [14:01] <hsivonen> zcorpan_: if the answer is "no", I have severely misunderstood something
# [14:02] * zcorpan_ doesn't know the answer, but has specced assuming "no"
# [14:03] <anne> zcorpan_, the idea is that you can specify a single widget type with fallbacks, like font-family in CSS
# [14:03] <anne> so the widget type would be "aol-buddlylist" but it's "list" if that's not supported
# [14:05] <zcorpan_> so "yes"
# [14:05] <anne> yeah, unless it's bogus :)
# [14:06] <zcorpan_> define bogus, please :)
# [14:06] <anne> hmm
# [14:06] <anne> bogus being a value that's incorrect and doesn't map to anything at all anywhere
# [14:07] <zcorpan_> i.e. "not supported"?
# [14:07] <anne> yeah, if you consider <html:bogus> to be like that
# [14:08] <zcorpan_> ok
# [14:09] <zcorpan_> not sure how to define it; i mean we don't want to directly disallow other types of roles that do other things than accessibility api mapping
# [14:09] <zcorpan_> and such roles shouldn't suppress the aria mapping
# [14:09] <zcorpan_> even if "supported"
# [14:09] <anne> why don't we want to disallow those?
# [14:09] <anne> another point of my proposal was to fork the XHTML role module
# [14:11] <zcorpan_> supporting other roles isn't necessarily incompatible with doing the aria mapping, i don't see a good reason to ban them
# [14:11] <anne> make role= work for a single thing, not hundreds and be done with it
# [14:11] <hsivonen> fwiw, I had certain doubts when UI strings in RDF were mentioned
# [14:11] <hsivonen> doubts about what "support" means, that is
# [14:12] <anne> zcorpan_, 1) gives authors a clue as to what role= does; 2) simplifies stuff for implementors; 3) makes this fallback proposal work
# [14:12] <zcorpan_> another thing: are these equivalent?: role="aol-buddylist" role="wairole:aol-buddylist"
# [14:13] <anne> i'd say yes
# [14:13] <anne> i'd also make wairole: non-conforming if it appears anywhere in role=
# [14:14] <zcorpan_> we can do that later; dojo needs to do something that works in firefox 2
# [14:15] <anne> dojo doesn't conform to anything afaict
# [14:15] <zcorpan_> fair enough
# [14:16] <zcorpan_> i'm not sure i like wairole: being stripped from all tokens, i think it makes more sense to have a list of tokens where each aria role has two strings representing the role
# [14:17] <anne> good point, that does seem better
# [14:21] <anne> I think letting role= do a lot of things is dangerous. We already have <object>. Lets not introduce another one (in attribute form!)
# [14:38] * Joins: ROBOd (robod@89.122.216.38)
# [15:01] <zcorpan_> updated the spec; does it seem ok?
# [15:01] <anne> I think you should remove the bit about http://www.w3.org/2002/06/xhtml2/
# [15:02] <anne> wasn't it also the plan to have html:role not work on html:x
# [15:02] <zcorpan_> that was the plan; does the spec say otherwise?
# [15:03] <anne> the authoring requirements suggest otherwise
# [15:04] <anne> it's also important that the custom role is supported by the AT, otherwise it's useless
# [15:04] <anne> "Note: In this version of this specification, only the first supported role is used." can be removed
# [15:04] <anne> and "Note: No namespace lookup of the attribute value is performed in this version of this specification." prolly too
# [15:04] <anne> that's both by design
# [15:05] <anne> you should prolly make it more clear that if the algorithm returns the empty string (null or none might be better) that the element then does not have an associated role identifier
# [15:06] * Joins: myakura (myakura@124.84.120.239)
# [15:17] * Quits: gavin_ (gavin@99.226.75.20) (Ping timeout)
# [15:22] * Joins: gavin_ (gavin@99.226.75.20)
# [15:22] <hsivonen> anne: I restored the human-readable validation result to (X)HTML and text outputs
# [15:23] <hsivonen> anne: thanks for reminding me
# [15:23] * Joins: timbl (timbl@146.115.66.146)
# [15:23] <anne> hah, I said what, when? :)
# [15:24] <anne> oh, http://validator.nu/?doc=http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml%2F returns "validates" again
# [15:24] <hsivonen> anne: http://krijnhoetmer.nl/irc-logs/html-wg/20070929#l-8
# [15:25] * Quits: Lionhear1 (robin@66.57.69.65) (Quit: Leaving.)
# [15:29] <hsivonen> hrm. putting the file control first would totally break streamability of multipart/form-data
# [15:29] <hsivonen> but putting it last would be bad UI :-(
# [15:31] * Quits: timbl (timbl@146.115.66.146) (Quit: timbl)
# [15:31] <anne> you want XBL
# [15:33] <hsivonen> if I move the file control on onsubmit, will the UA clear it for security reasons or something?
# [15:34] <zcorpan_> anne: "Authors may specify a role attribute in the http://www.w3.org/1999/xhtml namespace on any element that is not in the http://www.w3.org/1999/xhtml ... namespace." -- that doesn't allow <h:x h:role="">, no?
# [15:35] <anne> oh, I read the first paragraph incorrectly, sorry
# [15:36] <zcorpan_> anne: could you send the suggestion about the .../xhtml2/ namespace to the list(s), please?
# [15:37] <hsivonen> is there an elegant way to run DOM manipulation script immediately when the <form> element on v.nu has got all its children inserted by the parser and that doesn't involve putting <script>foo();</script> in the content stream right after the form?
# [15:37] * Joins: karl (karlcow@128.30.52.30)
# [15:37] <anne> hsivonen, maybe you should reorder the controls onsubmit
# [15:38] <hsivonen> anne: ok
# [15:53] * Joins: aaronlev (chatzilla@66.31.86.217)
# [15:53] <anne> zcorpan_, I suppose, at some point
# [15:54] <anne> zcorpan_, prolly around the time I'll object against the authoring requirements mentioning namespaces and such
# [15:56] <anne> zcorpan_, more about the algorithm, say "let the result of splitting the string on spaces be tokens"
# [15:56] <anne> zcorpan_, for each <var>token</var> in <var>tokens</var>
# [15:56] <anne> (is that operation ordered?)
# [15:58] <zcorpan_> anne: the algorithm referenced does that
# [15:58] <anne> it returns tokens to what?
# [15:58] <anne> hmm
# [15:59] <zcorpan_> aha
# [16:00] <anne> also note my earlier remark about it being unclear what the empty string role identifier is
# [16:00] <anne> or does
# [16:01] * Joins: tH (Rob@87.102.67.202)
# [16:04] <zcorpan_> anne: fixed the algorithm. added a note about the empty role identifier
# [16:06] <anne> hmm
# [16:07] <anne> i would say "unless the role identifier is presentation or the empty string"
# [16:08] <anne> that also prevents people from defining the empty string and space characters as valid role values in practice
# [16:08] <anne> (well, space characters as already prevented)
# [16:09] <zcorpan_> UAs should still pass along the entire value when they don't recognize any tokens
# [16:10] <zcorpan_> (using the "xml-roles" object attribute in some APIs)
# [16:12] <anne> yeah...
# [16:16] * Joins: timbl (timbl@128.30.7.41)
# [16:21] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
# [16:22] * Quits: myakura (myakura@124.84.120.239) (Quit: Leaving...)
# [16:37] <anne> zcorpan_, I believe ref, registrationmark and template will become superglobal attributes too
# [16:48] <zcorpan_> anne: ok
# [16:49] * Joins: billmason (billmason@69.30.57.156)
# [17:01] <zcorpan_> aaronlev: why does "presentation" need to be special cased?
# [17:01] <aaronlev> it's in the part of the code that builds the accessible tree
# [17:01] <anne> what does "presentation" do?
# [17:02] <aaronlev> UAs must expose the entire object to the AT using accessibility API specific methods, unless the object is strictly for presentation.
# [17:02] <aaronlev> An object is strictly for presentation if any of the role identifiers in the role attribute is "presentation", and the object is not focusable. In other words, the role of presentation overrides all other roles to indicate an object as no semantic or accessible importance, unless it is focusable.
# [17:02] <zcorpan_> that doesn't quite fit in the current draft, since there will only be one role identifier
# [17:03] <anne> <div role="wairole:checkbox wairole:presentation"> would do what in Firefox currently?
# [17:03] <aaronlev> anne: right now our code to deal with multiple roles is broken
# [17:03] <aaronlev> but presentation is special, it means this thing has no semantic value
# [17:03] <anne> how do ATs implement it?
# [17:04] <aaronlev> it''s just easier to ignore it in the multiple role case, or make it override everything else
# [17:04] <anne> (i don't think multiple roles should be implemented, see proposal on HTML list)
# [17:04] <aaronlev> anne: they don't have to implement it, because we don't expose that object to them at all
# [17:04] <anne> <table role=presentation> helps how?
# [17:04] <anne> I'm not sure this role makes sense
# [17:04] <aaronlev> anne: you put that on a layout able
# [17:04] <aaronlev> on a layout table
# [17:05] <aaronlev> so the AT just sees the table cell content
# [17:05] <anne> but ATs don't support it?
# [17:05] <anne> it seems to encourage presentational markup
# [17:05] <anne> bah
# [17:05] <zcorpan_> aaronlev: does "presentation" override implicit roles?
# [17:06] <aaronlev> anne: AT's supports it, automatically, because of how we expose things
# [17:06] <aaronlev> lets say you make a checkbox with an <img> child
# [17:06] <aaronlev> for the checkbox
# [17:06] <aaronlev> what matters is the role="checkbox" parent
# [17:06] <aaronlev> the child is only for building the appearance
# [17:07] <aaronlev> in terms of using it for table
# [17:07] <aaronlev> the reality of the web today is people use <table> for layout
# [17:07] <zcorpan_> whether <img> is focusable or not depends on platform conventions
# [17:07] <aaronlev> specificing role="presentation" in firefox makes it so the AT just sees the content and doesn't deal with it as a data table
# [17:08] <aaronlev> zcorpan_: is it focusable in opera?
# [17:08] <zcorpan_> aaronlev: no
# [17:08] <aaronlev> is it focusable on small devices or something?
# [17:08] <zcorpan_> could be
# [17:08] <aaronlev> zcorpan_: if it is focusable it needs to be able to fire focus events, otherwise it breaks fundamental a11y
# [17:08] <anne> on some, yes, iirc
# [17:09] <aaronlev> which in that case it needs an accessible object
# [17:09] <anne> most elements are actually focusable on some way so you can navigate through them by keyboard in Opera
# [17:09] <aaronlev> firefox says if something is focusable it is not really for presentation, it's something you can interact with
# [17:09] <anne> although not strictly focusable in the DOM/CSS sense of the word
# [17:10] <aaronlev> anne: i never understood that well
# [17:11] <anne> it's called "pre-focus"/"hilite" for lack of a better term iirc
# [17:11] <aaronlev> is a dom event fired?
# [17:11] <zcorpan_> i guess it's equivalent to caret browsing in firefox
# [17:11] <anne> could be, dunno
# [17:11] <anne> I wouldn't say equivalent
# [17:12] <aaronlev> anne: if there is no event fired, how would a fire vox type extension (opere vox?) read the current item
# [17:12] <aaronlev> anyway, you would need to fire focus to the AT for those
# [17:12] <aaronlev> so it needs an msaa/atk/ua object
# [17:13] <aaronlev> zcorpan_: if it is like caret browsing, then you could just fire an event that the caret moved to it
# [17:13] <aaronlev> in which case you can do that on a non-presentational ancestor of the text, which contains that text
# [17:14] <zcorpan_> anyway, "presentation" seems to have to integrate with the rest of the processing that i haven't defined yet
# [17:14] <anne> aaronlev, doesn't that simply depend on how you integrate with the AT?
# [17:14] <anne> aaronlev, seems a bit weird to me to do everything through the DOM
# [17:14] <aaronlev> anne: i meant what opera might do, based on what i know, not what the spec should say
# [17:15] <aaronlev> anne: fine
# [17:15] <anne> overloading the DOM with AT specific semantics seems wrong to me
# [17:15] <aaronlev> zcorpan_: there's a special rule for dealing with presentatiuon on <table>, in that it automatically means the <td>'s etc. that are descendnats are also presentation-only
# [17:15] <aaronlev> anne: k
# [17:16] <zcorpan_> aaronlev: interesting
# [17:16] <anne> also, why isn't "presentation" implied for childnodes of a widget?
# [17:16] <anne> maybe based on the type of the widget
# [17:16] <anne> anyway, it doesn't seem that "presentation" warrants support for multiple role values
# [17:17] <anne> as authors simply shouldn't specify both presentation and checkbox (for instance) on the same element
# [17:17] <zcorpan_> anne: agree
# [17:18] <zcorpan_> if authors say role="checkbox presentation" then it's ok to say that it represents a checkbox, imho
# [17:19] <zcorpan_> checking for presentation first seems to just complicate processing
# [17:20] <zcorpan_> you might also want to actually fall back to "presentation" for some custom new role
# [17:20] <aaronlev> zcorpan_: so role="presentation checkbox" would be different from "checkbox presentation"
# [17:20] <zcorpan_> aaronlev: yes
# [17:20] <aaronlev> ok
# [17:21] <aaronlev> that makes the spec simpler but processing more compkciated
# [17:21] <zcorpan_> aaronlev: oh
# [17:21] <zcorpan_> how so?
# [17:21] <anne> aaronlev, note that the new specification also addresses your fallback concern which is currently addressed by loading RDF...
# [17:23] <aaronlev> zcorpan_: it's very fast to do a substring check for " presentation " or " wairole:presentation "
# [17:23] <aaronlev> cheaper than calling the method i'll be writing to ask for the first wai role
# [17:23] <aaronlev> but i guess, you're right, it's not really more complicated
# [17:24] <anne> substring check would go wrong too
# [17:25] <zcorpan_> why does "presentation" need better perf than e.g. "checkbox"? :)
# [17:25] <anne> your substring check for instance doesn't cover \n \f \t characters
# [17:25] * Parts: billmason (billmason@69.30.57.156)
# [17:25] <anne> it also doesn't cover presentation being the last or first value
# [17:25] <anne> etc.
# [17:25] <anne> plus what zcorpan_ said
# [17:25] * Quits: gavin_ (gavin@99.226.75.20) (Ping timeout)
# [17:25] <aaronlev> anne: i was writing in pseudo code, i figure you'd handle the deatils
# [17:26] <aaronlev> zcorpan_: at the moment i was able to keep the decision of whether to create an accessible separate from determining the computed wai role
# [17:26] <aaronlev> go ahead and make the spec how you want, i'll deal with it
# [17:27] <anne> aaronlev, ok, fair enough, but it seems that if you need code to obtain tokens it isn't that much worse than doing both that and substring matching :)
# [17:30] <zcorpan_> aaronlev: what happens when an element has role=presentation but is focusable?
# [17:30] * Joins: gavin_ (gavin@99.226.75.20)
# [17:35] <aaronlev> zcorpan_: the fact that it's focusable overrides the presentation role
# [17:35] <aaronlev> and it is no longer presentational
# [17:37] <zcorpan_> aaronlev: but is the xml-roles object attribute used in that case?
# [17:37] <aaronlev> zcorpan_: yes
# [17:37] <zcorpan_> ok
# [17:41] <zcorpan_> updated the spec
# [17:42] <aaronlev> i kind of like the suggestion for role="aol-buddylist listbox"
# [17:42] <anne> good :)
# [17:43] <zcorpan_> :)
# [17:44] <aaronlev> doesn't mean everyone will, but we have a good chance
# [17:45] <anne> i don't think "everyone" will ever agree on something
# [17:46] <anne> although it would be nice
# [17:47] <aaronlev> i mean we have a good chance for consensus
# [17:47] <aaronlev> you guys really make me use exact language :)
# [17:48] <aaronlev> "However, unlike the xml prefix, the wairole prefix has to be declared before it is used according to this specification"
# [17:48] <aaronlev> why did we add that?
# [17:48] <zcorpan_> because we want to ban the wairole: prefix in text/html :)
# [17:48] <aaronlev> k
# [17:48] <aaronlev> although the processing rules allow for it
# [17:48] <zcorpan_> yes
# [17:49] <aaronlev> Is it work saying something about that?
# [17:49] <aaronlev> It's easy to miss
# [17:49] <anne> the processing rules don't allow for the other thing that _is_ allowed
# [17:49] <anne> i think the authoring requirements should be made simpler by removing all the namespace cruft
# [17:50] <aaronlev> anne: the processing rules don't allow for what other thing?
# [17:50] <anne> foobar:role
# [17:50] <anne> foobar:value
# [17:50] <hsivonen> aaronlev: what was the passing mention about RDF and localized strings about?
# [17:50] <hsivonen> (I can't remember whether it was here or on-list)
# [17:51] <zcorpan_> anne: if "foobar:role" is a supported custom role, then it will be used :)
# [17:51] <aaronlev> zcorpan_: right now i have to very carefully read the processing and authoring rules to see the differences between the strictness of one and looseness of the other
# [17:51] <anne> zcorpan_, sure, but it won't be bound to a namespace
# [17:51] <aaronlev> it would be nice if that was called out so everyone was clear on it
# [17:51] <anne> I would suggest to just read the processing requirements
# [17:52] <aaronlev> hsivonen: i'm not saying it makes sense, i'm just trying to report my understanding of how PF's plan to use RDF would have to work
# [17:52] <aaronlev> we haven't spent enough time in PFWG talking about how RDF would be used for custom roles
# [17:52] <aaronlev> because we're trying to get1.0 out, and we've pushed that off
# [17:52] <aaronlev> plus i've been telling them rdf sucks for this.
# [17:52] <aaronlev> but that said ...
# [17:53] <anne> my suggestion would be to merge the role values into the Simon proposal and publish that instead
# [17:53] <anne> and dump the XHTML role module
# [17:53] <aaronlev> i think it's a resonable idea for authors to be able to define new roles, with new semantic properties with types of boolean, string or idref, etc.
# [17:53] <aaronlev> and to doefine what gets spoken, if anything, when those properties change
# [17:53] <aaronlev> not necessarily spoken
# [17:54] <aaronlev> but presented
# [17:54] <zcorpan_> aaronlev: what do you want the spec to say? and where? (re differences in authoring/ua reqs)
# [17:54] <aaronlev> so for example, if aol-away="false" becomes "True"
# [17:54] <hsivonen> aaronlev: mmkay. I'd expect an app (screen reader or otherwise) be responsible for knowing its own UI strings and content to be responsible for supplying its strings without indirection
# [17:54] <aaronlev> hsivonen: it should be for all the base well-known markup
# [17:54] <aaronlev> but it's impossible for ATs to keep up with the web
# [17:55] <aaronlev> or with software in general
# [17:55] <aaronlev> that's always been a big problem
# [17:55] <aaronlev> people want to define new stuff and how the AT should deal with it
# [17:55] <aaronlev> zcorpan_: how about a summary table
# [17:55] <hsivonen> so they want effectively to program the AT from within content?
# [17:56] <aaronlev> zcorpan_: with what's allowed or not allowed for authors or processing
# [17:56] <aaronlev> hsivonen: not program the AT, but supply it with what it needs to know
# [17:56] <aaronlev> it's not script
# [17:57] <zcorpan_> aaronlev: i'm not sure why any differences need to be called out explicitly. e.g. html5 has lots of differences between ua and authoring reqs; listing them all would likely double the size of the spec
# [17:58] <hsivonen> in any case, so far the localization approach of the Web has been that the server supplies a representation with burned-in strings in one language
# [17:58] <zcorpan_> aaronlev: if you're an author, you don't care about ua reqs
# [17:58] <aaronlev> zcorpan_: ok
# [17:58] <zcorpan_> aaronlev: and if you're an implementor, you don't care about authoring reqs
# [17:58] <hsivonen> not that the UA assembles stuff from string bundles
# [17:58] <aaronlev> hsivonen: i don't think pfwg thought about localization, but from what they're saying, it would be needed
# [17:59] <aaronlev> i can go back to them and ask, but we definitely pushed this issue off in the interests of getting the basics finished
# [17:59] * Joins: Sander (svl@86.87.68.167)
# [17:59] <anne> why would you localize role values and not the <body> element?
# [17:59] <aaronlev> anne: <body> is well-known
# [17:59] <aaronlev> if we can write this spec so it allows for role customization later, but not specify completely yet, that would be helpful
# [18:00] <anne> there's lots of things here that don't make sense to me
# [18:00] <hsivonen> aaronlev: it would be weird to start abstracting localization from the a11y stuff considering that for HTML in general, we want to push it out of UA scope to the server side (per current Design Principles draft)
# [18:01] <hsivonen> aaronlev: I'd expect client "support" for aol-buddy list to include the chrome strings required for speaking about buddy lists
# [18:01] <aaronlev> hsivonen: the idea is to break accessibility from the chains of the AT bottleneck
# [18:01] * Joins: polin8 (polin8@75.71.72.175)
# [18:01] <aaronlev> tiny companies that cannot hope to keep up with current authoring
# [18:02] <aaronlev> that's the problem we're trying to solve, i don't know how it will be solved but i believe it is technically possible to solve it
# [18:02] <aaronlev> and if we could push it off until there is time to discuss it more deeply that'd be great
# [18:03] <hsivonen> aaronlev: if I make a Finnish submit button in HTML, I burn the UI string in the content instead of sending a string bundle to the UA so it could assemble the pieces
# [18:03] * Quits: polin8 (polin8@75.71.72.175) (Quit: :wq)
# [18:03] <hsivonen> why wouldn't the screen readable strings be similarly part of the content in the language of the content?
# [18:03] <aaronlev> ah
# [18:04] <aaronlev> right, the problem with that was, how to associate the localized property name with the semantic one
# [18:04] <hsivonen> doing string bundle-based UI assembly on the client is some serious scope creep
# [18:04] <aaronlev> hsivonen: no one wnts to pass the entire string budle over to the at
# [18:05] <aaronlev> i'm sure we can come up with something better
# [18:06] <hsivonen> aaronlev: but if the custom roles are only opaque identifiers to the AT, why bother with that abstraction at all?
# [18:06] <aaronlev> because you may also want to write scripts that utilize the semantic value
# [18:06] <hsivonen> aaronlev: shouldn't "semantic" identifiers be removed then and the user experience be driven directly with custom UI strings?
# [18:06] <hsivonen> hmm.
# [18:06] <aaronlev> there is no sharp line between what the AT's will handle now and what they will evolve to handle
# [18:06] <aaronlev> some ATs will evolve to handle busy=false|true and do something special for that
# [18:07] <aaronlev> otherws will use the fallback
# [18:07] <aaronlev> <div role="aol-buddy option">My friend</div>
# [18:07] <hsivonen> ok
# [18:07] <aaronlev> how should is specify that he is busy or not, and how that changes
# [18:07] <hsivonen> but to me, aol-buddy makes no sense without at least one voice browsing configuration doing something useful with it natively
# [18:07] <aaronlev> in a way that the author can define the fallback localization for the AT
# [18:08] <aaronlev> it is alreayd usefuly to say "My friend" "busy off" or "busy on"
# [18:09] <anne> It's still not clear to me how this is going to work. Content producers have shown in the last decade or something that this type of afterthought accessibility doesn't work for them (alt=, headers=, axis=, longdesc=) and not only are we adding a bunch of stuff on top of that (role=, aria-*=), no you're proposing to make it even more complicated
# [18:09] <anne> It seems to me that this problem is much better solved at the side where there are only 1-10 players
# [18:10] <aaronlev> well there is open source
# [18:10] <aaronlev> how do you define how many players there are in that case
# [18:11] <aaronlev> anne: maybe there is a simpler solution
# [18:11] <aaronlev> but i don't think giving up on the problem i explained is the only reasonable answer
# [18:11] <aaronlev> also, headers|axis suck
# [18:11] <aaronlev> longdesc is not that useful
# [18:11] <aaronlev> and alt is used all the time
# [18:12] <hsivonen> aaronlev: are there known implementations of axis?
# [18:12] <aaronlev> hsivonen: not that i've found
# [18:12] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
# [18:13] <hsivonen> aaronlev: for the purpose of counting players, I'd count version control repos
# [18:13] <hsivonen> aaronlev: so the Mozilla cvs repo counts as one "player" for anne's purpose
# [18:13] <aaronlev> there are a lot more than one player involved in mozilla
# [18:14] <zcorpan_> mozilla has multiple version control repos? :)
# [18:14] <hsivonen> aaronlev: there are still fewer client code bases to which features need to be introduced than there are content-side code bases
# [18:15] <aaronlev> that's for sure
# [18:15] <aaronlev> i thouight the point is, this is possible scope creep, and we also don't have a clean way to do it yet so no one will use it
# [18:15] <aaronlev> even if we implement it
# [18:16] <aaronlev> so we should wait until we get the bases covered, but keep ourselves open to it for later
# [18:17] <hsivonen> anyway, for relatively special-purpose things like buddy availability states, I'd try to get rid of one layer of abstraction and use UI strings in the language of the page without the UA knowing the semantics--just speaking content-provided strings
# [18:18] <aaronlev> that was one proposal, but people want semantics
# [18:18] <aaronlev> it's certainly a lot simpler
# [18:19] <aaronlev> we could offer that for now and the promised land of something better when we get to xbl
# [18:19] <hsivonen> aaronlev: semantics are pretty useless unless there are clients that use the "semantic" strings as something smarted than opaque hash table keys
# [18:19] <aaronlev> who says there won't be
# [18:20] <aaronlev> ATs will soon be offering the capability of end user scrpting for web apps, just as they do for desktop apps now
# [18:20] <hsivonen> aaronlev: authoring for future clients and scripting support for today's clients tends to poison the future
# [18:21] <aaronlev> i don't follow, but i'd like to continue the conversation later
# [18:21] <aaronlev> i have to go pick up my daughter
# [18:21] <zcorpan_> aaronlev: cya
# [18:21] <aaronlev> later
# [18:23] * Joins: hyatt (hyatt@209.173.92.142)
# [18:25] <hsivonen> aaronlev: bye
# [18:25] <hsivonen> anyway, for logs: what I meant is this
# [18:26] <hsivonen> consider WF2
# [18:26] <hsivonen> there's Opera 9 and there's scripts for IE
# [18:26] <hsivonen> Opera 9 is a shipping browser that can be used to test that the scripts for IE are future-proof with a native implementation
# [18:27] <hsivonen> that is, that the scripts properly go out of the way when the native impl. is there
# [18:29] <hsivonen> on the other hand, if there's no native implementation to test with, well-intentioned people will do things that prevent native implementation from ever being introduced because the emulation scripts would conflict with the native impls
# [18:29] <hsivonen> like when in 2000 O'Reilly was serving XHTML on the Web and Mozilla was unable to introduce XML parsing for text/html XHTML content, because there was already a broken legacy out there
# [18:30] <hsivonen> (O'Reilly's "XHTML" was ill-formed)
# [18:35] * Quits: hyatt (hyatt@209.173.92.142) (Quit: hyatt)
# [18:54] * Quits: Sander (svl@86.87.68.167) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [19:12] * Joins: mjs (mjs@17.255.98.235)
# [19:18] <anne> krijnh, any chance you can fix the regular expression used for autolinking URIs in the archives?
# [19:18] <anne> krijnh, you need a pattern for <http://, specifically, see http://krijnhoetmer.nl/irc-logs/whatwg/20070930
# [19:20] <anne> hsivonen, http://validator.nu/?doc=http%3A%2F%2Fannevankesteren.nl%2F2007%2F09%2Ftmb-overview
# [19:20] <anne> hsivonen, scope= is allowed at those points :)
# [19:20] <hsivonen> anne: wasn't when I last reviewed the schema ;-)
# [19:21] * Joins: aroben (aroben@17.203.12.72)
# [19:21] <hsivonen> anne: anyway, I'll fix that soonish
# [19:21] * hsivonen is working on multipart/form-data support
# [19:22] <anne> no problem; I validated my frontpage as HTML4 and then using HTML5 override mode and it suddenly stopped validating
# [19:23] <anne> (just to play with validator.nu, I normally don't validate my webpages as I'm pretty sure they're always valid or are invalid because I'm doing so on purpose (testing WF2 features or something))
# [19:24] <zcorpan_> anne: stop being so elitist ;)
# [19:24] <anne> is fact telling elitist now? :p
# [19:24] * anne hides
# [19:28] <krijnh> anne: unhide and fix $content = preg_replace("#((https?|ftp):[^'\">\\s]+)#", '<a href="\1">\1</a>', $content); will ya ;)
# [19:29] <aaronlev> hsivonen: hi
# [19:30] <anne> krijnh, ouch
# [19:30] <aaronlev> hsivonen: i guess i'd like to delay some of this conversation until i find a proposal that i myself even like
# [19:30] <hsivonen> aroben: hi
# [19:30] <krijnh> I wonder where I copied that one from
# [19:30] <hsivonen> doh
# [19:30] <hsivonen> aaronlev: hi
# [19:30] <hsivonen> aaronlev: ok
# [19:30] <aaronlev> hsivonen: because i think something reasonable may exist
# [19:30] <aroben> hi hsivonen
# [19:31] * aroben is a typo
# [19:31] <aaronlev> and i should probably write something up to explain how it would work and why it's not bad
# [19:31] <aaronlev> so people can critique that
# [19:31] <aaronlev> but i agree that the current ideas are too complicated to fly
# [19:32] <hsivonen> aaronlev: did you see my point about speculative future compat without nothing to test against? (in the log earlier)
# [19:32] <aaronlev> i didn't understand it completely, sorry for being dense
# [19:33] <aaronlev> i think for we have enough future compat in there
# [19:33] <anne> krijnh, I suppose you can simply add one before that one that replaces all occurances of <http:// ...> with http:// ...
# [19:33] * Quits: gavin_ (gavin@99.226.75.20) (Ping timeout)
# [19:33] <aaronlev> because we're ignoring everything but wairole
# [19:33] <hsivonen> aaronlev: if people start publishing using a new syntax before there are consumers with native support, it is easy to accidentally build a legacy that prevents native support from ever emerging
# [19:34] <aaronlev> yes
# [19:34] <aaronlev> we have that prolbem today with screen readers
# [19:34] <aaronlev> but not on the web
# [19:34] <aaronlev> JAWS provides a scripting language
# [19:34] <aaronlev> for desktop apps
# [19:35] <aaronlev> and sometimes what happens, is someone develops a JAWS script that works well enough
# [19:35] <aaronlev> and the app is never truly made accessible
# [19:35] <krijnh> anne: no time now, sorry
# [19:35] <aaronlev> but, on the whole it empowers the users, who get to share scripts
# [19:35] <aaronlev> and it's unrealistic for every app to have native jaws support that works well enough
# [19:35] <hsivonen> aaronlev: is it because the script is useful enough or because changing the app would break the script?
# [19:36] <aaronlev> i would have to say usuall because the script is useful enough, but it's possible that changeing the app would break the script
# [19:36] <anne> krijnh, you can say that again :p
# [19:36] <aaronlev> however, apps that change and get a new version break the scripts all the time
# [19:36] <aaronlev> athat's just reality
# [19:37] <aaronlev> thes script-breaking changes aren't usually because someone made it more accessible
# [19:37] <aaronlev> but because the app just changed
# [19:38] <aaronlev> i believe that on the whole, the end user wins when they're empowered to fix things themselves, even with the risks you mention
# [19:38] * Joins: gavin_ (gavin@99.226.75.20)
# [19:38] <krijnh> anne: I can :)
# [19:41] <hsivonen> aaronlev: ok. the Web parallel is more like greasemonkey
# [19:42] <hsivonen> aaronlev: not the someone deployed ill-formed "XHTML" content as text/html and thus prevented browsers from ever parsing text/html as XML
# [19:42] <aaronlev> hsivonen: right, although the at script shouldn't modify the dom imo
# [19:42] <hsivonen> s/the/that/
# [19:46] <aaronlev> right, like greasemonkey but readonly
# [19:46] <aaronlev> doesn't modify the dom
# [19:47] <aaronlev> although possibly pushes input
# [19:47] <aaronlev> or sets focus
# [19:47] * Joins: hyatt (hyatt@209.173.92.142)
# [19:49] * Quits: hyatt (hyatt@209.173.92.142) (Quit: hyatt)
# [19:49] * Joins: hyatt (hyatt@209.173.92.142)
# [20:05] * Quits: xover (xover@193.157.66.5) (Ping timeout)
# [20:05] * Joins: xover (xover@193.157.66.5)
# [20:05] * Quits: laplink (link@193.157.66.199) (Ping timeout)
# [20:05] * Joins: laplink (link@193.157.66.199)
# [20:19] * Joins: icaaq (icaaaq@85.228.55.82)
# [20:28] * Parts: timbl (timbl@128.30.7.41)
# [20:32] * Joins: Sander (svl@86.87.68.167)
# [20:52] * Parts: hendry_ (hendry@89.16.172.32)
# [20:54] * Quits: zcorpan_ (zcorpan@88.131.66.80) (Ping timeout)
# [20:55] * anne replies to rich
# [21:03] * Quits: Steve_f (chatzilla@82.44.69.8) (Connection reset by peer)
# [21:04] * Joins: Steve_f (chatzilla@82.44.69.8)
# [21:09] * Quits: ROBOd (robod@89.122.216.38) (Quit: http://www.robodesign.ro )
# [21:21] * Joins: drry_ (drry@210.191.161.204)
# [21:22] * Quits: drry (drry@210.191.160.64) (Ping timeout)
# [21:28] * Quits: drry_ (drry@210.191.161.204) (Quit: drry_)
# [21:30] * Quits: Steve_f (chatzilla@82.44.69.8) (Quit: ChatZilla 0.9.78.1 [Firefox 2.0.0.7/2007091417])
# [21:31] * Joins: drry (drry@210.191.161.204)
# [21:35] <anne> lol
# [21:35] <anne> http://www.w3.org/mid/47014AF2.3040205@aptest.com
# [21:41] * Quits: gavin_ (gavin@99.226.75.20) (Ping timeout)
# [21:46] * Joins: gavin_ (gavin@99.226.75.20)
# [21:47] * Quits: aroben (aroben@17.203.12.72) (Ping timeout)
# [21:50] * Joins: aroben (aroben@17.203.12.72)
# [21:52] * Quits: mjs (mjs@17.255.98.235) (Quit: mjs)
# [21:53] * Joins: mjs (mjs@17.255.98.235)
# [22:02] * Quits: mjs (mjs@17.255.98.235) (Quit: mjs)
# [22:11] * Joins: mjs (mjs@17.255.98.235)
# [22:11] <aaronlev> anne: no doubt, someone please make it stop :)
# [22:13] <anne> "opaque string battles"
# [22:14] <anne> oh, and politics
# [22:14] <anne> W3C seems mostly about politics these days, not about doing any actual technical stuff
# [22:14] <anne> that's for your free time
# [22:15] <aaronlev> yep
# [22:21] <aaronlev> anne: that doc lists both xhtml2 wg and html wg
# [22:22] <anne> yeah, and PFWG
# [22:22] <anne> and the RDFa guys, hurray
# [22:29] * Quits: schepers (schepers@128.30.52.30) (Ping timeout)
# [22:47] * Joins: dbaron (dbaron@63.245.220.241)
# [22:58] * Quits: mjs (mjs@17.255.98.235) (Ping timeout)
# [23:06] * Quits: gavin (gavin@63.245.208.169) (Ping timeout)
# [23:09] * Joins: gavin (gavin@63.245.208.169)
# [23:13] * Quits: aroben (aroben@17.203.12.72) (Connection reset by peer)
# [23:16] * Quits: gavin (gavin@63.245.208.169) (Ping timeout)
# [23:19] * Joins: aroben (aroben@17.203.12.236)
# [23:20] * Joins: gavin (gavin@63.245.208.169)
# [23:20] * Quits: aroben (aroben@17.203.12.236) (Connection reset by peer)
# [23:20] * Joins: aroben (aroben@17.203.12.236)
# [23:24] * Quits: aaronlev (chatzilla@66.31.86.217) (Ping timeout)
# [23:24] * Joins: karl (karlcow@128.30.52.30)
# [23:25] * Joins: aaronlev (chatzilla@66.31.86.217)
# [23:25] * Joins: mjs (mjs@17.255.98.235)
# [23:27] * Joins: aaron (chatzilla@66.31.86.217)
# [23:28] * Quits: mjs (mjs@17.255.98.235) (Quit: mjs)
# [23:29] * Quits: aaronlev (chatzilla@66.31.86.217) (Ping timeout)
# [23:29] * aaron is now known as aaronlev
# [23:35] * Joins: aroben_ (aroben@17.203.12.72)
# [23:37] * Quits: aroben (aroben@17.203.12.236) (Quit: Leaving)
# [23:37] * aroben_ is now known as aroben
# [23:46] * Quits: tH (Rob@87.102.67.202) (Quit: ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508])
# [23:48] * Quits: gavin_ (gavin@99.226.75.20) (Ping timeout)
# [23:50] * Quits: anne (annevk@81.68.67.12) (Ping timeout)
# [23:50] * Joins: mjs (mjs@17.255.98.235)
# [23:52] * Quits: Sander (svl@86.87.68.167) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [23:53] * Joins: gavin_ (gavin@99.226.75.20)
# [23:55] * Joins: kingryan (rking3@208.66.64.47)
# Session Close: Tue Oct 02 00:00:00 2007

The end :)