/irc-logs / w3c / #html-wg / 2007-06-07 / end

Options:

  1. # Session Start: Thu Jun 07 00:00:00 2007
  2. # Session Ident: #html-wg
  3. # [00:03] * Joins: dbaron (dbaron@63.245.220.242)
  4. # [00:04] <zcorpan> Thomas Broyer has a point -- the table model in html5 isn't good enough
  5. # [00:07] <hsivonen> headers='' needs to be included for backwards compat
  6. # [00:08] <hsivonen> but it has the worst possible burden placement properties of possible solutions
  7. # [00:08] <Dashiva> Included for UAs or in conforming documents too?
  8. # [00:09] <hsivonen> Dashiva: both
  9. # [00:10] <zcorpan> <table><tr><th>A<td>1<th>B<td>2</table> should work
  10. # [00:10] <Dashiva> That's one of the table things... tables that really are multi-columned
  11. # [00:11] <zcorpan> i don't know if THs to the far right should be taken into account
  12. # [00:12] <zcorpan> i haven't seen a table on the web with headers on the right, but i have seen it in print
  13. # [00:12] <zcorpan> (i.e. both on the left and on the right)
  14. # [00:21] <Dashiva> Well, that was the counter-case for scope, two superimposed tables, using all four borders for headings
  15. # [00:22] <zcorpan> i didn't have gez's overlaid table in mind
  16. # [00:23] <zcorpan> i should probably scan it and put it online
  17. # [00:27] * Quits: dbaron (dbaron@63.245.220.242) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  18. # [00:34] * Quits: Sander (svl@71.57.109.108) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  19. # [00:49] * Quits: mw22 (chatzilla@84.41.169.151) (Quit: Chatzilla 0.9.75.1 [SeaMonkey 1.1.2/2007050918])
  20. # [00:56] * Quits: tH (Rob@87.102.12.3) (Quit: ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508])
  21. # [01:01] * Joins: hyatt (hyatt@17.255.100.216)
  22. # [01:05] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
  23. # [01:08] * Parts: hasather (hasather@81.235.209.174)
  24. # [01:10] * Joins: gavin (gavin@74.103.208.221)
  25. # [01:20] * Quits: billmason (billmason@69.30.57.156) (Connection reset by peer)
  26. # [01:30] * Parts: zcorpan (zcorpan@84.216.42.186)
  27. # [01:31] * Joins: zcorpan (zcorpan@84.216.42.186)
  28. # [01:34] * Quits: heycam (cam@203.214.95.190) (Quit: bye)
  29. # [01:36] <zcorpan> http://simon.html5.org/temp/periodic-table.png
  30. # [01:52] * Joins: heycam (cam@130.194.72.84)
  31. # [01:54] * Joins: sbuluf (zonu@200.49.140.249)
  32. # [01:57] * Quits: mjs (mjs@17.255.97.147) (Connection reset by peer)
  33. # [02:07] * Quits: hyatt (hyatt@17.255.100.216) (Quit: hyatt)
  34. # [02:08] * Quits: inimino (inimino@75.71.88.233) (Client exited)
  35. # [02:14] * Joins: inimino (inimino@75.71.88.233)
  36. # [02:27] * Joins: mjs (mjs@17.255.97.147)
  37. # [02:28] * Joins: karl (karlcow@128.30.52.30)
  38. # [02:34] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Quit: Leaving)
  39. # [02:36] * Quits: kingryan (rking3@208.66.64.47) (Quit: kingryan)
  40. # [02:46] * Quits: mjs (mjs@17.255.97.147) (Quit: mjs)
  41. # [03:05] <karl> Laura Carlson made an excellent job
  42. # [03:05] <karl> very deep bow
  43. # [03:10] * Joins: Lachy (chatzilla@203.206.247.10)
  44. # [03:11] <karl> [00:11] <zcorpan> i don't know if THs to the far right should be taken into account
  45. # [03:11] <karl> # # [00:12] <zcorpan> i haven't seen a table on the web with headers on the right, but i have seen it in print
  46. # [03:11] <karl> hmmm
  47. # [03:11] <karl> I guess it would be easier to find such tables (if there are) on pages written in arabic or hebrew
  48. # [03:11] <zcorpan> i meant in LTR tables
  49. # [03:12] <karl> yes
  50. # [03:12] <zcorpan> [01:35] <zcorpan> http://simon.html5.org/temp/periodic-table.png
  51. # [03:12] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
  52. # [03:13] <karl> hmm table with multiple entries
  53. # [03:13] <zcorpan> that's a separate issue
  54. # [03:13] <karl> your headers on the right is another way of reading, what I call multiple entries
  55. # [03:14] <karl> and there is the funny thing at the top left, which has never been solved in HTML tables :) tricky
  56. # [03:14] <zcorpan> oh, ok, i thought you referred to each cell containing multiple data
  57. # [03:14] <zcorpan> and indeed
  58. # [03:15] <karl> nope :) even more complex :p not going there for now :)
  59. # [03:15] <zcorpan> good :)
  60. # [03:16] <zcorpan> the funny thing at the top left can be solved by having one colspanned TH at the top and one rowspanned TH on the left
  61. # [03:16] <zcorpan> semantically
  62. # [03:17] <zcorpan> or moving the vertical header one cell upwards and the horizontal header one cell to the left
  63. # [03:17] * Joins: gavin (gavin@74.103.208.221)
  64. # [03:32] <zcorpan> doing the latter means that the headers on the left won't be in the first column
  65. # [03:33] <Dashiva> For the periodic table, there's a 1:1 mapping between period and orbit, isn't there?
  66. # [03:34] <zcorpan> yeah
  67. # [03:36] * Quits: h3h (bfults@66.162.32.234) (Quit: |)
  68. # [03:46] * Joins: hyatt (hyatt@24.6.91.161)
  69. # [03:48] <zcorpan> http://simon.html5.org/temp/periodic-table.html
  70. # [03:49] <hyatt> didn't you paste that earlier today? :)
  71. # [03:49] <zcorpan> no
  72. # [03:49] <zcorpan> .html
  73. # [03:51] <Lachy> wikipedia does it slightly differently from your examples http://en.wikipedia.org/wiki/Periodic_table
  74. # [03:51] <zcorpan> yeah
  75. # [03:54] <zcorpan> added
  76. # [03:54] * karl wonders if a nested list is possible for this table, not sure
  77. # [03:54] <karl> if I have time later, I will see
  78. # [03:55] <Lachy> zcorpan: why are you spelling "group" as "grupp"?
  79. # [03:55] <zcorpan> swedish
  80. # [03:55] <Lachy> ok
  81. # [03:56] <karl> http://www.la-grange.net/2003/09/08-calendrier-list
  82. # [03:57] <karl> I guess it must fall apart in IE6 at least
  83. # [03:58] <zcorpan> falls apart without css
  84. # [03:59] <karl> well not really it depends on what you want to do
  85. # [04:00] <karl> ah time for the lecture. bbl
  86. # [04:00] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
  87. # [04:11] <zcorpan> hmm
  88. # [04:12] * Quits: hyatt (hyatt@24.6.91.161) (Quit: hyatt)
  89. # [04:12] <zcorpan> if a row contains only THs, and there is a <th scope=row>, then that is a heading for the headings on the same row
  90. # [04:13] <zcorpan> similar for a column
  91. # [04:15] <zcorpan> that would make the wiki periodic table work by just adding scope="" to the "Group" and "Period" cells
  92. # [04:17] <zcorpan> still not sure how to solve the right hand side headers, if at all
  93. # [04:32] * Joins: Lachy_ (chatzilla@203.217.56.97)
  94. # [04:33] * Quits: Lachy (chatzilla@203.206.247.10) (Ping timeout)
  95. # [04:33] * Lachy_ is now known as Lachy
  96. # [04:33] * Quits: Lachy (chatzilla@203.217.56.97) (Quit: ChatZilla 0.9.78.1 [Firefox 2.0.0.3/2007030919])
  97. # [04:35] * Quits: zcorpan (zcorpan@84.216.42.186) (Ping timeout)
  98. # [04:45] * Joins: Sander (svl@71.57.109.108)
  99. # [04:49] * Joins: hyatt (hyatt@24.6.91.161)
  100. # [04:55] * Joins: Lachy (chatzilla@203.217.56.97)
  101. # [05:08] * Quits: hyatt (hyatt@24.6.91.161) (Quit: hyatt)
  102. # [05:54] * Joins: karl (karlcow@128.30.52.30)
  103. # [06:03] * Joins: mjs (mjs@64.81.48.145)
  104. # [06:11] * Joins: hyatt (hyatt@24.6.91.161)
  105. # [06:17] * Quits: hyatt (hyatt@24.6.91.161) (Quit: hyatt)
  106. # [06:59] * Joins: Grigoris (runbaby@213.7.67.137)
  107. # [07:00] <Grigoris> Hello
  108. # [07:00] <Grigoris> Can div tags be displayed inline ?
  109. # [07:00] * Quits: schepers (schepers@84.73.168.194) (Quit: Free at last!)
  110. # [07:09] <karl> Grigoris: yes, but it is not the appropriate channel for this. :) display: inline;
  111. # [07:12] <Grigoris> oh sorry
  112. # [07:17] * Quits: Sander (svl@71.57.109.108) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  113. # [07:17] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
  114. # [07:22] * Joins: gavin (gavin@74.103.208.221)
  115. # [07:31] <Grigoris> bye
  116. # [07:31] * Quits: Grigoris (runbaby@213.7.67.137) (Quit: Grigoris)
  117. # [07:43] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
  118. # [08:01] * Joins: Zeros (Zeros-Elip@69.140.48.129)
  119. # [08:07] * Quits: laplink (link@193.157.66.93) (Quit: Leaving)
  120. # [08:15] * Joins: heycam (cam@203.214.95.190)
  121. # [08:47] * Parts: bdash (bdash@72.36.164.203)
  122. # [08:55] * Joins: schepers (schepers@129.132.127.228)
  123. # [09:01] <karl> I wonder where the style element appears in the page. If someone has a MySpace account
  124. # [09:01] <karl> http://blog.jobamatic.com/2007/06/how_to_hide_the.html
  125. # [09:01] <karl> <style>
  126. # [09:01] <karl> #post_link_container{visibility:hidden;}
  127. # [09:01] <karl> #no-jobs-message{visibility:hidden;}
  128. # [09:01] <karl> #backfill-rule{visibility:hidden;}
  129. # [09:01] <karl> </style>
  130. # [09:02] <anne> doesn't matter
  131. # [09:02] <anne> if it appears in the page it will be used
  132. # [09:02] <karl> anne: I still have a question :) I wonder where they put it in the page.
  133. # [09:03] <karl> your answer is interesting but not the one I was looking for :)
  134. # [09:03] <anne> oh, dunno
  135. # [09:03] <anne> view a myspace page I suppose
  136. # [09:04] <karl> with loud music and images everywhere ;)
  137. # [09:06] <karl> anne: oooh and yesterday you asked about geomap, it wast just a name made like this. thinking out loud. but with the number using maps with the same basic features: flag a part, zoom out/in, tiles loading, etc.
  138. # [09:07] <karl> the source code of MySpace is… interesting
  139. # [09:08] <karl> </style><br><br>
  140. # [09:08] <karl> <br><br>
  141. # [09:08] <karl> </style>
  142. # [09:08] <anne> I suppose that's the better part?
  143. # [09:09] <karl> ;)
  144. # [09:09] <karl> ooooh sweet the ending is quite cool too
  145. # [09:09] <karl> after the </body>, we have an iframe, a script, another script and a...
  146. # [09:09] <karl> <style type="text/css">
  147. # [09:09] <karl> body, html {visibility:visible !important; display:block !important}
  148. # [09:09] <karl> </style>
  149. # [09:09] <karl> </html>
  150. # [09:10] * Joins: schepers_ (schepers@129.132.127.228)
  151. # [09:10] * Quits: schepers (schepers@129.132.127.228) (Connection reset by peer)
  152. # [09:10] <anne> "The HTML working group, according to Juicy Studio, has concluded that the headers attribute for complex tables is unnecessary for HTML5."
  153. # [09:10] <anne> blogs are a great source of information
  154. # [09:10] <mjs> heh
  155. # [09:10] <mjs> still, I am glad actual research and testing was finally done on "headers"
  156. # [09:11] <karl> on blogs your life will be longer, on blogs you will read all kind of craps from informed and uninformed people, on blogs you will save cats
  157. # [09:12] <Zeros> karl, looks like that's a cheap way for them to prevent people from making the entire page invisible?
  158. # [09:12] <karl> "Hi! my name is Karl. I was a blogger. I have stopped on December 31, 2007", "Hiiiii Karl"
  159. # [09:13] <hsivonen> karl: you still have relapses of blogging at the QA blog and the WG blog ;-)
  160. # [09:13] <anne> http://www.mistermartin75.net/?p=29
  161. # [09:13] <karl> hsivonen: sssshhhhhhhh ;) don't tell anyone, it is my secret :p
  162. # [09:13] <anne> (about W3C losing its way)
  163. # [09:14] * Joins: tH (Rob@87.102.12.3)
  164. # [09:16] <karl> "Well, I’ll hear that from the WhatWG (they at least have an idea what they’re doing, and are clear about that to the public)."
  165. # [09:16] <karl> funny
  166. # [09:16] <karl> it is interesting to see people going on their rants
  167. # [09:17] <hsivonen> it is also interesting to see how some people feel betrayed when the W3C adjusts its stance instead of staying the course no matter what
  168. # [09:17] <karl> yes
  169. # [09:18] * Quits: Zeros (Zeros-Elip@69.140.48.129) (Quit: Leaving)
  170. # [09:19] <karl> hsivonen: W3C is a wonderful target for everyone.
  171. # [09:20] <karl> It makes your life as an employee interesting. You are always on the wrong side :) even if you just try to make the communities talking to each other. Kind of interesting exercise after a while.
  172. # [09:20] <karl> It develops the zen part in you.
  173. # [09:24] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
  174. # [09:29] * Joins: gavin (gavin@74.103.208.221)
  175. # [09:34] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
  176. # [09:50] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  177. # [09:52] * Joins: edas (edaspet@88.191.34.123)
  178. # [10:21] <anne> what's 10am LA time here?
  179. # [10:21] <anne> 8:40 hours from now
  180. # [10:24] * Quits: mjs (mjs@64.81.48.145) (Client exited)
  181. # [10:24] * Joins: mjs (mjs@64.81.48.145)
  182. # [10:38] <MikeSmith> anne - http://timeanddate.com/worldclock/meeting.html
  183. # [10:58] * Quits: inimino (inimino@75.71.88.233) (Ping timeout)
  184. # [11:00] * Joins: frippz (frippz@193.15.86.51)
  185. # [12:17] * Quits: edas (edaspet@88.191.34.123) (Client exited)
  186. # [12:21] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
  187. # [12:26] * Joins: gavin (gavin@74.103.208.221)
  188. # [12:46] * Quits: frippz (frippz@193.15.86.51) (Quit: frippz)
  189. # [12:49] * Joins: ROBOd (robod@86.34.246.154)
  190. # [12:55] * Quits: sbuluf (zonu@200.49.140.249) (Ping timeout)
  191. # [12:57] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
  192. # [13:10] * Joins: edas (edaspet@88.191.34.123)
  193. # [13:45] <anne> w3.org down?
  194. # [13:45] <anne> hmm, just slow
  195. # [13:53] <MikeSmith> anne - I think there might be some problems ... tried to do a commit to cvs.w3.org and got an error that seems to indicate it's out of tmp file space
  196. # [13:58] * Quits: olivier (ot@128.30.52.30) (Quit: This computer has gone to sleep)
  197. # [14:02] * Quits: anne (annevk@213.236.208.22) (Ping timeout)
  198. # [14:28] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
  199. # [14:33] * Joins: gavin (gavin@74.103.208.221)
  200. # [15:26] * Joins: anne (annevk@213.236.208.22)
  201. # [15:53] * Joins: icaaq (icaaaq@217.13.228.226)
  202. # [16:11] * Joins: tH_ (Rob@83.100.251.60)
  203. # [16:11] * Quits: tH (Rob@87.102.12.3) (Ping timeout)
  204. # [16:12] * tH_ is now known as tH
  205. # [16:26] * Joins: hasather (hasather@81.235.209.174)
  206. # [16:36] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
  207. # [16:36] * Joins: billmason (billmason@69.30.57.156)
  208. # [16:41] * Joins: gavin (gavin@74.103.208.221)
  209. # [16:44] * Quits: xover (xover@193.157.66.5) (Ping timeout)
  210. # [16:46] * Joins: xover (xover@193.157.66.5)
  211. # [16:51] * Joins: robburns (robburns@208.54.95.1)
  212. # [16:53] * Joins: robburns_ (robburns@208.54.95.1)
  213. # [16:53] * Quits: robburns (robburns@208.54.95.1) (Connection reset by peer)
  214. # [16:53] * Quits: robburns_ (robburns@208.54.95.1) (Connection reset by peer)
  215. # [17:00] * Joins: zcorpan (zcorpan@84.216.41.183)
  216. # [17:02] * Quits: xover (xover@193.157.66.5) (Ping timeout)
  217. # [17:05] * Joins: h3h (bfults@66.162.32.234)
  218. # [17:06] * Joins: Sander (svl@71.57.109.108)
  219. # [17:08] * Joins: xover (xover@193.157.66.5)
  220. # [17:14] * Joins: nickshanks (nicholas@195.137.85.17)
  221. # [17:18] * Parts: icaaq (icaaaq@217.13.228.226)
  222. # [17:19] * Quits: tH (Rob@83.100.251.60) (Ping timeout)
  223. # [17:22] * Quits: nickshanks (nicholas@195.137.85.17) (Quit: nickshanks)
  224. # [17:22] * Joins: nickshanks (nicholas@195.137.85.17)
  225. # [17:33] * Joins: robburns (robburns@208.54.95.1)
  226. # [17:34] * Joins: robburns_ (robburns@208.54.95.1)
  227. # [17:34] * Quits: robburns (robburns@208.54.95.1) (Connection reset by peer)
  228. # [17:38] * Parts: robburns_ (robburns@208.54.95.1)
  229. # [17:40] * Joins: tH (Rob@83.100.251.60)
  230. # [17:44] * Joins: rburns (robburns@208.54.95.1)
  231. # [18:06] * Quits: schepers_ (schepers@129.132.127.228) (Quit: Free at last!)
  232. # [18:13] * Quits: edas (edaspet@88.191.34.123) (Quit: http://eric.daspet.name/ et l'édition 2007 de http://www.paris-web.fr/ )
  233. # [18:17] <DanC> I just added a menu of sections to review to the tasks survey. I'd like quick review before I send it out: http://www.w3.org/2002/09/wbs/40318/tasks83/
  234. # [18:21] <anne> maybe you should exclude "forms" for now
  235. # [18:21] <anne> dunno
  236. # [18:21] <anne> rest looks fine
  237. # [18:21] * Quits: jgraham (jgraham@81.86.210.0) (Ping timeout)
  238. # [18:21] <DanC> why exclude forms?
  239. # [18:22] <anne> hmm, I guess Web Forms 2 was accepted as well
  240. # [18:22] <anne> however, it's not integrated in the spec so the forms section is mostly empty
  241. # [18:22] <DanC> ah. right. I suppose folks who want to review it can figure that out, though
  242. # [18:23] <DanC> i.e. they can find http://dev.w3.org/cvsweb/html5/web-forms-2/
  243. # [18:23] * Joins: rburns_ (robburns@208.54.95.1)
  244. # [18:23] <anne> I guess
  245. # [18:23] * Quits: rburns (robburns@208.54.95.1) (Connection reset by peer)
  246. # [18:23] <rburns_> s
  247. # [18:24] <DanC> I suppose lumping it all into one section is probably not optimal
  248. # [18:24] <anne> ah, the spec already points to Web Forms 2
  249. # [18:24] * anne wonders when the forms TF will start
  250. # [18:25] <zcorpan> DanC: looks good
  251. # [18:27] <rburns_> greetings. questionnaire looks good to me too.
  252. # [18:30] * Joins: hober (ted@68.107.112.172)
  253. # [18:33] * Quits: heycam (cam@203.214.95.190) (Ping timeout)
  254. # [18:38] * Quits: rburns_ (robburns@208.54.95.1) (Client exited)
  255. # [18:42] * Joins: rburns (robburns@208.54.95.1)
  256. # [18:43] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
  257. # [18:48] * Joins: gavin (gavin@74.103.208.221)
  258. # [18:48] <anne> "Note that if we don't say anything, some will assume our endorsement." what exactly does that imply?
  259. # [18:49] <anne> http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/#test_character_encoding_support is wrong
  260. # [18:51] * Joins: oedipus (oedipus@71.250.74.215)
  261. # [18:51] * Quits: oedipus (oedipus@71.250.74.215) (Quit: #html)
  262. # [18:51] * Joins: heycam (cam@203.214.95.190)
  263. # [18:52] * Joins: oedipus (oedipus@71.250.74.215)
  264. # [18:53] <DanC> anne, if W3C publishes mobileOK tests that say "make all your HTML documents purple," some readers will assume that the W3C HTML WG agrees.
  265. # [18:53] <anne> also, they make requirements on content that mobile UAs typically not implement correctly
  266. # [18:53] <anne> such as using XML...
  267. # [18:53] <DanC> where?
  268. # [18:53] <anne> which causes problems for UAs that do support XML
  269. # [18:54] <anne> http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/#test_content_format_support
  270. # [18:54] * Joins: dbaron (dbaron@63.245.220.242)
  271. # [18:54] <anne> requires the media type to not be text/html
  272. # [18:54] <DanC> #test_character_encoding_support ... is it straightforward to make a test that shows it's wrong?
  273. # [18:55] * Joins: Chris (cwilso@131.107.0.105)
  274. # [18:55] <anne> it says "application/xhtml+xml"
  275. # [18:55] <anne> UAs only recognize the "charset" bit
  276. # [18:56] <DanC> hi Chris
  277. # [18:56] <anne> the more relevant thing here however is that per HTML4 <meta> elements are a server thing
  278. # [18:56] <anne> and XHTML should not follow <meta> for character encoding detection, it should simply follow the XML rules
  279. # [18:56] <Chris> Hi Dan (and all
  280. # [18:57] <DanC> I spent some time trying to get my list of agenda/issues updated (http://www.w3.org/html/wg/il16) . I made some progress (1.24), but didn't really get it into a tidy list of things to discuss.
  281. # [18:57] <gsnedders> I guess we can't do anything about
  282. # [18:57] <gsnedders> the mobile platform
  283. # [18:57] <DanC> what do you mean? of course we can do something about the mobile platform.
  284. # [18:58] <gsnedders> about having to treat application/xhtml+xml for backwards compat
  285. # [18:58] <DanC> I don't think I follow you. I'd sure like to look at a test case.
  286. # [18:59] <gsnedders> I've been unable to phrase myself all day :\
  287. # [18:59] * Joins: mjs (mjs@64.81.48.145)
  288. # [18:59] <anne> http://simon.html5.org/articles/mobile-results
  289. # [18:59] <anne> (also has tests)
  290. # [19:00] <DanC> hmm... yes, I recall those. Does one of those show that #test_character_encoding_support is wrong?
  291. # [19:00] <anne> It basically indicates that some mobile browsers parse application/xhtml+xml as "text/html"
  292. # [19:00] <anne> I'm not sure you'd show it's wrong
  293. # [19:00] <anne> XML defines character detection, not XHTML
  294. # [19:01] <anne> and XML doesn't take <meta> in the XHTML namespace into account last time I checked
  295. # [19:01] <gsnedders> my point is that as current UAs treat application/xhtml+xml as HTML, there will be sites which will break if we change that (though it's probably negligibly small)
  296. # [19:02] <anne> that's mostly walled-garden mobile content, but yes
  297. # [19:02] <gsnedders> how walled-gardened is it?
  298. # [19:02] * DanC can't see what's wrong with http://www.w3.org/TR/mobileOK-basic10-tests/#test_character_encoding_support
  299. # [19:02] <anne> DanC, it says you can use the <meta> element in XHTML
  300. # [19:03] <anne> gsnedders, enough to not affect desktop brows(ers|ing)
  301. # [19:04] <DanC> if by "in XHTML" you mean "with the application/xhtml+xml media type", then OK, I see your point.
  302. # [19:04] <mjs> <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8"/>
  303. # [19:05] <Philip`> Does anyone have statistics on how many application/xhtml+xml sites are ill-formed? (maybe particularly on .mobi sites?)
  304. # [19:05] <anne> DanC, they require application/xhtml+xml somewhere else
  305. # [19:05] <anne> also, I'm not convinced that XHTML exists other than with an XML MIME type
  306. # [19:05] <anne> all other "XHTML" mostly relies on HTML specific rules
  307. # [19:05] <Philip`> Looking at the first hundred in Google I can find http://peterbe.mobi/plog/blogitem-040406-1/ and http://www.author-me.mobi/Item7.xhtml which make real browsers unhappy
  308. # [19:06] * Joins: MikeSmith^ (MikeSmith@mcclure.w3.org)
  309. # [19:06] * Quits: MikeSmith^ (MikeSmith@mcclure.w3.org) (Client exited)
  310. # [19:06] <anne> "<span class=c_9>" in XHTML, awesome :)
  311. # [19:06] <mjs> so far no desktop UA has chosen to process the application/xhtml+xml MIME type as text/html, so presumably the content requiring that is all mobile-specific
  312. # [19:07] <DanC> what do you call stuff like http://www.w3.org/html/wg/ , anne ? i.e. it's served with text/html , but it's also XML-WF. I call it XHTML.
  313. # [19:07] <Chris> I'd call it HTML, if it's served as text/html
  314. # [19:07] <anne> mjs, end of 2005 I found a site that broke desktop sites except IE: http://annevankesteren.nl/2005/11/draconian
  315. # [19:07] <gsnedders> I'd also call it HTML
  316. # [19:07] <anne> DanC, all text/html is HTML
  317. # [19:08] <anne> like all text/plain is text
  318. # [19:08] <anne> actually, I retract that last statement
  319. # [19:08] <DanC> well, I could argue a different position. But OK, I can live with that.
  320. # [19:08] <Chris> heh
  321. # [19:08] <anne> there's content sniffing going on for text/plain
  322. # [19:08] <mjs> anne: oh yes, any site that uses content negotiation to serve as HTML or XHTML is likely to do that - I think the only reason desktop UAs haven't changed is because the number of sites using the XHTML MIME type is trivial and none is an important site
  323. # [19:09] <mjs> the situation is rather sad
  324. # [19:10] <anne> s/desktop sites/desktop browsers/
  325. # [19:11] <anne> I believe text/html is also sniffed
  326. # [19:11] <anne> for feeds
  327. # [19:11] <DanC> hmm... I recommend authors use XHTML+CSS, by which I mean XHTML 1.0 Transitional, served as text/html . I hear from consultants that interop is pretty good that way, and I hear from educators that students grok. If I shouldn't use "XHTML" for this, the slogan gets longer. hm.
  328. # [19:11] * Joins: olivier (ot@128.30.52.30)
  329. # [19:11] <gsnedders> anne: yes, many feeds are incorrectly served
  330. # [19:11] <anne> use HTML4 strict + CSS?
  331. # [19:11] <DanC> no, HTML4 strict isn't XML-WF. doesn't work with XML tools.
  332. # [19:12] <anne> most XML toolchains have an HTML parser somewhere
  333. # [19:12] <mjs> XML tools presumably need a special tool anyway to output Appendix C conforming XHTML 1.0
  334. # [19:12] <anne> that too
  335. # [19:12] <mjs> if they can have a mode for that, they can have a mode for HTML output
  336. # [19:13] <anne> <script/> or <textarea/> in text/html won't work for instance
  337. # [19:13] <DanC> well, yeah, an HTML parser that sorta works. maybe when libhtml5 and the like are ubiquitously deployed, it won't matter much... no... I think authors want their tools to report poorly nested tags.
  338. # [19:13] <anne> as mentioned before character encoding stuff is different
  339. # [19:14] <anne> authors use PHP, Perl, Python and a good dosis of string concatenation to generate (X)HTML
  340. # [19:14] <anne> mostly
  341. # [19:14] <rburns> so, if I understand correctly, anne, your concern about http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/#test_character_encoding_support is that the page uses a meta element to set the character encoding (which should already be set through other means)?
  342. # [19:14] <anne> no tools that properly build up trees and then serialize
  343. # [19:14] <DanC> anne, you're talking about what most people do. I'm talking about what I recommend.
  344. # [19:15] * anne likes the ease of string concatenation
  345. # [19:15] <mjs> rburns: using a <meta> element to set the encoding is supposed to be ignored by XML processors
  346. # [19:15] <mjs> rburns: http://www.w3.org/TR/xhtml1/#C_9
  347. # [19:15] <Chris> I think the point is that it's problematic to serve XML-WF HTML as text/html - the tools would need to enforce the HTML compatibility rules too.
  348. # [19:16] <DanC> well, if that's the point, I disagree with it. I've been doing XML-WF HTML as text/html for years and years, quite happily.
  349. # [19:17] <anne> HTML5 allows "XML-WF" as text/html btw
  350. # [19:17] <DanC> about which I am greatly relieved.
  351. # [19:17] <anne> it allows a meaningless / in <br> like <br /> (and similar elements)
  352. # [19:17] <mjs> it's not a world-ending thing to put some slashes in your empty element tags
  353. # [19:17] <anne> and allows a meaningless xmlns attribute on <html> with the XHTML namespace as value
  354. # [19:17] <mjs> the main problem with sending XML with text/html MIME type is that a lot of things will work differently than in real XML
  355. # [19:18] <DanC> meaningless? I don't think so. but no matter.
  356. # [19:18] <hsivonen> anne: doesn't Opera sniff for a certain bogotic mobile spec doctype to reconcile XML rules and Mobile Web b0rkedness?
  357. # [19:18] <anne> it's not quite serialized the same way and especially if you don't follow the rest of the HTML syntax rules things start get icky
  358. # [19:18] <anne> hsivonen, I don't know the details
  359. # [19:18] <mjs> so you'll either try XML constructs and be confused that they fail, or you'll be confused the first time you try processing your document as XHTML and it behaves differently than you expected
  360. # [19:19] <DanC> "a lot of things"? care to be less handy-wavy and more specific, mjs? I can't think of one that matters.
  361. # [19:19] <Chris> I didn't say meaningless or that it should be recommended against - I think it can be problematic if you blindly use XML tools to generate XHTML, then serve it as text/html.
  362. # [19:19] <rburns> I would agree with DanC. I think there's a lot of misunderstanding about authroing xhtml and serving it as text/html. The dangers are much exaggerated.
  363. # [19:19] <mjs> DanC: using self-closing syntax on elements that aren't empty per DTD
  364. # [19:19] <DanC> yes, if you use XML tools to generate HTML, the occasional <blockquote /> can slip in, which doesn't work.
  365. # [19:19] <mjs> <div/>
  366. # [19:19] <anne> DanC, http://wiki.whatwg.org/wiki/HTML_vs._XHTML
  367. # [19:19] <hsivonen> anne: "WML 2.0 and DOCTYPE Switching" in http://www.opera.com/docs/specs/doctype/
  368. # [19:19] <mjs> not the same thing in XHTML and HTML
  369. # [19:20] <mjs> document.write works in HTML but not XHTML (currently)
  370. # [19:20] <gsnedders> <script/> is the worst
  371. # [19:20] <mjs> CSS rules are different
  372. # [19:20] <mjs> case sensitivity rules are different
  373. # [19:20] <gsnedders> (IMO)
  374. # [19:20] <anne> hsivonen, I think that's mostly "namespace defaulting" and some additional entities
  375. # [19:20] <hsivonen> anne: plus the $ utter bogosity
  376. # [19:20] <anne> oh yes
  377. # [19:20] <mjs> in the DOM, elt.tagName uppercases for HTML
  378. # [19:20] <anne> that's evil :)
  379. # [19:21] * DanC has never gotten to the bottom of the uppercase situation
  380. # [19:21] <mjs> HTML is case insensitive and some DOM APIs are required to return uppercase for HTML
  381. # [19:22] <mjs> XHTML is case sensitive and tag names are all in lowercase; DOM APIs do not alter the case for XHTML
  382. # [19:22] <mjs> that's basically the main thing
  383. # [19:22] <DanC> and when you say "for XHTML" there, do you mean "for content labelled application/xhtml+xml"?
  384. # [19:22] <anne> or any other XML MIME type
  385. # [19:22] * Quits: gsnedders (gsnedders@86.139.123.225) (Quit: Don't touch /dev/null…)
  386. # [19:22] <mjs> well yes, to me content labeled text/html is not XHTML
  387. # [19:23] <mjs> if it's labelled text/html, it will be treated with all HTML rules applied
  388. # [19:24] <DanC> and yet it still conforms to the XHTML spec, so it _is_ XHTML. (I said I could accept anne's terminology earlier, but I'm interested to discuss the differences now)
  389. # [19:24] <DanC> maybe I'll try "WF-HTML" or something.
  390. # [19:25] <anne> there's such a thing as syntax error-free HTML
  391. # [19:25] <rburns> the case sensitivity issues are very significant (the CSS differences are significant but easily handled). Just as scripts use feature checks to branch, they could likewise use checks for application/xhtml+xml v text/html for handling case-sensitivity issues (if the document needed to be handled in both environments).
  392. # [19:25] <oedipus> question from gregory: i added an HTML Wiki Space Index / Table of Contents by searching ESW for HTML/* and then adding them to the index; does anyone know of other pages that need to be included?
  393. # [19:26] <mjs> HTML5 could even define a subset of conformance criteria to be well-formedness criteria if that made people happy
  394. # [19:26] <DanC> that would make me happy
  395. # [19:26] <mjs> rburns: a lot of content has a CSS background on the body
  396. # [19:26] <rburns> me too
  397. # [19:26] <anne> that would be difficult
  398. # [19:26] <anne> it would require weird ifdefs in the parsing section
  399. # [19:26] <oedipus> forgot to give the wiki URI: http://esw.w3.org/topic/HTML/TableOfContents
  400. # [19:26] <mjs> anne: it would?
  401. # [19:27] <mjs> what I meant was you could have a concept of "well-formed HTML5 HTML serialization" that would parse without parse errors, but may be nonconforming in other ways
  402. # [19:27] <anne> mjs, maybe you could do it in another way... like saying that if the document is conforming HTML5 and well-formed XML it is super-duper HTML5
  403. # [19:27] <mjs> I didn't mean HTML/XHTML chameleon documents
  404. # [19:28] <anne> oh ok
  405. # [19:28] <mjs> the way to do that in HTML5 would be to validate as HTML5 and validate as XHTML5
  406. # [19:28] <anne> but I don't think people want optional tags in that new serialization
  407. # [19:28] <mjs> if it passes both, that's the rough equivalent of Appendix C, machine-checked for the first time ever
  408. # [19:28] <anne> and don't want characters in there that are not allowed in XML 1.0
  409. # [19:28] <anne> but maybe I'm mistaken
  410. # [19:29] <anne> re CSS differences: we should fix that by making them the same
  411. # [19:29] <rburns> yes, I think that would be ideal. Especially since the draft already abstracts the HTML5 DOM from its two serializations
  412. # [19:29] <mjs> I think reducing the differences is good, where possible
  413. # [19:30] <anne> rburns, what's the advantage over simply using XHTML5 though?
  414. # [19:31] <anne> Other subject, will HTML5 be published as a spec?
  415. # [19:31] <anne> like a snapshot on the TR/ page?
  416. # [19:32] <DanC> yes, but I think it's worth having the WG go over it in some detail 1st.
  417. # [19:32] <DanC> i.e. to swap it in
  418. # [19:33] * Quits: rburns (robburns@208.54.95.1) (Connection reset by peer)
  419. # [19:33] * Joins: rburns (robburns@208.54.95.1)
  420. # [19:33] <DanC> for 1st WD, I currently lean toward a mixture of "what's new in HTML5?" and design princples.
  421. # [19:34] <anne> is there a document for the former?
  422. # [19:35] <DanC> http://wiki.whatwg.org/wiki/Differences_from_HTML4 has been nominated a few times
  423. # [19:35] <anne> Since I wrote that it hasn't really been updated by people...
  424. # [19:36] <DanC> well, it's still better than a blank page
  425. # [19:37] <DanC> hmm... "HTML5 also integrates a new version of DOM Level 2 HTML so the element-specific APIs are defined along with the rest of the language." I have been sorta head-in-the-sand about that sort of thing, assuming that the DOM WG took care of that stuff. I wonder how the WebAPI WG is doing these days.
  426. # [19:39] <anne> http://wiki.whatwg.org/wiki/Talk:Differences_from_HTML4 has some stuff that needs adding
  427. # [19:39] <Chris> heheheh
  428. # [19:39] <DanC> re "This XML serialization is called XHTML5", I've been asked to not use "XHTML5" to save confusion with XHTML2. I replied that XHTML2 should have a name that doesn't have H-T-M-L in that order.
  429. # [19:39] * Joins: gsnedders (gsnedders@86.139.123.225)
  430. # [19:39] <anne> HTML specific APIs are probably best in the HTML spec itself as they directly integrate with the semantics of the language
  431. # [19:39] <anne> DanC, :)
  432. # [19:41] <mjs> DanC: modern w3c language specs include the language-specific DOM
  433. # [19:41] <mjs> (SVG, XForms, etc)
  434. # [19:42] <rburns> Regarding DOM inclusion in the spec, many of the other workgroups define DOM related APIs as they relate to the specific recommendations.
  435. # [19:42] <DanC> yes, as I say, it's somewhat head-in-the-sand to think that the API is Somebody Else's Problem
  436. # [19:42] <rburns> mjs beat me to the punch
  437. # [19:42] <anne> except for CSS :(
  438. # [19:42] * anne works on the CSS Object Model
  439. # [19:42] <nickshanks> do you? or are you just supposed to be doing that? :)
  440. # [19:43] * hsivonen likes DanC's stance on the naming "confusion" with XHTML2.
  441. # [19:43] <mjs> later
  442. # [19:43] <anne> nickshanks, http://dev.w3.org/cvsweb/csswg/cssom/Overview.html has a list of changes
  443. # [19:44] <anne> nickshanks, it's not my full time job
  444. # [19:44] * anne isn't sure it's part of his job...
  445. # [19:44] * DanC noodles on an HTML5 document-checking service
  446. # [19:45] <nickshanks> anne: hey, cool, good to see it's alive and being worked on
  447. # [19:45] <nickshanks> i figured you had so much other stuff to do that it night get left untended
  448. # [19:45] <anne> DanC, like http://hsivonen.iki.fi/validator/html5/ ?
  449. # [19:46] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
  450. # [19:46] <DanC> somewhat like that, yes... does it integrate libhtml5 stuff yet? does it pass the 200 or so tests?
  451. # [19:47] <hsivonen> DanC: I'm writing an HTML5 parser in Jav
  452. # [19:47] <hsivonen> a
  453. # [19:47] <hsivonen> DanC: so does not but will
  454. # [19:48] <DanC> hmm... trying it on the WG homepage, I get "Fatal Error: XHTML public id seen. " hmm... I thought I was using <!DOCTYPE html> there.
  455. # [19:48] <DanC> ah. no... let's try my homepage...
  456. # [19:48] <anne> http://hsivonen.iki.fi/validator/html5/?doc=http%3A%2F%2Fwww.w3.org%2F2006%2Fwebapi%2F
  457. # [19:48] <DanC> #
  458. # [19:48] <DanC> Error: Element div from namespace http://www.w3.org/1999/xhtml not allowed in this context.
  459. # [19:48] <DanC> Line 99, column 22 in resource http://www.w3.org/People/Connolly/
  460. # [19:49] <anne> you can not mix inline level and block level
  461. # [19:49] <anne> you're mixing <a> and <div> within a single parent
  462. # [19:51] <anne> to be honest, I'm not entirely sure why that requirement it is there although it does make some sense to me to not allow <blockquote> test <p>test </p> </blockquote>
  463. # [19:51] <anne> (and similar constructs)
  464. # [19:51] <DanC> is that requirement in the html5 spec, or just in a schema that approximates it?
  465. # [19:51] <anne> req from HTML5
  466. # [19:51] <DanC> is that listed in the differences from HTML4?
  467. # [19:51] * DanC checks...
  468. # [19:52] <anne> it's in "things to possibly add"
  469. # [19:52] <hsivonen> DanC: %Flow has become bimorphic
  470. # [19:52] <DanC> once more, please, hsivonen , in english?
  471. # [19:53] <gsnedders> DanC: it can have one of two states, not both at once
  472. # [19:53] <hsivonen> DanC: what was mix of block and inline in html4 is either block or inline in html5
  473. # [19:53] <DanC> any reason why?
  474. # [19:54] <anne> what does "<div>test<p>test</p></div>" mean?
  475. # [19:54] <anne> was one of the reasons I think
  476. # [19:54] <hsivonen> DanC: I could guess but Hixie knows
  477. # [19:54] <DanC> it means a div element with some text followed by a p element.
  478. # [19:56] <hsivonen> DanC: http://intertwingly.net/blog/2007/05/08/Dont-Break-The-Web#c1178698369
  479. # [19:56] <DanC> the http://wiki.whatwg.org/wiki/Differences_from_HTML4 page gets "Fatal Error: XHTML public id seen." too. doesn't HTML5 just ignore stuff in the <!DOCTYPE >?
  480. # [19:57] <anne> It's a conformance error though...
  481. # [19:57] * anne wonders if http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/#whitespace implies that mobile browsers are supposed to support XML 1.1 too...
  482. # [19:58] <hsivonen> DanC: it is a prototype parser that predates the spec. working on a real parser. will announce when ready
  483. # [19:58] * Quits: rburns (robburns@208.54.95.1) (Connection reset by peer)
  484. # [19:58] <DanC> "Writing a WYSIWYGish editor for HTML is harder if one is to support anything that browsers handle." is arguable, but not justified there. I wonder if tinyMCE and the like use this constraint
  485. # [19:58] * Joins: rburns (robburns@208.54.95.1)
  486. # [19:59] <nickshanks> hsivonen: could you estimate an ETA for tha
  487. # [19:59] <nickshanks> t
  488. # [19:59] <hsivonen> nickshanks: "soon"
  489. # [20:00] <nickshanks> before my kettle boils?
  490. # [20:00] <DanC> java isn't my cup of tea; I'm a little bummed that sam ruby has switched to ruby; I was hoping the python libhtml5 would be sorta the leading implementation. I like python. But I suppose as long as it's *a* leading implementation, I'm fine.
  491. # [20:00] <anne> We'll fix it when needed
  492. # [20:01] <hsivonen> java has the best lib ecosystem for this sort of thing
  493. # [20:01] <DanC> I'm interested to start test-driven validator development, a la http://www.tbray.org/ongoing/When/200x/2007/01/30/XML-2#c1170426928.971842
  494. # [20:01] * anne has hopes for a standalone C parser
  495. # [20:02] <rburns> DanC, I wanted to understand the recent email to the list serv. You said: "I'd like at least two people to do thorough reviews of each section of the spec, and send their comments for discussion in the WG". Does that mean you want those two to thoroughly review the entire draft. Or does it mean you want at least two members to review each section (chapter or subsection) where a different two or more would review each section?
  496. # [20:02] <DanC> java and debian don't get along well yet. I'm trying out ubuntu; maybe I could get modern and take Java seriously. dunno.
  497. # [20:02] <DanC> the latter, rburns
  498. # [20:02] <hsivonen> DanC: I can implement to tests if someone else contributes tests
  499. # [20:02] <DanC> (forall ?section (exists ?person (reviewed ?section ?person))
  500. # [20:03] <rburns> OK :-)
  501. # [20:03] <anne> html5lib has lots of tests that can be reused
  502. # [20:03] <hsivonen> anne: that's the plan
  503. # [20:03] <DanC> yes, html5lib is proceeding nicely in test-driven fashion
  504. # [20:04] * hsivonen will write to spec first to tests second
  505. # [20:04] <anne> that's a good way to find bugs in the tests :)
  506. # [20:04] <DanC> I've been noodling on how to use a wiki to build/maintain the diagnostics used by a checking tool
  507. # [20:08] <DanC> when a checking tool gives a user some bogus message, once the user finds out what it was trying to tell them, they should be able to tweak the message, wiki-style
  508. # [20:10] * hsivonen has been thinking of that style for translating messages
  509. # [20:14] <Philip`> Hmm, the mobile XHTML scene doesn't seem entirely dreadful - out of an arbitrary collection of 4000 .mobi pages of which 109 use application/xhtml+xml, ignoring the totally broken http://peterbe.mobi/ which is in my list lots of times for some reason, only one isn't well-formed XML (and that's only because it's got &copy; and real browsers should work on it) and all have the right xmlns
  510. # [20:14] <Philip`> (though that's far too few pages to get particularly meaningful results)
  511. # [20:15] <DanC> &copy; is a royal pain. it's one of the things that makes me take the XML v.next idea seriously.
  512. # [20:15] <DanC> I go around changing &nbsp; to &#160; , but it seems a little silly.
  513. # [20:16] * DanC noodles on a ftf meeting in late July or Aug ...
  514. # [20:17] <rburns> If &copy is in the portion of the XML in the HTML namespace, shouldn't the reference be recognized? (probably isn't required if the UA doesn't retrieve the DTD, but really).
  515. # [20:18] <DanC> for all the talk of suveying top web sites, I haven't seen much progress. have I missed something?
  516. # [20:18] <DanC> XML entities have nothing to do with namespaces, currently.
  517. # [20:19] <Philip`> rburns: I wasn't retrieving the DTD - just passing the document to Python's minidom, which seems to use Expat and ignores DTDs
  518. # [20:20] <anne> XML should just gain a bunch of HTML entities
  519. # [20:20] <anne> and get decent error handling
  520. # [20:20] <gsnedders> users. don't. like. parse. errors.
  521. # [20:20] <Philip`> XML needs a much bigger version number too
  522. # [20:20] <rburns> DanC, yeah when I think about it I realize that they're not, but that's seems like an oversight of the xml namespace / xml recommendations
  523. # [20:20] <anne> Philip`, :)
  524. # [20:21] <DanC> users don't like parse errors in somebody *else's* content. but authors like good diagnostics.
  525. # [20:21] <DanC> if I wrote <b><i>..</b></i>, I want my computer to tell me asap. (I love nxml-mode)
  526. # [20:22] <rburns> Its these character reference entity parse errors that are much more frustrating to authors than genuine well-formedness errors.
  527. # [20:22] <anne> http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/#test_non_text_alternatives_1 seems also broken
  528. # [20:23] <rburns> No, I think there they're saying that non-semantic images should be added through CSS. All others should have an alt attribute with a meaningful description.
  529. # [20:24] <rburns> or am I misunderstanding what you're flagging?
  530. # [20:25] <anne> sometimes an image is just there it illustrate what the content already tells you
  531. # [20:26] <anne> alt=something wouldn't help there
  532. # [20:27] <oedipus> if an image is needed to illustrate a concept, there MUST be a textual equivalent
  533. # [20:28] <anne> I'm not saying it's needed
  534. # [20:28] <rburns> yeah, they acknowledge the problem of automagically testing for meaning. However, even if the image is described in detail in the surrounding prose, the alt should at least mention that, otherwise the reader will assume they're missing something in that image.
  535. # [20:28] <hsivonen> does real AT support SVG <desc> these days?
  536. # [20:28] <anne> do they support SVG at all?
  537. # [20:29] <oedipus> a lot can be conveyed by describing Lord Cornwallis' portrait that isn't covered by "Portrait fo Lord Cornwallis" -- how he is dressed, the setting, the objects in view all add detail to the portrait (that's what longdesc is for!)
  538. # [20:29] <anne> rburns, isn't that what alt="" is for?
  539. # [20:29] <anne> oedipus, thinking that people will use longdesc for Flickr for instance seems unreastic
  540. # [20:29] <oedipus> i have not been able to find a screen-reader that supports SVG, although the DAISY consortium is working on a CDF to integrate SVG illustrations into Digital Talking Books
  541. # [20:30] <rburns> No, I think it would need to be something more like alt="this image portrays the blah blah blah described previously"
  542. # [20:30] <billmason> Anyone using a screen reader would not thank you for that.
  543. # [20:31] <rburns> alt="" would say to me that the author through that in there to stop the nagging from the vvalidator
  544. # [20:31] <oedipus> i don't care what's on flicker (sp?) - it's when i'm trying to ascertain if, after 20 years, i remember the design, for example of a particular counrty's flag
  545. # [20:32] * Joins: michelegera (michele@87.2.174.154)
  546. # [20:32] <oedipus> to billmason - the key is enduser control - either follow a link to the longdesc, or choose to have it rendered in place of the image; plus with aural CSS, the end user can override any settings set by a (usually sighted) author
  547. # [20:33] <billmason> My response was to rburns, not to longdesc.
  548. # [20:33] <oedipus> sorry bill
  549. # [20:33] <rburns> anne, searching for images requires elaborate descriptive text. So someone on flickr (especially as the library grows) will need to describe the image to find it and for others to find it. flickr (and other tools) need to make the task easier to help all consumers of images.
  550. # [20:34] <rburns> billmason were you referring to the blah blah blah (thas was just a placeholder since its a hypothetical example and I didn't know what to say to describe it)
  551. # [20:34] <anne> that's not the only way to enable searching of images or multimedia content for that matter
  552. # [20:34] <anne> and as I said, it's unrealistic
  553. # [20:34] <hsivonen> DanC: http://krijnhoetmer.nl/irc-logs/whatwg/20070607#l-339
  554. # [20:34] <rburns> no, its not the only way, but its one of the better ways these days
  555. # [20:34] <billmason> No, I was referring to the entire alt value you were proposing.
  556. # [20:35] <rburns> billmason, ok
  557. # [20:36] <anne> it's not the better way
  558. # [20:36] <anne> it requires years of work to describe all photos on flickr
  559. # [20:36] <oedipus> i need to put some of my photos from "did i leave the lens cap on again?" http://my.opera.com/oedipus/albums/ up on flicker and hear what happens - this is a longtime pet project of mine (http://my.opera.com/oedipus/blog/my-fifteen-minutes-of-fame) where i asked a community to describe photos i had taken
  560. # [20:38] <DanC> hsivonen, the <div>test<p>test</p></div> changed is justified by "my[Hixies'] impression that the allowing of mixed inline and block content at the same level was a bug in HTML4"? Then there's no reason not to undo it.
  561. # [20:38] <oedipus> i want to build a library of iconic images and have them described in a 2 field form: the first would be a terse description (for ALT text), the second would be an unlimited TEXTAREA - the name of the project is "Is a Picture Worth A Thousand Words?"
  562. # [20:38] <Hixie> DanC: well, the question is, what does it mean? it really seems very wrong to me to have inline and block content as siblings.
  563. # [20:38] <Hixie> DanC: everything in the design of html seems counter to this concept.
  564. # [20:39] <DanC> <div>test<p>test</p></div> means a div element containing a bit of text and a p element.
  565. # [20:39] <Hixie> what's the bit of text? a header? a paragraph?
  566. # [20:39] <DanC> it's a bit of text.
  567. # [20:39] <Hixie> that doesn't cut it for me
  568. # [20:39] <Hixie> i don't know what to do with that
  569. # [20:40] * hsivonen waits for this hit the semantic fan on the mailing list
  570. # [20:40] <rburns> there aren't too many places that allow it in HTML 4: td, th, li, dd, div. Any others?
  571. # [20:40] <Hixie> <div> means that anywhere allows it, basically
  572. # [20:40] <anne> Hixie, implied paragraph?
  573. # [20:40] <oedipus> in regards allowing mixed inline and block content, would it apply - in your opinion - to a single QUOTE element, as i've outlined on public-html?
  574. # [20:40] <DanC> do in what sense? why do you have to do anything? the software and the people have consensus on what it means. the spec has no good reason to say otherwise.
  575. # [20:40] <Hixie> if it's an _implied_ paragraph, then we should imply a <p> around it
  576. # [20:40] <Hixie> DanC: i don't understand what "a bit of text" means
  577. # [20:40] <anne> and break content?
  578. # [20:41] <Hixie> anne: right, so we can't do that
  579. # [20:41] * anne meant it in the "semantic" sense
  580. # [20:41] <oedipus> what is an implied paragraph - things need to be explicitly bound (have definite start and end points for all types of processing)
  581. # [20:41] <Hixie> i don't think i've ever seen inline and block content used next to each other in a legitimate way
  582. # [20:41] <anne> much like <h1><h2> the <h2> there implies a section
  583. # [20:41] <anne> we don't wrap <section> around it though
  584. # [20:42] <DanC> what seems ligitimate to one person seems pretty irrelevant, to me. "everything in the design of html" is a hodgepodge anyway.
  585. # [20:42] <oedipus> ok, anne and ian, then i'll settle for a reformed and strengthened Q element, with a for/id association with the CITE element
  586. # [20:42] <Hixie> anne: i honestly don't think that it _is_ an implied paragraph, though
  587. # [20:42] <Hixie> oedipus: see the spec, we've already done that
  588. # [20:42] <Hixie> or maybe we've only done it for <blockquote>, i forget
  589. # [20:42] <anne> i think for both, but without the need for for/id
  590. # [20:43] <oedipus> i noticed implied fieldsets and no FIELDSET element - that is dangerous
  591. # [20:43] <DanC> I tried introducing this constraint in HTML 2; couldn't justify it; took it out. It got added back into XHTML strict, but I'm not sure there's much value in it.
  592. # [20:43] <DanC> maybe an uber-pedantic HTML5 subset could rule it out, but I see little grounds.
  593. # [20:44] <anne> Hixie, don't you need to define the meaning anyway if content does it?
  594. # [20:44] <Hixie> DanC: well, certainly we can review use cases and so on, but i haven't seen any use cases for inline and block content to ever be siblings
  595. # [20:44] <Hixie> anne: the meaning can be "this makes no sense" if it's non-conforming
  596. # [20:44] <DanC> the best argument I've seen is "it complicates implementation of direct-manipulation editors". If that claim is backed by some research, that would be more interesting.
  597. # [20:44] <DanC> my homepage is a usecase. I've got an <li> with some text and then a <div>
  598. # [20:44] <oedipus> the for/id model can be used to reuse abbreviations, though - optimally through reference to an external expansions document, so that - like a sitewide stylesheet - it can be appended once and reused anywhere else on the site; abbreviations, though, do need for/id associations for reuse purposes
  599. # [20:45] <anne> oedipus, they have that implicitly in HTML5
  600. # [20:45] <anne> oedipus, as well
  601. # [20:47] <oedipus> sorry, anne - hard to keep up and listen to myself type and my screen reader spit back audio at me - to what were you referring re: implicitly in HTML5?
  602. # [20:47] <Hixie> DanC: uri?
  603. # [20:47] <Sander> Hixie: <div><img><p></p></div>? Or <h2><img>? Or... (etc). That's a pretty common pattern out there.
  604. # [20:47] * Joins: mjs (mjs@17.255.104.72)
  605. # [20:47] <anne> oedipus, HTML5 defines implicit association for <abbr> so you can reuse it within the same page
  606. # [20:47] <Sander> <h2></h2><img> even
  607. # [20:47] <Hixie> Sander: that's exactly the kind of thing we want to avoid -- the <img>, when replaced as text, is a paragraph.
  608. # [20:48] <DanC> sorry, my homepage is http://www.w3.org/People/Connolly/ (uri was given before you tuned in)
  609. # [20:49] <Hixie> DanC: i do not consider that markup to be legitimate. I think what you have there is a list item with two paragraphs. I don't even know how to describe what you have now, given that <div> doesn't have any meaning.
  610. # [20:49] * Quits: dbaron (dbaron@63.245.220.242) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  611. # [20:49] * Joins: dbaron (dbaron@63.245.220.242)
  612. # [20:49] <Sander> Ah, I see your point. But can you really say that the alternate text for a logo image, or an icon, or things like that, is a "paragraph"?
  613. # [20:49] <Hixie> DanC: in fact it looks very much like you're using the <div> to mean "line break"
  614. # [20:49] <Hixie> which is completely bogus imho
  615. # [20:50] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
  616. # [20:50] <Hixie> Sander: if it's presentational it shouldn't be an <img>.
  617. # [20:50] <Sander> I consider a logo - at least - to be content.
  618. # [20:50] <Hixie> Sander: do you have a sample page showing what you mean? I'm not really following well.
  619. # [20:50] <DanC> I'm using <div> to mean "a little block of stuff on its own"
  620. # [20:51] <DanC> paragraphs are made of sentences and such. none of the stuff in my travel schedule is paragraphs
  621. # [20:52] <Hixie> DanC: in fact imho your whole thing isn't an <ol>. It should be a <dl> with multiple <dd>s, or a <dl> with <dd>s containing <p>s followed by <aside>s.
  622. # [20:52] <Hixie> imho.
  623. # [20:52] <DanC> I get conflicting advice on whether to use dl or ol for schedules like this. Are we really expected to bake the aesthetic judgements of one person into the HTML 5 standard?
  624. # [20:53] <Hixie> if we want to make html interoperably interpretable, yes, we need a clear definition.
  625. # [20:53] * Hixie notes that he included <div> in the spec against his better judgement and only really considers it to be valid as an escape hatch when there really isn't anything better in HTML.
  626. # [20:53] <DanC> in what way is interoperability at risk with <li>text<div>...</div></li>?
  627. # [20:54] <Hixie> we haven't defined what that means.
  628. # [20:54] <Hixie> and i don't see any sane definition.
  629. # [20:54] <DanC> we have to the satisfaction of all concerned.
  630. # [20:54] * Joins: hyatt (hyatt@17.255.105.178)
  631. # [20:54] <Hixie> clearly not to the satisfaction of all concerned :-)
  632. # [20:55] <DanC> lots of software groks, and lots of authors use it, and they agree. what's the problem?
  633. # [20:55] * hsivonen finds it amusing if the hard-core semanticists accept <li>text<div>...</div></li> but not <i>text</i>
  634. # [20:55] <Hixie> i've already explained the problem several times
  635. # [20:55] <rburns> HTML5 would allow <li>text<div>...</div></li>, but its not any clearer what meaning that conveys
  636. # [20:55] * Joins: gavin (gavin@74.103.208.221)
  637. # [20:56] <Hixie> what rburns said
  638. # [20:56] <DanC> well, your explanation of the problem is "it's unaesthetic"
  639. # [20:56] <zcorpan> define it as being equivalent to <li><div>text</div><div>...</div></li>
  640. # [20:56] <rburns> I meant to change it to: <li>text<span>...</span></li>?
  641. # [20:57] <Hixie> zcorpan: that doesn't really help much :-)
  642. # [20:57] <hsivonen> zcorpan++
  643. # [20:57] <DanC> if you just take the constraint out of the spec, the spec stands just as well, and better. there's no reason to explain the specific case of <li>text<div>...</div></li> ; it gets its meaning from <li> and <div> and other parts of the spec.
  644. # [20:57] <rburns> HTML5 allows that, but its not any clearer what that means than what DanC is using
  645. # [20:57] <oedipus> one means of associating a diagram with detailed information containing equivalent text, there is use for <DIV><P></P><IMG></DIV> - especially when one cannot add a longdescription (or doesn't want to); making the DIV a visible box will help tie together the description and the photo (low vision users switching between the two, people with spacial relationship disabilities) - for a stronger visual and accessible binding, the DIV can be made a visible contai
  646. # [20:57] <zcorpan> Hixie: then i don't see the problem really, since the latter is conforming
  647. # [20:57] <Hixie> rburns: <li> text <span>...</span> </li> is exactly equivalent, per spec, to <li> text ... </li>
  648. # [20:58] * Quits: hyatt (hyatt@17.255.105.178) (Quit: hyatt)
  649. # [20:58] <hsivonen> oedipus: that's what <figure> is for
  650. # [20:58] <oedipus> that WAI-ARIA syntax is: <div class-"caption-and-img" aaa:labelledby="#img1"><p aaa:owns="#img1"></p><p><img id="img1" alt="xxx" src="accessibleelement"></p>
  651. # [20:58] <Hixie> DanC: imho that markup is bogus. it doesn't convey the meaning you are trying to convey, and the spec has multiple features that allow you to convey the right meaning. having the spec support your bogus markup doesn't help anything.
  652. # [20:58] <hsivonen> oedipus: that's awful compared to <figure>
  653. # [20:58] <oedipus> it's backwards compatible...
  654. # [20:59] <DanC> I don't see the relevance of your opinion, given, the level of deployment of the idiom.
  655. # [20:59] <DanC> having the spec support this idiom increases the consistency between the spec and the web.
  656. # [21:00] <Hixie> changing what is conforming doesn't affect legacy content
  657. # [21:00] <Hixie> the spec defines how to handle that case
  658. # [21:00] <Hixie> it just doesn't condone it
  659. # [21:00] * Quits: zcorpan (zcorpan@84.216.41.183) (Ping timeout)
  660. # [21:01] <DanC> let's try another take... what should a document checking tool say to me when I write <li>text<div>text2</div></li>?
  661. # [21:01] * Joins: zcorpan (zcorpan@84.216.43.3)
  662. # [21:01] <DanC> i.e. what's some helpful advice? if it's considered less-than-fully-conforming, what's a useful diagnostic?
  663. # [21:03] <Sander> Hixie: unsuccessful at finding a sample page; trying to construct something which holds together, I keep realizing it's either a list, or the image is part of the paragraph, or something else which means that you're right and the image shouldn't be a sibling of block-level content. I still feel there might be cases where this doesn't hold, but for the moment you've convinced me.
  664. # [21:03] <oedipus> hsivonen: there is a world of difference between a caption alt-text and a long description; why is LONGDESC not part of HTML5, then? the average user wants to know, as quickly as possible what is being illustrated, so that they can make an educated decision to get more information from a LONGDESC - it's a question of granularity
  665. # [21:03] <Hixie> DanC: "The meaning of this list item's contents are ambiguous. Consider wrapping the inline content ("text") with an appropriate block-level element such as <p>. Consider replacing the <div> with more a appropriate element such as <section> or <aside>."
  666. # [21:04] <Hixie> Sander: :-)
  667. # [21:04] <DanC> if I replaced <div> with <aside>, wouldn't the constraint still be violated?
  668. # [21:05] <DanC> I think we disagree on when <p> is appropriate. Encouraging people to use <p> for things other than complete thoughts written out in sentences is pernicious.
  669. # [21:05] <Hixie> (looking more closely, the <br> there is bogus too)
  670. # [21:06] <DanC> hmm.... really? the br is probably there because I haven't really learned CSS, but I'm not sure; care to teach me?
  671. # [21:06] <anne> oedipus, it requires too much from authors to do it correctly and they're not using it
  672. # [21:06] <Hixie> DanC: I would say the correct markup of the <li> would, ignoring the inline elements for ease of typing here, be <li> <p> May 30-Jun 1 to Mountain View CA for TAG meeting </p> <nav> <a> trip stuff </a> </nav> </li>
  673. # [21:07] <Hixie> DanC: or something along those lines
  674. # [21:07] <DanC> you really think a <p> is appropriate? I don't think that's a paragraph.
  675. # [21:07] <Hixie> a paragraph is typically a block of text with one or more sentences that discuss a particular topic, as in typography, but can also be used for more general thematic grouping
  676. # [21:07] <Hixie> (according to both the html5 spec and the dictionary)
  677. # [21:08] <oedipus> anne: i'm using it, and for reading a book on the web, such as jakob riis' "how the other half lives" is MEANINGLESS without detailed description of the photographs
  678. # [21:08] <DanC> doesn't the <li> serve as a the thematic grouping here?
  679. # [21:08] <Hixie> yes, but you have subgroups within the <li>
  680. # [21:08] <Hixie> you are separating the event data with links about the event data
  681. # [21:08] <Hixie> thus, two subgroups
  682. # [21:10] <oedipus> How the Other Half Lives: http://www.cis.yale.edu/amstud/inforev/riis/title.html
  683. # [21:10] * Joins: briansuda (briansuda@82.221.34.106)
  684. # [21:10] <oedipus> Illustrations contained in How the Other Half Lives: http://www.cis.yale.edu/amstud/inforev/riis/illustrations.html
  685. # [21:11] <oedipus> online courses and educational materails DEMAND longdescs (and i do know a handful of professors who do use them)
  686. # [21:11] <DanC> hmm... I see the slug in <li>slug <p>desc</p></li> as analagous to the bit of text beneath one heading and above the subheading.
  687. # [21:12] * oedipus when i capitalize i'm not shouting - it's the only formatting that doesn't keep my screen reader from reading "underline" or "asterisk" only, without the accented word
  688. # [21:12] <anne> oedipus, :)
  689. # [21:12] <anne> oedipus, would <object> extensive fallback </object> not help?
  690. # [21:13] <oedipus> i have added emoticons to my screen reader's dictionary
  691. # [21:13] <anne> I suppose longdesc could be added if there's enough demand for it. I suppose it hasn't been considered much yet.
  692. # [21:13] <anne> much like headers=
  693. # [21:14] <Hixie> DanC: ...which is a <p> :-) (typically inside a <header> if it's a subheading as opposed to a heading of a subsection, if you see what i mean)
  694. # [21:14] <oedipus> i am constructing a case for and against LONGDESC which i hope to have up on the wiki today (fingers crossed)
  695. # [21:14] * Quits: gsnedders (gsnedders@86.139.123.225) (Quit: Don't touch /dev/null…)
  696. # [21:14] <anne> oedipus, cool
  697. # [21:14] * Quits: rburns (robburns@208.54.95.1) (Connection reset by peer)
  698. # [21:16] * Joins: rburns (robburns@208.54.95.1)
  699. # [21:16] <rburns> I think for the sake of backwards compatibility we should be careful about removing things that are in HTML4. Adding semantic expression is not too troubling (like aside header and footer), but removing semantic expression (without cause) is a bad thing (like @headers, @summary and @longdesc),.
  700. # [21:16] <anne> http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/#test_style_sheets_use is also problematic given HTML5 as currently specced
  701. # [21:16] <DanC> well, I can see your position, but I'm not convinced. I think <li>slug<p>more</p></li> is just fine. It's widly used and supported, with no interop issues. There's no hold left in the spec if you delete the constraint.
  702. # [21:16] <DanC> hole
  703. # [21:16] <anne> rburns, we should only add things with clear use cases
  704. # [21:16] <oedipus> i'm also working on a wiki page for retention of the summary attribute
  705. # [21:17] <rburns> anne, I'm more speaking to the removal of things
  706. # [21:17] <Hixie> rburns: we're not removing anything from the implementation requirements. we are, however, making the language simpler where the extra complexity isn't a distinct win.
  707. # [21:17] <anne> rburns, HTML5 started with a clean slate
  708. # [21:17] <zcorpan> oedipus: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-June/006669.html
  709. # [21:18] <rburns> anne, nothing starts a clean slate. And my understanding is that backwards compatibility is a goal for the spec
  710. # [21:18] <Hixie> DanC: i understand that you think it's fine. i think it's ambiguous, i don't understand how to write the part of the spec that would define what it means, and i think there are significantly better ways of writing that kind of markup.
  711. # [21:18] <anne> rburns, with the web and implementations, yes
  712. # [21:18] <anne> rburns, not so much with conformance
  713. # [21:18] <DanC> which part of the spec would you have trouble writing?
  714. # [21:18] <anne> (mostly the web actually)
  715. # [21:19] <anne> rburns, or HTML4
  716. # [21:19] <Hixie> DanC: the part that defines what the meaning of markup that has mixed inline and block content is
  717. # [21:19] <zcorpan> Hixie: what would authors gain by changing <img><p> to <p><img><p>? they have to do it if they want to switch to conforming html5, and i don't see what the win is
  718. # [21:19] <DanC> care to help me find that part?
  719. # [21:20] <DanC> oops; I read too fast.
  720. # [21:20] <Hixie> DanC: that part isn't there now, because the mixing of inline and block isn't allowed.
  721. # [21:20] <DanC> why would the spec need to define the meaning of that combination specially?
  722. # [21:21] <DanC> if you just delete the constraint, why is the spec not OK?
  723. # [21:21] <oedipus> anne: i think there is an equal need for a longdescriptor for both figures and embedded objects - the problem with the HTML5 WG's spec is that it is hard to determine precisely what element is being discussed - i would expect before hearing "contexts in which this element may be used" to hear (or, if i could, see or feel) the name of the element being addressed
  724. # [21:21] <Hixie> zcorpan: it's basically the same win as not having <b> <i> </b> </i> -- ease of maintanence, unambiguous conveyance of the intended meaning, and so forth.
  725. # [21:21] <anne> oedipus, the name of the element should be mentioned before that, it's part of the section heading
  726. # [21:21] <Hixie> DanC: the spec has to define the meaning of what it allows.
  727. # [21:22] <DanC> <p><label>Address: <textarea name="a"></textarea></label></p> is bogus. that's not a paragraph.
  728. # [21:23] <Hixie> how is it not a paragraph?
  729. # [21:23] <anne> If both inline and block level are within a single parent the meaning is identical when the inline level content would be wrapped in a <div>
  730. # [21:23] <zcorpan> anne: yeah
  731. # [21:23] <Hixie> anne: which is an open issues itself
  732. # [21:23] <DanC> it's not written in sentences. it's not "A paragraph is a self-contained unit of a discourse in writing dealing with a particular point or idea, or the words of an author." -- http://en.wikipedia.org/wiki/Paragraph
  733. # [21:24] <Hixie> DanC: sure it is
  734. # [21:25] <Hixie> DanC: though if you're arguing that we should introduce a new element to separate sentence-based paragraphs as found in prose from thematic paragraphs as found in applications and dialog boxes, i suppose we could introduce such an element
  735. # [21:25] <Hixie> it would be an expensive thing to do, and i'm not sure there's any advantage to it, but it's an option
  736. # [21:25] <oedipus> anne: i have to make a text image of it using lynx - JAWS 8 can't handle the page in IE7 and FireFox, and i didn't have much more luck with FireVox
  737. # [21:25] <zcorpan> if we do that, it could be called <div> :)
  738. # [21:25] <DanC> exactly. <div>.
  739. # [21:26] <zcorpan> although i think using <p> for such uses is fine
  740. # [21:26] <DanC> I suppose I could live with a watered-down definition of <p>; it grates against me to use it in examples, though.
  741. # [21:26] <Hixie> <div> isn't that
  742. # [21:26] <Hixie> <div> is meaningless by definition
  743. # [21:26] <zcorpan> the definition isn't set in stone, is it?
  744. # [21:27] * anne likes the <p><label> stuff
  745. # [21:27] <anne> don't break it!
  746. # [21:27] <DanC> by what definition? how about changing the definitions so that <p> is a normal paragraph and <div> is a thematic grouping that isn't necessarily discourse?
  747. # [21:27] <Hixie> <div> and <span> are the extension mechanisms of HTML. We need two elements that are by definition meaningless so that people can do stuff we haven't thought of.
  748. # [21:27] <anne> <p> is much nicer because it has some default styling
  749. # [21:28] <Hixie> they are, as it were, sacred in their virginity. ;-)
  750. # [21:28] <anne> (besides display:block)
  751. # [21:29] <zcorpan> another argument for changing bimorphic to flow is that it makes the rules simpler, so easier for authors
  752. # [21:29] <DanC> wild.. <blockquote>xyz</blockquote> is also prohibited. ah. that's more of the stuff that gets old after you try to use XHTML strict for a while.
  753. # [21:29] <rburns> Hixie and DanC, I can see what you're both saying (though I can't defend your markup DanC :-)). However, I wonder whether these types of fringe cases are beyond what the spec should seek to address. That is we should try to provide clear content models; clear implementation algorithms, and expressive semantics where reasonable. We might even have a non-nomrative chapter that uses DanC's homepage as an example (where its transformed into a prettier HTML5 mark
  754. # [21:29] <Hixie> zcorpan: allowing any element anywhere makes things easier too :-)
  755. # [21:30] <anne> DanC, I think <blockquote> should allow inline level content
  756. # [21:30] <Hixie> DanC: that's a vestige of HTML4
  757. # [21:30] <oedipus> why is there nothing analagous to LONGDESC or <OBJECT> extensive fallback </object> in the media element attributes for video and audio - one might want to slash need to read a transcript (either because one can't process sound, or one has only a reading knowledge of the natural language contained in the audio
  758. # [21:30] <rburns> zcorpan, especially authors coming from an HTML4 background
  759. # [21:30] <zcorpan> we wouldn't need the structural inline concept
  760. # [21:30] <anne> DanC, basically making it switch between sectioning and paragraph level element
  761. # [21:30] <anne> people use it that way already and it makes sense
  762. # [21:30] <Hixie> rburns: i think we need to define the meaning of anything we allow, it would imho be irresponsible of us to do otherwise
  763. # [21:31] <anne> it's not much different from <p><q>....</q></p> I suppose but I don't really care about that
  764. # [21:31] <oedipus> zcorpan: thanks for the pointer
  765. # [21:31] <Hixie> i don't have a strong opinion against making blockquote imply that it is a |paragraph| if it contains inline only
  766. # [21:31] <anne> oedipus, <video> and <audio> both allow "extensive fallback" too
  767. # [21:31] <anne> Hixie, good, fix it! :)
  768. # [21:32] <oedipus> anne: thanks for clarification
  769. # [21:32] <Hixie> anne: you sent e-mail about that, no? it's on the list if so
  770. # [21:33] <DanC> that still wouln't allow <blockquote>Everything should be as simple as possible and no simpler. <address>Einstein</address></blockquote>, would it?
  771. # [21:33] <oedipus> i still think there should be only one quote element, as a quote is a quote is a quote, and there is precedent <ins><del> for an element acting both as a block and as an inline element
  772. # [21:34] <Hixie> DanC: correct. then again, that would be wrong use of <address> anyway. and wrong use of <blockquote> since einstein didn't say "einstein" after saying that.
  773. # [21:34] <rburns> Hixie, that brings up my early counter-example. How is DanC's any more ambiguous in meaning than <li> text <span>...</span> </li> is exactly equivalent, per spec, to <li> text ... </li> which is allowed by the spec. In other words we're not going to allow that as <div>, but we will allow it as <span>. But I can't tell any more clearly what it means if DanC changes <div> to <span>.
  774. # [21:34] <anne> I might have, I guess
  775. # [21:34] <Hixie> oedipus: <ins> and <del> are the poster children of why having one element be both inline and block is a bad idea. :-)
  776. # [21:35] <anne> DanC, I might be willing to volunteer for making a "working draft" out of that wiki page
  777. # [21:35] <Hixie> rburns: the problem is that <span> really introduces absolutely no semantics, whereas <div> introduces the nebulous concept of it being "a different block".
  778. # [21:35] <DanC> the diffs from html4?
  779. # [21:35] <anne> If people think such a document would help to have on TR/
  780. # [21:35] <oedipus> hixie: well, one finds precedent where one can... not my first choice of examples, either
  781. # [21:35] * Quits: michelegera (michele@87.2.174.154) (Quit: michelegera)
  782. # [21:35] <hsivonen> Hixie: for practical purposes, attribution inside blockquote is needed
  783. # [21:35] <anne> DanC, yeah
  784. # [21:35] <Hixie> rburns: whereas since there is no other block in the first place, it's not clear what "different block" means.
  785. # [21:35] * DanC wonders if mjs is around
  786. # [21:36] <Hixie> rburns: you can always remove <span> elements (that have no attributes) without making any difference to the meaning
  787. # [21:36] <DanC> I'd like a combination of diffs-from-html4 and design principles. i.e. what's changed and why, mixing in some discussion of status.
  788. # [21:36] <Hixie> rburns: but removing <div>s can change the meaning, e.g. it can merge two... "blocks"... into one sentence.
  789. # [21:37] <Hixie> oedipus: precedent that shows that something works is good. precedent that shows what a disaster teh idea can be, is a strong argument against. :-)
  790. # [21:37] <DanC> though separate design principles and diffs-from-html4 is prolly good too.
  791. # [21:37] <Hixie> hsivonen: why? (given our definition of <blockquote><p><cite>)
  792. # [21:38] <anne> styling
  793. # [21:38] <hsivonen> Hixie: typographically, you want the attribution inside the same CSS box. It is easier to write using WYSIWYG tools. and <cite> has the wrong default presentation for people.
  794. # [21:38] <DanC> I have trouble with the blockquote/cite discussion... it brings out the html2-editor in me; i.e. the guy who tried to design parts of HTML, who did at least as much harm as good.
  795. # [21:38] <hsivonen> afk
  796. # [21:38] <rburns> hixie, I would say removing <div> removes default presentation and meaning. Removing <span> removes meaning (granted under-specified meaning like <div>), but does not remove any default presentation. In both cases, the author had some meaning in mind. But I couldn't tell you what it was in either case.
  797. # [21:39] <DanC> <cite> was supposed to capture the chicago-manual-of-style idiom for titles of works. I have lost track of what it means these days.
  798. # [21:39] <anne> the guy who said it
  799. # [21:40] * anne kind of likes the <blockquote> <address> construct
  800. # [21:40] <anne> I believe mozilla.org uses that
  801. # [21:40] <zcorpan> <blockquote>Everything should be as simple as possible and no simpler. <credit>Einstein</credit></blockquote>
  802. # [21:40] <zcorpan> html 3.0
  803. # [21:40] <Hixie> rburns: i'm not really talking about the presentation here, that's an entirely separate problem.
  804. # [21:40] <Hixie> imho
  805. # [21:40] <oedipus> if you don't have <span> how can you mark a natural language switch. assuming that the natural language declared for the document is "en": Obviously, although the object portrayed in <a href="pipe.html"><span lang="fr">La trahison des images</span> (The Treachery of Images)</a> is obviously a pipe, it is not, itself a pipe, but the representation of a pipe, which is an entirely different phenomenon.
  806. # [21:40] <anne> zcorpan, what did HTML+ do?
  807. # [21:40] <Hixie> hsivonen: it is true that there are limitations in CSS that we need to fix (just ask anne about <di>)
  808. # [21:41] <zcorpan> anne: iirc html+ didn't have <credit> for <blockquote>
  809. # [21:41] <anne> Hixie, I'm still not sure if making CSS that much more complex is really worth it though
  810. # [21:42] <anne> Hixie, contrary to making some HTML constructs slightly more complex
  811. # [21:42] * oedipus skip CSS21 and go straight to CSS3 - do not pass go, do not collect $200
  812. # [21:42] <anne> (besides the fact that nobody is really working on tackling those issues)
  813. # [21:42] <rburns> oedipus, if your comment about span referred to what I was discussing, we we're talking about the use by an author of <span> and <div> with no attributes (therefore under-specified semantics).
  814. # [21:43] <DanC> use case: an excerpted quote, with attribution. Semantics have to be captured without CSS, since it's a blog article and it's going to get syndicated across stylesheets. I'd like to see an example in the html5 spec section on <blockquote>.
  815. # [21:43] <anne> write one :)
  816. # [21:44] <DanC> well, I just did, but Hixie said my <address> usage was bogus.
  817. # [21:44] <DanC> I'm hoping the channel produces some advice.
  818. # [21:44] <oedipus> rburns: thanks - can't wait until the WAI-ARIA politeness rules are implemented so that i can hear what's coming in as well as going out, so i'm often missing chunks of the conversation
  819. # [21:44] <anne> DanC, ah HTML5 says to use <blockquote><p>quote</p><p>more of that</p></blockquote><p><cite>Einstein</cite></p>
  820. # [21:44] <zcorpan> DanC: http://www.whatwg.org/specs/web-apps/current-work/multipage/section-documents0.html#nav-bar
  821. # [21:45] <DanC> <cite> is block-level?
  822. # [21:45] <zcorpan> no
  823. # [21:45] * Hixie notes that he's certainly open for better solutions to all this
  824. # [21:45] * oedipus would be using chatzilla, for which FireVox implemented WAI-ARIA roles and states, but chatzilla always crashes on me when using FireVox
  825. # [21:45] <anne> I like reusing <address> for attribution
  826. # [21:45] <Hixie> i like the <blockquote> <credit> idea
  827. # [21:46] <anne> Except that <address> doesn't work for <q>
  828. # [21:46] <Hixie> reusing <address> might work if nobody has <address> elements in <blockquote> elements already, unless they are already doing it "wrong"
  829. # [21:46] <oedipus> why <address> for attribution? why not <cite>?
  830. # [21:46] <anne> So maybe <credit> is better
  831. # [21:46] <DanC> zcorpan, what about #nav-bar?
  832. # [21:46] <anne> Hixie, mozilla.org does it "wrong"
  833. # [21:46] <zcorpan> DanC: oh, scroll down to the example
  834. # [21:47] <DanC> (URIs alone on a line are often confusing.)
  835. # [21:47] <hsivonen> Hixie: punctuation. Works for casual authors. Check out the quote at the top of http://hsivonen.iki.fi/producing-xml/
  836. # [21:47] <Hixie> anne: we'll have to do a scan to see how widespread it is, and sample some of the uses
  837. # [21:47] <zcorpan> DanC: #nav-bar is part of the uri if you click in the ToC
  838. # [21:47] <anne> Hixie, http://www.mozilla.org/contribute/writing/markup#quotations
  839. # [21:47] <zcorpan> DanC: you'll find an example of quotation
  840. # [21:47] <rburns> In addition to Tables model, cite and address are two areas I'd like to see much more guidance on from HTML5
  841. # [21:47] <Hixie> hsivonen: oh i agree there are issues here, don't get me wrong
  842. # [21:47] * Philip` doesn't like the #nav-bar links now
  843. # [21:48] <DanC> ah... you're pointing me at a quote with attribution in the html5 spec. thanks.
  844. # [21:48] <DanC> is it too late to restore <cite> to its former glory?
  845. # [21:48] <oedipus> it better not be...
  846. # [21:48] <Hixie> hsivonen: i think the real issue is holes in css, and i don't consider presentation concerns to be that important in deciding the markup structure, but the markup structure itself isn't perfect yet either.
  847. # [21:48] <zcorpan> imho... <cite> = title of work, <address> = any contact information
  848. # [21:48] <DanC> <cite> is for http://en.wikipedia.org/wiki/Quotation_mark#Titles_of_artistic_works
  849. # [21:48] * hsivonen treats <cite> as title of work
  850. # [21:48] * Hixie has to go now
  851. # [21:48] <Hixie> bbiab
  852. # [21:49] <anne> Yeah, the default style of <cite> sucks for attribution
  853. # [21:49] <anne> It's great for titles of work
  854. # [21:49] * Quits: olivier (ot@128.30.52.30) (Quit: Leaving)
  855. # [21:49] <hsivonen> afk
  856. # [21:49] <oedipus> <cite> needs to be able support Dublin Core as well as human parseable text
  857. # [21:51] <oedipus> i still maintain that <Q> needs a for/id association with <CITE> and that the attribute
  858. # [21:51] <rburns> my thought is that <cite> should also have a type attribute to indicate the type of the cite: person, book-title, article-title, etc. In this way the use of type as an element specific enumeration would be extended
  859. # [21:51] <anne> for/id is too complex
  860. # [21:51] <oedipus> "cite" should be changed to src to point at a target where the quote can be found in context
  861. # [21:52] <oedipus> where does it say that for/id is too complex?
  862. # [21:52] <oedipus> rburns: +1 on adding a "type" attribute to <CITE>
  863. # [21:52] <DanC> so... who will lead the charge by reviewing 3.8.5. The blockquote element, 3.8. Sections, and 3.9. Prose in detail?
  864. # [21:53] <rburns> oedipus, why not use the cite attribute to point to the referenced cite element id or to an isbn/issn uri?
  865. # [21:53] <zcorpan> cite="" can perhaps be dropped altogether. use <a href> inside <credit> instead
  866. # [21:54] <oedipus> rburns: that's something i've been thinking, but just couldn't articulate
  867. # [21:55] <DanC> hmm... 3 volunteers to do detailed reviews so far... http://www.w3.org/2002/09/wbs/40318/tasks83/results#xwhichsec
  868. # [21:56] <oedipus> <Q for="c12" src="../lincoln.html#p3s2"><!-- quote from Lincoln --></Q> points to <CITE type="bibliographic" id="c12"></CITE>
  869. # [21:57] <oedipus> DanC: i have apparently very unorthodox views on Q and BLOCKQUOTE, but i did make an argument for combining the 2 into a single QUOTE element, as well as arguments against BLOCKQUOTE, so i don't know if you want me to review BLOCKQUOTE
  870. # [21:58] <rburns> oedipus I think that example works well (bibliographic type is good too, though perhaps it requires even a new element).
  871. # [22:00] <anne> HTML should not go into that much detail I think
  872. # [22:00] <DanC> if by saying "I have unorthodox views on Q and BLOCKQUOTE" you mean that a review by you of the BLOCKQUOTE section would not emphasize the deployed/implemented understanding of HTML, then indeed, such a review is less useful to the group, I think, than one based on more emperically-backed views.
  873. # [22:00] <rburns> DanC, I think of the prose as the meat of the recommendation. I don't think unorthodox is necessarily a problem. an unorthodox reading is more likely to draw out latent issues with the current draft.
  874. # [22:02] <DanC> indeed, it's not necessarily a problem
  875. # [22:03] * Quits: mjs (mjs@17.255.104.72) (Quit: mjs)
  876. # [22:03] <oedipus> DanC: judge for yoursef: BLOCKQUOTE deprecation: http://lists.w3.org/Archives/Public/public-html/2007Apr/0102.html ; preserving and strenghening Q: http://lists.w3.org/Archives/Public/public-html/2007Apr/0066.html
  877. # [22:03] * Joins: inimino (inimino@75.71.88.233)
  878. # [22:04] <oedipus> in any event, i will make my reaction to the review on list and on wiki
  879. # [22:04] <anne> deprecating elements is not useful
  880. # [22:05] * Joins: mjs (mjs@17.255.104.72)
  881. # [22:05] <rburns> anne, I don't think oedipus' example is that much detail. This is a basic construct that anyone writing an academic paper must include (though it can be done independent of the presentation details). Every quotation or paraphrasing is expected to credit the creator of the idea and to point to a source and specific page numbers where it could be found. Since HTML hasn't provided clear guidance on this in the past, every author is left to develop their own ad
  882. # [22:05] <anne> we should either not have them in the language (but have them as UA conformance criteria) or have them in the language
  883. # [22:06] * Quits: Chris (cwilso@131.107.0.105) (Ping timeout)
  884. # [22:07] * Quits: mjs (mjs@17.255.104.72) (Quit: mjs)
  885. # [22:08] <oedipus> rburns: i have heard this complaint from innumerable academics
  886. # [22:09] <oedipus> by which i mean, a standard way to insert or point to or identify a citation according to the rules their academy slash language slash cultural conventions slash manual of style
  887. # [22:11] * Joins: mjs (mjs@17.255.104.72)
  888. # [22:15] <rburns> yes, to me it seems like a major oversight for a document language (my first sentence above was supposed to say "anne, I don't think oedipus example is NOT that much detail").
  889. # [22:15] <oedipus> rburns & anne: what about this formulation: <Q for="c12" src="../lincoln.html#p3s2"><!-- quote from Lincoln --></Q> <!-- points to --> <CITE type=:"bibliographic" id="c12" src="dcoreinfo-al.rdf"> <!-- bibliographic information --></CITE> note that, in the CITE element, the src attribute to point to a structured external reference resource (such as dublin core, etc.)
  890. # [22:15] <anne> it's not extensive document language by any means
  891. # [22:16] <anne> it's supposed to cover the 80% scenarios (from all that you encounter on the web)
  892. # [22:17] <oedipus> it is, more and more - educational institutions are relying on computers and intranets to facillitate remote slash distance learning (more profit for less expense) from pre-school through university
  893. # [22:17] * zcorpan wonders whether <q> is worth keeping at all (the replacement being quotation characters)
  894. # [22:18] * anne sort of concurs with zcorpan
  895. # [22:18] <oedipus> speaking as a speech-only user, &#34; conveys nothing to me or to my AT - a quote needs to be capable of being styled - aurally, so it is differentiatable from the rest of the text, easily identifiable, and ACTIONABLE
  896. # [22:19] * Sander would be sad to see it go, since he uses it every other month or so
  897. # [22:19] * anne uses it every other month or so too
  898. # [22:19] * anne has yet to see tanginble benefits
  899. # [22:21] <anne> DanC, let me know if the idea to publish something the "differences from HTML4" will go through
  900. # [22:22] * anne has to go
  901. # [22:22] <oedipus> the way to use emphatic quotes is with CSS: <style>@media screen { em.air-quote:before (content="open-quote") em.air-quote:after (content-"close-quote")</style> <!-- --> that's a <em class="air-quote">really</em> good idea, oedipus!
  902. # [22:23] * Joins: hyatt (hyatt@17.255.105.178)
  903. # [22:23] <oedipus> the way to use emphatic quotes is with CSS: <style>@media screen { em.air-quote:before {content="open-quote"} em.air-quote:after { content="close-quote" } }</style> <!-- --> that's a <em class="air-quote">really</em> good idea, oedipus!
  904. # [22:24] <oedipus> i can also define @media aural or @media speech rules to em.air-quote, such as change in pitch, change in voice, change in voice characteristics, play an earcon, etc.
  905. # [22:26] <DanC> will do, anne. thanks.
  906. # [22:26] <oedipus> Q should be reserved for quotations, and not used as emphasis or to denote irony - you can achieve the desired result using CSS
  907. # [22:27] * Quits: hasather (hasather@81.235.209.174) (Ping timeout)
  908. # [22:28] <oedipus> which is why a <DIALOG> element is useful - when you are writing a work of fiction, you're not quoting your characters, they are speaking
  909. # [22:30] * Quits: rburns (robburns@208.54.95.1) (Connection reset by peer)
  910. # [22:30] * Joins: rburns (robburns@208.54.95.1)
  911. # [22:31] <rburns> I have to go too. I will add my name to review some of the sections (3.8 and 3.9 and 9) probably for the end of the month. Talk to you all gain. rburns out.
  912. # [22:32] <oedipus> good to speak with you rburns - "see" you on list
  913. # [22:32] * Quits: rburns (robburns@208.54.95.1) (Quit: rburns)
  914. # [22:34] <oedipus> i too, need to part, in part to work on the Retention of Summary wiki page and on a for/id binding between Q slash BLOCKQUOTE and CITE (quotes would point to CITE, CITE would have a type element and a src element to link to an external resource, such as a dublin core representation of the work being cited
  915. # [22:34] * Joins: gsnedders (gsnedders@86.139.123.225)
  916. # [22:35] * oedipus aloha, everyone
  917. # [22:35] * Parts: oedipus (oedipus@71.250.74.215)
  918. # [22:35] * Quits: briansuda (briansuda@82.221.34.106) (Quit: briansuda)
  919. # [22:39] * Quits: hyatt (hyatt@17.255.105.178) (Quit: hyatt)
  920. # [22:39] * Quits: mjs (mjs@17.255.104.72) (Quit: mjs)
  921. # [22:40] * Joins: mjs (mjs@17.255.104.72)
  922. # [22:40] * Quits: mjs (mjs@17.255.104.72) (Quit: mjs)
  923. # [22:58] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
  924. # [23:03] * Joins: gavin (gavin@74.103.208.221)
  925. # [23:11] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
  926. # [23:12] * Joins: schepers (schepers@84.73.168.194)
  927. # [23:44] * Joins: briansuda (briansuda@82.221.34.106)
  928. # [23:44] * Quits: heycam (cam@203.214.95.190) (Ping timeout)
  929. # [23:45] * Joins: hyatt (hyatt@17.255.105.178)
  930. # [23:46] * Joins: hasather (hasather@81.235.209.174)
  931. # [23:48] * Joins: rburns (robburns@71.57.116.81)
  932. # Session Close: Fri Jun 08 00:00:00 2007

The end :)