/irc-logs / w3c / #html-wg / 2007-11-02 / end

Options:

  1. # Session Start: Fri Nov 02 00:00:00 2007
  2. # Session Ident: #html-wg
  3. # [00:01] * Quits: aroben (aroben@17.203.12.72) (Quit: Leaving)
  4. # [00:01] * Joins: timbl (timbl@146.115.66.146)
  5. # [00:07] * Quits: ChrisWilson (cwilso@131.107.0.74) (Ping timeout)
  6. # [00:11] * Joins: sbuluf (veg@200.49.140.197)
  7. # [00:25] * Joins: karl (karlcow@128.30.52.30)
  8. # [00:26] * Quits: hasather (hasather@90.231.107.133) (Quit: leaving)
  9. # [00:35] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
  10. # [01:08] * Joins: smedero (smedero@207.245.69.186)
  11. # [01:09] * Quits: tH (Rob@87.102.17.22) (Quit: ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508])
  12. # [01:20] * Quits: mjs (mjs@207.47.0.2) (Ping timeout)
  13. # [01:21] * Joins: mjs (mjs@207.47.0.2)
  14. # [01:33] * Quits: kingryan (rking3@208.66.64.47) (Quit: kingryan)
  15. # [01:40] * Quits: mjs (mjs@207.47.0.2) (Quit: mjs)
  16. # [01:44] * Lionhear1 coughs
  17. # [01:44] * Lionhear1 is now known as Lionheart
  18. # [01:56] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  19. # [02:59] * Quits: smedero (smedero@207.245.69.186) (Quit: smedero)
  20. # [03:35] * Joins: smedero (smedero@207.245.69.186)
  21. # [03:36] * Quits: smedero (smedero@207.245.69.186) (Quit: smedero)
  22. # [04:18] * Quits: deltab (deltab@82.36.30.34) (Ping timeout)
  23. # [04:19] * Joins: deltab (deltab@82.36.30.34)
  24. # [04:51] * Quits: gavin (gavin@99.227.30.12) (Ping timeout)
  25. # [04:56] * Joins: gavin (gavin@99.227.30.12)
  26. # [05:24] * Joins: mjs (mjs@64.81.48.145)
  27. # [05:46] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
  28. # [05:46] * Joins: mjs (mjs@64.81.48.145)
  29. # [07:52] * Quits: gavin (gavin@99.227.30.12) (Ping timeout)
  30. # [07:57] * Joins: gavin (gavin@99.227.30.12)
  31. # [07:57] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Client exited)
  32. # [07:57] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  33. # [08:35] * Quits: shepazu (schepers@128.30.52.30) (Quit: Trillian (http://www.ceruleanstudios.com)
  34. # [08:48] * Joins: shepazu (schepers@128.30.52.30)
  35. # [08:54] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
  36. # [08:56] * Quits: shepazu (schepers@128.30.52.30) (Client exited)
  37. # [09:03] * Joins: shepazu (schepers@128.30.52.30)
  38. # [09:35] * Joins: tH_ (Rob@87.102.17.22)
  39. # [09:35] * tH_ is now known as tH
  40. # [10:00] * Quits: gavin (gavin@99.227.30.12) (Ping timeout)
  41. # [10:05] * Joins: gavin (gavin@99.227.30.12)
  42. # [10:12] <anne> hsivonen, do you have a more concrete sugggestion about HTML/XHTML compatibility?
  43. # [10:12] * anne is making some changes to the document now
  44. # [10:12] <anne> though one problem I have is that I haven't been keeping track of all feedback which is a problem...
  45. # [10:12] * anne thought he wasn't going to edit it again
  46. # [10:24] <anne> mjs, the design principles are currently a bit weird with two principles extending several paragraphs and the rest just having a single...
  47. # [10:25] <anne> mjs, was the plan to make the rest equally long?
  48. # [10:44] * Joins: Steve_f (chatzilla@82.44.69.8)
  49. # [10:45] <hsivonen> anne: more concrete compared to what?
  50. # [10:46] <anne> to just saying we need one
  51. # [10:46] <anne> but I made a proposal in an e-mail I'm about to send right now
  52. # [10:46] <hsivonen> anne: I think there should be DOM consistency between HTML5 and XHTML5
  53. # [10:47] <hsivonen> anne: but if there's an extremely good reason (e.g. legacy reality) to have specific discrepancies, we can have those but we should try hard to minimize them
  54. # [10:48] <hsivonen> anne: and the reason for DOM consistency is to allow the same code to operate on HTML5 and XHTML5 document trees
  55. # [10:48] <anne> it was more about hearing actual proposed text :)
  56. # [10:48] <anne> as you might know, i understand the reasons :p
  57. # [10:48] <hsivonen> right
  58. # [10:49] <anne> looking at #whatwg logs it seems that mjs is sleeping
  59. # [10:49] <hsivonen> I'm not thinking straight today
  60. # [10:49] <hsivonen> hmm.
  61. # [10:49] <anne> when are you leaving?
  62. # [10:50] <hsivonen> to Boston? in the night between Saturday and Sunday
  63. # [10:50] * Quits: sbuluf (veg@200.49.140.197) (Quit: sbuluf)
  64. # [10:51] <anne> don't you get an awkward arrival time then?
  65. # [10:51] <hsivonen> anne: no, the arrival time is fine
  66. # [10:51] <hsivonen> anne: the departure time sucks
  67. # [10:51] <anne> tell me more :)
  68. # [10:52] * anne will arrive in Boston on Saturday 6PM local time or so
  69. # [10:52] <hsivonen> I'll be arriving on Sunday at 17:05 Boston time
  70. # [10:52] <anne> Steve_f, are you saying that removing "when possible" is not enough?
  71. # [10:52] <hsivonen> The flight from Amsterdam leaves at 15:05 Amsterdam time
  72. # [10:53] <hsivonen> but the flight from Helsinki to Amsterdam is inconveniently early
  73. # [10:53] <hsivonen> still the best option I could find
  74. # [10:53] <anne> oh, that's weird
  75. # [10:53] <hsivonen> it's best to avoid Heathrow these day, so I hear
  76. # [10:53] <anne> I wonder why my flight takes an additional hour
  77. # [10:53] <anne> yeah
  78. # [10:54] <anne> although, even when they had code red or so going on it wasn't too bad from my experience
  79. # [10:54] <hsivonen> anne: Boston changes its timezone between your arrival and my arrival
  80. # [10:54] <hsivonen> anne: Amsterdam keeps its time zone
  81. # [10:54] <anne> fun
  82. # [10:54] <hsivonen> anne: that might explain a one-hour discrepancy
  83. # [10:59] <hsivonen> anne: concrete text: "The two serializations should be designed in such a way that the DOM trees produced by the respective parsers appear as consistently as feasible to scripts and other program code operating on the document trees. Discrepancies can be allowed for compatibility with legacy implementations, but the differences should be minimized."
  84. # [11:00] <hsivonen> the basic sentiment is that yes, there are already some differences but those suck and should not be used as precedent for introducing more
  85. # [11:01] <anne> title and location?
  86. # [11:02] <hsivonen> title: DOM Consistency
  87. # [11:02] <anne> is it a compatibility thing or utility...
  88. # [11:03] <anne> in theory it doesn't affect interop so I don't think that category fits
  89. # [11:05] <Steve_f> hi anne > yes
  90. # [11:05] <anne> Steve_f, see my reply on the list
  91. # [11:05] <hsivonen> anne: Utitily then, I guess
  92. # [11:05] <anne> yeah, i guess
  93. # [11:06] <hsivonen> anne: moreover, there should probably also be a sentence that gratuitous difference in syntactic appearance should be avoided as well (unless required by legacy)
  94. # [11:06] <anne> Steve_f, also keep in mind that these are not language requirements
  95. # [11:08] * Quits: Lachy (Lachy@213.236.208.22) (Quit: Leaving)
  96. # [11:08] * Joins: Lachy (Lachy@213.236.208.22)
  97. # [11:09] <hsivonen> Steve_f: I agree with designing features to be accessible, etc., but I don't think working with WAI is a language design principle even if it might be a good idea
  98. # [11:10] <anne> I'm not sure what's wrong with Universal Access to be honest
  99. # [11:11] <hsivonen> anne: it is more vague than specifically scoping accessibility to disabilities
  100. # [11:12] <anne> yeah, but therefore it does cover people driving in a car, accessing content through a terminal, search engines, etc.
  101. # [11:12] <Lachy> universal access should be turned into a category instead of a principle that contains other principles relating to accessibility, device independence, etc.
  102. # [11:12] * hsivonen agrees with Lachy
  103. # [11:13] <Lachy> I emailied public-html about that 2 or 3 months ago
  104. # [11:13] <anne> with concrete text?
  105. # [11:13] <anne> makes sense to me
  106. # [11:14] <Lachy> http://lists.w3.org/Archives/Public/public-html/2007Aug/0889.html
  107. # [11:16] <hsivonen> btw, perhaps accessing content through a tty should not be taken as a principle when the tty browsers themselves are languishing
  108. # [11:16] <hsivonen> that is, it doesn't really make sense to design for a frozen state of tty browsers
  109. # [11:16] <hsivonen> and it doesn't make sense to design for hypothetical tty browsers
  110. # [11:17] <hsivonen> if it looks like tty browsers aren't getting much feature work attention
  111. # [11:17] <hsivonen> designing language for a product category makes sense if the product category is under active development
  112. # [11:17] <Steve_f> i consider that the differing aspects of universal access need to be noted within the design principles, accessibility should not be subsumed.
  113. # [11:18] * Joins: ROBOd (robod@89.122.216.38)
  114. # [11:19] <Steve_f> lachy:>universal access should be turned into a category instead of a principle that contains other principles relating to accessibility, device independence, etc - this is similar to what i proposed
  115. # [11:21] <Steve_f> hsivenon:>but I don't think working with WAI is a language design principle even if it might be a good idea - i won't be crying if that bit is dropped :-)
  116. # [11:22] <anne> Lachy, what was your text for accessibility?
  117. # [11:24] <Lachy> I can't remember, there's probably an email in the archive somewhere with my suggested text
  118. # [11:28] <hsivonen> btw, is car voice browsing still an adademic idea or has it been productized?
  119. # [11:28] <hsivonen> academic
  120. # [11:29] <Lachy> I doubt it, in car browing really wouldn't be a good idea for the driver. Would be too distracting
  121. # [11:31] <anne> ok, done
  122. # [11:31] <anne> Steve_f, Lachy, hsivonen, please shout on http://www.w3.org/html/wg/html5/principles/#universal-access
  123. # [11:34] <hsivonen> anne: perhaps replace "Features to represent a single web page in multiple languages are out of scope." with "Features for packing multiple translations of a document in a single file aro out of scope."
  124. # [11:34] <hsivonen> s/aro/are/
  125. # [11:34] <hsivonen> "Access by everyone regardless of ability is an essential." broken sentence
  126. # [11:35] <Steve_f> anne: "Access by everyone regardless of ability is an essential. This does not mean that features should be omitted entirely if not all users can fully make use of them, but alternate mechanisms should be provided." two suggested mods
  127. # [11:35] <Steve_f> change " is an essential" to "is essential" .
  128. # [11:35] <Lachy> s/Italics is useful/Italic text is useful/ - grammatically, it reads better that way
  129. # [11:35] <Steve_f> and "mechanisms should be provided" to "mechanisms shall be provided"
  130. # [11:36] <hsivonen> anne: the accessibility principle doesn't say disabilities
  131. # [11:36] <anne> Steve_f, the document doesn't use RFC 2119 terminology
  132. # [11:36] <anne> it's not even a normative document
  133. # [11:36] <anne> i'll make the other edit
  134. # [11:36] <hsivonen> anne: it still looks more like Universality generalities that about accessibility specifics
  135. # [11:37] <anne> hsivonen, did you first suggestion, Lachy, done
  136. # [11:38] <anne> hsivonen, it says "regardless of ability" which seems more positive
  137. # [11:39] <anne> I think that covers it
  138. # [11:39] <Steve_f> anne: "Features should be designed universal access." missing "for"
  139. # [11:39] <beowulf> anne: "Features should be designed universal access." to "Features should be designed for universal access"
  140. # [11:39] <hsivonen> anne: ok. "accessible" and "inclusive" seem ok. "universal" is iffy since the point of the refactoring was to make accessibility stand out on its own from universality
  141. # [11:40] <anne> thanks Steve_f and beowulf
  142. # [11:40] <Steve_f> hsivenon : agree, drop universal
  143. # [11:41] <anne> ok, so "features accessible and inclusive"
  144. # [11:41] <anne> ?
  145. # [11:41] <hsivonen> yeah
  146. # [11:41] <Steve_f> anne: "not all users can fully make use of them" should be changed to "not all users can make full use of them"
  147. # [11:41] <anne> maybe add a sentence: "When possible, make features intrinsically accessible." and add an example about <progress> or so?
  148. # [11:42] <anne> Steve_f, done
  149. # [11:43] <Steve_f> anne: would be good to add in another example as you suggest
  150. # [11:45] <beowulf> tell me, if a technology was badly implemented, such as a the cursor on a mobile moving in increments larger than ui elements, is that somethign universal access shoudl consider or ignore?
  151. # [11:46] <hsivonen> beowulf: I'd say ignore if the implementation just sucks. Opera Mini 4 beta shows that this particular point does not have to suck
  152. # [11:47] <anne> yeah, only if reality shows that "utopia" isn't attainable it should be taken into consideration imo: WYSIWYG editors for instance
  153. # [11:47] <anne> hsivonen, how would you phrase the progress element sample. it seems very clear to me that it's accessible, but i can't come up with suitable text for "why"
  154. # [11:49] <hsivonen> beowulf: refining the point a bit: if there exists an implementation that does not suck, then it isn't intrinsic suckage. however, if all implementation suck, then it might be intrinsic
  155. # [11:49] <anne> apart from that the information it contains can be represented in various forms
  156. # [11:49] <anne> maybe that's it
  157. # [11:49] <hsivonen> anne: no that's not it
  158. # [11:49] <Steve_f> anne: some words about its role ans state being available to assistive tech?
  159. # [11:50] <hsivonen> anne: it has unambiguos progress bar semantics which permits mapping to accessibility APIs that can represent progress indicators
  160. # [11:50] <anne> i guess that's what I meant, thanks
  161. # [11:52] <beowulf> hsivonen: that makes sense, thanks
  162. # [11:54] <Steve_f> I suggest the first sentence under accessibility be changed to "Design features to be accessible to users with disabilities." which makes it unambiguous.
  163. # [11:54] * hsivonen agrees
  164. # [11:55] <anne> done
  165. # [11:55] <Steve_f> hsivenon: thanks
  166. # [11:55] <Steve_f> thanks to all!
  167. # [11:55] <anne> ok, apart from nitpicking i think we can publish it now
  168. # [11:55] <anne> hope that helps DanC get some sleep :p
  169. # [11:56] <anne> and indeed, thanks to everyone who contributed to this cooperative editing effort
  170. # [11:56] <Steve_f> So wil i be seeing you guys in boston?
  171. # [11:56] <hsivonen> I'll be in Boston
  172. # [11:56] <anne> yeah
  173. # [11:57] <anne> well, me anyway
  174. # [11:57] <Steve_f> look forward to meeting you all, gotta go and do some paid work now Se ya! (back to lurking mode)
  175. # [11:59] * Quits: bogi (bogi@153.19.120.250) (Client exited)
  176. # [12:02] <beowulf> hsivonen: I mention it because the s60 webkit browser has a pretty low movement resolution, but like you say om4 works fine
  177. # [12:03] <beowulf> s/browser/cursor
  178. # [12:03] <hsivonen> beowulf: the S60 WebKit browser apparently hasn't gotten as much mobile-specific polish as Opera
  179. # [12:05] <beowulf> it made me wonder how the wf2 slider controls might work in that situation, but it's probably moot as by the time wf2 comes along mobile browsers will have moved a fair bit i guess
  180. # [12:06] <hsivonen> beowulf: I'd expect mobile browsers that have pointing device emulation to be improved to do Opera Mini-style snapping to interactive elements
  181. # [12:06] <hsivonen> beowulf: moreover, I'd expect WF2 range controls not to emulate mouse-operated sliders
  182. # [12:07] <hsivonen> beowulf: rather, I'd expect there to be a focus mechanism (navigate onto widget and press joystick) after which the slider could be adjusted pressing keys
  183. # [12:07] * Quits: gavin (gavin@99.227.30.12) (Ping timeout)
  184. # [12:08] <hsivonen> beowulf: like mobile browsers generally expect you to initiate widget-focused interaction with text inputs, too
  185. # [12:08] <Philip> anne: s/unambiguos/unambiguous/ in the Accessibility section
  186. # [12:08] <hsivonen> beowulf: I think ismap has some intrinsic issues, though, since the UA doesn't know what to snap to
  187. # [12:09] * beowulf wishes to subscribe to hsivonen newsletter
  188. # [12:10] <hsivonen> beowulf: ?
  189. # [12:10] <beowulf> hsivonen: homer simpsone quote "i find your ideas interesting and ish to subscribe to your newsletter"
  190. # [12:11] <hsivonen> hmm. my awareness of Simpsons quotables is limited
  191. # [12:12] <beowulf> hsivonen: do you see any value in putting mobile specific examples such as these into the spec?
  192. # [12:12] <hsivonen> I think it is OK to suggest implementations
  193. # [12:12] <hsivonen> but when the implementation approach is not interop-critical, they shouldn't be requirements
  194. # [12:13] * Joins: gavin (gavin@99.227.30.12)
  195. # [12:14] <anne> Philip, fixed
  196. # [12:28] * Joins: smedero (smedero@158.130.16.191)
  197. # [12:29] * Joins: smedero_ (smedero@158.130.16.191)
  198. # [12:29] * Quits: smedero (smedero@158.130.16.191) (Connection reset by peer)
  199. # [12:45] * Quits: timbl (timbl@146.115.66.146) (Quit: timbl)
  200. # [12:50] * Joins: Sander (svl@86.87.68.167)
  201. # [13:14] <anne> hsivonen, as Hixie said, even with UTF-32 you can have multiple code points representing a single character...
  202. # [13:15] <anne> though maybe not if you normalize it all to NFC, not sure about that
  203. # [13:17] <hsivonen> anne: anyway, a test suite with astral chars on the line before the testable error would yield different UTF-16 and UTF-32 locations
  204. # [13:17] <hsivonen> anne: and with UTF-32 the code point always equals a Unicode character
  205. # [13:18] <hsivonen> anne: but not necessarily what a user might perceive as a character
  206. # [13:18] <hsivonen> anne: a test suite should, IMO, stay firmly away from counting user perceptions. :-)
  207. # [13:30] * Joins: timbl (timbl@128.30.6.228)
  208. # [13:31] * Quits: timbl (timbl@128.30.6.228) (Quit: timbl)
  209. # [13:32] * Joins: timbl (timbl@128.30.6.228)
  210. # [14:14] * Joins: matt (matt@128.30.52.30)
  211. # [14:15] * Quits: gavin (gavin@99.227.30.12) (Ping timeout)
  212. # [14:18] * Joins: aaronlev (chatzilla@66.31.86.217)
  213. # [14:20] * Joins: gavin (gavin@99.227.30.12)
  214. # [14:23] <DanC> aha! a miracle occurred while I was sleeping. most excellent.
  215. # [14:23] <DanC> http://www.w3.org/html/wg/html5/principles/ 1.17 $ of $Date: 2007-11-02 11:13:22
  216. # [14:25] * Quits: anne (annevk@81.68.67.12) (Ping timeout)
  217. # [14:25] * Joins: anne (annevk@81.68.67.12)
  218. # [14:25] * Quits: shepazu (schepers@128.30.52.30) (Client exited)
  219. # [14:27] <anne> yeah, see also some e-mails on public-html for summaries
  220. # [14:27] <DanC> yes, saw those.
  221. # [14:28] <DanC> I hope you can scribble names into the CVS commit logs in the future so that we can improve the acks section
  222. # [14:30] <anne> if you want that to be more detailed that's probably possible
  223. # [14:30] <DanC> I suppose the information isn't really lost; just a little harder to recover
  224. # [14:30] <DanC> I want it to be more detailed, but I don't in any way need it soon
  225. # [14:30] <anne> i can probably come up with a list of names and add a sentence that to the effect that if we forgot you please e-mail the editor
  226. # [14:31] <DanC> that would be a wonderful bonus
  227. # [14:31] * DanC is preparing the formal WBS deely...
  228. # [14:32] <anne> it will include publishing HTML5?
  229. # [14:33] <DanC> that'll be another WBS deely, but yes, I intend to do that today too
  230. # [14:35] * DanC noodles on the shortname for hdp... /TR/html-hdp/ ?
  231. # [14:36] <anne> html-design-principles is not short enough?
  232. # [14:36] <anne> if not html-design-principles i'd go for hdp if that's available
  233. # [14:36] <anne> it's available
  234. # [14:37] <DanC> html-design-principles is fine
  235. # [14:37] <DanC> "Specifically, version 1.17 of 2007-11-02 11:13:22 plus any publication-related changes (e.g. status section, typos, broken links) agreed by one of the editors
  236. # [14:37] <DanC> (Maciej Stachowiak, Anne van Kesteren) and
  237. # [14:37] <DanC> one of the co-chairs (Dan Connolly and Chris Wilson)."
  238. # [14:37] <DanC> I think acks section falls under publication-related changes
  239. # [14:38] <DanC> take a look at http://www.w3.org/2002/09/wbs/40318/wdhdp/ ?
  240. # [14:39] <anne> "It will open on 2007-11-03."
  241. # [14:39] <DanC> right; I don't want to open it until I get some eyeballs on it
  242. # [14:39] <DanC> I'll change that date momentarily
  243. # [14:39] <anne> what I meant with that is that I can't look at it
  244. # [14:39] <DanC> phpht
  245. # [14:40] * Quits: aaronlev (chatzilla@66.31.86.217) (Quit: ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816])
  246. # [14:40] <DanC> ok, 2007-11-02 now. feedback needed urgently
  247. # [14:42] <DanC> can you look at it now, anne?
  248. # [14:44] <DanC> I gotta go to another meeting; I changed the opening date back to 2007-11-03 until I can get another set of eyeballs
  249. # [14:44] <anne> nope
  250. # [14:45] * anne collects names of people
  251. # [14:49] <anne> ok, comitted that
  252. # [14:49] <DanC> very nice
  253. # [14:50] * Quits: paullewis (paullewis@82.242.109.217) (Ping timeout)
  254. # [14:50] <anne> the idea is for everyone who has impacted the document in anyway (pointing out a typo qualifies) to be on that list
  255. # [14:50] <anne> s/anyway/any way/
  256. # [14:51] <DanC> yes, but "in any way" is probably too strong; discussion doesn't count; only direct text suggestions count
  257. # [14:51] <DanC> otherwise you'd have zillions of names to list
  258. # [14:52] <anne> right, but if the editor agrees a change need to be made based on your argument you're included
  259. # [14:52] <DanC> hmm... "direct text suggestions" doesn't cover the case of Henri Sivonen and DOM scripting. but anyway... I think the list of names you've got follows a fairly traditional pattern of acking people whose suggestions you integrated
  260. # [14:52] <anne> oh, ok, so scrap "right, but" above
  261. # [14:53] <anne> for similar reasons, Jirka is included because he pointed out a sentence was confusing which I then fixed
  262. # [14:54] <DanC> ok, can you look at http://www.w3.org/2002/09/wbs/40318/wdhdp/ now?
  263. # [14:55] <anne> no :(
  264. # [14:56] <DanC> hang on a sec...
  265. # [14:56] <DanC> how about now?
  266. # [14:56] <anne> yup
  267. # [14:56] <DanC> (pushing the "today" button didn't actually fill in today's date. :-/ )
  268. # [14:57] <DanC> mjs, you have a good eye for process; do you have a spare minute to peek at http://www.w3.org/2002/09/wbs/40318/wdhdp/ before I announce it?
  269. # [14:57] <anne> seems fine
  270. # [14:58] <anne> I doubt mjs is awake btw
  271. # [14:59] <DanC> hmm... maybe I'll hold off on announcing until I have the corresponding one for the spec ready
  272. # [14:59] * DanC heads to telcon now...
  273. # [15:24] <Philip> anne: s/HTML 5 Editors draft/HTML 5 Editor's draft/
  274. # [15:26] * Quits: anne (annevk@81.68.67.12) (Ping timeout)
  275. # [15:27] * Quits: Sander (svl@86.87.68.167) (Ping timeout)
  276. # [15:27] * Quits: Steve_f (chatzilla@82.44.69.8) (Ping timeout)
  277. # [15:27] * Quits: gsnedders (gsnedders@86.145.188.131) (Ping timeout)
  278. # [15:27] * Quits: beowulf (beowulf@194.74.230.217) (Ping timeout)
  279. # [15:27] * Quits: jgraham (jgraham@81.86.213.34) (Ping timeout)
  280. # [15:27] * Quits: jgraham_ (jgraham@81.86.213.34) (Ping timeout)
  281. # [15:27] * Quits: Philip (philip@80.177.163.133) (Ping timeout)
  282. # [15:27] * Joins: jgraham_ (jgraham@81.86.213.34)
  283. # [15:27] * Joins: Sander (svl@86.87.68.167)
  284. # [15:27] * Joins: Steve_f (chatzilla@82.44.69.8)
  285. # [15:27] * Joins: Philip (philip@80.177.163.133)
  286. # [15:28] * Joins: jgraham (jgraham@81.86.213.34)
  287. # [15:28] * Joins: beowulf (beowulf@194.74.230.217)
  288. # [15:28] <Sander> heh, looks like I wasn't the only one who lost connection. :)
  289. # [15:28] * Joins: anne (annevk@81.68.67.12)
  290. # [15:29] <Philip> anne: Did you see my last comment (~4 minutes ago)?
  291. # [15:29] <Philip> anne: Also, s/behaviour/behavior/
  292. # [15:31] <Philip> s/depends/depend/
  293. # [15:35] <Philip> s/It's/It is/, s/there's/there is/, though I'm mostly just being uselessly pedantic at the moment and this probably doesn't matter that much
  294. # [15:36] <anne> yeah
  295. # [15:36] <anne> i'll do these later
  296. # [15:36] <anne> got to go
  297. # [15:39] <Philip> "The default presentation of the proposed <section> element can be emulated through the CSS rule section { display: block; }." - that doesn't work correctly in the top two browsers, so it's not a good example of graceful degradation
  298. # [15:42] <Philip> s/colums/columns/
  299. # [15:50] * Philip wonders if 'Degrade Gracefully' could be an argument for making something like <section><span>...block-level-elements...</span></section> conforming, so it can degrade usefully in Firefox
  300. # [15:55] <hsivonen> Philip: is that suggestion on file in WHATWG issue list?
  301. # [16:06] <hsivonen> anne: oops. I hadn't seen your email about the Similarity of Serializations when we talked about the principle on IRC
  302. # [16:09] <Philip> hsivonen: Not that I can see, so I should probably mention it somewhere
  303. # [16:09] <Philip> Incidentally, http://canvex.lazyilluminati.com/misc/cgi/issues.cgi/message/%3C689CD652-3320-11D9-8ACF-000A95AD3972%40myrealbox.com%3E vs http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2004-November/002344.html is odd - the *-prefixed lines are missing
  304. # [16:22] * Quits: gavin (gavin@99.227.30.12) (Ping timeout)
  305. # [16:27] * Joins: gavin (gavin@99.227.30.12)
  306. # [16:48] * Quits: Steve_f (chatzilla@82.44.69.8) (Quit: ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816])
  307. # [16:52] * Joins: myakura (myakura@61.214.28.218)
  308. # [16:56] * Joins: Julian (chatzilla@217.91.35.233)
  309. # [17:01] * Joins: aroben (aroben@67.160.250.192)
  310. # [17:11] * Joins: aroben_ (aroben@67.160.250.192)
  311. # [17:13] * Quits: aroben (aroben@67.160.250.192) (Ping timeout)
  312. # [17:14] * Quits: Julian (chatzilla@217.91.35.233) (Ping timeout)
  313. # [17:16] * Quits: aroben_ (aroben@67.160.250.192) (Ping timeout)
  314. # [17:19] * Joins: aroben (aroben@67.160.250.192)
  315. # [17:36] * Joins: shepazu (schepers@128.30.52.30)
  316. # [17:44] * Quits: aroben (aroben@67.160.250.192) (Ping timeout)
  317. # [17:48] * Joins: aroben (aroben@67.160.250.192)
  318. # [17:50] * Quits: shepazu (schepers@128.30.52.30) (Quit: Trillian (http://www.ceruleanstudios.com)
  319. # [18:04] <anne> hsivonen, no problem
  320. # [18:09] * Joins: kingryan (rking3@208.66.64.47)
  321. # [18:14] * Parts: timbl (timbl@128.30.6.228)
  322. # [18:18] <Hixie> "When: Saturday, November 10th, 2 p.m. to 6 p.m. (-ish; or whenever we get tired of it)
  323. # [18:18] <Hixie> er
  324. # [18:18] <Hixie> mispaste
  325. # [18:19] <Hixie> anne: "I did remove "when possible" from the Universal Access principle" -- does that mean that we'll have to make things accessible even when it's _not_ possible?
  326. # [18:19] <Hixie> anne: also, if you're adding DOM Consistency can we also add Baby Steps?
  327. # [18:22] * Joins: ChrisWilson (cwilso@131.107.0.72)
  328. # [18:23] <mjs> I don't see how "when possible" can ever be a bad thing to have
  329. # [18:23] <mjs> it has a very slight badness if something is in fact always possible
  330. # [18:23] <Hixie> we already have examples where it's not, here
  331. # [18:23] <mjs> because it might imply otherwise
  332. # [18:23] <mjs> but in this case that's not clear
  333. # [18:23] <Hixie> namely images that are uploaded without text equivalents
  334. # [18:24] <mjs> I think some accessibility folks would prefer that all features that cannot be made accessible to their satisfaction should be removed
  335. # [18:24] <Hixie> e.g. a webcam
  336. # [18:24] <Hixie> "if we can't make everyone happy, no-one should be"?
  337. # [18:26] <Philip> "If this feature can't make everyone happy, we should concentrate our efforts on other features that can"?
  338. # [18:27] <Hixie> that assumes features are mutually exclusive
  339. # [18:28] <Philip> It assumes working on a feature has an opportunity cost
  340. # [18:28] <beowulf> stupid question, how is a webcam not accessible?
  341. # [18:28] * Quits: myakura (myakura@61.214.28.218) (Quit: Leaving...)
  342. # [18:28] <Hixie> beowulf: if you're blind, you can't see the picture, and unless someone is describing every single frame, you can't get a description either.
  343. # [18:29] <beowulf> that's what i thought you meant
  344. # [18:29] <beowulf> the person at the other end might not be blind though
  345. # [18:30] * Quits: gavin (gavin@99.227.30.12) (Ping timeout)
  346. # [18:30] <Hixie> i meant webcam as in cameras just pointed at town squares or whatever
  347. # [18:30] <beowulf> gotcha
  348. # [18:30] <Hixie> as opposed to video communication
  349. # [18:35] * Joins: gavin (gavin@99.227.30.12)
  350. # [18:35] <mjs> AquariumCam
  351. # [18:35] <mjs> that sort of thing
  352. # [18:37] <Philip> XCoffee is one that could have an accessible alternative
  353. # [18:45] * Quits: Lachy (Lachy@213.236.208.22) (Quit: Leaving)
  354. # [18:46] * Quits: jgraham_ (jgraham@81.86.213.34) (Client exited)
  355. # [18:46] <mjs> good morning btw
  356. # [18:46] <mjs> and that reminds me, I need some coffee
  357. # [18:50] * ChrisWilson passes coffee to mjs
  358. # [18:50] * ChrisWilson is on his second cup - but woke up too early, so needs to be on his third
  359. # [18:53] <mjs> I have this problem
  360. # [18:53] <mjs> where after I get up, I feel too tired to drink coffee for a while
  361. # [18:53] <mjs> but once I've had some coffee, I'm totally fine to drink more coffee.
  362. # [18:53] <ChrisWilson> heh. I don't have the problem. :)
  363. # [18:53] <ChrisWilson> But I do have your latter symptom.
  364. # [19:02] * Joins: timbl (timbl@128.30.6.228)
  365. # [19:14] * Philip sees http://www.straightdope.com/columns/000512.html about rules of thumb
  366. # [19:14] * Joins: gsnedders (gsnedders@86.145.188.131)
  367. # [19:18] * Joins: Julian (chatzilla@80.143.141.117)
  368. # [19:19] * Joins: hober (ted@68.107.112.172)
  369. # [19:23] <mjs> I was not very sympathetic to the rule of thumb thing
  370. # [19:23] <mjs> since it is a myth and apparently very well-known to be one
  371. # [19:23] <mjs> every google reference I found mentioned that it was an urban legend
  372. # [19:24] * Quits: heycam (cam@203.214.45.58) (Ping timeout)
  373. # [19:27] * Joins: heycam (cam@203.214.45.58)
  374. # [19:49] * Joins: hasather (hasather@90.231.107.133)
  375. # [19:54] * Quits: hasather (hasather@90.231.107.133) (Quit: Lost terminal)
  376. # [20:09] * Quits: smedero_ (smedero@158.130.16.191) (Quit: smedero_)
  377. # [20:26] <anne> Hixie, e-mail? :)
  378. # [20:26] * anne sort of has to go
  379. # [20:27] <gsnedders> anne: like move half your body?
  380. # [20:28] * Quits: aroben (aroben@67.160.250.192) (Ping timeout)
  381. # [20:37] * Quits: gavin (gavin@99.227.30.12) (Ping timeout)
  382. # [20:42] * Joins: gavin (gavin@99.227.30.12)
  383. # [20:45] <DanC> hmm... how to phrase the question on the HTML 5 spec, specifically versions
  384. # [20:46] <DanC> do we have a way to point to a specific version of the html5 spec in w3.org space?
  385. # [20:46] <gsnedders> you can point to a specific CVS rev
  386. # [20:47] <gsnedders> DanC: <http://dev.w3.org/cvsweb/html5/spec/Overview.html> has the links, though the CVS viewer adds charset=ISO-8859-1 that we don't want
  387. # [20:48] * Joins: smedero (smedero@207.245.69.186)
  388. # [20:50] <DanC> I might leave that as an exercise to the reader.
  389. # [20:50] <hober> Could one of the choices be "whatever the latest revision is at publish time?"
  390. # [21:00] * Quits: ChrisWilson (cwilso@131.107.0.72) (Ping timeout)
  391. # [21:05] <Hixie> anne: i already sent some :-) can send more if you want
  392. # [21:19] <DanC> hober, I don't want to give multiple choices
  393. # [21:20] <DanC> but I might just let that be the proposal, implicitly
  394. # [21:20] <hober> *nod*
  395. # [21:36] * Philip sees the process:technical discussion ratio rising dangerously
  396. # [21:37] * gsnedders still thinks DanC should just be unpopular and publish all the docs as WDs
  397. # [21:41] <DanC> I'm putting the question on all 3; we'll see how popular the idea is.
  398. # [21:41] <DanC> 2 questions, actually.
  399. # [21:48] <DanC> ok, I think I'm ready to announce the 2 questions: http://www.w3.org/2002/09/wbs/40318/wdhdp/ and http://www.w3.org/2002/09/wbs/40318/wd11spec/
  400. # [21:48] <DanC> gsnedders, Hixie , hober, can you eyeball those real quick?
  401. # [21:48] <Hixie> ooo, more surveys
  402. # [21:48] <Hixie> sure thing
  403. # [21:48] <Hixie> should i reply to them too?
  404. # [21:49] <DanC> umm... wait until I announce to reply, please.
  405. # [21:49] <Hixie> sure thing
  406. # [21:49] <gsnedders> DanC: I would state that we're already overdue the heartbeat requirement
  407. # [21:50] <Hixie> re question 1, i'd like to be the one to do the pubrules updates; i try to keep the document in pubrules compliance and if there are any problems i can probably fix them quicker than anyone else, since i know the markup
  408. # [21:50] <hober> both look good to me
  409. # [21:50] <Hixie> (of course if i'm not around then i don't object to other people doing the updates in the meantime)
  410. # [21:50] <gsnedders> DanC: apart from that, they look fine
  411. # [21:51] <Hixie> DanC: i'd change "should" to "must" in paragraph 4 of question 1
  412. # [21:51] <Hixie> and change "Formally Object" to "Formally Object (you must include technical arguments and proposed changes that would address your objection below"
  413. # [21:51] <Hixie> s/"/)"/
  414. # [21:52] <Hixie> possibly the same with q2
  415. # [21:52] <gsnedders> Hixie: the should is quoted from the process doc
  416. # [21:52] <Hixie> other than that it looks fine
  417. # [21:52] <gsnedders> Hixie: and I'd rather we didn't divert from that on this
  418. # [21:52] <Hixie> gsnedders: in practice we do -- we've ignored formal objections without rationale before in this group, iirc.
  419. # [21:53] <Hixie> and the process document uses rfc2119, which says that "should" can only be violated with rationale, which kinda makes it moot here :-)
  420. # [21:53] <DanC> including technical argument is recommended, but not required, by w3c process
  421. # [21:53] <gsnedders> Hixie: in part, if I'm not mistaken, because the option was just "No", and people didn't realise it was a formal objection
  422. # [21:53] <Hixie> gsnedders: maybe
  423. # [21:53] <hober> So long as the should there is RFC 2119's SHOULD, I'm happy with it. If it's just an ordinary-English-should, then I'd prefer ordinary-English-must.
  424. # [21:54] * DanC is getting behind...
  425. # [21:54] <gsnedders> hober: it's a quote from the process doc, so it is a RFC2119 should
  426. # [21:54] <Hixie> well anyway, that's my feedback. take it or leave it. :-)
  427. # [21:54] <Hixie> (if we don't require feedback, then i'd like it to be made clear what we'll do with a formal objection that has no rationale)
  428. # [21:54] <DanC> re pubrules updates, we'll have to talk about the status section
  429. # [21:54] <Hixie> (because as editor, i see no way to address a formal objection without rationale)
  430. # [21:55] <DanC> all formal objections get considered by the chair; without a rationale, I won't spend much time considering it.
  431. # [21:55] <hober> If there's no rationale specified, then the responder violates the SHOULD, by not specifying "the full implications" that "must be understood and carefully weighed"
  432. # [21:55] <Hixie> right
  433. # [21:55] <Hixie> hober: that's what i said :-)
  434. # [21:56] <gsnedders> hober: and the fact that the should is in reference to giving reasons, is rather silly.
  435. # [21:56] <hober> right
  436. # [21:56] * Hixie runs the pubrules checker to see if he's got any new problems since his last check a few months ago
  437. # [21:56] * Joins: ChrisWilson (cwilso@131.107.0.104)
  438. # [21:57] <Hixie> uh
  439. # [21:57] <Hixie> the pubrules checker returned nothing
  440. # [21:57] <Hixie> wtf
  441. # [21:59] <DanC> I changed http://www.w3.org/2002/09/wbs/40318/wd11spec/ to just say "will choose between v1.310 (Nov 1 03:11:43 2007 UTC) and any later revisions from the editors this week."
  442. # [21:59] <DanC> which leaves it to me to twist your arm about the status
  443. # [21:59] <DanC> if necessary
  444. # [22:00] <Hixie> heh
  445. # [22:00] <Hixie> what's wrong with it?
  446. # [22:01] <Hixie> i don't think the pubrules checker can cope with the html5 spec
  447. # [22:01] <Hixie> sigh
  448. # [22:06] <DanC> I think it's a big step backward that the pubrules checker doesn't work offline anymore.
  449. # [22:06] <DanC> but it integrates input from a bunch of online sources now, so maybe that's a step forward
  450. # [22:06] <Hixie> it doesn't work online either right now
  451. # [22:06] <Hixie> i can't get it to check the doc at all
  452. # [22:06] <Hixie> wtf
  453. # [22:06] <DanC> anyway... I sent the announcement. reply away
  454. # [22:07] <DanC> all I can suggest is a problem report to sysreq, copy me and karl
  455. # [22:07] <Hixie> sysreg@w3?
  456. # [22:07] <DanC> q not g
  457. # [22:07] <Hixie> er right
  458. # [22:07] <Hixie> k
  459. # [22:08] * gsnedders replies away
  460. # [22:10] <gsnedders> huh… they don't show up on my "my questionnaires" page
  461. # [22:15] <DanC> I think there are a few bugs around formal questions and public invited experts
  462. # [22:15] <DanC> all I can suggest is a problem report to sysreq, copy me and karl, again.
  463. # [22:15] * Quits: ROBOd (robod@89.122.216.38) (Quit: http://www.robodesign.ro )
  464. # [22:15] <DanC> I'm pretty sure none of the bugs is critical
  465. # [22:28] * Quits: timbl (timbl@128.30.6.228) (Quit: timbl)
  466. # [22:37] <smedero> Hixie, can you spare moment to elaborate your concerns with the working group filing issues within the Tracker over the wiki?
  467. # [22:38] <smedero> I know you have like 3000+ issues from WHATWG you are working with now... that's a huge task of course... I know you'd like to reduce the amount noise you have to deal with.
  468. # [22:38] <Hixie> i will be replying to those e-mails next
  469. # [22:38] <smedero> Ok.
  470. # [22:38] <smedero> I hate to nag, I just want to find a way to make this work for the editors and the group.
  471. # [22:38] <Hixie> (basically my concerns were based around a misunderstanding about how the tracker worked. i didn't realise the description could be edited. learning now that it can, this will greatly change my opinion.)
  472. # [22:43] <smedero> I'm totally on-board with the previous emails you've sent to the list (and the template on the wiki) about the best way to address issues.
  473. # [22:43] <smedero> A lot of the "issue" pages on the wiki don't even cite a section(s) of the spec they concern.
  474. # [22:43] * Quits: matt (matt@128.30.52.30) (Quit: matt)
  475. # [22:46] <Hixie> yeah a lot of the issues wiki pages are a mess
  476. # [22:47] <Dashiva> At least it's a visible, documented mess instead of a mess hidden in the email archives :)
  477. # [22:47] <smedero> sure, sure. I mean... a lot of content has been placed in the wiki and it is great that people took the time to summarize various discussion that have happened on the list (and in IRC)
  478. # [22:48] <smedero> but to call them Issues is rather misleading...
  479. # [22:48] <smedero> Somewhat related... I tried to look at other examples of the W3C Tracker to see how "Products" was used but I don't have access to view any of the ones linked from the Tracker homepage.
  480. # [22:49] <smedero> Anyone know how that feature has been used in other groups?
  481. # [22:49] <DanC> email archives are hidden? I dunno... email is more clear than the wiki in a lot of cases.
  482. # [22:50] <Dashiva> No, the archives aren't hidden, but finding anything in them is a different problem
  483. # [22:51] <smedero> I would assume that "HTML Design Principles" is a product in the Tracker.
  484. # [22:51] * DanC just sent mail about issues and principles
  485. # [22:52] <DanC> there... 2 products: HTML 5 spec http://www.w3.org/html/wg/tracker/products/1 ...
  486. # [22:52] <DanC> and HTML Principles/Requirements http://www.w3.org/html/wg/tracker/products/2
  487. # [22:53] <DanC> and PINGPOST is connected to the spec now.
  488. # [22:53] <Hixie> do i have to include something else in the subject line, or is "ISSUE-1" enough for ping/post?
  489. # [22:54] <Hixie> (i'm replying to all ping feedback right now)
  490. # [22:54] <DanC> yes, I think ISSUE-1 suffices
  491. # [22:54] <Hixie> excellent
  492. # [22:54] <DanC> I much prefer issue names (PINGPOST) but I think ISSUE-1 is better supported, currently
  493. # [22:55] <DanC> do you want write access to the tracker, Hixie? or do you want to be able to say "I'm busy enough with editing the spec; talk to one of the tracking elves"
  494. # [22:56] <Hixie> well my stance is that write access to the tracker should be publically accessible to anyone, but that's just me. i don't anticipate doing much editing in the tracker, but that's not to say i wouldn't do any if i had access.
  495. # [22:57] <DanC> I think we tried "everyone can write" and didn't win.
  496. # [22:57] <Hixie> oh well
  497. # [22:57] <Hixie> the w3c still has a lot to learn :-)
  498. # [22:57] <Hixie> still, we're making great progress
  499. # [22:58] <DanC> ew... hyatt has 2 accounts or something wierd... http://www.w3.org/2000/09/dbwg/edit-group.php3?search=hyatt&group=41863
  500. # [22:58] <DanC> ah... one is "stopped"
  501. # [22:59] <Hixie> (that's team access only)
  502. # [22:59] <DanC> sorry for the distraction
  503. # [23:00] <DanC> there... Hixie, anne, mjs, hyatt are all added
  504. # [23:00] <Hixie> cool, thanks
  505. # [23:01] * DanC sure wanted to make more progress on test cases this last couple weeks...
  506. # [23:02] <DanC> I'd like to do some ACTUAL FRIGGIN TECHNICAL WORK.
  507. # [23:02] * kingryan has written a bunch of test cases recently
  508. # [23:02] <DanC> sure, kingryan , rub it in.
  509. # [23:02] <DanC> ;-)
  510. # [23:03] <kingryan> gladly
  511. # [23:03] <DanC> watch it or I'll turn you into an issue tracking elf!
  512. # [23:04] <DanC> ;-)
  513. # [23:04] * hsivonen is already a schema-writing elf
  514. # [23:05] * DanC noodles on a document-checker product...
  515. # [23:05] * kingryan is a test case elf, i guess
  516. # [23:06] <DanC> I would like one of the test case elves to do a write-up of some test materials to make them easier to review by the rest of the WG. I'm interested to do it myself, but I won't mind (much) if somebody beats me to it.
  517. # [23:06] <kingryan> what would make them easier to review?
  518. # [23:07] <DanC> last time I checked, the expected results were easy enough to find if you were comfortable with svn checkout and Makefiles... but there wasn't much of a README, let alone a nice hypertext guide
  519. # [23:08] <DanC> a 1 page blog article would be a start
  520. # [23:08] <DanC> there are a bunch of elves signed up to report results of test cases; I'd like some framework where people can run test cases against their browser and report results, with the results aggregated automatically
  521. # [23:09] <DanC> e.g. the tree-vs-lattice parsing issue; I'd like to have a nice table showing which browsers do what.
  522. # [23:10] <DanC> maybe that's a bad example
  523. # [23:11] <DanC> I probably need to get my hands drity more to know what's useful
  524. # [23:13] <DanC> some test materials don't have any automated way of checking expected results; they say "if this paragraph is green, you're winning". those are pretty useful, but even better if we can have dozens of people run them and aggregate the results
  525. # [23:13] <DanC> http://esw.w3.org/topic/HtmlTestMaterials
  526. # [23:17] <Philip> It'd be nicer if the browser could automatically detect that the paragraph is green
  527. # [23:18] <gsnedders> why not pink? :(
  528. # [23:22] <DanC> that worked, Hixie ; your response to all that ping stuff is linked from http://www.w3.org/html/wg/tracker/issues/1
  529. # [23:22] <Hixie> cool
  530. # [23:28] <Hixie> man, gregory is always jumping down my throat, what's with that. did i say no to one of his proposals or something?
  531. # [23:28] * Quits: ChrisWilson (cwilso@131.107.0.104) (Quit: ChrisWilson)
  532. # [23:29] * hsivonen finds Roy Fielding's "No, disagree" rationale interesting
  533. # [23:29] <hsivonen> "so that the folks who just want to implement HTML can do so without any of this operational/DOM nonsense"
  534. # [23:30] <Hixie> that explains his stance on the http spec not needing prose that explains how to implement http interoperably, at least
  535. # [23:33] * Joins: Lachy (Lachlan@88.91.111.68)
  536. # [23:35] * Quits: kingryan (rking3@208.66.64.47) (Quit: kingryan)
  537. # [23:40] <gsnedders> the difference in strictness between HTTP clients and servers is rather amazing, actually
  538. # [23:41] * DanC heads out to his son's birthday party...
  539. # [23:45] * Quits: gavin (gavin@99.227.30.12) (Ping timeout)
  540. # [23:47] * Quits: xover (xover@193.157.66.5) (Quit: Leaving)
  541. # [23:50] * Joins: gavin (gavin@99.227.30.12)
  542. # Session Close: Sat Nov 03 00:00:00 2007

The end :)