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

Options:

# Session Start: Fri May 11 00:00:00 2007
# Session Ident: #html-wg
# [00:01] * Joins: Zeros (Zeros-Elip@67.154.87.254)
# [00:25] * Quits: Sander (svl@71.57.109.108) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [00:29] * Quits: olivier (ot@128.30.52.30) (Quit: Leaving)
# [00:54] * Joins: mjs (mjs@17.255.105.149)
# [00:57] * Quits: laplink (link@212.33.131.105) (Quit: Leaving)
# [01:00] * Joins: laplink (link@212.33.131.105)
# [01:02] * Quits: schepers (schepers@72.29.239.177) (Quit: Free at last!)
# [01:08] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [01:12] <cying> hmmm, i feel neglected, no one commented on my chained classnames
# [01:12] <cying> i was sure someone might comment
# [01:13] * Joins: gavin_ (gavin@74.103.208.221)
# [01:13] <MikeSmith> post a message on <i> vs <em> ... you'll get lots of replies
# [01:14] <MikeSmith> I promise to post a +1 reply if you do
# [01:15] <cying> haha
# [01:15] <zcorpan_> cying: pointer?
# [01:16] <cying> zcorpan_: http://lists.w3.org/Archives/Public/public-html/2007May/0929.html
# [01:16] <Zeros> cying, support doesn't exist in IE6 though
# [01:17] <Zeros> Is IE7's rule parser fixed for that?
# [01:17] <cying> Zeros: oh @#%@#!#%!%@%
# [01:17] <Zeros> cying, IE6 sees .foo.bar.baz {} as if it was .baz {}
# [01:17] <Zeros> So it'd work, sort of. It'd just have unexpected behavior if you also had a .copyright elsewhere
# [01:18] <cying> ahhh
# [01:18] <Zeros> Personally I think role (or some such attribute) makes much more sense than class
# [01:19] * Quits: tH (r@87.102.22.235) (Quit: ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508])
# [01:19] <Zeros> There's no chance for collision that way, and we can make real claims on conformance. There's no way we can make a statement like "copyright is only allowed on foo element" in HTML5, it'd invalidate lots of existing content
# [01:19] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Get thee behind me, satan.)
# [01:19] <cying> ahhh
# [01:20] <Zeros> Of course IE6 doesn't actually support [role=foo] either, so we don't gain anything on that front, heh.
# [01:20] <hasather> Zeros: yea, multiple classes are supported in IE7
# [01:20] <cying> oh cool!
# [01:21] * Joins: sbuluf (rx@200.49.140.40)
# [01:21] <zcorpan_> i don't see the use in having copyright being a predefined class name. what is there that browsers/markup consumers can do with it?
# [01:22] <Zeros> we need a <copyright>
# [01:22] <zcorpan_> Zeros: why?
# [01:22] <jdandrea> I used it as a style hook (even with a former big-shot telco employer) but that's about it.
# [01:22] <jdandrea> :)
# [01:22] <Zeros> zcorpan_, because it's a very common feature of pages
# [01:22] <Zeros> Most pages have a copyright
# [01:23] <sbuluf> what's so wrong about role?
# [01:23] <Zeros> zcorpan_, why have <p> ?
# [01:23] * Quits: billmason (billmason@69.30.57.156) (Connection reset by peer)
# [01:23] <sbuluf> <Zeros> zcorpan_, why have <p> ? <--in this wg, because of back compat. if we are talking about a hipotetically good content authoring language, we shouldn't
# [01:24] <zcorpan_> Zeros: because it's useful for browsers and markup consumers to know where text is split up in paragraphs
# [01:24] <Zeros> zcorpan_, and it's also useful to know what the meaning of different parts of the page
# [01:24] <zcorpan_> Zeros: i don't see how a UA knowing that a piece of text is a copyright statement is useful for the UA
# [01:25] <Zeros> Screen readers could skip it, parsers could parse it out when scraping
# [01:25] <zcorpan_> Zeros: it depends on whether there is something useful you can do with the knowledge
# [01:25] <jdandrea> Mmm. Where to draw the line. There should be a good litmus test for this sort of thing - when to prefer divining a new element vs. attribute vs. metadata.
# [01:25] <jdandrea> Use cases then.
# [01:25] <Zeros> jdandrea, the use cases are all over the web
# [01:25] <Zeros> damn near every page has a copyright
# [01:26] <Zeros> Lots of people use class="copyright"
# [01:26] <Zeros> or some such variant for adding it to the footer
# [01:26] <zcorpan_> copyrights being common does not imply that there is a use-case for UAs knowing what is a copyright statement
# [01:26] <Zeros> That doesn't make sense
# [01:26] <Philip`> That's just a use case for class="copyright" and CSS - why will content producers and consumers want something more than that?
# [01:26] <Zeros> zcorpan_, you're stuck in the browser world
# [01:26] <jdandrea> Is there dublin core metadata for copyright?
# [01:27] <Zeros> there's lots of UAs that are *not* browsers zcorpan_
# [01:27] <zcorpan_> Zeros: um, yeah, i know
# [01:27] <hsivonen> Zeros: do you have non-browser consumer use cases for knowing what pieces of text are copyright notices?
# [01:27] <Zeros> Screen readers could skip copyrights unless the person really cared, most people put a date in the copyright and parsers could pull that out
# [01:27] <jdandrea> Hmm. http://dublincore.org/documents/dcmi-terms/#H2 (dateCopyrighted)
# [01:28] <Zeros> zcorpan_, what about feeds? Or books (those have copyrights) on amazon?
# [01:28] <Zeros> hsivonen, What browser lets you do getElementByContentInSomeRandomNode ?
# [01:28] <hsivonen> Zeros: I don't understand you question
# [01:29] <hsivonen> Zeros: ooh. now I get it
# [01:29] <Zeros> hsivonen, or styling, or parsing? What about a node that has a random © in it that isn't a copyright such as one that talks about it?
# [01:29] <hsivonen> Zeros: you just said you were talking about non-browsers
# [01:29] <Zeros> You can't use a heuristic like that.
# [01:29] <zcorpan_> Zeros: the use-case you have given is that screen readers can identify copyright statements and don't reveal them to the reader. i don't understand why this is wanted
# [01:29] <Zeros> hsivonen, Screen readers use the DOM too though, lots of things use it that aren't really browsers
# [01:29] <Philip`> Would screen readers find it better to have irrelevant material identified as copyright, or would it better to use <article> and <footer> and <nav> so they can jump to the relevant parts and ignore the rest?
# [01:30] <Zeros> zcorpan_, Because it's not really meaningful to read it over and over?
# [01:30] <Philip`> s/irrelevant material/copyright material which is irrelevant to the users of screen readers most of the time/
# [01:30] <Zeros> Books have copyrights as well, so Amazon could use it
# [01:30] <zcorpan_> Zeros: screen readers can skip a paragraph at the user's will
# [01:30] <hsivonen> Zeros: why shouldn't aural users be made aware of copyright provenance if the author thinks it is worth mentioning it to visual users?
# [01:30] <Zeros> zcorpan_, Then why again are we using <nav> ?
# [01:30] <Zeros> or menu?
# [01:30] <Zeros> those have no use cases either, we already have ul
# [01:30] <zcorpan_> Zeros: besides, there is <header> and <footer>
# [01:31] <Zeros> zcorpan_, <footer> doesn't imply anything, it's a general container
# [01:31] <Zeros> that's like arguing we don't need <p> because we have <div>
# [01:31] <zcorpan_> Zeros: it's the kind of content that you're likely to skip if you're on a screen reader
# [01:31] <Zeros> What is the harm is having a copyright?
# [01:32] <zcorpan_> i'm not saying there's any harm, i'm saying i don't see the use-case of defining the class name
# [01:32] <Zeros> You all seem very against adding any element that adds meaning to the page, but come time to talk about adding some kind of new form control and you're all for it
# [01:32] <zcorpan_> Zeros: what?
# [01:33] <Philip`> As far as I can see, the problem is with adding "meaning" when there aren't good reasons why people would make use of that added meaning, to justify the cost of specifying/implementing/testing/learning/etc a new feature
# [01:33] <Zeros> zcorpan_, A huge portion of HTML5 and web forms goes into adding new "application" features
# [01:33] <Zeros> Not adding better meaning
# [01:33] <zcorpan_> i don't think it's a good idea to add some kind of new form control if there's no real use-case for it
# [01:34] <Zeros> zcorpan_, there's lots of use cases for copyright, I've already presented them, you shot them all down with "well you can do it another way"
# [01:34] <Zeros> and the same is true of the new form controls
# [01:34] <zcorpan_> Zeros: i could extract one use-case (screen readers could skip copyrights)
# [01:34] <zcorpan_> please point out the others i missed
# [01:35] <Zeros> zcorpan_, spiders could show them separately on the search results, or any kind of parser could utilize that information.
# [01:35] <zcorpan_> ok, thanks
# [01:36] <zcorpan_> come to think of it, google code search shows copyright along with code snippets
# [01:37] <hsivonen> zcorpan_: and did they need markup for it? :-)
# [01:37] <zcorpan_> although code usually simply have their copyright statments in comments
# [01:37] <zcorpan_> hsivonen: no
# [01:37] <Zeros> hsivonen, you don't really /need/ markup for any of this though
# [01:37] <jdandrea> Metadata.
# [01:37] <jdandrea> When I think copyright I keep thinking metadata.
# [01:37] <Zeros> The visible copyright notice on the page is far more reliable than the meta tag anyway
# [01:37] <Philip`> Do screen readers currently attempt to use some heuristic methods to skip parts of pages? If so, I think those would be good examples of use cases that people clearly want and that could be improved by better language support. I've no idea how to find that out, though
# [01:37] <Zeros> That's true of all metadata, meta in general is crap since it's hidden
# [01:38] <jdandrea> But ... it's not intended to be rendered. It's data about data. (?)
# [01:38] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Quit: Leaving)
# [01:38] <zcorpan_> it seems like a heuturistics is a more accurate way to extract what is a copyright statement for consumers given the current web, and that would possibly include looking at class=copyright
# [01:38] * Joins: Zeros (Zeros-Elip@67.154.87.254)
# [01:38] <jdandrea> You can certainly cover a lot of ground that way.
# [01:39] <Zeros> zcorpan_, similarly an <email> element would be very useful.
# [01:39] <sbuluf> <haiku>
# [01:39] <sbuluf> <employee>
# [01:39] <Zeros> More meaningful elements need to be added to HTML.
# [01:39] <sbuluf> <car>
# [01:39] <Zeros> sbuluf, that's silly, and you know it. Stop with the straw man.
# [01:39] <zcorpan_> Zeros: doesn't <a href=mailto:> imply email?
# [01:40] <Zeros> zcorpan_, how often is the mailto not used to prevent spam? how often is some kind of encryption used?
# [01:40] <Philip`> http://www.google.com/support/bin/answer.py?answer=29508 seems useful copyright use, with <link rel=license>, which probably is enough to handle the metadata cases already for search engines to use
# [01:40] <zcorpan_> Zeros: um, what would your <email> element be good for?
# [01:40] <Zeros> Philip`, I don't know about that
# [01:41] <Zeros> zcorpan_, Any email being presented on a web page, a directory, a mail client, a search page
# [01:41] <Philip`> zcorpan_: The spec could say that user agents MUST NOT use the addresses contained in <email> tags to send spam
# [01:41] <zcorpan_> Zeros: wouldn't spam bots pick that up the same way they have picked up mailto:?
# [01:41] <Zeros> zcorpan_, Why do you think microformats exist? Because HTML is *deficient* in implying email.
# [01:41] <Zeros> err meaning
# [01:41] <Zeros> zcorpan_, Possibly
# [01:42] <Zeros> zcorpan_, Again, why are you so against adding meaningful elements?
# [01:42] <zcorpan_> Zeros: i'm not
# [01:42] <beowulf> is there a microformat for email?
# [01:42] <Zeros> These /have/ use cases
# [01:42] <zcorpan_> Zeros: i'm asking for use-cases
# [01:42] <Zeros> They're visible on pages everywhere
# [01:42] <Zeros> zcorpan_, what's the use case for footer?
# [01:43] <zcorpan_> Zeros: not sure
# [01:43] <Philip`> Is <email> meant to be used with obfuscated/encrypted email addresses that only a human can convert into a real address?
# [01:43] <zcorpan_> Zeros: i can see clear use-cases for <article> and <nav> and <header>
# [01:43] <Zeros> zcorpan_, what's the usecase for header?
# [01:43] <beowulf> oh, duh, of course there is
# [01:44] <zcorpan_> Zeros: sub-headings not being part of the document outline
# [01:44] * Joins: ddailey (david_dail@24.144.172.117)
# [01:44] <Zeros> zcorpan_, And who is that useful to?
# [01:44] <Zeros> What screen reader or search engine uses that?
# [01:44] <zcorpan_> <header><h1>foo</h1><h2>bar</h2></header> as opposed <h1>foo</h1><h2>bar</h2>
# [01:45] <beowulf> use case for <header> and <footer> might be to read the data once for each page in a group of pages?
# [01:45] <zcorpan_> Zeros: screen readers can navigate between sections and create a document outline, i think
# [01:45] <Zeros> beowulf, We can use zcorpan_'s argument too, why not just use a class or an id?
# [01:45] <sbuluf> would someone inform me if this discussion is limited to the existing web and what this WG is supposed to do, or if it is off topic, and about what a good content authoring language should be like?
# [01:45] <Zeros> Or why not just use the heuristic that any two headers that come right after the other should be considered combined like that?
# [01:46] <Zeros> I don't see what's wrong with adding elements for common parts of pages on the web
# [01:46] <Zeros> Microformats are designed to add meaning, what's the resistance to doing the same with HTML?
# [01:46] <zcorpan_> Zeros: a heading following another heading doesn't always imply sub-heading
# [01:47] <zcorpan_> right
# [01:47] * Parts: hasather (hasather@81.235.209.174)
# [01:47] <ddailey> The discussion of copyright made me think of a couple of years ago -- I was writing an e-mail about copyright law. I concluded with three points (a), (b) and (c). My word processor automatically converted (c) to the copyright symbol for me. I figured the software was precognizant. http://srufaculty.sru.edu/david.dailey/copyright/uncopyrightable.htm
# [01:47] <Zeros> heh
# [01:48] <Philip`> One problem with adding elements is that it doesn't degrade gracefully, since you can't style unrecognised elements in IE6/7, so authors won't really want to use them
# [01:48] <Zeros> Philip`, that's true for header, or footer, or anything then
# [01:48] <Zeros> How is this different?
# [01:48] <zcorpan_> Philip`: yeah, that's a problem
# [01:48] <jdandrea> Light Reading: http://ln.hixie.ch/?start=1129948617&count=1
# [01:48] <sbuluf> thank you very much.
# [01:48] <zcorpan_> Zeros: it isn't different
# [01:49] <jdandrea> Search for "I think one of the biggest problems at the W3C is that groups feel that to show progress they must release specifications with new features, instead of trying their best to not release anything unless it is absolutely necessary. ...
# [01:49] <jdandrea> ... Tantek's got it right with his whole microformats thing. The best microformat is the one that doesn't introduce anything new at all, it just defines more specifically the semantics of existing elements."
# [01:49] <Zeros> jdandrea, Eh, I don't know about that.
# [01:49] <Zeros> The debate about role is hilarious too
# [01:50] <Zeros> The comment that the role attribute allows namespaced roles really took the cake.
# [01:50] <beowulf> a lot of the debates show that people want very different things, and think they can get them from the same wg
# [01:50] <Zeros> We're reinventing HTML in the form of attributes!
# [01:50] <Philip`> It's a problem for all the new structural elements, so that kind of problem (plus the cost of adding the feature) has to be balanced against the value, which I think is what's wrong with "adding elements for common parts of pages on the web" when people aren't convinced the cost/value balance is in the right direction
# [01:50] <beowulf> which is maybe worrying
# [01:51] <Zeros> Philip`, there's no cost, the value is apparent.
# [01:52] <Philip`> Someone has to write the spec for the new feature, dozens of people have to implement it, other people have to write test cases, authors have to learn about it and understand how to use it correctly and make use of it
# [01:52] <Philip`> Even if it's something very simple like just a new tag that's parsed the same as <div>, there still is a cost to adding it
# [01:52] <Zeros> Of course
# [01:53] <Zeros> The same as any other element we add
# [01:53] <zcorpan_> Zeros: yes, it's the same as any other element we add
# [01:53] <Philip`> so I think I disagree with "there's no cost"
# [01:53] <Zeros> zcorpan_, what's the usecase for time?
# [01:53] <Zeros> HTML5 adds that
# [01:54] <Zeros> Or meter?
# [01:54] <Zeros> What's the use of that to a screen reader or a search engine or anyone?
# [01:54] <Hixie> the use case for <meter> is giving people a chance not to abuse <progress>
# [01:54] <zcorpan_> Zeros: hmm, being able to disambuigate dates/times. apparently there is a need for that, cf microformats <abbr title> for the same thing
# [01:55] <jdandrea> WRT time: "The primary use cases for these elements are for marking up publication dates e.g. in blog entries, and for marking event dates in hCalendar markup. Thus the DOM APIs are likely to be used as ways to generate interactive calendar widgets or some such."
# [01:55] <Hixie> (if we just introduced <progress>, people would abuse it, since there's no other way to give a nice meter)
# [01:55] <Zeros> zcorpan_, I don't see know needing to disambiguate that and email is different
# [01:55] <Hixie> <time> i'm less convinced about
# [01:55] <Philip`> About <time>, it says "The primary use cases for these elements are for marking up publication dates e.g. in blog entries, and for marking event dates in hCalendar markup"
# [01:55] <Hixie> but it seems there's a lot of people writing times who stick spans around them
# [01:55] <Philip`> Oops
# [01:55] <Hixie> so...
# [01:55] <jdandrea> np. :)
# [01:56] <zcorpan_> Zeros: it isn't, it's just that there already is a way to disambiguate email, we don't need more ways to do the same
# [01:56] <Zeros> Hixie, And there's a lot of people writing copyrights who stick an element around them
# [01:56] <Zeros> The same is true of email.
# [01:57] <Hixie> Zeros: yeah, hence class=copyright
# [01:57] <Zeros> zcorpan_, HTML doesn't define that though
# [01:57] <Philip`> Does <time> have advantages over using whatever microformats do for times?
# [01:57] <Hixie> Zeros: e-mail addresses can be done using <a href="mailto:"></a>
# [01:57] <zcorpan_> Zeros: no, the mailto: protocol defines it
# [01:57] <Zeros> zcorpan_, I'm not sure how you can argue that using a heuristic on a link is a good way to do that. Should people use <a href="mailto:"> if they don't want it to be a link?
# [01:57] <Hixie> Philip`: microformats (ab)use <abbr> for times
# [01:58] <Zeros> Hixie, and if it's not supposed to be a link?
# [01:58] <Zeros> Hixie, Or what if we want to select it from the DOM?
# [01:58] <Hixie> Zeros: why would you not want it to be a link?
# [01:58] <zcorpan_> Zeros: probably not, then they should simply use the email as text not in an element
# [01:58] <Hixie> to select it from the dom, use .href or similar
# [01:58] <Zeros> So we need a getElementsByContentInSomeRandomAttribute()
# [01:58] <Zeros> Hixie, That implies searching every a in the entire document yourself
# [01:59] <Hixie> Zeros: i'm not sure i understand your use case
# [01:59] <zcorpan_> Zeros: it should be pretty easy to find what is an email address even without <email>. ask your nearest spam bot
# [01:59] <Zeros> Hixie, It adds extra meaning to the page. Both screen readers, search engines and any kind of consumer can use it.
# [02:00] <Zeros> zcorpan_, They're not trying to consume the document as a document though, they're parsing it as a giant text file.
# [02:00] <Philip`> Ah, I guess that abuse of <abbr> is a problem for screen readers if they try reading out the expanded format, and maybe the title tooltip is an undesired side-effect, and there's not any other convenient elements you could hang an alternate version of the date off of, hence the value of <time>
# [02:00] <Hixie> Zeros: that's not a use case
# [02:00] <Zeros> Hixie, I'm not sure what you mean? What's the usecase for footer?
# [02:01] <Hixie> Zeros: a use case is something like "i want it to be possible for people to click on a link and open a mail program with my address filled in"
# [02:01] <Hixie> Zeros: the use case for <footer> is stylistic, mostly -- class="footer" is one of the most used class names
# [02:01] <Hixie> (according to my multi-billion document surveys, anyway)
# [02:02] <Philip`> If it's just stylistic, that doesn't sound much like a use case that isn't already satisfied by 'class'
# [02:02] <Zeros> yes
# [02:02] <sbuluf> hixie, slightly unrelated: how many <blink>s in those documents?
# [02:02] <Hixie> Philip`: indeed
# [02:02] <jdandrea> As currently defined, the footer "typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like." So in a sense there's a place reserved for the copyright, no?
# [02:02] <Hixie> Philip`: but <div class="footer"> isn't as neat as <footer>
# [02:02] <Hixie> Philip`: "pave the cowpaths" and so on
# [02:02] <Zeros> Fighting against copyright when footer is there for stylistic reasons doesn't make sense hixie
# [02:02] * Hixie isn't fighting against copyright
# [02:03] <beowulf> but you could possibly add to that use case that a <header> and <footer> can be ignored by a screen reader on the 2, 3, 4 ... pages with those tags at a url ?
# [02:03] * zcorpan_ isn't either
# [02:03] * zcorpan_ is asking for use-cases
# [02:03] <Zeros> zcorpan_, the same as footer then
# [02:03] * Quits: marcos (chatzilla@131.181.148.226) (Ping timeout)
# [02:03] <zcorpan_> Zeros: ok, thanks
# [02:03] <Philip`> sbuluf: I saw <blink> in something like half a percent of some very small statistically-insignificant nonrandom sample of pages
# [02:03] <Hixie> i've already added class=copyright as a magic value to the spec. i'm not sure what an element would do, because it seems like there are multiple elements that might make sense for a copyright -- small, p, footer, address, span, a...
# [02:03] <sbuluf> ohillip, your page collection is biased, and relatively small, right?
# [02:04] <Hixie> sbuluf: quite a few, but not in the top 10
# [02:04] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Quit: Leaving)
# [02:04] <Hixie> sbuluf: more than many actual valid html elements
# [02:04] * Joins: Zeros (Zeros-Elip@67.154.87.254)
# [02:04] <Zeros> Hixie, I'm not sure predefined class names are a good idea, we can't enforce them
# [02:04] <sbuluf> hixie, if html5 has to document the web, what's the rationale for not including it then?
# [02:04] <Hixie> Zeros: we can't enforce anything
# [02:04] <Zeros> They also smell of reinventing HTML in the form of attributes
# [02:05] <Zeros> We could have class="paragraph"
# [02:05] <Philip`> I don't think I see why footers need <footer> while copyrights just need <div class="copyright">, when the use cases seem the same for both... Is it just some arbitary cutoff point of popularity?
# [02:05] <Hixie> sbuluf: <blink> will be defined in due course (in the rendering section), along with all the other oft-used presentational elements
# [02:05] <Philip`> sbuluf: It is both
# [02:05] <Hixie> Philip`: the point is that footers are always block-level
# [02:05] <Zeros> Hixie, You're defining what a conforming document is. How can you define that a class (that may already be in use in a lot of places) is only allowed on X elements in a conforming document?
# [02:05] <sbuluf> hixie, oh thanks, i thought i saw people saying it would not be included
# [02:06] <Hixie> Philip`: whereas copyrights are put all over the place -- inline, in blocks, in aside blocks, in multi-paragrph blocks, in links, etc
# [02:06] <sbuluf> philip, thanks, nonetheless. hixie's docs are way bigger and more general.
# [02:06] <Zeros> Hixie, A definition may be lots of different things as well, why do we need dfn instead of class="definition" ?
# [02:06] <Hixie> Philip`: so it isn't clear how to define a single element for copyrights
# [02:06] <Hixie> Philip`: see the code.google.com/webstats survey -- i mention copyright there as being one of the things i don't know how to handle
# [02:07] <Hixie> Zeros: the class="" thing is still very much in the air
# [02:07] <Hixie> Zeros: i'm not sure really what we should do with it
# [02:07] <Hixie> Zeros: i'm thinking we should drop it, maybe, or change the way it's defined, not sure
# [02:07] <zcorpan_> Zeros: <dfn> is for a defining *term*, not for the definition, and we're not adding <dfn> it has been in html since 1992
# [02:07] <Philip`> sbuluf: There's a point at which larger samples are meaningless because you can work out the statistical error for any sample size and be happy if that error is small enough and then not bother looking at more data :-)
# [02:07] <Hixie> Zeros: <dfn> was in HTML4, i didn't add it :-)
# [02:07] <Zeros> zcorpan_, <copyright> is for marking up a *copyright*
# [02:07] <ddailey> Hixie: the data you are talking about and http://code.google.com/webstats/ are one and the same? I have been curious about that.
# [02:07] <Zeros> Hixie, It was an example and you got the point. :)
# [02:08] <zcorpan_> Zeros: <copyright> wasn't present in previous versions of html
# [02:08] <Hixie> Zeros: i don't know that <dfn> should be an inline element necessarily, though it makes more sense since a term is always a short piece of text
# [02:08] <Zeros> zcorpan_, And neither was output, but it requires it's own element, and so does time or whatever
# [02:08] <Hixie> Zeros: certainly a term is more likely to be inline than a copyright is
# [02:09] <Hixie> ddailey: the stats on that site are one set of stats, yeah. i've seen done much bigger surveys to address other aspects of the language design
# [02:09] <Zeros> Hixie, I'm very against adding predefined class names. Elements make much more sense to me. The whole namespaced role attribute is a huge failing point in my opinion. It's very visible as an Inner platform effect problem to me.
# [02:09] <zcorpan_> Zeros: you keep mentioning that new elements have been included. you think use-cases weren't analysed for each and every new feature that was added before it was added?
# [02:09] <ddailey> thanks
# [02:10] <Hixie> Zeros: our opinions aren't really relevant, it's the use cases, technical arguments, and experience that matters
# [02:10] <Zeros> zcorpan_, I think the use cases for them are not more important than the use cases for copyright or email or date though
# [02:10] <Hixie> anyway, i have work to do :-)
# [02:10] <Hixie> bbiab
# [02:10] <zcorpan_> Zeros: that might well be the case
# [02:10] <Zeros> zcorpan_, Would be be against a <date> ?
# [02:10] <Zeros> you*
# [02:11] <zcorpan_> yes, there is <time> for that already. :)
# [02:12] <Zeros> Eh, there's already a <ul> for <menu> though, one is just more specific. :)
# [02:12] <Zeros> Not all dates involve time and vice versa
# [02:12] <zcorpan_> <time> can contain either date or time, or both
# [02:12] <ddailey> the dates which do not involve time grow on date trees?
# [02:13] <zcorpan_> Zeros: <menu> is for context menus and menu toolbars, mostly
# [02:13] <Zeros> zcorpan_, I'm not sure that's a valid argument against date though. How do you know (as a person writing code) the difference between those kinds of dates?
# [02:13] <Zeros> You parse out each and every one to search for them?
# [02:14] <zcorpan_> Zeros: i don't understand the question
# [02:14] <Zeros> zcorpan_, How do you differentiate between date and time <time> elements?
# [02:14] <zcorpan_> Zeros: oh. that's defined in the spec
# [02:14] <Zeros> zcorpan_, Right, there's an attribute, now is there a getElementsBySomeRandomAttribute() ?
# [02:15] <Zeros> There's your use case right there. I want to be able to get all the dates in a document without getting every single date and time and scanning each one.
# [02:15] <ddailey> I see tags like <date>, <time> <address> <location> <latitude> <copyright> <author> and I think of real world inference and automated reasoning
# [02:16] <ddailey> Two <date> s are elements on a time continuum that motivates inference about before and after
# [02:16] <zcorpan_> Zeros: so you want <time> to be split up to two elements because you don't want to process times when looking for dates?
# [02:17] <Zeros> zcorpan_, I want them to be split up because they are different in meaning, but you don't want to hear that, you want use cases that about about applications.
# [02:17] <Zeros> are about*
# [02:17] <Philip`> Zeros: What's wrong with using getElementsByTagName('time') and then filtering the list?
# [02:17] <zcorpan_> Zeros: i don't see them being very different, though
# [02:18] <Philip`> (You can just check the .date or .time DOM attribute to see what it's got)
# [02:18] <Zeros> Philip`, That's a lot of parsing to do something that should be simple
# [02:18] <Zeros> well, processing, parsing is a bad word
# [02:19] <zcorpan_> ok, so you want <time> to be split up in two elements because processing both date and time when you only want to look for dates is too much processing?
# [02:19] <Philip`> You don't have to do parsing - just getElementsByTagName('time').filter(function(x){x.date!==null})
# [02:20] <zcorpan_> you think you will notice a difference in processing time?
# [02:20] <Philip`> (Er, can you do filter on that kind of list? It'd be something similar anyway)
# [02:20] <Zeros> zcorpan_, I want them to be split up because they're different in meaning, but that's not a valid use case to you guys. :)
# [02:20] <Hixie> Zeros: if you have <time> and <date>, how do you distinguish between a time with a timezone and a time without?
# [02:21] <Zeros> Hixie, An attribute. Both are times.
# [02:21] <Zeros> Hixie, A time may occur on any date, and date has no implicit time.
# [02:21] <Hixie> Zeros: if you have <time> and <date>, how do you distinguish between a date indicating a year and a date indicating a month?
# [02:21] <Hixie> the distinction between times and dates is artificial
# [02:21] <Zeros> Hixie, Both are dates, there's no implicit difference there
# [02:22] <Hixie> Zeros: "january" and "1997" are both dates, but "17:01" and "1970-01-01" are not both times?
# [02:22] <Zeros> Hixie, 1970 01 01 is a date, there's no time in that.
# [02:23] <Zeros> 17:01 is a time
# [02:23] <Philip`> It's the time period from early midnight to late midnight on that day
# [02:23] <Hixie> Zeros: 1970-01-01 is a 24 hour period, just like 17:01 is a one minute period
# [02:23] <Philip`> 17:01 is the time period from the start of 17:01 to almost 17:02
# [02:23] * Philip` doesn't see a significant distinction either
# [02:24] <ddailey> does "yesterday" in an 18th century text have any meaning?
# [02:24] <zcorpan_> ddailey: yes. does it warrant its own element? probably not :)
# [02:24] <Zeros> hah
# [02:25] <Zeros> I love the <car> argument
# [02:25] <Hixie> Philip`: Zeros and us both have valid points -- you can cut times and dates any number of ways. timezones, repeating times, ranges, moments, etc -- <time> in HTML5 only handles the cases that are commonly seen on the web, according to the research i did
# [02:25] <Zeros> Makes it very easy to dismiss anything
# [02:25] <Hixie> this is why you can't make arguments based on opinions
# [02:25] <Hixie> it has to be based on research
# [02:25] <zcorpan_> Hixie: indeed
# [02:26] <Zeros> Hixie, That's not particularly useful for anyone outside google ;)
# [02:26] <Hixie> Zeros: lucky for us that we have googlers on the list, then :-)
# [02:26] <Zeros> Considering your research cannot be duplicated or verified, I'm not sure I really count that as formal research at all.
# [02:26] <Zeros> It might as well be made up
# [02:26] * Hixie specifically quit opera and came to work for google because he wanted access to this data, for what it's worth
# [02:26] <Hixie> Zeros: it might
# [02:27] <Hixie> Zeros: but then if you don't trust my integrity, you have bigger problems that whether or not <date> and <time> are in the spec
# [02:27] <Hixie> Zeros: i encourage you to find a way to get the data, like i did
# [02:27] <Philip`> If there was some way to get a uniform random list of web pages, you could check a small sample pretty easily, and make sure the rough pattern matches the previously published results
# [02:27] <Hixie> ideally somewhere other than google, so that we can have independent backup for the research
# [02:27] <Philip`> (or non-uniform random but biased in the same way as the original sample)
# [02:28] <Zeros> Philip`, The web is a failure in that manner though
# [02:28] <ddailey> hixie: can't you just publish a few more excerpts from time to time -- sort of in serial installments? :)
# [02:28] <Hixie> ddailey: what would you want me to publish?
# [02:28] <Zeros> Hixie, I'm not sure that's possible without writing an entire search engine; So, can you parse the web and find class=".*?email.*?" ?
# [02:29] * zcorpan_ should go to bed now, will talk about html5 for students in the morning
# [02:29] <ddailey> hixie: all the news that's fit to print
# [02:29] <ddailey> cooccurrence data would be sorta fun
# [02:29] <Hixie> zeros: "email" was the 380th most common class in my sample of several billion pages last september
# [02:29] * Parts: zcorpan_ (zcorpan@84.216.42.208)
# [02:30] <Zeros> Hixie, And copyright was?
# [02:30] <ddailey> a bit more detail on what goes on inside the <script> tag
# [02:30] <Hixie> Zeros: 7th
# [02:30] <Zeros> Hixie, hmm, interesting.
# [02:31] <Zeros> Not sure that's actually vindictive of anything though. <div class="footer"><span>©... #footer span {} works just as well. And the most common use case for classes is styling, not meaning.
# [02:31] <Hixie> footer was 1st
# [02:31] <Zeros> How about left and right?
# [02:32] <Hixie> left was 17th, right was 13th
# [02:32] <Zeros> more pages with a right hand column I guess
# [02:32] <Hixie> yeah, left and right inspired <aside> and <nav> (amongst others)
# [02:33] <Zeros> I still think adding proper elements for discreet common page components would be useful for deriving meaning from documents.
# [02:33] <Hixie> i agree
# [02:33] * Quits: laplink (link@212.33.131.105) (Quit: This computer has gone to sleep)
# [02:34] <Hixie> hence the new or repurposed <footer>, <header>, <article>, <menu>, <small>, <nav> elements
# [02:34] <Zeros> Hixie, So if you were going to compare <copyright> to class="copyright" what do you see as the disadvantage to the former?
# [02:34] <Hixie> which covers more than half the top 10 classes
# [02:35] <sbuluf> a new element vs. attribute vs. metadata. <--wouldn't this be worthy of a rationale page in some wiki?
# [02:35] <sbuluf> at least for some sort of faq
# [02:35] <Hixie> feel free to write one up
# [02:35] <Hixie> Zeros: well, designing an element needs information on the way you'd expect it to be used. for example, you'd need to know whether it's going to be a block or inline
# [02:36] <Hixie> Zeros: as mentioned on the webstats page, i considered <copyright>, but i couldn't work out how to design it
# [02:36] <Zeros> sbuluf, I didn't mention meta data specifically since I think it's a huge reliability problem as shown by keywords or description.
# [02:36] <Hixie> Zeros: should it be block? inline? metadata in the head? an attribute? a link?
# [02:37] <Zeros> Hixie, Speaking of which, on that same line of thought, combined block/inline containers like del are out?
# [02:37] <sbuluf> zeros, *you* didn't. but some else did. and i just did as well. *you* meantime (and everyone else), did not answer wat iu asked before, hence, marginalized me from the whole discussion.
# [02:38] <Zeros> sbuluf, My apologies.
# [02:38] <sbuluf> np
# [02:38] <Hixie> Zeros: <del> and <ins> are pains in the ass, but right now the spec allows them. the content models for them are hella complicated.
# [02:39] <Hixie> due to their transparent nature
# [02:39] <Zeros> Hixie, I'd say inline considering the most common use case for it would end up in the line of <footer><copyright>...
# [02:39] <Hixie> Zeros: what research are you basing that on?
# [02:40] <Hixie> Zeros: if there's one thing i've learnt from the web, it's don't assume what authors are doing. they seem to do things you wouldn't expect, imho.
# [02:40] <Zeros> Hixie, That the copyright on google, yahoo, deviantart, myspace, msn, w3.org, et al. are in the footers?
# [02:40] <Zeros> I'm sure I could compile a rather lengthly list of pages that have a copyright in the footer
# [02:40] <Hixie> Zeros: in the case of http://www.google.com/, i'd say it's not a footer, it's a paragraph of its own. thus it would be block-level.
# [02:41] <Hixie> Zeros: it's not "pages that have a copyright in the footer" that we need, it's a neutral study of randomly selected pages, and for each one, a determination of what the closest match to the existing markup is
# [02:41] <Zeros> Hixie, It's at the end of every page, it's a footer by definition.
# [02:41] <Hixie> Zeros: yes, but it's its own block
# [02:41] <Philip`> You could make a rather lengthy list of pretty much any feature at all, given how many pages there are to choose from :-)
# [02:42] <Philip`> (e.g. count the number of pages using <footer> already)
# [02:42] <Zeros> Philip`, It's the counter evidence pages which would be relevant. How many pages don't place the copyright at the end of the document?
# [02:42] <Hixie> Zeros: with the dozens of billions of pages on the web, you can find millions of pages to prove anything
# [02:43] <Hixie> e.g. i can give you over 3 million pages that use id="_ctl1_hlEmailFriend"
# [02:43] <Zeros> Hixie, I'm not sure how it being it's own block is an argument against that though. Google's markup sucks. <footer><copyright> is problematic there how?
# [02:44] <Philip`> http://www.whatwg.org/specs/web-apps/current-work/ - that has copyright information not in a footer
# [02:44] <Zeros> That gives it the meaning that's the document footer (which it is) and that it's the copyright (which it is)
# [02:44] <Hixie> Zeros: that's the wrong question. the question is, what's the problem that you're trying to solve?
# [02:44] <Zeros> Hixie, Differentiating the copyright from the rest of the document in a meaningful way. Reducing the need for attributes like role.
# [02:44] <Hixie> Zeros: if the problem is "people are using a class right now, so it makes sense to give them an element so that their pages are shorter and neater", then you wouldn't want to go from <p class="copyright"> to <footer><copyright>, because that would be way longer
# [02:45] <Zeros> Or predefined class names as the case may be.
# [02:45] <Hixie> Zeros: why is differentiating the copyright from the rest of the document in a meaningful way a goal?
# [02:45] <Hixie> Zeros: is there some use for the copyright?
# [02:45] <Zeros> Hixie, Why is adding <aside> better than class="left" ?
# [02:46] <Hixie> Zeros: because it is shorter, and allows people who come to edit the page later to understand the markup much quicker than if they had to learn all the site's custom classes
# [02:46] <Hixie> Zeros: and because it means you can switch it to the right hand side without changing all your class names
# [02:46] <Hixie> (or confusing yourself and those who follow you)
# [02:46] <Zeros> Hixie, <copyright> is shorter than <p class="copyright">, how is that even a relevant argument though...
# [02:47] <Hixie> if you are replacing <p class="copyright"></p> with <copyright></copyright>, then that argues for a block-level element (and it isn't shorter, anyway)
# [02:47] <Zeros> I'm not sure how length should be considered
# [02:47] <Hixie> length is usually a red herring, but it can be a guide
# [02:47] <Hixie> something shorter is usually simpler
# [02:47] <Hixie> and thus easier to understand
# [02:47] <Zeros> For that I guess I could argue for <copy>
# [02:47] <Zeros> Which has all kinds of translation problems, but it's shorter!
# [02:48] <Hixie> right. but that argues for a block-level element, not inline
# [02:48] <Philip`> If I could work out how to type in Unicode, I'd suggest <{the Unicode copyright symbol}> which is only one character
# [02:48] <Hixie> the point i'm trying to make is that if you really want to work out what to do with copyright, then you have to work out why and how people are using it today
# [02:48] <Hixie> only then can you really make a good design decision
# [02:49] <Zeros> Hixie, Either way, I see a real use case for copyright within the document as a means by which to differentiate it from the rest of the document for a screen reader (skip), a search engine (search by copyright?)
# [02:49] <Hixie> note that it's possible that we've already addressed the need that class="copyright" handles -- if people are just doing that so they can style it, then <small> in HTML5 already addresses their need
# [02:49] <Hixie> Zeros: right, but for that we already have <small>
# [02:50] <Zeros> Hixie, Why does the text need to be smaller?
# [02:50] <Hixie> Zeros: in practice, since copyrights are at the bottom, they don't need to be skipped; if they did, the <article> and <footer> elements already provide the hook for that
# [02:50] <Philip`> (http://canvex.lazyilluminati.com/misc/copyright.html is kind of relevant for seeing what some people use class="*copyright*" for - mostly they actually put copyright notices in it - though it doesn't help with knowing where on the page it goes...)
# [02:50] <Hixie> Zeros: also, google already does license search, and doesn't need a clear copyright element to do it
# [02:50] <Zeros> Hixie, Ah, now you're arguing the same thing I did. Why are copyrights at the bottom? ;)
# [02:50] <Hixie> Zeros: so the search engine use is apparently not true
# [02:50] <Hixie> Zeros: <small> is redefined in HTML5, see the new definition
# [02:50] <Zeros> So you agree that a copyright is probably in the footer?
# [02:51] <Zeros> Hixie, I know, how many pages use small right now?
# [02:51] <Hixie> a lot
# [02:51] <Zeros> And then them for presentational reasons?
# [02:52] <Hixie> ...?
# [02:52] <Zeros> err, and in them*
# [02:52] <Hixie> i don't understand the question
# [02:52] <Zeros> How many of the uses of <small> have to do with meaning and how many are just for making the font a little smaller?
# [02:53] <Hixie> no idea
# [02:53] <Hixie> in HTML4 <small> was presentational only, so presumably, all of them
# [02:53] <Zeros> um, Where's the research on that then?
# [02:53] <Zeros> That sounds like a huge mistake. You're making every page on the web that uses small have new meaning now...
# [02:53] <Hixie> no
# [02:53] <Hixie> all the pages on the web are not HTML5
# [02:53] <Zeros> Oh, so you're saying that HTML5 documents have different meaning than HTML4 ones?
# [02:54] <Hixie> i'm saying that anyone who wrote a valid HTML4 document still has a valid HTML4 document
# [02:54] <Hixie> HTML5 doesn't change that
# [02:55] <Zeros> Hixie, So screen readers and browsers that want to extract meaning need a switch to tell if it's HTML5 or not?
# [02:55] <Philip`> (http://canvex.lazyilluminati.com/misc/email.html for class="*email*" - only about two actually use it around an email address)
# [02:55] <Hixie> Zeros: no, they need heuristics to tell if the page is conforming or not.
# [02:55] <Hixie> Zeros: but they need that anyway -- most pages aren't conforming
# [02:56] <Zeros> Hixie, An HTML5 and a HTML4 document look identical if you don't use new features.
# [02:56] <Hixie> Zeros: yup
# [02:56] <Zeros> Hixie, So how can you reliably extract meaning?
# [02:56] <Hixie> you can't
# [02:56] <Zeros> Hixie, And in that same line, so HTML6 can just redefine what <small> means again and then say that a HTML6 document is not a HTML5 document?
# [02:56] <Hixie> you can only extract meaning from pages you know are conforming
# [02:56] * Quits: zdenko (zdenko@84.255.203.169) (Quit: zdenko)
# [02:56] <Hixie> the current state of the web is a disaster as far as that goes
# [02:57] <Zeros> Hixie, HTML4 becomes non-conforming with HTML5 though
# [02:57] <Zeros> since the <small> is useless
# [02:57] <Zeros> The same is true of <i> or <b>, you're saying they have meaning, but only in a HTML5 document near as I can tell.
# [02:58] <Hixie> i don't really understand the problem with that
# [02:58] <Zeros> And then you say that HTML4 and HTML5 look the same, and don't have a differentiating feature, so how is that meaning not lost?
# [02:58] <Hixie> this is a straw man argument
# [02:58] <Hixie> most pages on the web are completely non-conforming
# [02:59] <Zeros> You're saying HTML4 documents are still conforming in the HTML5 world, but they're not.
# [02:59] <Zeros> HTML4 document that used small for small text is not conforming in HTML5.
# [02:59] <Hixie> no, no
# [02:59] <Hixie> consider this from the top:
# [03:00] <Hixie> let's simplify and say that there are two classes of documents right now: those that use semantic markup and those that don't
# [03:00] <Hixie> those that do have "meaning", and those that don't, well, don't.
# [03:00] <Hixie> those in the latter category are those that use <i>, <b>, <small>. but in the previous versions, those elements had _no_ meaning (beyond the presentational meaning)
# [03:00] <Zeros> Yes, so they were conforming.
# [03:00] <Hixie> those in the former category don't use presentational elements
# [03:01] <Hixie> now, in the html5 world, we've given "semantic" meaning to those three elements, alongside their presentational meaning
# [03:01] <Zeros> So how do you know the difference between the semantic ones and the presentational ones?
# [03:01] <Hixie> the documents in the first category, those with meaning, still have the same meaning, and are unchanged
# [03:02] <Hixie> those in the second category, those without meaning, now have some minor meaning, possibly non-sensical
# [03:02] <Zeros> And the ones without meaning, which look just like a HTML5 document, have no meaning, and can't be differentiated from (non)conforming HTML5.
# [03:02] * Parts: ddailey (david_dail@24.144.172.117)
# [03:03] <Zeros> And you don't see any problem with adding non-sensical meaning to existing pages?
# [03:03] <Hixie> so, the above was the transition from html4 to html5. now, consider purely html5 documents.
# [03:03] * Quits: mjs (mjs@17.255.105.149) (Quit: mjs)
# [03:03] <Zeros> A purely HTML5 document looks just like a HTML4 document. Consider a purely HTML4, conforming document, that used <b> for presentation.
# [03:04] <Hixie> in html5, we have conforming documnets (those using the elements correctly) and non-conforming ones (those using the elements incorrectly)
# [03:04] <Zeros> It's valid, the meaning is correct, b was never deprecated, it has perfect meaning in HTML4. Now you're adding non-sense.
# [03:04] <Hixie> there's no way to distinguish them
# [03:04] <Hixie> programatically
# [03:04] <Zeros> And that's not a problem?
# [03:04] <Hixie> so a user agent has to have heuristics if it wants to detect one from the other (e.g. google does this)
# [03:05] <Zeros> Google can tell the difference between a presentational or a meaningful <b>?
# [03:05] <Zeros> How about screen readers?
# [03:05] <Hixie> but in fact, this has always been the case, because there is a third category of documents in the html4 case that i omitted to mention earlier: documents that look like they use semantic markup, but actually are ignoring their meaning and just using them for presentational effect
# [03:05] <Hixie> e.g. using <blockquote> for indent
# [03:06] <Hixie> or <table> for layout effects
# [03:06] <Zeros> And the fourth category that used valid markup and presentational elements too since they had no meaning.
# [03:06] <Hixie> and there was no way even then to tell the html4 documents with meaning from the html4 documents without meaning
# [03:06] <Zeros> And there's no way to tell a HTML5 document with meaning, from one without from one that's HTML4 that used <b> for presentation
# [03:07] <Hixie> in conclusion: we're not actually changing anything, except making some documents that previously had no meaning have some minor meaning that may be wrong -- we're just moving documents from the category of "no meaning" to "wrong meaning"
# [03:07] * Hixie goes back and looks at everything zeros wrote while he was saying that
# [03:08] <Hixie> i don't see what you describe as a problem, no
# [03:08] * Joins: wcox (chatzilla@70.101.178.102)
# [03:09] <Zeros> I do.
# [03:09] * Joins: laplink (link@212.33.131.105)
# [03:10] <Hixie> then we disagree :-)
# [03:10] <Zeros> I assume you have research that shows making it impossible to tell a meaningful b from a regular b is okay too?
# [03:10] <Zeros> Or anything that shows it's *not* a problem?
# [03:10] <Hixie> you can't prove a negative, typically
# [03:10] * Quits: dbaron (dbaron@63.245.220.242) (Ping timeout)
# [03:11] <Zeros> We can prove it is a problem though, with the enumerated points, of which you've stated don't matter because you just don't think they do.
# [03:11] <Zeros> You've dismissed the issues with telling a meaningful document from a non-sense document with "I don't care"
# [03:11] <Philip`> How is it possible to solve the problem of telling a meaningful b from a regular b?
# [03:12] <Philip`> (given that whatever markup is added, people will misuse it to varying extents)
# [03:12] <Zeros> Philip`, That's true of everything though, I wasn't touching that aspect. From here we can see that any page that used b before, as a presentational element (of which it's currently defined) becomes non-sense.
# [03:13] <Zeros> And a document that looks like HTML4 may also be HTML5 so we can't tell those apart.
# [03:13] <Hixie> Zeros: if we were talking about the difference between a link and a script insertion, then maybe it would be clearer that it's a problem. but we're talking about the difference between "text in a small font" and "small print", and "italic text" and "text that is offset from the other text", and "bold text" from "text that is highlighted", and i really don't see that that is an incompatible change
# [03:14] <Hixie> Zeros: the difference is so small as to be academic, imho
# [03:14] <Hixie> Zeros: can you give an example of where a user agent would process <i>-italics differently from <i>-offset-from-text?
# [03:14] <Zeros> Hixie, One that has to read it out loud?
# [03:15] <Zeros> Or one processing it for meaning
# [03:15] <Zeros> <i> is used for presentation all over (as you already noted)
# [03:15] <Hixie> Zeros: can you give an actual example? e.g. take emacsspeak, or jaws: what would they do with <i>-italics, and what would they do with <i>-offset-from-text that is different?
# [03:15] <Zeros> "Hey look at my awesome page, every paragraph is in italics!"
# [03:15] <Philip`> I think I may have meant to say, how is possible to tell a meaningful anything from a non-meaningful anything? It seems quite possible that that's impossible - and if you can never tell them apart, it's not an interesting problem to consider for a single specific feature that you still can't tell them apart because that's inevitable
# [03:16] <Zeros> Hixie, I'm not sure they actual care about either in a lot of cases since they're unreliable
# [03:16] <Philip`> (Er, that sentence didn't really make sense, I think)
# [03:16] <Hixie> Philip`: that's one thing i mentioned in my long monologue earlier -- we have this problem anyway with e.g. <blockquote>
# [03:16] <Hixie> Zeros: EXACTLY
# [03:16] <Hixie> Zeros: so what's the problem?
# [03:17] <Zeros> Hixie, And adding meaning to them means that screen readers CANNOT ever read them, since they will ALWAYS suffer from the old content on the web which used it for presentation.
# [03:17] <Hixie> Zeros: in practice, they'll speak <i> slightly differently, whether the author used it to mean "italics" or whether the author used it to mean "offset-from-text"
# [03:17] <Hixie> Zeros: in what way would the want to use <i> if there was no presentational legacy?
# [03:17] <Hixie> s/the/they/
# [03:17] <Zeros> Philip`, If you really wanted to get hot on the trail of meaning you'd have to remove all default presentation. If <foo> didn't change the way things looked, and just added meaning, it'd be abused less.
# [03:18] <Zeros> Problematic for visual UAs though.
# [03:19] <Zeros> Hixie, You mean why use them since they don't fall back on a presentational aspect?
# [03:19] <Zeros> So we could define <center> to be the same as <section> then?
# [03:20] <Hixie> Zeros: i mean if we introduced an element to mean "a span of text in an alternate voice or mood, or otherwise offset from the normal prose, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name", which wasn't <i>, how would the UA handle that element? how would it be _different_ from <i>?
# [03:20] <Zeros> Hixie, How is <aside> different from <div>?
# [03:20] <Zeros> It's the same argument.
# [03:21] <Hixie> um
# [03:21] <Hixie> no?
# [03:21] <Zeros> How are they different, what will a UA do differently to it?
# [03:21] <Hixie> aside allows authors to easily style a sidebar
# [03:21] <Zeros> that's not the same argument, you're way off in left field.
# [03:22] <Hixie> also <aside> gets involved in the algorithm for working out sections for tables of contents
# [03:22] <Zeros> <mood> lets authors style that differently than italic presentational text.
# [03:22] <Zeros> Same idea
# [03:22] <Hixie> no, because we'd drop <i> if we introduced <mood>
# [03:22] <Hixie> since we are getting rid of meaningless elements
# [03:23] <Hixie> you still haven't answered my question :-)
# [03:24] <Zeros> Assuming you didn't get rid of <i>, one in the UA could be used to form a dialog outline and chronicle moods.
# [03:24] <Zeros> anyway, you don't really care. It's all wasted breathe here. I've suggested <email>, <copyright> and quite a few other elements and they all have use cases which are "not good enough"
# [03:25] <Hixie> i myself have suggested dozens of elements and attributes that didn't make the cut
# [03:25] <Hixie> don't take it personally
# [03:25] <Zeros> I think I get why the WHATWG list is so much quieter than the html-wg one too. I'm sure in time that point will come as well.
# [03:25] <Hixie> it's hard to make good suggestions for new elements at this stage, afterall we've been doing this for over 3 years now, most of the obvious ideas have already been considered
# [03:26] * Quits: wcox (chatzilla@70.101.178.102) (Client exited)
# [03:26] <Zeros> So why was summary removed from table?
# [03:27] <Hixie> nobody uses it
# [03:27] <Zeros> http://www.safercars.gov/ bingo
# [03:27] <Hixie> (to be precise, it wasn't "removed", it was just not included. html5 was a blank slate into which html4 elements were added.)
# [03:27] <Zeros> Their title is funny too
# [03:28] <Hixie> that page is a perfect example of why summary="" sucks
# [03:28] <Zeros> What did you research on summary show?
# [03:28] <Zeros> your*
# [03:28] <Hixie> the very first row says exactly what the summary says
# [03:28] <Hixie> and since it's not tabular data, it shouldn't be a table in the first place
# [03:28] <Hixie> let's see
# [03:28] <Zeros> You said it wasn't used, not that it was duplicating the first line.
# [03:29] <Hixie> sorry, i was counting bad uses as non-uses
# [03:29] <Hixie> let me rephrase
# [03:29] <Hixie> "it's never used correctly"
# [03:29] <Zeros> prove it :)
# [03:29] <Zeros> Or at least, show me your 'results' from research :p
# [03:29] <Hixie> i can't, again, it's a negative :-)
# [03:29] <Hixie> let's see
# [03:29] * Joins: marcos (chatzilla@131.181.148.226)
# [03:30] <Zeros> well show me that there were little or no cases used correctly in your results, we'll ignore fringe cases where google can't search it.
# [03:30] * Quits: hyatt (hyatt@24.6.91.161) (Quit: hyatt)
# [03:31] <Hixie> hm, i don't have the numbers on summary="" values here
# [03:31] <Hixie> that might still be in my queue
# [03:31] * Hixie searches
# [03:31] <Zeros> http://diveintoaccessibility.org/day_20_providing_a_summary_for_tables.html
# [03:31] <Zeros> There's two use cases for summary in that page
# [03:31] <Hixie> ah, yeah, summary is in my list of "things i want to know that are going to be expensive to find out"
# [03:32] <Hixie> oh don't get me wrong
# [03:32] <Hixie> i think summary=, if it was used, would be useful for accessibility
# [03:32] <Zeros> The other summary use cases are too
# [03:32] <Zeros> JAWS reads it and so does iCab.
# [03:32] <Hixie> but in practice most features that are only useful in "accessibility" contexts are abused or misunderstood
# [03:33] * Joins: wcox (wcox@70.101.178.102)
# [03:33] <Zeros> Well lets see then, compile a list of a lot of summaries and their attached pages, lets see how misused it is.
# [03:33] <Zeros> I'm hoping google is capable of that
# [03:33] <Hixie> yeah, that's going to have to be something we look at at some point
# [03:33] <Zeros> I know the 508 people would have my head if I said we were going to remove summary.
# [03:34] <Zeros> Speaking of which, did mjs ever propose his accessibility for media elements?
# [03:34] <Hixie> the "508 people", in that case, care more about rules than about practicality
# [03:34] <Hixie> what we SHOULD do is find a way to fix tables so they are accessible
# [03:34] <Hixie> summary="", imho, is really not a good design
# [03:35] <Zeros> For the people that need to use their 508 compliant pages their argument is perfectly valid
# [03:35] <Zeros> And I'm betting there are lots of pages using it that google can't spider
# [03:35] <Hixie> 508-compliance doesn't even remotely guarentee accessibility
# [03:35] <Zeros> um, real compliancy does, yes.
# [03:36] <Zeros> Some random "validator" doesn't
# [03:36] <Hixie> e.g. the summary="" on the .gov page you listed above is a great example of summary="" actually hurting matters.
# [03:36] <Zeros> Have you seen the 508 checklist that government employees need to go down?
# [03:37] <Hixie> you mean http://www.section508.gov/index.cfm?FuseAction=Content&ID=14 ?
# [03:37] <Hixie> or http://www.section508.gov/index.cfm?FuseAction=Content&ID=12 ?
# [03:37] <Zeros> Yes
# [03:38] <Zeros> And assuming you actually comply with all the points, you're making the page accessible.
# [03:38] <Hixie> assuming you even understand what the points are saying
# [03:38] <Hixie> you're already doing pretty well
# [03:38] <Zeros> Get the check list, it makes it very clear.
# [03:39] <Hixie> oh, you don't mean the above then
# [03:39] <Hixie> i thought you did mean the above
# [03:39] <Zeros> no
# [03:39] <Hixie> you mean the actual checklist, like this one: http://www.webaim.org/standards/508/508checklist.pdf ?
# [03:39] <Zeros> Yes, but it's the real one that they have in government offices.
# [03:39] <Hixie> uri?
# [03:40] <Zeros> I'm not sure of one, I have a printed copy somewhere, I'll have to find it for you.
# [03:40] * Joins: inimino (inimino@75.71.88.233)
# [03:40] <Zeros> It enumerates points very specifically "all video must have written transcripts or accessible closed captioning" etc.
# [03:41] <Hixie> sure
# [03:42] <Philip`> http://canvex.lazyilluminati.com/misc/summary.html - still statistically insignificant and biased but probably gives better than zero idea
# [03:42] <Zeros> Philip`, where's that from?
# [03:44] <Zeros> Hixie, http://www.cfug-md.org/meetings/VanessaHowles3Sec508Template1.doc
# [03:44] <Hixie> well there's irony for you
# [03:44] <Hixie> the accessibility document is inaccessible to me
# [03:44] <Zeros> Oh?
# [03:45] <Philip`> Zeros: From the combination of the top 1000 Yahoo search results for each of "the", "a" and "and"
# [03:45] * Hixie jumps through hoops to get this word document to show something on his machine
# [03:45] <Zeros> Philip`, You work for yahoo, or yahoo lets you scan markup?
# [03:45] <Zeros> Hixie, What's wrong with the word doc?
# [03:45] <Hixie> word's a proprietary format, i don't have good ways to read them
# [03:46] <Philip`> Zeros: No, I just used their search API to get a list of those results, and then downloaded them and passed them through the html5lib parser
# [03:46] <Hixie> Philip`: it's good data
# [03:46] <Philip`> (hence only being ~2500 pages instead of billions)
# [03:46] <Zeros> Hixie, It's not /that/ proprietary though, TextEdit.app, WordPad, OpenOffice?
# [03:47] <Zeros> Certainly not as bad as Flash with the single player architecture, heh.
# [03:47] <Philip`> (and being heavily biased towards front pages, and to English sites, and to whatever Yahoo thinks makes a site popular)
# [03:47] <Zeros> Hixie, Want me to print to PDF for you?
# [03:47] <Hixie> Zeros: is there a spec for it? the only tools i have that process it are ones that have reverse-engineered the format, and those are not ultrareliable
# [03:47] <Hixie> no, i've got it up now
# [03:47] <Hixie> Philip`: what would be interesting is the text in the attribute was in any way similar to the text at the start of the table
# [03:47] <Zeros> You're in luck, Office XML gives you a spec Hixie (har har, it's useless too)
# [03:48] <Zeros> If there every was a spec to come out of MS that was completely useless, that was it.
# [03:48] <Hixie> calling the office xml spec a "spec" is an insult to my profession :-)
# [03:48] <Zeros> The sarcasm in my statement should have been enough to kill small animals :)
# [03:50] <Philip`> (Updated summary.html now to show the URLs it came from)
# [03:51] <Zeros> Hixie, They're actually in the process of revising 508 now too
# [03:53] <Zeros> Philip`, Some of those looks plenty valid. ridegear for one.
# [03:54] <Hixie> theu ridegear.com site's tables are all presentational
# [03:54] <Zeros> The number of "table is used for layout purposes" type ones is interesting
# [03:55] <Hixie> yeah. talk about irony.
# [03:55] * Quits: laplink (link@212.33.131.105) (Quit: This computer has gone to sleep)
# [03:55] <Hixie> using an attribute intended to help accessibility to tell the user that the page isn't accessible
# [03:55] <Zeros> Hixie, So what your objection to a transcript element inside media elements and source elements? (possibly an attribute)
# [03:56] * Quits: marcos (chatzilla@131.181.148.226) (Ping timeout)
# [03:57] <Philip`> I wonder if many of the summary="" are there because the table is irrelevant and should be skipped by non-visual readers, or because they just wanted to shut up the accessibility warnings without doing any work
# [03:58] <Zeros> Hixie, Not for text content though, for pointing to a separate transcript like longdesc. Placing an entire transcript to a movie that's 20 minutes long right in the page can make the page very heavy.
# [03:59] <Zeros> Use case is that 508 compliant pages must have a transcript, government sites right now add them separately with link below or inside the current media element.
# [03:59] <Hixie> Zeros: dunno, haven't looked at the various proposals for <video> metadata stuff yet. there's a bunch of them on the pile.
# [03:59] <Zeros> Screen readers could offer to load up the transcript as an option, browsers with flash disabled could offer to do it like an <iframe>
# [03:59] <Zeros> ah
# [04:00] <Hixie> as you say, it's something we need
# [04:00] <Zeros> yes :)
# [04:00] <Hixie> whether it should be an attribute (or something) on the video, or a rel="" value on <a>, or in-page content of some kind, is what we'll have to decide
# [04:00] <Hixie> (or something else)
# [04:00] <Zeros> ah yes
# [04:01] <Zeros> rel feels problematic
# [04:01] <Zeros> Is there a list of all the proposals somewhere?
# [04:02] <Zeros> I'd be interested in forwarding it to the accessibility people I know working in government positions to see what their feedback was.
# [04:02] <Hixie> yup, on my IMAP server :-)
# [04:03] <Zeros> hah
# [04:03] <Zeros> that's a little much effort for me to forward it ;)
# [04:03] * Joins: marcos (chatzilla@131.181.148.226)
# [04:05] <Zeros> Hixie, http://www.access-board.gov/ has information about the 508 and ADA committees
# [04:08] <Zeros> All the 508 committee's presentation materials are available in two formats too, pdf or ppt and html or rtf for people who don't want to use a specless document
# [04:09] * Quits: marcos (chatzilla@131.181.148.226) (Ping timeout)
# [04:09] <Zeros> anyway, thanks for the discussion Hixie
# [04:11] <Hixie> np
# [04:16] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Quit: Leaving)
# [04:33] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [04:38] * Joins: gavin_ (gavin@74.103.208.221)
# [04:51] * Joins: marcos (chatzilla@131.181.148.226)
# [05:08] * Joins: mjs (mjs@64.81.48.145)
# [05:50] * Quits: jdandrea (jdandrea@68.192.161.254) (Quit: jdandrea)
# [05:55] * Quits: wcox (wcox@70.101.178.102) (Quit: wcox)
# [06:00] * Joins: hyatt (hyatt@24.6.91.161)
# [06:01] * Quits: hyatt (hyatt@24.6.91.161) (Client exited)
# [06:01] * Joins: hyatt (hyatt@24.6.91.161)
# [06:39] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [06:44] * Joins: gavin_ (gavin@74.103.208.221)
# [06:48] * Quits: heycam (cam@203.214.12.71) (Ping timeout)
# [06:51] * Joins: schepers (schepers@72.29.239.177)
# [07:04] * Joins: heycam (cam@210.84.3.81)
# [07:05] * Quits: schepers (schepers@72.29.239.177) (Quit: Free at last!)
# [07:28] * Joins: myakura (myakura@125.194.247.196)
# [07:36] * Joins: Zeros (Zeros-Elip@69.140.48.129)
# [07:44] * Joins: dbaron (dbaron@71.198.189.81)
# [07:57] * hyatt wonders if he has a cvs account now
# [08:04] <cying> you probably do
# [08:05] <cying> cp -rf WebKit/* Amaya/*
# [08:05] <cying> cvs commit
# [08:07] <cying> hyatt: i know i know, not funny...
# [08:09] <Zeros> Are they still actively developing amaya?
# [08:09] <hyatt> what's amaya, is that the w3c browser thingie
# [08:10] <cying> yes
# [08:11] <cying> i was having a discussion today with someone about how W3C could improve
# [08:11] <cying> and i thought maybe if they backed implementation on a WebKit fork, that might be worthwhile
# [08:12] <cying> get some real tests in there
# [08:12] <cying> (in the specs, not in webkit)
# [08:12] <cying> fantasy != reality
# [08:22] <Zeros> amaya historically was awful
# [08:24] <sbuluf> http://lists.w3.org/Archives/Public/www-tag/2006Nov/0077.html
# [08:26] <Zeros> dead then I take it
# [08:27] <Zeros> Whatever Amaya could/should have accomplished hopefully HTML5 can do so with test cases.
# [08:29] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [08:34] * Joins: gavin_ (gavin@74.103.208.221)
# [08:37] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [08:37] <hyatt> why webkit
# [08:38] * Quits: marcos (chatzilla@131.181.148.226) (Ping timeout)
# [08:39] * Joins: marcos (chatzilla@131.181.148.226)
# [08:39] <Zeros> hyatt, because it's awesome?
# [08:39] <hyatt> :)
# [08:39] <hyatt> awwww
# [08:39] <hyatt> flattery will get you everywhere
# [08:39] <Zeros> sweet
# [08:39] <Zeros> :)
# [08:40] <Zeros> I found a weird bug the other day, I need to find that page again. Searching for a word actually got you into the middle of the result set. So previous would find earlier matches.
# [08:42] * Joins: gavin_ (gavin@74.103.208.221)
# [08:43] <Zeros> oh I know what it was, hmm, I bet that was my bad, nevermind.
# [08:56] * Quits: inimino (inimino@75.71.88.233) (Ping timeout)
# [08:56] * Joins: tH (r@87.102.22.235)
# [08:58] * Quits: Zeros (Zeros-Elip@69.140.48.129) (Quit: Leaving)
# [09:04] * Joins: laplink (link@212.33.131.105)
# [09:04] * Quits: laplink (link@212.33.131.105) (Quit: This computer has gone to sleep)
# [09:05] * Joins: laplink (link@212.33.131.105)
# [09:08] * Joins: loic (loic@86.71.4.162)
# [09:45] * Quits: dbaron (dbaron@71.198.189.81) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [09:47] * Quits: myakura (myakura@125.194.247.196) (Ping timeout)
# [10:00] * Quits: laplink (link@212.33.131.105) (Quit: Leaving)
# [10:06] * Joins: zdenko (zdenko@193.77.152.244)
# [10:23] * Joins: zcorpan_ (zcorpan@84.216.41.94)
# [10:31] * Joins: ROBOd (robod@86.34.246.154)
# [10:44] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [10:49] * Joins: gavin_ (gavin@74.103.208.221)
# [10:55] * Quits: zcorpan_ (zcorpan@84.216.41.94) (Ping timeout)
# [11:09] * Quits: sbuluf (rx@200.49.140.40) (Ping timeout)
# [11:12] * Quits: hyatt (hyatt@24.6.91.161) (Quit: hyatt)
# [11:13] * Joins: hyatt (hyatt@24.6.91.161)
# [11:42] * Joins: zcorpan_ (zcorpan@84.216.41.94)
# [12:01] * Joins: jdandrea (jdandrea@68.192.161.254)
# [12:33] * Quits: gsnedders (gsnedders@86.139.123.225) (Quit: Don't touch /dev/null…)
# [12:42] * Quits: hyatt (hyatt@24.6.91.161) (Quit: hyatt)
# [12:45] <zcorpan_> is Henrik Leid smoking crack?
# [12:45] <zcorpan_> s/Leid/Lied/
# [12:45] <anne> you could ask
# [12:46] <anne> if he is you might not get a meaningfull answer though :p
# [12:46] <zcorpan_> heh
# [12:51] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [12:56] * Joins: gavin_ (gavin@74.103.208.221)
# [13:11] * Joins: myakura (myakura@125.194.247.196)
# [13:47] * Joins: ddailey (david_dail@24.144.172.117)
# [13:47] * Parts: ddailey (david_dail@24.144.172.117)
# [13:48] * Joins: gsnedders (gsnedders@86.139.123.225)
# [14:09] <hsivonen> oh. he'd like to kick anyone who suggests <indent>? I wonder if he'd like to do that because it is presentational or because it isn't compatible with legacy UAs that require <blockquote>.
# [14:10] * Quits: zcorpan_ (zcorpan@84.216.41.94) (Ping timeout)
# [14:30] <Lachy> Henrik seems to be reading too much into the meaning of "(public) Invited expert". It really just means contributor
# [14:33] <Philip`> It seems to be a meaningless phrase that's only kept because otherwise it would require changing the Process which takes forever
# [15:05] * Joins: zcorpan_ (zcorpan@130.243.79.10)
# [15:06] <nickshanks> maybe we could change it to "Uninvited Idiot" :-)
# [15:06] <anne> "One <burger/> please"
# [15:07] <anne> (from DanC)
# [15:07] <nickshanks> or, more seriously, "Interested Party"
# [15:08] <Philip`> or "mailing list subscriber"
# [15:09] <zcorpan_> "just another moron"
# [15:11] <zcorpan_> or "self-invited nobody"
# [15:12] * anne is glad to be part of a W3C Member
# [15:12] * zcorpan_ doesn't care
# [15:13] * Bob_le_Pointu is not.
# [15:24] * Joins: briansuda (briansuda@82.221.34.106)
# [15:25] * gsnedders attempts to not make a comment about anne not wanting a burger
# [15:25] * gsnedders fails by saying taht
# [15:25] <gsnedders> *that
# [15:27] <nickshanks> i don't think <burger/> is semantic enough
# [15:27] * Joins: zcorpan (zcorpan@84.216.40.21)
# [15:28] <anne> it doesn't have to be
# [15:28] <anne> it's quite temporary
# [15:28] <nickshanks> it doesn't have to be, as long as it's a WYSIWYG burger chain?
# [15:29] <anne> it's eaten during parsing
# [15:29] <gsnedders> not tokenising?
# [15:29] <anne> neh
# [15:29] <anne> that would be hard
# [15:29] <gsnedders> because otherwise isn't it left open?
# [15:29] <anne> you first have to make the token to eat it :)
# [15:29] <gsnedders> :)
# [15:29] * Quits: zcorpan_ (zcorpan@130.243.79.10) (Ping timeout)
# [15:30] * Joins: zcorpan_ (zcorpan@84.216.40.21)
# [15:30] <Philip`> It fits in nicely with the existing elements - <menu><burger/><option value="$1.99">Large</option><option value="$3.99">Extra Large</option></menu>
# [15:31] <anne> <input type="<burger/>">
# [15:32] * Quits: zcorpan (zcorpan@84.216.40.21) (Ping timeout)
# [15:32] <gsnedders> but that creates parser errors!111!!!111onee1!!eleventy!!!
# [15:32] <anne> no it doesn't
# [15:32] <gsnedders> < doesn't create a parser error any more? oh.
# [15:33] <Philip`> <input type="mouth" required="<burger/>">
# [15:34] <anne> gsnedders, it never did
# [15:34] <anne> gsnedders, inside double or single quoted attribute values in HTML5, that is
# [15:34] <gsnedders> anne: it does in XML
# [15:34] <anne> who cares about that?
# [15:34] <anne> (my XML5 prototype allows them fwiw)
# [15:34] <gsnedders> anne: and it does in SGML. I can't remember HTML5's tokeniser's details so well :P
# [15:35] <Philip`> This <burger/> looks like XML
# [15:35] <gsnedders> anne: I just assumed anywhere where there was a parse error in SGML there was one in HTML5
# [15:35] <zcorpan_> gsnedders: < in a quoted attribute value is allowed in sgml iirc
# [15:35] * Quits: briansuda (briansuda@82.221.34.106) (Quit: briansuda)
# [15:36] * gsnedders doesn't have access to a copy of the SGML spec here to check, but he thinks otherwise
# [15:36] <anne> Philip`, it's a void tag with a symbol of faith to please the XML gods
# [15:38] <zcorpan_> gsnedders: in any case, parse errors in sgml doesn't imply parse errors in html5... e.g. <foo bar> is a parse error in sgml unless "bar" is a value defined in the dtd. not a parser error in html5
# [15:39] <gsnedders> zcorpan_: well sure, seeming HTML5 doesn't have DTDs
# [15:42] * Joins: briansuda (briansuda@82.221.34.106)
# [16:10] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [16:13] * Joins: Shunsuke (Shunsuke@219.110.80.235)
# [16:15] * Joins: gavin_ (gavin@74.103.208.221)
# [16:34] * Quits: Shunsuke (Shunsuke@219.110.80.235) (Ping timeout)
# [16:36] * Joins: billmason (billmason@69.30.57.156)
# [16:44] * Joins: AnPol (anpol@85.118.224.254)
# [16:51] * Joins: DanC_lap (connolly@128.30.52.30)
# [16:52] * Quits: zdenko (zdenko@193.77.152.244) (Quit: zdenko)
# [16:52] * Quits: briansuda (briansuda@82.221.34.106) (Quit: briansuda)
# [16:55] * Joins: h3h (bfults@66.162.32.234)
# [17:02] * Joins: Shunsuke (Shunsuke@219.110.80.235)
# [17:16] * Quits: DanC_lap (connolly@128.30.52.30) (Ping timeout)
# [17:29] * Joins: foca (foca@190.64.207.115)
# [17:32] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
# [17:33] * Joins: DanC_lap (connolly@128.30.52.30)
# [17:38] * Parts: foca (foca@190.64.207.115)
# [17:46] * Quits: AnPol (anpol@85.118.224.254) (Quit: Bye)
# [17:49] * Quits: Shunsuke (Shunsuke@219.110.80.235) (Ping timeout)
# [17:49] * Joins: Shunsuke (Shunsuke@219.110.80.235)
# [17:52] * Joins: schepers (schepers@72.29.239.177)
# [17:55] * Quits: tH (r@87.102.22.235) (Ping timeout)
# [17:59] * Joins: tH (r@87.102.22.235)
# [18:02] <cying> i have a stupid question
# [18:02] <cying> RELAXNG, DTD, schemas,... they all serve to declaratively specify a grammar for a particular language...
# [18:03] <cying> couldn't they be replaced with a procedural imperative language?
# [18:03] <cying> since, correct me if i'm wrong, things like SVG, HTML5 and CSS can't be validated simply with a DTD.
# [18:04] <hsivonen> cying: replaced for what purpose?
# [18:05] * Quits: schepers (schepers@72.29.239.177) (Quit: Free at last!)
# [18:05] <cying> hsivonen: so that something like the internals of SVG's d attribute could be well-specified by something other than paragraphs of text
# [18:05] <hsivonen> cying: if for validation, the answer is "yes"
# [18:05] <cying> hsivonen: ohhh, i forgot about BNF
# [18:05] <cying> hsivonen: i guess i'm looking for something more meaningful than BNF
# [18:05] <cying> grammars
# [18:06] <hsivonen> cying: what you are looking for is Python or Java
# [18:06] <cying> ECMA claims to be using ML for ECMAScript 4 or 5
# [18:06] <cying> hsivonen: yes, i wonder if the html5lib could be it
# [18:06] <hsivonen> cying: html5lib is just a parser
# [18:06] <cying> hsivonen: but i guess i thought it would be fun as part of a formal spec
# [18:07] <cying> that's true
# [18:07] <cying> but perhaps a validator + test suite for the validator could be a formal effort by the WG
# [18:08] <cying> in Python, perhaps
# [18:11] * Quits: DanC_lap (connolly@128.30.52.30) (Ping timeout)
# [18:11] * Joins: kazuhito (kazuhito@222.151.148.23)
# [18:12] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [18:12] <hsivonen> cying: are you aware that there already is a non-vaporware project?
# [18:12] <cying> hsivonen: no, what's it called?
# [18:13] <hsivonen> http://hsivonen.iki.fi/validator/html5/
# [18:13] <hsivonen> documentation: http://hsivonen.iki.fi/thesis/
# [18:14] <cying> cool
# [18:15] <cying> is it schema validation only or do you intend to check attribute syntax?
# [18:16] <hsivonen> cying: it is not validation only and I already check attribute syntax (but incompletely at this point)
# [18:16] <cying> <path d="M35,20 L23,35 ...." transform="scale(30, 40) rotate(10, 20) ..." />
# [18:16] <hsivonen> SVG is on my todo list after HTML5
# [18:18] <cying> fascinating, well this is a great effort
# [18:18] <cying> it's too bad it's in java though
# [18:18] <cying> for me, it'll be harder to contribute
# [18:19] <cying> but i suppose, given the broad range of tools used to validate W3C specs it may be the right choice for its intended use
# [18:19] <hsivonen> cying: of garbage collected languages that run on various Unix-like systems Java has the best XML library ecosystem
# [18:19] <cying> right
# [18:20] <hsivonen> Python was the runner-up that didn't get chosen
# [18:20] <cying> i wonder if a HTML5 only one in Python could be written
# [18:20] <cying> that was shorter and easier for spec contributors to edit
# [18:21] <cying> anyway, more vaporware talk,
# [18:21] * MikeSmith thinks cying should take some time to read hsivonen's thesis
# [18:22] <hsivonen> cying: you do realize that my implementation is based on a RELAX NG schema for the most part and RELAX NG Compact Syntax is easier to edit than Python?
# [18:22] <hsivonen> part of the point of choosing Java is that Java has a RELAX NG validator written by one of the editors of the RELAX NG spec
# [18:23] <hsivonen> the other reason is that SAX is ubiquitous in the Java world, so all libraries fit together
# [18:29] <nickshanks> whenever i see that i think of frankie goes to hollywood
# [18:30] <nickshanks> and the 'ng!' bit just adds to the aural imagery …
# [18:39] <cying> hmmm
# [18:39] <cying> i think i will do some more research
# [18:39] <cying> i thought that RELAX NG was only opaque outside of attributes
# [18:39] <cying> but i wonder what it does with HTML tag soup
# [18:39] <cying> so i will go and read up more on RELAX NG
# [18:40] <cying> hsivonen: very cool stuff
# [18:41] <hsivonen> cying: RELAX NG validators can use libraries implemented in Turing-complete languages to check the inside of attributes
# [18:41] <cying> hsivonen: ah
# [18:41] <hsivonen> cying: again, the API situation is the best for Java
# [18:42] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Get thee behind me, satan.)
# [18:42] <cying> hsivonen: i don't doubt it
# [18:44] * Joins: DanC_lap (connolly@128.30.52.30)
# [18:49] * Quits: cying (cying@75.18.223.137) (Quit: cying)
# [19:03] * Joins: olivier (ot@128.30.52.30)
# [19:05] * Joins: Sander (svl@71.57.109.108)
# [19:11] * Joins: mjs (mjs@17.255.105.149)
# [19:17] * Joins: schepers (schepers@72.29.239.177)
# [19:21] * Quits: tH (r@87.102.22.235) (Ping timeout)
# [19:22] * Quits: Sander (svl@71.57.109.108) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [19:24] * Joins: Sander (svl@71.57.109.108)
# [19:25] * Joins: tH (r@87.102.22.235)
# [19:39] * Quits: tH (r@87.102.22.235) (Ping timeout)
# [19:41] * Joins: tH (r@87.102.22.235)
# [19:47] * Quits: Shunsuke (Shunsuke@219.110.80.235) (Quit: See you...)
# [19:55] * Joins: dbaron (dbaron@63.245.220.242)
# [19:55] * Joins: Shunsuke (Shunsuke@219.110.80.235)
# [19:58] * Quits: Shunsuke (Shunsuke@219.110.80.235) (Quit: See you...)
# [20:01] * Quits: tH (r@87.102.22.235) (Ping timeout)
# [20:02] * Joins: tH (r@87.102.22.235)
# [20:07] * Quits: schepers (schepers@72.29.239.177) (Quit: Free at last!)
# [20:12] <zcorpan_> perhaps PaveTheCowpaths should be more clear that it's not intended to adopt *anything* that is wide-spread, just don't forbid harmless things
# [20:12] <zcorpan_> apparently some people think it means the former
# [20:12] * Quits: olivier (ot@128.30.52.30) (Quit: This computer has gone to sleep)
# [20:15] <Philip`> It already says "consider adopting it" which sounds distinct enough from 'always adopt it' and still allows room for thinking
# [20:16] <Lachy> yeah, we need to do some serious PR work this week to address the misunderstandings and fears people have about such things
# [20:16] <Hixie> are we allowed to talk here?
# [20:16] <Philip`> (Incidentally, http://www.archive.org/details/whiffsfromwildme00fossiala has the original copy of the poem - it seems to have been mutated quite a bit in its journey around the web, at least in terms of formatting)
# [20:16] <zcorpan_> yup, just not on the mailing list (i think) :)
# [20:24] * Quits: myakura (myakura@125.194.247.196) (Ping timeout)
# [20:24] <mjs> zcorpan_: it was really meant to be more about practices that are orthogonal to existing standards rather than contrary ones, although there is a bit of each
# [20:35] * Joins: Zeros (Zeros-Elip@67.154.87.254)
# [20:39] * Quits: kazuhito (kazuhito@222.151.148.23) (Quit: Computer goes to sleep!)
# [20:40] * Quits: DanC_lap (connolly@128.30.52.30) (Ping timeout)
# [20:43] <zcorpan_> mjs: yeah, i'm just noticing that some of them are causing FUD
# [20:45] <zcorpan_> s/them/the proposed design principles/
# [20:45] <Hixie> Pave The Cowpaths really should be about paving the cowpaths when something is paved at all -- i.e. given a requirement, satisfy it by enshrining what authors do instead of inventing something new that they have to learn.
# [20:46] <Hixie> or maybe it should be about adding features based on what authors do, rather than on what we think they do
# [20:47] <Hixie> basically, it's either "class="footer" is used, so we should enshrine it" or "class="footer" is used, so we should have <footer>"
# [20:47] <Lachy> <footer> is the safer alternative, given the recent debate about predefined classes
# [20:49] <mjs> zcorpan_: I'm certainly happy to clarify it (and I owe a rewrite of Support Existing Content), but DanC asked me not to talk about it
# [20:49] <mjs> (on the mailing list)
# [20:49] <Hixie> Lachy: right, my point was that i'm not sure which one is intended
# [20:49] <mjs> he also put the design principles on indefinite hold, even though both designated reviewers came back with a mostly positive evaluation
# [20:50] <mjs> Hixie: it's meant to be the former (and at "consider" level, so could be outweighed by other technical issues), but we should also have something about the latter
# [20:50] * Joins: hasather (hasather@81.235.209.174)
# [20:51] <Hixie> mjs: would be interesting to have more examples from the spec than just <br/>
# [20:51] <mjs> Hixie: predefined classes would be an example, though likely a controversial one
# [20:51] <Hixie> yeah
# [20:52] <Hixie> predefined classes are an argument against this principle
# [20:53] <mjs> well, they are subject to your "given a requirement" proviso
# [20:53] <mjs> I'm not sure what requirement, if any, the current predefined classes satisfy
# [20:54] <Hixie> true
# [20:54] * Joins: DanC_lap (connolly@128.30.52.30)
# [20:54] <Hixie> i really think i'm gonna yank it
# [20:54] <Hixie> the only thing i actually cared about was class=copyright, and we can deal with that use case with <small>
# [20:54] <Hixie> oh! <small> is a pave-the-cowpaths
# [20:54] <mjs> good point
# [20:54] <Hixie> duh
# [20:54] <Hixie> shoulda thought of that
# [20:54] <Hixie> wait, i did
# [20:54] <Hixie> nevermind
# [20:54] <Hixie> moving right along
# [20:55] <Hixie> so yeah. the other classes in the spec now are handled by <aside>, mostly
# [20:55] <Hixie> and i think that's all _i_ need from the point of view of writing the spec
# [20:55] <Hixie> (e.g. making examples and notes <aside>s)
# [20:55] <mjs> I like <small> better than class="copyright", as it is more general and the actual copyright notice can be identified through trivial textual analysis so class="copyright" doesn't help much
# [20:55] <Hixie> yeah
# [20:55] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [20:56] <Hixie> class="copyright" as far as i can tell is just used for making small fonts, too
# [21:00] * Joins: gavin_ (gavin@74.103.208.221)
# [21:01] <nickshanks> making fonts small, not making small fonts ;)
# [21:06] <hsivonen> hmm. XHTML 1.0 2nd ed. has been translated into a larger number of languages than HTML 4.01 that in included by reference :-)
# [21:08] <nickshanks> does that include be-x-old ?
# [21:09] <nickshanks> which apparently has 7000 wikipedia articles: http://be-x-old.wikipedia.org/
# [21:11] <hsivonen> what does Breton have to do with the Cyrillic script??
# [21:12] <hsivonen> hmm. the list I'm looking at has the same 2-letter code for Byelorussian and Breton
# [21:13] * Joins: olivier (ot@128.30.52.30)
# [21:14] <hsivonen> IANA spells it Belarusian
# [21:15] <hsivonen> and Apple's dictionary Belorussian
# [21:18] * Quits: DanC_lap (connolly@128.30.52.30) (Ping timeout)
# [21:54] * Quits: loic (loic@86.71.4.162) (Quit: hoopa rules)
# [21:54] * Joins: edas (edaspet@88.191.34.123)
# [21:59] * Quits: edas (edaspet@88.191.34.123) (Quit: http://eric.daspet.name/ et l'édition 2007 de http://www.paris-web.fr/ )
# [22:01] * Quits: hasather (hasather@81.235.209.174) (Client exited)
# [22:02] * Joins: hasather (hasather@81.235.209.174)
# [22:02] * Joins: myakura (myakura@125.194.247.196)
# [22:02] * Joins: DanC_lap (connolly@128.30.52.30)
# [22:08] * Joins: Bony_M (elare@213.7.67.30)
# [22:10] <Bony_M> Hello. <marguee> can be used in html and xhtml ?
# [22:12] <Bony_M> Hello. <marguee> can be used in html and xhtml ?
# [22:12] <Zeros> Provided the browser implemented it, since it's not part of the standard. I think most of them did, though a little differently in each IIRC.
# [22:13] <Bony_M> ok thanks
# [22:13] * Quits: Bony_M (elare@213.7.67.30) (Quit: Bony_M)
# [22:13] <Zeros> :/
# [22:14] <gavin> I think he took that as a "yes" :)
# [22:15] <Philip`> It's technically true that marquee can be used, and it will work - he didn't ask if it actually should be used :-)
# [22:16] <Philip`> ...although he'd have to spell it correctly first, since HTML's error handling doesn't go that far
# [22:16] <mjs> it depends on what you mean by "can"
# [22:18] <gavin> also what you mean by "html" and "xhtml"
# [22:19] <Zeros> I can only imagine if browsers used a shortest unambiguous tag name error correction system like WPS...
# [22:20] <Philip`> Why limit it to unambiguous cases? Just choose the tag with the minimal Hamming distance from what the author typed in
# [22:22] <Philip`> As long as it's well-defined, it'd allow new possibilities for extensibility - you could add new tags that get error-corrected into <div> or <span> or <blockquote> or whatever so that you get the right effect in old browsers, just by choosing the new element name sufficiently carefully
# [22:22] <Zeros> Sure, that opens the door to all kinds of fun
# [22:24] <Zeros> Then we really could have a <dog>
# [22:27] <gsnedders> Philip`: error handling has odd things in it — <image> == <img>
# [22:44] * Joins: zdenko (zdenko@84.255.203.169)
# [22:49] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
# [23:09] * Quits: DanC_lap (connolly@128.30.52.30) (Ping timeout)
# [23:15] * Quits: olivier (ot@128.30.52.30) (Quit: This computer has gone to sleep)
# [23:22] * Joins: DanC_lap (connolly@128.30.52.30)
# [23:22] * Joins: olivier (ot@128.30.52.30)
# [23:27] * Joins: zdenko_ (zdenko@84.255.203.169)
# [23:27] * Quits: zdenko (zdenko@84.255.203.169) (Connection reset by peer)
# [23:37] * Joins: inimino (inimino@75.71.88.233)
# [23:51] * Joins: kingryan (rking3@142.131.37.98)
# [23:57] * Joins: timblair (timblair@87.74.129.183)
# Session Close: Sat May 12 00:00:00 2007

The end :)