| 01:46 | <inlogic> | Hey all |
| 02:06 | <TabAtkins> | annevk2: Never mind, got mine working anyway. I'd still be interested in the details, though. |
| 02:28 | <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. |
| 02:44 | <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. |
| 02:44 | <tantek> | oh congrats! |
| 02:44 | <TabAtkins> | ^_^ |
| 02:45 | <tantek> | (in CSS WG I presume) |
| 02:45 | <TabAtkins> | Yes. |
| 02:45 | <tantek> | I think fantasai starated a wiki for the working group a few years ago |
| 02:45 | <tantek> | that would be a great place for it |
| 02:45 | <TabAtkins> | Ah, over there. |
| 02:45 | <TabAtkins> | Sure. |
| 03:04 | <Hixie> | looks like U+23CE and U+231B are missing from the fonts we're using to print the pdf versions of the spec |
| 18:45 | <annevk2> | gotto love how http://www.mozilla.org/projects/intl/UniversalCharsetDetection.html has incorrect characters |
| 19:50 | <markhuot> | Hey there ladies and gents. Does anyone have a minute to talk about HTML5?! |
| 19:51 | <JonathanNeal> | I always do. |
| 19:51 | <markhuot> | Hey Jonathan! |
| 19:52 | <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. |
| 19:52 | <markhuot> | I can't come up with the benefit of a FOOTER over just a plain ol' DIV. |
| 19:56 | <Kalms> | Well, I suppose its intention is to aide in a better semantic overview of the structure. |
| 19:56 | <Kalms> | Sorry for breaking in ;) |
| 19:56 | <markhuot> | No worries Kalms. Thanks for the reply! |
| 19:56 | <TabAtkins> | <footer> is supposed to be something like metadata about its parent section. |
| 19:56 | <TabAtkins> | But, eh, I dunno. |
| 19:57 | <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 |
| 19:58 | <TabAtkins> | That *is* how footers work on things like articles, but the standard use of a footer element for an entire page is different. |
| 19:58 | <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) |
| 19:58 | <tantek> | http://microformats.org/wiki/hcard |
| 19:59 | <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? |
| 19:59 | <tantek> | because footers are more structural than semantic |
| 20:00 | <tantek> | whereas hCards (people, organizations) are more semantic than structural |
| 20:00 | <markhuot> | Hum, I think I'm starting to understand… |
| 20:00 | <tantek> | semantic = data sharing |
| 20:00 | <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. |
| 20:01 | <tantek> | markhuot - feel free to join #microformats for more on hCard, microformats, semantics, data sharing |
| 20:01 | <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>? |
| 20:01 | <takkaria> | tantek: no-one will use it, though |
| 20:01 | <takkaria> | u |
| 20:01 | <takkaria> | TabAtkins* even |
| 20:02 | <TabAtkins> | takkaria: Is anyone going to use <footer> for the intended purpose? |
| 20:02 | <takkaria> | I imagine people will just slot it in instead of <div id="footeR"> |
| 20:02 | <tantek> | the intended purpose should reflect the emergent usage of "footer" class name and id from the markup study |
| 20:03 | <tantek> | rather than prescribing an a priori purpose |
| 20:03 | <TabAtkins> | takkaria: Exactly. Which isn't what <footer> is currently specced to be used for. |
| 20:03 | <TabAtkins> | I'm really glad Zeldman & co had that meeting of theirs. ^_^ |
| 20:04 | <Philip`> | markhuot: There's <aside> for sidebars |
| 20:04 | <Kalms> | Isn't there a lot of confusing regarding the footer element right now? |
| 20:04 | <Kalms> | Seems so. |
| 20:04 | <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. |
| 20:05 | <tantek> | markhuot - the FOOTER element isn't for everyone |
| 20:05 | <markhuot> | philip: technically `aside` is for related content, not the full blown out sidebar that I'm envisioning… |
| 20:05 | <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> |
| 20:05 | <tantek> | what utility is, requires more in depth research of the markup study data |
| 20:06 | <tantek> | what *that* utility is |
| 20:06 | <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… |
| 20:06 | <TabAtkins> | markhuot: a full sidebar should be either a <section>, if it's relevant to the document, or more likely just a <div>. |
| 20:06 | <TabAtkins> | tantek: I think the basic problem is that the people who use #footer and the people who use .footer are meaning different things. |
| 20:07 | <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. |
| 20:07 | <TabAtkins> | I believe .footer is probably roughly what <footer> is. |
| 20:07 | <tantek> | TabAtkins that may be a problem yes |
| 20:07 | <tantek> | I would hypothesize that id="footer" is simply people meaning *the* footer of *the* <body> |
| 20:08 | <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>. |
| 20:08 | <Kalms> | Isn't it kinda dangerous to name something "aside" there by implying it's use, in for example, a full blown sidebar? |
| 20:08 | <tantek> | whereas class="footer" people are using to mean *a* footer, maybe for the <body>, maybe for a main <section>, maybe for a sidebar |
| 20:08 | tantek | dislikes <aside> and wouldn't mind seeing it dropped. Same with <article>. |
| 20:08 | <Kalms> | I mean, if that's not its intended use |
| 20:09 | <TabAtkins> | Kalms: Yeah, maybe. I get what <aside> is for now, but I totally tried to use it for a sidebar at first. |
| 20:09 | <Kalms> | I think a lot of people did. Myself included |
| 20:10 | <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) |
| 20:10 | <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." |
| 20:10 | <TabAtkins> | markhuot: <input type=search>? |
| 20:12 | <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. |
| 20:12 | <TabAtkins> | Couldn't an AT just find <input type=search>, and then assume that the containing section is relevant to it? |
| 20:13 | <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. |
| 20:13 | <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). |
| 20:14 | <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. |
| 20:14 | <takkaria> | I think it certainyl simplifies markup and styling to have footer/header elements, which is what they were made for |
| 20:14 | <tantek> | TabAtkins reasoning is good as well. |
| 20:14 | <TabAtkins> | markhuot: There are limitations, sure. If the author's using <section> decently, though, it would probably work fine. |
| 20:15 | <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. |
| 20:15 | <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>. |
| 20:16 | <markhuot> | TabAtkins: Ah, now we're talking. Thinking implicitly and explicitly helped a bit. I can see the difference a bit better now. |
| 20:18 | <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. |
| 20:18 | <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. |
| 20:19 | <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. |
| 20:19 | <takkaria> | I intend to misuse <footer> happily. :) |
| 20:19 | <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. ^_^ |
| 20:20 | <TabAtkins> | Though, seriously: fat footer - is <header> appropriate? |
| 20:20 | <takkaria> | unless we're redefining the meaning of english words, no |
| 20:21 | <takkaria> | "A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like." |
| 20:21 | <TabAtkins> | "The header element represents a group of introductory or navigational aids." |
| 20:21 | <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>. |
| 20:22 | <takkaria> | I think they count as links to related documents and can safely go in <footer> |
| 20:23 | <TabAtkins> | No dice. I can't drop sectioning content into it. No <nav>, no <h1> titling my groups of links, etc. |
| 20:23 | <TabAtkins> | I can't put my blogroll down there if I want to put a title on it. |
| 20:23 | <takkaria> | that's true |
| 20:23 | <TabAtkins> | Which means that <footer> ain't no good for being my footer. |
| 20:24 | <takkaria> | well, <footer> needs to be redefined then, I think |
| 20:24 | <TabAtkins> | That's what I'm saying. ^_^ |
| 20:24 | <takkaria> | :) |
| 20:24 | <TabAtkins> | And what a goodly bunch of other people are saying too. |
| 20:24 | <markhuot> | TabAtkins: that makes sense, ATs can skip that content on subsequent page loads, if requested, I guess… |
| 20:24 | <takkaria> | I've done a bad job of paying attention to the whole debate, really, but unintuitive language features help no-one |
| 20:24 | <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. |
| 20:25 | <TabAtkins> | takkaria: Nod. |
| 20:26 | <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. ^_^ |
| 20:26 | <takkaria> | TabAtkins: well, even if they have the same content models, that doesn't mean the conformance criteria are the same |
| 20:26 | <TabAtkins> | takkaria: Elaborate? |
| 20:26 | <TabAtkins> | Also: brb, need to hit Sonic now so I can get back in time for work. |
| 20:27 | <TabAtkins> | You in +1 time, takkaria? |
| 20:27 | <takkaria> | I'm UTC+2 atm |
| 20:28 | <TabAtkins> | Oh, right. kk, then it's late your place. |
| 20:28 | <TabAtkins> | Well, hope you're still around in 20min or so. ^_^ |
| 20:28 | <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 |
| 20:35 | <markhuot> | Hey guys, for anyone else who's around, a few more questions, if that's Ok? |
| 20:36 | <takkaria> | go for it |
| 20:37 | <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? |
| 20:39 | <takkaria> | <article> for each entry, I'd have thought |
| 20:39 | <markhuot> | takkaria: sorry, that's probably better. yes. |
| 20:41 | <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? |
| 20:41 | <takkaria> | I believe so, there's no requirement for the footer to be at the end |
| 20:42 | <markhuot> | takkaria: Ok, I wasn't expecting that. If that's the case then awesome! |
| 20:43 | <markhuot> | takkaria: and in the HEADER, would I have a H2 for the title and an H3 for the subhead? |
| 20:43 | <tantek> | markhuot - exactly "wasn't expecting that" - you just captured what is perhaps the biggest problem with the <footer> definition right now |
| 20:43 | <tantek> | for more on this, see: http://adactio.com/journal/1604/ |
| 20:43 | <markhuot> | :) |
| 20:43 | <markhuot> | tantek: yup, just read it. |
| 20:46 | <markhuot> | tantek: thanks again for helping my wrap my head around some of this. |
| 20:46 | <TabAtkins> | tantek: I agree. >_< <footer> just carries too much visual connotations with it. |
| 20:46 | <tantek> | np markhuot - there's definitely some non-trivial things in some of the new elements |
| 20:47 | <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 |
| 20:48 | <tantek> | footer != metadata IMHO |
| 20:48 | <TabAtkins> | tantek: I'd probably agree with you. |
| 20:48 | <tantek> | metadata may be in the footer, or anywhere else |
| 20:48 | <markhuot> | tantek: hum, so metadata could go in a footer, but so could a whole lot of other things? |
| 20:48 | <TabAtkins> | So now we want a <metadata> element instead? ^_^ |
| 20:48 | <tantek> | actually, it's kind of silly to say where metadata should or does go. |
| 20:48 | <tantek> | LOL |
| 20:48 | <tantek> | perhaps the problem is thinking about such data as "meta" in the first place |
| 20:49 | <takkaria> | <meta> would be fine with me |
| 20:49 | <tantek> | it's not meta in most cases, it's just data |
| 20:49 | <TabAtkins> | That would mean changing the <meta> to a non-empty element, takkaria. |
| 20:49 | <markhuot> | TabAtkins: that's my issue though, when do you stop defining elements? |
| 20:49 | <TabAtkins> | markhuot: WHEN YOU RUN OUT OF WORDS. |
| 20:50 | <markhuot> | TabAtkins: seriously? |
| 20:50 | <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 |
| 20:50 | <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. |
| 20:51 | <markhuot> | TabAtkins: thanks, that's much more clear. |
| 20:51 | <takkaria> | TabAtkins: oh, yeah. I'm not paying enough attention :) |
| 20:52 | <TabAtkins> | takkaria: Don't worry, that was my first thought too. Then I remembered that <meta> already exists. ^_^ |
| 20:53 | <markhuot> | TabAtkins: in that respect it seems that HTML5 is simply providing meaning to what everyone is already using… |
| 20:54 | <TabAtkins> | markhuot: Yeah, basically. The new elements are just the language explicitly blessing certain things. |
| 20:54 | <TabAtkins> | So it's easier for machines, and for humans too. |
| 20:54 | <markhuot> | TabAtkins: (this is about to get way to theoretical) is that the job of the spec? |
| 20:55 | <TabAtkins> | Partly be definition, it's the job of the HTML5 spec. |
| 20:55 | <TabAtkins> | Because it defines that as being part of its job. |
| 20:56 | <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 |
| 20:56 | <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? |
| 20:56 | <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. |
| 20:56 | <TabAtkins> | I think renaming it is the best solution. |
| 21:00 | <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. |
| 21:01 | <TabAtkins> | I wonder if we could replace <footer> with <info>? That seems reasonably self-documenting to me. |
| 21:01 | <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. |
| 21:01 | <markhuot> | TabAtkins: I'm wondering if that's even more ambiguous though. |
| 21:01 | <markhuot> | TabAtkins: probably right. |
| 21:02 | <markhuot> | TabAtkins: although, I'd ask if the HEADER element wasn't just another, more specific, INFO element? |
| 21:02 | <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? |
| 21:03 | <TabAtkins> | markhuot: That's possible. But, I think, less likely. I'm trying to articulate exactly why I think so, though. |
| 21:03 | <markhuot> | TabAtkins: thanks! This has been a most enjoyable, and eyeopening, discussion. |
| 21:03 | <TabAtkins> | Any time, man. |
| 21:04 | <TabAtkins> | <aside> -> <rel>? I'm not sure if this is good or not. |
| 21:04 | <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. |
| 21:05 | <TabAtkins> | You mean, because it doesn't immediately bring to mind uses that would be inappropriate? |
| 21:06 | <tantek> | indeed |
| 21:06 | <tantek> | and people could put <info> in their <footer> if that's what made sense to them |
| 21:07 | <TabAtkins> | I think, worst case, <info> would be used in places where <aside> should be. And that's not that bad. |
| 21:08 | <TabAtkins> | Keep <header> around, for one because virtually *every* page in the entire world has a <div> with .header, .head, .top, or similar. |
| 21:08 | <tantek> | TabAtkins, perhaps <aside> should similarly be more structurally defined than semantic. |
| 21:08 | <TabAtkins> | That is, make it a sidebar? |
| 21:08 | <tantek> | TabAtkins - by the same argument, <footer> .footer |
| 21:09 | <TabAtkins> | tantek: Yeah, yeah, I know. |
| 21:09 | <tantek> | but IMHO aside/sidebar is already handled sufficiently well by a sub <section> |
| 21:10 | <TabAtkins> | Hmm. Do you really think the average sidebar should be a section? |
| 21:10 | <tantek> | I think the average sidebar is *just* a section, no more. |
| 21:10 | <TabAtkins> | I think it's more of semanticless <div> filled with <nav>s and <sections>s. But I may be splitting hairs too finely. |
| 21:10 | <TabAtkins> | You're probably right. |
| 21:11 | <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 |
| 21:11 | <TabAtkins> | Convincing. |
| 21:11 | <TabAtkins> | The proper use of <aside> spec-wise *isn't* a sidebar in the website sense, though. |
| 21:11 | <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) |
| 21:11 | <tantek> | sidebars even |
| 21:11 | <tantek> | hah - even worse |
| 21:12 | <TabAtkins> | I know! |
| 21:12 | <TabAtkins> | It's horrible. |
| 21:12 | <tantek> | people will use <aside> for sidebars because it sounds like the right thing |
| 21:12 | <TabAtkins> | Yup. |
| 21:12 | <tantek> | this is all a repeat of the <address> mistake |
| 21:12 | <tantek> | (in HTML4) |
| 21:12 | <TabAtkins> | Yeah. |
| 21:12 | <tantek> | using a common term to name an element which then does not behave as the common term would imply |
| 21:12 | <TabAtkins> | I misused <address> when I first started using html, for godsakes. |
| 21:12 | <tantek> | behave/mean etc. |
| 21:12 | <tantek> | bingo |
| 21:13 | <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. |
| 21:14 | <tantek> | one of the most frequent FAQs in microformats as well: http://microformats.org/wiki/hcard-faq#Should_I_use_ADDRESS_for_hCards |
| 21:15 | <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. |
| 21:15 | <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 |
| 21:16 | <TabAtkins> | Philip`: Man, forget you. ^_^ |
| 21:17 | <TabAtkins> | Philip`: I'm not the one that used 1990 as a reference date in their email. |
| 21:19 | <markhuot> | Hey guys, thanks again for talking through some things with me. I'm going to step away and absorb for a while. |
| 21:19 | <TabAtkins> | No problem, markhuot. |
| 21:32 | <TabAtkins> | How about renaming footer to <about>? I don't think it's even *possible* to misuse something named <about>. |
| 21:38 | <markhuot> | Well, would I use ABOUT for a speakers bio on a conference page? |
| 21:43 | <TabAtkins> | Hmm, you mean like on a page listing all the talks at a conference? |
| 21:43 | <markhuot> | Right. |
| 21:43 | <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… |
| 21:44 | <markhuot> | If that's Ok, then awesome, but I'm not sure that's the intended use of FOOTER. |
| 21:44 | <TabAtkins> | Hmm, probably not. That's the actual content of the page. |
| 21:44 | <TabAtkins> | So, good argument against. |
| 21:44 | <TabAtkins> | Though I want to use "meta" somewhere, the average person doesn't know what that means, so it's not good to use. |
| 21:45 | <markhuot> | Agreed, META is much more technical than something like FOOTER. |
| 21:45 | <takkaria> | <metaboutfooter> |
| 21:46 | <markhuot> | :) |
| 21:46 | <TabAtkins> | takkaria: +1 |
| 21:46 | <TabAtkins> | <sectioninfo>? |
| 21:47 | <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 |
| 21:47 | <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? |
| 21:48 | <TabAtkins> | Given that <article> is just a <section> that is theoretically independent and could be viewed separately. |
| 21:49 | <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. |
| 21:50 | <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? |
| 21:51 | <takkaria> | TabAtkins: you can use <footer> as a direct descendent of <body>, so you totally can use it outside of <article> |
| 21:51 | <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? |
| 21:52 | <TabAtkins> | takkaria: Yeah, but there <body> is acting as an implicit containing <article>. By definition the <body> can be viewed as a separate page. ^_^ |
| 21:52 | <takkaria> | TabAtkins: hmm, ok |
| 21:52 | <TabAtkins> | markhuot: Yeah, I think that's appropriate. The individual posts are certainly separate articles, but so is the listing itself. |
| 21:54 | <TabAtkins> | Ooh, just thought of a good metric for what should be an <article>: would it be useful if you full-screened the element? |
| 21:55 | <TabAtkins> | That goes well with the metric for using <section>: Would you put a heading on the element? |
| 21:57 | <markhuot> | Hum, sorry TabAtkins can you explain the SECTION metric quickly? |
| 21:59 | <TabAtkins> | If an element can *potentially* have a heading put on it, it should be a <section>. |
| 21:59 | <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>. |
| 22:00 | <markhuot> | Ah, Ok. Thank.s |
| 22:00 | <markhuot> | thanks* |
| 22:01 | <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… |
| 22:03 | <TabAtkins> | Yeah, exactly. |
| 22:03 | <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…) |
| 22:03 | <TabAtkins> | And <body> implicitly carries the same semantics, so there's no need to wrap the whole page in an <article>. |
| 22:04 | <markhuot> | Would each of his six cross sells need their own ARTICLE element? |
| 22:04 | <TabAtkins> | you mean the 6 things with red headings on the right? |
| 22:05 | <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 |
| 22:05 | <TabAtkins> | That's fuzzy, but I'd say no. I wouldn't want to full-screen those. They're definitely <section>s, though. |
| 22:06 | <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? |
| 22:07 | <TabAtkins> | At what point does a collection of sand grains become a heap of sand? |
| 22:07 | <TabAtkins> | And my personal answer would be yes, <section>s instead if they were just excerpts. |
| 22:07 | <markhuot> | Ah, ok TabAtkins. As long as you'd switch them from ARTICLEs to SECTIONs I think that makes sense then. |
| 22:09 | <TabAtkins> | Yeah. Having a clear question that you can ask yourself with real-world implications is *way* better than just circle-jerking over semantics. |
| 22:09 | <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? |
| 22:09 | <TabAtkins> | takkaria: Yes. |
| 22:10 | <jgraham> | FWIW I believ Hixie says that a blogroll is OK in <aside> |
| 22:10 | <takkaria> | I'm glad I don't read blogs anymore :) |
| 22:10 | <jgraham> | I think he is wrong and that it should only be used for pullouts |
| 22:10 | <TabAtkins> | I think I agree with you, jgraham. A blogroll isn't related-but-tangential content. |
| 22:10 | <TabAtkins> | It's just... *extra*. Stuff you have on your page. |
| 22:11 | <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) |
| 22:11 | <jgraham> | (but it sounds quite dubious to me) |
| 22:11 | <TabAtkins> | But then again, I don't know if I can come up with a good question for deciding <aside> vs <div>. |
| 22:12 | <jgraham> | The uses of <aside> for in-article content seem pretty straightforward to me: |
| 22:12 | <jgraham> | pull quotes |
| 22:13 | <jgraham> | something that would be labelled e.g. "Box A" in a magazine |
| 22:13 | <TabAtkins> | Yeah, but what rule do you use to make it *only* be used for that? |
| 22:14 | <jgraham> | "rule" as in "spec language formulation"? Don't know |
| 22:14 | <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… |
| 22:14 | <beowulf> | is the super friends thing a joke? |
| 22:14 | <jgraham> | markhuot: eh? |
| 22:14 | <TabAtkins> | beowulf: I think it's half-jokey. ^_^ |
| 22:15 | <jgraham> | Why has style got anything to do with <aside> v <div>? |
| 22:15 | <TabAtkins> | markhuot: Pull-quote in this context means *repeating* a quote that's already in an article, but styling it up special. |
| 22:15 | <markhuot> | Ah, sorry TabAtkins, *repeating* is certainly the difference, though, right? |
| 22:15 | <jgraham> | TabAtkins: Or, I think using a third-party quote |
| 22:15 | <beowulf> | TabAtkins: then i only half want to throw up |
| 22:16 | <TabAtkins> | markhuot: Yeah. If it's a normal quote in an article, then it should certainly just be normally written up/wrapped. |
| 22:16 | <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? |
| 22:16 | <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? |
| 22:16 | <TabAtkins> | beowulf: Is it the unicorn? |
| 22:17 | <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> |
| 22:17 | <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. |
| 22:18 | <TabAtkins> | jgraham: Yeah, totally. That fits my idea of related-but-tangential. |
| 22:18 | <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") |
| 22:18 | <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?" |
| 22:19 | <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. |
| 22:19 | <TabAtkins> | jgrahahm: Yeah, that'd work for me. You have to add "or not read at all" to account for repeated quotes. |
| 22:19 | <jgraham> | If the answer is "yes" it probably makes sense to use <aside> |
| 22:19 | <TabAtkins> | markhuot: That could also just be a <small>. |
| 22:19 | <beowulf> | TabAtkins: my nausea was rising at alarming rates until i saw the unicorn, then i was confused |
| 22:19 | <jgraham> | Anyway, I was going to bed some time ago |
| 22:19 | <jgraham> | Goodnight |
| 22:19 | <TabAtkins> | later |
| 22:20 | <markhuot> | TabAtkins: then I think I see the FOOTER confusion ;-) I would have assumed that'd be a FOOTER |
| 22:20 | <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. |
| 22:20 | <TabAtkins> | markhuot: Man, it might be. I'm not sure yet. It's also possibly appropriate as both. |
| 22:21 | <TabAtkins> | I sorta wanna restrict <footer>/<info> to <article> and <body>, though, which would make it clear that that bit was just a <small>. |
| 22:21 | <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. |
| 22:23 | <beowulf> | TabAtkins: throw up or destroy with fire |
| 22:24 | <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. |
| 22:25 | <markhuot> | Yup, makes sense, but if you allow it in body then aren't you kind of double dipping your body into two roles? |
| 22:25 | <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. |
| 22:26 | <TabAtkins> | AryehGregor: I'm totally for renaming <footer> and <aside>. I agree with your point. |
| 22:26 | <TabAtkins> | markhuot: Explain? What's the second role? |
| 22:26 | <AryehGregor> | Why even bother renaming them? What are the use-cases? |
| 22:27 | <AryehGregor> | Actually, what are the use-cases for any of them, as compared to <div class=>? |
| 22:27 | <TabAtkins> | AryehGregor: filling in semantics that useful common semantics - basically, metainfo about an article, and related-but-tangential stuff scattered throughout an article. |
| 22:27 | <AryehGregor> | Great, but semantics per se isn't a use case as far as HTML 5 is concerned, from what I've seen. |
| 22:27 | <TabAtkins> | That sentence didn't make a lot of sense, but I think you get what I mean. |
| 22:28 | <TabAtkins> | If you ignore all the new elements, sure. |
| 22:28 | <AryehGregor> | Those aren't there for semantics per se. |
| 22:28 | <TabAtkins> | But that's because that's precisely what the new elements are for. |
| 22:28 | <AryehGregor> | Most of them have clearly-defined purposes. |
| 22:28 | <TabAtkins> | Elaborate. |
| 22:28 | <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>. |
| 22:28 | <TabAtkins> | Yes. |
| 22:29 | <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. |
| 22:30 | <AryehGregor> | Since some types of progress bars would be invisible to screen readers and such. |
| 22:30 | <TabAtkins> | Indeed. And now the set of <header>/<section>/<mark>/etc. elements? |
| 22:31 | <AryehGregor> | <section> is supposed to be for automatic outline generation, isn't it? |
| 22:32 | <AryehGregor> | <mark> . . . I don't know, offhand. <header> is one of the ones I'm asking about. |
| 22:32 | <TabAtkins> | Partially. We already have <h1-6> to do that with. <section>, however, helps bless a particular way of dividing a page. |
| 22:33 | <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). |
| 22:33 | <TabAtkins> | True. |
| 22:34 | <AryehGregor> | I don't see how <aside> isn't appropriate for most sidebars. |
| 22:34 | <AryehGregor> | It would be fine for Wikipedia's infoboxes, for instance, right? |
| 22:34 | <AryehGregor> | That's basically the first example in the spec. |
| 22:34 | <TabAtkins> | Probably, yeah. But it wouldn't be appropriate for the stuff that's actually a *sidebar* on wikipedia, on the left. |
| 22:34 | <AryehGregor> | Hmm, not quite, I guess. |
| 22:34 | <AryehGregor> | Oh, no. |
| 22:34 | <AryehGregor> | I see your point. |
| 22:34 | <AryehGregor> | That would be <nav>. |
| 22:35 | <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. |
| 22:35 | <TabAtkins> | Exactly. |
| 22:35 | <AryehGregor> | I mean, just from the name. |
| 22:35 | <TabAtkins> | That is, in fact, the precise definition I keep espousing. related-but-tangential. |
| 22:35 | <AryehGregor> | I'd say "part of but tangential". |
| 22:36 | <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 |
| 22:36 | <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. |
| 22:36 | <AryehGregor> | At least for what I'd call an aside in English. |
| 22:36 | <AryehGregor> | Well, it is, frankly, right? |
| 22:36 | <AryehGregor> | I mean, it's basically meant to replace class=sidebar. |
| 22:36 | <AryehGregor> | That's why it was added. |
| 22:37 | <AryehGregor> | Anyway, I'm not clear on why these three (<header>/<footer>/<aside>) were added, if not to save typing. :P |
| 22:37 | <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. |
| 22:38 | <TabAtkins> | Aryeh: It's meant to replace the *magazine* notion of sidebar. Not the website notion. |
| 22:38 | <AryehGregor> | (I have zero classes or ids on aryeh.name. I did have to use three spans, though.) |
| 22:39 | <AryehGregor> | I never really think of stuff like Wikipedia's left column as "sidebars", I think of them as "navigation". |
| 22:39 | <AryehGregor> | So I guess <aside> vs. <nav> is intuitive to me. |
| 22:40 | <TabAtkins> | Yeah, so that's part of the problem. |
| 22:42 | <markhuot> | But one thing AryehGregor said that confused me, ASIDE is _not_ meant to replace `class="sidebar"` right? |
| 22:43 | <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". |
| 22:43 | <TabAtkins> | It's meant to replace class=sidebar, when that class is used in the magazine sense. |
| 22:43 | <AryehGregor> | Same with <header> and <footer> |
| 22:43 | <AryehGregor> | . |
| 22:43 | <TabAtkins> | Where it means "related but tangential content" |
| 22:43 | <TabAtkins> | AryehGregor: That someone was Hixie. |
| 22:43 | <markhuot> | But, going back, again, to the Zeldman.com example, it wouldn't be used for his right column, right? |
| 22:44 | <TabAtkins> | Correct. It shouldn't be used for that. |
| 22:44 | <markhuot> | The URL to reference: http://www.zeldman.com/category/html5/ |
| 22:44 | <TabAtkins> | The BBC article that jgraham linked to shows good use of the <aside> semantic. |
| 22:44 | <AryehGregor> | No, that would use <nav>. |
| 22:44 | <markhuot> | So to me that would have a `class="sidebar"` and this is one instance where ASIDE would not replace it. |
| 22:45 | <AryehGregor> | Well, no, theoretically. But <nav> could be used here. |
| 22:45 | <AryehGregor> | So you have an element you can use anyway. |
| 22:45 | <markhuot> | AryehGregor: the entire right column? Including the ads and speaking engagements? |
| 22:45 | <TabAtkins> | markhuot: Right. Sort of like how class=footer describes two fairly different things - a structural meaning, and a semantic meaning. |
| 22:45 | <AryehGregor> | Er, maybe not. |
| 22:45 | <AryehGregor> | Hmm. |
| 22:45 | <TabAtkins> | class=sidebar is both structural and semantic, and the two meanings are *often* connected on a single element, but often not. |
| 22:46 | <markhuot> | AryehGregor: I could see the here, there and elsewhere being three separate NAV elements, but not the entire column. |
| 22:46 | <AryehGregor> | That would be more like "not part of the content at all". Maybe we need something like <interface>. |
| 22:47 | <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. |
| 22:47 | <TabAtkins> | To mark "this is just part of the UI, move along"? Currently that's just what <div> is for. |
| 22:49 | <AryehGregor> | TabAtkins, no, <div> is for anything. It can be used in content too. |
| 22:49 | <AryehGregor> | markhuot, the new semantic elements are a tiny fraction of the spec. |
| 22:49 | <AryehGregor> | Each one takes what, a couple of paragraphs? |
| 22:49 | <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>". |
| 22:51 | <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? |
| 22:51 | <AryehGregor> | Namely <article>? |
| 22:52 | <TabAtkins> | markhuot: That's exactly the argument people are using. ^_^ AryegGregor, that's exactly the argument *I'm* using. |
| 22:52 | <markhuot> | TabAtikins: I hear you and feel your pain. |
| 22:59 | <markhuot> | TabAtkins: I think you're on the right track though. Most of my confusion and stubbornness is related to my own inability to understand concretely where I would use an ASIDE, HEADER, etc… |
| 22:59 | <TabAtkins> | Yeah, that's the problem for a lot of people. I'm planning to start a thread tonight about it, and the Superfriends are apparently going to send some too. |
| 23:00 | <markhuot> | That'll be helpful. One of the most helpful things for me today, was hearing your metrics for determining an element, that grounded things for me a bit. |
| 23:02 | <TabAtkins> | Yeah, I'm going to see if I can come up with something similar for <aside>, along with a better name. |
| 23:02 | <markhuot> | That'd be great TabAtkins. |
| 23:02 | <TabAtkins> | <header> is just what it sounds like, really - stuff you want to put in a page/section header rather than in the main content. It's a structural element with relatively weak semantics. |
| 23:02 | <TabAtkins> | It just means that ATs might want to skip it, is all. |
| 23:03 | <markhuot> | Yup, that makes sense to me, and is nice because there's a real world example of the benefits of using it. |
| 23:03 | <tantek> | TabAtkins - and all that reasoning applies to <footer> as well (or should). |
| 23:03 | <markhuot> | FOOTER, should have the same benefits too… |
| 23:04 | <markhuot> | :) tantek, exactly. |
| 23:04 | <tantek> | :) |
| 23:04 | <TabAtkins> | tantek: Agreed now. We should have a <footer> that is identical in nature to <header>. |
| 23:04 | <TabAtkins> | And the current <footer> semantics should be given to a new element. |
| 23:04 | <tantek> | TabAtkins - I'm unsure of the need / utility of having the current <footer> info/meta semantics being given to a new element. |
| 23:05 | <TabAtkins> | tantek: I think "article metainfo" is likely commonly put in a classed div for positioning/styling. I believe it's a common semantic, and thus at least a candidate for elementhood. |
| 23:07 | <markhuot> | TabAtkins, I'd just wonder if that "meta" stuff couldn't also go in the HEADER element. Since ATs are already skipping it (in theory), no since muddying up your source with more elements. |
| 23:07 | <TabAtkins> | markhuot: but it can just as reasonably be put in the <footer>. And in fact often is, which is why it's currently named <footer>. |
| 23:07 | <TabAtkins> | One could argue that it doesn't *need* an element, but I don't think it belongs to an *existing* element. |
| 23:08 | <TabAtkins> | It's just a question of if the semantic is common enough to bless. |
| 23:08 | <markhuot> | TabAtkins: right, but I don't think we've come up with any semantic differences between the HEADER and FOOTER other than their placement. And if that's the case couldn't they then both be the same element? |
| 23:09 | <TabAtkins> | markhuot: Semantically, yeah. But in practice people don't use the same class for both. They differentiate between <div class=header> and <div class=footer>, so if we're blessing things, we should do that too. |
| 23:09 | <TabAtkins> | The whole point is to make things unsurprising. |
| 23:09 | <tantek> | principle of least surprise |
| 23:09 | <TabAtkins> | Yah. |
| 23:09 | <tantek> | AKA JonathanMalek - it might be better to consider defining a news item which is a special kind of hAtom entry |
| 23:10 | <tantek> | oops copy/paste bug - sorry |
| 23:10 | <tantek> | make that: |
| 23:10 | <tantek> | AKA http://en.wikipedia.org/wiki/Principle_of_least_astonishment |
| 23:10 | <tantek> | (that other text was meant for / already pasted into #microformats - apologies for the noise) |
| 23:10 | <markhuot> | Hum, so let me ask you a question then TabAtkins. Why do people use .header and .footer? |
| 23:11 | <TabAtkins> | Perfect reference, tantek. That's why <footer>, if it exists, should just be a structural element meaning "stuff you put at the bottom of a section". |
| 23:11 | <tantek> | yes! |
| 23:11 | <TabAtkins> | markhuot: To separate out "stuff I put at the top/bottom of a section" from "the contents of the section". |
| 23:11 | <tantek> | and that's perfectly sufficient for most web devs/designers to go oh yeah, I do that already with class="footer", ok cool. |
| 23:11 | <markhuot> | Ah, I think I see now TabAtkins. So then there really isn't any difference between the two other than the placement. |
| 23:12 | <TabAtkins> | markhuot: If they're both going to exist (and I think it has to be both or neither, really), then yeah, placement is the only difference. |
| 23:12 | <tantek> | and that placement is *structural*, not necessarily presentational - there is a (fine but) important difference |
| 23:12 | <markhuot> | So then, that goes back to a much earlier point that they should probably both have the same rules applied (re: what's allows within) |
| 23:12 | <TabAtkins> | tantek: Can you elaborate? I don't understand the distinction enough to repeat it elsewhere. |
| 23:12 | <tantek> | really this is not so different from <thead> <tfoot> |
| 23:12 | <TabAtkins> | markhuot: Yes. |
| 23:12 | <alkarin> | greetings everybody, I hope I'll be around fr'now on *and god - this is real internet relay chat |
| 23:12 | <TabAtkins> | tantek: Yes. |
| 23:13 | <TabAtkins> | Yo, alkarin. |
| 23:13 | <tantek> | TabAtkins - consider the structure as the document tree, where as the presentation *may* reflect the document tree, it may also be very different on different devices and modalities |
| 23:13 | <tantek> | TabAtkins and re tbody tfoot, note that there *is* a tbody |
| 23:13 | <tantek> | as well |
| 23:14 | <markhuot> | tantek: I think the difference though is that THEAD and TFOOT are clearly defined to relate to a TABLE (and tabular data). HEADER and FOOTER are a bit more vague and can go in just about anything (unless TabAtkins has his way ;-)) |
| 23:14 | <tantek> | we can learn many things from the structural (and semantic) elements of tables |
| 23:14 | <hober> | IIRC <thead> : <table> :: <header> : any sectioning element |
| 23:14 | <TabAtkins> | Hm... I guess it's sort of like the distinction between <i> and <span style="font-style:italic">. The former doesn't carry *specific* information, just that the stuff contained within is typically italicized for *some* reason. |
| 23:15 | tantek | wonders if <shead> <sbody> <sfoot> would have been better, but leave that particular *shed painting problem to someone else. ;) |
| 23:15 | <hober> | heh |
| 23:15 | <TabAtkins> | hober: agreed. which is why <footer> should map to <tfoot>, as tantek says. |
| 23:15 | <alkarin> | did we have to tell the machines that we're actually defining "sub-sections" inside the body, called HEADER and FOOTER? |
| 23:15 | <markhuot> | tantek: I like it though. TabAtkins raised this earlier and I think it makes sense. |
| 23:16 | <tantek> | BTW - having thought about this longer that I really wish I had, there is another very useful feature of structural tables that could use promotion to general use |
| 23:16 | <TabAtkins> | alkarin: it's not that we *have* to, it's that we *do* already with class=header and footer. |
| 23:16 | <tantek> | the "headers" attribute |
| 23:16 | <markhuot> | Alright, well it's quittin' time over here in the EDT, so I'm going to call it a day. Thanks again everyone, it's been great. I'll hop back in later tonight or tomorrow to follow along. |
| 23:17 | <TabAtkins> | alkarin: And we do it *so* frequently that having it blessed can be a good thing. |
| 23:17 | <TabAtkins> | later, markhuot. |
| 23:17 | <tantek> | all the benefits it provides for table cells (semantics, accessibility) would also work for any other element which implicitly (perhaps through presentational coincidence) includes semantics/heading context from other elements in the document. |
| 23:18 | <TabAtkins> | tantek: Is that really something that happens in the real world, though? Tables are complex structures, and sometimes it *isn't* obvious just what's supposed to refer to what, especially when you have multiple levels of heading cells. |
| 23:19 | <TabAtkins> | But I don't know that I've ever really seen ordinary text that was moved away from the section it corresponds to for presentational reasons, except maybe to fake columns. |
| 23:19 | <TabAtkins> | And we can do columns correctly now. |
| 23:20 | <alkarin> | let me put it in this way; did "we" - the html authors, proposal makers, researchers developers etc .. have to define new SUB-SECTIONS to BODY element where we had none, ust like we had or we were offered sub divisions called THEAD and TBODY for the TABLE element, nonetheless we had our own ways passing around it, again matching all the semantical criteria |
| 23:20 | <tantek> | TabAtkins - it happens even *more* often outside of tables, because at least with tables you can imply columns/rows to determine some amount of context (as long as you can *see* them) |
| 23:20 | <TabAtkins> | tantek: I'd need to see an example. |
| 23:21 | <TabAtkins> | alkarin: I can't parse what question you're actually asking. |
| 23:21 | <tantek> | TabAtkins in many ways it is the *inverse* of what is proposed for the "subject" attribute |
| 23:21 | <tantek> | "subject" says this element applies to this other element over here. |
| 23:22 | <tantek> | "headers" says these other elements apply to this element right here. |
| 23:22 | <TabAtkins> | You talking about the microdata @subject? |
| 23:23 | <tantek> | and "headers" both works well today conceptually (in HTML4.01), and reflects the more natural way to do content/link inclusion (e.g. documents link to their stylesheets, not vice versa) |
| 23:24 | <tantek> | TabAtkins AFAIK there is no other "subject" in HTML5. So per-current spec yes, but conceptually, much more broadly. "headers" has good accessibility benefits that could be spread to other elements. "subject" as currently defined is scoped just to microdata. |
| 23:24 | <tantek> | put another way, "subject" is to "rev", what "headers" is to "rel" |
| 23:25 | <tantek> | "headers" is a space separated list of IDREFs. more http://www.w3.org/TR/html401/struct/tables.html#adef-headers |
| 23:25 | <TabAtkins> | Yeah, I know @headers. So you'd use this on <section>s placed elsewhere in the document, to point them to headings that should apply to them? |
| 23:26 | alkarin | nods affirmative. |
| 23:30 | <tantek> | TabAtkins - I'd like to see @headers available on *any* element to note what headings/semantics/context may apply to them. |
| 23:31 | <tantek> | for example a page of blog posts |
| 23:31 | <TabAtkins> | What heading would the posts refer to? |
| 23:31 | <tantek> | commonly lists the date only *once* for all the posts for that day |
| 23:31 | <tantek> | but then includes the time for each post in particular |
| 23:31 | <tantek> | (lots of examples, e.g. tumblr) |
| 23:31 | <tantek> | those individual <time> elements have to currently duplicate the date information in invisible metadata |
| 23:32 | <tantek> | much better if they could instead say headers="d123" pointing to the date element that has the date for the time. |
| 23:32 | <tantek> | the inverse, using subject on the date element to point to the time elements is both more counterintuitive (ala rev), and fragile (meta is further from the data per Ruby's Postulate) |
| 23:32 | <TabAtkins> | Any particular reason the date can't just be expressed in the header for the listing, and thus automatically apply to the posts in the outline? |
| 23:34 | alkarin | name kunter ilalan |
| 23:34 | <tantek> | TabAtkins - in many cases some amount of implied hierarchicial context can solve this yes |
| 23:34 | <tantek> | similarly to how the implied row/column context can solve this |
| 23:34 | <alkarin> | good .. I call this "rust" :p |
| 23:35 | <tantek> | but also similarly, headers *does* help in some cases in tables, and I think it would for the same kinds of cases *outside* of tables as well |
| 23:35 | <Binarytales> | TabAtkins - I was about to ask the very same question |
| 23:36 | <TabAtkins> | tantek: I'm not arguing that it could be theoretically useful. I'm saying that I don't know that I've ever seen content where it would be useful, and thus question its *practical* usefulness. If such content doesn't really exist in the wild, I don't want to cater to it. |
| 23:36 | <tantek> | basically, we've had tons of experience in the microformats community with this need for explicit content inclusion, and built the include-pattern for it, and in doing so very much felt like this needed to be a built-in language feature. http://microformats.org/wiki/include-pattern |
| 23:36 | <tantek> | and in fact we make use of the "headers" attribute on table cells to solve this for hCalendar |
| 23:37 | <tantek> | tables of events |
| 23:37 | <tantek> | http://microformats.org/wiki/hcalendar-brainstorming#Tabular_event_calendars |
| 23:37 | <alkarin> | tantek: if we are to follow that fashion inside BODY like we did inside TABLE, as you have suggested, then one day won't we be dealing with similar kinds of cases "outside" of the HTML ... like, TARGET of this document, CLASSIFY your purpose |
| 23:37 | <tantek> | and using the "headers" attribute in this fashion is *much* cleaner from a markup perspective (and easier/simpler to author) than the include-pattern. |
| 23:38 | <TabAtkins> | Hmm, I've used hresume, and specifically used the <object> include pattern. I'm not sure how that would work with @headers, though. |
| 23:38 | <tantek> | basically a use of "headers" *attribute* on your hCards in your job experience would replace a whole awkward <object> element workaround :) |
| 23:39 | <TabAtkins> | What would you point the @headers at in that circumstance, though? |
| 23:39 | <tantek> | the same thing your object data points to! |
| 23:39 | <tantek> | that's the beauty, the structure is identical but simpler |
| 23:39 | <TabAtkins> | That's not a header, though, that's an entire section. |
| 23:40 | <tantek> | right, it's an entire "chunk" of content |
| 23:40 | <tantek> | so perhaps the name "headers" is not the best for this purpose. however it is already in use for exactly this semantic in tables, thus would make sense to re-use |
| 23:40 | <tantek> | as opposed to introducing a new attribute like "includes" |
| 23:41 | <TabAtkins> | What part of the hresume would have the @headers, though? |
| 23:41 | <tantek> | (which would be fine too, however I think the principles of re-use and least vocabulary provide more benefit than creating a new name) |
| 23:41 | <tantek> | TabAtkins the hCards for your title/org/etc. in your job experience |
| 23:42 | <tantek> | right before where you currently put your <object data> includes |
| 23:42 | <TabAtkins> | Hm. Currently I'm putting them as the first element of the .htitle inside my .hcard. |
| 23:43 | <TabAtkins> | (This reminds me; I need to update my resume.) |
| 23:45 | <TabAtkins> | I don't think I fully understand the semantic intended by pointing @headers at chunks of non-heading content. |
| 23:47 | <tantek> | TabAtkins - right, so you could take whatever element you have class="vcard" on in your job experience and add headers="idref" where idref is the same thing that you have in your <object data="#idref"> now. |
| 23:48 | <TabAtkins> | But that then just means "treat the element I'm pointing to like it was one of my children". That's not the same semantic as table @headers, is it? |
| 23:48 | <tantek> | TabAtkins - it effectively is |
| 23:49 | <tantek> | structurally it's the same and thus the same semantics can be applied |
| 23:49 | <TabAtkins> | Hm, okay. I suppose I can see that. |
| 23:49 | <tantek> | like I said, the "headers" attribute may itself be poorly named |
| 23:49 | <tantek> | another instance of the <address> problem |
| 23:49 | <TabAtkins> | You'd want something like @include |
| 23:49 | <tantek> | because if you look at what ATs can (and) do with the headers attribute, they *do* treat it structurally and semantically like an include |
| 23:49 | <Binarytales> | I always though of it more as "this element already told you some information that also relevant here" |
| 23:50 | <tantek> | Binarytales - precisely correct |
| 23:50 | <tantek> | and yes that is what "headers" does |
| 23:51 | <Binarytales> | "headers" is a poor name for it. authors might assume that in the information needs to come before where it is including which isn't true |
| 23:52 | <TabAtkins> | One nice thing about attributes is that you don't really have to worry about parsing constraints. All attributes parse equally, and so minting a new one isn't bad unless it's already in wide use meaning something different. |
| 23:52 | <TabAtkins> | (One of the best things about data-* is that it namespaces private data, preventing such collisions.) |
| 23:54 | <TabAtkins> | dude, maciej, you need to go to bed. ^_^ |
| 23:54 | <TabAtkins> | Or, wait, you Apple or Opera? |
| 23:54 | <othermaciej> | TabAtkins: wait, what? |
| 23:54 | <othermaciej> | it's 4 PM in my time zone |
| 23:55 | <TabAtkins> | k. Sorry, that you were one of the Opera folk. |
| 23:55 | <TabAtkins> | "strange name" translates mentally to "norwegian" for me in this room. |
| 23:56 | <othermaciej> | dude |
| 23:56 | <othermaciej> | I was all in the news with a specific mention of Apple recently |
| 23:56 | <othermaciej> | well, on Ars Technica anyway |
| 23:56 | <TabAtkins> | I don't pay any attention to Ars Technica. |
| 23:56 | <othermaciej> | for the HTML WG co-chair thing |
| 23:56 | <othermaciej> | I do have a weird name though! |
| 23:57 | <AryehGregor> | The name sounds more Eastern European to me. |
| 23:58 | <AryehGregor> | It would have more diereses and slashes through letters and stuff if it were Scandinavian, and fewer alarmingly long stretches of consonants. |
| 23:58 | <TabAtkins> | I don't have enough experience to reliably distinguish. |
| 23:59 | <AryehGregor> | Hmm, "Maciej Stachowiak". Not so many stretches of consonants. |
| 23:59 | <AryehGregor> | Do "ch" and "w" even exist in the Scandinavian languages? |