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

Options:

  1. # Session Start: Tue Nov 27 00:00:00 2007
  2. # Session Ident: #html-wg
  3. # [08:12] * Attempting to rejoin channel #html-wg
  4. # [08:12] * Rejoined channel #html-wg
  5. # [08:12] * Topic is 'HTML WG teleconference 2007-11-16T17:00:00Z http://www.w3.org/html/wg/tracker/agenda (logs: http://krijnhoetmer.nl/irc-logs/ ) '
  6. # [08:12] * Set by DanC on Fri Nov 16 17:27:44
  7. # [08:32] <anne> lol, I just got an angry e-mail from Dean Edridge about my anti-XHTML conspiracy
  8. # [08:32] <anne> apparently I forgot to address feedback on HTML Design Principles he privately e-mailed to Maciej, duh
  9. # [08:33] <mjs> anne: I didn't know he privately emailed me design principles feedback
  10. # [08:35] * Quits: heycam (cam@203.217.79.225) (Connection reset by peer)
  11. # [08:36] <anne> I'd love to quote from the e-mail, but that would be bad
  12. # [08:40] <MikeSmith> anne - aye
  13. # [08:40] <MikeSmith> definitely right to resist that temptation
  14. # [08:41] <anne> MikeSmith, your release quote never made it into any IRC logs btw
  15. # [08:42] <MikeSmith> I don't understand why Dean decided to send comments on the document in private e-mail
  16. # [08:42] <MikeSmith> anne - release quote?
  17. # [08:43] <anne> HTML Design Principles on the W3C homepage
  18. # [08:44] <MikeSmith> I see
  19. # [08:45] <MikeSmith> some problem with Krijn's logger the last couple of days?
  20. # [08:45] <anne> yeah, krijnh wasn't here :)
  21. # [08:45] <MikeSmith> ah
  22. # [08:45] <MikeSmith> oh well
  23. # [08:46] <MikeSmith> anyway, I'll send an announcement out to public-html-announce later today
  24. # [08:46] <mjs> anne: oh, Dean did send me a private suggestion, I guess I just didn't have time to deal with it (was sent Oct 30)
  25. # [08:47] <mjs> anne: at least, that's what I'll say to deny my involvement in the anti-XHTML conspiracy
  26. # [08:47] <mjs> (death to slashes and double quotes!!!)
  27. # [08:48] <anne> without slashes you'd get a flattened tree, that's pretty awkward :p
  28. # [08:49] <mjs> (death to unnecessary slashes and double quotes!!!)
  29. # [08:50] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
  30. # [08:53] * Joins: kingryan (kingryan@66.92.2.56)
  31. # [08:53] * Quits: kingryan (kingryan@66.92.2.56) (Quit: kingryan)
  32. # [09:07] * Quits: trackbot-ng (trackbot-n@128.30.52.30) (Client exited)
  33. # [09:14] * Joins: trackbot-ng (trackbot-n@128.30.52.30)
  34. # [09:14] * trackbot-ng is loading HTML Issue Tracking data...
  35. # [09:14] * trackbot-ng found 15 users
  36. # [09:14] <trackbot-ng> Tracking ISSUEs and ACTIONs from http://www.w3.org/html/wg/tracker/
  37. # [09:38] * Joins: zcorpan (zcorpan@88.131.66.80)
  38. # [09:40] * Quits: trackbot-ng (trackbot-n@128.30.52.30) (Client exited)
  39. # [09:42] <hsivonen> hmm. smedero hit the confusing issue of input type=hidden being allowed in more places than other inputs
  40. # [09:44] * Joins: trackbot-ng (trackbot-n@128.30.52.30)
  41. # [09:44] * trackbot-ng is loading HTML Issue Tracking data...
  42. # [09:44] * trackbot-ng found 15 users
  43. # [09:44] <trackbot-ng> Tracking ISSUEs and ACTIONs from http://www.w3.org/html/wg/tracker/
  44. # [09:45] * Quits: trackbot-ng (trackbot-n@128.30.52.30) (Client exited)
  45. # [09:46] <anne> hsivonen, that error message should probably say: "Only input type hidden allowed here." or something
  46. # [09:46] <anne> hsivonen, actually, I think you should make <form> either block or inline level
  47. # [09:47] <anne> requiring <form><p> seems like overhead to me for simple search forms etc.
  48. # [09:48] <anne> I think we should do that for <blockquote>, <div>, etc. too
  49. # [09:50] * Joins: trackbot-ng (trackbot-n@128.30.52.30)
  50. # [09:50] * trackbot-ng is loading HTML Issue Tracking data...
  51. # [09:50] * trackbot-ng found 15 users
  52. # [09:50] <trackbot-ng> Tracking ISSUEs and ACTIONs from http://www.w3.org/html/wg/tracker/
  53. # [09:53] * Quits: trackbot-ng (trackbot-n@128.30.52.30) (Client exited)
  54. # [09:57] * Joins: trackbot-ng (trackbot-n@128.30.52.30)
  55. # [09:57] * trackbot-ng is loading HTML Issue Tracking data...
  56. # [09:57] * trackbot-ng found 15 users
  57. # [09:57] <trackbot-ng> Tracking ISSUEs and ACTIONs from http://www.w3.org/html/wg/tracker/
  58. # [09:58] * Quits: trackbot-ng (trackbot-n@128.30.52.30) (Client exited)
  59. # [10:02] * Joins: trackbot-ng (trackbot-n@128.30.52.30)
  60. # [10:02] * trackbot-ng is loading HTML Issue Tracking data...
  61. # [10:02] * trackbot-ng found 15 users
  62. # [10:02] <trackbot-ng> Tracking ISSUEs and ACTIONs from http://www.w3.org/html/wg/tracker/
  63. # [10:04] * Quits: trackbot-ng (trackbot-n@128.30.52.30) (Client exited)
  64. # [10:04] <hsivonen> anne: unfortunately that's not the way the RELAX NG back end works
  65. # [10:09] * Joins: trackbot-ng (trackbot-n@128.30.52.30)
  66. # [10:09] * trackbot-ng is loading HTML Issue Tracking data...
  67. # [10:09] * trackbot-ng found 15 users
  68. # [10:09] <trackbot-ng> Tracking ISSUEs and ACTIONs from http://www.w3.org/html/wg/tracker/
  69. # [10:11] * Quits: trackbot-ng (trackbot-n@128.30.52.30) (Client exited)
  70. # [10:16] * Joins: trackbot-ng (trackbot-n@128.30.52.30)
  71. # [10:16] * trackbot-ng is loading HTML Issue Tracking data...
  72. # [10:16] * trackbot-ng found 15 users
  73. # [10:16] <trackbot-ng> Tracking ISSUEs and ACTIONs from http://www.w3.org/html/wg/tracker/
  74. # [10:17] * Quits: Lachy (Lachlan@84.215.41.149) (Quit: This computer has gone to sleep)
  75. # [10:18] * Joins: jgraham_ (james@81.86.210.2)
  76. # [10:35] * Joins: andreas (andreasb@213.236.208.22)
  77. # [10:36] * Parts: andreas (andreasb@213.236.208.22)
  78. # [10:37] * Joins: Lachy (Lachlan@213.236.208.22)
  79. # [10:40] * Joins: ROBOd (robod@89.122.216.38)
  80. # [10:47] * Joins: inimino (chatzilla@75.71.88.233)
  81. # [10:49] * Quits: inimino (chatzilla@75.71.88.233) (Quit: ChatZilla 0.9.79 [Firefox 2.0.0.9/2007102501])
  82. # [10:50] * Quits: trackbot-ng (trackbot-n@128.30.52.30) (Client exited)
  83. # [10:55] * Joins: trackbot-ng (trackbot-n@128.30.52.30)
  84. # [10:55] * trackbot-ng is loading HTML Issue Tracking data...
  85. # [10:55] * trackbot-ng found 15 users
  86. # [10:55] <trackbot-ng> Tracking ISSUEs and ACTIONs from http://www.w3.org/html/wg/tracker/
  87. # [11:13] * Quits: jgraham_ (james@81.86.210.2) (Quit: This computer has gone to sleep)
  88. # [11:17] * Quits: aroben (aroben@67.160.250.192) (Ping timeout)
  89. # [11:30] * Joins: inimino (chatzilla@75.71.88.233)
  90. # [11:43] * Quits: trackbot-ng (trackbot-n@128.30.52.30) (Client exited)
  91. # [11:49] * Quits: sbuluf (lxy@200.49.132.99) (Quit: sbuluf)
  92. # [11:53] * Joins: trackbot-ng (trackbot-n@128.30.52.30)
  93. # [11:53] * trackbot-ng is loading HTML Issue Tracking data...
  94. # [11:53] * trackbot-ng found 15 users
  95. # [11:53] <trackbot-ng> Tracking ISSUEs and ACTIONs from http://www.w3.org/html/wg/tracker/
  96. # [12:08] * Joins: hasather (hasather@90.231.107.133)
  97. # [12:12] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  98. # [12:27] <zcorpan> could someone shut trackbot-ng up?
  99. # [12:28] <anne> trackbot-ng, leave
  100. # [12:28] * Parts: trackbot-ng (trackbot-n@128.30.52.30)
  101. # [12:29] <zcorpan> thanks
  102. # [12:29] <anne> although I think it will join again after reboot...
  103. # [12:29] <zcorpan> i don't mind him quitting and joining, so long as he doesn't make noise about it
  104. # [12:29] <anne> everytime someone is added to the system trackbot will reboot or something in that direction
  105. # [12:29] <hsivonen> what's the deal with W3C IRC bots not using the colon convention for addressing a nick and instead want the comma?
  106. # [12:30] <anne> I know colon is used within the W3C for attributing a quote to someone
  107. # [12:31] <anne> I'm not sure about the bots
  108. # [12:31] * anne uses comma to talk to "someone"
  109. # [12:31] <hsivonen> anne: yeah, but breaking the tab autocomplete convention used everywhere else on IRC sucks
  110. # [12:32] <mjs> I hate the W3C use of colon
  111. # [12:32] <mjs> people always break it anyway due to IRC client habit
  112. # [12:32] <mjs> it is spitting into the wind
  113. # [12:33] * mjs could draw some kind of analogy with some w3c specs but refrains
  114. # [12:33] * anne doesn't disagree
  115. # [12:33] * anne is just not filling to fight it
  116. # [12:33] * anne is much amused by the conversation in #jslang
  117. # [12:43] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
  118. # [12:46] <mjs> I shouldn't feed the troll
  119. # [12:47] <anne> that guy is hilarious
  120. # [13:12] * Joins: myakura (myakura@124.84.169.97)
  121. # [14:23] * Quits: jmb (jmb@152.78.68.189) (Ping timeout)
  122. # [14:24] * Joins: jmb (jmb@152.78.68.189)
  123. # [14:51] * Quits: ROBOd (robod@89.122.216.38) (Quit: http://www.robodesign.ro )
  124. # [15:11] <Philip> Hmm, sounds like Firefox 2.0.0.10 broke canvas drawImage quite unpleasantly
  125. # [15:12] <Philip> (https://bugzilla.mozilla.org/show_bug.cgi?id=405584)
  126. # [15:12] <Philip> which sounds like a bit of a problem with regression testing
  127. # [15:15] <Lachy> wow, that's quite a major regression. I guess they'll have to release 2.0.0.11 very quickly to fix it
  128. # [15:16] <anne> i'm thrilled that sites rely on this stuff working already
  129. # [15:16] <anne> awesome
  130. # [15:16] <Philip> Looks like the wrong patch got checked in when fixing a security bug
  131. # [15:16] <Philip> which I had reported, so indirectly this is all my fault :-)
  132. # [15:20] <Philip> (Given the number of security problems exposed by canvas-2d, I think canvas-3d is going to be quite worrying...)
  133. # [15:21] * Quits: myakura (myakura@124.84.169.97) (Ping timeout)
  134. # [15:21] * Joins: myakura (myakura@124.84.169.97)
  135. # [15:23] <Philip> (Also, I found non-interoperability the first time I tried canvas-3d shaders - NVIDIA drivers on Windows support the "saturate" function, but on OS X they don't. So that's going to be very worrying if people want portability/interoperability/etc without testing their code on every platform.)
  136. # [15:27] * Joins: aaronlev (chatzilla@209.6.168.245)
  137. # [15:32] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  138. # [15:32] <anne> maybe an abstract 3D API isn't so bad
  139. # [15:33] <Philip> It's bad if it doesn't provide the features that authors needs, and anything that does provide those features will probably end up looking a lot like OpenGL
  140. # [15:33] <Philip> s/needs/need/
  141. # [15:34] <Philip> or maybe that's not true at all - I don't really know :-)
  142. # [15:34] <anne> abstract also helps with keeping all the various incompatible versions of OpenGL away from the author
  143. # [15:35] <anne> I'm not saying it should be low on features :)
  144. # [15:35] <Philip> I think programmable shaders are an important feature, and I can't think of any way to abstract those away
  145. # [15:36] <Philip> (and they're probably the main place for driver incompatibility)
  146. # [15:37] <Philip> (and they tie implementors to OpenGL, since translating the programs into e.g. DirectX's shader language is not trivial)
  147. # [15:37] <Philip> (but I expect I'd be unhappy at losing them)
  148. # [15:38] <Philip> (so it's a slightly difficult problem :-( )
  149. # [15:50] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
  150. # [16:02] * Joins: ROBOd (robod@89.122.216.38)
  151. # [16:03] * Joins: matt (matt@128.30.52.30)
  152. # [16:16] * Joins: Lachy (Lachlan@84.215.41.149)
  153. # [16:19] * Quits: aaronlev (chatzilla@209.6.168.245) (Ping timeout)
  154. # [16:22] * Quits: gavin_ (gavin@99.227.30.12) (Ping timeout)
  155. # [16:27] * Joins: smedero (smedero@158.130.16.191)
  156. # [16:32] * Joins: aaronlev (chatzilla@66.30.196.151)
  157. # [16:48] * Joins: billmason (billmason@69.30.57.156)
  158. # [16:54] * Quits: myakura (myakura@124.84.169.97) (Quit: Leaving...)
  159. # [17:03] * Joins: gavin_ (gavin@99.227.30.12)
  160. # [17:12] * MikeSmith is now known as MikeSmith^away
  161. # [17:13] * Quits: hasather (hasather@90.231.107.133) (Ping timeout)
  162. # [17:35] * Quits: Lachy (Lachlan@84.215.41.149) (Quit: This computer has gone to sleep)
  163. # [17:37] * Quits: gsnedders (gsnedders@86.145.188.131) (Ping timeout)
  164. # [17:37] * Joins: gsnedders (gsnedders@86.145.188.131)
  165. # [17:39] * zcorpan splitted css processing and xslt processing in http://simon.html5.org/specs/xml-stylesheet5
  166. # [17:42] * Quits: gsnedders (gsnedders@86.145.188.131) (Ping timeout)
  167. # [17:42] * Joins: Sander (svl@86.87.68.167)
  168. # [18:02] * Joins: dbaron (dbaron@71.204.145.103)
  169. # [18:12] * Joins: jgraham_ (james@81.86.210.2)
  170. # [18:14] * Joins: Lachy (Lachlan@84.215.41.149)
  171. # [18:37] <hsivonen> considering earlier discussions about <object> accessibility, it would be interesting to analyze how showcase Flash sites such as those listed at http://www.smashingmagazine.com/2007/10/30/65-excellent-flash-designs/ handle accessibility
  172. # [18:37] <hsivonen> not handled? handled inside Flash (Windows/JAWS)? textual alternative?
  173. # [18:51] * Joins: aroben (aroben@17.203.12.236)
  174. # [18:58] * Joins: gsnedders (gsnedders@86.145.188.131)
  175. # [18:58] * gsnedders hopes he has a good enough wifi connection here
  176. # [19:09] * Quits: gavin_ (gavin@99.227.30.12) (Ping timeout)
  177. # [19:14] * Joins: gavin_ (gavin@99.227.30.12)
  178. # [19:20] * matt is now known as matt-sick
  179. # [19:20] * Quits: matt-sick (matt@128.30.52.30) (Quit: matt-sick)
  180. # [19:21] * Quits: zcorpan (zcorpan@88.131.66.80) (Ping timeout)
  181. # [19:32] * Joins: aroben_ (aroben@17.203.12.72)
  182. # [19:32] * Quits: aroben (aroben@17.203.12.236) (Quit: Leaving)
  183. # [19:48] * Quits: gsnedders (gsnedders@86.145.188.131) (Quit: gsnedders)
  184. # [19:54] * Quits: JanC (janc@213.118.32.92) (Ping timeout)
  185. # [19:56] * Quits: dbaron (dbaron@71.204.145.103) (Ping timeout)
  186. # [19:56] <smedero> hsivonen: Thanks for the info on the validator, makes perfect sense.... and you're right that's not an easy problem to tackle.
  187. # [19:57] * anne still thinks the <form> content model should change
  188. # [19:57] <anne> then again, <form>, etc. are not really defined by HTML 5 yet :(
  189. # [19:58] <hsivonen> smedero, anne: let's ask Hixie
  190. # [19:58] <hsivonen> Hixie: does this still hold: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2005-March/003217.html
  191. # [19:58] <hsivonen> ?
  192. # [19:58] <anne> DanC, if you're around, the question about publishing HTML 5 should probably make it more clear whether Web Forms 2.0 will also be published
  193. # [20:00] <anne> In the inline case the <form> is just a paragraph like construct and semantics depend on <label> and / or <input type=submit>/<button type=submit>
  194. # [20:00] <anne> children
  195. # [20:00] <DanC> yes, next time I put a question on publishing HTML 5, I hope it'll be more clear about Web Forms 2.0 too
  196. # [20:02] <DanC> where are we on that? let's see... it's http://www.w3.org/html/wg/tracker/issues/19 HTML 5 specification release(s)
  197. # [20:02] <DanC> MikeSmith, you did the PDF building action, didn't you? I wonder why tracker didn't notice. http://www.w3.org/html/wg/tracker/actions/6
  198. # [20:05] <hsivonen> whatwg.org now has PDFs. w3.org does not
  199. # [20:07] <smedero> the <body> ... <form><label>search</label><input type="hidden">(N hiddens)<input type="text"><input type="submit"> ... </form> seems like a very common search widget HTML pattern... but I don't have the data to back that up. (the <label> is probably missing too more often than not...)
  200. # [20:08] <hsivonen> hmm. it turns out that the part of WF2 that anne quoted in the email Hixie responded to in the above archive reference has been zapped from WF2
  201. # [20:08] <hsivonen> which leaves the content model of <form> undefined
  202. # [20:09] <smedero> Yeah that section now reads
  203. # [20:09] <smedero> "The children of a form element must be block-level elements, unless one of the ancestors of the form element is an element other than div whose content model includes both block- and inline-level content, in which case either block-level or inline-level content is allowed (but not both). input elements of type hidden may be placed anywhere (both in inline contexts and block contexts).""
  204. # [20:10] * DanC changes topic to 'HTML WG meets Thu 29 Nov at 17:00UTC http://www.w3.org/html/wg/tracker/agenda (logs: http://krijnhoetmer.nl/irc-logs/ ) '
  205. # [20:10] <hsivonen> oh. I failed the find that
  206. # [20:10] * Joins: edas (edaspet@82.233.238.50)
  207. # [20:10] <hsivonen> I'm not particularly keen on implementing that and explaining the error messages that would ensue
  208. # [20:17] * Joins: edaspet (edaspet@82.233.238.50)
  209. # [20:19] * Quits: edas (edaspet@82.233.238.50) (Ping timeout)
  210. # [20:21] * Quits: edaspet (edaspet@82.233.238.50) (Ping timeout)
  211. # [20:30] * Joins: heycam (cam@203.217.79.225)
  212. # [20:30] * Joins: dbaron (dbaron@63.245.220.241)
  213. # [20:50] <smedero> wow. I'm reading back trying to understand clearly why <body> would sufficiently count as a block level element in the case Hixie has that email...
  214. # [20:51] <smedero> "Generally, block-level elements may contain inline elements and other block-level elements. Generally, inline elements may contain only data and other inline elements."
  215. # [20:51] <smedero> that's really... helpful.
  216. # [20:51] <smedero> via: http://www.w3.org/TR/html4/struct/global.html#h-7.5.3
  217. # [20:52] <Hixie> hey, what's up
  218. # [20:53] * Quits: Bob_le_Pointu (blp@80.248.208.232) (Quit: Changing server)
  219. # [20:54] <smedero> Hi Hixie. We've been discussing this old WHATWG email: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2005-March/003217.html
  220. # [20:54] <smedero> and the current wording of that paragraph in the web forms spec.
  221. # [20:56] <Hixie> ah
  222. # [20:56] <smedero> I noticed what I thought was a odd error message in Henri's validator last night but it turns out to be correct interpretation of things...
  223. # [20:56] <Hixie> just with an odd error message :-)
  224. # [20:56] <smedero> yes, which I understand the logic behind it at least now.
  225. # [20:57] <Hixie> yeah
  226. # [20:57] <smedero> I leave it to Henri and Anne to discuss their issues with the current wording though...
  227. # [20:58] <Hixie> well i'm sure the wording will change when wf2 is merged into html5
  228. # [20:59] <smedero> (I'm tempted to do a little data mining because I think the example you give of a body->form->input is a pretty common one... but perhaps it is more edgy than I believe....)
  229. # [20:59] <Hixie> wf2 is written as a diff spec which makes its wording a little... annoying at times
  230. # [20:59] <smedero> yeah, I know the forms stuff is still quite fluid.
  231. # [20:59] <Hixie> smedero: oh it's very common
  232. # [20:59] <Hixie> smedero: so is <body> <div> text
  233. # [20:59] <Hixie> smedero: and <body> <img>
  234. # [20:59] <smedero> sure.
  235. # [21:00] <Hixie> those are all equivalently bad
  236. # [21:00] <Hixie> (<div> text </div> is only allowed because of its use in making custom widgets where we really don't have useful semantic elements at hand)
  237. # [21:01] <smedero> Right, those examples seem pretty clear... but I think web authors are going to be a little confused by the <form> instance... because adding the extra <p> seems like semantics for the sake of it. (though of course a <fieldset> is quite logical... but I'm guessing most will just dump in a <p> to work around the validator message)
  238. # [21:02] * smedero for the record... loathes these types of debates
  239. # [21:02] <Dashiva> What's it going to be on <p><form><input> vs <form><p><input>? Is one still bad and the other good?
  240. # [21:02] <smedero> but I'd rather wait until wf2 is merged and see what happens then.
  241. # [21:03] <Hixie> well we could define <form>-containing-only-inline as being a paragraph-equivalent container, like we do with <li>
  242. # [21:03] <Hixie> but that won't help those people using <br>s in there to get the effect they should be doing with <p>
  243. # [21:03] <smedero> I think there is an assumption that's exactly what it means...
  244. # [21:04] <smedero> right... the <br> usage is nasty.
  245. # [21:04] <hsivonen> Hixie: whenever CSS generates an anonymous block box, assume paragraph semantics
  246. # [21:04] <Hixie> i think if we do that i may explicitly ban <br> in <form>, since the only use case i can think of is things like shipping labels, and those would ned actual <p> elements to indicate the address
  247. # [21:05] * Hixie looks out from his window on this floor of the ivory tower at the beautiful tag soup fields below
  248. # [21:05] * Joins: kingryan (kingryan@66.92.2.56)
  249. # [21:05] <Hixie> hsivonen: <div> doesn't define a paragraph
  250. # [21:05] <Hixie> hsivonen: the whole point of <div> is that it doesn't define anything (except grouping)
  251. # [21:06] <Dashiva> So what is the "best" way to do a line-based form? One-column table? No-style list? <br>? No-padding <p>?
  252. # [21:06] <Hixie> <p>
  253. # [21:07] <Dashiva> What if a group of those lines would normally be a <p>?
  254. # [21:07] <Hixie> like what?
  255. # [21:07] <Hixie> like an address label?
  256. # [21:07] <Hixie> <p> with <br>
  257. # [21:09] <Dashiva> And what if you want two-column alignment? :)
  258. # [21:13] <Hixie> the presentation is a CSS issue
  259. # [21:13] <Hixie> a two-column <table> can be appropriate though if the markup consists of just a list of labels with associated form controls
  260. # [21:17] * Philip would like a validator mode that ignores any content-model requirement that is just there for semantic purity and not for any practical problem
  261. # [21:18] * Quits: smedero (smedero@158.130.16.191) (Quit: smedero)
  262. # [21:18] <Hixie> Philip: wouldn't that be most of them?
  263. # [21:18] <Hixie> Philip: what's the practical problem of having an <h1> in an <h2> ?
  264. # [21:19] <Hixie> or an <li> without a parent <ol>
  265. # [21:19] <Hixie> or a <dt> with no associated <dd>?
  266. # [21:19] <Hixie> or the root element being <div> instead of <html>
  267. # [21:19] <Hixie> or of there not being a <title>
  268. # [21:20] <Hixie> or of value="" on <li> not having a numeric value
  269. # [21:20] <Hixie> etc...
  270. # [21:20] <Hixie> many things can be "wrong" without their wrongness necessarily being an immediate practical problem
  271. # [21:21] <Dashiva> Philip: A @suppresserrors directive, perhaps. "I know I'm not supposed to put this <p> here, but I'm going to do it, so don't bug me"
  272. # [21:22] <Dashiva> The validator can't really know the difference otherwise
  273. # [21:25] <Philip> <h1> inside <h2> would make header extractors (like for tables of contents) break; <li> outside <ol> doesn't get indented properly and gets parsed confusingly in existing browsers; missing <title> means people can't bookmark your page nicely; non-numeric <li> value won't get rendered properly; etc
  274. # [21:26] <Hixie> inline text without a proper paragraph container will get rendered confusingly by an aural UA
  275. # [21:26] <Hixie> and can't be styled properly
  276. # [21:26] <Hixie> and won't have proper paragraph margins
  277. # [21:27] * Joins: gsnedders (gsnedders@86.145.188.131)
  278. # [21:32] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
  279. # [21:33] * Joins: hober (ted@68.107.112.172)
  280. # [21:33] * Joins: mjs (mjs@64.81.48.145)
  281. # [21:34] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
  282. # [21:34] * Quits: gsnedders (gsnedders@86.145.188.131) (Ping timeout)
  283. # [21:34] <Philip> Does <span><div>...</div></span> cause problems?
  284. # [21:36] <Hixie> confusing styling behaviour by default?
  285. # [21:36] <Hixie> i don't know what it would mean, which i suppose is another problem
  286. # [21:36] <Hixie> it also wouldn't parse right if used after a <p> element with an implied end tag
  287. # [21:37] <Hixie> i don't think the "allow everything except what causes problems" strategy is a winning one, to be honest
  288. # [21:37] <Hixie> it seems overly risky
  289. # [21:37] <Hixie> without a clear gain
  290. # [21:37] <anne> hmm, transparent <a> is going to be tricky
  291. # [21:38] <Hixie> transparent <a>?
  292. # [21:38] <anne> <a> around block-level elements
  293. # [21:39] <Hixie> ah
  294. # [21:39] <Hixie> yes it is
  295. # [21:39] <anne> that has exactly the same problem as above <p> ... <a> <div> ... </div> </a> is an issue while <p> ... </p> <a> <div> ... isn't
  296. # [21:40] <Hixie> that's just one of the problems, yeah
  297. # [21:40] <anne> DOM-wise and parsing-wise is solved afaict
  298. # [21:41] <anne> btw, I wanted to ask about no new features, what about Ruby markup?
  299. # [21:41] <anne> and this async JavaScript thread
  300. # [21:43] <Hixie> ruby is on the list of things that will be added
  301. # [21:43] <Hixie> worker pools are punted to 5.1
  302. # [21:43] <hsivonen> Hixie: is "the list" concretely written down somewhere?
  303. # [21:44] <Hixie> the list is wf2, rendering, and ruby, i believe.
  304. # [21:44] <hsivonen> ok
  305. # [21:44] <Hixie> i may come across some old suggestions that were sent before the feature freeze that deserve to be added, too
  306. # [21:44] <Hixie> we'll see
  307. # [21:44] <hsivonen> I should probably document that Validator.nu doesn't support IPv6...
  308. # [21:45] <anne> http://fileformats.blogspot.com/2007/11/design-principles-for-html-5.html maybe we should have another note with a few reasons of why HTML5 is needed...
  309. # [21:45] <anne> (the ones that zcorpan mentioned there + what hsivonen talked about during the TPAC)
  310. # [21:47] <Hixie> i'd just stick it in the design principles
  311. # [21:47] <Hixie> since hte goals mostly explain why we have hte principles we have
  312. # [21:48] * Joins: edas (edaspet@82.233.238.50)
  313. # [21:48] <Philip> hsivonen: Non-support of IPv6 is the default assumption for users of anything at all on the internet - it's perhaps more efficient to only document the rare cases where something does support IPv6
  314. # [21:49] <anne> i guess that could work too
  315. # [21:50] <hsivonen> Philip: well, yeah. but it sucks that portless URIs look like a failure at the other end and URIs with port do nothing which is *really* weird
  316. # [21:55] * Quits: ROBOd (robod@89.122.216.38) (Quit: http://www.robodesign.ro )
  317. # [21:56] * Quits: heycam (cam@203.217.79.225) (Quit: bye)
  318. # [22:01] * Quits: Lachy (Lachlan@84.215.41.149) (Quit: This computer has gone to sleep)
  319. # [22:15] <DanC> I'm doing some system administration, and I think I'm going to reboot... so while the http://fileformats.blogspot.com/2007/11/design-principles-for-html-5.html is on the screen, here...
  320. # [22:15] <DanC> if it has anything interesting to say, I'd appreciate if somebody would excerpt and cite in mail to our comments list
  321. # [22:16] <DanC> a little redundancy is in order while W3C catches up on the migration from email to blogs
  322. # [22:17] * Parts: DanC (connolly@128.30.52.30) (Leaving)
  323. # [22:46] * Joins: heycam (cam@130.194.72.84)
  324. # [22:51] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
  325. # [23:15] * Quits: aaronlev (chatzilla@66.30.196.151) (Ping timeout)
  326. # [23:19] * Joins: DanC (connolly@128.30.52.30)
  327. # [23:20] * Quits: edas (edaspet@82.233.238.50) (Quit: Quitte)
  328. # [23:22] * Joins: Hixie (ianh@129.241.93.37)
  329. # [23:54] * Quits: Sander (svl@86.87.68.167) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  330. # [23:57] * Quits: jgraham_ (james@81.86.210.2) (Quit: This computer has gone to sleep)
  331. # [23:58] * Joins: jgraham_ (james@81.86.210.2)
  332. # Session Close: Wed Nov 28 00:00:00 2007

The end :)