/irc-logs / w3c / #html-wg / 2007-04-05 / end

Options:

# Session Start: Thu Apr 05 00:00:00 2007
# Session Ident: #html-wg
# [00:27] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
# [00:30] * Parts: hasather (hasather@81.235.209.174)
# [01:02] * Parts: zcorpan_ (zcorpan@84.216.43.95)
# [01:11] * Joins: Lachy (chatzilla@220.245.91.147)
# [01:11] * Joins: sbuluf (lgos@200.49.140.65)
# [01:50] * Joins: htmlr (htmlr@203.206.237.84)
# [01:51] * Quits: heycam (cam@203.214.79.176) (Quit: bye)
# [01:51] * Joins: heycam (cam@203.214.79.176)
# [01:52] * Quits: tylerr (tylerr@66.195.32.2) (Connection reset by peer)
# [01:56] * Joins: karl (karlcow@128.30.52.30)
# [02:06] <karl> oooh boeing has joined the HTML WG
# [02:07] <karl> http://www.w3.org/2000/09/dbwg/details?group=40318&public=1&order=org
# [02:07] <karl> * 277 group participants,
# [02:07] <karl> * 277 in good standing,
# [02:07] <karl> * 44 participants from 16 organizations
# [02:07] <karl> * 233 Invited Experts
# [02:13] * Quits: h3h (bfults@66.162.32.234) (Quit: |)
# [02:15] * mjs notes Nokia and AOL newly on list
# [02:15] <karl> AOL it has been almost one week :)
# [02:16] <karl> mjs: there was even a mail from arun http://lists.w3.org/Archives/Public/public-html/2007JanMar/0677
# [02:17] * dbaron wonders who else will be at the AC meeting (not sure I'm going)
# [02:17] * karl will not be at the AC Meeting
# [02:17] <karl> but Dan Connolly will be
# [02:18] <dbaron> Banff seems like an annoying location to me -- it's only a 3 hour flight from California, but then there's a 2 hour bus ride on top of that.
# [02:18] <dbaron> (flight to Calgary, that is)
# [02:18] <karl> dbaron: yes definitely. I wonder why the organizers of the WWW conferences put it there.
# [02:20] * Quits: hober (ted@66.162.32.234) (Quit: ERC Version 5.1.3 (IRC client for Emacs))
# [02:20] <karl> hmm anne's weblog post has created a new load of applications
# [02:21] <Hixie> yeah now that chris has joined i guess we'll start in earnest
# [02:34] <karl> holy cow
# [02:35] <karl> I have received an email, I want to join, with the signature and legal disclaimers on sharing the content 20 times longer than the mail
# [02:35] <Lachy> karl: that sounds typical
# [02:36] * Quits: kingryan (kingryan@66.92.187.33) (Quit: kingryan)
# [02:36] <Lachy> ha! http://lists.w3.org/Archives/Public/www-tag/2007Apr/0030.html :-)
# [02:37] <Hixie> lachy: i was hoping we'd have a wiki page explaining all the reasons that was wrong, wrought from your mails and henri's
# [02:38] <Lachy> sure, we can write one up later
# [02:39] <Lachy> I intend to respond to all the mails in that thread since my last reply a few days ago. We can then use most of those responses to write something in the wiki
# [02:40] <Hixie> oh, cool
# [02:40] <Hixie> yeah, that'd be awesome
# [02:41] <karl> I love the list of people names (participating to the HTML WG), it always give me the desire to explore and find out the origin of the name and its meaning.
# [02:41] <karl> things like Higginbotham
# [02:43] <karl> for the last two days I had a lot of applications with very gaelic names.
# [02:44] <Lachy> Hey Hixie, I had a look at String.toLower() in ECMAScript to see how it handles lower casing of unicode chars
# [02:44] <Lachy> its definition seems rather poor too
# [02:44] <Lachy> :-(
# [02:44] <Hixie> :-(
# [02:44] <Hixie> i remembered yesterday that xbl2 might give you an answer
# [02:44] <Lachy> It has an informative note stating that it should use the unicode case mappings
# [02:44] <Hixie> since i had to deal with the prefixes there
# [02:45] <Lachy> I had a look at XBL2 as well
# [02:45] <Hixie> was it ok?
# [02:46] <Lachy> well, it depends on the resolution of my outstanding issue in Selectors regarding case sensitivity of namespace prefixes, but...
# [02:47] <Hixie> i wouldn't expect that to be resolved any time soon
# [02:47] <Hixie> unless anne pushes for it
# [02:47] <Hixie> and even then
# [02:47] <Lachy> it does with the way Selectors currently defines them to be case insenstive, it handles the issue reasonably well, cause it explicitly defines which takes precendence in cases like xmlns:foo="x" and xmlns:FOO="y"
# [02:47] <Lachy> yeah, I realise that
# [02:48] <Hixie> can you use the xbl2 ideas at all here?
# [02:48] <Hixie> or doesn't it really work for that
# [02:48] <Lachy> well, these are my options:
# [02:49] <Lachy> 1. Define them to be case insensitive by lowercasing the prefix and normatively referencing the Unicode case mappings.
# [02:49] <Hixie> if you do 1 you have to give a locale for the mapping, so that the turkish dotted-i situation is defined
# [02:49] <Lachy> 2. Define that the prefixes be passed as-is to the NSResolver, and leave it up to the author to determine how to handle case sensitivity
# [02:50] <Lachy> I'm inclined to spec #2 as it makes implementation much easier, and technically doesn't really violate Selectors
# [02:50] <Hixie> 2 implies that the prefixes aren't case-insensitive, which could make it impossible to use an off-the-shelf selectors solution in theory
# [02:51] <Lachy> hmm. that's true
# [02:51] <Lachy> wait, actually, it technically does violate selectors. I don't know what I was thinking
# [02:51] * Joins: h3h (bfults@70.95.237.98)
# [02:52] <Lachy> I should to look into how css3-namespaces handles the issue with @namespace
# [02:52] * Quits: dbaron (dbaron@63.245.220.242) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [02:54] * Quits: mjs (mjs@64.81.48.145) (Quit: then we we)
# [02:57] * Quits: h3h (bfults@70.95.237.98) (Quit: h3h)
# [03:01] <Lachy> ah, it doesn't. This is everything CSS3 NS has to say on the matter: "Namespace prefixes are, like CSS property names, case-insensitive."
# [03:03] <Dashiva> Sometimes I dream about a world where the canonical form of HTML elements was lowercase
# [03:04] <Lachy> Dashiva: the XHTML WG have been dreaming about that for nearly 10 years
# [03:05] <Hixie> HTML5 actually makes the canonical form lowercase (it has to, for compat with XHTML), it's just the DOM interfaces that return uppercase in non-XML HTML documents
# [03:07] <Dashiva> Well, then it's still as arbitrary as it used to be, IMO
# [03:07] <Hixie> what would you have changed?
# [03:08] <Dashiva> If canonical form is lowercase, I would expect the DOM to return the same
# [03:08] <Hixie> ah well, too late to change that.
# [03:08] <Hixie> doesn't change what the canonical case is, though, just means the DOM is quirky :-)
# [03:09] <Dashiva> Yeah, too many scripts depending on uppercase now, but it's still nice to dream
# [03:10] <karl> Lachy: css3 namespaces are local to the stylesheet. They are *not* XML namespaces.
# [03:11] <Lachy> karl: I know that, but that's not the issue
# [03:11] <Lachy> The issue is that it says they are case insensitive, but fails to define or normatively reference anything that defines how to do case comparisons
# [03:11] <karl> hmm good points
# [03:12] <karl> s/s//
# [03:12] <Lachy> and it's the same issue I'm having with selectors API
# [03:14] <karl> maybe you could ask internationalization
# [03:15] <karl> http://lists.w3.org/Archives/Public/public-i18n-core/
# [03:16] <Lachy> yeah, I could. But it would be so much easier if the CSSWG could get a new editor for Selectors and fix the issue there. It's easy for them to do, I already proposed how, it's just not getting fixed
# [03:17] <Lachy> in other words, I'd rather the problem were fixed at the source, rather than having to work around it
# [03:33] * Joins: mjs (mjs@64.81.48.145)
# [03:44] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [03:46] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Client exited)
# [04:00] * Joins: olivier (ot@128.30.52.30)
# [04:03] * Quits: Philip (excors@80.177.163.133) (Quit: Philip)
# [04:11] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [04:23] <karl> For those going to XTech http://esw.w3.org/topic/HTML/XTech2007BoF
# [04:26] <sbuluf> karl, what does this line in the charter mean? "Editing APIs and user-driven WYSIWYG editing features."
# [04:26] <sbuluf> how do you read it, what is it asking for?
# [04:27] <karl> sbuluf: it means that authoring tools are very important for the design of HTML.
# [04:29] <sbuluf> karl, more particularly, does it ask that the language is able to be edited in a WYSIWG manner? As in a stand alone editor?
# [04:31] <karl> it means that wysiwyg editors implementations might have constraints which are important enough to have influences on the language.
# [04:32] <sbuluf> thanks
# [04:33] <marcos> CSS4 3D Module? :P
# [04:56] * Quits: cbulock (cbulock@209.153.128.248) (Quit: leaving)
# [04:56] * Joins: h3h (bfults@70.95.237.98)
# [05:00] * Joins: tylerr (tylerr@24.16.148.66)
# [05:01] * Quits: tylerr (tylerr@24.16.148.66) (Quit: Leaving)
# [05:03] * Joins: Zeros (Zeros-Elip@69.140.48.129)
# [05:35] * Quits: mjs (mjs@64.81.48.145) (Quit: then we we)
# [05:48] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Get thee behind me, satan.)
# [05:51] * Mallory is glad to see interesting threads on list.
# [05:51] <Mallory> And great ideas.
# [05:55] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [06:01] <Lachy> woah! Chris has barely been in the group a day and Matthew Raymond is already interrogating him with random questions
# [06:03] <Mallory> He was waiting that for ages.
# [06:05] <Lachy> yeah, but it's hardly appropriate to shoot 20 questions at someone like that. It just seems a bit over the top to me, as I'm sure the issues will get dealt with one at a time in due course
# [06:06] <Mallory> Every question will launch a single threat.
# [06:07] <Mallory> Wow, I read all the threads today,I'm impressed.
# [06:16] * Joins: mjs (mjs@64.81.48.145)
# [06:16] <Lachy> hmm. The <term> element would probably be better handled with a predefined class on i, b and/or span, if its use cases really can be justified
# [06:23] * Joins: Grauw (ask@202.71.92.74)
# [06:24] <marcos> yeah, I still don't really see the need for <term>...
# [06:25] * Joins: tylerr (tylerr@24.16.148.66)
# [06:25] <Zeros> Lachy, Why should we start using predefined classes to change the meaning of a element?
# [06:25] <Grauw> I have, when authoring documents.
# [06:26] <Lachy> Zeros: Microformats have been extending the semantics of elements for years
# [06:26] <Grauw> the problem is always that you want to use <dfn>, but that’s only for the defining instance, and <em> isn’t appropriate either
# [06:26] <Zeros> Lachy, then why add <menu> or any of the things in HTML5 if we might as well use a microformat?
# [06:26] <Zeros> <dialog> would just as well be one too
# [06:27] <Lachy> <menu> already exists, and because menu has some additional features that aren't suppored by <ul>
# [06:27] <Grauw> in my opinion, <footer> <header> <article> and all those silly tags should just be <section> with predefined classnames
# [06:27] <Zeros> I'm not really sure we should add predefined classes either.
# [06:28] <Zeros> Grauw, wouldn't a meaningful attribute be better. <section rel="footer"> ?
# [06:28] <Lachy> Grauw: they're so commonly used, it's much more convenient to use elements for them
# [06:28] <Lachy> Zeros: rel is for link relationships
# [06:28] <Grauw> zeros: then you should use role, not rel
# [06:28] <Zeros> Grauw, Though I'm not sure that's best either, but class names don't make a lot of sense
# [06:28] <Grauw> Lachy, I don’t agree
# [06:28] <Mallory> <div> aren't <section> ?
# [06:28] <Lachy> no, div != section
# [06:29] <Grauw> class names are mainly convenient from a styling perspective, otherwise people would duplicate the value of a separate attribute in a class attribute anyway
# [06:29] <Lachy> section, header, etc. have specific processing requirements for heading levels
# [06:29] <Zeros> Mallory, The goal is that a <section> combined with <header> gives a nesting context to work around the <hx> limitation. <div> is too commonly used as a generic container. <div><div><div> ...
# [06:29] <Grauw> lachy: yes, and that’s only making it more complex
# [06:30] <Zeros> Grauw, Why? They should be using the attribute selector?
# [06:30] <Lachy> aren't you the one who argued to have <h> introduced recently?
# [06:30] <Mallory> The meaning of a section could depend of the context too.
# [06:30] <Zeros> Any browser that supports HTML5 is going to support attribute selectors too Grauw
# [06:30] <Lachy> and yet you're saying the heading level algorithm makes things too complex?
# [06:30] <Grauw> zeros, because that’s what they always say, people should use ‘semantic’ names for classes, ne :)
# [06:30] <Grauw> Zeros: I’m fine with @role ;p
# [06:30] <Grauw> I’d just rather have predefined classes than nothing at all
# [06:31] <Lachy> role is not well defined
# [06:31] <Zeros> I don't see anything to gain from predefined classes
# [06:31] <Grauw> Lachy, <h> is very simple really :)
# [06:31] <Zeros> How do you style them?
# [06:31] <Lachy> simple? what?
# [06:31] <Lachy> <h> is very much undefined
# [06:31] <Grauw> doh
# [06:31] <Grauw> it’s not in the spec
# [06:31] <Zeros> There's no way to give them default styles for cross platform compatibly. People will end up * { margin: 0; padding: 0; }'ing them all over again.
# [06:32] <Grauw> Lachy, I’m sorry, but <h> is in no way *more* difficult than the current situation
# [06:32] <Zeros> Font rendering, screen size, there's all kinds of things that are devices dependent.
# [06:32] <Mallory> <h deep="1"> per exemple ?
# [06:32] <Grauw> Zeros, what are you talking about precisely?
# [06:32] <Grauw> mallory, ugh!
# [06:32] <Zeros> Grauw, the style of a predefined class
# [06:32] <Lachy> Grauw: if <h> were defined, the algorithm would be the almost the same, so the complexity would be the same
# [06:32] <Grauw> ah
# [06:32] <Grauw> yes, that’s true
# [06:33] <Grauw> then again, where role would be used, I don’t think you would want predefined styles
# [06:33] <Zeros> I don't think we should be adding predefined classes at all
# [06:33] <Mallory> Sorry, I believed <h> sould replace <h1> and others.
# [06:33] <Lachy> Mallory: <h deep="1"> would be worse than just using <h1>
# [06:33] <Grauw> Lachy: well you just said something different :)
# [06:33] <Zeros> Mallory, it did in XHTML2, I think they used <header> in HTML5
# [06:33] <Lachy> Mallory: <h> isn't backwards compatible and <h1> to <h6> aren't gong anywhere
# [06:33] <Grauw> Lachy: my argument to make it simpler was to only use <section> and <h1>...<h6>
# [06:34] <Grauw> ack, unfinished sentence
# [06:34] <Lachy> Mallory: I didn't say anything different. <h deep> would be worse because it's longer to type and has no additoinal benefits
# [06:34] <Mallory> Sure.
# [06:34] <Mallory> Why replace it so ?
# [06:34] <Grauw> anyway, I’m not really very interested in promoting <h> at the moment other than just making the occasional reference to it ;p
# [06:35] <Zeros> Lachy, If that's all that matters we certainly shouldn't be adding <audio> then. We should use <bgsound> since it already exists and just add attributes
# [06:35] <Grauw> I absolutely understand the arguments why you would *not* want to have it
# [06:35] <Lachy> good, cause I'm not arguing against <h> and more, it's been rejected
# [06:35] <Grauw> Lachy: Zeros is right
# [06:35] <Lachy> s/and/any/
# [06:35] <Zeros> The goal is to not break the web, and <h> doesn't break the web.
# [06:35] <Grauw> Again, Zeros is right :)
# [06:35] <Zeros> Lachy, and <h> was accepted as http://www.whatwg.org/specs/web-apps/current-work/#header
# [06:35] <Zeros> XHTML2 called it <h> :)
# [06:36] <Grauw> Lachy: header is different
# [06:36] <Lachy> <bgsound> is not equivalent to <audio> in anyway
# [06:36] <Grauw> sorry
# [06:36] <Grauw> Zeros: header is different
# [06:36] <Zeros> Grauw, they both solve the same problem. As far as XHTML2 was concerned it wasn't though.
# [06:36] <Grauw> the <header> element indicates a section of one kind
# [06:36] <Lachy> we'd have to deal with the issue of having 2 <bgsound> elements, extending its API, and many other issues that greatly affect copmat
# [06:36] <Lachy> *compat
# [06:36] <Zeros> Grauw, XHTML2 said <h> + <section> does what <header> + <section> does in HTML5
# [06:37] <Lachy> Zeros: not quite
# [06:37] <Grauw> zeros, no, header isn't used like that last I read?
# [06:37] <Grauw> <header> === <section role="header">
# [06:37] <Lachy> Grauw: it seems that's the intention of <section role>
# [06:37] <Grauw> <section><h1>blabla === <section><h>blabla
# [06:37] <Lachy> but it's not defined well enough
# [06:37] <Zeros> Grauw, "The first heading in a sectioning element gives the header for that section. Subsequent headers of equal or higher rank start new (implied) sections, headers of lower rank start subsections that are part of the previous one."
# [06:38] <Zeros> same concept
# [06:38] <Lachy> and not back compat
# [06:38] <Grauw> Lachy, are you referring to XHTML2 now? because whether or not XHTML2 defines it properly or not isn’t really important
# [06:38] <Lachy> ok
# [06:38] <Zeros> Grauw, I don't think section role="header" makes sense since you'd need to nest them
# [06:38] <Grauw> we can always do it better
# [06:38] <Lachy> I just don't see how you can promote something that isn't well defined nor backwards compatible
# [06:39] <Grauw> Zeros: now I’m confused
# [06:39] <Zeros> The goal of header is that we can define sections of a document with their own header contexts, you're not stuck in the h1-h6 model
# [06:39] <Grauw> "The header element represents the header of a section." - this phrasing does not correspond to the examples below
# [06:39] <Grauw> or my impression of what it was
# [06:39] <Zeros> Of course that's mucked up in HTML5, but its close enough
# [06:39] <Zeros> header elements must have at least one h1, h2, h3, h4, h5, or h6 element as a descendant.
# [06:39] <Zeros> hmm
# [06:39] <Zeros> I guess its just a group for the header of the section
# [06:40] <Zeros> still solves the relationship problem then
# [06:40] <Zeros> guess it doesn't add new headers
# [06:40] <Grauw> lachy: what? <header> isn’t backwards compatible either, AND it wasn’t defined until it appeared in the WHATWG spec either
# [06:40] <Grauw> of course some new suggestion is not going to be ‘well defined’ yet
# [06:40] <Grauw> and ‘backwards compatible’ is as Hixie suggests not really a good term to use, we should rather think in terms of the principles
# [06:40] <Grauw> that is, don’t *break* anything, but adding new stuff is not prohibited
# [06:40] <Lachy> Grauw: header also introduces new functionality that isn't available with anything else
# [06:41] <Zeros> The examples for <header> are poor too
# [06:41] <Lachy> and it's not much of a problem if it's ignored
# [06:41] <Grauw> So does <section role=header>
# [06:41] <Zeros> There's no reason to add a <h1> immediately followed by a <h2> like that. That wouldn't create a good outline.
# [06:42] <Grauw> zeros, according to the huge section on creating an outline, I think it probably would.
# [06:42] <Grauw> it’s a couple of pages of text trying to explain the exact algorithm :)
# [06:42] <mjs> Grauw: there's "Don't Break The Web" but also "Degrade Gracefully"
# [06:43] <Grauw> mjs: headings are usually styled completely different from their default presentation anyway
# [06:43] <tylerr> What you have is <section><title><content></...></...></...>
# [06:43] <Zeros> Grauw, the examples they show aren't backwards compatible. They have a <p> before a <h1> inside the <header>. With another <header> before it with a <h2>. In a legacy interpretation that <p> is associated with the <h2> not the other <h1> in the <header>
# [06:44] <Grauw> plus: h1...h6 are still there, you could gradually start using <h> as more browsers support it natively if that's what you want
# [06:44] <Zeros> Since we're assuming unknown tags just get ignored
# [06:45] <Grauw> zeros: legacy implementations don't really associate any type of sectioning with headings anyway
# [06:45] <Grauw> as the HTML4 specification doesn’t really define it
# [06:46] <Grauw> HTML5 tries to, but I think fails, it can and should not
# [06:46] <Zeros> Grauw, its the logical flow assumption. Whatever follows the heading is associated with it (vaguely)
# [06:46] <Grauw> zeros: that doesn’t have to be so per se. this example is a good one
# [06:46] <Zeros> A screen reader that lets you jump through headings would skip that <p> since its before the <h1>
# [06:47] <Zeros> That's an example
# [06:47] <Grauw> another is that a section might end, and there might be another paragraph in a higher-level section that continues where it left off
# [06:47] <mjs> I don't know what you guys are debating, just wanted to point out there is more than oen kind of compatibility that we care about
# [06:47] <Grauw> Zeros: hence the purpose of <section> elements.
# [06:47] <Grauw> *one of the purposes
# [06:47] <Zeros> Grauw, We're trying to make this work in a backwards compatible manner. Why else would we go to such great lengths to use all this legacy stuff?
# [06:47] <Grauw> or in this case, <header> (or <section role="header">)
# [06:48] <Zeros> <p> before <h1> being associated is not backwards compatible
# [06:48] <Zeros> It renders decently in a visual UA, but the associated of them is wrong
# [06:48] <Grauw> that’s only a farily academic case I think
# [06:48] <Grauw> *fairly
# [06:49] <Grauw> the association is indeed wrong, HTML4 says that the section that belongs to a heading follows the heading
# [06:49] <Zeros> :)
# [06:50] <Zeros> The spec needs to be more clear then with how you use <header> and that example should be removed
# [06:50] <Grauw> but I do think the spec gives a very legitimate use there in that example, and it would something you simply cannot do in HTML4
# [06:51] <Grauw> so the options are: 1. not allow the author to do it at all, or 2. allow the author to do it, but not be handled 100% ideally by all UAs
# [06:51] <Zeros> Grauw, Examples in the spec are dangerous because people argue intent later. The dialog for dl in HTML4 is case of that.
# [06:51] <Grauw> I think option 2 has preference here
# [06:51] <Grauw> ugh, yeah, that’s horrid
# [06:51] <Zeros> We shouldn't be doing this in the spec either
# [06:51] <Grauw> I think we should
# [06:52] <Grauw> after all, there are specific use cases that <section> solves and that could not be done in the ‘old way’
# [06:52] <Zeros> If backwards compatibility is a major concern the examples should be of best practices
# [06:52] <Grauw> ignoring them would be like claiming that there’s no need for <section>
# [06:52] <Grauw> As Hixie said: it would be better not to use the term ‘backwards compatibility’ but rather refer to the design principles
# [06:53] <Zeros> Grauw, then the principal of not breaking the web
# [06:53] <Grauw> backwards compatibility can be a very broad and a very narrow term
# [06:53] <Grauw> well, this does not break the web
# [06:53] <Grauw> it does not break existing pages
# [06:53] <Zeros> Grauw, sure it does. Its changing the association of new documents so they meaning something entirely different to older UAs
# [06:53] <Grauw> that is not what the breaking the web principle covers
# [06:54] <tylerr> To not break existing pages the new spec would need to be HTML 4.01++
# [06:54] <Grauw> you see, UAs will improve over time
# [06:54] <mjs> Is someone advocating for <h>?
# [06:54] <Grauw> no
# [06:54] <Zeros> Grauw, then we don't need to worry about breaking anyway ;)
# [06:54] <mjs> what's the point of debate?
# [06:54] <Grauw> Lachy brought it up :)
# [06:54] <mjs> I can't tell and I don't feel like reading all the scrollback
# [06:54] <Lachy> don't blame me
# [06:54] <tylerr> No clue mjs, I'm glancing at this while playing sudoku. :-)
# [06:54] <Grauw> Lachy: ;p
# [06:55] <Grauw> the debate at the moment is about <header> versus <section class="header"> / <section role="header">
# [06:55] <Zeros> mjs, that the <header> example in HTML5 is poor because it shows a <p> before a <h1> inside the <header> with a <h2> in another header before it. The association is that the <p> is under the <h2>, not the <h1> its grouped with in the <header>
# [06:55] <Grauw> or in the meantime it moved to <h1>...<h6> being not the first element in a section
# [06:55] <Zeros> Which shows a weakness in the <header> design
# [06:56] <Zeros> the associations are wrong
# [06:56] <Grauw> Zeros: NOT according to the HTML5 rules
# [06:56] <Zeros> well, potentially
# [06:56] <Zeros> Grauw, HTML5 rules meaning NOTHING to old UAs and screen readers
# [06:56] <Grauw> Old UAs are irrelevant
# [06:56] <tylerr> Well, here's food for thought: The <p> before the <h1> could very well be intro text that comes before the main header of the section. Whereas the <header> provides the main area that the intro text and main header reside.
# [06:56] <Grauw> they will be improved over time
# [06:56] <mjs> Zeros: I don't know what the example is, but if you send mail to whatwg list I'm sure it will be fixed
# [06:57] <Grauw> Old UAs are not covered in the design principles
# [06:57] <Zeros> Grauw, I don't agree there. If old UAs don't matter we don't need to care about radical changes at all.
# [06:57] <mjs> <header> is a sectioning element in HTML5, isn't it?
# [06:57] <Zeros> yes
# [06:57] <Grauw> one of the many
# [06:57] <mjs> which would make it act the same for purpose of <h_> elements as <section class="header"> or <section role="header">
# [06:58] <Grauw> Zeros: the principle that applies to old UAs is "Degrade Gracefully"
# [06:59] <Grauw> (I was wrong saying they were not covered at all)
# [06:59] <mjs> but obviously an element is easier to use and semantically stronger than a predefined class, and role is a useless duplication of class
# [06:59] <tylerr> So if it can't recognize <section><header>, give it <div><h1>.
# [06:59] <Zeros> Grauw, Wrong association is not degrading gracefully.
# [07:00] <Zeros> Certainly not if we screw with how screen readers should look at a document
# [07:00] <Grauw> Zeros, please put things in perspective! It does not have to be a 100% perfect every time
# [07:00] <Grauw> as long as it ‘works’, which in this case, it does.
# [07:00] <Zeros> it doesn't 'work'
# [07:00] <Grauw> it does.
# [07:01] <Grauw> screen readers will be updated to process HTML5
# [07:01] <Zeros> You're excluding disabled users; I don't think that's acceptable.
# [07:01] * mjs still doesn't understand the debate
# [07:01] <Zeros> Grauw, and so will browsers, /eventually/
# [07:02] <Grauw> mjs: Zeros is concerned that if a screen reader user ‘jumps ahead’ to the next header, in case of the second example at http://www.whatwg.org/specs/web-apps/current-work/#header , he will miss the <p> that comes before the <h1>
# [07:02] <Grauw> however, if he just reads the document normally, there is no problem. this is a <p> in the header, so it will probably be read first anyway
# [07:02] <Zeros> Or any other tool that is using the headers to determine sections of the document
# [07:02] * Parts: olivier (ot@128.30.52.30) (Leaving)
# [07:02] <Grauw> and even if he would skip it, it’s not as if it’s really relevant to the header or the document
# [07:03] <mjs> those are supposed to be three separate examples, right?
# [07:03] <Grauw> yes
# [07:03] <Grauw> I assume so
# [07:03] <Zeros> Grauw, That's a trivial case
# [07:03] <mjs> I don't see how that is any worse than <div> <p>Welcome to...</p><h1>Voidwars!</h1> </div>
# [07:04] <Grauw> Zeros, I’m sorry, but I just can’t be in favour of saying ‘you can never have anything before a heading in a section’. This is a new spec and it should be doing new things within reasonable limits
# [07:04] <Zeros> mjs, Together they show the flaw in the <header> design though. Anything inside <header> but before the first <hx> is not associated with it in a non-html5 compliant UA
# [07:04] <mjs> there's nothing specific to <header> about it, is there?
# [07:04] <Grauw> 99% of UAs don’t make any type of ‘association’ anyway
# [07:04] <Zeros> Most statistics are made up
# [07:04] <Zeros> prove it :)
# [07:05] <mjs> do some UAs associate headers with their containing block-level element?
# [07:05] <Grauw> Mozilla, IE, Opera, Safari and Konqueror don’t.
# [07:05] <mjs> (including content before the header?)
# [07:05] <Grauw> that makes up 99%, likely
# [07:05] <Grauw> oh, and I doubt Google does either.
# [07:05] <Zeros> mjs, As I understand it screen readers let you jump through a document, and there could potentially be tools out there that do it too
# [07:06] <mjs> Zeros: Safari integrates with the built-in Mac OS X screen reader, and I don't know of such an issue
# [07:06] <Grauw> Zeros: so old readers will jump to a place that’s slightly off. Big deal.
# [07:06] <Zeros> Grauw, heh
# [07:06] <Grauw> it’s a jump. You’re skipping content anyway
# [07:06] <mjs> in any case, I don't think that is a strong enough reason to avoid adding any new block-level elements
# [07:06] * Grauw nods
# [07:07] <Zeros> mjs, I wasn't suggesting that
# [07:07] <mjs> Zeros: is this issue different for <header> than for other newly introduced block-level elements?
# [07:07] <Grauw> it’s not
# [07:08] <Zeros> mjs, I don't see it that way. If we assume newer browsers ignore those elements and just throw in the text content.
# [07:08] <Zeros> s/newer/older/
# [07:09] <mjs> Zeros: I don't understand your last statement
# [07:09] <mjs> "I don't see it that way" -- what do you not see that way?
# [07:10] <mjs> If we assume newer browsers ignore new elements then what?
# [07:10] <Zeros> mjs, oh, I miss read that. I do see it as a different problem.
# [07:10] <mjs> what's a different problem?
# [07:10] <Zeros> HTML4 defined that the grouping for <hx> was what followed it.
# [07:10] <mjs> <header> vs other newly introduced block-level elements?
# [07:11] <Zeros> mjs, What other elements would have a similar issue?
# [07:11] <Grauw> Zeros, you need to look at the practical problem that overriding that definition causes, and if you do look at it it’s relatively minor
# [07:11] <mjs> Zeros: any new block-level elements, such as <section>, <footer>, <aside>, etc
# [07:11] <Grauw> Zeros, <section> <article> <footer> etcetera
# [07:12] <Grauw> I don’t think this is related to <header> specifically
# [07:12] <Zeros> <footer> if it came before the rest of the document would be in the wrong place I guess
# [07:12] <Grauw> eh?
# [07:13] <Grauw> <footer><p>And now...</p><h1>The credits</h1></footer>
# [07:13] <Zeros> or the section
# [07:13] <Grauw> <section><p>Continueing...</p><h1>Chapter 2</h1></section>
# [07:13] <Grauw> it’s the same thing.
# [07:14] <Zeros> Grauw, <section><header></header><footer></footer> contents here</section>
# [07:14] <tylerr> Grauw: For some reason that looks like a Monty Python gone HTML. :-D
# [07:14] <Zeros> footer is now before the conten
# [07:14] <Grauw> tylerr ;p
# [07:15] <Grauw> Zeros, if that’s how HTML5 says it works, that’s just utterly confusing and wrong
# [07:15] <Zeros> Grauw, I'm looking for something more specific
# [07:15] <Zeros> though it looks like that'd be allowed
# [07:16] <Grauw> from what I understand, <header> <footer> <article> <aside> are just special types of <section> elements, and nothing more
# [07:16] <Grauw> in other words, if you would use it like you mention above, then you would have two sections nested inside the first
# [07:16] <Zeros> Grauw, not from what I see
# [07:16] <Grauw> (where header and footer would be kind of inappropriate in that place)
# [07:17] <Zeros> "The footer element represents the footer for the section it applies to. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like."
# [07:17] <Zeros> Footer should be nested inside a section then
# [07:17] * Grauw grabs head * argh, they’re going to mess it up, completely...
# [07:18] <Zeros> If we use what you propose Grauw we get <section><section role="header"></section> <section role="footer"></section> ... </section>
# [07:18] <Zeros> like I said, we have to nest them
# [07:18] <Grauw> I think the <body> tag is also considered a ‘sectioning’ element here
# [07:18] <mjs> back in a few, need to perf test something
# [07:18] * Quits: mjs (mjs@64.81.48.145) (Quit: then we we)
# [07:18] <Grauw> in other words, you would not have to nest it, but can use it directly in the body
# [07:19] <Zeros> Grauw, but you would for subsections, which are clearly shown as being proper
# [07:19] <Grauw> this phrasing merely makes it somewhat more generic so that it could theoretically also be used to create headers and footers for sections
# [07:19] <Zeros> I like the idea, what we need to fix the ordering. <footer> should be required to be last in a <section>
# [07:19] <Grauw> if there were a case where that would be useful to you
# [07:19] <tylerr> :D
# [07:20] <tylerr> So I'll chime in here.
# [07:20] <Grauw> that ordering makes no sense
# [07:20] <tylerr> Basically we're looking at how to structure the content of a page.
# [07:20] <Grauw> btw, if we already have trouble understanding it, imagine how it will be for average joe. HTML5 makes a lot of things way too complex, and way more than necessary
# [07:20] <tylerr> Pages have headers, footers, asides, and main sections.
# [07:21] <Grauw> which are really all just types of sections
# [07:21] <tylerr> Tables have <thead><tbody> and <tfooter>
# [07:21] <tylerr> Yes.
# [07:21] <Zeros> tylerr, in a backwards compatible manner. You're already allowed to do <thead/><tfoot/><tbody/>
# [07:21] <tylerr> Sure.
# [07:21] <Zeros> So the <section><header/><footer/> stuff</section> model is fine with that.
# [07:22] <Zeros> (not suggesting XHTML, just tired of typing it)
# [07:22] <Grauw> do browsers support <tfooter> if it’s not at the end it :)
# [07:22] <Zeros> tylerr, the problem is the order those are in in a legacy browser. They're wrong since the footer is first.
# [07:23] <Zeros> The spec should be made more clear like with the <table> that says you can't have a <thead> at the end.
# [07:23] <tylerr> What I'm saying is, <section><header /><content /><aside @align(near|far) /><footer /></section> could be used.
# [07:23] <tylerr> Or are we trying to keep <section> as the only tag.
# [07:23] <tylerr> Being that it could describe headers, footers, asides, and content.
# [07:23] <Grauw> typerr: I’m trying.
# [07:24] <Zeros> tylerr, Grauw suggested that, I think <footer|header|section> makes more sense than role attributes
# [07:24] <Grauw> I think it would be a lot more sensible
# [07:24] <Zeros> Still not sure I like aside
# [07:24] <Grauw> aside is maybe a bit of an awkward name, but has a very clear use in documents
# [07:24] <Zeros> Maybe its the name that I don't like
# [07:24] <Zeros> the idea is good
# [07:24] <tylerr> Well, side could be styled to be a "Warning|Alert|Note|etc" box inside the content section as well.
# [07:25] <Grauw> if you look at any technical journal, ‘asides’ are used extremely frequently
# [07:25] * tylerr nods.
# [07:25] <Grauw> *scientific
# [07:25] <Zeros> Grauw, until they restyle the document and the <aside> is no longer the side bar but a bar that goes across the bottom.
# [07:25] <Grauw> it’s not a side bar
# [07:26] <Zeros> Grauw, I know, but the name has strong implications of that
# [07:26] <Grauw> it’s a box that floats somewhere, the exact position or presentation isn’t really important although it would help if it’s close to the relevant subject
# [07:26] <Grauw> well, if you have a better suggestion, I’d love to hear a proposal on the list :)
# [07:26] <Zeros> Grauw, it need not float though
# [07:27] <Grauw> as I said, the exact presentation isn’t really important (although floating would be reasonably typical)
# [07:27] <tylerr> This is why we need a glossary of agreed upon definitions.
# [07:27] <tylerr> An aside to me is something that is "placed or kept separate and distinct as for a purpose"
# [07:27] <Zeros> tylerr, very specifically defined in the spec. The name still feels poor to me. Its great to be abused.
# [07:27] <tylerr> To someone else it's a footer, or a warning box, etc.
# [07:28] <Zeros> Grauw, As for the case of predefined classes: .note: "It must only be used on the following elements: aside, p, span"
# [07:28] <tylerr> Grauw: An automatic float could be applied with an @align of top|bottom|near|far
# [07:28] <tylerr> But then that gets into CSS
# [07:28] <tylerr> :-)
# [07:29] <Zeros> How can we possibly say that, potentially millions of documents already use the class note on elements that are not those.
# [07:29] <Zeros> Which means they violate this spec
# [07:29] <Grauw> Predefined classes that apply to this element:
# [07:29] <Grauw> example, issue, note, search, warning
# [07:29] <Grauw> (aside)
# [07:29] <Zeros> yes
# [07:29] <Grauw> Zeros: that’s why people argue for @role instead of predefined classnames
# [07:30] <Grauw> as I said, I prefer role, but if the alternative is having nothing at all (or the current element names) I’d rather have predefined classnames than nothing
# [07:30] <Zeros> Grauw, I think role in conjunction with the foundation sectioning elements makes sense
# [07:30] <Grauw> me too.
# [07:31] <Zeros> footer,header,section + role avoids invalidating older documents and you still get all the same benefits
# [07:31] <Grauw> eh, why have footer and header?
# [07:31] <Zeros> Grauw, to prevent the nesting problem I showed earlier
# [07:31] <tylerr> <footer role="header" /> Uh oh... ;-)
# [07:31] <Grauw> I’m sorry, but I must have missed that? what problem?
# [07:31] <Zeros> tylerr, we wouldn't define the header role
# [07:32] <Grauw> why not?
# [07:32] <Zeros> <section><section role="header"></section> <section role="footer"></section> ... </section>
# [07:32] <Grauw> your idea seems kind of half-assed if you make exceptions for header and footer :)
# [07:32] <Grauw> yes, what’s wrong with that?
# [07:32] <Zeros> Grauw, role defines extra information in addition to its structural component.
# [07:32] <Zeros> footer is a structural part of the section. "warning" or "note" is not.
# [07:33] <Grauw> so is <article> and <aside>
# [07:33] <Grauw> and <nav>
# [07:34] <Zeros> Those aren't strictly related to what a section is though
# [07:34] <Grauw> role specifies the role that a section plays in the document
# [07:34] <Zeros> Grauw, the definition of role in the HTML5 spec says its made up of headers, content and footers
# [07:34] <Zeros> err not role, section
# [07:35] <Grauw> http://www.whatwg.org/specs/web-apps/current-work/#sectioning
# [07:35] <Grauw> 3.8.1. The body element
# [07:35] <Zeros> Grauw, look at what the predefined classes apply to
# [07:35] <Grauw> 3.8.3. The nav element
# [07:35] <Grauw> 3.8.4. The article element
# [07:35] <Zeros> They don't apply to header or footer, they do apply to <section>
# [07:36] <Zeros> header and footer define the logical parts of a section.
# [07:36] <Grauw> which predefined classes apply to which element seems kind of arbitrary
# [07:36] <Zeros> Grauw, you can argue that nav and article are both types of section sure. They could be in the role, but header and footer don't make sense there.
# [07:36] <Zeros> The header isn't a section, its a group that applies to a section.
# [07:37] <Grauw> aside has 5, article has one (‘warning’??), nav none...
# [07:37] <Grauw> I’m sorry, the HTML5 specification is really confusing me here :).
# [07:38] <MikeSmith> Grauw - are you in Tokyo?
# [07:38] <Grauw> mike, Kyoto
# [07:39] <MikeSmith> OK
# [07:39] <MikeSmith> you said you are a student, or ?
# [07:39] * Joins: mjs (mjs@64.81.48.145)
# [07:39] <tylerr> Welcome back mjs.
# [07:39] <mjs> hello tylerr
# [07:39] <Grauw> yes, and I used to work at Backbase too before I came here to study
# [07:40] <Grauw> I never officially resigned, will probably start working for them again when I get back to the Netherlands
# [07:40] <MikeSmith> Grauw - Ok. Just asking out of curiosity (aka being nosey)
# [07:40] <Grauw> :)
# [07:42] <Zeros> Grauw, the TCPConnection stuff should be fun. Very bizarre protocol requirement.
# [07:43] <tylerr> Looks like Zeros and Grauw will be heading up the <section> team. ;-)
# [07:43] <Grauw> SVG has it, so HTML should too!
# [07:43] <Zeros> SVG has tcp?
# [07:43] * Zeros wonders about use-cases :p
# [07:43] <Grauw> I think it does, it was one of the complaints about the complexity of the spec
# [07:44] * Quits: h3h (bfults@70.95.237.98) (Quit: |)
# [07:44] <mjs> I don't like TCPConnection
# [07:44] <mjs> or SVG's Connection
# [07:44] <Grauw> I don’t really care much for it... if the browser wants to implement it, it’d better be in a standard way
# [07:44] <mjs> but I need to work on a counter-proposal
# [07:44] <mjs> but <video> is higher on my agenda
# [07:44] <Zeros> mjs, please do.
# [07:44] <mjs> as is getting HTML5 into the HTML WG
# [07:44] <Grauw> tsk, video :)
# [07:44] <Zeros> mjs, the protocol for TCPConnection seems awkward.
# [07:45] <Zeros> its glorified telnet
# [07:45] <mjs> Zeros: I don't like that it invents a custom protocol and lets you run it over ports that IANA assigned to other protocols
# [07:45] <mjs> I would rather have a way to get a persistent connection that is based on http
# [07:45] <Zeros> mjs, that'd make more sense.
# [07:45] <mjs> I think a new http method plus a proof of concept apache module would cut it
# [07:46] <Zeros> wouldn't we need to get that in a RFC though?
# [07:46] <mjs> and then a nicer message-passing two-way API
# [07:46] <mjs> yes, any new protocol or protocol extension should probably be submitted to IETF
# [07:47] <Grauw> what does it try to solve exactly that you can’t just do with HTTP?
# [07:47] <mjs> TCPConnection?
# [07:47] <Grauw> yes
# [07:47] <Zeros> Grauw, http doesn't really support streaming well
# [07:47] <mjs> it tries to solve the problem of making a persistent two-way connection to the server, where you can send messages back and forth without protocol setup / teardown
# [07:47] <Zeros> Grauw, and you can't reply when you're getting a response
# [07:47] <Grauw> would be nice if every section included notes like ‘what does it try to solve’, etc
# [07:48] <Grauw> aha
# [07:48] <mjs> you could extend the CONNECT method to apply to non-proxies
# [07:49] <Grauw> I suppose prefer REST-based communication :)
# [07:49] <Grauw> although there is a demand for push stuff
# [07:49] <mjs> sure, but REST-based communication is not very well suited to things like instant messaging
# [07:49] <mjs> or live shared whiteboards
# [07:49] <Zeros> mjs, seems like there'd need to be a way to append headers mid message
# [07:50] <Grauw> yeah you have to mess with keeping connections open and trickle data through
# [07:50] <mjs> or SubEthaEdit-style collaborative editing
# [07:50] <mjs> Zeros: I think headers are irrelevant - you just make the connection and talk whatever protocol the server offers
# [07:50] <mjs> which could be, say XMPP
# [07:51] <Grauw> of course, that trick is in the meanwhile fairly well supported by backend architectures (e.g. Cocoon)
# [07:51] <Zeros> mjs, headers already exist in http for metadata on the packet body
# [07:51] <Grauw> so I’m not sure if there’s a real reason to have something new
# [07:51] <mjs> Zeros: you don't need or want headers for every packet
# [07:51] <Zeros> that'll save people from implementing their own protocol to parse out. Channel: #foo\nSender: username\n\nmessage foo bar\n
# [07:52] <mjs> Zeros: although if you wanted that, you could use chunked encoding
# [07:52] <Grauw> The new release of Backbase is going to have push support as well, iirc, as there was a fair customer demand for it.
# [07:52] <mjs> I'd expect people would use something like XML or JSON for messages
# [07:53] <Zeros> speaking of which we should specify a better eval() for JSON-like data
# [07:53] <mjs> yes, two-way streaming connection support is really just an optimization
# [07:53] <mjs> Zeros: ES4 will add that
# [07:53] <Zeros> mjs, Oh, nice.
# [07:54] <Zeros> Two way connection support is possible now with Flash or Java scripting. Doesn't work so well in Opera since they didn't implement the NS scripting interface though
# [07:55] <Grauw> ‘Java scripting’, heh :)
# [07:57] <Zeros> mjs, Safari is going to need better behavior with sleeping content for these remote connections to work too. As it is now when it sleeps all plugins when minimized you'd timeout the connection for a chat server.
# [08:17] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Get thee behind me, satan.)
# [08:24] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [08:32] <Lachy> mjs: what's ES4 adding for JSON?
# [08:32] <mjs> Lachy: serialization and deserialization
# [08:32] <mjs> I need to talk to Brendan more about ES4 sometime though
# [08:32] <mjs> it's a little XHTML2-ish in current state
# [08:32] <Lachy> do you know what functions, objects, or whatever they're specifically introducing for it?
# [08:32] <mjs> don't recall offhand
# [08:33] <mjs> I believe there is a public wiki holding current draft
# [08:33] <Lachy> is ES4 the same as E4X?
# [08:34] <Lachy> and is that like JavaScript 2.0?
# [08:35] <hsivonen> mjs: XHTML2-ish? I thought Brendan already had Opera on board so it isn't a Mozilla-only thing.
# [08:35] <mjs> ES4 is not the same as E4X
# [08:35] <mjs> but it's gonna be JavaScript 2.0
# [08:35] <hsivonen> Lachy: I'd expect E4X to continue to be an optional language feature
# [08:35] <mjs> hsivonen: I mean, it does not Degrade Gracefully
# [08:35] <hsivonen> oh
# [08:35] <mjs> (although it tries to be backwards compatible with existing ES3)
# [08:36] <mjs> if you use any of the new ES4 syntactic features, your script is unusable in browsers that only support ES3
# [08:36] <mjs> though library stuff you could do conditional checks for
# [08:37] <Lachy> does ES4 change any of the syntax that exists in ES3?
# [08:39] * hsivonen sees "semantic meaning" again in the morning mail
# [08:45] * Quits: tylerr (tylerr@24.16.148.66) (Quit: Leaving)
# [09:00] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
# [09:07] <Hixie> it's all very well people saying that the whatwg should stop working and the work should happen in the html wg instead, but nothing's happening in the html wg yet, so what are we supposed to do in the meantime? *confoosed*
# [09:08] <mjs> I disagree with those people but should probably say something more useful than -1
# [09:09] <hsivonen> Hixie: do you have a suggestion on what's the best way to move to deciding on whether the HTML WG will adopt the XBL2 editing model?
# [09:09] <hsivonen> (in my opinion, it is the only reasonable model put forward)
# [09:10] <hsivonen> (also, now that Chris has joined, we might actually make a decision)
# [09:11] <mjs> I was going to write up a proposal on decision/editing policy
# [09:11] <marcos> hsivonen, briefly, what was the XBL2 editing model?
# [09:11] <mjs> we could do that right now and put it on the wiki if y'all can help me write it up
# [09:11] <mjs> but I need to quit for a bit and do some speed tests
# [09:11] <mjs> brb
# [09:11] * Quits: mjs (mjs@64.81.48.145) (Quit: then we we)
# [09:11] <Lachy> marcos, the editor is a benevolent dictator who has final say on everything
# [09:11] <marcos> I thought so
# [09:11] <marcos> I'm ok with that.
# [09:12] <marcos> Gets stuff done.
# [09:12] <Lachy> yep!
# [09:12] <Hixie> hsivonen: i have no idea how to make decisions in the htmlwg... i've never had to do that step before, i've always gotten there as a status quo :-)
# [09:12] <hsivonen> marcos: the spec is in version control somewhere. Hixie edits as the benevolent dictator. upon commit, a version with Mozilla copyright headers is published at mozilla.org. from time to time, a version with W3C headers is published as a WD under /TR/
# [09:13] <marcos> Ok, that makes sense to me.
# [09:13] <hsivonen> marcos: here the version control would be the WHATWG SVN, which already has tools created by Anne et al.
# [09:13] <hsivonen> marcos: and s/mozilla.org/whatwg.org/
# [09:14] <Hixie> and dev.w3.org probably would have a copy of the editor's draft version with w3c branding
# [09:15] <hsivonen> Hixie: is that easy for you to handle without breaking Anne's SVN tracker?
# [09:15] <marcos> That model did work really well for XBL2 in WAF... but only because all *active* wg members support hixie's work.
# [09:15] <Lachy> should Apple, Mozilla and Opera make a W3C Submission with the WHATWG spec, which the HTMLWG can then review and accept as the basis for continued work?
# [09:15] <Lachy> just like they did with WF2
# [09:16] <marcos> So we would need to change the model a bit for the HTML WG... once mjs gets back we can write it up.
# [09:16] <anne> Anything interested being discussed?
# [09:16] * anne skimmed through the discussion and it seemed to be about semantics again...
# [09:16] <anne> <h deep="1">?!
# [09:16] <Lachy> or should we just post the proposal to public-html and wait for all the +1s and -1s to roll in?
# [09:16] <Lachy> :-)
# [09:16] <Lachy> anne: that's the proposal to replace <h1>
# [09:17] <anne> lol
# [09:17] <marcos> Anne, we are discussing totalitarianism
# [09:17] <Hixie> hsivonen: yeah it'd be easy, just a script that copies the files around and does cvs checkins automatically (the xbl2 work was checked in to two cvs reps at the same time too)
# [09:17] <hsivonen> I think the proposal should explain the model well and should have an explanation about the role of the WHATWG list framed in a way that the people who believe in the referent power of the W3C can accept
# [09:17] <hsivonen> Hixie: good
# [09:18] <Hixie> Lachy: that's up to them, i don't really have anything i can do about that
# [09:20] * Joins: edas (edaspet@88.191.34.123)
# [09:21] <anne> whoa, what's up with all the questions to cwilso
# [09:21] <hsivonen> Hixie: how was the XBL2 copyright stuff arranged?
# [09:23] <hsivonen> anne: to me, it looks like the premise of the question was that Microsoft commitment to certain features is wanted
# [09:23] <marcos> People need to chill out about MS and cwilso. People really don't understand the role of a WG chair.
# [09:24] * Joins: mjs (mjs@64.81.48.145)
# [09:24] <marcos> mjs, should we do write that stuff up... ?
# [09:25] <mjs> marcos: sorry, I was out of the channel
# [09:25] * mjs checks recent logs
# [09:25] <marcos> editing policy
# [09:25] <marcos> mjs, nothing has happened.
# [09:25] <mjs> ah, ok
# [09:25] <marcos> We were waiting for ya.
# [09:26] <Lachy> I have to go to catch a train, and then a plane, bye everyone
# [09:26] <marcos> cya lachy
# [09:26] <hsivonen> Lachy: bye
# [09:26] * Quits: Lachy (chatzilla@220.245.91.147) (Quit: ChatZilla 0.9.78 [Firefox 2.0.0.3/2007030919])
# [09:26] * mjs thinks
# [09:26] <Hixie> hsivonen: w3c owned the copyright in the first place because netscape submitted xbl1
# [09:27] <mjs> so I'm not really interested in writing up details about dual-track editing, I think that goes along with discussion to adopt HTML5, which will be started in due course
# [09:27] <mjs> (and in this case by "in due course" I mean RSN, not far off in the future)
# [09:28] <mjs> but
# [09:28] <mjs> I'd like to write something like this as a policy for taking actions (editing or otherwise)
# [09:28] <mjs> for a given category action, there should be a designated responsible person (or maybe in some cases persons)
# [09:29] <marcos> Explain category action?
# [09:29] <mjs> an action category may be making a change to a spec, or adding a test to a test suite, organizing an f2f, etc
# [09:29] <hsivonen> Hixie: (not speaking for the Foundation) it seems to me it would be prudent copyright-wise to make it so that the WHATWG can publish an annotated spec if necessary
# [09:29] <mjs> whoever is responsible should listen to discussion and make a preliminary decision
# [09:29] <mjs> if some people do not like the decision, they can object through argument and the designated responsible person should take their feedback into account, possibly making changes
# [09:29] <mjs> if anyone objects strongly enough, they can call for a vote
# [09:30] <mjs> perhaps we should have a requirement to second a motion for a full group vote
# [09:30] <mjs> and vote is carried out by email or web survey, as per web charter
# [09:30] <Hixie> hsivonen: well if, say, mozilla was to grant w3c copyrights to a copy of the spec, that wouldn't mean that they would lose that copyright themselves
# [09:30] <mjs> this is basically a W3C WG version of the WHATWG editorship model
# [09:30] <mjs> slightly generalized
# [09:30] <Hixie> hsivonen: much like mozilla has their own copy of the xbl2 spec
# [09:31] <mjs> (I'm imagining for instance that it could apply just as well to the test suite maintainer(s), or other such things)
# [09:31] <Hixie> hsivonen: and whatwg has a copy of the wf2 spec
# [09:31] <marcos> Hixie, how does wht mjs currently happen in WHATWG? I don't like the voting because it is not mandatory.
# [09:31] <mjs> in whatwg there is no full group voting
# [09:31] <mjs> but in theory there is a small group that has the power to override
# [09:31] <mjs> I don't think we want to make the HTMLWG pick some sort of select committee for that purpose
# [09:32] <mjs> but that is another possibility, that people elect an override committe
# [09:32] <mjs> that seems lame and political though
# [09:32] <marcos> I like the idea of having designated people at the top... I assume of the 250+ people in the working group, only about 30 will actively contribute
# [09:32] <Hixie> marcos: in WHATWG the WHATWG members (see the WHATWG charter) can override me
# [09:32] <mjs> marcos: then I also assume only 30 will vote on anything brought to a vote
# [09:32] <anne> heh, Boeing joined
# [09:32] <anne> and one of the W3C guys left
# [09:32] <mjs> why is Boeing joining noteworthy?
# [09:33] <anne> dunno, I wonder what their interest in HTML is
# [09:34] <mjs> (several people have mentioned it)
# [09:34] <mjs> I am not really sure why they are a W3C member
# [09:34] <mjs> I am slightly happy that Nokia joined, though unsure if their rep would be active
# [09:34] <Hixie> boeing are relatively active in the w3c (at least at the ac level, as i understand it)
# [09:34] <hsivonen> Boeing is *big* on documentation
# [09:34] <anne> maybe they use it for documentation and such
# [09:34] <hsivonen> you could write documentation in HTML
# [09:35] <mjs> I'd like to see Yahoo and IBM join
# [09:35] * anne too
# [09:35] <mjs> IBM specifically so Sam Ruby can be in the WG
# [09:35] * marcos would like to see Adobe
# [09:35] <mjs> oh yeah, them too
# [09:35] <mjs> they are in the CSS WG
# [09:36] <marcos> They are entering the browser business
# [09:36] <mjs> you mean Apollo?
# [09:36] <marcos> yeah, that thing
# [09:36] <Zeros> Apollo is not a browser
# [09:36] <mjs> I don't expect them to do any core work on the engine
# [09:36] <marcos> zero, Apollo has a browse component
# [09:37] <Zeros> marcos, it embeds webkit
# [09:37] <marcos> I was just going to say...
# [09:37] <MikeSmith> As far as Boeing, I've heard they maintain an especially large number of internal websites.
# [09:38] <MikeSmith> Boeing was also sorta famously one of the biggest adopters of SGML for producing their documentation.
# [09:38] <Zeros> marcos, in itself though its no more a browser than the AIM client for windows which uses Trident
# [09:38] <MikeSmith> service manuals for jets and such, I guess
# [09:38] <mjs> Apollo is intended as a runtime for desktop apps, not a browser
# [09:39] * Quits: Lachy_ (Lachlan@124.168.25.222) (Ping timeout)
# [09:39] <Zeros> mjs, Do you know if they're going to be using the Webkit (Safari 3.0) engine? Seems the beta of Apollo has a build from a while ago in there.
# [09:40] <marcos> Zeros, I haven't looked into it too much so I won't comment further... however, the fact that it renders HTML means something...
# [09:40] <Zeros> marcos, so do lots of applications like the windows help viewer
# [09:40] <marcos> What does windows help view use?
# [09:41] <anne> HTML
# [09:41] <Zeros> marcos, http://labs.adobe.com/wiki/index.php/Apollo:DeveloperFAQ#Is_Apollo_a_web_browser.3F
# [09:41] <mjs> Zeros: I don't know when they will update but I believe they plan to
# [09:41] <marcos> "Theoretically you could build a web browser on top of Apollo." :)
# [09:42] <Zeros> mjs, alright, cool.
# [09:46] * Joins: zcorpan_ (zcorpan@84.216.40.174)
# [09:50] <marcos> ...anyway, mjs. I think the current model of one editor lots of reviews will probably be the easiest to manage. Setting up committees might be a pain, but then again those groups may naturally emerge around specialized topics. Hopefully camps will not form.
# [09:51] <marcos> I have yet to see anyone from the HTMLWG put forward a detailed review of the HTML5 spec.
# [09:51] <marcos> (on the HTMLWG list)
# [09:52] <anne> I have yet to see anyone do that
# [09:53] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Get thee behind me, satan.)
# [09:54] <marcos> Safely (optimistically) assuming HTML5 will be brought over to this WG, I think that is the logical place to start.
# [09:56] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [09:58] * marcos see home time... yay! 4 day weekend!
# [10:00] * Quits: Zeros (Zeros-Elip@69.140.48.129) (Quit: Leaving)
# [10:02] <mjs> I don't think a detailed review would be the right place to start actually
# [10:02] <mjs> I think a high-level review would be the right place to start
# [10:02] <mjs> and it would be helpful if volunteers could summarize major additions / removals / changes relative to HTML4
# [10:02] <mjs> in terms of actual functionality
# [10:02] <mjs> like "parse error handling defined" might be one
# [10:03] <mjs> "syntax no longer an SGML application" could be another
# [10:03] <anne> maybe I should invest some time in that
# [10:03] <mjs> "added <canvas> element and associated API" could be one
# [10:03] * anne has some free days
# [10:03] <marcos> mjs, people have done this
# [10:03] <mjs> I think it is only fair that the WG get to see what they are signing up for before they adopt it
# [10:04] <mjs> marcos: there are some lists of deprecated elements, not sure if there is an up to date list of new elements / attributes
# [10:04] <anne> it should be quite up to date, but I think it could be a bit more detailed and prolly on a separate wiki page
# [10:05] <marcos> There are lots of people here who could put together such a summary.
# [10:05] * marcos looks at Anne, Hixie, Lachy, hsivonen... :)
# [10:07] <marcos> In fact, lachy put together a nice presentation a few months ago...
# [10:07] <marcos> http://lachy.id.au/dev/presentation/future-of-html/
# [10:07] <anne> WHATWG or W3C wiki?
# [10:07] <marcos> WHATWG might be more relevant.
# [10:07] <mjs> whatwg wiki would be a good starting point
# [10:08] * zcorpan_ will hold a presentation about html5 next month, albeit in swedish
# [10:08] <marcos> Anne is doing one in two weeks here in brisbane
# [10:08] <marcos> Australia
# [10:08] <anne> I should also be doing one at a Spanish web conference end of June
# [10:09] * Quits: anne (annevk@86.90.70.28) (Connection reset by peer)
# [10:10] * Joins: anne (annevk@86.90.70.28)
# [10:11] * Joins: ROBOd (robod@86.34.246.154)
# [10:14] <marcos> Mjs, maybe you could review lachy's presentation and transcript and see what more we would need?
# [10:14] * Quits: anne (annevk@86.90.70.28) (Ping timeout)
# [10:14] <marcos> The actual powerpoint slides are quite good too at illustrating functionality.
# [10:16] <mjs> marcos: I assume any talk like this is a set of highlights by nature and might not be complete enough, but I bet it would be a good starting point
# [10:17] <marcos> yeah, that's what I think too but I guess it would be good to get consensus on how much detail we actually need before we simply point people to reading the HTML5 spec
# [10:18] * marcos has to go... :(
# [10:19] <marcos> bye everyone
# [10:24] * Joins: anne (annevk@86.90.70.28)
# [10:28] * Quits: mjs (mjs@64.81.48.145) (Quit: then we we)
# [10:30] * Joins: mjs (mjs@64.81.48.145)
# [10:30] <Grauw> Boeing, hmm, interesting.
# [10:35] * Joins: karl (karlcow@128.30.52.30)
# [10:35] <anne> http://wiki.whatwg.org/wiki/Changes_from_HTML4 has a start
# [10:36] <anne> I suppose elements that have changed in semantics should also be mentioned...
# [10:36] <anne> such as <strong>, <small>, etc.
# [10:37] <hsivonen> Hixie: are you planning on defining frames in HTML5?
# [10:38] <zcorpan_> anne: pretty much all elements are slightly changed semantics i think
# [10:39] <anne> <a> hasn't
# [10:39] <anne> <h1-h6> haven't really
# [10:39] <anne> (they're still headings)
# [10:39] <anne> and backwards compatible
# [10:39] <mjs> that's not a bad start
# [10:39] <zcorpan_> <a name> is an anchor in html4, a placeholder for a link in html5
# [10:40] <zcorpan_> perhaps a bad example since it's invalid html5 but anyway
# [10:40] <mjs> changed elements would also be good to mention
# [10:40] <mjs> and new / removed / changed APIs
# [10:41] <zcorpan_> is http://simon.html5.org/test/ie7b2-bugs/008.html invalid?
# [10:41] <mjs> (new / removed / changed attributes should be mentioned w/ changes for an element but I guess global ones deserve their own space)
# [10:41] <hsivonen> anne: um. the semantics of h1–h6 have changed pretty significantly
# [10:42] <anne> hsivonen, in a way that's backwards compatible with HTML4
# [10:42] <hsivonen> anne: given that you can now opt to use a single heading level with <section>s like you'd use <h> in XHTML 2.0
# [10:42] <zcorpan_> anne: what isn't? :)
# [10:42] <anne> <strong> for instance
# [10:42] <anne> <i>, <b>
# [10:42] <anne> <small>
# [10:42] * Joins: hasather (hasather@81.235.209.174)
# [10:42] <anne> <menu>
# [10:43] <anne> <hr>
# [10:43] <zcorpan_> why are they not backwards compatible?
# [10:43] <mjs> <h1> changed more significantly than <i> from the point of view of expected presentational effect
# [10:43] <Grauw> Haybe introducing <h> to be a generic section heading, and allow <h1>...<h6> only if they’re used in the proper order and rank is a good idea.
# [10:43] <anne> maybe not
# [10:43] <Grauw> *Maybe
# [10:44] <Grauw> ;p
# [10:44] <zcorpan_> h1-h6 are seldom used as their "proper rank"
# [10:44] <zcorpan_> people have all sorts of ideas of how they should be used
# [10:45] <mjs> I have not yet been fully convinced of the goodness of <h*> being given rank by section containership
# [10:45] <hsivonen> Grauw: no. the whole point of the HTML5 approach was that the outline algorithm must reconcile the use of old and new style heading levels and implied sections
# [10:45] <mjs> I think that will change the rendering of a lot of existing documents
# [10:45] <zcorpan_> mjs: does it have to affect rendering?
# [10:45] <anne> existing docs don't use <section>
# [10:45] <hsivonen> Grauw: the XHTML 2.0 approach doesn't solve the problem of incoming document mixing and matching stuff
# [10:45] <zcorpan_> that would break the expectations of people who use the number for font size
# [10:46] <anne> lets not have another heading debate
# [10:46] <Grauw> hsivonen, how would what I just said not make that possible?
# [10:46] * anne grows tired of heading debates
# [10:46] <Grauw> two nested <section>s? use <h2>.
# [10:46] <anne> is there wiki syntax for <dl>?
# [10:46] <Grauw> or rather <h3>, because there's the body
# [10:46] <anne> so we could explain the rationale behind the change
# [10:47] <zcorpan_> anne: use a table?
# [10:47] <hsivonen> Grauw: you need to define a deterministic processing model. just legislating that inconvenient cases are not allowed is not enough
# [10:47] <hsivonen> Grauw: it's not like Hixie was unaware of <h>
# [10:47] <Grauw> so maybe define that h1...h6 are ignorant of any sectioning at all
# [10:47] <anne> how is that useful?
# [10:48] <anne> things should be easy and useful
# [10:48] <anne> not clean
# [10:48] <hsivonen> Grauw: you are taking the approach of making inconvenient cases undefined
# [10:48] <Grauw> hsivonen: Hixie knows a lot of things, doesn’t mean he’s always right
# [10:48] <hsivonen> Grauw: which doesn't help at all
# [10:48] <anne> what I meant to say was that things should be easy and useful over a clean design
# [10:48] <mjs> anne: but existing docs do use things that HTML5 defines as sectioning elements
# [10:48] <Grauw> (or at the least that I always have to agree with him :))
# [10:48] <anne> mjs, only <body>?
# [10:48] <zcorpan_> people will slap <nav> and <article> to their existing documents, and existing documents use h1-h6 not <h>
# [10:48] <mjs> interestingly, <header> is not a sectioning element, invalidating earlier debate on this
# [10:49] <zcorpan_> with the current definition it will work fine
# [10:49] <mjs> anne: blockquote
# [10:49] <anne> oh
# [10:49] <Grauw> well mjs it says it has the semantics of a heading (like h1...h6), but I don’t think it says that it’s not a section element?
# [10:50] <hsivonen> Grauw: sectioning elements say that they are sectioning elements
# [10:50] <Grauw> I see
# [10:50] <anne> also: "The header element represents the header of a section."
# [10:50] <Grauw> well anyway, I can’t really say I find it simple
# [10:50] <mjs> <header> has to contain an <hn> element but isn't one itself
# [10:51] <Grauw> how all these differrent elements interact
# [10:51] <Grauw> mjs, it is, that’s what it says
# [10:51] <hsivonen> Grauw: there's a very specific algorithm
# [10:51] <Grauw> he rank of a header element is the same as for an h1 element (the highest rank).
# [10:51] <zcorpan_> Grauw: just think of <h1> as you <h> and don't worry about the rest
# [10:51] <mjs> <hn> in blockquote might be rare enough to not be a problem in practice
# [10:52] <mjs> so I semi-withdraw my objection
# [10:52] <zcorpan_> your*
# [10:52] <anne> Grauw, if everything time you'd find something not easy you'd introduce a new element the eventual language would be complex, not easy
# [10:52] <anne> Grauw, also, just use <h1> and <section>
# [10:52] <Grauw> zcorpan_: that’s reasobly easy, although I still find it weird having a rank indicator in it, but I was rather referring to the <nav> <header> <footer> <section> and pals
# [10:52] <hsivonen> mjs: headings inside blockquotes do not participate in the main document outline
# [10:52] <mjs> hmm, actually the heading and section part does say <header> is a heading
# [10:53] <Grauw> hsivonen, ah, yet another exception :)
# [10:53] * Quits: anne (annevk@86.90.70.28) (Connection reset by peer)
# [10:53] <hsivonen> Grauw: it is exception that you need in order to make the blockquote and outline semantics sane
# [10:54] <hsivonen> Grauw: <h> would not help
# [10:54] <Grauw> I suppose I agree it makes sense for blockquote
# [10:57] <mjs> ok, maybe it's not a problem
# [10:57] <mjs> I am scared of the complex outlining algorithm, but it doesn't seem to be needed except to generate an outline or table of contents
# [10:57] <hsivonen> my only gripe with Hixie's algoritm is that it isn't immediately obvious how the algoritm maps to a state machine doing a single document-order pass over the document
# [10:58] <hsivonen> mjs: well, in the future the CSS WG could introduce selectors that match based on the outline algorithm
# [10:58] <Grauw> Maybe I shouldn’t make off-hand remarks about <h> that generate 4 pages of discussion :).
# [10:59] <mjs> those could be painful to implement, especially in the face of dynamic updates
# [10:59] * Grauw nods
# [10:59] <mjs> (selectors based on section level)
# [11:00] <mjs> is there an intended use for associated section or associated heading (other than maybe navigation aids?)
# [11:01] <zcorpan_> automatic numbering of headings?
# [11:01] <hsivonen> navigational "what's the heading of the paragraph I am reading?" would be a reasonable use case
# [11:01] <Grauw> zcorpan, the current algorithm doesn't exactly make that an easy task :)
# [11:01] <hsivonen> zcorpan_: ideally, that should integrate with css counters
# [11:02] <zcorpan_> hsivonen: indeed
# [11:02] <mjs> automatic numbering of headings would only need to know a heading's section nesting level
# [11:02] <hsivonen> which brings us back to selectors
# [11:03] <mjs> I'm wondering about the rather complex algorithm for determining "associated section" / "associated header", which is a lot fancier than the rules for section nesting level
# [11:04] <mjs> those terms are not referenced outside 3.8.11.2 right now
# [11:10] <Grauw> mjs: do you think the design principle on graceful degradation could use a note on that it is a temporal problem (as opposed to e.g. breaking the web)?
# [11:10] <mjs> temporal?
# [11:10] <Grauw> *temporary
# [11:11] <mjs> you mean because browsers will update?
# [11:11] <Grauw> ultimately
# [11:11] <Grauw> in the end
# [11:11] <Grauw> yes
# [11:11] <Grauw> and old devices will cease to be used
# [11:11] <mjs> well, there's fewer different browsers than web sites
# [11:11] <mjs> by many orders of magnitude
# [11:12] <mjs> but the problem is, authors are unlikely to make content that breaks in older browsers at first, and that gives browsers less incentive to implement such features, since they won't be used as much
# [11:12] <mjs> so it's still an important consideration
# [11:12] <mjs> less so than breaking content, I think
# [11:12] <Grauw> Yeah, I don’t think it’s unimportant
# [11:13] <hsivonen> also, sometimes authors have irrational old browser concerns. for example, they use one feature that utterly breaks in legacy browsers but are afraid of using another feature on the same page over concerns about legacy compat
# [11:14] <zcorpan_> like ajax without fallback
# [11:14] <hsivonen> yes
# [11:14] <Grauw> but I see graceful degradation now being used as an argument to withhold new things
# [11:14] <hsivonen> it seems to me that authors are more willing to use legacy browser-incompatible scripting features than markup or style features
# [11:15] <Grauw> e.g. the discussion we had earlier, ‘<p> before a <h1>, yet in the same section, that breaks existing UAs’
# [11:16] <mjs> I don't think it does
# [11:16] <Grauw> ok, it was just a thought that maybe it would be valueable that over time, it is less of an issue.
# [11:16] <Grauw> *valueable to mention
# [11:16] <mjs> really the scale of the breakage is more relevant than the duration
# [11:17] <Grauw> (is there actually some kind of script for mIRC that automatically updates previous sentences if you type s/something/somethingelse ?)
# [11:17] <Grauw> mjs: in this particular case, screenreaders were one of the groups that kind of used the functionality that content is always after the heading
# [11:18] <Grauw> if you say they’re a minority, you get blamed for discriminating the disabled :)
# [11:18] <mjs> well, that might not be true even currently
# [11:19] <mjs> <div> Welcome to... <h1>Web Standards Battle Explosion</h1> ... </div>
# [11:19] <Grauw> indeed
# [11:19] <mjs> that's perfectly valid HTML4
# [11:19] * Joins: anne (annevk@86.90.70.28)
# [11:19] <Grauw> besides, if there’s a use case for it, it’ll be used, even though the language won’t allow it
# [11:19] <mjs> HTML4 wouldn't associate the bit before the h1 with the heading, but that doesn't have much effect on content
# [11:20] <Grauw> not that I want to not consider screenreaders btw, but this only ‘breaks’ them in a very little way for one specific case
# [11:21] * Quits: edas (edaspet@88.191.34.123) (Quit: http://eric.daspet.name/ et l'édition 2007 de http://www.paris-web.fr/ )
# [11:21] <Grauw> p.s. did I ever tell the story that I got hired at Backbase because I posted on the WHATWG list a few years ago? :)
# [11:23] <anne> I was asked by Backbase much for the same reason
# [11:23] <Grauw> *grins*
# [11:24] * Parts: zcorpan_ (zcorpan@84.216.40.174)
# [11:24] * Quits: mjs (mjs@64.81.48.145) (Quit: then we we)
# [11:25] <anne> actually, that was the second time they asked me
# [11:26] <anne> the first time I was much younger than they expected
# [11:26] <Grauw> oh really? heh :)
# [11:26] * Quits: anne (annevk@86.90.70.28) (Connection reset by peer)
# [11:28] * Joins: mjs (mjs@64.81.48.145)
# [11:29] <Grauw> mjs: is your ‘Quit: then we we’ message intentional? It keeps puzzling me :).
# [11:29] <mjs> no, I'm not sure where it came from
# [11:30] <Grauw> looks like you accidentally typed in the quit message setting some time, or something
# [11:31] <mjs> yes probably
# [11:31] <mjs> I just cleared the setting
# [11:31] <Grauw> you should put something nice in it
# [11:40] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Get thee behind me, satan.)
# [11:48] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
# [11:49] * Joins: edas (edaspet@88.191.34.123)
# [11:51] * Joins: mjs (mjs@64.81.48.145)
# [12:04] * Quits: hasather (hasather@81.235.209.174) (Connection reset by peer)
# [12:04] * Joins: hasather (hasather@81.235.209.174)
# [12:15] * Parts: htmlr (htmlr@203.206.237.84)
# [12:18] * Joins: zcorpan_ (zcorpan@130.243.79.10)
# [12:43] * Quits: Ashe (Ashe@213.47.199.86) (Connection reset by peer)
# [12:48] * Quits: sbuluf (lgos@200.49.140.65) (Ping timeout)
# [12:57] * Joins: loic (loic@90.29.39.131)
# [12:59] * Quits: zcorpan_ (zcorpan@130.243.79.10) (Ping timeout)
# [13:10] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
# [13:32] * Quits: marcos__ (chatzilla@203.206.31.102) (Ping timeout)
# [13:36] * Joins: zcorpan_ (zcorpan@130.243.79.10)
# [13:39] * Joins: Philip (excors@80.177.163.133)
# [13:53] * Joins: olivier (ot@128.30.52.30)
# [13:53] * Quits: zcorpan_ (zcorpan@130.243.79.10) (Ping timeout)
# [13:54] * Joins: karl (karlcow@128.30.52.30)
# [14:01] * Quits: loic (loic@90.29.39.131) (Ping timeout)
# [14:02] * Joins: zcorpan_ (zcorpan@130.243.79.10)
# [14:04] * Joins: loic (loic@90.29.119.135)
# [14:12] * Joins: zcorpan (zcorpan@84.216.40.174)
# [14:13] * Quits: zcorpan_ (zcorpan@130.243.79.10) (Ping timeout)
# [14:21] * Joins: anne (annevk@86.90.70.28)
# [14:24] * Joins: marcos__ (chatzilla@203.206.31.102)
# [14:30] <anne> details is not data, is it?
# [14:30] * Quits: marcos__ (chatzilla@203.206.31.102) (Ping timeout)
# [14:30] * anne plans to make some further changes
# [14:31] <anne> also, is <meter> data or app?
# [14:32] * anne leaves it in data
# [14:37] <hsivonen> anne: meter makes sense without client-side scripts
# [14:37] <hsivonen> anne: I thought details made sense, too
# [14:37] <anne> well, <datalist> can be used with scripts too
# [14:37] <anne> without*
# [14:38] <hsivonen> perhaps datalist belogs under the other heading then
# [14:39] * anne thinks the distinction is pretty arbitrary
# [14:40] <hsivonen> well, the taxonomy is not spec-endorsed, but I think it will help newbies see what's in there better
# [14:41] * anne would expect <details> to be used in apps
# [14:41] * zcorpan would expect <details> to be used in forms
# [14:42] <anne> forms -> apps
# [14:42] * anne added a section "Global overview" which needs fixing
# [14:43] <hsivonen> the page could use an overview of the APIs
# [14:44] <zcorpan> <font> is also dropped, except for wysiwyg
# [14:44] <hsivonen> I haven't read the API sections that carefully, because outside the area that I'm working on
# [14:44] <hsivonen> because they ore
# [14:44] <hsivonen> are
# [14:44] <hsivonen> typo++
# [14:45] * Joins: Lachy (chatzilla@124.168.24.114)
# [14:46] <anne> typo's +1
# [14:46] * anne adds <font>
# [14:47] <anne> Besides APIs we need attributes and such
# [14:47] <anne> prolly way more elements need to be added to changed elements
# [14:47] <anne> and explanation of why they have changed
# [14:49] <anne> APIs, markup, sniffing, syntax, rendering
# [14:49] <anne> basically: http://www.whatwg.org/specs/web-apps/current-work/#structure
# [14:50] * anne wonders if he has CVS access to /html/wg/
# [14:52] <anne> it uses XHTML for some weird reason
# [14:58] <Lachy> hey, u discussing anything interesting?
# [14:59] <hsivonen> Lachy: making http://wiki.whatwg.org/wiki/Changes_from_HTML4 better so that non-WHATWG HTML WG participants could get an idea about HTML5 before they commit to reading the spec
# [14:59] * anne found definition list syntax!
# [15:00] <hsivonen> or without reading the spec at all if people plan on participating without reading it :-(
# [15:00] <anne> did you read it?
# [15:00] <hsivonen> anne: I've read it twice cover-to-cover (though not paying proper attention to all APIs)
# [15:01] <Lachy> There was some stuff about that here http://wiki.whatwg.org/wiki/HTML_vs._XHTML#Differences_Between_HTML_4.01_and_HTML_5
# [15:01] <hsivonen> anne: I'm now reading it through the third time and marking schema bugs at the same time
# [15:01] <hsivonen> anne: when I'm done, the bugs zcorpan pointed out will hopefully get fixed
# [15:01] <Lachy> may as well merge merge any of that stuff into the one you're creating now
# [15:01] <hsivonen> anne: I've also read random sections following cross-references
# [15:01] <hsivonen> anne: I'm yet to read it backwards
# [15:02] <anne> hsivonen, ok, fair enough
# [15:02] * anne doubts that goes for many people though
# [15:02] <anne> Lachy, it's a wiki, feel free to do so :)
# [15:03] <anne> Lachy, part of it was based on that btw
# [15:03] <Lachy> ok
# [15:04] <Lachy> are you editing it right now? I don't want any changes to conflict
# [15:04] <anne> not at the moment, no
# [15:04] <Lachy> ok, I'll copy the stuff about attributes and the meta charset over to the new doc and clean it up a little
# [15:05] <anne> I think Global Overview should be really clear and basically cover most in a couple of sentences... The rest of the page can then be pretty lengthy and exhaustive in case people need more info
# [15:12] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
# [15:15] * Lachy updated the wiki
# [15:17] * DanC wanders off to focus on other things...
# [15:17] * Parts: DanC (connolly@128.30.52.30) (Client exiting)
# [15:18] * Quits: Lachy (chatzilla@124.168.24.114) (Quit: Chatzilla 0.9.77 [Firefox 2.0.0.3/2007030919])
# [15:20] * Quits: anne (annevk@86.90.70.28) (Connection reset by peer)
# [15:49] * Quits: hasather (hasather@81.235.209.174) (Ping timeout)
# [15:55] * Joins: hRehfeld (hrehfeld@84.63.26.140)
# [15:57] * Quits: hRehfeld (hrehfeld@84.63.26.140) (Quit: hRehfeld)
# [16:10] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [16:14] * Quits: st (st@62.234.155.214) (Quit: st)
# [16:14] * Quits: edas (edaspet@88.191.34.123) (Quit: http://eric.daspet.name/ et l'édition 2007 de http://www.paris-web.fr/ )
# [16:17] * Quits: olivier (ot@128.30.52.30) (Quit: Leaving)
# [16:19] * Joins: hasather (hasather@81.235.209.174)
# [16:20] * Quits: hasather (hasather@81.235.209.174) (Client exited)
# [16:20] * Joins: hasather (hasather@81.235.209.174)
# [16:21] * Quits: hasather (hasather@81.235.209.174) (Client exited)
# [16:21] * Joins: hasather (hasather@81.235.209.174)
# [16:28] * Joins: anne (annevk@86.90.70.28)
# [16:31] * Quits: anne (annevk@86.90.70.28) (Connection reset by peer)
# [17:13] * Joins: st (st@62.234.155.214)
# [17:14] * Joins: st_ (st@62.234.155.214)
# [17:15] * Joins: anne (annevk@83.82.206.111)
# [17:16] * Quits: st (st@62.234.155.214) (Ping timeout)
# [17:23] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
# [17:36] * anne wonders if http://www.w3.org/mid/46150B3D.8030908@vectoreal.com is meant as a joke...
# [17:36] * Joins: tylerr (tylerr@66.195.32.2)
# [17:38] * gavin_ wondered that too
# [17:44] <tylerr> G'day all.
# [17:44] <anne> good afternoon
# [17:44] <tylerr> Hey hey anne
# [17:50] * Joins: asbjornu (asbjorn@84.48.116.134)
# [17:55] <anne> "proprietary standards
# [17:55] <anne> "
# [17:56] <anne> Doug is getting funnier every e-mail
# [17:58] <anne> I have updated http://wiki.whatwg.org/wiki/Changes_from_HTML4 a bit more.
# [17:59] * anne goes to add APIs
# [18:01] * Joins: h3h (bfults@66.162.32.234)
# [18:04] <anne> http://wiki.whatwg.org/wiki/Changes_from_HTML4#APIs
# [18:07] <anne> comments welcome
# [18:07] <anne> better would be to directly update the wiki yourself, of course ;)
# [18:07] <zcorpan> links to the spec might be useful
# [18:08] <ROBOd> zcorpan: i was just reading the article right now and that's the comment i wanted to make
# [18:08] <ROBOd> anne: add the links to each new element section in the spec
# [18:09] <ROBOd> also it would be nice if the new elements would have a short description
# [18:10] <zcorpan> "HTML5 also integrates DOM Level 2 HTML" ...should perhaps say "the successor of ..." or something?
# [18:10] <zcorpan> since dom2 html will be obsolete
# [18:18] * Joins: mjs (mjs@17.255.97.110)
# [18:50] * Quits: Grauw (ask@202.71.92.74) (Quit: New: RHTML, HTML expressed in RDF. No longer are you limited to tree-based structures!)
# [18:58] * Joins: kingryan (kingryan@66.92.187.33)
# [19:02] <zcorpan> is anyone editing that wiki page atm?
# [19:03] * zcorpan takes that as a no and goes ahead to add links
# [19:04] <mjs> which wiki page?
# [19:04] <zcorpan> http://wiki.whatwg.org/wiki/Changes_from_HTML4
# [19:04] <mjs> oh cool
# [19:06] * Quits: st_ (st@62.234.155.214) (Quit: st_)
# [19:08] <zcorpan> "These syntax rules are compatible with the XHTML syntax rules" ...sounds like the HTML5 syntax is always compatible with XHTML syntax. suggestions of how to make it clearer that that is not the case?
# [19:09] <zcorpan> "HTML5 documents can be written in a way that looks exactly like XHTML"?
# [19:10] * Joins: st (st@62.234.155.214)
# [19:13] <mjs> HTML5 has a lot of minor added APIs too, like getElementsByClass and classList
# [19:13] <mjs> dunno if those are worth mentioning
# [19:13] <mjs> I will resist the urge to edit that page for now
# [19:14] <zcorpan> i'll say when i'm done :)
# [19:32] <tylerr> :-)
# [19:33] <anne> thanks zcorpan!
# [19:33] * anne was having food and also playing with his new Wii
# [19:34] <hasather> anne: got any nice games?
# [19:35] <anne> I got Zelda
# [19:35] <anne> and Wii Play with a controller I fetched today
# [19:35] <hasather> got those too, Zelda rocks
# [19:36] <anne> I thought Wii Sports was part of Wii Play but it isn't... so I'll probably get that tomorrow or this weekend
# [19:36] <hasather> Wii Sports is supposed to be included, isn't it anymore?
# [19:36] <hasather> weird
# [19:37] <hasather> included with the consolde I mean
# [19:38] <tylerr> anne: Wii Sports comes with the Wii.
# [19:38] <tylerr> Or did you get the Wii via eBay?
# [19:39] <zcorpan> updated
# [20:09] * Quits: mjs (mjs@17.255.97.110) (Quit: mjs)
# [20:25] <anne> maybe we should use the permalinks without the "the-" prefix
# [20:27] <anne> looks nice though
# [20:28] * Joins: edas (edaspet@88.191.34.123)
# [20:29] <zcorpan> at least be consistent...
# [20:29] <anne> I don't trust the HTML5 permalinks one bit
# [20:29] <anne> It's one of the more annoying things about the document
# [20:30] <kingryan> anne: are you talking about fragment identifiers in the spec?
# [20:30] <anne> yes, they are autogenerated
# [20:30] <kingryan> ah yeys
# [20:30] <kingryan> yes*
# [20:31] <kingryan> we have the same problem with the microformats wiki
# [20:31] <zcorpan> some of them are
# [20:31] <zcorpan> others are hardcoded
# [20:31] <kingryan> anytime someone changes header text, fragment identifiers break
# [20:31] <anne> most are autogenerated
# [20:31] <kingryan> it'd be nice if there were some mechanism for either (1) redirecting frag id's or (2) applying multiple frag id's to the same fragment
# [20:32] <zcorpan> id="foo" xml:id="bar" ... :)
# [20:33] <kingryan> <div id="foo"><a name="bar"></a></div>
# [20:33] <kingryan> ;)
# [20:33] <anne> there are about 1200 definitions in the WHATWG specification... no way Hixie is going to add IDs to all of them
# [20:33] <Philip> <a name="foo" id="bar"></a>
# [20:33] <anne> would be nice though
# [20:33] <zcorpan> he doesn't have to do it manually
# [20:34] <zcorpan> so long as they are consistent and permanent i'm happy
# [20:34] <kingryan> change is fine if there's a way to track the change
# [20:34] <zcorpan> ok, so long as they are consistent i'm happy
# [20:40] <Philip> Is there some explanation of what the "[SCS]" in some section headings means?
# [20:41] <anne> standalone section or something
# [20:41] <Philip> (I can see [TBW] and [WIP] too, but I can guess what they are, though maybe it'd be nice if the spec explained them too)
# [20:41] <anne> they are added by a script iirc
# [20:41] <zcorpan> self-contained section
# [20:41] <zcorpan> i think
# [20:41] <anne> right, what zcorpan said
# [20:41] <Philip> Ah, makes sense
# [20:42] <anne> hmm, I suppose area had at least rev too
# [20:42] * anne checks HTML4
# [20:43] <anne> apparently not :s
# [20:43] <zcorpan> i guess the script could insert <abbr title> to them, or insert a paragraph explaining them to the Stability section
# [20:44] <anne> http://www.w3.org/TR/html401/struct/objects.html#edef-AREA also has no "target"
# [20:44] * anne wonders if he's missing something
# [20:45] <zcorpan> you're surprised?
# [20:46] <anne> oh
# [20:46] <anne> that's prolly defined somewhere else
# [20:46] <anne> right
# [20:47] <zcorpan> where?
# [20:47] <anne> http://www.w3.org/TR/html401/present/frames.html#adef-target (pointer is at the end of the above link its section)
# [20:48] <zcorpan> ah
# [20:49] <zcorpan> the nohref attribute i don't get
# [20:49] <zcorpan> what's the use of it?
# [20:49] <anne> maybe because href was defined somewhere else?
# [20:51] <zcorpan> surely not specifying href is enough to say that the "region has no associated link"?
# [20:51] <anne> well, we fixed it
# [20:51] <zcorpan> i know
# [20:51] <zcorpan> still leaves me pondering
# [20:51] <zcorpan> why it was included in the first place
# [20:52] <anne> DanC or some other "old timer" might know
# [20:54] <zcorpan> ie supports disabled="" on any element (although it doesn't disable links)
# [20:55] <anne> yeah, I know
# [20:55] <zcorpan> are there use-cases for that?
# [20:55] <anne> contenteditable and disabled
# [20:55] <anne> maybe
# [20:56] <zcorpan> i've seen a table with disabled rows where each row represented a task, and the disabled rows were planned tasks in the future
# [20:59] * Joins: kingryan_ (kingryan@66.92.187.33)
# [21:01] * Quits: kingryan (kingryan@66.92.187.33) (Ping timeout)
# [21:06] * Joins: dbaron (dbaron@63.245.220.242)
# [21:35] * Quits: kingryan_ (kingryan@66.92.187.33) (Quit: kingryan_)
# [21:56] * Quits: hasather (hasather@81.235.209.174) (Client exited)
# [21:56] * Joins: hasather (hasather@81.235.209.174)
# [22:08] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
# [22:08] * Joins: kingryan (kingryan@66.92.187.33)
# [22:08] * Quits: kingryan (kingryan@66.92.187.33) (Quit: kingryan)
# [22:26] * Joins: kingryan (kingryan@66.92.187.33)
# [22:30] * Quits: heycam (cam@203.214.79.176) (Ping timeout)
# [22:45] * Quits: edas (edaspet@88.191.34.123) (Quit: http://eric.daspet.name/ et l'édition 2007 de http://www.paris-web.fr/ )
# [22:47] * Joins: heycam (cam@203.214.79.176)
# [22:51] * Quits: anne (annevk@83.82.206.111) (Ping timeout)
# [23:44] * Quits: loic (loic@90.29.119.135) (Quit: hoopa rules)
# [23:49] * Joins: mjs (mjs@17.255.104.119)
# [23:52] * Hixie reads "the XHTML 2 role-attribute is far superior to the Web Applications 1.0 predefined class names" and wonders why the two would be compared
# Session Close: Fri Apr 06 00:00:00 2007

The end :)