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

Options:

  1. # Session Start: Mon Oct 01 00:00:00 2007
  2. # Session Ident: #html-wg
  3. # [00:01] * Joins: schepers (schepers@128.30.52.30)
  4. # [00:16] * Quits: timbl (timbl@70.108.26.144) (Quit: timbl)
  5. # [00:20] * Quits: dbaron (dbaron@71.204.145.103) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  6. # [01:02] * Quits: heycam (cam@203.214.33.166) (Ping timeout)
  7. # [01:19] * Quits: gavin_ (gavin@99.226.75.20) (Ping timeout)
  8. # [01:23] * Joins: gavin_ (gavin@99.226.75.20)
  9. # [01:25] * Joins: heycam (cam@130.194.72.84)
  10. # [01:58] * Joins: karl (karlcow@128.30.52.30)
  11. # [02:07] * Joins: Lionhear1 (robin@66.57.69.65)
  12. # [02:07] * Quits: Lionheart (robin@66.57.69.65) (Ping timeout)
  13. # [03:51] * Joins: olivier (ot@128.30.52.30)
  14. # [04:23] * Joins: Lachy (chatzilla@124.171.26.6)
  15. # [04:25] * Parts: Shunsuke (Shunsuke@123.176.107.50)
  16. # [04:26] * Quits: gavin_ (gavin@99.226.75.20) (Ping timeout)
  17. # [04:31] * Joins: gavin_ (gavin@99.226.75.20)
  18. # [05:33] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
  19. # [05:33] * Quits: Lachy (chatzilla@124.171.26.6) (Quit: ChatZilla 0.9.78.1 [Firefox 2.0.0.6/2007072518])
  20. # [06:16] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  21. # [06:22] * Joins: heycam (cam@203.214.33.166)
  22. # [06:34] * Quits: gavin_ (gavin@99.226.75.20) (Ping timeout)
  23. # [06:39] * Joins: gavin_ (gavin@99.226.75.20)
  24. # [06:58] * Joins: Shunsuke (Shunsuke@123.176.107.50)
  25. # [07:30] * Quits: emeriste (emeriste@69.22.229.84) (Ping timeout)
  26. # [07:32] * Joins: emeriste (emeriste@69.22.229.84)
  27. # [07:45] * Joins: hyatt (hyatt@209.173.92.142)
  28. # [07:46] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
  29. # [07:55] * Quits: heycam (cam@203.214.33.166) (Ping timeout)
  30. # [08:13] * Joins: heycam (cam@203.214.114.92)
  31. # [08:42] * Quits: gavin_ (gavin@99.226.75.20) (Ping timeout)
  32. # [08:42] * Quits: aroben (aroben@67.160.250.192) (Quit: Leaving)
  33. # [08:44] * Quits: hyatt (hyatt@209.173.92.142) (Quit: hyatt)
  34. # [08:47] * Joins: gavin_ (gavin@99.226.75.20)
  35. # [08:54] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  36. # [09:15] * Joins: aaronlev (chatzilla@209.6.168.245)
  37. # [09:25] * Quits: olivier (ot@128.30.52.30) (Quit: Leaving)
  38. # [09:27] * Quits: heycam (cam@203.214.114.92) (Ping timeout)
  39. # [09:31] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
  40. # [09:40] * Joins: Steve_f (chatzilla@82.44.69.8)
  41. # [10:09] * Joins: heycam (cam@203.214.114.92)
  42. # [10:27] * Quits: aaronlev (chatzilla@209.6.168.245) (Ping timeout)
  43. # [10:27] * Joins: ROBOd (robod@89.122.216.38)
  44. # [10:34] * Quits: heycam (cam@203.214.114.92) (Quit: bye)
  45. # [10:39] * Joins: zcorpan_ (zcorpan@88.131.66.80)
  46. # [10:50] * Quits: gavin_ (gavin@99.226.75.20) (Ping timeout)
  47. # [10:55] * Joins: gavin_ (gavin@99.226.75.20)
  48. # [11:53] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
  49. # [12:57] * Quits: gavin_ (gavin@99.226.75.20) (Ping timeout)
  50. # [13:02] * Joins: gavin_ (gavin@99.226.75.20)
  51. # [13:02] * Quits: ROBOd (robod@89.122.216.38) (Quit: http://www.robodesign.ro )
  52. # [13:47] <anne> maybe "afterthought" should be "after-the-fact"
  53. # [13:58] <zcorpan_> hmm, i'm not sure i get the aol-buddylist fallback example
  54. # [13:59] <zcorpan_> would the aol-buddylist have an accessibility API mapping of its own?
  55. # [14:00] <hsivonen> zcorpan_: either yes, or you have just uncovered a chunk of failed communication on the ARIA topic
  56. # [14:01] <hsivonen> zcorpan_: if the answer is "no", I have severely misunderstood something
  57. # [14:02] * zcorpan_ doesn't know the answer, but has specced assuming "no"
  58. # [14:03] <anne> zcorpan_, the idea is that you can specify a single widget type with fallbacks, like font-family in CSS
  59. # [14:03] <anne> so the widget type would be "aol-buddlylist" but it's "list" if that's not supported
  60. # [14:05] <zcorpan_> so "yes"
  61. # [14:05] <anne> yeah, unless it's bogus :)
  62. # [14:06] <zcorpan_> define bogus, please :)
  63. # [14:06] <anne> hmm
  64. # [14:06] <anne> bogus being a value that's incorrect and doesn't map to anything at all anywhere
  65. # [14:07] <zcorpan_> i.e. "not supported"?
  66. # [14:07] <anne> yeah, if you consider <html:bogus> to be like that
  67. # [14:08] <zcorpan_> ok
  68. # [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
  69. # [14:09] <zcorpan_> and such roles shouldn't suppress the aria mapping
  70. # [14:09] <zcorpan_> even if "supported"
  71. # [14:09] <anne> why don't we want to disallow those?
  72. # [14:09] <anne> another point of my proposal was to fork the XHTML role module
  73. # [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
  74. # [14:11] <anne> make role= work for a single thing, not hundreds and be done with it
  75. # [14:11] <hsivonen> fwiw, I had certain doubts when UI strings in RDF were mentioned
  76. # [14:11] <hsivonen> doubts about what "support" means, that is
  77. # [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
  78. # [14:12] <zcorpan_> another thing: are these equivalent?: role="aol-buddylist" role="wairole:aol-buddylist"
  79. # [14:13] <anne> i'd say yes
  80. # [14:13] <anne> i'd also make wairole: non-conforming if it appears anywhere in role=
  81. # [14:14] <zcorpan_> we can do that later; dojo needs to do something that works in firefox 2
  82. # [14:15] <anne> dojo doesn't conform to anything afaict
  83. # [14:15] <zcorpan_> fair enough
  84. # [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
  85. # [14:17] <anne> good point, that does seem better
  86. # [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!)
  87. # [14:38] * Joins: ROBOd (robod@89.122.216.38)
  88. # [15:01] <zcorpan_> updated the spec; does it seem ok?
  89. # [15:01] <anne> I think you should remove the bit about http://www.w3.org/2002/06/xhtml2/
  90. # [15:02] <anne> wasn't it also the plan to have html:role not work on html:x
  91. # [15:02] <zcorpan_> that was the plan; does the spec say otherwise?
  92. # [15:03] <anne> the authoring requirements suggest otherwise
  93. # [15:04] <anne> it's also important that the custom role is supported by the AT, otherwise it's useless
  94. # [15:04] <anne> "Note: In this version of this specification, only the first supported role is used." can be removed
  95. # [15:04] <anne> and "Note: No namespace lookup of the attribute value is performed in this version of this specification." prolly too
  96. # [15:04] <anne> that's both by design
  97. # [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
  98. # [15:06] * Joins: myakura (myakura@124.84.120.239)
  99. # [15:17] * Quits: gavin_ (gavin@99.226.75.20) (Ping timeout)
  100. # [15:22] * Joins: gavin_ (gavin@99.226.75.20)
  101. # [15:22] <hsivonen> anne: I restored the human-readable validation result to (X)HTML and text outputs
  102. # [15:23] <hsivonen> anne: thanks for reminding me
  103. # [15:23] * Joins: timbl (timbl@146.115.66.146)
  104. # [15:23] <anne> hah, I said what, when? :)
  105. # [15:24] <anne> oh, http://validator.nu/?doc=http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml%2F returns "validates" again
  106. # [15:24] <hsivonen> anne: http://krijnhoetmer.nl/irc-logs/html-wg/20070929#l-8
  107. # [15:25] * Quits: Lionhear1 (robin@66.57.69.65) (Quit: Leaving.)
  108. # [15:29] <hsivonen> hrm. putting the file control first would totally break streamability of multipart/form-data
  109. # [15:29] <hsivonen> but putting it last would be bad UI :-(
  110. # [15:31] * Quits: timbl (timbl@146.115.66.146) (Quit: timbl)
  111. # [15:31] <anne> you want XBL
  112. # [15:33] <hsivonen> if I move the file control on onsubmit, will the UA clear it for security reasons or something?
  113. # [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?
  114. # [15:35] <anne> oh, I read the first paragraph incorrectly, sorry
  115. # [15:36] <zcorpan_> anne: could you send the suggestion about the .../xhtml2/ namespace to the list(s), please?
  116. # [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?
  117. # [15:37] * Joins: karl (karlcow@128.30.52.30)
  118. # [15:37] <anne> hsivonen, maybe you should reorder the controls onsubmit
  119. # [15:38] <hsivonen> anne: ok
  120. # [15:53] * Joins: aaronlev (chatzilla@66.31.86.217)
  121. # [15:53] <anne> zcorpan_, I suppose, at some point
  122. # [15:54] <anne> zcorpan_, prolly around the time I'll object against the authoring requirements mentioning namespaces and such
  123. # [15:56] <anne> zcorpan_, more about the algorithm, say "let the result of splitting the string on spaces be tokens"
  124. # [15:56] <anne> zcorpan_, for each <var>token</var> in <var>tokens</var>
  125. # [15:56] <anne> (is that operation ordered?)
  126. # [15:58] <zcorpan_> anne: the algorithm referenced does that
  127. # [15:58] <anne> it returns tokens to what?
  128. # [15:58] <anne> hmm
  129. # [15:59] <zcorpan_> aha
  130. # [16:00] <anne> also note my earlier remark about it being unclear what the empty string role identifier is
  131. # [16:00] <anne> or does
  132. # [16:01] * Joins: tH (Rob@87.102.67.202)
  133. # [16:04] <zcorpan_> anne: fixed the algorithm. added a note about the empty role identifier
  134. # [16:06] <anne> hmm
  135. # [16:07] <anne> i would say "unless the role identifier is presentation or the empty string"
  136. # [16:08] <anne> that also prevents people from defining the empty string and space characters as valid role values in practice
  137. # [16:08] <anne> (well, space characters as already prevented)
  138. # [16:09] <zcorpan_> UAs should still pass along the entire value when they don't recognize any tokens
  139. # [16:10] <zcorpan_> (using the "xml-roles" object attribute in some APIs)
  140. # [16:12] <anne> yeah...
  141. # [16:16] * Joins: timbl (timbl@128.30.7.41)
  142. # [16:21] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
  143. # [16:22] * Quits: myakura (myakura@124.84.120.239) (Quit: Leaving...)
  144. # [16:37] <anne> zcorpan_, I believe ref, registrationmark and template will become superglobal attributes too
  145. # [16:48] <zcorpan_> anne: ok
  146. # [16:49] * Joins: billmason (billmason@69.30.57.156)
  147. # [17:01] <zcorpan_> aaronlev: why does "presentation" need to be special cased?
  148. # [17:01] <aaronlev> it's in the part of the code that builds the accessible tree
  149. # [17:01] <anne> what does "presentation" do?
  150. # [17:02] <aaronlev> UAs must expose the entire object to the AT using accessibility API specific methods, unless the object is strictly for presentation.
  151. # [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.
  152. # [17:02] <zcorpan_> that doesn't quite fit in the current draft, since there will only be one role identifier
  153. # [17:03] <anne> <div role="wairole:checkbox wairole:presentation"> would do what in Firefox currently?
  154. # [17:03] <aaronlev> anne: right now our code to deal with multiple roles is broken
  155. # [17:03] <aaronlev> but presentation is special, it means this thing has no semantic value
  156. # [17:03] <anne> how do ATs implement it?
  157. # [17:04] <aaronlev> it''s just easier to ignore it in the multiple role case, or make it override everything else
  158. # [17:04] <anne> (i don't think multiple roles should be implemented, see proposal on HTML list)
  159. # [17:04] <aaronlev> anne: they don't have to implement it, because we don't expose that object to them at all
  160. # [17:04] <anne> <table role=presentation> helps how?
  161. # [17:04] <anne> I'm not sure this role makes sense
  162. # [17:04] <aaronlev> anne: you put that on a layout able
  163. # [17:04] <aaronlev> on a layout table
  164. # [17:05] <aaronlev> so the AT just sees the table cell content
  165. # [17:05] <anne> but ATs don't support it?
  166. # [17:05] <anne> it seems to encourage presentational markup
  167. # [17:05] <anne> bah
  168. # [17:05] <zcorpan_> aaronlev: does "presentation" override implicit roles?
  169. # [17:06] <aaronlev> anne: AT's supports it, automatically, because of how we expose things
  170. # [17:06] <aaronlev> lets say you make a checkbox with an <img> child
  171. # [17:06] <aaronlev> for the checkbox
  172. # [17:06] <aaronlev> what matters is the role="checkbox" parent
  173. # [17:06] <aaronlev> the child is only for building the appearance
  174. # [17:07] <aaronlev> in terms of using it for table
  175. # [17:07] <aaronlev> the reality of the web today is people use <table> for layout
  176. # [17:07] <zcorpan_> whether <img> is focusable or not depends on platform conventions
  177. # [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
  178. # [17:08] <aaronlev> zcorpan_: is it focusable in opera?
  179. # [17:08] <zcorpan_> aaronlev: no
  180. # [17:08] <aaronlev> is it focusable on small devices or something?
  181. # [17:08] <zcorpan_> could be
  182. # [17:08] <aaronlev> zcorpan_: if it is focusable it needs to be able to fire focus events, otherwise it breaks fundamental a11y
  183. # [17:08] <anne> on some, yes, iirc
  184. # [17:09] <aaronlev> which in that case it needs an accessible object
  185. # [17:09] <anne> most elements are actually focusable on some way so you can navigate through them by keyboard in Opera
  186. # [17:09] <aaronlev> firefox says if something is focusable it is not really for presentation, it's something you can interact with
  187. # [17:09] <anne> although not strictly focusable in the DOM/CSS sense of the word
  188. # [17:10] <aaronlev> anne: i never understood that well
  189. # [17:11] <anne> it's called "pre-focus"/"hilite" for lack of a better term iirc
  190. # [17:11] <aaronlev> is a dom event fired?
  191. # [17:11] <zcorpan_> i guess it's equivalent to caret browsing in firefox
  192. # [17:11] <anne> could be, dunno
  193. # [17:11] <anne> I wouldn't say equivalent
  194. # [17:12] <aaronlev> anne: if there is no event fired, how would a fire vox type extension (opere vox?) read the current item
  195. # [17:12] <aaronlev> anyway, you would need to fire focus to the AT for those
  196. # [17:12] <aaronlev> so it needs an msaa/atk/ua object
  197. # [17:13] <aaronlev> zcorpan_: if it is like caret browsing, then you could just fire an event that the caret moved to it
  198. # [17:13] <aaronlev> in which case you can do that on a non-presentational ancestor of the text, which contains that text
  199. # [17:14] <zcorpan_> anyway, "presentation" seems to have to integrate with the rest of the processing that i haven't defined yet
  200. # [17:14] <anne> aaronlev, doesn't that simply depend on how you integrate with the AT?
  201. # [17:14] <anne> aaronlev, seems a bit weird to me to do everything through the DOM
  202. # [17:14] <aaronlev> anne: i meant what opera might do, based on what i know, not what the spec should say
  203. # [17:15] <aaronlev> anne: fine
  204. # [17:15] <anne> overloading the DOM with AT specific semantics seems wrong to me
  205. # [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
  206. # [17:15] <aaronlev> anne: k
  207. # [17:16] <zcorpan_> aaronlev: interesting
  208. # [17:16] <anne> also, why isn't "presentation" implied for childnodes of a widget?
  209. # [17:16] <anne> maybe based on the type of the widget
  210. # [17:16] <anne> anyway, it doesn't seem that "presentation" warrants support for multiple role values
  211. # [17:17] <anne> as authors simply shouldn't specify both presentation and checkbox (for instance) on the same element
  212. # [17:17] <zcorpan_> anne: agree
  213. # [17:18] <zcorpan_> if authors say role="checkbox presentation" then it's ok to say that it represents a checkbox, imho
  214. # [17:19] <zcorpan_> checking for presentation first seems to just complicate processing
  215. # [17:20] <zcorpan_> you might also want to actually fall back to "presentation" for some custom new role
  216. # [17:20] <aaronlev> zcorpan_: so role="presentation checkbox" would be different from "checkbox presentation"
  217. # [17:20] <zcorpan_> aaronlev: yes
  218. # [17:20] <aaronlev> ok
  219. # [17:21] <aaronlev> that makes the spec simpler but processing more compkciated
  220. # [17:21] <zcorpan_> aaronlev: oh
  221. # [17:21] <zcorpan_> how so?
  222. # [17:21] <anne> aaronlev, note that the new specification also addresses your fallback concern which is currently addressed by loading RDF...
  223. # [17:23] <aaronlev> zcorpan_: it's very fast to do a substring check for " presentation " or " wairole:presentation "
  224. # [17:23] <aaronlev> cheaper than calling the method i'll be writing to ask for the first wai role
  225. # [17:23] <aaronlev> but i guess, you're right, it's not really more complicated
  226. # [17:24] <anne> substring check would go wrong too
  227. # [17:25] <zcorpan_> why does "presentation" need better perf than e.g. "checkbox"? :)
  228. # [17:25] <anne> your substring check for instance doesn't cover \n \f \t characters
  229. # [17:25] * Parts: billmason (billmason@69.30.57.156)
  230. # [17:25] <anne> it also doesn't cover presentation being the last or first value
  231. # [17:25] <anne> etc.
  232. # [17:25] <anne> plus what zcorpan_ said
  233. # [17:25] * Quits: gavin_ (gavin@99.226.75.20) (Ping timeout)
  234. # [17:25] <aaronlev> anne: i was writing in pseudo code, i figure you'd handle the deatils
  235. # [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
  236. # [17:26] <aaronlev> go ahead and make the spec how you want, i'll deal with it
  237. # [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 :)
  238. # [17:30] <zcorpan_> aaronlev: what happens when an element has role=presentation but is focusable?
  239. # [17:30] * Joins: gavin_ (gavin@99.226.75.20)
  240. # [17:35] <aaronlev> zcorpan_: the fact that it's focusable overrides the presentation role
  241. # [17:35] <aaronlev> and it is no longer presentational
  242. # [17:37] <zcorpan_> aaronlev: but is the xml-roles object attribute used in that case?
  243. # [17:37] <aaronlev> zcorpan_: yes
  244. # [17:37] <zcorpan_> ok
  245. # [17:41] <zcorpan_> updated the spec
  246. # [17:42] <aaronlev> i kind of like the suggestion for role="aol-buddylist listbox"
  247. # [17:42] <anne> good :)
  248. # [17:43] <zcorpan_> :)
  249. # [17:44] <aaronlev> doesn't mean everyone will, but we have a good chance
  250. # [17:45] <anne> i don't think "everyone" will ever agree on something
  251. # [17:46] <anne> although it would be nice
  252. # [17:47] <aaronlev> i mean we have a good chance for consensus
  253. # [17:47] <aaronlev> you guys really make me use exact language :)
  254. # [17:48] <aaronlev> "However, unlike the xml prefix, the wairole prefix has to be declared before it is used according to this specification"
  255. # [17:48] <aaronlev> why did we add that?
  256. # [17:48] <zcorpan_> because we want to ban the wairole: prefix in text/html :)
  257. # [17:48] <aaronlev> k
  258. # [17:48] <aaronlev> although the processing rules allow for it
  259. # [17:48] <zcorpan_> yes
  260. # [17:49] <aaronlev> Is it work saying something about that?
  261. # [17:49] <aaronlev> It's easy to miss
  262. # [17:49] <anne> the processing rules don't allow for the other thing that _is_ allowed
  263. # [17:49] <anne> i think the authoring requirements should be made simpler by removing all the namespace cruft
  264. # [17:50] <aaronlev> anne: the processing rules don't allow for what other thing?
  265. # [17:50] <anne> foobar:role
  266. # [17:50] <anne> foobar:value
  267. # [17:50] <hsivonen> aaronlev: what was the passing mention about RDF and localized strings about?
  268. # [17:50] <hsivonen> (I can't remember whether it was here or on-list)
  269. # [17:51] <zcorpan_> anne: if "foobar:role" is a supported custom role, then it will be used :)
  270. # [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
  271. # [17:51] <anne> zcorpan_, sure, but it won't be bound to a namespace
  272. # [17:51] <aaronlev> it would be nice if that was called out so everyone was clear on it
  273. # [17:51] <anne> I would suggest to just read the processing requirements
  274. # [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
  275. # [17:52] <aaronlev> we haven't spent enough time in PFWG talking about how RDF would be used for custom roles
  276. # [17:52] <aaronlev> because we're trying to get1.0 out, and we've pushed that off
  277. # [17:52] <aaronlev> plus i've been telling them rdf sucks for this.
  278. # [17:52] <aaronlev> but that said ...
  279. # [17:53] <anne> my suggestion would be to merge the role values into the Simon proposal and publish that instead
  280. # [17:53] <anne> and dump the XHTML role module
  281. # [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.
  282. # [17:53] <aaronlev> and to doefine what gets spoken, if anything, when those properties change
  283. # [17:53] <aaronlev> not necessarily spoken
  284. # [17:54] <aaronlev> but presented
  285. # [17:54] <zcorpan_> aaronlev: what do you want the spec to say? and where? (re differences in authoring/ua reqs)
  286. # [17:54] <aaronlev> so for example, if aol-away="false" becomes "True"
  287. # [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
  288. # [17:54] <aaronlev> hsivonen: it should be for all the base well-known markup
  289. # [17:54] <aaronlev> but it's impossible for ATs to keep up with the web
  290. # [17:55] <aaronlev> or with software in general
  291. # [17:55] <aaronlev> that's always been a big problem
  292. # [17:55] <aaronlev> people want to define new stuff and how the AT should deal with it
  293. # [17:55] <aaronlev> zcorpan_: how about a summary table
  294. # [17:55] <hsivonen> so they want effectively to program the AT from within content?
  295. # [17:56] <aaronlev> zcorpan_: with what's allowed or not allowed for authors or processing
  296. # [17:56] <aaronlev> hsivonen: not program the AT, but supply it with what it needs to know
  297. # [17:56] <aaronlev> it's not script
  298. # [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
  299. # [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
  300. # [17:58] <zcorpan_> aaronlev: if you're an author, you don't care about ua reqs
  301. # [17:58] <aaronlev> zcorpan_: ok
  302. # [17:58] <zcorpan_> aaronlev: and if you're an implementor, you don't care about authoring reqs
  303. # [17:58] <hsivonen> not that the UA assembles stuff from string bundles
  304. # [17:58] <aaronlev> hsivonen: i don't think pfwg thought about localization, but from what they're saying, it would be needed
  305. # [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
  306. # [17:59] * Joins: Sander (svl@86.87.68.167)
  307. # [17:59] <anne> why would you localize role values and not the <body> element?
  308. # [17:59] <aaronlev> anne: <body> is well-known
  309. # [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
  310. # [18:00] <anne> there's lots of things here that don't make sense to me
  311. # [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)
  312. # [18:01] <hsivonen> aaronlev: I'd expect client "support" for aol-buddy list to include the chrome strings required for speaking about buddy lists
  313. # [18:01] <aaronlev> hsivonen: the idea is to break accessibility from the chains of the AT bottleneck
  314. # [18:01] * Joins: polin8 (polin8@75.71.72.175)
  315. # [18:01] <aaronlev> tiny companies that cannot hope to keep up with current authoring
  316. # [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
  317. # [18:02] <aaronlev> and if we could push it off until there is time to discuss it more deeply that'd be great
  318. # [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
  319. # [18:03] * Quits: polin8 (polin8@75.71.72.175) (Quit: :wq)
  320. # [18:03] <hsivonen> why wouldn't the screen readable strings be similarly part of the content in the language of the content?
  321. # [18:03] <aaronlev> ah
  322. # [18:04] <aaronlev> right, the problem with that was, how to associate the localized property name with the semantic one
  323. # [18:04] <hsivonen> doing string bundle-based UI assembly on the client is some serious scope creep
  324. # [18:04] <aaronlev> hsivonen: no one wnts to pass the entire string budle over to the at
  325. # [18:05] <aaronlev> i'm sure we can come up with something better
  326. # [18:06] <hsivonen> aaronlev: but if the custom roles are only opaque identifiers to the AT, why bother with that abstraction at all?
  327. # [18:06] <aaronlev> because you may also want to write scripts that utilize the semantic value
  328. # [18:06] <hsivonen> aaronlev: shouldn't "semantic" identifiers be removed then and the user experience be driven directly with custom UI strings?
  329. # [18:06] <hsivonen> hmm.
  330. # [18:06] <aaronlev> there is no sharp line between what the AT's will handle now and what they will evolve to handle
  331. # [18:06] <aaronlev> some ATs will evolve to handle busy=false|true and do something special for that
  332. # [18:07] <aaronlev> otherws will use the fallback
  333. # [18:07] <aaronlev> <div role="aol-buddy option">My friend</div>
  334. # [18:07] <hsivonen> ok
  335. # [18:07] <aaronlev> how should is specify that he is busy or not, and how that changes
  336. # [18:07] <hsivonen> but to me, aol-buddy makes no sense without at least one voice browsing configuration doing something useful with it natively
  337. # [18:07] <aaronlev> in a way that the author can define the fallback localization for the AT
  338. # [18:08] <aaronlev> it is alreayd usefuly to say "My friend" "busy off" or "busy on"
  339. # [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
  340. # [18:09] <anne> It seems to me that this problem is much better solved at the side where there are only 1-10 players
  341. # [18:10] <aaronlev> well there is open source
  342. # [18:10] <aaronlev> how do you define how many players there are in that case
  343. # [18:11] <aaronlev> anne: maybe there is a simpler solution
  344. # [18:11] <aaronlev> but i don't think giving up on the problem i explained is the only reasonable answer
  345. # [18:11] <aaronlev> also, headers|axis suck
  346. # [18:11] <aaronlev> longdesc is not that useful
  347. # [18:11] <aaronlev> and alt is used all the time
  348. # [18:12] <hsivonen> aaronlev: are there known implementations of axis?
  349. # [18:12] <aaronlev> hsivonen: not that i've found
  350. # [18:12] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
  351. # [18:13] <hsivonen> aaronlev: for the purpose of counting players, I'd count version control repos
  352. # [18:13] <hsivonen> aaronlev: so the Mozilla cvs repo counts as one "player" for anne's purpose
  353. # [18:13] <aaronlev> there are a lot more than one player involved in mozilla
  354. # [18:14] <zcorpan_> mozilla has multiple version control repos? :)
  355. # [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
  356. # [18:15] <aaronlev> that's for sure
  357. # [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
  358. # [18:15] <aaronlev> even if we implement it
  359. # [18:16] <aaronlev> so we should wait until we get the bases covered, but keep ourselves open to it for later
  360. # [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
  361. # [18:18] <aaronlev> that was one proposal, but people want semantics
  362. # [18:18] <aaronlev> it's certainly a lot simpler
  363. # [18:19] <aaronlev> we could offer that for now and the promised land of something better when we get to xbl
  364. # [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
  365. # [18:19] <aaronlev> who says there won't be
  366. # [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
  367. # [18:20] <hsivonen> aaronlev: authoring for future clients and scripting support for today's clients tends to poison the future
  368. # [18:21] <aaronlev> i don't follow, but i'd like to continue the conversation later
  369. # [18:21] <aaronlev> i have to go pick up my daughter
  370. # [18:21] <zcorpan_> aaronlev: cya
  371. # [18:21] <aaronlev> later
  372. # [18:23] * Joins: hyatt (hyatt@209.173.92.142)
  373. # [18:25] <hsivonen> aaronlev: bye
  374. # [18:25] <hsivonen> anyway, for logs: what I meant is this
  375. # [18:26] <hsivonen> consider WF2
  376. # [18:26] <hsivonen> there's Opera 9 and there's scripts for IE
  377. # [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
  378. # [18:27] <hsivonen> that is, that the scripts properly go out of the way when the native impl. is there
  379. # [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
  380. # [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
  381. # [18:30] <hsivonen> (O'Reilly's "XHTML" was ill-formed)
  382. # [18:35] * Quits: hyatt (hyatt@209.173.92.142) (Quit: hyatt)
  383. # [18:54] * Quits: Sander (svl@86.87.68.167) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  384. # [19:12] * Joins: mjs (mjs@17.255.98.235)
  385. # [19:18] <anne> krijnh, any chance you can fix the regular expression used for autolinking URIs in the archives?
  386. # [19:18] <anne> krijnh, you need a pattern for <http://, specifically, see http://krijnhoetmer.nl/irc-logs/whatwg/20070930
  387. # [19:20] <anne> hsivonen, http://validator.nu/?doc=http%3A%2F%2Fannevankesteren.nl%2F2007%2F09%2Ftmb-overview
  388. # [19:20] <anne> hsivonen, scope= is allowed at those points :)
  389. # [19:20] <hsivonen> anne: wasn't when I last reviewed the schema ;-)
  390. # [19:21] * Joins: aroben (aroben@17.203.12.72)
  391. # [19:21] <hsivonen> anne: anyway, I'll fix that soonish
  392. # [19:21] * hsivonen is working on multipart/form-data support
  393. # [19:22] <anne> no problem; I validated my frontpage as HTML4 and then using HTML5 override mode and it suddenly stopped validating
  394. # [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))
  395. # [19:24] <zcorpan_> anne: stop being so elitist ;)
  396. # [19:24] <anne> is fact telling elitist now? :p
  397. # [19:24] * anne hides
  398. # [19:28] <krijnh> anne: unhide and fix $content = preg_replace("#((https?|ftp):[^'\">\\s]+)#", '<a href="\1">\1</a>', $content); will ya ;)
  399. # [19:29] <aaronlev> hsivonen: hi
  400. # [19:30] <anne> krijnh, ouch
  401. # [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
  402. # [19:30] <hsivonen> aroben: hi
  403. # [19:30] <krijnh> I wonder where I copied that one from
  404. # [19:30] <hsivonen> doh
  405. # [19:30] <hsivonen> aaronlev: hi
  406. # [19:30] <hsivonen> aaronlev: ok
  407. # [19:30] <aaronlev> hsivonen: because i think something reasonable may exist
  408. # [19:30] <aroben> hi hsivonen
  409. # [19:31] * aroben is a typo
  410. # [19:31] <aaronlev> and i should probably write something up to explain how it would work and why it's not bad
  411. # [19:31] <aaronlev> so people can critique that
  412. # [19:31] <aaronlev> but i agree that the current ideas are too complicated to fly
  413. # [19:32] <hsivonen> aaronlev: did you see my point about speculative future compat without nothing to test against? (in the log earlier)
  414. # [19:32] <aaronlev> i didn't understand it completely, sorry for being dense
  415. # [19:33] <aaronlev> i think for we have enough future compat in there
  416. # [19:33] <anne> krijnh, I suppose you can simply add one before that one that replaces all occurances of <http:// ...> with http:// ...
  417. # [19:33] * Quits: gavin_ (gavin@99.226.75.20) (Ping timeout)
  418. # [19:33] <aaronlev> because we're ignoring everything but wairole
  419. # [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
  420. # [19:34] <aaronlev> yes
  421. # [19:34] <aaronlev> we have that prolbem today with screen readers
  422. # [19:34] <aaronlev> but not on the web
  423. # [19:34] <aaronlev> JAWS provides a scripting language
  424. # [19:34] <aaronlev> for desktop apps
  425. # [19:35] <aaronlev> and sometimes what happens, is someone develops a JAWS script that works well enough
  426. # [19:35] <aaronlev> and the app is never truly made accessible
  427. # [19:35] <krijnh> anne: no time now, sorry
  428. # [19:35] <aaronlev> but, on the whole it empowers the users, who get to share scripts
  429. # [19:35] <aaronlev> and it's unrealistic for every app to have native jaws support that works well enough
  430. # [19:35] <hsivonen> aaronlev: is it because the script is useful enough or because changing the app would break the script?
  431. # [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
  432. # [19:36] <anne> krijnh, you can say that again :p
  433. # [19:36] <aaronlev> however, apps that change and get a new version break the scripts all the time
  434. # [19:36] <aaronlev> athat's just reality
  435. # [19:37] <aaronlev> thes script-breaking changes aren't usually because someone made it more accessible
  436. # [19:37] <aaronlev> but because the app just changed
  437. # [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
  438. # [19:38] * Joins: gavin_ (gavin@99.226.75.20)
  439. # [19:38] <krijnh> anne: I can :)
  440. # [19:41] <hsivonen> aaronlev: ok. the Web parallel is more like greasemonkey
  441. # [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
  442. # [19:42] <aaronlev> hsivonen: right, although the at script shouldn't modify the dom imo
  443. # [19:42] <hsivonen> s/the/that/
  444. # [19:46] <aaronlev> right, like greasemonkey but readonly
  445. # [19:46] <aaronlev> doesn't modify the dom
  446. # [19:47] <aaronlev> although possibly pushes input
  447. # [19:47] <aaronlev> or sets focus
  448. # [19:47] * Joins: hyatt (hyatt@209.173.92.142)
  449. # [19:49] * Quits: hyatt (hyatt@209.173.92.142) (Quit: hyatt)
  450. # [19:49] * Joins: hyatt (hyatt@209.173.92.142)
  451. # [20:05] * Quits: xover (xover@193.157.66.5) (Ping timeout)
  452. # [20:05] * Joins: xover (xover@193.157.66.5)
  453. # [20:05] * Quits: laplink (link@193.157.66.199) (Ping timeout)
  454. # [20:05] * Joins: laplink (link@193.157.66.199)
  455. # [20:19] * Joins: icaaq (icaaaq@85.228.55.82)
  456. # [20:28] * Parts: timbl (timbl@128.30.7.41)
  457. # [20:32] * Joins: Sander (svl@86.87.68.167)
  458. # [20:52] * Parts: hendry_ (hendry@89.16.172.32)
  459. # [20:54] * Quits: zcorpan_ (zcorpan@88.131.66.80) (Ping timeout)
  460. # [20:55] * anne replies to rich
  461. # [21:03] * Quits: Steve_f (chatzilla@82.44.69.8) (Connection reset by peer)
  462. # [21:04] * Joins: Steve_f (chatzilla@82.44.69.8)
  463. # [21:09] * Quits: ROBOd (robod@89.122.216.38) (Quit: http://www.robodesign.ro )
  464. # [21:21] * Joins: drry_ (drry@210.191.161.204)
  465. # [21:22] * Quits: drry (drry@210.191.160.64) (Ping timeout)
  466. # [21:28] * Quits: drry_ (drry@210.191.161.204) (Quit: drry_)
  467. # [21:30] * Quits: Steve_f (chatzilla@82.44.69.8) (Quit: ChatZilla 0.9.78.1 [Firefox 2.0.0.7/2007091417])
  468. # [21:31] * Joins: drry (drry@210.191.161.204)
  469. # [21:35] <anne> lol
  470. # [21:35] <anne> http://www.w3.org/mid/47014AF2.3040205@aptest.com
  471. # [21:41] * Quits: gavin_ (gavin@99.226.75.20) (Ping timeout)
  472. # [21:46] * Joins: gavin_ (gavin@99.226.75.20)
  473. # [21:47] * Quits: aroben (aroben@17.203.12.72) (Ping timeout)
  474. # [21:50] * Joins: aroben (aroben@17.203.12.72)
  475. # [21:52] * Quits: mjs (mjs@17.255.98.235) (Quit: mjs)
  476. # [21:53] * Joins: mjs (mjs@17.255.98.235)
  477. # [22:02] * Quits: mjs (mjs@17.255.98.235) (Quit: mjs)
  478. # [22:11] * Joins: mjs (mjs@17.255.98.235)
  479. # [22:11] <aaronlev> anne: no doubt, someone please make it stop :)
  480. # [22:13] <anne> "opaque string battles"
  481. # [22:14] <anne> oh, and politics
  482. # [22:14] <anne> W3C seems mostly about politics these days, not about doing any actual technical stuff
  483. # [22:14] <anne> that's for your free time
  484. # [22:15] <aaronlev> yep
  485. # [22:21] <aaronlev> anne: that doc lists both xhtml2 wg and html wg
  486. # [22:22] <anne> yeah, and PFWG
  487. # [22:22] <anne> and the RDFa guys, hurray
  488. # [22:29] * Quits: schepers (schepers@128.30.52.30) (Ping timeout)
  489. # [22:47] * Joins: dbaron (dbaron@63.245.220.241)
  490. # [22:58] * Quits: mjs (mjs@17.255.98.235) (Ping timeout)
  491. # [23:06] * Quits: gavin (gavin@63.245.208.169) (Ping timeout)
  492. # [23:09] * Joins: gavin (gavin@63.245.208.169)
  493. # [23:13] * Quits: aroben (aroben@17.203.12.72) (Connection reset by peer)
  494. # [23:16] * Quits: gavin (gavin@63.245.208.169) (Ping timeout)
  495. # [23:19] * Joins: aroben (aroben@17.203.12.236)
  496. # [23:20] * Joins: gavin (gavin@63.245.208.169)
  497. # [23:20] * Quits: aroben (aroben@17.203.12.236) (Connection reset by peer)
  498. # [23:20] * Joins: aroben (aroben@17.203.12.236)
  499. # [23:24] * Quits: aaronlev (chatzilla@66.31.86.217) (Ping timeout)
  500. # [23:24] * Joins: karl (karlcow@128.30.52.30)
  501. # [23:25] * Joins: aaronlev (chatzilla@66.31.86.217)
  502. # [23:25] * Joins: mjs (mjs@17.255.98.235)
  503. # [23:27] * Joins: aaron (chatzilla@66.31.86.217)
  504. # [23:28] * Quits: mjs (mjs@17.255.98.235) (Quit: mjs)
  505. # [23:29] * Quits: aaronlev (chatzilla@66.31.86.217) (Ping timeout)
  506. # [23:29] * aaron is now known as aaronlev
  507. # [23:35] * Joins: aroben_ (aroben@17.203.12.72)
  508. # [23:37] * Quits: aroben (aroben@17.203.12.236) (Quit: Leaving)
  509. # [23:37] * aroben_ is now known as aroben
  510. # [23:46] * Quits: tH (Rob@87.102.67.202) (Quit: ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508])
  511. # [23:48] * Quits: gavin_ (gavin@99.226.75.20) (Ping timeout)
  512. # [23:50] * Quits: anne (annevk@81.68.67.12) (Ping timeout)
  513. # [23:50] * Joins: mjs (mjs@17.255.98.235)
  514. # [23:52] * Quits: Sander (svl@86.87.68.167) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  515. # [23:53] * Joins: gavin_ (gavin@99.226.75.20)
  516. # [23:55] * Joins: kingryan (rking3@208.66.64.47)
  517. # Session Close: Tue Oct 02 00:00:00 2007

The end :)