/irc-logs / freenode / #whatwg / 2009-09-09 / end

Options:

# Session Start: Wed Sep 09 00:00:00 2009
# Session Ident: #whatwg
# [00:03] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
# [00:10] * Quits: dbaron (n=dbaron@c-69-140-1-234.hsd1.va.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
# [00:11] * Parts: rkennedy (n=rkennedy@pixout.appriss.com)
# [00:14] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
# [00:15] * Joins: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
# [00:15] * Quits: heycam (n=cam@210-84-56-211.dyn.iinet.net.au) ("bye")
# [00:20] * Quits: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (Read error: 60 (Operation timed out))
# [00:21] * Joins: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
# [00:24] * Joins: webben (n=benh@91.85.214.58)
# [00:25] * Quits: hobertoAtWork (n=hobertoa@gw1.mcgraw-hill.com) ("Nettalk6 - www.ntalk.de")
# [00:29] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
# [00:39] * Joins: tantek (n=tantek@67.180.202.79)
# [00:39] * Joins: nessy (n=nessy@115.130.24.94)
# [00:44] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
# [00:52] * Joins: sicking (n=chatzill@nat/mozilla/x-nxljfwkbyfrkcipn)
# [00:57] * Joins: tantekc (n=tantek@67.180.202.79)
# [01:00] * Joins: annevk3 (n=annevk@5355732C.cable.casema.nl)
# [01:00] * Joins: Unixmonkey (n=Unixmonk@ppp-69-208-150-144.dsl.ipltin.ameritech.net)
# [01:05] * Quits: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu) ("Leaving...")
# [01:10] * annevk3 wonders if the testcase format for Validator.nu is described somewhere
# [01:10] <annevk3> in case I suddenly get interested in making polyglot tests, that is
# [01:12] <Lachy> annevk3, I suppose you could just make them in the format used by html5lib, and then it should be fairly easy to convert to a different format if needed
# [01:12] <annevk3> oh wow
# [01:12] <annevk3> that latest bug report is awesome
# [01:13] <annevk3> JavaScript people are corporate lol
# [01:13] * Quits: tantek (n=tantek@67.180.202.79) (Read error: 110 (Connection timed out))
# [01:14] <Lachy> this one? [Bug 7547] New: on .drawImage() negative widths or heights should flip/mirror the image. There's no easy way of fliping images in canvas
# [01:14] <Lachy> that's the latest one I have
# [01:17] <annevk3> latest in yesterday's #html-wg logs then
# [01:18] * Quits: Unixmonkey (n=Unixmonk@ppp-69-208-150-144.dsl.ipltin.ameritech.net)
# [01:18] * Joins: boblet (n=boblet@p1254-ipbf304osakakita.osaka.ocn.ne.jp)
# [01:18] <Lachy> oh, that one. I was working on a reply to that. Not sure if I'll actually respond yet
# [01:19] * Quits: erlehmann (n=erlehman@tmo-104-178.customers.d1-online.com) (Read error: 110 (Connection timed out))
# [01:19] <annevk3> I take it you're bored? :)
# [01:20] * Quits: bgalbraith (n=bgalbrai@nat/mozilla/x-ejnobuccbzjpxpsy)
# [01:20] * Quits: nessy (n=nessy@115.130.24.94) ("This computer has gone to sleep")
# [01:21] <Lachy> not really, I was doing several things at the same time
# [01:22] <Lachy> just thought it would be useful to explain to him why having the spec defined in terms of the DOM was a good thing overall that made things simpler, not more complex
# [01:22] * Joins: Unixmonkey (n=Unixmonk@ppp-69-208-150-144.dsl.ipltin.ameritech.net)
# [01:26] * Joins: doublec (n=doublec@203-97-204-82.dsl.clear.net.nz)
# [01:27] <and> Is this the right channel for html5lib?
# [01:27] <Hixie> yes
# [01:27] <tantekc> Lachy - yeah, it's unfortunate, but better than inventing yet-another-abstraction (<cough>Infoset</cough)
# [01:28] <tantekc> because of course, inventing yet another abstraction doesn't confuse anyone right?
# [01:31] <and> Thanks. I have started to implement the tokeniser, and the tests in html5lib seem useful. However, I would like to make it stand-alone (i.e., possible to use without a treebuilder), and I did not find any tests for the transition to RCDATA or RAWTEXT. Are there any, or is the assumption that a real treebuilder has to be used for that?
# [01:32] <annevk3> the tests only cover what can happen in practice
# [01:33] <annevk3> oh wait
# [01:33] <and> It seems possible to run the tokeniser without a real treebuilder. The only real problem seems to be foreign content inside HTML inside foreign content, but I have not really tried to figure out how that works.
# [01:33] <annevk3> the assumption is that you need a treebuilder to switch that flag
# [01:34] <annevk3> there should be tests that set the flag to an initial state and then test if things are tokenized correctly
# [01:34] <and> Fair enough. Any intuition regarding how much of the treebulder is needed to get the tokenisation right?
# [01:34] <gsnedders> Is there any reason why that can't be done in the tokenizer? Are there any cases where it's hard to tell whether it should be changed or not?
# [01:34] * gsnedders has been meaning to look into this for ages
# [01:35] <gsnedders> Anyhow, time for my to get six hours sleep (ergh)
# [01:35] <annevk3> i think the implementations made so far both decided it would be best in the treebuilder
# [01:35] <and> Nested foreign content seems to be the only obvious problem.
# [01:35] <annevk3> because it effectively depends on the tag name
# [01:36] <and> (If I am right in thinking that the RCDATA and CDATA states are only reached after a corresponding start token.)
# [01:36] * Quits: Unixmonkey (n=Unixmonk@ppp-69-208-150-144.dsl.ipltin.ameritech.net)
# [01:36] <and> Yes, but there are just a handful of elements with CDATA/RAWTEXT or CDATA content, so that seems easy to add.
# [01:37] <and> *CDATA/RAWTEXT or RCDATA
# [01:37] * Joins: Unixmonkey (n=Unixmonk@ppp-69-208-150-144.dsl.ipltin.ameritech.net)
# [01:38] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
# [01:39] <annevk3> and, true, I think the design of the existing implementations influenced the tests here
# [01:39] <annevk3> though I might be missing something, been a while since I played with the parser
# [01:40] <and> Sure. Thanks for the information.
# [01:41] * Quits: Unixmonkey (n=Unixmonk@ppp-69-208-150-144.dsl.ipltin.ameritech.net) (Client Quit)
# [01:43] * Joins: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com)
# [01:44] * Quits: dglazkov (n=dglazkov@nat/google/x-qzclyyjcrvtebfmf)
# [01:49] <Hixie> and: you can't know if you'll be switching mode without a tree
# [01:49] <Hixie> and: because sometimes start tag tokens are just dropped on the floor without switching
# [01:51] <and> Hixie: "Sometimes"? Does this happen outside of foreign contents as well?
# [01:51] * Quits: webben (n=benh@91.85.214.58) (Read error: 145 (Connection timed out))
# [01:51] <and> s/ as well//
# [01:52] <annevk3> yeah
# [01:52] <annevk3> <select> <style> xx </select> xx
# [01:52] * annevk3 forgot
# [01:52] <annevk3> only <script> is dealt with inside <select>
# [01:52] <annevk3> <style>, <xmp>, <title>, <plaintext>, etc. are dropped on the floor
# [01:53] * tantekc is now known as tantek
# [01:56] <and> Right. The real question, then, is how much of the treebuilder can be ignored if the goal is not to build a tree or DOM, and the answer may not be easy to extract from the spec.
# [01:57] * Joins: franksalim (n=frank@adsl-75-61-85-210.dsl.pltn13.sbcglobal.net)
# [01:59] * Quits: cardona507 (n=cardona5@c-67-180-160-250.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
# [01:59] * Joins: cardona507 (n=cardona5@c-67-180-160-250.hsd1.ca.comcast.net)
# [01:59] <Hixie> and: what's the goal?
# [02:00] * ap|away is now known as ap
# [02:02] <tantek> if the goal is just to not build a tree or DOM, one answer would be NOP. ;) (defining things in terms of negatives - what they're not - is usually unproductive)
# [02:02] <and> Hixie: One goal would be to look at tokenisation of character references without the treebuilder overhead, but implementing a part of the treebuilder is probably not a good idea if a substantial part is required anyway.
# [02:04] * annevk3 figures out who and is by /whois
# [02:04] <annevk3> welcome!
# [02:04] <and> Thanks!
# [02:07] <annevk3> still waiting to hear back on encodings from the two missing browsers; guess I'll ping them tomorrow
# [02:07] <othermaciej> what's the encoding question?
# [02:08] <annevk3> othermaciej, trying to fill out the tables in http://wiki.whatwg.org/wiki/Web_Encodings
# [02:08] <annevk3> i.e. which encodings are shipping with Safari and what aliases are recognized and which matching algorithm is used to see if labels well, match
# [02:09] <Hixie> and: you mean for a study?
# [02:09] <Hixie> and: i think you'll end up needing a full tree builder, even if it just throws out the DOM it's creating
# [02:09] <Hixie> and: (the tree builder only uses internal data structures, it doesn't need the output iirc)
# [02:10] * Joins: ifette_GOOG (n=ifette@220.109.219.244)
# [02:10] <mpilgrim> erlehmann: of course the XHTML side is shorter
# [02:11] <mpilgrim> "fail at first error" is shorter than "parse billions of pages of existing web content according to the following 200-page algorithm"
# [02:11] <annevk3> i'd still like to see a never-failing SAX API for HTML defined one day (where you end up with graphs I guess)
# [02:12] <mpilgrim> i was under the impression that a SAX-like API would be difficult due to reparenting, adoption, whatever
# [02:12] <annevk3> for quite a few non-browser use cases that would actually be better than a DOM-based API I think
# [02:12] <mpilgrim> there are non-browser use cases?
# [02:13] <mpilgrim> someone's been falling for roy fielding's bullshit
# [02:13] <annevk3> mpilgrim, yeah, you'd need a distinct conformance class for such an API that can do other things there
# [02:13] <othermaciej> annevk3: of the unanswered questions asked on the wiki, I know we use the system version of ICU on Mac, and we do use TEC on Mac only for extra encodings that are not in ICU
# [02:13] <and> Hixie: Yes, I tried to look at the http://www.dotnetdotcom.org/ dataset, which seems to support my suspicion about the current handling of unterminated character references not being an ideal match for existing pages, but the results are rather too noisy since it is difficult to distinguish between attribute values and text without a parser.
# [02:13] <mpilgrim> ooh, there's an encoding wiki now? where?
# [02:14] * mpilgrim reads the backscroll and retracts the question
# [02:14] <annevk3> and, maybe use the Validator.nu HTML parser?
# [02:14] <annevk3> othermaciej, and on Windows?
# [02:15] <othermaciej> annevk3: our matching algorithms used to be case insensitive match ignoring addition or removal of underscores or hyphens
# [02:15] <othermaciej> annevk3: I think we might use ICU's matching now for at least some encodings; not sure
# [02:15] * Quits: murr4y (n=murray@85.84-49-67.nextgentel.com) (Read error: 60 (Operation timed out))
# [02:15] <Hixie> and: yeah
# [02:15] <othermaciej> annevk3: on Windows we ship our own ICU and don't support any non-ICU encodings
# [02:15] <annevk3> cheers
# [02:16] * Joins: murr4y (n=murray@85.84-49-67.nextgentel.com)
# [02:16] <and> annevk3: I was hoping to get away with something more lightweight, but that is indeed a possible solution.
# [02:21] <othermaciej> annevk3: more specifically, our encoding name comparison is:
# [02:21] <othermaciej> "Hash for all-ASCII strings that does case folding and skips any characters that are not alphanumeric."
# [02:22] <othermaciej> so it will ignore any extra non-alphanumeric characters, which might be more lenient than is needed
# [02:22] <annevk3> sounds like UTS22
# [02:22] <annevk3> I think it's actually causing you compat problems just like us
# [02:23] <othermaciej> that's possible
# [02:23] <othermaciej> TextEncodingRegistry.cpp is the file in our source tree that's responsible for creating all the text encoding name maps
# [02:23] <annevk3> on crazy sites that specify EUC_JP in HTTP but are actually UTF-8 yet we recognize them as EUC-JP because of UTS22 whereas Firefox and IE don't
# [02:24] * Quits: cardona507 (n=cardona5@c-67-180-160-250.hsd1.ca.comcast.net)
# [02:24] * Quits: benward (n=benward@nat/yahoo/x-svkbinepcqpczyov) (Read error: 110 (Connection timed out))
# [02:25] <othermaciej> that's crazy
# [02:25] * Quits: ifette (n=ifette@220.109.219.244) (Read error: 110 (Connection timed out))
# [02:27] <othermaciej> TextCodecICU::registerExtendedEncodingNames includes most of the aliases we add on top of ICU
# [02:27] <othermaciej> Latin-1 and UTF-16 have hardcoded special-case codecs
# [02:29] <othermaciej> for Latin-1 we register a whole lot of aliases for ISO-8859-1, windows-1252, and US-ASCII; we consider the three technically different but decode all three as WinLatin1
# [02:30] <othermaciej> similarly we have a lot of aliases for UTF-16LE and UTF-16BE
# [02:31] * Joins: tantekc (n=tantek@67.180.202.79)
# [02:33] * Joins: nessy (n=nessy@115.130.7.179)
# [02:35] * Joins: wakaba_ (n=wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
# [02:36] * Parts: nessy (n=nessy@115.130.7.179) ("Leaving")
# [02:39] * Joins: ttepasse (n=ttepas--@p5B016D77.dip.t-dialin.net)
# [02:45] * Quits: yutak_home (n=kee@M006079.ppp.dion.ne.jp) ("Ex-Chat")
# [02:47] * Quits: tantek (n=tantek@67.180.202.79) (Read error: 110 (Connection timed out))
# [02:47] <annevk3> ta othermaciej, added some notes to look at this later
# [02:48] * Quits: annevk3 (n=annevk@5355732C.cable.casema.nl)
# [02:54] * Quits: tantekc (n=tantek@67.180.202.79)
# [02:55] * Quits: franksalim (n=frank@adsl-75-61-85-210.dsl.pltn13.sbcglobal.net) ("Leaving")
# [03:01] * Joins: Unixmonkey (n=Unixmonk@ppp-69-208-150-144.dsl.ipltin.ameritech.net)
# [03:02] * Quits: ttepass- (n=ttepas--@p5B0142FA.dip.t-dialin.net) (Read error: 110 (Connection timed out))
# [03:11] * Joins: ginger (n=nessy@115.130.16.138)
# [03:13] * Joins: tantek (n=tantek@67.180.202.79)
# [03:14] * Quits: tantek (n=tantek@67.180.202.79) (Client Quit)
# [03:15] * Joins: tantek (n=tantek@67.180.202.79)
# [03:16] * Quits: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com) (Read error: 110 (Connection timed out))
# [03:19] * Joins: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
# [03:37] * Quits: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
# [03:38] * Joins: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp)
# [03:38] * Quits: ap (n=ap@17.203.14.219)
# [03:39] * Quits: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
# [03:41] * Quits: cying (n=cying@70.90.171.153)
# [03:49] * Quits: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp) ("Tomorrow to fresh woods, and pastures new.")
# [03:50] * Joins: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp)
# [03:51] * Joins: lazni (n=lazni@123.16.224.114)
# [03:55] * Joins: bgalbraith (n=bgalbrai@71.202.109.116)
# [03:55] * Joins: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
# [03:58] * Quits: tantek (n=tantek@67.180.202.79)
# [03:59] * Quits: bgalbraith (n=bgalbrai@71.202.109.116) (Client Quit)
# [04:04] * Quits: Unixmonkey (n=Unixmonk@ppp-69-208-150-144.dsl.ipltin.ameritech.net)
# [04:05] * Quits: Super-Dot (n=Super-Do@66-240-27-50.isp.comcastbusiness.net)
# [04:06] * Quits: ginger (n=nessy@115.130.16.138) ("This computer has gone to sleep")
# [04:12] * Joins: Super-Dot (n=Super-Do@66.240.25.23)
# [04:14] * Quits: weinig (n=weinig@nat/apple/x-tartuvlxzexbytck)
# [04:16] * Quits: jwalden (n=waldo@nat/mozilla/x-duunneqwuajfjoca) ("over and out")
# [04:24] * Quits: gavin__ (n=gavin@CPE001346f5db49-CM0018c0db9a8a.cpe.net.cable.rogers.com)
# [04:26] * Quits: sicking (n=chatzill@nat/mozilla/x-nxljfwkbyfrkcipn) (Remote closed the connection)
# [04:43] * Joins: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
# [04:44] * Quits: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net) (Remote closed the connection)
# [04:47] * Joins: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
# [04:48] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Read error: 60 (Operation timed out))
# [05:20] * Quits: Super-Dot (n=Super-Do@66.240.25.23)
# [05:26] * Joins: cying (n=cying@adsl-75-18-225-53.dsl.pltn13.sbcglobal.net)
# [05:37] * Quits: jlebar (n=jlebar@nat/mozilla/x-xzwlbzpufhjtnohd) ("Leaving")
# [05:40] * Joins: nessy (n=nessy@115.130.39.138)
# [05:47] * Joins: GPH-Laptop (n=GPHemsle@pdpc/supporter/student/GPHemsley)
# [05:50] * Joins: Unixmonkey (n=Unixmonk@ppp-69-208-150-144.dsl.ipltin.ameritech.net)
# [05:54] * Quits: dpranke (n=Adium@nat/google/x-touqirnmubesiukw) ("Leaving.")
# [05:56] * Quits: nessy (n=nessy@115.130.39.138) (Read error: 104 (Connection reset by peer))
# [05:56] * Joins: shepazu (n=schepers@adsl-221-74-58.rmo.bellsouth.net)
# [05:57] * Joins: othermaciej (n=mjs@ip67-95-211-74.z211-95-67.customer.algx.net)
# [06:00] * Quits: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley) (Read error: 110 (Connection timed out))
# [06:03] * Quits: othermaciej (n=mjs@ip67-95-211-74.z211-95-67.customer.algx.net)
# [06:08] * Quits: Unixmonkey (n=Unixmonk@ppp-69-208-150-144.dsl.ipltin.ameritech.net)
# [06:09] * Quits: lazni (n=lazni@123.16.224.114) ("Leaving.")
# [06:15] * Joins: lazni (n=lazni@123.16.224.114)
# [06:41] * Joins: tantek (n=tantek@12.140.254.34)
# [06:42] * Joins: cardona507 (n=cardona5@c-67-180-160-250.hsd1.ca.comcast.net)
# [06:48] * Joins: benward (n=benward@98.210.154.133)
# [06:51] * Joins: lazni1 (n=lazni@118.71.168.26)
# [06:51] * Quits: paul_irish (n=paul_iri@12.33.239.250)
# [06:52] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
# [06:54] * Quits: KevinMarks (n=KevinMar@c-67-164-14-96.hsd1.ca.comcast.net) ("The computer fell asleep")
# [06:57] * GPH-Laptop is now known as GPHemsley
# [06:59] * Quits: lazni (n=lazni@123.16.224.114) (Read error: 145 (Connection timed out))
# [07:03] * Quits: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
# [07:03] * Joins: [1]mpilgrim (n=mark@96.10.240.189)
# [07:05] * Quits: mpilgrim (n=mpilgrim@rrcs-96-10-240-189.midsouth.biz.rr.com) (Nick collision from services.)
# [07:05] * [1]mpilgrim is now known as mpilgrim
# [07:06] * Joins: zdobersek (n=zan@cpe-92-37-72-206.dynamic.amis.net)
# [07:07] <mpilgrim> http://diveintohtml5.org/detect.html
# [07:07] <mpilgrim> feedback welcome
# [07:07] <mpilgrim> (other than "it looks like shit in opera 10," which i already know about)
# [07:09] <roc> where did you get these fonts?
# [07:09] <cardona507> that looks good to me - nice fonts
# [07:09] <roc> the page looks fantastic to me
# [07:09] <mpilgrim> roc: http://diveintohtml5.org/about.html has links
# [07:12] <roc> thanks
# [07:13] <roc> I wish all your graphics were SVG, but nonetheless, great page
# [07:14] <mpilgrim> the SVG versions are much much larger
# [07:15] <mpilgrim> as they are basically created from scans of old books
# [07:15] <mpilgrim> so not terribly optimized as far as vector graphics go
# [07:16] <mpilgrim> anyway, thanks for the kind words
# [07:16] <mpilgrim> if anyone has any technical corrections or stumbles across any bugs in the dynamic content, please let me know
# [07:19] * Joins: Super-Dot (n=Super-Do@adsl-75-61-83-64.dsl.pltn13.sbcglobal.net)
# [07:27] * Quits: zdobersek (n=zan@cpe-92-37-72-206.dynamic.amis.net) ("Leaving.")
# [07:31] * Quits: doublec (n=doublec@203-97-204-82.dsl.clear.net.nz) (Read error: 60 (Operation timed out))
# [07:36] * Joins: roc_ (n=roc@203-97-204-82.dsl.clear.net.nz)
# [07:41] * Quits: tantek (n=tantek@12.140.254.34)
# [07:43] * Quits: mcdave (n=mcdave@cm-83-97-164-135.telecable.es) ("Leaving.")
# [07:43] * Joins: mcdave (n=mcdave@83.97.164.135)
# [07:43] * Quits: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley) ("This computer has gone to sleep")
# [07:44] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
# [07:45] * Joins: doublec (n=doublec@203-97-204-82.dsl.clear.net.nz)
# [07:45] * Quits: roc (n=roc@203-97-204-82.dsl.clear.net.nz) (Read error: 110 (Connection timed out))
# [07:45] * roc_ is now known as roc
# [07:46] * Quits: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
# [07:59] * Quits: doublec (n=doublec@203-97-204-82.dsl.clear.net.nz) ("Leaving")
# [08:08] * Joins: Mrmil (n=ut_ollie@host-77-236-204-8.blue4.cz)
# [08:14] * Joins: harig (n=harig@59.90.71.35)
# [08:21] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) ("bye")
# [08:23] * Joins: nessy (n=nessy@115.130.39.71)
# [08:25] * Joins: heycam (n=cam@dyn-130-194-69-204.its.monash.edu.au)
# [08:27] * Joins: tantek (n=tantek@70.36.139.128)
# [08:33] * Quits: heycam (n=cam@dyn-130-194-69-204.its.monash.edu.au) ("bye")
# [08:35] * Joins: heycam (n=cam@dyn-130-194-69-204.its.monash.edu.au)
# [08:42] * Joins: dave_levin_ (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net)
# [08:43] <hsivonen> the deadlock discussion makes me think NPAPI lets plug-ins do too many things
# [08:43] * Quits: heycam (n=cam@dyn-130-194-69-204.its.monash.edu.au) ("bye")
# [08:44] * Quits: nessy (n=nessy@115.130.39.71) (Success)
# [08:45] * Joins: heycam (n=cam@dyn-130-194-69-204.its.monash.edu.au)
# [08:45] * Joins: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl)
# [08:50] <hsivonen> mpilgrim: Are you intentionally giving your readers the impression that Geolocation is an HTML5 feature?
# [08:53] <hsivonen> mpilgrim: I see the Q & A now
# [08:54] <boblet> mpilgrim: the position of the Canvas API support statement below the illustration made me think the illustration was done via Canvas. Also you’re using “HTML 5”, but I assume that’s intentional. Other than that informative and looks great
# [08:56] <hsivonen> Hixie: even mpilgrim isn't using <figure>/<legend> yet. Maybe we really need to change the <legend> part to <c> or something
# [08:57] <hsivonen> mpilgrim: Video for Everybody! requires authors to use a soon-to-be-royalty-bearing format
# [08:57] <Hixie> hsivonen: i really don't understand what the rush is
# [08:58] <Hixie> hsivonen: i wasn't expecting anyone to use 90% of this stuff for another decade
# [08:58] <hsivonen> Hixie: is using <legend> instead of <c> worth the wait?
# [08:58] <Hixie> yes
# [08:58] <cardona507> another decade?
# [08:59] <hsivonen> Hixie: for what benefit? avoiding the minting of another element
# [08:59] <hsivonen> Hixie: when you then go ahead and mint stuff like <dialog>
# [09:00] <Hixie> hsivonen: <c> is a dumb name. <legend> is the exact right name.
# [09:00] <hsivonen> mpilgrim: congrats for figuring out the codecs parameters for H.264
# [09:01] <hsivonen> mpilgrim: unfortunately, they are unlikely to be correct for video that your readers might encode
# [09:01] <hsivonen> profiles and AVC levels FTW!
# [09:03] * Joins: Hish_ (n=chatzill@212.23.139.152)
# [09:03] * Hish_ is now known as Hish
# [09:03] * tantek thinks <dialog> is a dumb name for a conversation, and there's scant data to legitimize a misconceived offhand informative example from HTML4 (dt/dd for conversations).
# [09:04] <Hixie> tantek: is zeldman done collecting the feedback from his blog commenters yet? :-)
# [09:05] <hsivonen> why does this stuff look like COM instead of looking like JS or even Java? http://www.forum.nokia.com/infocenter/index.jsp?topic=/Web_Developers_Library/GUID-4DDE31C7-EC0D-4EEC-BC3A-A0B0351154F8.html
# [09:07] <MikeSmith> the think I like the least about it <dialog> is that its addition causes the semantics of the <dt> and <dd> elements to change drastically depending on what their parent element is. which seems like very suboptimal language design.
# [09:07] <Hixie> MikeSmith: why?
# [09:08] <hsivonen> Hixie: are you planning on saying anything about cruft in SVG subtrees?
# [09:08] <MikeSmith> Hixie: because elements should have consistent semantics unless there's some really good reason for them not too
# [09:08] <Hixie> hsivonen: dunno, what's the question?
# [09:09] <othermaciej> are there other cases in HTML where semantics change significantly based on the parent element?
# [09:09] <Hixie> MikeSmith: why?
# [09:09] <hsivonen> Hixie: whether the cruft should be conforming despite being bogus
# [09:09] <othermaciej> I would say semantics of <li> change depending on the parent
# [09:09] <Hixie> hsivonen: sounds like an SVG issue, why would I say anything?
# [09:09] <othermaciej> it's a list item in both <ul> and <ol>, but in the latter case it implies an ordering position
# [09:09] <MikeSmith> Hixie: because it's easier for authors
# [09:09] <hsivonen> Hixie: you caused the cruft to become non-conforming per SVG
# [09:10] <hsivonen> Hixie: before you did your thing, SVG was coherent on this particular point
# [09:10] <tantek> Hixie - why do you think inconsistency in element semantics is a good thing?
# [09:10] <Hixie> MikeSmith: i don't really buy that. i don't think authors have problems with that. what makes you think they do?
# [09:10] <Hixie> hsivonen: oh you mean in text/html?
# [09:11] <hsivonen> Hixie: right
# [09:11] <othermaciej> whether it's due to SVG or HTML, someone should define it
# [09:11] <othermaciej> so it doesn't become one of those gap-between-the-spec things
# [09:11] <Hixie> hsivonen: the text/html parsing just generates a DOM, the conformance criteria apply after that, just as if you'd created an equivalent DOM using the DOM API.
# [09:11] <Hixie> tantek: i don't think it's inconsistent.
# [09:12] <othermaciej> right now I think conformance of SVG in text/html is not clearly defined
# [09:12] <hsivonen> Hixie: right, so there's demand for a definition of "bogus but conforming" that defines no-namespace attributes with a colon in their local name bogus but conforming on http://www.w3.org/2000/svg elements
# [09:12] * Joins: ifette (n=ifette@220.109.219.244)
# [09:12] <Hixie> on a completely different topic, how does the UA know which private key is associated with a certificate it gets back after the server has taken the public key created by <keygen> and turned it into a client cert?
# [09:12] <MikeSmith> othermaciej: I don't think the case of <li> is comparable. it's still an item in a list, it just happens to be two different types of lists. whereas in the case of <dialog>, <dt> and <dd> become something else completely
# [09:12] <hsivonen> Hixie: and http://www.w3.org/2000/svg elements with a colon in their local name as bogus but conforming
# [09:12] <Hixie> hsivonen: i have no intention of making any bogus things conforming.
# [09:12] <tantek> MikeSmith - agreed
# [09:13] <othermaciej> MikeSmith: I'm wondering whether there are other examples
# [09:13] <Hixie> hsivonen: (unless there are compelling use cases that need that, like with the <br/> nonsense or the xmlns="" nonsense)
# [09:13] <othermaciej> MikeSmith: besides, arguably, <legend>, but that's also new in HTML5
# [09:13] <hsivonen> Hixie: do you find the SVG WG's use cases compelling?
# [09:13] * Joins: pesla (n=retep@procurios.xs4all.nl)
# [09:14] <Hixie> hsivonen: i have no idea what their use cases are. I'm assuming from the way you're talking that there's some thread i haven't read yet that is all about this.
# [09:14] <othermaciej> Hixie: the compelling use case here is pasting output from Inkscape into an HTML document without having to do a great deal of postprocessing first
# [09:14] * Quits: cying (n=cying@adsl-75-18-225-53.dsl.pltn13.sbcglobal.net)
# [09:14] <othermaciej> (well, arguably compelling)
# [09:14] <MikeSmith> othermaciej: I can't think of any offhand. Not only can't I think of comparable examples in HTML, I can't think offhand of any in other markup vocabularies either
# [09:14] <hsivonen> Hixie: what othermaciej said. IIRC, copying and pasting from Inkscape is part of the SVG WG's use cases
# [09:15] <Hixie> hsivonen: inkscape litters its documents with bogus content?
# [09:15] <hsivonen> Hixie: it sprays junk all over
# [09:15] <othermaciej> MikeSmith: well in this case, HTML4 already gave <dt> and <dd> both sets of semantics
# [09:15] <hsivonen> Hixie: really tedious to remove in a text editor
# [09:15] <Hixie> hsivonen: well that sucks
# [09:16] <Hixie> hsivonen: i'd recommend asking the inkscape guys to have an html-mode output that doesn't do taht.
# [09:16] <hsivonen> Hixie: IIRC, Inkscape has a clean output mode already
# [09:16] <Hixie> we don't need _more_ tag soup
# [09:16] <MikeSmith> othermaciej: how so?
# [09:16] <Hixie> hsivonen: oh
# [09:16] <Hixie> hsivonen: well then
# [09:17] <Hixie> hsivonen: problem solved
# [09:17] <hsivonen> Hixie: the use case in taking stuff someone else saved in Inkscape and copying that
# [09:17] <hsivonen> Hixie: from a clip art library
# [09:17] * Quits: ifette_GOOG (n=ifette@220.109.219.244) (Read error: 145 (Connection timed out))
# [09:17] <hsivonen> Hixie: or a Free content repository
# [09:18] <othermaciej> MikeSmith: http://www.w3.org/TR/html401/struct/lists.html#h-10.3
# [09:18] <othermaciej> "Another application of DL, for example, is for marking up dialogues, with each DT naming a speaker, and each DD containing his or her words."
# [09:18] <Hixie> hsivonen: so basically the proposal is to make certain cases of xml output from certain tools conforming but not support other cases of xml output from other tools?
# [09:18] <othermaciej> MikeSmith: HTML5 just removes that application of DL and assigns it to DIALOG
# [09:19] <tantek> othermaciej - that's false. HTML4 only gave dt and dd one set of *normative* semantics - definition terms and definitions.
# [09:20] <othermaciej> tantek: is the sentence I quoted a false statement of fact in the HTML4 spec, then?
# [09:20] <hsivonen> Hixie: the idea is to bless the cruft that's already in SVG/XML in Wikimedia Commons, etc. as stuff you can copy and paste without a flurry of errors
# [09:20] <othermaciej> (assuming it's not a conformance criterion)
# [09:20] <Philip`> Inkscape has two different modes for saving SVG, one with loads of extra editor-specific data and one without - is the idea that both formats should be copy-and-pastable?
# [09:20] <tantek> the conversation nonsense came from an *informative* example that was nothing more than a mistake - someone misusing semantic elements for their presentational effect
# [09:20] <Hixie> tantek and I are like two priests both with our own interpretation of a really vague holy text
# [09:21] * Quits: johnk_ (n=johnk@cpe-69-205-56-47.nycap.res.rr.com) (Read error: 54 (Connection reset by peer))
# [09:21] <othermaciej> tantek: the sentence I quoted is not backed by an example
# [09:21] <hsivonen> Philip`: yes, because stuff exported in the wrong mode is already out there as potential source to copy
# [09:21] <Hixie> hsivonen: i'd recommend just coallescing the errors into one, but from what you've said it doesn't sound like something we'd want to make conforming.
# [09:21] <othermaciej> tantek: I'd believe it was a mistake, but it does not seem any more or less normative than the rest of the DL/DT/DD definition
# [09:21] <hsivonen> Hixie: I can try that
# [09:22] <hsivonen> Hixie: but it won't make users happy
# [09:22] <hsivonen> Hixie: so what's the point?
# [09:22] <tantek> othermaciej the key phrase there is ", for example," == informative
# [09:22] <othermaciej> hsivonen, Hixie: another claimed use case is foreign namespace content that bears the copyright notice and license for the content, and cannot legally be removed
# [09:22] <Hixie> tantek: if you read html4 literally, 99% of the spec is non-normative and you're left with very little worth talking about.
# [09:23] <hsivonen> othermaciej: I think that use case is based on a faulty interpretation of the CC licenses
# [09:23] <tantek> Hixie - also not true - and I submitted a test suite with methodology to prove it.
# [09:23] <Hixie> othermaciej: parsing an xml file as text/html removes the copyright notice.
# [09:23] <hsivonen> othermaciej: the syntax no longer expresses a license anyway if you paste it to text/html
# [09:24] <Hixie> tantek: your methodology was "let's make up some rules about how to get normative statements from this spec, then pretend the spec had said those were the rules"
# [09:24] <hsivonen> othermaciej: thus, syntax looking like RDF/XML isn't appropriate for the text/html medium
# [09:24] <Hixie> hsivonen: the point is making sure that authors say what they think they are saying
# [09:24] <othermaciej> hsivonen: what would be the legal way to paste an SVG containing a license or copyright notice in foreign namespace content into a text/html document?
# [09:25] <tantek> Hixie - the rules were not "made up", they were constructed based on asking the Editor what was intended by the language used.
# [09:25] <Hixie> tantek: the editor is not a normative source.
# [09:25] <tantek> othermaciej - if you believe it is a mistake, then you should oppose <dialog> in HTML5
# [09:25] <othermaciej> hsivonen: replace with a faithful plain text representation?
# [09:25] <hsivonen> othermaciej: IANAL, but writing the copyright notice and license legend in plain text next to the SVG island
# [09:25] <hsivonen> othermaciej: possibly embellished with microdata
# [09:26] <tantek> and that portion of the DL/DT/DD description is ", for example, " which makes it less normative
# [09:26] <Hixie> tantek: and whether you made them up or the editor made them up doesn't change that they were made up, from the perspective of them not being in the spec.
# [09:26] <othermaciej> tantek: I don't have the information at hand to determine with any certainty whether it was a mistake
# [09:26] <tantek> Hixie - the editor is the source of the language of the spec, including "MUST", "SHOULD" etc., and "this section is normative" etc. thus, the editor *is* a normative source.
# [09:26] <othermaciej> tantek: but whether it was a mistake or not doesn't seem to impact the usefulness of <dialog> (I am pretty agnostic about it)
# [09:26] <Hixie> tantek: no, sorry. that's not how it works.
# [09:26] <othermaciej> hsivonen: presumably you could also put it in plain text in a comment or inside <metadata>
# [09:27] * Joins: foolip (n=philip@pat.se.opera.com)
# [09:27] <tantek> Hixie, simple contradiction ("that's not how it works") is not an argument.
# [09:27] <Hixie> tantek: nor is stating that it is how it works, as you are doing :-)
# [09:27] <hsivonen> othermaciej: does SVG allow text children there?
# [09:27] <othermaciej> hsivonen: but that's a tricky manual step, and it becomes a matter of legality, not just authoring tool leftovers
# [09:27] <hsivonen> othermaciej: one might argue that comments are devoid of semantics
# [09:28] <tantek> Hixie - I did not state "how it works", I explained with reasoning why the editor's use of language is normative or informative - that's part of the editor's job in writing up a spec.
# [09:28] <hsivonen> othermaciej: well, we aren't going to make the entirety of RDF/XML work just because so people thought it was a great idea to use RDF/XML for licensing data
# [09:28] <othermaciej> hsivonen: comments are indeed devoid of semantics, but I don't think that makes them an invalid copyright notice
# [09:28] <hsivonen> s/so/some/
# [09:29] <Hixie> tantek: the intent of the person writing teh spec is irrelevant to what the spec means. Only the spec, and what the spec references normatively, are relevant. Unless the spec says that a human can override it, no human can override it.
# [09:29] <othermaciej> hsivonen: I agree that it would probably be unwise to make it "work", at least in the sense of parsing it in the intended namespaceful way, along with other foreign namespaces
# [09:29] <Hixie> tantek: some specs do say that, e.g. the rules for Munchkin explicitly defer to the owner of the game to resolve rules disputes.
# [09:29] <Hixie> tantek: HTML4 does not. It claims various things about itself, like use of RFC2119, and doesn't mention any editor as being some final arbiter of meaning.
# [09:30] * hsivonen wonders if RSS is like Munchkin
# [09:30] <Hixie> tantek: therefore the only correct way to interpret HTML4's normative meaning is to read it and its references and not to make up (or have the editor make up) post-hoc rationalisations about the text of the spec.
# [09:31] <Hixie> tantek: now as it happens, html4 is so poorly written than a literal reading is a futile exercise, as i mentioned
# [09:31] <Hixie> tantek: and it's quite possible that a pragmatic reading with the editor's advice is a more _useful_ undertaking
# [09:31] <tantek> Hixie - indeed, I think that is a good summary of the differences of our readings of HTML4
# [09:31] <Hixie> tantek: but that is quite irrelevant when it comes to the point of establishing the pedantically precise normative Truth that can be determined from HTML4.
# [09:33] <Hixie> hopefully html5 doesn't have this issue and nobody will later come and say "hey ian, what's normative?" and require that i answer in a way that isn't just pointing to the answer.
# [09:33] <tantek> but is pedantically precise normative truth more important, or what browsers actually implement, or what authors actually publish, or ... ?
# [09:33] <tantek> Hixie - HTML5 will have errors, it is inevitable.
# [09:33] <Hixie> sure, but nothing as eggregious as html4, i hupe
# [09:33] <Hixie> hope
# [09:33] <tantek> In fact, given how big HTML5 is, there is a much higher chance it will have errors than HTML4 did/does.
# [09:33] <tantek> have (more) errors
# [09:33] <Hixie> i'm sure it'll have more errors too
# [09:33] <Hixie> but a thousand typos is nothing compared to not having a normative statement about pretty much anything :-)
# [09:34] <Hixie> anyway, what matters is what legacy content intended, and to that end I've ignored HTML4 completely in writing HTML5
# [09:34] <Hixie> (much to Julian's dismay)
# [09:34] <othermaciej> does the definition of <dl> in HTML4 include any of the Tantek-extended normativity keywords?
# [09:34] <othermaciej> (I can't remember what they were)
# [09:35] <othermaciej> also, does anyone actually use <dl> for marking up conversations (thereby indicating a need for some more suitable way to do so)?
# [09:36] <tantek> othermaciej - http://www.w3.org/MarkUp/Test/HTML401/current/assertions/prologue.html
# [09:37] <tantek> which is part of http://www.w3.org/MarkUp/Test/HTML401/current/assertions/assertions_toc.html
# [09:37] <tantek> referenced by http://www.w3.org/MarkUp/Test/HTML401/current/htmltestdocumentation.html
# [09:38] <othermaciej> tantek: does "is" count as a case of "are"?
# [09:38] <tantek> which is the documentation for http://www.w3.org/MarkUp/Test/HTML401/current/
# [09:42] <tantek> othermaciej - I believe that's what the documentation was saying, but perhaps could have been more explicit and included all forms of a verb rather than just an illustrative form.
# [09:42] <tantek> othermaciej - also note that the "Another application of DL, for example..." sentence is in the context of a sequence of *informative* examples
# [09:42] <tantek> "Here is an example:" ...
# [09:42] <tantek> "Here is an example with ..."
# [09:42] <tantek> "Another application of DL, for example..."
# [09:43] <tantek> hence the reasonable informative treatment of that text
# [09:43] <tantek> as all examples are informative
# [09:43] <tantek> whether described as "here is an example" or "for example"
# [09:44] * Quits: Super-Dot (n=Super-Do@adsl-75-61-83-64.dsl.pltn13.sbcglobal.net)
# [09:45] <othermaciej> tantek: it seems there isn't any normative definition of DL at all using your extended keywords
# [09:46] <othermaciej> the only verbs applied to it are "vary" and "consist"
# [09:47] <tantek> othermaciej - not true, there are several testable assertions derived from normative text regarding DL, see Assertions 10.3-1 through 10.3.1-3 here: http://www.w3.org/MarkUp/Test/HTML401/current/assertions/assertions_section10.html
# [09:48] <tantek> sorry - make that *two* testable assertions
# [09:48] <tantek> Assertion 10.3-1 and 10.3-2
# [09:48] <tantek> (regarding DL)
# [09:48] * Quits: benward (n=benward@98.210.154.133) ("Sleep")
# [09:48] <othermaciej> tantek: the one you expressed as an "author must" doesn't actually use any of the key verbs
# [09:48] <tantek> "must" is already a key RFC2119 word
# [09:48] <tantek> "are required"
# [09:49] <tantek> = "must"
# [09:49] <othermaciej> the only verbs in it are "vary", "consist", "give" (in passive voice), "restrict" (in passive voice) and "contain"
# [09:49] <othermaciej> I mean Assertion 10.3-2
# [09:50] <othermaciej> I think you'd have to be psychic to know that sentence is normative, but the one about marking up dialogues is not
# [09:50] <tantek> yes - I think that's evidence that we used "is" as normatively as "are"
# [09:50] <tantek> othermaciej - not at all, "for example" = informative
# [09:51] <Hixie> othermaciej: psychic, or willing to apply out-of-band information obtained from the person who wrote the spec
# [09:51] * Joins: maikmerten (n=maikmert@Zb250.z.pppool.de)
# [09:51] <othermaciej> so you're saying "is" used as an auxiliary verb for a passive voice verb indicates normativity, but not if the sentence includes the words "for example"?
# [09:51] * Joins: harig_ (n=harig@59.90.71.35)
# [09:51] <tantek> othermaciej - right - anything of an "example" nature is informative.
# [09:51] <othermaciej> but all passive voice verbs are normative
# [09:52] <othermaciej> while active voice ones are not, unless they are on the special list
# [09:52] <othermaciej> but you also includes this sentence in the assertion, which doesn't have any of the magic words, even as auxiliary verbs: "Definition lists vary only slightly from other types of lists in that list items consist of two parts: a term and a description."
# [09:53] <tantek> othermaciej - that sentence was included for context so the following normative sentences would make sense.
# [09:53] * lazni1 is now known as lazni
# [09:53] <tantek> it's not its own assertion
# [09:54] <tantek> (judging *what* to quote from the spec for each assertion was certainly a challenge)
# [09:54] * Joins: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
# [09:55] <othermaciej> so if that second sentence said "the DT element gives the term" instead of "the term is given by the DT element" it would not be normative?
# [09:55] <hsivonen> tantek: the first assertion (at http://www.w3.org/MarkUp/Test/HTML401/current/assertions/assertions_section05.html) shouldn't be marked (author) if one assumed the spec writer used the SGML concept of "document character set" correctly
# [09:55] <hsivonen> tantek: since the SGML concept is always Unicode for HTML
# [09:56] <tantek> othermaciej - we would have had to have made the term "gives" explicitly normative as well, though in hindsight, should have anyway given it's use with "is".
# [09:56] * Joins: ifette_GOOG (n=ifette@220.109.219.244)
# [09:57] <hsivonen> It's also interesting that "User agents must also know the specific character encoding that was used to transform the document character stream into a byte stream" is annotated as (author) when the sentence says what UAs must do
# [09:57] <tantek> hsivonen - I think you're right. you may have found the first bug in the testable assertions. well done.
# [09:57] <othermaciej> here is a sentence using "may" that contains "for example": "For example, using CSS, one may specify that the style of numbers for list elements in a numbered list should be lowercase roman numerals."
# [09:57] <othermaciej> is that non-normative?
# [09:58] * Hixie wonders how "user agents must know [...]" is supposed to be implemented
# [09:58] <tantek> othermaciej - yes that's non-normative, and should be in the HTML spec, as the HTML spec doesn't normatively define what CSS does or does not do.
# [09:58] <tantek> that's common for cross-spec/functionality references
# [09:59] <tantek> (using informative language so as to not potentially invalidate the normative language in another spec)
# [09:59] <tantek> (key for good spec modularity)
# [09:59] <othermaciej> it seems like most uses of "for example" are true statements of fact
# [10:00] <othermaciej> but I guess that one for dl has to be either normative or false
# [10:00] <tantek> othermaciej - most "informative" statements are true statements of fact. that doesn't make them normative.
# [10:00] * othermaciej likes the RFC keyword system a lot better
# [10:00] <tantek> othermaciej - indeed.
# [10:01] <Philip`> If you made the term "gives" explicitly normative, presumably you'd still have to apply some other non-normative interpretation to cases like "Using external (linked) style sheets gives you the flexibility to change the presentation without revising the source HTML document"
# [10:01] <othermaciej> although there still doesn't appear to be a normative definition of DL itself, even if DT and DL are not
# [10:01] * Joins: ROBOd (n=robod@89.122.216.38)
# [10:02] <othermaciej> it seems like the following sentence with "for example" introduces a genuine SHOULD/RECOMMEND-level requirement: "In the absence of more sophisticated behavior, for example tailored to the needs of a particular script or language, we recommend the following behavior for user agents"
# [10:02] <tantek> othermaciej - unfortunately the only normative definition of DL is that it must have a start and end tag per Assertion 10.3-1 :/
# [10:02] <tantek> othermaciej "we recommend" is actually non-normative
# [10:03] <tantek> per http://www.w3.org/TR/html401/conform.html
# [10:03] <othermaciej> as distinct from "recommended"?
# [10:03] <tantek> "At times, the authors of this specification recommend good practice for authors and user agents. These recommendations are **not normative**
# [10:03] <boblet> re: now-completed discussion of <dialog> and <dl>, would <dialog> be used for marking up a theatrical play or IRC log? if so what about non-actor dialog, such as stage directions and joined/left etc announcements?
# [10:03] <tantek> **emphasis adde**
# [10:03] * Quits: harig (n=harig@59.90.71.35) (Read error: 110 (Connection timed out))
# [10:03] * Hixie updates his registration for TPAC to point out he now has clashes with not three, but four working groups on the first two days
# [10:03] <tantek> "These recommendations contain the expression "We recommend ...", "This specification recommends ...", or some similar wording.
# [10:03] <tantek> "
# [10:04] <Lachy> hsivonen, the solution to the RDF/XML looking stuff (and other useless metadata) within <metadata> in SVG is to simply comment it out if the author thinks it can't physically be removed from the image
# [10:04] <tantek> and "we recommend ... (the following)" is exactly what quoted text says
# [10:04] <Philip`> "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]." sounds like it conflicts with that
# [10:05] <tantek> Philip`: "RECOMMENDED" is not the same as "we recommend"
# [10:05] <othermaciej> boblet: <dialog> could be used for such purposes in theory, but in practice its content model is not suitable for expressing anything but the conversation itself, so stage directions, join/leave messages, IRC /me actions, etc could not be properly marked up in <dialog>
# [10:05] <Philip`> Oh, I missed the "ED"
# [10:05] <tantek> more good reasons to dump <dialog>
# [10:06] * Hixie thinks if <dialog> is popular, we should just add <ds> or whatever to cover that case
# [10:06] <hsivonen> Lachy: that's not a solution to the inkscape cruft
# [10:06] <tantek> Philip` - yes, the distinction ("ED") is too subtle and prone to error in reading.
# [10:06] <Hixie> but that's a problem for a future spec
# [10:06] <Lachy> hsivonen, I know
# [10:06] <Lachy> the solution to that is to have them stripped out by a simple post processor
# [10:06] <othermaciej> does anyone actually currently mark up conversations with <dl>? or in any other distinct and idiomatic way?
# [10:07] <othermaciej> that's the relevant question to me, not what HTML4 may or may not have meant
# [10:07] <hsivonen> Lachy: having anything but textual copy and paste defeats the SVG WG's use cases
# [10:07] <tantek> othermaciej - ordered list, with cite for the speaker and q for the utterance, e.g.: http://rbach.priv.at/Microformats/IRC/2009-08-28
# [10:08] <Hixie> (<cite> for speaker contradics html5's statements about <cite> btw)
# [10:08] <boblet> othermaciej: that’s what I thought. I think authors would potentially find it confusing to decide whether to use method A or B if there are two approved ways for marking up a conversation (depending on whether it contains non-actor content)
# [10:08] <tantek> Hixie - your HTML5 defintion of <cite> contradicts existing usage. Ergo the HTML5 definition of <cite> should change to conform to existing usage.
# [10:08] <Lachy> hsivonen, that's not a problem unless you think their use case deserves addressing, which I don't. The more we can encourage authors to strip useless cruft from markup, the better
# [10:08] <tantek> especially since that usage is permitted in HTML4
# [10:09] <Hixie> tantek: actually, research indicates that <cite> for people is used far less than for other things, and is in fact used less than, say, <cite> for italics, or <cite> for the sake of it with no good semantic use.
# [10:09] <hsivonen> Lachy: I think telling authors not to type cruft is a worthwhile thing to do. Telling them to remove cruft, no so much.
# [10:10] <Lachy> what's the difference?
# [10:10] * Philip` likes how HTML5 lets him extract stuff like http://philip.html5.org/tests/canvas/suite/spec.yaml where there's an explicit "must" statement for most test cases
# [10:10] <Hixie> tantek: i actually disagree that html4 allows <cite> for people, but my reading of html4 is at odds with other people's, so i'm not going to argue that point
# [10:10] <Hixie> tantek: except to point out yet again that html4 is ungodly vague.
# [10:10] <MikeSmith> othermaciej: I think Jonas's message on <dialog> from a while back was meant to make the case that there's little evidence of anybody actually using <dl> for dialogs
# [10:11] * MikeSmith looks in the list archive
# [10:11] * Quits: ifette (n=ifette@220.109.219.244) (Read error: 110 (Connection timed out))
# [10:11] <hsivonen> Lachy: the difference is that the first case saves time and the latter wastes it
# [10:11] <heycam> i haven't been paying attention to the conversation just now, but for the point about conformance of SVG DOM subtrees created from parsing text/html documents, i'm sure we could add some wording in svg's conformance appendix about that
# [10:11] <tantek> Hixie, research indicates that <cite> is used for people far more than <dt> is
# [10:11] <tantek> therefore you should drop <dialog>
# [10:11] <tantek> and fix <cite> accordingly
# [10:11] <Hixie> othermaciej: (per tantek's rules, is "Contains a citation or a reference to other sources" normative?)
# [10:11] <heycam> currently conformance is markup focussed rather than dom focussed
# [10:12] <othermaciej> heycam: I think that would be a reasonable approach
# [10:12] <Hixie> tantek: <dialog> wasn't added because of high usage
# [10:12] <tantek> Hixie - doesn't matter
# [10:12] <heycam> but we could add something about say converting the dom to markup and then determining the conformance based on that
# [10:12] <Hixie> tantek: it kinda does
# [10:12] <tantek> if you want to be consistent in your methodology
# [10:12] <othermaciej> heycam: it does seem that conformance of SVG (at least for 1.1) is ultimately defined in terms of the source text, if you chase all the normative references
# [10:12] <heycam> othermaciej, right
# [10:12] <hsivonen> heycam: in this case, the DOM is not serializable as XML
# [10:12] <heycam> hsivonen, you're talking about the metadata rdf stuff?
# [10:13] <heycam> i guess i'm just worrying about the general issue
# [10:13] <Hixie> tantek: my methodology is not blind adherence to a single principle, it's a very broad set of principles that encompass far more than just usage.
# [10:13] <hsivonen> heycam: that and the inkscape cruft
# [10:13] <heycam> of defining document conformance
# [10:13] <tantek> you should prefer <cite> for people rather than <dt> for people (in conversations)
# [10:13] <othermaciej> hsivonen: you could apply the infoset coercion rules first, but that would certainly result in documents that are not conforming SVG
# [10:13] <Hixie> tantek: why?
# [10:13] <tantek> btw reference to broader request for cite: http://www.zeldman.com/superfriends/guide/#cite
# [10:13] <boblet> Actually it’d be great if there was a quasi-official coding patterns reference (how to mark up a play script etc). Perhaps a section in the Wiki at some stage?
# [10:13] <heycam> well, to be honest, text/html doesn't support xml namespaces -- so if you've got some elements in there with colons in them, you're going to produce invalid text/html imo
# [10:13] <Hixie> tantek: actually, for <cite>, if you want that changed, please respond to the relevant thread in whatwg recently
# [10:13] <hsivonen> othermaciej: true, but it would be the resulting spec text incomprehensible to authors
# [10:13] <Hixie> tantek: since it was discussed to death there already
# [10:14] <Lachy> hsivonen, it's not a waste of time to produce cleaner markup
# [10:14] <Lachy> it makes working with the markup easier
# [10:14] <Hixie> tantek: is zeldman done collecting the feedback from his blog commenters yet btw?
# [10:14] <tantek> and requesting of dropping of dialog: http://www.zeldman.com/superfriends/guide/#dialog
# [10:14] <heycam> but i guess it could be in line with allowing xmlns="" talismans to allow rdf stuff to not be unconforming
# [10:14] <othermaciej> heycam: that was hsivonen's interpretation of the de facto reality, but apparently that would make a great deal of existing SVG produce errors when pasted into text/html
# [10:14] <Hixie> tantek: send that feedback to the list if you want it to get a reply
# [10:14] <heycam> othermaciej, yeah, given a lot is produced by inkscape and inkscape outputs the extra stuff
# [10:14] <tantek> Hixie - will do, was merely citing it here for the benefit of connecting the discussions for the logs.
# [10:15] <Lachy> and makes subsequent copy/pasting by other authors easies by not having to ignore so much useless cruft
# [10:15] <Lachy> *easier
# [10:15] * heycam has to leave, but i'll raise an issue with the svg wg about the "conformance of a dom" thing
# [10:15] <Hixie> i found http://www.zeldman.com/2009/09/04/html5-redefines-footer/ somewhat ridiculous, btw. claiming credit for something that had nothing to do with him.
# [10:15] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
# [10:15] <Hixie> and not even apologising when called on it
# [10:15] <heycam> s/i'll/he'll/ if i want to get my pronouns right :)
# [10:16] * Quits: heycam (n=cam@dyn-130-194-69-204.its.monash.edu.au) ("bye")
# [10:17] <hsivonen> so, it looks like I can express all tree operations as an opcode and three pointers
# [10:17] <hsivonen> if I bake the element namespace into the opcode
# [10:17] <hsivonen> yay for namespaces complicating my work again
# [10:18] * Quits: cardona507 (n=cardona5@c-67-180-160-250.hsd1.ca.comcast.net)
# [10:18] <Lachy> Hixie, it's understandable why he thought he played a part in it. The timing of when they first published their feedback, and when you dealt with older feedback on the same issue, was very coincidental
# [10:19] <Hixie> Lachy: sure, but he didn't correct it or anything when it was pointed out that it was in fact a coincidence
# [10:19] <othermaciej> Hixie: since you did what he wanted, it doesn't seem very important whether you did it because you listened to him (as he thought) or due to similar feedback from others (as was actually the case)
# [10:19] <takkaria> hsivonen: hm, why are you expressing tree operations as opcodes?
# [10:19] <othermaciej> he didn't actually directly claim that it was *because* of his request, though the justaposition implies that
# [10:20] <hsivonen> takkaria: to put their identity on a heap-allocate queue as opposed to having direct on-stack method calls
# [10:20] <Hixie> othermaciej: it grates on me that someone would claim to be contributing and claiming credit for it (whether implicitly or not) when they have in fact not done so, because it takes away from the credit that the real contributors should be getting
# [10:20] <hsivonen> *allocated
# [10:20] <Hixie> othermaciej: we have literally hundreds of people who have actually contributed, and they deserve the credit that he's taking
# [10:21] <hsivonen> takkaria: the tree building algorithm runs independently of the tree operations actually happening
# [10:21] <boblet> Hixie: I actually think that the coincidental timing is a good thing, as it’s going to both encourage more people to get involved (increased perception they can contribute), and hopefully to do so in a constructive way (some of the feedback has been backed up by more than personal opinion)
# [10:21] * Quits: shepazu (n=schepers@adsl-221-74-58.rmo.bellsouth.net) (Read error: 104 (Connection reset by peer))
# [10:21] <takkaria> hsivonen: ah, interesting
# [10:21] <takkaria> hsivonen: I'm guessing this is for off-main-thread parsing?
# [10:21] <hsivonen> takkaria: yes
# [10:21] <Hixie> hsivonen: how many opcodes? If your pointers are aligned, and if you don't have many opcodes, you might be able to encode the opcodes in the LSBs of the pointers, for extra obfuscation. :-)
# [10:21] * Joins: shepazu (n=schepers@adsl-221-74-58.rmo.bellsouth.net)
# [10:22] <othermaciej> Hixie: well, the spec has acknowledgements, I guess if you wanted to give more credit you could cite people who gave relevant feedback in commit messages
# [10:22] <hsivonen> takkaria: although I already had a setup like this in order to batch notifications so that the CSS frame constructor didn't run after every tree operation
# [10:22] <Hixie> othermaciej: i do, sometimes. but the commit messages aren't going to get the exposure his claims are.
# [10:22] <othermaciej> but I suppose I should stay away from getting in the middle of the Leibniz-Newton priority dispute here
# [10:23] <Hixie> yeah
# [10:23] <Hixie> me too
# [10:23] <Hixie> i'm not going to make a fuss over it or anything
# [10:23] <Hixie> it just grates me
# [10:23] * Joins: benward (n=benward@98.210.154.133)
# [10:23] * Hixie might be overly protective of the spec's contributors :-)
# [10:23] <Philip`> othermaciej: "cite people"? I thought that wasn't allowed :-p
# [10:24] <hsivonen> Hixie: 19 opcodes so far
# [10:24] <othermaciej> I think I am one of the few people that is not offended by Zeldman's high level of self-esteem
# [10:24] <hsivonen> Hixie: will have a few more
# [10:25] <Hixie> hsivonen: if your pointers are aligned to 4-byte boundaries, you get 2 bits per pointer, right? with 6 bits you can have 64 opcodes.
# [10:25] <Hixie> hsivonen: (btw this is the worst idea ever unless you expect to have bazillions of these flying about)
# [10:26] <hsivonen> Hixie: seems like a premature optimization, but I'll keep it in mind
# [10:26] <Hixie> (your pointers might well be aligned, though, especially if they're coming out of an arena as i expect they are)
# [10:26] <Hixie> yeah like i said, it's a horrible idea :-)
# [10:26] <hsivonen> Hixie: they come out of jemalloc
# [10:26] <tantek> Hixie - your comment on Zeldman's post seems to explain the situation clearly enough. I'm not sure what you're objecting to. Anyone who reads the post and comments will see the details you note and given that no-one is arguing with you, accept them.
# [10:27] <Hixie> hsivonen: no idea what that is
# [10:27] <othermaciej> it's a custom malloc implementation borrowed from FreeBSD
# [10:28] <othermaciej> on modern systems you can always expect any pointer that comes from an allocator to be at least 4-byte aligned, and likely 8-byte aligned if the allocation is at least 8 bytes in size
# [10:29] <Hixie> yeah, i was just looking at the jemalloc source
# [10:29] <othermaciej> however, stuffing flags in the low bits of pointers should probably not be the first tool you reach for
# [10:29] <Hixie> indeed
# [10:29] <Hixie> more like the last tool
# [10:30] <hsivonen> now I have an opcode, three pointers and one integer
# [10:30] <othermaciej> (we do it sometimes in WebKit but only if we can prove the space saved is a singificant memory improvement)
# [10:30] <hsivonen> getting rid of the integer might actually be a small win
# [10:33] * Philip` thought malloc had to return at least 8-byte aligned, because you might potentially use it for storing doubles and (in practice) they ought to be 8-byte aligned, or something like that
# [10:35] <othermaciej> Philip`: yeah, but not for a 4-byte allocation, if malloc supports true 4-byte allocations
# [10:36] * Quits: dave_levin_ (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net)
# [10:37] <Philip`> Hmm, C99 seems to just say it is "suitably aligned so that it may be assigned to a pointer to any type of object and then used to access such an object ..."
# [10:38] <Philip`> but since *(double*)malloc(4) is always going to be undefined behaviour, I suppose that means it doesn't have to be double-aligned
# [10:39] <Philip`> (even though it is any type of object)
# [10:39] <Philip`> s/it/double/
# [10:48] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Remote closed the connection)
# [10:53] <Hixie> five points to the first person who can find me a page with a smallish table that one could imagine markup up using microdata where the items correspond to columns rather than rows
# [10:54] * Joins: heycam (n=cam@210-84-56-211.dyn.iinet.net.au)
# [10:54] <Hixie> and one point for each error that anyone can find in any of the files in http://damowmow.com/playground/microdata/
# [10:55] <Lachy> Hixie, what's the value of these points you're offering?
# [10:55] <Hixie> they're each worth one point
# [10:55] <Lachy> hah
# [10:56] <Lachy> can we exchange them for prizes if we get enough?
# [10:58] <Hixie> with each other? sure
# [10:59] <Lachy> <p>Taken on <time itemprop="http://flickr.com/ns/pubdate" datetime="2009-07-21T00:00-00:00">July 21, 2009</time>.</p>
# [10:59] <Lachy> the datetime attribute doesn't need to have the time specified
# [10:59] <Lachy> just use datetime="2009-07-21"
# [11:00] * Joins: Phae (n=phaeness@gateb.mh.bbc.co.uk)
# [11:00] <Lachy> from http://damowmow.com/playground/microdata/001/flickr-annotated.html
# [11:01] * Joins: nessy (n=nessy@caffeine.cc.com.au)
# [11:02] <Lachy> also, <img itemprop="about" src="/photos/05108321.jpeg"> -- the image is missing
# [11:02] <tantek> indeed - and artificial precision is an anti-pattern (it implies data where there is none)
# [11:02] <tantek> (regarding not needing to specify the time)
# [11:02] <othermaciej> Hixie: http://www.sosmath.com/tables/trigtable/trigtable.html
# [11:03] <othermaciej> if you think of sin(x), cos(x) and tan(x) as the items
# [11:03] * Joins: annevk3 (n=annevk@5355732C.cable.casema.nl)
# [11:03] <ttepasse> Shouldn't be the rating in http://damowmow.com/playground/microdata/003/yelp-annotated.html a <meter>?
# [11:03] <Hixie> Lachy: for the purposes of this study, i'm defining the datetime pattern as being the full datetime
# [11:03] * Joins: Chris_Wilson (n=cwilso@nat/microsoft/x-oraxwmtgxuvclydy)
# [11:03] <Hixie> Lachy: just so there's less to explain
# [11:03] <tantek> Hixie, why?
# [11:03] <Hixie> othermaciej: thanks
# [11:04] <Hixie> tantek: based on advice from our usability expert that each additional aspect of complexity makes the data harder to analyse
# [11:05] <Lachy> Hixie, but requiring authors to add a meaningless and incorrect time to a time stamp, or some random date when they only want a time, makes things more complex
# [11:05] <Hixie> ttepasse: yeah i'm trying to keep it to html4 as much as possible
# [11:05] <Hixie> Lachy: good point. i'll make it be a specific time.
# [11:05] <Lachy> unless you make sure that there are no dates without times or times without dates in any of the examples used
# [11:06] <Lachy> how many points is that worth? :-)
# [11:06] <tantek> Lachy's experience is with authors agrees with mine.
# [11:06] * Quits: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
# [11:06] <tantek> s/is with/with
# [11:06] <Hixie> i agree that in the actual html5 spec we should make it possible for an itemprop="" to have as values either a date, time, or datetime
# [11:07] <Hixie> (though god knows what that does to the rdf conversion)
# [11:08] <Hixie> Lachy: that was 12 points, i think, based on the edits i had to do. :-)
# [11:09] <Lachy> woo hoo!
# [11:09] <Hixie> RE: the missing images, they're all missing
# [11:09] <Hixie> not sure if we'll provide images or not on the day
# [11:09] <othermaciej> if I am due 5 points then I think I must decline to avoid the appearance of bribery
# [11:09] <Lachy> Hixie, also, requiring authors to specify a day when they only have a year and month, is equally wrong, and is why the spec should be more flexible with allowing less specific dates
# [11:09] * Parts: nessy (n=nessy@caffeine.cc.com.au) ("Leaving")
# [11:10] * Joins: nessy (n=nessy@caffeine.cc.com.au)
# [11:10] <ttepasse> Making meter/@value a possible microdata-value as in time/@datetime would be also too complex, wouldn't it?
# [11:10] <Hixie> ttepasse: for the study? yeah, i don't want to go there for the study.
# [11:11] <ttepasse> In general.
# [11:11] <Hixie> ttepasse: might make sense to add to the language, though
# [11:12] * Quits: ChrisWilson (n=cwilso@nat/microsoft/x-smupmvtpzfdurjlb) (Read error: 110 (Connection timed out))
# [11:13] * Joins: webben (n=benh@nat/yahoo/x-ysetcwnphhfevwlx)
# [11:14] * Joins: zcorpan (n=zcorpan@c83-252-193-59.bredband.comhem.se)
# [11:14] <hsivonen> http://stackoverflow.com/questions/1350741/html5-0-canvas-textfield
# [11:17] <othermaciej> ick
# [11:17] <Hixie> how horrifying
# [11:18] <tantek> Lachy agreed: http://www.zeldman.com/superfriends/guide/#time
# [11:20] <Hixie> Lachy: i don't understand the use cases for exposiing only a year and a month. Do calendars even support that? I didn't see anything like that in the iCal format.
# [11:21] <hsivonen> tantek: what's your use case for exposing imprecise dates in a machine-readable format?
# [11:22] <hsivonen> tantek: that is, I see why you might want to write only year and month on a Web site but why do those need to be machine-readable?
# [11:22] * Quits: zcorpan (n=zcorpan@c83-252-193-59.bredband.comhem.se) (Read error: 104 (Connection reset by peer))
# [11:23] * Quits: erikvvold (n=erikvvol@96.49.192.204)
# [11:23] <hsivonen> tantek: what apps actually support month-precision events in calendaring?
# [11:23] <hsivonen> tantek: oops. sorry. I misread the superfrieds doc. nothing to see here.
# [11:24] * hsivonen confused Lachy's case and Super Friends' case
# [11:25] <tantek> hsivonen - I've seen far fewer examples in the wild of month-precision "dates". Until I find sufficiently representative real world examples to justify a request, I'm withholding that specific request.
# [11:26] <tantek> I would not be opposed to such an enhancement, but I don't think I can justify one myself.
# [11:26] <hsivonen> tantek: the Super Friends date use cases do look a bit Semantic Webby, though
# [11:26] <tantek> hsivonen - no triples here, move along. ;)
# [11:27] <othermaciej> extracting birthdays without a year sounds plausible
# [11:27] <othermaciej> and years without a day are indeed common on historical timelines
# [11:28] <Hixie> google has shown that to do a timeline you don't need explicit markup
# [11:28] <annevk3> not really
# [11:28] <hsivonen> othermaciej: in the latter case, it seems Semantic Webby that timeline data and timeline creators would arise on that level of coupling
# [11:28] <hsivonen> othermaciej: as opposed to Wikipedia-specific tools
# [11:28] <annevk3> Google places my about page in 1986
# [11:29] <annevk3> as news article, last I checked
# [11:29] <Hixie> annevk3: you think relying on authors to get markup right is going to be any better overall? :-)
# [11:29] * Quits: lazni (n=lazni@118.71.168.26) ("Leaving.")
# [11:30] <othermaciej> hsivonen: I have a hard time gauging what is realistic in terms of extracting data from web pages
# [11:30] <annevk3> mpilgrim, you should do the s/HTML 5/HTML5/ thingie as well
# [11:31] * Joins: zcorpan (n=zcorpan@c83-252-193-59.bredband.comhem.se)
# [11:31] * Hixie doesn't understand why people care about that space
# [11:31] <ttepasse> http://en.wikipedia.org/wiki/July_Crisis would be an example for yyyy-mm.
# [11:31] <Lachy> Hixie, so you're saying that sites that want to do timelines incorporating vague moments in time, like YYYY-MM without a day, can do so, but are excluded from taking advantage of the <time> element?
# [11:32] <Hixie> not just vague moments in time
# [11:32] <Hixie> any timelines
# [11:32] <hsivonen> Lachy: the time element is not for intra-site timelines
# [11:32] * Joins: lazni (n=lazni@123.16.224.114)
# [11:32] <hsivonen> Lachy: <time> implies that you crawl someone else's content and build a timeline out ofthat
# [11:33] <Philip`> Google News Timeline associates http://www.developerfusion.com/event/8137/the-last-mile-html-5-websockets-comet-free-event-with-jonas-jacobi/ with 01 January 1999 even though there's actually a correct machine-readable hCard date on the page
# [11:33] <Hixie> lachy: i'm saying <time> is intended to allow calendar events to be marked up, to allow Atom feeds to be generated from HTML pages, and nothing else
# [11:33] <hsivonen> Bugzilla uses MySQL data for bug trend graphs. It doesn't scrape its own HTML output.
# [11:33] <Hixie> Lachy: (because nothing else has had a compelling argument made for it)
# [11:34] * Quits: nessy (n=nessy@caffeine.cc.com.au) ("This computer has gone to sleep")
# [11:34] <tantek> Hixie, Google has shown you can create a *lossy* timeline without explicit markup - just like nearly all "entity recognition"
# [11:34] <hsivonen> people love to think up semantics and then invent use cases for the semantics. After all, we've been taught that Semantics are Good.
# [11:35] <tantek> hsivonen people love to think up APIs and then invent applications for the APIs.
# [11:35] <tantek> no difference
# [11:36] <tantek> semantics are just really simple APIs
# [11:36] <tantek> and they enable applications
# [11:36] <tantek> shared semantics enable portable applications
# [11:36] <Hixie> tantek: you can't create anything better than a lossy timeline even with markup, because of the error rate in authoring
# [11:36] <hsivonen> I could buy the argument that including all Porter–Duff operations is a matter of completeness instead of solid use cases for each one
# [11:36] <tantek> Hixie - nope. there are tons of problems with entity recognition. false positives etc.
# [11:37] <Hixie> tantek: you can only get higher fidelity if you have a controlled environment, at which point you can just use microdata/microformats/rdfa/whatever and don't need explicit support from html itself.
# [11:37] <Lachy> Hixie, what about, for example, the list that Opera maintains internally of upcoming web related conferences? That often lists events which are known to be held in a certain month, but the exact date has yet to be decided.
# [11:37] <tantek> Hixie - artificial dichotomy
# [11:37] <Hixie> tantek: your argument assumes that authors can write markup correctly, which is false
# [11:37] <Hixie> Lachy: what about it?
# [11:37] <hsivonen> Lachy: does iCal support that kind of data? where do you intent to import the data?
# [11:38] <tantek> Hixie - tons of microformats on the web show plenty of data that authors can write markup correctly enough.
# [11:38] <ttepasse> Hixie, not all applications deals with Googles scales and Googles possibilities. More often than not it's just a script, scraping data of a small part of the interweb.
# [11:38] <Lachy> it just seems like you're imposing unnecessary restrictions
# [11:38] * Joins: webben_ (n=benh@nat/yahoo/x-reaqtfrkuoncerru)
# [11:38] <hsivonen> Lachy: do you want to be the one who implements per-month events in iCal and Outlook for HTML compat?
# [11:39] <Hixie> tantek: well then authors can write microformats better than they can write html, in which case, again, use microformats, not html, to solve this problem.
# [11:39] <tantek> Lachy - worse than just "unnecessary", but in contradiction of existing publishing patterns.
# [11:39] <tantek> Hixie, <time> is *supposed* to be an improvement upon the way we markup dates and times in microformats.
# [11:39] <Hixie> tantek: no, it's not
# [11:39] <tantek> at least, last time I read HTML5 it said that.
# [11:39] <Hixie> tantek: <time> is supposed to be a way to give a date to iCal and Atom convertors. that's all.
# [11:40] <tantek> and those use cases came from hCalendar and hAtom
# [11:40] <othermaciej> that seems like a pretty narrow set of use cases
# [11:40] <Lachy> Hixie, time was inspired by the abuse of <abbr> in microformats
# [11:40] * Quits: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)