/irc-logs / freenode / #whatwg / 2009-08-31 / end

Options:

# Session Start: Mon Aug 31 00:00:00 2009
# Session Ident: #whatwg
# [00:02] <TabAtkins> Hrm, trying to set up delegation for openid. Looks like I might not be able to delegate to my google id.
# [00:02] <TabAtkins> annevk2: Just how does your id page work?
# [00:05] * Quits: heycam (n=cam@210-84-56-211.dyn.iinet.net.au) ("bye")
# [00:23] * Quits: k0rnel (n=k0rnel@147.175.167.202) (Read error: 110 (Connection timed out))
# [00:28] * weinig is now known as weinig|away
# [00:35] * Quits: annodomini (n=lambda@wikipedia/lambda) (Client Quit)
# [00:42] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
# [01:06] * Quits: dbaron (n=dbaron@pool-98-111-140-154.phlapa.fios.verizon.net) ("8403864 bytes have been tenured, next gc will be global.")
# [01:20] * Quits: ttepasse (n=ttepas--@p5B0153FC.dip.t-dialin.net) ("?Q")
# [02:18] * Quits: shepazu (n=schepers@31-33-83.wireless.csail.mit.edu)
# [02:19] * Quits: MikeSmith (n=MikeSmit@31-35-163.wireless.csail.mit.edu) ("Tomorrow to fresh woods, and pastures new.")
# [02:20] * Joins: annodomini (n=lambda@c-75-69-96-104.hsd1.nh.comcast.net)
# [02:35] * Joins: wakaba_1 (n=wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
# [02:35] * Quits: wakaba_0 (n=wakaba_@217.63.138.58.dy.bbexcite.jp) (Read error: 110 (Connection timed out))
# [02:39] * Quits: yutak_home (n=kee@ZD094246.ppp.dion.ne.jp) ("Ex-Chat")
# [02:54] * Joins: inlogic (n=inlogic@217.129.104.92)
# [02:54] <inlogic> Hey all
# [02:56] * Parts: inlogic (n=inlogic@217.129.104.92)
# [03:06] * Joins: SamerZ (n=SamerZ@CPE0024369ef3ab-CM001ac35cd4b4.cpe.net.cable.rogers.com)
# [03:14] * Joins: tkent (n=tkent@220.109.219.244)
# [03:14] <TabAtkins> annevk2: Never mind, got mine working anyway. I'd still be interested in the details, though.
# [03:29] * Joins: tantek (n=tantek@12.140.254.34)
# [03:31] * Quits: Evolver (n=dmitrij@83.241.47.185) (Read error: 145 (Connection timed out))
# [03:36] <tantek> TabAtkins - re: collecting for [css3-ui] - even better is if you maintain a wiki page of all your proposals. When it comes time to go through them, wading through www-style will take a while.
# [03:52] <TabAtkins> tantek: Do you prefer any particular location? I could also just wait for you to come active again - I'm an Invited Expert now, so I'll probably see you in the telecon.
# [03:52] <tantek> oh congrats!
# [03:52] <TabAtkins> ^_^
# [03:53] <tantek> (in CSS WG I presume)
# [03:53] <TabAtkins> Yes.
# [03:53] <tantek> I think fantasai starated a wiki for the working group a few years ago
# [03:53] <tantek> that would be a great place for it
# [03:53] <TabAtkins> Ah, over there.
# [03:53] <TabAtkins> Sure.
# [04:02] * Quits: tantek (n=tantek@12.140.254.34)
# [04:12] <Hixie> looks like U+23CE and U+231B are missing from the fonts we're using to print the pdf versions of the spec
# [04:21] * weinig|away is now known as weinig
# [04:30] * Joins: tantek (n=tantek@adsl-71-134-227-69.dsl.pltn13.pacbell.net)
# [05:14] * Quits: erikvold (n=erikvvol@96.49.192.204)
# [05:23] * Joins: cying (n=cying@adsl-75-18-220-22.dsl.pltn13.sbcglobal.net)
# [06:14] * Joins: shepazu (n=schepers@72-255-30-45.client.stsn.net)
# [06:27] * Quits: tantek (n=tantek@adsl-71-134-227-69.dsl.pltn13.pacbell.net)
# [06:31] * Quits: TabAtkins (n=chatzill@99-35-179-251.lightspeed.hstntx.sbcglobal.net) (Read error: 110 (Connection timed out))
# [06:41] * Joins: tantek (n=tantek@76-191-210-116.dsl.dynamic.sonic.net)
# [07:06] * Joins: k0rnel (n=k0rnel@147.175.167.202)
# [07:34] * Quits: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley) ("This computer has gone to sleep")
# [07:52] * Quits: SamerZ (n=SamerZ@CPE0024369ef3ab-CM001ac35cd4b4.cpe.net.cable.rogers.com)
# [07:54] * Joins: SamerZ (n=SamerZ@CPE0024369ef3ab-CM001ac35cd4b4.cpe.net.cable.rogers.com)
# [07:54] * Quits: SamerZ (n=SamerZ@CPE0024369ef3ab-CM001ac35cd4b4.cpe.net.cable.rogers.com) (Client Quit)
# [07:56] * Joins: KevinMarks (n=KevinMar@c-67-164-14-96.hsd1.ca.comcast.net)
# [07:56] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
# [08:00] * Joins: SamerZ (n=SamerZ@CPE0024369ef3ab-CM001ac35cd4b4.cpe.net.cable.rogers.com)
# [08:01] * Joins: Mrmil (n=ut_ollie@host-77-236-204-8.blue4.cz)
# [08:02] * Quits: annodomini (n=lambda@wikipedia/lambda) (Client Quit)
# [08:11] * Joins: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de)
# [08:14] * Quits: tantek (n=tantek@76-191-210-116.dsl.dynamic.sonic.net) (Read error: 110 (Connection timed out))
# [08:23] * Quits: cying (n=cying@adsl-75-18-220-22.dsl.pltn13.sbcglobal.net)
# [10:25] * Disconnected
# [17:09] * Attempting to rejoin channel #whatwg
# [17:09] * Rejoined channel #whatwg
# [17:09] * Topic is 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Vennligst legg igjen din følelse av logikken ved døren, takk!'
# [17:09] * Set by Lachy on Wed Aug 26 20:57:24
# [19:09] * Disconnected
# [19:10] * Attempting to rejoin channel #whatwg
# [19:10] * Rejoined channel #whatwg
# [19:10] * Topic is 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Vennligst legg igjen din følelse av logikken ved døren, takk!'
# [19:10] * Set by Lachy on Wed Aug 26 20:57:24
# [19:12] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net) (Read error: 54 (Connection reset by peer))
# [19:12] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
# [19:17] * Joins: jlebar (n=jlebar@nat/mozilla/x-sqetkemyhteevfcn)
# [19:23] * Quits: cying (n=cying@70.90.171.153) (Read error: 110 (Connection timed out))
# [19:23] * cying_ is now known as cying
# [19:25] * Joins: annodomini (n=lambda@130.189.179.215)
# [19:25] * Quits: cying (n=cying@70.90.171.153)
# [19:26] * Joins: weinig (n=weinig@17.246.19.176)
# [19:28] * Joins: inlogic (n=inlogic@bl8-14-67.dsl.telepac.pt)
# [19:30] * Joins: zcorpan_ (n=zcorpan@c83-252-193-59.bredband.comhem.se)
# [19:30] * Joins: KevinMarks (n=KevinMar@157.22.22.46)
# [19:38] * Joins: scherkus (n=scherkus@74.125.59.65)
# [19:38] * Joins: ap_ (n=ap@17.246.19.164)
# [19:38] * Quits: zcorpan_ (n=zcorpan@c83-252-193-59.bredband.comhem.se) (Read error: 104 (Connection reset by peer))
# [19:44] * Joins: bgalbraith (n=bgalbrai@nat/mozilla/x-bhlpvjafaobxtzgz)
# [19:46] * Quits: ap (n=ap@17.203.14.219) (Read error: 145 (Connection timed out))
# [19:47] * Quits: ap_ (n=ap@17.246.19.164) (Remote closed the connection)
# [19:47] * Joins: ap (n=ap@nat/apple/x-pncjuwmncvzlduyk)
# [19:53] <annevk2> gotto love how http://www.mozilla.org/projects/intl/UniversalCharsetDetection.html has incorrect characters
# [20:00] * Quits: jlebar (n=jlebar@nat/mozilla/x-sqetkemyhteevfcn) ("Leaving")
# [20:02] * Joins: maikmerten (n=maikmert@BAE15e9.bae.pppool.de)
# [20:07] * Joins: jlebar (n=jlebar@nat/mozilla/x-echdhclwpvwaiodk)
# [20:09] * Quits: sbublava (n=stephan@77.117.230.232.wireless.dyn.drei.com)
# [20:12] * Quits: inlogic (n=inlogic@bl8-14-67.dsl.telepac.pt)
# [20:21] * Joins: slightlyoff (n=slightly@nat/google/x-tzuyzkpqokcauaxp)
# [20:30] * Joins: scherkus_ (n=scherkus@74.125.59.65)
# [20:35] * Quits: scherkus (n=scherkus@74.125.59.65) (Read error: 60 (Operation timed out))
# [20:39] * Joins: cying (n=cying@70.90.171.153)
# [20:49] * Joins: markhuot (n=markhuot@64.3.245.34.ptr.us.xo.net)
# [20:53] * Quits: Binarytales (n=Binaryta@host81-157-254-162.range81-157.btcentralplus.com)
# [20:54] * Joins: jlebar_ (n=jlebar@nat/mozilla/x-jfjvgxmfkzbfphgf)
# [20:56] * Quits: jlebar (n=jlebar@nat/mozilla/x-echdhclwpvwaiodk) (Read error: 110 (Connection timed out))
# [20:58] <markhuot> Hey there ladies and gents. Does anyone have a minute to talk about HTML5?!
# [20:59] <JonathanNeal> I always do.
# [20:59] <markhuot> Hey Jonathan!
# [21:00] <markhuot> I've been keeping busy reading up on the semantic uses of the FOOTER element, but was hoping someone could educate me on WHY there's a footer element.
# [21:00] <markhuot> I can't come up with the benefit of a FOOTER over just a plain ol' DIV.
# [21:04] <Kalms> Well, I suppose its intention is to aide in a better semantic overview of the structure.
# [21:04] <Kalms> Sorry for breaking in ;)
# [21:04] * Joins: jwalden (n=waldo@nat/mozilla/x-fxkbsoojokxexyjg)
# [21:04] <markhuot> No worries Kalms. Thanks for the reply!
# [21:04] <TabAtkins> <footer> is supposed to be something like metadata about its parent section.
# [21:04] <TabAtkins> But, eh, I dunno.
# [21:05] <markhuot> I think my confusion is that we're walking a very gray line here and if we have a FOOTER element, then why not a SIDEBAR or VCARD element
# [21:06] <TabAtkins> That *is* how footers work on things like articles, but the standard use of a footer element for an entire page is different.
# [21:06] <tantek> markhuot - no need for a VCARD element, that's solved by hCard, which works better independent of any specific element (there are people/organizations mentioned everywhere in pages, not just in a footer)
# [21:06] <tantek> http://microformats.org/wiki/hcard
# [21:07] <markhuot> tantek, I think that's my confusion then. Why is a hCard used for vcard type stuff but a, let's say, hFooter, isn't good?
# [21:07] * Joins: virtuelv (n=virtuelv@125.175.251.212.customer.cdi.no)
# [21:07] <tantek> because footers are more structural than semantic
# [21:08] <tantek> whereas hCards (people, organizations) are more semantic than structural
# [21:08] <markhuot> Hum, I think I'm starting to understand…
# [21:08] <tantek> semantic = data sharing
# [21:08] <TabAtkins> I sorta like adactio's suggestion of naming it <contentinfo> better. It's clear, it won't get misused as a site footer, and it then maps transparently to the ARIA role.
# [21:09] <tantek> markhuot - feel free to join #microformats for more on hCard, microformats, semantics, data sharing
# [21:09] <TabAtkins> If you've got a "fat footer" with nav and info and such in it, could that be reasonably marked up as a <header>?
# [21:09] <takkaria> tantek: no-one will use it, though
# [21:09] <takkaria> u
# [21:09] <takkaria> TabAtkins* even
# [21:10] <TabAtkins> takkaria: Is anyone going to use <footer> for the intended purpose?
# [21:10] * Joins: dpranke (n=Adium@nat/google/x-wspzkwqxckutmsaq)
# [21:10] <takkaria> I imagine people will just slot it in instead of <div id="footeR">
# [21:10] <tantek> the intended purpose should reflect the emergent usage of "footer" class name and id from the markup study
# [21:10] * Joins: inlogic (n=inlogic@217.129.104.92)
# [21:11] <tantek> rather than prescribing an a priori purpose
# [21:11] <TabAtkins> takkaria: Exactly. Which isn't what <footer> is currently specced to be used for.
# [21:11] <TabAtkins> I'm really glad Zeldman & co had that meeting of theirs. ^_^
# [21:12] * slightlyoff is now known as slightlyoff_afk
# [21:12] <Philip`> markhuot: There's <aside> for sidebars
# [21:12] <Kalms> Isn't there a lot of confusing regarding the footer element right now?
# [21:12] <Kalms> Seems so.
# [21:12] <markhuot> Tantek, I think I'm still struggling with how a FOOTER element is helpful when you have no idea what's in the FOOTER.
# [21:13] <tantek> markhuot - the FOOTER element isn't for everyone
# [21:13] <markhuot> philip: technically `aside` is for related content, not the full blown out sidebar that I'm envisioning…
# [21:13] <tantek> however, quite a few have found utility in class="footer" or id="footer" and thus the same utility would be found in an element <footer>
# [21:13] <tantek> what utility is, requires more in depth research of the markup study data
# [21:14] <tantek> what *that* utility is
# [21:14] <markhuot> tantek, (thanks so much, it's great to talk this through) well then who is it for? I guess that's the trouble for me. When would I use it programatically. Google can't parse it without knowing what's in it. A screen reader couldn't really do anything different with it…
# [21:14] <TabAtkins> markhuot: a full sidebar should be either a <section>, if it's relevant to the document, or more likely just a <div>.
# [21:14] <TabAtkins> tantek: I think the basic problem is that the people who use #footer and the people who use .footer are meaning different things.
# [21:15] <tantek> markhuot - start taking a look at examples in the wild on the web of authors publishing class="footer" and id="footer" and perhaps some utility will emerge. it is difficult to discuss utility in the abstract, rarely does utility in the abstract exist.
# [21:15] <TabAtkins> I believe .footer is probably roughly what <footer> is.
# [21:15] <tantek> TabAtkins that may be a problem yes
# [21:15] <tantek> I would hypothesize that id="footer" is simply people meaning *the* footer of *the* <body>
# [21:16] <TabAtkins> But #footer is way more common (or .footer used as #footer, since a surprising amount of people do CSS with *only* classes), and these days that includes content that's not allowed in <footer>.
# [21:16] <Kalms> Isn't it kinda dangerous to name something "aside" there by implying it's use, in for example, a full blown sidebar?
# [21:16] <tantek> whereas class="footer" people are using to mean *a* footer, maybe for the <body>, maybe for a main <section>, maybe for a sidebar
# [21:16] * tantek dislikes <aside> and wouldn't mind seeing it dropped. Same with <article>.
# [21:16] <Kalms> I mean, if that's not its intended use
# [21:17] <TabAtkins> Kalms: Yeah, maybe. I get what <aside> is for now, but I totally tried to use it for a sidebar at first.
# [21:17] <Kalms> I think a lot of people did. Myself included
# [21:18] <markhuot> tantek: thanks again, doesn't it seem like we're just muddying the waters though adding in FOOTER elements? I would think if FOOTER is in and HEADER is in then we would also need things like SEARCH (a quite common class name)
# [21:18] <TabAtkins> And, I mean, the proper usage of <aside> is pretty cool. I'll be using it. I personally think it's nice to be able to say "Here's some stuff that I'm just shoving into the middle of this page. It's not directly relevant, but just sorta related."
# [21:18] <TabAtkins> markhuot: <input type=search>?
# [21:20] <markhuot> TabAtkins: but what about the containing element and the related form fields? Just like HEADER has many child elements, I would think SEARCH would too. And this isn't to say I'm in favor of a SEARCH element. It is to say that I'm worried that adding elements like HEADER and FOOTER is getting to be a bit much.
# [21:20] <TabAtkins> Couldn't an AT just find <input type=search>, and then assume that the containing section is relevant to it?
# [21:20] * aroben is now known as aroben|lunch
# [21:21] <markhuot> TabAtkins: not necessarily, what if the containing element is a P, inside a FORM, inside a DIV and the DIV is what actually defines the search experience.
# [21:21] <TabAtkins> A <search> element would be defined as just "a section for putting search forms in". That sort of thing can be done better implicitly. <header> can't always be, nor can <footer> (however you slice the semantics of it).
# [21:22] <tantek> markhuot - at some point you need to draw the line yes. It is my impression that that's what Hixie did with the markup study data. He used some of the top results as justification for considering new elements with what were presumed to be shared structure and/or semantics, and then did so.
# [21:22] <takkaria> I think it certainyl simplifies markup and styling to have footer/header elements, which is what they were made for
# [21:22] <tantek> TabAtkins reasoning is good as well.
# [21:22] <TabAtkins> markhuot: There are limitations, sure. If the author's using <section> decently, though, it would probably work fine.
# [21:23] <TabAtkins> Even the implicit sectioning algorithm would be good here - if you've got a complex search form, you generally have a header on it as well.
# [21:23] <TabAtkins> You only omit the header, imxp, when you're being compact about things, and then you only have a simple <form><input type=search><input type=submit></form>.
# [21:24] <markhuot> TabAtkins: Ah, now we're talking. Thinking implicitly and explicitly helped a bit. I can see the difference a bit better now.
# [21:26] <markhuot> Although I still worry that a HEADER without any clarity around what it contains won't be much more useful than a DIV with a class of HEADER.
# [21:26] <TabAtkins> My own review: I think <header>, <section>, and <article> are good. I think <aside> and <footer> fill a useful niche, but will be misused because of their name.
# [21:27] <TabAtkins> markhuot: Well, you can at least tell that there *is* a header there. That's usually stuff you can skip. Possibly good for ATs.
# [21:27] <takkaria> I intend to misuse <footer> happily. :)
# [21:27] <TabAtkins> takkaria: The only reason I haven't misused it yet is because the sites I've been using html5 elements on haven't needed a footer. ^_^
# [21:28] <TabAtkins> Though, seriously: fat footer - is <header> appropriate?
# [21:28] <takkaria> unless we're redefining the meaning of english words, no
# [21:29] <takkaria> "A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like."
# [21:29] <TabAtkins> "The header element represents a group of introductory or navigational aids."
# [21:29] <TabAtkins> If I'm putting my nav at the bottom of my screen, that's a footer. But it sounds like it should be using <header>.
# [21:30] <takkaria> I think they count as links to related documents and can safely go in <footer>
# [21:31] <TabAtkins> No dice. I can't drop sectioning content into it. No <nav>, no <h1> titling my groups of links, etc.
# [21:31] <TabAtkins> I can't put my blogroll down there if I want to put a title on it.
# [21:31] <takkaria> that's true
# [21:31] <TabAtkins> Which means that <footer> ain't no good for being my footer.
# [21:32] <takkaria> well, <footer> needs to be redefined then, I think
# [21:32] <TabAtkins> That's what I'm saying. ^_^
# [21:32] <takkaria> :)
# [21:32] <TabAtkins> And what a goodly bunch of other people are saying too.
# [21:32] <markhuot> TabAtkins: that makes sense, ATs can skip that content on subsequent page loads, if requested, I guess…
# [21:32] * Joins: virtuelv_ (n=virtuelv@125.175.251.212.customer.cdi.no)
# [21:32] <takkaria> I've done a bad job of paying attention to the whole debate, really, but unintuitive language features help no-one
# [21:32] <TabAtkins> Problem, though: if <footer> allows the same content as <header>, then we're basically just repeating the element except saying that one goes at the top of the screen and one at the bottom.
# [21:33] <TabAtkins> takkaria: Nod.
# [21:34] <TabAtkins> markhuot: Yeah, that's a theoretical benefit. I like it just because I can scroll down and see the </header> telling me that I'm entering the content section of my page. ^_^
# [21:34] <takkaria> TabAtkins: well, even if they have the same content models, that doesn't mean the conformance criteria are the same
# [21:34] <TabAtkins> takkaria: Elaborate?
# [21:34] <TabAtkins> Also: brb, need to hit Sonic now so I can get back in time for work.
# [21:35] <TabAtkins> You in +1 time, takkaria?
# [21:35] <takkaria> I'm UTC+2 atm
# [21:36] <TabAtkins> Oh, right. kk, then it's late your place.
# [21:36] <TabAtkins> Well, hope you're still around in 20min or so. ^_^
# [21:36] <takkaria> TabAtkins: I think you can keep the current verbal definitions ("represents a group of xxx" "typically contains information about...") and change the content models to allow the same content
# [21:38] * Joins: taf2 (n=taf2@38.99.201.242)
# [21:38] * Joins: Kalms_ (n=rasmuska@81.161.185.108)
# [21:39] * Quits: virtuelv (n=virtuelv@125.175.251.212.customer.cdi.no) (Read error: 60 (Operation timed out))
# [21:43] <markhuot> Hey guys, for anyone else who's around, a few more questions, if that's Ok?
# [21:44] <takkaria> go for it
# [21:45] <markhuot> So still thinking about the HEADER element… let's say I have a blog listing page, would it be correct to have a SECTION for the blog listing, a DIV for each entry, a HEADER for each title and a FOOTER for the metadata about the entry?
# [21:46] * aroben|lunch is now known as aroben
# [21:47] <takkaria> <article> for each entry, I'd have thought
# [21:47] <markhuot> takkaria: sorry, that's probably better. yes.
# [21:49] <markhuot> takkaria: a followup: let's say the design calls for the the metadata to be right below the title, would it be Ok to have the ARTICLE set up as follows: HEADER, FOOTER, P.excerpt?
# [21:49] <takkaria> I believe so, there's no requirement for the footer to be at the end
# [21:50] <markhuot> takkaria: Ok, I wasn't expecting that. If that's the case then awesome!
# [21:51] * Quits: mlpug (n=mlpug@a88-115-164-40.elisa-laajakaista.fi) (Read error: 54 (Connection reset by peer))
# [21:51] <markhuot> takkaria: and in the HEADER, would I have a H2 for the title and an H3 for the subhead?
# [21:51] * Quits: Kalms (n=rasmuska@81.161.185.108) (Read error: 110 (Connection timed out))
# [21:51] * Kalms_ is now known as Kalms
# [21:51] <tantek> markhuot - exactly "wasn't expecting that" - you just captured what is perhaps the biggest problem with the <footer> definition right now
# [21:51] <tantek> for more on this, see: http://adactio.com/journal/1604/
# [21:51] <markhuot> :)
# [21:51] <markhuot> tantek: yup, just read it.
# [21:54] <markhuot> tantek: thanks again for helping my wrap my head around some of this.
# [21:54] <TabAtkins> tantek: I agree. >_< <footer> just carries too much visual connotations with it.
# [21:54] <tantek> np markhuot - there's definitely some non-trivial things in some of the new elements
# [21:55] <tantek> TabAtkins - which is why I think class="footer" and id="footer" is used more structurally than semantically, based on the limited samples / HTML view sources I've looked at
# [21:56] <tantek> footer != metadata IMHO
# [21:56] <TabAtkins> tantek: I'd probably agree with you.
# [21:56] <tantek> metadata may be in the footer, or anywhere else
# [21:56] <markhuot> tantek: hum, so metadata could go in a footer, but so could a whole lot of other things?
# [21:56] <TabAtkins> So now we want a <metadata> element instead? ^_^
# [21:56] <tantek> actually, it's kind of silly to say where metadata should or does go.
# [21:56] <tantek> LOL
# [21:56] * Quits: inlogic (n=inlogic@217.129.104.92)
# [21:56] <tantek> perhaps the problem is thinking about such data as "meta" in the first place
# [21:57] <takkaria> <meta> would be fine with me
# [21:57] <tantek> it's not meta in most cases, it's just data
# [21:57] <TabAtkins> That would mean changing the <meta> to a non-empty element, takkaria.
# [21:57] <markhuot> TabAtkins: that's my issue though, when do you stop defining elements?
# [21:57] <TabAtkins> markhuot: WHEN YOU RUN OUT OF WORDS.
# [21:58] <markhuot> TabAtkins: seriously?
# [21:58] <hober> for more about <footer>'s content model, see the conversation beginning at http://krijnhoetmer.nl/irc-logs/whatwg/20090716#l-1155 and continuing into the following day
# [21:58] <TabAtkins> More seriously, you create new elements when data suggests that a significant number of authors are using a common semantic on their pages that can usefully be captured. You stop when you've run out of semantics that are used widely enough.
# [21:59] <markhuot> TabAtkins: thanks, that's much more clear.
# [21:59] <takkaria> TabAtkins: oh, yeah. I'm not paying enough attention :)
# [22:00] * Joins: Eran (i=404ad5ae@gateway/web/freenode/x-ghgjoxsgtcuxusie)
# [22:00] <TabAtkins> takkaria: Don't worry, that was my first thought too. Then I remembered that <meta> already exists. ^_^
# [22:01] <markhuot> TabAtkins: in that respect it seems that HTML5 is simply providing meaning to what everyone is already using…
# [22:02] <TabAtkins> markhuot: Yeah, basically. The new elements are just the language explicitly blessing certain things.
# [22:02] <TabAtkins> So it's easier for machines, and for humans too.
# [22:02] <markhuot> TabAtkins: (this is about to get way to theoretical) is that the job of the spec?
# [22:03] <TabAtkins> Partly be definition, it's the job of the HTML5 spec.
# [22:03] <TabAtkins> Because it defines that as being part of its job.
# [22:03] * Joins: ttepasse (n=ttepas--@p5B014061.dip.t-dialin.net)
# [22:04] <Eran> As part of an upcoming Yahoo! Developers event in NY 10/9 I will moderating a panel on Open Innovation: "Many new products and services that are only possible via the joint efforts of many individuals and corporations. The social web biggest strength is its distributed nature and the ability of individuals to share their experiences across sites. The session will look at how communities and companies collaborate to create new market
# [22:04] <Eran> I am looking for a couple panel members from outside the valley (best from the NY metro area) to talk about their experience building products that would not be possible without collaboration with other companies and without open specifications. HTML5 has many features which enable just that. Any ideas?
# [22:04] <TabAtkins> Man, I really don't want <footer>'s content model relaxed, though. I want to put complex stuff in my footer, but not in my <footer>. I just want the urge to *use* <footer> to go away.
# [22:04] <TabAtkins> I think renaming it is the best solution.
# [22:04] * Joins: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
# [22:08] <markhuot> TabAtkins: I agree. I'd love to see HEADER and FOOTER go away and be replaced with a single element. But that's just me.
# [22:09] <TabAtkins> I wonder if we could replace <footer> with <info>? That seems reasonably self-documenting to me.
# [22:09] * Quits: maikmerten (n=maikmert@BAE15e9.bae.pppool.de) (Remote closed the connection)
# [22:09] <TabAtkins> If I had no idea what the official definition of an <info> element was, I still probably wouldn't misuse it badly if it was intended for the things that <footer> is currently meant for.
# [22:09] <markhuot> TabAtkins: I'm wondering if that's even more ambiguous though.
# [22:09] <markhuot> TabAtkins: probably right.
# [22:10] <markhuot> TabAtkins: although, I'd ask if the HEADER element wasn't just another, more specific, INFO element?
# [22:10] <TabAtkins> That's the big criteria I'm using: will it be misused by authors who don't know the official definition, and are going purely by the name + copypasta examples?
# [22:11] <TabAtkins> markhuot: That's possible. But, I think, less likely. I'm trying to articulate exactly why I think so, though.
# [22:11] <markhuot> TabAtkins: thanks! This has been a most enjoyable, and eyeopening, discussion.
# [22:11] <TabAtkins> Any time, man.
# [22:12] <TabAtkins> <aside> -> <rel>? I'm not sure if this is good or not.
# [22:12] <markhuot> So, anyway, I do think the INFO element would be a bit less prone to mis-use, but only because it's a bit more ambiguous.
# [22:12] * aroben is now known as aroben|meeting
# [22:13] <TabAtkins> You mean, because it doesn't immediately bring to mind uses that would be inappropriate?
# [22:13] * Joins: Binarytales (n=Binaryta@host81-157-254-162.range81-157.btcentralplus.com)
# [22:14] <tantek> indeed
# [22:14] <tantek> and people could put <info> in their <footer> if that's what made sense to them
# [22:15] <TabAtkins> I think, worst case, <info> would be used in places where <aside> should be. And that's not that bad.
# [22:15] * Joins: inlogic (n=inlogic@217.129.104.92)
# [22:16] <TabAtkins> Keep <header> around, for one because virtually *every* page in the entire world has a <div> with .header, .head, .top, or similar.
# [22:16] <tantek> TabAtkins, perhaps <aside> should similarly be more structurally defined than semantic.
# [22:16] <TabAtkins> That is, make it a sidebar?
# [22:16] <tantek> TabAtkins - by the same argument, <footer> .footer
# [22:17] <TabAtkins> tantek: Yeah, yeah, I know.
# [22:17] <tantek> but IMHO aside/sidebar is already handled sufficiently well by a sub <section>
# [22:18] <TabAtkins> Hmm. Do you really think the average sidebar should be a section?
# [22:18] <tantek> I think the average sidebar is *just* a section, no more.
# [22:18] <TabAtkins> I think it's more of semanticless <div> filled with <nav>s and <sections>s. But I may be splitting hairs too finely.
# [22:18] <TabAtkins> You're probably right.
# [22:19] <tantek> In fact, when I've seen MSWORD serializations of documents that are to be laid out with sidebars/asides, they are simple sub <sections> in the flow
# [22:19] <TabAtkins> Convincing.
# [22:19] <TabAtkins> The proper use of <aside> spec-wise *isn't* a sidebar in the website sense, though.
# [22:19] <tantek> and if I'm browsing on a mobile device, I would expect to see the same (sidbars/asides as just in flow sub <section>s)
# [22:19] <tantek> sidebars even
# [22:19] <tantek> hah - even worse
# [22:20] <TabAtkins> I know!
# [22:20] <TabAtkins> It's horrible.
# [22:20] <tantek> people will use <aside> for sidebars because it sounds like the right thing
# [22:20] <TabAtkins> Yup.
# [22:20] <tantek> this is all a repeat of the <address> mistake
# [22:20] <tantek> (in HTML4)
# [22:20] <TabAtkins> Yeah.
# [22:20] * Joins: sebmarkbage (n=miranda@c123.a108.sto.bahnhof.net)
# [22:20] <tantek> using a common term to name an element which then does not behave as the common term would imply
# [22:20] <TabAtkins> I misused <address> when I first started using html, for godsakes.
# [22:20] <tantek> behave/mean etc.
# [22:20] <tantek> bingo
# [22:21] <TabAtkins> And we have several anecdotes from half an hour ago or so that several of us immediately tried to misuse <aside> because of the name.
# [22:22] <tantek> one of the most frequent FAQs in microformats as well: http://microformats.org/wiki/hcard-faq#Should_I_use_ADDRESS_for_hCards
# [22:23] <TabAtkins> Like the current definition of <footer>, I like the current definition of <aside> and want to use it. I just want it renamed so I don't try to use it for other things.
# [22:23] <Philip`> "I agree that the web is a better place now than it was 20 years ago." - well, yeah, since it's only 18 years old
# [22:24] <TabAtkins> Philip`: Man, forget you. ^_^
# [22:25] <TabAtkins> Philip`: I'm not the one that used 1990 as a reference date in their email.
# [22:27] * Parts: pmuellr (n=pmuellr@nat/ibm/x-gbxkofkjcijqdnwc)
# [22:27] <markhuot> Hey guys, thanks again for talking through some things with me. I'm going to step away and absorb for a while.
# [22:27] <TabAtkins> No problem, markhuot.
# [22:28] * Joins: dimich (n=dimich@74.125.59.65)
# [22:30] * Quits: ROBOd2 (n=robod@89.122.216.38) ("http://www.robodesign.ro")
# [22:34] * Quits: Kalms (n=rasmuska@81.161.185.108)
# [22:36] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
# [22:39] * Quits: Eran (i=404ad5ae@gateway/web/freenode/x-ghgjoxsgtcuxusie) ("Page closed")
# [22:40] <TabAtkins> How about renaming footer to <about>? I don't think it's even *possible* to misuse something named <about>.
# [22:41] * Quits: jaket (n=jake@110.32.130.158)
# [22:44] * Quits: weinig (n=weinig@17.246.19.176)
# [22:44] * Quits: bzed (n=bzed@devel.recluse.de) (Read error: 54 (Connection reset by peer))
# [22:44] * Joins: bzed (n=bzed@devel.recluse.de)
# [22:46] * Quits: virtuelv_ (n=virtuelv@125.175.251.212.customer.cdi.no) ("Ex-Chat")
# [22:46] <markhuot> Well, would I use ABOUT for a speakers bio on a conference page?
# [22:48] * Joins: virtuelv (n=virtuelv@125.175.251.212.customer.cdi.no)
# [22:51] <TabAtkins> Hmm, you mean like on a page listing all the talks at a conference?
# [22:51] <markhuot> Right.
# [22:51] <markhuot> If I had a listing of speakers and I had a heading for Speaker X, then I would assume ABOUT could be used for that person's bio…
# [22:52] <markhuot> If that's Ok, then awesome, but I'm not sure that's the intended use of FOOTER.
# [22:52] <TabAtkins> Hmm, probably not. That's the actual content of the page.
# [22:52] <TabAtkins> So, good argument against.
# [22:52] <TabAtkins> Though I want to use "meta" somewhere, the average person doesn't know what that means, so it's not good to use.
# [22:53] <markhuot> Agreed, META is much more technical than something like FOOTER.
# [22:53] <takkaria> <metaboutfooter>
# [22:54] <markhuot> :)
# [22:54] <TabAtkins> takkaria: +1
# [22:54] <TabAtkins> <sectioninfo>?
# [22:55] <markhuot> If there's a SECTIONINFO then I'd argue for a SECTIONHEADER as well though. In fact those would make me much happier than HEADER and FOOTER
# [22:55] <TabAtkins> Here's a question: Should <footer> always refer to an <article>, or is there a good use for it to refer to a plain <section> too?
# [22:56] <TabAtkins> Given that <article> is just a <section> that is theoretically independent and could be viewed separately.
# [22:57] <markhuot> The first instance I can think of refers to a blog listing page where there's several ARTICLE elements inside a SECTION. I would think you'd sometimes need a FOOTER element on each ARTICLE and on the containing SECTION.
# [22:58] * Quits: sebmarkbage (n=miranda@c123.a108.sto.bahnhof.net) ("http://calyptus.eu/")
# [22:58] <TabAtkins> Definitely one on the individual articles. What would be the use on the containing <section>, though? And would it be more appropriate to find the containing <article> (or <body>) and attach it to that?
# [22:59] <takkaria> TabAtkins: you can use <footer> as a direct descendent of <body>, so you totally can use it outside of <article>
# [22:59] <markhuot> TabAtkins: looking at a specific example: http://www.zeldman.com/category/html5/ would the correct markup be an ARTICLE for each entry and a containing ARTICLE for the whole group of them?
# [23:00] <TabAtkins> takkaria: Yeah, but there <body> is acting as an implicit containing <article>. By definition the <body> can be viewed as a separate page. ^_^
# [23:00] <takkaria> TabAtkins: hmm, ok
# [23:00] <TabAtkins> markhuot: Yeah, I think that's appropriate. The individual posts are certainly separate articles, but so is the listing itself.
# [23:01] * aroben|meeting is now known as aroben
# [23:02] <TabAtkins> Ooh, just thought of a good metric for what should be an <article>: would it be useful if you full-screened the element?
# [23:03] * Joins: markboulton (n=markboul@82-69-24-131.dsl.in-addr.zen.co.uk)
# [23:03] <TabAtkins> That goes well with the metric for using <section>: Would you put a heading on the element?
# [23:05] <markhuot> Hum, sorry TabAtkins can you explain the SECTION metric quickly?
# [23:07] <TabAtkins> If an element can *potentially* have a heading put on it, it should be a <section>.
# [23:07] <TabAtkins> If it shouldn't recieve a heading (like if it's just being used to group things for styling), then it should just be a <div>.
# [23:08] <markhuot> Ah, Ok. Thank.s
# [23:08] <markhuot> thanks*
# [23:09] <markhuot> So then, by the full screen metric and the Zeldman.com example: http://www.zeldman.com/category/html5/, the entire listing of all articles would be an ARTICLE, each individual entry would be an ARTICLE, but nothing in the sidebar would be an article…
# [23:11] <TabAtkins> Yeah, exactly.
# [23:11] <markhuot> Cool, that makes good sense. One place I'd see confusion would be the footer area (not the element, that's been discussed already…)
# [23:11] <TabAtkins> And <body> implicitly carries the same semantics, so there's no need to wrap the whole page in an <article>.
# [23:11] * Quits: inlogic (n=inlogic@217.129.104.92)
# [23:12] <markhuot> Would each of his six cross sells need their own ARTICLE element?
# [23:12] <TabAtkins> you mean the 6 things with red headings on the right?
# [23:13] <markhuot> TabAtkins: at the very bottom of the page the six images with associated blurbs. The first one is a callout to An Event Apart
# [23:13] <TabAtkins> That's fuzzy, but I'd say no. I wouldn't want to full-screen those. They're definitely <section>s, though.
# [23:14] <markhuot> Hum, so using those examples, let's say Zeldman used shorter excerpts for each blog post, would they then not be articles, and be sections?
# [23:15] <TabAtkins> At what point does a collection of sand grains become a heap of sand?
# [23:15] <TabAtkins> And my personal answer would be yes, <section>s instead if they were just excerpts.
# [23:15] <markhuot> Ah, ok TabAtkins. As long as you'd switch them from ARTICLEs to SECTIONs I think that makes sense then.
# [23:17] <TabAtkins> Yeah. Having a clear question that you can ask yourself with real-world implications is *way* better than just circle-jerking over semantics.
# [23:17] <takkaria> christ, there's going to be a long period where everyone writes blog articles about how the new elements should be used before it settles down and becomes part of the background, isn't there?
# [23:17] <TabAtkins> takkaria: Yes.
# [23:18] <jgraham> FWIW I believ Hixie says that a blogroll is OK in <aside>
# [23:18] <takkaria> I'm glad I don't read blogs anymore :)
# [23:18] <jgraham> I think he is wrong and that it should only be used for pullouts
# [23:18] <TabAtkins> I think I agree with you, jgraham. A blogroll isn't related-but-tangential content.
# [23:18] * Quits: markboulton (n=markboul@82-69-24-131.dsl.in-addr.zen.co.uk)
# [23:18] <TabAtkins> It's just... *extra*. Stuff you have on your page.
# [23:19] <jgraham> (but you can argue, I guess, that the relationship between a blogroll and the overall page is the same as the relationship between some content and a pullout)
# [23:19] <jgraham> (but it sounds quite dubious to me)
# [23:19] <TabAtkins> But then again, I don't know if I can come up with a good question for deciding <aside> vs <div>.
# [23:20] <jgraham> The uses of <aside> for in-article content seem pretty straightforward to me:
# [23:20] <jgraham> pull quotes
# [23:20] * Joins: tantek (n=tantek@67.180.202.79)
# [23:21] <jgraham> something that would be labelled e.g. "Box A" in a magazine
# [23:21] * Joins: pmuellr (n=pmuellr@user-0ce2gjn.cable.mindspring.com)
# [23:21] <TabAtkins> Yeah, but what rule do you use to make it *only* be used for that?
# [23:22] <jgraham> "rule" as in "spec language formulation"? Don't know
# [23:22] <markhuot> That's the question, because more often than not a pull quote can fit directly into the surrounding text, in which case, it's stylistic difference should be represented by a DIV…
# [23:22] <beowulf> is the super friends thing a joke?
# [23:22] <jgraham> markhuot: eh?
# [23:22] <TabAtkins> beowulf: I think it's half-jokey. ^_^
# [23:23] <jgraham> Why has style got anything to do with <aside> v <div>?
# [23:23] <TabAtkins> markhuot: Pull-quote in this context means *repeating* a quote that's already in an article, but styling it up special.
# [23:23] <markhuot> Ah, sorry TabAtkins, *repeating* is certainly the difference, though, right?
# [23:23] <jgraham> TabAtkins: Or, I think using a third-party quote
# [23:23] <beowulf> TabAtkins: then i only half want to throw up
# [23:24] <TabAtkins> markhuot: Yeah. If it's a normal quote in an article, then it should certainly just be normally written up/wrapped.
# [23:24] <atwilson> Hixie: Looking at http://www.whatwg.org/specs/web-apps/current-work/#concept-error-nothandled - is the implication of this section (6.5.6.5) that if someone registers an error handler for a Worker via addEventListener() that the error is always considered to be not handled?
# [23:24] * Joins: markboulton (n=markboul@82-69-24-131.dsl.in-addr.zen.co.uk)
# [23:24] <TabAtkins> jgraham: You mean like a commentary on the subject from a party different from the person that you're normally quoting in the article?
# [23:24] <TabAtkins> beowulf: Is it the unicorn?
# [23:25] <jgraham> At least I think something like the boxes on http://news.bbc.co.uk/sport2/hi/tennis/8230640.stm would be fine uses of <aside>
# [23:25] <atwilson> It explicitly says that if the value of onerror is not a Function, then it's not handled, but I'm not certain if that's meant to cover listeners with addEventListener() too.
# [23:26] <TabAtkins> jgraham: Yeah, totally. That fits my idea of related-but-tangential.
# [23:26] <markhuot> Oh jgraham, the sidebar has a good use of FOOTER too, as I understand it ("The BBC is not responsible for the content of external internet sites")
# [23:26] <jgraham> TabAtkins: The metric I have is "if this text were read out of order e.g. after all the rest of the content, would the article still make sense?"
# [23:27] <markhuot> TabAtkins would the sidebar of that page be an ARTICLE? If not, then there's an example of using a FOOTER outside an ARTICLE.
# [23:27] <TabAtkins> jgrahahm: Yeah, that'd work for me. You have to add "or not read at all" to account for repeated quotes.
# [23:27] <jgraham> If the answer is "yes" it probably makes sense to use <aside>
# [23:27] <TabAtkins> markhuot: That could also just be a <small>.
# [23:27] <beowulf> TabAtkins: my nausea was rising at alarming rates until i saw the unicorn, then i was confused
# [23:27] <jgraham> Anyway, I was going to bed some time ago
# [23:27] <jgraham> Goodnight
# [23:27] <TabAtkins> later
# [23:28] <markhuot> TabAtkins: then I think I see the FOOTER confusion ;-) I would have assumed that'd be a FOOTER
# [23:28] <TabAtkins> beowulf: If the unicorn *lessened* your nausea, then I think you should go throw up now. In the sense that seems to be making you nauseated, I think they're serious.
# [23:28] <TabAtkins> markhuot: Man, it might be. I'm not sure yet. It's also possibly appropriate as both.
# [23:29] <TabAtkins> I sorta wanna restrict <footer>/<info> to <article> and <body>, though, which would make it clear that that bit was just a <small>.
# [23:29] <markhuot> Hum, I think the most defined approach would be to limit it to article only. That'd prevent people from using it as a page footer like you mentioned before.
# [23:31] * Joins: adactio (n=adactio@cust217-dsl91-135-3.idnet.net)
# [23:31] <beowulf> TabAtkins: throw up or destroy with fire
# [23:32] <TabAtkins> markhuot: Keeping it away from <body> would mean that sometimes you need a superfluous <article>, though, if you have a fairly simplistic page without a lot of UI crud surrounding.
# [23:33] <markhuot> Yup, makes sense, but if you allow it in body then aren't you kind of double dipping your body into two roles?
# [23:33] <AryehGregor> Okay, I have to say, if <header>/<footer>/<aside> aren't basically just to be used for whatever authors were using .header/.footer/.sidebar for, then I don't see the point of any of them.
# [23:34] <TabAtkins> AryehGregor: I'm totally for renaming <footer> and <aside>. I agree with your point.
# [23:34] <TabAtkins> markhuot: Explain? What's the second role?
# [23:34] <AryehGregor> Why even bother renaming them? What are the use-cases?
# [23:35] <AryehGregor> Actually, what are the use-cases for any of them, as compared to <div class=>?
# [23:35] <TabAtkins> AryehGregor: filling in semantics that useful common semantics - basically, metainfo about an article, and related-but-tangential stuff scattered throughout an article.
# [23:35] <AryehGregor> Great, but semantics per se isn't a use case as far as HTML 5 is concerned, from what I've seen.
# [23:35] <TabAtkins> That sentence didn't make a lot of sense, but I think you get what I mean.
# [23:36] <TabAtkins> If you ignore all the new elements, sure.
# [23:36] <AryehGregor> Those aren't there for semantics per se.
# [23:36] <TabAtkins> But that's because that's precisely what the new elements are for.
# [23:36] <AryehGregor> Most of them have clearly-defined purposes.
# [23:36] <TabAtkins> Elaborate.
# [23:36] <AryehGregor> Well, I don't need to say any more for things like <video>, <audio>, and <canvas>. You're referring to stuff like <time> and <progress>.
# [23:36] <TabAtkins> Yes.
# [23:37] <AryehGregor> The use-case I've seen for <time> is (IIRC) so that users can copy-paste things into address books or something. For <progress>, well, you may recall I participated in a discussion about that, but the goal is apparently to make progress bars more accessible.
# [23:38] <AryehGregor> Since some types of progress bars would be invisible to screen readers and such.
# [23:38] <TabAtkins> Indeed. And now the set of <header>/<section>/<mark>/etc. elements?
# [23:39] <AryehGregor> <section> is supposed to be for automatic outline generation, isn't it?
# [23:40] <AryehGregor> <mark> . . . I don't know, offhand. <header> is one of the ones I'm asking about.
# [23:40] <TabAtkins> Partially. We already have <h1-6> to do that with. <section>, however, helps bless a particular way of dividing a page.
# [23:41] <AryehGregor> <h1-6> can't give you a reliable outline if a section doesn't have a header, or if a section logically ends before the next header occurs (e.g., a footer begins or such).
# [23:41] <TabAtkins> True.
# [23:41] * Quits: markboulton (n=markboul@82-69-24-131.dsl.in-addr.zen.co.uk)
# [23:42] <AryehGregor> I don't see how <aside> isn't appropriate for most sidebars.
# [23:42] <AryehGregor> It would be fine for Wikipedia's infoboxes, for instance, right?
# [23:42] <AryehGregor> That's basically the first example in the spec.
# [23:42] <TabAtkins> Probably, yeah. But it wouldn't be appropriate for the stuff that's actually a *sidebar* on wikipedia, on the left.
# [23:42] <AryehGregor> Hmm, not quite, I guess.
# [23:42] <AryehGregor> Oh, no.
# [23:42] <AryehGregor> I see your point.
# [23:42] <AryehGregor> That would be <nav>.
# [23:43] <AryehGregor> But <aside> doesn't sound like I'd use it for that, to me. It sounds like it's part of the content but tangential.
# [23:43] <TabAtkins> Exactly.
# [23:43] <AryehGregor> I mean, just from the name.
# [23:43] <TabAtkins> That is, in fact, the precise definition I keep espousing. related-but-tangential.
# [23:43] <AryehGregor> I'd say "part of but tangential".
# [23:44] <takkaria> you know, I thought these elements should basically go in without much debate a couple years ago. after watching so many people debate what they should be used for, I'm starting to come to the position that some of them should be removed
# [23:44] <TabAtkins> But everyone keeps thinking it's for sidebars. I just related this conversation to a friend, and he remarked that his "mind was blown" because he'd assumed it was for sidebars.
# [23:44] <AryehGregor> At least for what I'd call an aside in English.
# [23:44] <AryehGregor> Well, it is, frankly, right?
# [23:44] <AryehGregor> I mean, it's basically meant to replace class=sidebar.
# [23:44] <AryehGregor> That's why it was added.
# [23:45] <AryehGregor> Anyway, I'm not clear on why these three (<header>/<footer>/<aside>) were added, if not to save typing. :P
# [23:45] <AryehGregor> I think they're cool if only because they allow you to make not-completely-trivial pages using few to no classes or ids.
# [23:46] * Quits: taf2 (n=taf2@38.99.201.242)
# [23:46] <TabAtkins> Aryeh: It's meant to replace the *magazine* notion of sidebar. Not the website notion.
# [23:46] <AryehGregor> (I have zero classes or ids on aryeh.name. I did have to use three spans, though.)
# [23:47] <AryehGregor> I never really think of stuff like Wikipedia's left column as "sidebars", I think of them as "navigation".
# [23:47] <AryehGregor> So I guess <aside> vs. <nav> is intuitive to me.
# [23:48] <TabAtkins> Yeah, so that's part of the problem.
# [23:50] <markhuot> But one thing AryehGregor said that confused me, ASIDE is _not_ meant to replace `class="sidebar"` right?
# [23:51] <AryehGregor> As far as I know, the reason it was added to the spec is because someone generated a list of the top N classes used on sites in practice and said "Let's see if we can make elements for these".
# [23:51] <TabAtkins> It's meant to replace class=sidebar, when that class is used in the magazine sense.
# [23:51] <AryehGregor> Same with <header> and <footer>
# [23:51] <AryehGregor> .
# [23:51] <TabAtkins> Where it means "related but tangential content"
# [23:51] <TabAtkins> AryehGregor: That someone was Hixie.
# [23:51] <markhuot> But, going back, again, to the Zeldman.com example, it wouldn't be used for his right column, right?
# [23:52] <TabAtkins> Correct. It shouldn't be used for that.
# [23:52] <markhuot> The URL to reference: http://www.zeldman.com/category/html5/
# [23:52] <TabAtkins> The BBC article that jgraham linked to shows good use of the <aside> semantic.
# [23:52] <AryehGregor> No, that would use <nav>.
# [23:52] <markhuot> So to me that would have a `class="sidebar"` and this is one instance where ASIDE would not replace it.
# [23:53] <AryehGregor> Well, no, theoretically. But <nav> could be used here.
# [23:53] <AryehGregor> So you have an element you can use anyway.
# [23:53] <markhuot> AryehGregor: the entire right column? Including the ads and speaking engagements?
# [23:53] <TabAtkins> markhuot: Right. Sort of like how class=footer describes two fairly different things - a structural meaning, and a semantic meaning.
# [23:53] <AryehGregor> Er, maybe not.
# [23:53] <AryehGregor> Hmm.
# [23:53] <TabAtkins> class=sidebar is both structural and semantic, and the two meanings are *often* connected on a single element, but often not.
# [23:54] <markhuot> AryehGregor: I could see the here, there and elsewhere being three separate NAV elements, but not the entire column.
# [23:54] <AryehGregor> That would be more like "not part of the content at all". Maybe we need something like <interface>.
# [23:55] <markhuot> And this is, to put it way too frankly, why I think the HTML5 spec is so confusing, there's far too many elements, available that have somewhat overlapping definitions.
# [23:55] <TabAtkins> To mark "this is just part of the UI, move along"? Currently that's just what <div> is for.
# [23:57] <AryehGregor> TabAtkins, no, <div> is for anything. It can be used in content too.
# [23:57] <AryehGregor> markhuot, the new semantic elements are a tiny fraction of the spec.
# [23:57] <AryehGregor> Each one takes what, a couple of paragraphs?
# [23:57] <TabAtkins> Though, that goes against Hixie's statement that the useful content of the page (the stuff that screenreaders want to skip to) is "anything that's not <header>, <footer>, <nav>, or <aside>".
# [23:58] * Joins: nessy (n=nessy@203-214-73-15.dyn.iinet.net.au)
# [23:59] <markhuot> TabAtkins: that makes sense to me and is a good example, but instead of adding HEADER, FOOTER, NAV and ASIDE elements, wouldn't it be easier to add a CONTENT element and leave everything else as DIVs?
# [23:59] <AryehGregor> Namely <article>?
# Session Close: Tue Sep 01 00:00:00 2009

The end :)