/irc-logs / freenode / #whatwg / 2007-09-16 / end

Options:

  1. # Session Start: Sun Sep 16 00:00:00 2007
  2. # Session Ident: #whatwg
  3. # [00:07] <Philip`> Current status: Firefox 3 + shadow patch: 44/44 passed. Safari 3: 35/44. Opera 9.5: 12/44.
  4. # [00:07] * Joins: weinig (i=weinig@nat/apple/x-51ea15cb09132093)
  5. # [00:08] <Philip`> (The failures in Safari are (in my opinion) definitely bugs, rather than just being differences with the (proposed) specification)
  6. # [00:16] * Quits: Ducki (i=Ducki@nrdh-d9b980dc.pool.mediaWays.net) (Read error: 113 (No route to host))
  7. # [00:32] * Quits: virtuelv_ (n=virtuelv@58.80-202-82.nextgentel.com) ("Leaving")
  8. # [00:41] * Quits: Ducki_ (i=Ducki@nrdh-d9b980d2.pool.mediaWays.net) (Read error: 113 (No route to host))
  9. # [00:45] * Joins: tantek (n=tantek@adsl-63-203-221-50.dsl.snfc21.pacbell.net)
  10. # [00:52] * Quits: dev0 (i=Tobias@unaffiliated/icefox0) ("dev0 has no reason")
  11. # [01:00] * Joins: rob1n (n=emp@unaffiliated/rob1n)
  12. # [01:00] * Parts: rob1n (n=emp@unaffiliated/rob1n) ("Leaving")
  13. # [01:32] * Quits: tantek (n=tantek@adsl-63-203-221-50.dsl.snfc21.pacbell.net)
  14. # [01:57] * Joins: om_sleep (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  15. # [01:59] * om_sleep is now known as othermaciej
  16. # [02:07] * Joins: webben (n=benh@82.153.85.49)
  17. # [02:18] * Quits: hasather (n=hasather@90-227-221-48-no62.tbcn.telia.com) (Remote closed the connection)
  18. # [02:23] * Quits: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com) (Read error: 110 (Connection timed out))
  19. # [02:41] * Joins: aaronlev (n=chatzill@209-6-168-245.c3-0.arl-ubr2.sbo-arl.ma.cable.rcn.com)
  20. # [03:05] * Quits: weinig (i=weinig@nat/apple/x-51ea15cb09132093)
  21. # [03:18] * Joins: doublec (n=doublec@202-74-219-89.ue.woosh.co.nz)
  22. # [03:20] <Lachy> http://adactio.com/journal/1343
  23. # [03:27] <Lachy> looks like me misunderstands and misrepresents how the 80-20 rule is applied and then uses that as a straw man to argue why we shouldn't be using it
  24. # [03:39] * Joins: h3h (n=w3rd@cpe-76-88-44-219.san.res.rr.com)
  25. # [03:43] * Quits: doublec (n=doublec@202-74-219-89.ue.woosh.co.nz)
  26. # [03:47] * Joins: mpt (n=mpt@219.234.180.199)
  27. # [03:47] * Quits: mpt (n=mpt@219.234.180.199) (Client Quit)
  28. # [03:50] * Joins: polin8 (n=brian@c-75-71-72-175.hsd1.co.comcast.net)
  29. # [04:07] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  30. # [04:52] * Joins: weinig (n=weinig@c-67-169-182-231.hsd1.ca.comcast.net)
  31. # [04:52] * Joins: doublec (n=doublec@203-211-102-83.ue.woosh.co.nz)
  32. # [04:59] <othermaciej> Lachy: do you have any suggestions for a "Degrade Gracefully" example I could add to replace the section/block one?
  33. # [05:00] <othermaciej> Lachy: I'd like an example of an element that can be pretty much emulated with CSS styling
  34. # [05:00] <Lachy> maybe <m>
  35. # [05:00] <othermaciej> does HTML5 have any new block-level elements that are only allowed inline contents?
  36. # [05:01] <othermaciej> I'm not sure what the expected presentation of <m> is, if any
  37. # [05:01] <Lachy> I would expect a yellow highlight or something
  38. # [05:03] <othermaciej> it's not totally obvious yet what is expected so I'm not sure I could give a concrete example of the style rule to use
  39. # [05:04] <othermaciej> I'm going through the elements at http://simon.html5.org/html5-elements
  40. # [05:04] <Lachy> that's what I'm looking through too
  41. # [05:04] <othermaciej> hmmm
  42. # [05:04] <othermaciej> can <figure> be handled properly with just display: block?
  43. # [05:05] <Lachy> maybe
  44. # [05:05] <othermaciej> it's not allowed any block children
  45. # [05:06] <othermaciej> the legend doesn't really display in what seems like a useful way by default
  46. # [05:06] <Lachy> unfortunately, <legend> has problems in some browsers. it doesn't appear in the DOM in Firefox
  47. # [05:08] * Quits: polin8 (n=brian@c-75-71-72-175.hsd1.co.comcast.net) (Client Quit)
  48. # [05:08] <Lachy> and IE isn't going to play nicely with any new element at all
  49. # [05:08] <othermaciej> the legend element isn't in the DOM in Safari either
  50. # [05:10] <othermaciej> it seems like using a new element for a figure caption instead of <legend> would work better
  51. # [05:10] <othermaciej> seems like <legend> will have the same problem for <details> as well
  52. # [05:10] * Quits: aaronlev (n=chatzill@209-6-168-245.c3-0.arl-ubr2.sbo-arl.ma.cable.rcn.com) (Read error: 110 (Connection timed out))
  53. # [05:10] <othermaciej> I can't figure out how to get this to style reasonably in any browser:
  54. # [05:11] <othermaciej> <figure><img src=chair.jpg><legend>a chair</legend></figure>
  55. # [05:11] <Lachy> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Afigure%20%7B%20display%3A%20block%3B%20background%3A%20yellow%3B%20%7D%0Afigure%20legend%2C%20figure%20span%20%7B%20display%3A%20block%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cfigure%3E%3Cimg%20src%3Dimage%3E%0A%3Clegend%3E%3Cspan%3ECaption%3C%2Fspan%3E%3C%2Flegend%3E%3C%2Ffigure%3E
  56. # [05:11] <othermaciej> (what I'd like to do is make the legend display on its own line horizontally centered)
  57. # [05:12] <Lachy> wrong link...
  58. # [05:12] <Lachy> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Afigure%20%7B%20display%3A%20block%3B%20background%3A%20yellow%3B%20%7D%0Afigure%20legend%2C%20figure%20span%20%7B%20display%3A%20block%3B%20background%3A%20lime%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cfigure%3E%3Cimg%20src%3Dimage%3E%0A%3Clegend%3E%3Cspan%3ECaption%3C%2Fspan%3E%3C%2Flegend%3E%3C%2Ffigure%3E
  59. # [05:12] <othermaciej> I can see that adding a span would work
  60. # [05:12] <othermaciej> I was hoping there might be a better way
  61. # [05:13] * Quits: tndH (i=Rob@87.102.74.242) ("ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  62. # [05:13] <othermaciej> a new element in place of <legend> would make it simpler at least in SafOperFox
  63. # [05:14] <Lachy> is there a reason why browsers need to ignore <legend> outside of a fieldset? Can that handling be changed without breaking anything?
  64. # [05:14] <othermaciej> it probably can be, but a new element would already work in today's browsers, so degrades better
  65. # [05:14] <othermaciej> <legend> is given special rendering behavior in a <fieldset> that can't be expressed with CSS
  66. # [05:15] <othermaciej> browsers probably ignore it in other places as a way to avoid causing problems with that in other places
  67. # [05:15] <Lachy> I know, that may cause some problems if someone tries to use a figure inside a fieldset
  68. # [05:16] <othermaciej> it seems pretty hard to center-align the caption under the image as well
  69. # [05:16] <othermaciej> this is the best I've got:
  70. # [05:16] <othermaciej> figure { display: block; float: left;}
  71. # [05:16] <othermaciej> figure legend, figure span { display: block; text-align: center; }
  72. # [05:16] <othermaciej> but floating by default is probably not desirable
  73. # [05:17] * othermaciej tries to remember what else will cause shrink-wrap
  74. # [05:17] <Lachy> no, definately not a good idea to float by default
  75. # [05:17] <Lachy> inline-block;
  76. # [05:17] <Lachy> display: table-cell;
  77. # [05:17] <othermaciej> does mozilla support inline-block yet?
  78. # [05:17] <othermaciej> ah, table-cell
  79. # [05:17] <othermaciej> well, that won't work in IE probably
  80. # [05:18] <Lachy> IE has limited support for inline-block
  81. # [05:19] <othermaciej> this works in Safari and Opera but not Firefox: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cstyle%3E%0D%0Afigure%20%7B%20display%3A%20inline-block%3B%7D%0D%0Afigure%20legend%2C%20figure%20span%20%7B%20display%3A%20block%3B%20text-align%3A%20center%3B%20%7D%0D%0A%3C%2Fstyle%3E%0D%0A%3Cfigure%3E%3Cimg%20src%3Dimage%3E%0D%0A%3Clegend%3E%3Cspan%3ECaption%3C%2Fspan%3E%3C%2Flegend%3E%3C%2Ffigure%3E
  82. # [05:19] <othermaciej> but in general inline-block seems good since it will make the image + caption work basically like a replaced element woud
  83. # [05:19] <othermaciej> *would
  84. # [05:20] * Joins: Lachy_ (n=lachlan_@124-170-114-235.dyn.iinet.net.au)
  85. # [05:20] * Parts: Lachy_ (n=lachlan_@124-170-114-235.dyn.iinet.net.au)
  86. # [05:21] <othermaciej> display: table-cell breaks the centering in Opera, but not Safari or Firefox
  87. # [05:22] <Lachy> this works in Firefox and Opera
  88. # [05:22] <othermaciej> ok, here's one that works in all three:
  89. # [05:22] <othermaciej> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Afigure%20%7B%20display%3A%20table-cell%3B%20display%3A%20inline-block%3B%20%7D%0Afigure%20legend%2C%20figure%20span%20%7B%20display%3A%20block%3B%20text-align%3A%20center%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cfigure%3E%3Cimg%20src%3Dimage%3E%0A%3Clegend%3E%3Cspan%3ECaption%3C%2Fspan%3E%3C%2Flegend%3E%3C%2Ffigure%3E
  90. # [05:22] <Lachy> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Afigure%20%7B%20display%3A%20table-cell%3B%20display%3A%20inline-block%3B%20background%3A%20yellow%3B%20%7D%0Afigure%20legend%2C%20figure%20span%20%7B%20display%3A%20block%3B%20background%3A%20lime%3B%20text-align%3A%20center%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cfigure%3E%3Cimg%20src%3Dimage%3E%0A%3Clegend%3E%3Cs
  91. # [05:22] <Lachy> pan%3ECaption%3C%2Fspan%3E%3C%2Flegend%3E%3C%2Ffigure%3E
  92. # [05:22] <othermaciej> yours got split into multiple lines
  93. # [05:22] <Lachy> yeah, that's the same thing :-)
  94. # [05:22] <Lachy> mine has pretty colours!
  95. # [05:22] <othermaciej> I'm not sure if that would work in IE
  96. # [05:22] <Lachy> download it from the clipboard
  97. # [05:23] <othermaciej> I'll fire up Windows
  98. # [05:23] <Lachy> doesn't work well in IE
  99. # [05:24] <Lachy> mostly because it treats "FIGURE", "/FIGURE", "LEGEND" and "/LEGEND" as distinct elements, that are all siblings of each other
  100. # [05:26] <Lachy> Hixie's server is having serious trouble. even is clipboard is generating intermittent HTTP 500 errors
  101. # [05:27] <othermaciej> ick
  102. # [05:28] <othermaciej> Lachy: IE's behavior on unknown elements seems to be a pretty serious impediment to adding new elements
  103. # [05:28] <othermaciej> even what Firefox does is pretty bad in a lot of cases
  104. # [05:28] <othermaciej> it's weird that Safari and Opera seem to be more similar to each other than the top two in a lot of these cases
  105. # [05:28] <Lachy> yeah, but there's nothing we can do about it
  106. # [05:28] <Lachy> unless we want to replace <section>, etc. with <div role=section>
  107. # [05:29] <Lachy> which I don't want to do
  108. # [05:29] <othermaciej> for Firefox we might have a reasonable shot of getting Mozilla to change handling of unknown elements to let them contain blocks
  109. # [05:30] <othermaciej> which seems to be the major issue
  110. # [05:30] <othermaciej> (change it well in advance of broad HTML5 adoption, that is)
  111. # [05:30] <Lachy> IIRC, the HTML5 parsing algorithm says unknown elements need to be treated as inlines
  112. # [05:31] <othermaciej> does that mean it would require that block element open tags terminate them?
  113. # [05:31] <othermaciej> that would (obviously) be a bad requirement
  114. # [05:31] <Lachy> hmm, apparently not http://wordsandpictures.dyndns.org/cgi-bin/parsetree/parsetree.py?source=%3C%21DOCTYPE%20html%3E%0D%0A%3Cbody%3E%0D%0A%3Cfoo%3ETest%3Cp%3Etest%3C%2Fp%3Etest%3C%2Ffoo%3E
  115. # [05:32] <othermaciej> that's good
  116. # [05:32] <Lachy> assuming that implementation is correct, yes
  117. # [05:32] <othermaciej> so anyway, I guess <figure> is not a good example
  118. # [05:32] <othermaciej> given IE's current behavior, I'm not sure any new element can be handled reasonably in existing versions of IE
  119. # [05:32] <Lachy> why not? We got good results in 3 out of 4
  120. # [05:33] <othermaciej> well, having to add the span is ugly
  121. # [05:33] <othermaciej> and the style rule is kinda complicated
  122. # [05:34] <Lachy> IE's handling could be patched using a script to modify the dom
  123. # [05:36] <othermaciej> true, but that also seems to be the case for <section> in Firefox and IE
  124. # [05:36] <othermaciej> (though the script would be nontrivial)
  125. # [05:38] <Lachy> not too hard. Dean Edwards (I think) has a script somewhere that fixes IE 6's handling of <abbr>, which was treated as an unknown element.
  126. # [05:38] <Lachy> so it's been done before
  127. # [05:38] <othermaciej> well, it's a bit easier in IE because the end tag also ends up as an element in the DOM
  128. # [05:38] <Lachy> yep
  129. # [05:38] <othermaciej> doing the fixup in Firefox would require some marker for the end of the element
  130. # [05:39] * Joins: polin8 (n=brian@c-75-71-72-175.hsd1.co.comcast.net)
  131. # [05:39] <othermaciej> I think I'll take the example out for now
  132. # [05:39] <othermaciej> there doesn't seem to be any element that can be adequately handled just with a CSS rule currently
  133. # [05:39] <othermaciej> except maybe <m>, but I'm not sure what default rendering would be appropriate
  134. # [05:40] <Lachy> m { background: yellow; }
  135. # [05:40] <Lachy> you don't need to demonstrate the default styling, only that it's possible for authors to provide their own
  136. # [05:41] <othermaciej> I think the background: yellow thing wouldn't even work in IE
  137. # [05:41] <othermaciej> though I guess by that standard, I'm not sure if IE supports attribute selectors either
  138. # [05:43] <Lachy> IE7 supports attribute selectors
  139. # [07:48] * Joins: kfish (n=conrad@61.194.21.25)
  140. # [07:57] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  141. # [08:07] <othermaciej> just sent email about the Mozilla issue
  142. # [08:07] <othermaciej> apparently there was already a bug filed some time ago (by Hixie)
  143. # [08:18] * Joins: aroben_ (n=aroben@unaffiliated/aroben)
  144. # [08:21] <gavins> https://bugzilla.mozilla.org/show_bug.cgi?id=311366
  145. # [08:22] <othermaciej> yes, I cited that in my email
  146. # [08:23] <gavins> email to the list?
  147. # [08:23] <gavins> (sorry, lacking context)
  148. # [08:23] * gavins is now known as gavin
  149. # [08:25] <gavin_> ah, yes
  150. # [08:27] <othermaciej> to public-html
  151. # [08:27] <othermaciej> seems like it would be nice to fix that in Firefox 3, since Firefox, Opera and Safari are all starting to get into HTML5 implementation
  152. # [08:28] <gavin_> yeah
  153. # [08:34] <othermaciej> Lachy: does IE7 still handle <abbr> as an unknown element?
  154. # [08:35] <Lachy> othermaciej, no, IE7 supports it properly
  155. # [08:35] <othermaciej> ok cool
  156. # [08:38] * Quits: polin8 (n=brian@c-75-71-72-175.hsd1.co.comcast.net) (Client Quit)
  157. # [08:47] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 110 (Connection timed out))
  158. # [08:47] * aroben_ is now known as aroben
  159. # [09:01] <othermaciej> Lachy: hmm, I think putting text-align: center on <figure> might be about the right thing
  160. # [09:03] <Lachy> othermaciej, show me a demo?
  161. # [09:07] <Lachy> figure { display: table; } figure legend { display: table-caption; } is probably the ideal default presentation, since it also allows the use of 'caption-side'
  162. # [09:08] <othermaciej> I'm not sure if it's right for the figure to shrink to fit the image or not
  163. # [09:08] <othermaciej> it's supposed to represent a paragraph
  164. # [09:08] <othermaciej> so presumably it should be its own block when mixed with paragraphs, and should get the full width of the containing block
  165. # [09:09] <othermaciej> but I don't think there's any way to handle it without adding a span or something inside the <legend>
  166. # [09:09] <othermaciej> hmm
  167. # [09:10] <othermaciej> display: table-caption means you have to control whether the caption appears above or below with separate properties instead of just whether it is before or after the image
  168. # [09:10] <Lachy> is that a bad thing?
  169. # [09:10] <othermaciej> well, yeah
  170. # [09:11] <othermaciej> why allow both <figure><img><legend>...</legend></figure> and <figure><legend>...</legend><img></figure> if they do the same thing?
  171. # [09:11] <othermaciej> whereas other elements that take a <legend> require it to be first
  172. # [09:13] <othermaciej> presumably there are cases where the image or video caption comes logically first, so you'd want it visually first by default as well
  173. # [09:14] * Quits: kfish (n=conrad@61.194.21.25) ("Pike!")
  174. # [09:21] <Lachy> I have a solution to that
  175. # [09:21] <Lachy> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Afigure%20%7B%20display%3A%20table%3B%20%7D%0Afigure%20legend%2C%20figure%20span%20%7B%20display%3A%20table-caption%3B%20caption-side%3A%20bottom%3B%20text-align%3A%20center%3B%20%7D%0Afigure%20legend%3Afirst-child%2C%20figure%20span%3Afirst-child%20%7B%20caption-side%3A%20top%3B%20%7D%0A%3C%2Fstyle%3E%0A%3
  176. # [09:21] <Lachy> Cp%3E%3Cfigure%3E%3Cimg%20src%3Dimage%3E%3Clegend%3E%3Cspan%3ECaption%3C%2Fspan%3E%3C%2Flegend%3E%3C%2Ffigure%3E%0A%3Cp%3E%3Cfigure%3E%3Clegend%3E%3Cspan%3ECaption%3C%2Fspan%3E%3C%2Flegend%3E%3Cimg%20src%3Dimage%3E%3C%2Ffigure%3E
  177. # [09:21] <Lachy> (if that split across several lines, download it from the clipboard)
  178. # [09:23] <othermaciej> that's not bad
  179. # [09:37] <Lachy> that doesn't work in Opera because legend is in the DOM as an empty element.
  180. # [09:38] <Lachy> These styles work:
  181. # [09:38] <Lachy> figure { display: table; }
  182. # [09:38] <Lachy> figure legend, figure span { display: table-caption; text-align: center; caption-side: bottom; }
  183. # [09:38] <Lachy> figure legend:first-child, figure legend:first-child+span, figure span:first-child { caption-side: top; }
  184. # [09:39] <Lachy> though I still haven't found anything that will get it working in IE
  185. # [09:41] * Quits: webben (n=benh@82.153.85.49) (Remote closed the connection)
  186. # [09:42] * Joins: webben (n=benh@dip5-fw.corp.ukl.yahoo.com)
  187. # [09:43] <othermaciej> I don't think there's any way to make it work in IE without script
  188. # [09:46] <othermaciej> that latest set of rules seems to give consistent and useful rendering in SafOperFox
  189. # [09:46] * Quits: h3h (n=w3rd@cpe-76-88-44-219.san.res.rr.com)
  190. # [09:47] <othermaciej> hmmm
  191. # [09:47] <othermaciej> Lachy: would there be any problem with using <label> instead of <legend>?
  192. # [09:49] <Lachy> not as far as the DOM is concerned, but I don't know how assistive technology reacts to labels that aren't used for form controls
  193. # [09:50] <othermaciej> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Afigure%20%7B%20display%3A%20table%3B%20%7D%0Afigure%20label%20%7B%20display%3A%20table-caption%3B%20text-align%3A%20center%3B%20caption-side%3A%20bottom%3B%20%7D%0Afigure%20label%3Afirst-child%20%7B%20caption-side%3A%20top%3B%20%7D%0A%3C%2Fstyle%3E%0A%0A%3Cfigure%3E%0A%3Cimg%20src%3Dimage%3E%0A%3Clabel%3ECaption%3C%2Flabel%3E%0A%3C%2Ffigure%
  194. # [09:50] <Lachy> would it, for example, interfere with forms mode, or would they be read out when not in forms mode? I have no idea. it may not be a problem at all.
  195. # [09:50] <othermaciej> the DOM for that is right even in IE
  196. # [09:52] <othermaciej> IE doesn't support CSS tables, right?
  197. # [09:52] <Lachy> well, the DOM is as close as we're going to get it without replacing figure too.
  198. # [09:52] <Lachy> no, it doesn't support css tables
  199. # [09:53] <othermaciej> the DOM is real close anyway; required script fallback would be limited to putting the <figure> contents back inside the figure
  200. # [09:54] <Lachy> the problem I would have with reusing label is that authors currently style label a lot for use with forms, and if they wanted to insert a figure into an existing page, those existing styles would interfere
  201. # [09:54] <Lachy> that would create a lot of headaches as they modified their style sheets
  202. # [09:56] <othermaciej> true, but they'd need to add a rule for "figure label", so that can undo changes in that rule
  203. # [09:57] <Lachy> from an authoring perspective, I can tell you that undoing styles from countless styles spread across several stylesheets is a lot harder than you might think
  204. # [10:00] <Lachy> it makes it even more complicated when authors want to copy and paste their figure styles from one site to another, which may have different label styles and thus more to undo
  205. # [10:00] * Joins: ROBOd (n=robod@89.123.35.166)
  206. # [10:00] * Joins: Ducki (i=Ducki@nrdh-d9b980c3.pool.mediaWays.net)
  207. # [10:01] <othermaciej> all you have to do is have "initial" rules for the kind of styles that are likely to be seen on "label" (which I suspect is somewhat limited)
  208. # [10:01] <othermaciej> the problems with <legend> go beyond styling
  209. # [10:01] <othermaciej> you need tricky script-based fixup to be able to even put event listeners on the caption
  210. # [10:01] <othermaciej> or to find figure captions in the DOM
  211. # [10:02] <othermaciej> anyway I'll mention this objection in my email
  212. # [10:02] <Lachy> ok
  213. # [10:04] <Lachy> but I don't think label styles that authors use today are in any way limited. Some use floats, display: block; cursor pointers, font styles, colours, text-align and much more.
  214. # [10:33] <Lachy> hmm. so much for the "No Original Research" policy on the wiki. I wonder where all those suggestions for using type="" for everything came from, and elements like bmark that have never been discussed on the mailing list
  215. # [10:34] <Lachy> http://esw.w3.org/topic/HTML/ThoughtExperimentInGracefulDegradation
  216. # [10:34] <Lachy> none of the <object type=""> suggestions to replace video, audio and canvas will work. I thought the reason for rejecting that idea had already been explained on public-html
  217. # [10:36] <othermaciej> the browser test results on that page are useful though
  218. # [10:36] <othermaciej> wow
  219. # [10:36] <Lachy> @IRC log readers: the main reason is that overloading <object> with APIs for video, audio and canvas will be extremely complex for implementers
  220. # [10:36] <othermaciej> that's some insane use of type=""
  221. # [10:37] <othermaciej> using new elements not only reduces complexity but also improves semantics
  222. # [10:37] <othermaciej> Since in practice "a video" is more meaningful than "an object"
  223. # [10:37] <Lachy> indeed. We need to cure divitis, not encourage it
  224. # [10:38] * Quits: doublec (n=doublec@203-211-102-83.ue.woosh.co.nz)
  225. # [10:38] <Lachy> not only that, but getting authors to understand MIME types enough to use type="video/mp4", "application/ogg", etc. properly, is a non-starter
  226. # [10:39] <othermaciej> application/x-canvas also seems like a bad idea, since it doesn't in fact represent a content type
  227. # [10:39] <othermaciej> and also the <source> element is a significantly better approach than <object>'s fallback model
  228. # [10:41] <Lachy> maybe we should add this to the wiki http://esw.w3.org/topic/HTML/AddedElementVideo
  229. # [10:41] <Lachy> anyway, dinner time
  230. # [10:41] <Lachy> bbl
  231. # [10:42] <othermaciej> later
  232. # [10:48] <Lachy> I'm back (the kitchen's in use and dinner needs to defrost)
  233. # [10:52] * Joins: doublec (n=doublec@202-74-220-77.ue.woosh.co.nz)
  234. # [10:57] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  235. # [11:02] <Philip`> About new elements in IE: ExplorerCanvas does the same thing with recognising "CANVAS" and "/CANVAS" elements, then treating everything in between as fallback content
  236. # [11:03] <Philip`> Doesn't work when you have <canvas><canvas>A</canvas>B</canvas>, though
  237. # [11:03] <Philip`> (but that doesn't work in Opera either)
  238. # [11:10] <hsivonen> Philip`: should doc conformance ban nested canvas in your opinion?
  239. # [11:17] <Lachy> hmm. <description> might be a reasonable alternative to <legend> for captions
  240. # [11:18] <Lachy> nested canvas don't make sense, since if a UA doesn't support canvas and thus uses the fallback content, then it won't support the nested canvas either
  241. # [11:19] <Lachy> so, yes, I think it should be banned for conformance
  242. # [11:19] <othermaciej> <description> is not bad
  243. # [11:20] <Lachy> Ben's other suggestion to use <title> won't work, since that would mess with legacy handling of <title>
  244. # [11:20] <othermaciej> but it's a bit wordy and a bit inaccurate
  245. # [11:20] <othermaciej> agreed on <title>
  246. # [11:20] <othermaciej> on <details> especially, it's definitely a label (or perhaps a caption, stretching it), not a description
  247. # [11:22] <Lachy> I'd never heard of "rubric" before, so that's not a good option either.
  248. # [11:24] <othermaciej> it's always possible to add an arbitrary marker of disctionction, like <caption2>
  249. # [11:25] <othermaciej> but that's kind of lame
  250. # [11:25] <Lachy> maybe something like <cap>
  251. # [11:26] <othermaciej> <capt>, <cptn>
  252. # [11:26] <othermaciej> or, just to be silly, <c>
  253. # [11:26] <othermaciej> if we had our names of choice without regard to compatibility, I would say a figure has a caption, but a details section has a label
  254. # [11:27] <Lachy> capt. is generally the abbreviation of captain
  255. # [11:27] <Lachy> yeah, that's the advantage the XHTML2 group has - they don't care about compatibility
  256. # [11:30] <othermaciej> I wouldn't consider that an advantage
  257. # [11:31] <Lachy> not in reality, but it's an advantage because they don't have to spend time thinking about the issues like we do
  258. # [11:33] <Lachy> thesaurus.com lists these synonyms: explanation, head, inscription, legend, rubric, subtitle, title, underline
  259. # [11:34] <othermaciej> yeah, that's where I looked
  260. # [11:34] <othermaciej> I ruled out title, underline, legend and head for various reasons that should be obvious
  261. # [11:34] <Lachy> description, descriptor, headline, label, lemma
  262. # [11:35] <Lachy> descriptor might work
  263. # [11:35] <Lachy> or <desc>
  264. # [11:37] <othermaciej> another possibility is two new elements, say <figcaption> and <detailslabel>
  265. # [11:37] <othermaciej> I'm not sure I like any of these a lot more than <label>
  266. # [11:38] <Lachy> I really don't like <label> for the reasons I gave before
  267. # [11:39] <othermaciej> it's true that one or more new elements would be better for pragmatic reasons
  268. # [11:39] <othermaciej> and would have basically no disadvantage compared to <legend>
  269. # [11:39] <othermaciej> playing off of <label>, another possibility is <tag>
  270. # [11:39] <othermaciej> but that might just confuse people
  271. # [11:40] <Lachy> <tagline>
  272. # [11:40] <Lachy> nah, doesn't quite fit its definition
  273. # [11:42] <Lachy> How about just using <figure><img/><p>Caption</p></figure>?
  274. # [11:46] <othermaciej> I'd guess the default and author styling for p would both interfere with that
  275. # [11:48] <Lachy> yeah, possibly. But I don't think it would be as bad as <label>, since most p styles are just margin and padding - the rest are typically just inherited
  276. # [11:49] <Lachy> but I could be wrong, people do all sorts of crazy things
  277. # [11:53] <gsnedders> is it possible to look up any post on whatwg archives by message-id (or anything else I'd have in my email client)?
  278. # [11:53] <Lachy> gsnedders, the closest you can get is narrowing it down by date, subject and author
  279. # [11:53] <gsnedders> Lachy: that was my fear
  280. # [11:54] <gsnedders> silly othermaciej posting so many things in a single thread…
  281. # [11:54] <othermaciej> gsnedders: it doesn't look like a single thread to me...
  282. # [11:54] <Lachy> the alternative is to download the gzip'd mbox files and search those
  283. # [11:54] <gsnedders> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-June/011973.html
  284. # [11:55] <gsnedders> that's what I was looking for
  285. # [11:56] <othermaciej> I shouldn't have posted anything on *that* thread
  286. # [11:56] <gsnedders> (I had been looking for it for around five minutes before asking the above question)
  287. # [12:03] * Joins: Ducki_ (i=Ducki@nrdh-d9b980c9.pool.mediaWays.net)
  288. # [12:05] <Lachy> othermaciej, why? did that thread turn into a flamewar or something?
  289. # [12:05] <othermaciej> I remember there being a lot of flamage around that topic
  290. # [12:06] <gsnedders> A lot.
  291. # [12:07] <Lachy> yeah, that's what happens when patents, laywers, and free-software advocates get involved
  292. # [12:14] * Joins: hasather (n=hasather@90-227-221-48-no62.tbcn.telia.com)
  293. # [12:21] * Quits: Ducki (i=Ducki@nrdh-d9b980c3.pool.mediaWays.net) (Read error: 113 (No route to host))
  294. # [12:24] * Quits: doublec (n=doublec@202-74-220-77.ue.woosh.co.nz)
  295. # [12:36] * Joins: maikmerten (n=maikmert@L9ff5.l.pppool.de)
  296. # [12:38] * Joins: tndH_ (i=Rob@87.102.74.242)
  297. # [12:39] * tndH_ is now known as tndH
  298. # [13:42] * Joins: Ducki (i=Ducki@nrdh-d9b9806b.pool.mediaWays.net)
  299. # [13:49] * Quits: Ducki_ (i=Ducki@nrdh-d9b980c9.pool.mediaWays.net) (Read error: 113 (No route to host))
  300. # [13:58] * Joins: peepo (n=Jay@host86-153-137-94.range86-153.btcentralplus.com)
  301. # [14:01] * Joins: Ducki_ (n=Ducki@nrdh-d9b980d1.pool.mediaWays.net)
  302. # [14:11] * Joins: aaronlev (n=chatzill@209-6-168-245.c3-0.arl-ubr2.sbo-arl.ma.cable.rcn.com)
  303. # [14:13] * Joins: BenWard (n=BenWard@87-194-62-78.bethere.co.uk)
  304. # [14:22] * Quits: Ducki (i=Ducki@nrdh-d9b9806b.pool.mediaWays.net) (Read error: 113 (No route to host))
  305. # [14:40] * Quits: peepo (n=Jay@host86-153-137-94.range86-153.btcentralplus.com) ("later")
  306. # [14:47] * Quits: BenWard (n=BenWard@87-194-62-78.bethere.co.uk)
  307. # [14:56] * Quits: Ducki_ (n=Ducki@nrdh-d9b980d1.pool.mediaWays.net) (Read error: 113 (No route to host))
  308. # [15:07] * Joins: hasather_ (n=hasather@90-227-221-48-no62.tbcn.telia.com)
  309. # [15:09] * Quits: aaronlev (n=chatzill@209-6-168-245.c3-0.arl-ubr2.sbo-arl.ma.cable.rcn.com) (Read error: 110 (Connection timed out))
  310. # [15:16] * Quits: ROBOd (n=robod@89.123.35.166) ("http://www.robodesign.ro")
  311. # [15:23] * Quits: hasather (n=hasather@90-227-221-48-no62.tbcn.telia.com) (Read error: 110 (Connection timed out))
  312. # [15:58] * Joins: aaronlev (n=chatzill@209-6-168-245.c3-0.arl-ubr2.sbo-arl.ma.cable.rcn.com)
  313. # [16:31] * Joins: gsnedders_ (n=gsnedder@host86-137-237-196.range86-137.btcentralplus.com)
  314. # [16:34] <hsivonen> hmm. validator.nu got killed by the kernel :-(
  315. # [16:38] * Quits: gsnedders (n=gsnedder@host86-139-120-102.range86-139.btcentralplus.com) (Read error: 110 (Connection timed out))
  316. # [16:39] * gsnedders_ is now known as gsnedders
  317. # [16:42] * Joins: BenWard (n=BenWard@87-194-62-78.bethere.co.uk)
  318. # [16:47] * Quits: aaronlev (n=chatzill@209-6-168-245.c3-0.arl-ubr2.sbo-arl.ma.cable.rcn.com) (Read error: 104 (Connection reset by peer))
  319. # [17:02] * Quits: grimeboy (n=grimboy@85-211-246-68.dsl.pipex.com) (Remote closed the connection)
  320. # [17:37] * Quits: BenWard (n=BenWard@87-194-62-78.bethere.co.uk)
  321. # [17:40] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  322. # [18:00] * Joins: Ducki (i=Ducki@nrdh-d9b980cb.pool.mediaWays.net)
  323. # [18:06] * Joins: aaronlev (n=chatzill@209-6-168-245.c3-0.arl-ubr2.sbo-arl.ma.cable.rcn.com)
  324. # [18:33] * Joins: ROBOd (n=robod@89.123.5.203)
  325. # [18:42] * Joins: grimboy (n=grimboy@85-211-246-68.dsl.pipex.com)
  326. # [18:42] * Joins: h3h (n=w3rd@cpe-76-88-44-219.san.res.rr.com)
  327. # [18:52] * Joins: maikmerten_ (n=maikmert@L8f9f.l.pppool.de)
  328. # [18:58] <Philip`> hsivonen: I don't see any value in forbidding nested canvases - it doesn't seem likely to be a mistake that authors will make, and it's supported in current browsers about as well as plain canvas fallback content is (i.e. it works in Firefox and Safari)
  329. # [18:59] <Philip`> I can only think of minor value in ever using nested canvases, though - I can imagine something like http://canvex.lazyilluminati.com/misc/photos.html where (in Firefox/Safari) the canvas gets replaced with its fallback content via DOM manipulation if certain JS/canvas features are missing, where it would be plausible for that fallback content to contain another canvas, but I don't expect that would be common
  330. # [19:03] <Philip`> Via http://triin.net/2006/06/12/CSS - it seems about 2% of pages style 'label'
  331. # [19:05] <Philip`> (but no idea how many just use "label { ... }" by itself, rather than ".loginform label { ... }" or whatever)
  332. # [19:06] * Philip` wonders how easy it would be to collect data about these kinds of things...
  333. # [19:10] * Quits: maikmerten (n=maikmert@L9ff5.l.pppool.de) (Read error: 113 (No route to host))
  334. # [19:11] * Quits: webben (n=benh@dip5-fw.corp.ukl.yahoo.com) (Read error: 110 (Connection timed out))
  335. # [19:15] * Quits: aaronlev (n=chatzill@209-6-168-245.c3-0.arl-ubr2.sbo-arl.ma.cable.rcn.com) (Read error: 110 (Connection timed out))
  336. # [19:17] <hsivonen> Philip`: ok. I won't suggest making nested canvases non-conforming, then
  337. # [19:34] <hsivonen> I wonder if the intra-paragraph VoiceOver navigation is different from Safare in Kestrel on purpose or if it is a bug
  338. # [19:35] <hsivonen> (I couldn't figure out how to read more than the first line of a para with VoiceOver in Kestrel)
  339. # [19:36] * Joins: tndH_ (i=Rob@adsl-87-102-72-215.karoo.KCOM.COM)
  340. # [19:39] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  341. # [19:51] * Joins: BenWard (n=BenWard@87-194-62-78.bethere.co.uk)
  342. # [19:53] * Quits: tndH (i=Rob@87.102.74.242) (Read error: 110 (Connection timed out))
  343. # [20:00] * Joins: Ducki_ (i=Ducki@nrdh-d9b980dd.pool.mediaWays.net)
  344. # [20:05] * Quits: maikmerten_ (n=maikmert@L8f9f.l.pppool.de) ("Leaving")
  345. # [20:19] * Quits: Ducki_ (i=Ducki@nrdh-d9b980dd.pool.mediaWays.net) ("Weq")
  346. # [20:23] * Quits: Ducki (i=Ducki@nrdh-d9b980cb.pool.mediaWays.net) (Read error: 113 (No route to host))
  347. # [20:24] * Joins: lll (n=lll@bl5-80-92.dsl.telepac.pt)
  348. # [20:25] * lll is now known as John
  349. # [20:26] * John is now known as LJey
  350. # [20:29] * Quits: LJey (n=lll@bl5-80-92.dsl.telepac.pt)
  351. # [20:32] * Joins: Jey (n=lll@bl5-80-92.dsl.telepac.pt)
  352. # [20:32] * Jey is now known as LJey
  353. # [20:41] * Quits: LJey (n=lll@bl5-80-92.dsl.telepac.pt)
  354. # [20:54] * Joins: aroben (n=aroben@unaffiliated/aroben)
  355. # [21:35] * Joins: aroben_ (n=aroben@unaffiliated/aroben)
  356. # [21:43] * Joins: doublec (n=doublec@203-211-86-156.ue.woosh.co.nz)
  357. # [21:58] * Quits: aroben (n=aroben@unaffiliated/aroben) (Nick collision from services.)
  358. # [21:58] * aroben_ is now known as aroben
  359. # [21:58] * Quits: doublec (n=doublec@203-211-86-156.ue.woosh.co.nz)
  360. # [22:06] <gsnedders> apparently HTML parsers are SGML parsers as they parse HTML 4.01, an SGML standard.
  361. # [22:07] <gsnedders> Whether they comply with the SGML spec is irrelevant.
  362. # [22:07] <Dashiva> heh
  363. # [22:16] * Quits: BenWard (n=BenWard@87-194-62-78.bethere.co.uk)
  364. # [22:24] * Joins: zcorpan (n=zcorpan@c-0922e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  365. # [22:26] <zcorpan> Hixie: i get a 500 internal server error for http://forums.whatwg.org/
  366. # [22:29] * Joins: webben (n=benh@dip5-fw.corp.ukl.yahoo.com)
  367. # [22:31] * Quits: weinig (n=weinig@c-67-169-182-231.hsd1.ca.comcast.net)
  368. # [22:44] * Joins: BenWard (n=BenWard@87-194-62-78.bethere.co.uk)
  369. # [22:47] * Joins: virtuelv_ (n=virtuelv@58.80-202-82.nextgentel.com)
  370. # [22:47] * tndH_ is now known as tndH
  371. # [22:47] * Quits: ROBOd (n=robod@89.123.5.203) ("http://www.robodesign.ro")
  372. # [22:50] * Quits: virtuelv_ (n=virtuelv@58.80-202-82.nextgentel.com) (Client Quit)
  373. # [23:02] <hsivonen> http://html4all.org/wiki/index.php/Open_Issues
  374. # [23:05] <zcorpan> hsivonen: looks like a list of solutions
  375. # [23:08] * Quits: grimboy (n=grimboy@85-211-246-68.dsl.pipex.com) (Read error: 110 (Connection timed out))
  376. # [23:09] * Joins: grimboy (n=grimboy@85-211-255-4.dsl.pipex.com)
  377. # [23:15] * Joins: antifuchs (n=asf@baker.boinkor.net)
  378. # [23:15] <antifuchs> hi there. the blog.whatwg.org gives me a 500 error. is the web master around? (if not, I'll just write an email)
  379. # [23:16] <gavin_> I think that's known
  380. # [23:16] <gavin_> Lachy mentioned it earlier
  381. # [23:16] <antifuchs> ah, ok
  382. # [23:17] <antifuchs> (so is the wiki, btw)
  383. # [23:20] <Philip`> So is ln.hixie.ch
  384. # [23:26] <Lachy> yeah, it appears that all sites on Hixie's server, especially the ones that aren't just serving static files, are having problems. Sometimes it gives an out of memory error.
  385. # [23:28] <Lachy> I wonder why the axis attribute is listed in their open issues list? It's totally useless for everyone and serves no practical purpose.
  386. # [23:34] * Joins: kingryan (n=kingryan@dsl081-240-149.sfo1.dsl.speakeasy.net)
  387. # [23:40] * Quits: KevinMarks (n=KevinMar@c-76-102-254-252.hsd1.ca.comcast.net) ("The computer fell asleep")
  388. # [23:42] * Joins: weinig (i=weinig@nat/apple/x-aea3d6744dd8681a)
  389. # [23:42] * Quits: zcorpan (n=zcorpan@c-0922e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  390. # [23:51] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 110 (Connection timed out))
  391. # Session Close: Mon Sep 17 00:00:00 2007

The end :)