Options:
- # Session Start: Sun Sep 16 00:00:00 2007
- # Session Ident: #whatwg
- # [00:07] <Philip`> Current status: Firefox 3 + shadow patch: 44/44 passed. Safari 3: 35/44. Opera 9.5: 12/44.
- # [00:07] * Joins: weinig (i=weinig@nat/apple/x-51ea15cb09132093)
- # [00:08] <Philip`> (The failures in Safari are (in my opinion) definitely bugs, rather than just being differences with the (proposed) specification)
- # [00:16] * Quits: Ducki (i=Ducki@nrdh-d9b980dc.pool.mediaWays.net) (Read error: 113 (No route to host))
- # [00:32] * Quits: virtuelv_ (n=virtuelv@58.80-202-82.nextgentel.com) ("Leaving")
- # [00:41] * Quits: Ducki_ (i=Ducki@nrdh-d9b980d2.pool.mediaWays.net) (Read error: 113 (No route to host))
- # [00:45] * Joins: tantek (n=tantek@adsl-63-203-221-50.dsl.snfc21.pacbell.net)
- # [00:52] * Quits: dev0 (i=Tobias@unaffiliated/icefox0) ("dev0 has no reason")
- # [01:00] * Joins: rob1n (n=emp@unaffiliated/rob1n)
- # [01:00] * Parts: rob1n (n=emp@unaffiliated/rob1n) ("Leaving")
- # [01:32] * Quits: tantek (n=tantek@adsl-63-203-221-50.dsl.snfc21.pacbell.net)
- # [01:57] * Joins: om_sleep (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
- # [01:59] * om_sleep is now known as othermaciej
- # [02:07] * Joins: webben (n=benh@82.153.85.49)
- # [02:18] * Quits: hasather (n=hasather@90-227-221-48-no62.tbcn.telia.com) (Remote closed the connection)
- # [02:23] * Quits: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com) (Read error: 110 (Connection timed out))
- # [02:41] * Joins: aaronlev (n=chatzill@209-6-168-245.c3-0.arl-ubr2.sbo-arl.ma.cable.rcn.com)
- # [03:05] * Quits: weinig (i=weinig@nat/apple/x-51ea15cb09132093)
- # [03:18] * Joins: doublec (n=doublec@202-74-219-89.ue.woosh.co.nz)
- # [03:20] <Lachy> http://adactio.com/journal/1343
- # [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
- # [03:39] * Joins: h3h (n=w3rd@cpe-76-88-44-219.san.res.rr.com)
- # [03:43] * Quits: doublec (n=doublec@202-74-219-89.ue.woosh.co.nz)
- # [03:47] * Joins: mpt (n=mpt@219.234.180.199)
- # [03:47] * Quits: mpt (n=mpt@219.234.180.199) (Client Quit)
- # [03:50] * Joins: polin8 (n=brian@c-75-71-72-175.hsd1.co.comcast.net)
- # [04:07] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
- # [04:52] * Joins: weinig (n=weinig@c-67-169-182-231.hsd1.ca.comcast.net)
- # [04:52] * Joins: doublec (n=doublec@203-211-102-83.ue.woosh.co.nz)
- # [04:59] <othermaciej> Lachy: do you have any suggestions for a "Degrade Gracefully" example I could add to replace the section/block one?
- # [05:00] <othermaciej> Lachy: I'd like an example of an element that can be pretty much emulated with CSS styling
- # [05:00] <Lachy> maybe <m>
- # [05:00] <othermaciej> does HTML5 have any new block-level elements that are only allowed inline contents?
- # [05:01] <othermaciej> I'm not sure what the expected presentation of <m> is, if any
- # [05:01] <Lachy> I would expect a yellow highlight or something
- # [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
- # [05:04] <othermaciej> I'm going through the elements at http://simon.html5.org/html5-elements
- # [05:04] <Lachy> that's what I'm looking through too
- # [05:04] <othermaciej> hmmm
- # [05:04] <othermaciej> can <figure> be handled properly with just display: block?
- # [05:05] <Lachy> maybe
- # [05:05] <othermaciej> it's not allowed any block children
- # [05:06] <othermaciej> the legend doesn't really display in what seems like a useful way by default
- # [05:06] <Lachy> unfortunately, <legend> has problems in some browsers. it doesn't appear in the DOM in Firefox
- # [05:08] * Quits: polin8 (n=brian@c-75-71-72-175.hsd1.co.comcast.net) (Client Quit)
- # [05:08] <Lachy> and IE isn't going to play nicely with any new element at all
- # [05:08] <othermaciej> the legend element isn't in the DOM in Safari either
- # [05:10] <othermaciej> it seems like using a new element for a figure caption instead of <legend> would work better
- # [05:10] <othermaciej> seems like <legend> will have the same problem for <details> as well
- # [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))
- # [05:10] <othermaciej> I can't figure out how to get this to style reasonably in any browser:
- # [05:11] <othermaciej> <figure><img src=chair.jpg><legend>a chair</legend></figure>
- # [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
- # [05:11] <othermaciej> (what I'd like to do is make the legend display on its own line horizontally centered)
- # [05:12] <Lachy> wrong link...
- # [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
- # [05:12] <othermaciej> I can see that adding a span would work
- # [05:12] <othermaciej> I was hoping there might be a better way
- # [05:13] * Quits: tndH (i=Rob@87.102.74.242) ("ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508]")
- # [05:13] <othermaciej> a new element in place of <legend> would make it simpler at least in SafOperFox
- # [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?
- # [05:14] <othermaciej> it probably can be, but a new element would already work in today's browsers, so degrades better
- # [05:14] <othermaciej> <legend> is given special rendering behavior in a <fieldset> that can't be expressed with CSS
- # [05:15] <othermaciej> browsers probably ignore it in other places as a way to avoid causing problems with that in other places
- # [05:15] <Lachy> I know, that may cause some problems if someone tries to use a figure inside a fieldset
- # [05:16] <othermaciej> it seems pretty hard to center-align the caption under the image as well
- # [05:16] <othermaciej> this is the best I've got:
- # [05:16] <othermaciej> figure { display: block; float: left;}
- # [05:16] <othermaciej> figure legend, figure span { display: block; text-align: center; }
- # [05:16] <othermaciej> but floating by default is probably not desirable
- # [05:17] * othermaciej tries to remember what else will cause shrink-wrap
- # [05:17] <Lachy> no, definately not a good idea to float by default
- # [05:17] <Lachy> inline-block;
- # [05:17] <Lachy> display: table-cell;
- # [05:17] <othermaciej> does mozilla support inline-block yet?
- # [05:17] <othermaciej> ah, table-cell
- # [05:17] <othermaciej> well, that won't work in IE probably
- # [05:18] <Lachy> IE has limited support for inline-block
- # [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
- # [05:19] <othermaciej> but in general inline-block seems good since it will make the image + caption work basically like a replaced element woud
- # [05:19] <othermaciej> *would
- # [05:20] * Joins: Lachy_ (n=lachlan_@124-170-114-235.dyn.iinet.net.au)
- # [05:20] * Parts: Lachy_ (n=lachlan_@124-170-114-235.dyn.iinet.net.au)
- # [05:21] <othermaciej> display: table-cell breaks the centering in Opera, but not Safari or Firefox
- # [05:22] <Lachy> this works in Firefox and Opera
- # [05:22] <othermaciej> ok, here's one that works in all three:
- # [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
- # [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
- # [05:22] <Lachy> pan%3ECaption%3C%2Fspan%3E%3C%2Flegend%3E%3C%2Ffigure%3E
- # [05:22] <othermaciej> yours got split into multiple lines
- # [05:22] <Lachy> yeah, that's the same thing :-)
- # [05:22] <Lachy> mine has pretty colours!
- # [05:22] <othermaciej> I'm not sure if that would work in IE
- # [05:22] <Lachy> download it from the clipboard
- # [05:23] <othermaciej> I'll fire up Windows
- # [05:23] <Lachy> doesn't work well in IE
- # [05:24] <Lachy> mostly because it treats "FIGURE", "/FIGURE", "LEGEND" and "/LEGEND" as distinct elements, that are all siblings of each other
- # [05:26] <Lachy> Hixie's server is having serious trouble. even is clipboard is generating intermittent HTTP 500 errors
- # [05:27] <othermaciej> ick
- # [05:28] <othermaciej> Lachy: IE's behavior on unknown elements seems to be a pretty serious impediment to adding new elements
- # [05:28] <othermaciej> even what Firefox does is pretty bad in a lot of cases
- # [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
- # [05:28] <Lachy> yeah, but there's nothing we can do about it
- # [05:28] <Lachy> unless we want to replace <section>, etc. with <div role=section>
- # [05:29] <Lachy> which I don't want to do
- # [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
- # [05:30] <othermaciej> which seems to be the major issue
- # [05:30] <othermaciej> (change it well in advance of broad HTML5 adoption, that is)
- # [05:30] <Lachy> IIRC, the HTML5 parsing algorithm says unknown elements need to be treated as inlines
- # [05:31] <othermaciej> does that mean it would require that block element open tags terminate them?
- # [05:31] <othermaciej> that would (obviously) be a bad requirement
- # [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
- # [05:32] <othermaciej> that's good
- # [05:32] <Lachy> assuming that implementation is correct, yes
- # [05:32] <othermaciej> so anyway, I guess <figure> is not a good example
- # [05:32] <othermaciej> given IE's current behavior, I'm not sure any new element can be handled reasonably in existing versions of IE
- # [05:32] <Lachy> why not? We got good results in 3 out of 4
- # [05:33] <othermaciej> well, having to add the span is ugly
- # [05:33] <othermaciej> and the style rule is kinda complicated
- # [05:34] <Lachy> IE's handling could be patched using a script to modify the dom
- # [05:36] <othermaciej> true, but that also seems to be the case for <section> in Firefox and IE
- # [05:36] <othermaciej> (though the script would be nontrivial)
- # [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.
- # [05:38] <Lachy> so it's been done before
- # [05:38] <othermaciej> well, it's a bit easier in IE because the end tag also ends up as an element in the DOM
- # [05:38] <Lachy> yep
- # [05:38] <othermaciej> doing the fixup in Firefox would require some marker for the end of the element
- # [05:39] * Joins: polin8 (n=brian@c-75-71-72-175.hsd1.co.comcast.net)
- # [05:39] <othermaciej> I think I'll take the example out for now
- # [05:39] <othermaciej> there doesn't seem to be any element that can be adequately handled just with a CSS rule currently
- # [05:39] <othermaciej> except maybe <m>, but I'm not sure what default rendering would be appropriate
- # [05:40] <Lachy> m { background: yellow; }
- # [05:40] <Lachy> you don't need to demonstrate the default styling, only that it's possible for authors to provide their own
- # [05:41] <othermaciej> I think the background: yellow thing wouldn't even work in IE
- # [05:41] <othermaciej> though I guess by that standard, I'm not sure if IE supports attribute selectors either
- # [05:43] <Lachy> IE7 supports attribute selectors
- # [07:48] * Joins: kfish (n=conrad@61.194.21.25)
- # [07:57] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
- # [08:07] <othermaciej> just sent email about the Mozilla issue
- # [08:07] <othermaciej> apparently there was already a bug filed some time ago (by Hixie)
- # [08:18] * Joins: aroben_ (n=aroben@unaffiliated/aroben)
- # [08:21] <gavins> https://bugzilla.mozilla.org/show_bug.cgi?id=311366
- # [08:22] <othermaciej> yes, I cited that in my email
- # [08:23] <gavins> email to the list?
- # [08:23] <gavins> (sorry, lacking context)
- # [08:23] * gavins is now known as gavin
- # [08:25] <gavin_> ah, yes
- # [08:27] <othermaciej> to public-html
- # [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
- # [08:28] <gavin_> yeah
- # [08:34] <othermaciej> Lachy: does IE7 still handle <abbr> as an unknown element?
- # [08:35] <Lachy> othermaciej, no, IE7 supports it properly
- # [08:35] <othermaciej> ok cool
- # [08:38] * Quits: polin8 (n=brian@c-75-71-72-175.hsd1.co.comcast.net) (Client Quit)
- # [08:47] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 110 (Connection timed out))
- # [08:47] * aroben_ is now known as aroben
- # [09:01] <othermaciej> Lachy: hmm, I think putting text-align: center on <figure> might be about the right thing
- # [09:03] <Lachy> othermaciej, show me a demo?
- # [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'
- # [09:08] <othermaciej> I'm not sure if it's right for the figure to shrink to fit the image or not
- # [09:08] <othermaciej> it's supposed to represent a paragraph
- # [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
- # [09:09] <othermaciej> but I don't think there's any way to handle it without adding a span or something inside the <legend>
- # [09:09] <othermaciej> hmm
- # [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
- # [09:10] <Lachy> is that a bad thing?
- # [09:10] <othermaciej> well, yeah
- # [09:11] <othermaciej> why allow both <figure><img><legend>...</legend></figure> and <figure><legend>...</legend><img></figure> if they do the same thing?
- # [09:11] <othermaciej> whereas other elements that take a <legend> require it to be first
- # [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
- # [09:14] * Quits: kfish (n=conrad@61.194.21.25) ("Pike!")
- # [09:21] <Lachy> I have a solution to that
- # [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
- # [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
- # [09:21] <Lachy> (if that split across several lines, download it from the clipboard)
- # [09:23] <othermaciej> that's not bad
- # [09:37] <Lachy> that doesn't work in Opera because legend is in the DOM as an empty element.
- # [09:38] <Lachy> These styles work:
- # [09:38] <Lachy> figure { display: table; }
- # [09:38] <Lachy> figure legend, figure span { display: table-caption; text-align: center; caption-side: bottom; }
- # [09:38] <Lachy> figure legend:first-child, figure legend:first-child+span, figure span:first-child { caption-side: top; }
- # [09:39] <Lachy> though I still haven't found anything that will get it working in IE
- # [09:41] * Quits: webben (n=benh@82.153.85.49) (Remote closed the connection)
- # [09:42] * Joins: webben (n=benh@dip5-fw.corp.ukl.yahoo.com)
- # [09:43] <othermaciej> I don't think there's any way to make it work in IE without script
- # [09:46] <othermaciej> that latest set of rules seems to give consistent and useful rendering in SafOperFox
- # [09:46] * Quits: h3h (n=w3rd@cpe-76-88-44-219.san.res.rr.com)
- # [09:47] <othermaciej> hmmm
- # [09:47] <othermaciej> Lachy: would there be any problem with using <label> instead of <legend>?
- # [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
- # [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%
- # [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.
- # [09:50] <othermaciej> the DOM for that is right even in IE
- # [09:52] <othermaciej> IE doesn't support CSS tables, right?
- # [09:52] <Lachy> well, the DOM is as close as we're going to get it without replacing figure too.
- # [09:52] <Lachy> no, it doesn't support css tables
- # [09:53] <othermaciej> the DOM is real close anyway; required script fallback would be limited to putting the <figure> contents back inside the figure
- # [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
- # [09:54] <Lachy> that would create a lot of headaches as they modified their style sheets
- # [09:56] <othermaciej> true, but they'd need to add a rule for "figure label", so that can undo changes in that rule
- # [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
- # [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
- # [10:00] * Joins: ROBOd (n=robod@89.123.35.166)
- # [10:00] * Joins: Ducki (i=Ducki@nrdh-d9b980c3.pool.mediaWays.net)
- # [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)
- # [10:01] <othermaciej> the problems with <legend> go beyond styling
- # [10:01] <othermaciej> you need tricky script-based fixup to be able to even put event listeners on the caption
- # [10:01] <othermaciej> or to find figure captions in the DOM
- # [10:02] <othermaciej> anyway I'll mention this objection in my email
- # [10:02] <Lachy> ok
- # [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.
- # [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
- # [10:34] <Lachy> http://esw.w3.org/topic/HTML/ThoughtExperimentInGracefulDegradation
- # [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
- # [10:36] <othermaciej> the browser test results on that page are useful though
- # [10:36] <othermaciej> wow
- # [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
- # [10:36] <othermaciej> that's some insane use of type=""
- # [10:37] <othermaciej> using new elements not only reduces complexity but also improves semantics
- # [10:37] <othermaciej> Since in practice "a video" is more meaningful than "an object"
- # [10:37] <Lachy> indeed. We need to cure divitis, not encourage it
- # [10:38] * Quits: doublec (n=doublec@203-211-102-83.ue.woosh.co.nz)
- # [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
- # [10:39] <othermaciej> application/x-canvas also seems like a bad idea, since it doesn't in fact represent a content type
- # [10:39] <othermaciej> and also the <source> element is a significantly better approach than <object>'s fallback model
- # [10:41] <Lachy> maybe we should add this to the wiki http://esw.w3.org/topic/HTML/AddedElementVideo
- # [10:41] <Lachy> anyway, dinner time
- # [10:41] <Lachy> bbl
- # [10:42] <othermaciej> later
- # [10:48] <Lachy> I'm back (the kitchen's in use and dinner needs to defrost)
- # [10:52] * Joins: doublec (n=doublec@202-74-220-77.ue.woosh.co.nz)
- # [10:57] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
- # [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
- # [11:03] <Philip`> Doesn't work when you have <canvas><canvas>A</canvas>B</canvas>, though
- # [11:03] <Philip`> (but that doesn't work in Opera either)
- # [11:10] <hsivonen> Philip`: should doc conformance ban nested canvas in your opinion?
- # [11:17] <Lachy> hmm. <description> might be a reasonable alternative to <legend> for captions
- # [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
- # [11:19] <Lachy> so, yes, I think it should be banned for conformance
- # [11:19] <othermaciej> <description> is not bad
- # [11:20] <Lachy> Ben's other suggestion to use <title> won't work, since that would mess with legacy handling of <title>
- # [11:20] <othermaciej> but it's a bit wordy and a bit inaccurate
- # [11:20] <othermaciej> agreed on <title>
- # [11:20] <othermaciej> on <details> especially, it's definitely a label (or perhaps a caption, stretching it), not a description
- # [11:22] <Lachy> I'd never heard of "rubric" before, so that's not a good option either.
- # [11:24] <othermaciej> it's always possible to add an arbitrary marker of disctionction, like <caption2>
- # [11:25] <othermaciej> but that's kind of lame
- # [11:25] <Lachy> maybe something like <cap>
- # [11:26] <othermaciej> <capt>, <cptn>
- # [11:26] <othermaciej> or, just to be silly, <c>
- # [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
- # [11:27] <Lachy> capt. is generally the abbreviation of captain
- # [11:27] <Lachy> yeah, that's the advantage the XHTML2 group has - they don't care about compatibility
- # [11:30] <othermaciej> I wouldn't consider that an advantage
- # [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
- # [11:33] <Lachy> thesaurus.com lists these synonyms: explanation, head, inscription, legend, rubric, subtitle, title, underline
- # [11:34] <othermaciej> yeah, that's where I looked
- # [11:34] <othermaciej> I ruled out title, underline, legend and head for various reasons that should be obvious
- # [11:34] <Lachy> description, descriptor, headline, label, lemma
- # [11:35] <Lachy> descriptor might work
- # [11:35] <Lachy> or <desc>
- # [11:37] <othermaciej> another possibility is two new elements, say <figcaption> and <detailslabel>
- # [11:37] <othermaciej> I'm not sure I like any of these a lot more than <label>
- # [11:38] <Lachy> I really don't like <label> for the reasons I gave before
- # [11:39] <othermaciej> it's true that one or more new elements would be better for pragmatic reasons
- # [11:39] <othermaciej> and would have basically no disadvantage compared to <legend>
- # [11:39] <othermaciej> playing off of <label>, another possibility is <tag>
- # [11:39] <othermaciej> but that might just confuse people
- # [11:40] <Lachy> <tagline>
- # [11:40] <Lachy> nah, doesn't quite fit its definition
- # [11:42] <Lachy> How about just using <figure><img/><p>Caption</p></figure>?
- # [11:46] <othermaciej> I'd guess the default and author styling for p would both interfere with that
- # [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
- # [11:49] <Lachy> but I could be wrong, people do all sorts of crazy things
- # [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)?
- # [11:53] <Lachy> gsnedders, the closest you can get is narrowing it down by date, subject and author
- # [11:53] <gsnedders> Lachy: that was my fear
- # [11:54] <gsnedders> silly othermaciej posting so many things in a single thread…
- # [11:54] <othermaciej> gsnedders: it doesn't look like a single thread to me...
- # [11:54] <Lachy> the alternative is to download the gzip'd mbox files and search those
- # [11:54] <gsnedders> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-June/011973.html
- # [11:55] <gsnedders> that's what I was looking for
- # [11:56] <othermaciej> I shouldn't have posted anything on *that* thread
- # [11:56] <gsnedders> (I had been looking for it for around five minutes before asking the above question)
- # [12:03] * Joins: Ducki_ (i=Ducki@nrdh-d9b980c9.pool.mediaWays.net)
- # [12:05] <Lachy> othermaciej, why? did that thread turn into a flamewar or something?
- # [12:05] <othermaciej> I remember there being a lot of flamage around that topic
- # [12:06] <gsnedders> A lot.
- # [12:07] <Lachy> yeah, that's what happens when patents, laywers, and free-software advocates get involved
- # [12:14] * Joins: hasather (n=hasather@90-227-221-48-no62.tbcn.telia.com)
- # [12:21] * Quits: Ducki (i=Ducki@nrdh-d9b980c3.pool.mediaWays.net) (Read error: 113 (No route to host))
- # [12:24] * Quits: doublec (n=doublec@202-74-220-77.ue.woosh.co.nz)
- # [12:36] * Joins: maikmerten (n=maikmert@L9ff5.l.pppool.de)
- # [12:38] * Joins: tndH_ (i=Rob@87.102.74.242)
- # [12:39] * tndH_ is now known as tndH
- # [13:42] * Joins: Ducki (i=Ducki@nrdh-d9b9806b.pool.mediaWays.net)
- # [13:49] * Quits: Ducki_ (i=Ducki@nrdh-d9b980c9.pool.mediaWays.net) (Read error: 113 (No route to host))
- # [13:58] * Joins: peepo (n=Jay@host86-153-137-94.range86-153.btcentralplus.com)
- # [14:01] * Joins: Ducki_ (n=Ducki@nrdh-d9b980d1.pool.mediaWays.net)
- # [14:11] * Joins: aaronlev (n=chatzill@209-6-168-245.c3-0.arl-ubr2.sbo-arl.ma.cable.rcn.com)
- # [14:13] * Joins: BenWard (n=BenWard@87-194-62-78.bethere.co.uk)
- # [14:22] * Quits: Ducki (i=Ducki@nrdh-d9b9806b.pool.mediaWays.net) (Read error: 113 (No route to host))
- # [14:40] * Quits: peepo (n=Jay@host86-153-137-94.range86-153.btcentralplus.com) ("later")
- # [14:47] * Quits: BenWard (n=BenWard@87-194-62-78.bethere.co.uk)
- # [14:56] * Quits: Ducki_ (n=Ducki@nrdh-d9b980d1.pool.mediaWays.net) (Read error: 113 (No route to host))
- # [15:07] * Joins: hasather_ (n=hasather@90-227-221-48-no62.tbcn.telia.com)
- # [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))
- # [15:16] * Quits: ROBOd (n=robod@89.123.35.166) ("http://www.robodesign.ro")
- # [15:23] * Quits: hasather (n=hasather@90-227-221-48-no62.tbcn.telia.com) (Read error: 110 (Connection timed out))
- # [15:58] * Joins: aaronlev (n=chatzill@209-6-168-245.c3-0.arl-ubr2.sbo-arl.ma.cable.rcn.com)
- # [16:31] * Joins: gsnedders_ (n=gsnedder@host86-137-237-196.range86-137.btcentralplus.com)
- # [16:34] <hsivonen> hmm. validator.nu got killed by the kernel :-(
- # [16:38] * Quits: gsnedders (n=gsnedder@host86-139-120-102.range86-139.btcentralplus.com) (Read error: 110 (Connection timed out))
- # [16:39] * gsnedders_ is now known as gsnedders
- # [16:42] * Joins: BenWard (n=BenWard@87-194-62-78.bethere.co.uk)
- # [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))
- # [17:02] * Quits: grimeboy (n=grimboy@85-211-246-68.dsl.pipex.com) (Remote closed the connection)
- # [17:37] * Quits: BenWard (n=BenWard@87-194-62-78.bethere.co.uk)
- # [17:40] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
- # [18:00] * Joins: Ducki (i=Ducki@nrdh-d9b980cb.pool.mediaWays.net)
- # [18:06] * Joins: aaronlev (n=chatzill@209-6-168-245.c3-0.arl-ubr2.sbo-arl.ma.cable.rcn.com)
- # [18:33] * Joins: ROBOd (n=robod@89.123.5.203)
- # [18:42] * Joins: grimboy (n=grimboy@85-211-246-68.dsl.pipex.com)
- # [18:42] * Joins: h3h (n=w3rd@cpe-76-88-44-219.san.res.rr.com)
- # [18:52] * Joins: maikmerten_ (n=maikmert@L8f9f.l.pppool.de)
- # [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)
- # [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
- # [19:03] <Philip`> Via http://triin.net/2006/06/12/CSS - it seems about 2% of pages style 'label'
- # [19:05] <Philip`> (but no idea how many just use "label { ... }" by itself, rather than ".loginform label { ... }" or whatever)
- # [19:06] * Philip` wonders how easy it would be to collect data about these kinds of things...
- # [19:10] * Quits: maikmerten (n=maikmert@L9ff5.l.pppool.de) (Read error: 113 (No route to host))
- # [19:11] * Quits: webben (n=benh@dip5-fw.corp.ukl.yahoo.com) (Read error: 110 (Connection timed out))
- # [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))
- # [19:17] <hsivonen> Philip`: ok. I won't suggest making nested canvases non-conforming, then
- # [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
- # [19:35] <hsivonen> (I couldn't figure out how to read more than the first line of a para with VoiceOver in Kestrel)
- # [19:36] * Joins: tndH_ (i=Rob@adsl-87-102-72-215.karoo.KCOM.COM)
- # [19:39] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
- # [19:51] * Joins: BenWard (n=BenWard@87-194-62-78.bethere.co.uk)
- # [19:53] * Quits: tndH (i=Rob@87.102.74.242) (Read error: 110 (Connection timed out))
- # [20:00] * Joins: Ducki_ (i=Ducki@nrdh-d9b980dd.pool.mediaWays.net)
- # [20:05] * Quits: maikmerten_ (n=maikmert@L8f9f.l.pppool.de) ("Leaving")
- # [20:19] * Quits: Ducki_ (i=Ducki@nrdh-d9b980dd.pool.mediaWays.net) ("Weq")
- # [20:23] * Quits: Ducki (i=Ducki@nrdh-d9b980cb.pool.mediaWays.net) (Read error: 113 (No route to host))
- # [20:24] * Joins: lll (n=lll@bl5-80-92.dsl.telepac.pt)
- # [20:25] * lll is now known as John
- # [20:26] * John is now known as LJey
- # [20:29] * Quits: LJey (n=lll@bl5-80-92.dsl.telepac.pt)
- # [20:32] * Joins: Jey (n=lll@bl5-80-92.dsl.telepac.pt)
- # [20:32] * Jey is now known as LJey
- # [20:41] * Quits: LJey (n=lll@bl5-80-92.dsl.telepac.pt)
- # [20:54] * Joins: aroben (n=aroben@unaffiliated/aroben)
- # [21:35] * Joins: aroben_ (n=aroben@unaffiliated/aroben)
- # [21:43] * Joins: doublec (n=doublec@203-211-86-156.ue.woosh.co.nz)
- # [21:58] * Quits: aroben (n=aroben@unaffiliated/aroben) (Nick collision from services.)
- # [21:58] * aroben_ is now known as aroben
- # [21:58] * Quits: doublec (n=doublec@203-211-86-156.ue.woosh.co.nz)
- # [22:06] <gsnedders> apparently HTML parsers are SGML parsers as they parse HTML 4.01, an SGML standard.
- # [22:07] <gsnedders> Whether they comply with the SGML spec is irrelevant.
- # [22:07] <Dashiva> heh
- # [22:16] * Quits: BenWard (n=BenWard@87-194-62-78.bethere.co.uk)
- # [22:24] * Joins: zcorpan (n=zcorpan@c-0922e353.1451-1-64736c12.cust.bredbandsbolaget.se)
- # [22:26] <zcorpan> Hixie: i get a 500 internal server error for http://forums.whatwg.org/
- # [22:29] * Joins: webben (n=benh@dip5-fw.corp.ukl.yahoo.com)
- # [22:31] * Quits: weinig (n=weinig@c-67-169-182-231.hsd1.ca.comcast.net)
- # [22:44] * Joins: BenWard (n=BenWard@87-194-62-78.bethere.co.uk)
- # [22:47] * Joins: virtuelv_ (n=virtuelv@58.80-202-82.nextgentel.com)
- # [22:47] * tndH_ is now known as tndH
- # [22:47] * Quits: ROBOd (n=robod@89.123.5.203) ("http://www.robodesign.ro")
- # [22:50] * Quits: virtuelv_ (n=virtuelv@58.80-202-82.nextgentel.com) (Client Quit)
- # [23:02] <hsivonen> http://html4all.org/wiki/index.php/Open_Issues
- # [23:05] <zcorpan> hsivonen: looks like a list of solutions
- # [23:08] * Quits: grimboy (n=grimboy@85-211-246-68.dsl.pipex.com) (Read error: 110 (Connection timed out))
- # [23:09] * Joins: grimboy (n=grimboy@85-211-255-4.dsl.pipex.com)
- # [23:15] * Joins: antifuchs (n=asf@baker.boinkor.net)
- # [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)
- # [23:16] <gavin_> I think that's known
- # [23:16] <gavin_> Lachy mentioned it earlier
- # [23:16] <antifuchs> ah, ok
- # [23:17] <antifuchs> (so is the wiki, btw)
- # [23:20] <Philip`> So is ln.hixie.ch
- # [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.
- # [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.
- # [23:34] * Joins: kingryan (n=kingryan@dsl081-240-149.sfo1.dsl.speakeasy.net)
- # [23:40] * Quits: KevinMarks (n=KevinMar@c-76-102-254-252.hsd1.ca.comcast.net) ("The computer fell asleep")
- # [23:42] * Joins: weinig (i=weinig@nat/apple/x-aea3d6744dd8681a)
- # [23:42] * Quits: zcorpan (n=zcorpan@c-0922e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
- # [23:51] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 110 (Connection timed out))
- # Session Close: Mon Sep 17 00:00:00 2007
The end :)