/irc-logs / w3c / #html-wg / 2007-06-15 / end

Options:

# Session Start: Fri Jun 15 00:00:01 2007
# Session Ident: #html-wg
# [00:05] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [00:05] * Parts: hasather_ (hasather@80.203.71.22)
# [00:10] * Joins: gavin_ (gavin@74.103.208.221)
# [00:22] * Quits: kingryan (rking3@208.66.64.47) (Client exited)
# [00:23] * Joins: kingryan (rking3@208.66.64.47)
# [00:35] * Quits: myakura (myakura@124.102.34.244) (Quit: Leaving...)
# [00:39] * Joins: mjs (mjs@17.255.96.220)
# [00:52] * Quits: Sander (svl@71.57.109.108) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [01:05] * Quits: heycam (cam@203.214.95.190) (Ping timeout)
# [01:34] * Quits: kingryan (rking3@208.66.64.47) (Client exited)
# [01:34] * Joins: kingryan (rking3@208.66.64.47)
# [01:37] * Quits: zcorpan_ (zcorpan@84.216.42.238) (Ping timeout)
# [01:50] * Quits: kingryan (rking3@208.66.64.47) (Quit: kingryan)
# [02:01] * Joins: karl (karlcow@128.30.52.30)
# [02:12] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [02:17] * Joins: gavin_ (gavin@74.103.208.221)
# [02:18] * Joins: heycam (cam@130.194.72.84)
# [02:47] * Joins: kingryan (rking3@64.81.240.149)
# [02:50] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Quit: Leaving)
# [03:12] * Quits: jmb (jmb@81.86.70.47) (Ping timeout)
# [03:13] * Quits: deltab (deltab@82.46.154.93) (Ping timeout)
# [03:14] * Quits: jgraham (jgraham@81.86.223.179) (Ping timeout)
# [03:14] * Joins: jmb (jmb@81.86.70.47)
# [03:15] * Joins: deltab (deltab@82.46.154.93)
# [03:16] * Quits: Philip` (philip@80.177.163.133) (Ping timeout)
# [03:17] * Joins: Philip` (philip@80.177.163.133)
# [03:17] * Joins: jgraham (jgraham@81.86.223.179)
# [03:18] * Joins: sbuluf (gtrutqb@200.49.140.173)
# [03:53] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
# [04:00] * Quits: Philip` (philip@80.177.163.133) (Ping timeout)
# [04:02] * Quits: mjs (mjs@17.255.96.220) (Ping timeout)
# [04:17] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
# [04:19] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [04:24] * Joins: gavin_ (gavin@74.103.208.221)
# [05:00] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [05:02] * Quits: sbuluf (gtrutqb@200.49.140.173) (Ping timeout)
# [05:02] * Joins: sbuluf (qitywph@200.49.140.173)
# [05:05] * Joins: gavin_ (gavin@74.103.208.221)
# [05:11] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [05:11] * Joins: hyatt (hyatt@24.6.91.161)
# [05:42] * Quits: hyatt (hyatt@24.6.91.161) (Quit: hyatt)
# [05:48] * Joins: Zeros (Zeros-Elip@69.140.48.129)
# [06:05] * Joins: Sander (svl@71.57.109.108)
# [06:16] * Joins: hyatt (hyatt@24.6.91.161)
# [06:43] * Quits: hyatt (hyatt@24.6.91.161) (Client exited)
# [06:44] * Joins: hyatt (hyatt@24.6.91.161)
# [06:48] * Quits: hyatt (hyatt@24.6.91.161) (Quit: hyatt)
# [06:52] * Joins: mjs (mjs@64.81.48.145)
# [06:55] <karl> http://savmaxru.livejournal.com/41476.html
# [06:55] <karl> negative comment about HTML 5.0
# [06:56] * mjs has had more than enough negative comments this week
# [06:58] <karl> mjs: I can imagine
# [06:59] <karl> welcome to the Win world
# [06:59] <mjs> it's... exciting
# [07:04] <karl> :)
# [07:08] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [07:09] <karl> though if you want mjs, there is also W3C employee. It is nice to receive negative comments as well :)
# [07:13] * Joins: gavin_ (gavin@74.103.208.221)
# [07:14] <mjs> karl :-)
# [07:38] * Quits: dbaron (dbaron@63.245.220.242) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [08:02] * Joins: zcorpan_ (zcorpan@84.216.43.161)
# [08:23] * Quits: Sander (svl@71.57.109.108) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [08:27] * Quits: Zeros (Zeros-Elip@69.140.48.129) (Ping timeout)
# [08:30] * Joins: Zeros (Zeros-Elip@69.140.48.129)
# [08:44] * Joins: tH_ (Rob@83.100.255.229)
# [08:44] * tH_ is now known as tH
# [08:48] <karl> http://www.nttdocomo.co.jp/english/service/imode/make/content/html/index.html
# [08:48] <karl> Specifications for i-mode compatible HTML and instructions on how to make websites for i-mode with HTML.
# [08:48] <karl> http://www.nttdocomo.co.jp/english/service/imode/make/content/xhtml/index.html
# [08:48] <karl> Specifications for i-mode compatible XHTML and instructions on how to make websites for i-mode with XHTML.
# [08:50] <karl> interesting
# [08:50] <karl> list of pictograms supported in imode
# [08:50] <karl> http://www.nttdocomo.co.jp/english/service/imode/make/content/pictograph/basic/index.html
# [08:53] <karl> http://www.nttdocomo.co.jp/english/service/imode/make/content/html/outline/s1.html#1_7
# [08:53] <karl> 1.7. i-mode compatible HTML 7.0
# [08:54] <karl> http://www.nttdocomo.co.jp/english/service/imode/make/content/html/about/
# [08:54] <karl> i-mode websites use subsets of HTML 2.0, 3.2, 4.0 and 4.01.
# [08:54] <karl> · Shift_JIS character encoding must be used. Images should be in the GIF format.
# [08:54] <karl> · Scripting languages are not supported.
# [08:54] <karl> · Half-size kana characters can be used.
# [08:55] <karl> lists of tags supported
# [08:55] <karl> http://www.nttdocomo.co.jp/english/service/imode/make/content/html/tool.html
# [08:55] <karl> i-mode HTML Simulator
# [08:56] <karl> http://www.nttdocomo.co.jp/english/service/imode/make/content/html/tool2.html
# [08:56] <karl> i-mode HTML Simulator II
# [08:56] <karl> http://www.nttdocomo.co.jp/english/service/imode/make/content/html/about/object_machi.html
# [08:57] <karl> http://www.nttdocomo.co.jp/english/service/imode/make/content/machi_chara/index.html
# [08:57] * MikeSmith didn't know until now that Docomo had published all those docs in English ...
# [08:58] <anne> Hmm, internet with a capital I huh...
# [08:58] <anne> I guess I can fix that
# [08:59] * anne doesn't like uppercasing for no reason
# [09:00] * karl wonders if Anne Van Kesteren has been hurt by an uppercase letter when he was young ;)
# [09:01] <anne> that's a perfect example of uppercasing where it's wrong
# [09:01] <anne> :)
# [09:02] <karl> hehe
# [09:02] * anne mumbles something about "Anne van Kesteren" en "sir Van Kesteren"
# [09:02] <karl> yes I heard about uppercasing issues and addressbooks
# [09:02] <karl> http://www.nttdocomo.co.jp/english/service/imode/make/content/xhtml/chart/index.html
# [09:02] <karl> Interesting chart
# [09:03] * Joins: Philip` (philip@80.177.163.133)
# [09:04] <karl> Deco Mail tags list
# [09:04] <karl> http://www.nttdocomo.co.jp/english/service/imode/make/content/deco_mail/tag/index.html
# [09:06] * Quits: zcorpan_ (zcorpan@84.216.43.161) (Ping timeout)
# [09:08] * Joins: zcorpan_ (zcorpan@84.216.43.161)
# [09:15] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [09:20] * Joins: gavin_ (gavin@74.103.208.221)
# [09:29] * Joins: edas (edaspet@88.191.34.123)
# [09:30] <karl> http://www.molly.com/2007/06/14/defy-the-pedantic-semantic-html5-and-xhtml-11-must-stop-for-now/
# [09:30] <karl> HTML5 and XHTML 1.1+ MUST Stop for Now
# [09:31] <anne> heh
# [09:31] <anne> the reason we have HTML5 is that XHTML1 and HTML4 can't be implemented reasonably
# [09:32] <karl> just replied
# [09:32] <anne> plus of course the threat of the plugin web
# [09:32] <karl> http://www.molly.com/2007/06/14/defy-the-pedantic-semantic-html5-and-xhtml-11-must-stop-for-now/#comment-476456
# [09:33] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
# [09:35] <mjs> wow, I'm surprised to see that from Molly
# [09:35] <mjs> especially given her low level of participation in the standards process so far
# [09:35] <mjs> for HTML5
# [09:35] <mjs> which is, I think, almost no participation
# [09:36] <anne> surprises me too
# [09:36] <anne> I thought I mentioned to her why we did HTML5...
# [09:38] <sbuluf> plugin web?
# [09:38] <sbuluf> as in flash, silverlight, etc?
# [09:39] <zcorpan_> sbuluf: yeah
# [09:39] * anne wonders what the other interpretation might be
# [09:40] <sbuluf> zcorpan, thanks
# [09:40] <sbuluf> anne, none, i just wanted to be sure of the meaning
# [09:40] <sbuluf> haven't seen people discussing such things here before
# [09:42] * Quits: Lachy (Lachlan@210.84.55.19) (Quit: This computer has gone to sleep)
# [09:44] * Joins: Lachy (Lachlan@210.84.55.19)
# [09:45] <sbuluf> i'm curious, in fact, in anyone cares to comment about it's significance
# [09:46] <zcorpan_> sbuluf: what do you mean?
# [09:46] <sbuluf> the significance of these things. their possible impact on the web, etc. the way things might evolve.
# [09:49] <zcorpan_> most videos and moving ads on the web today are made with flash
# [09:50] <zcorpan_> if <video> is implemented in relevant browsers that might change in the future
# [09:50] <sbuluf> so media, in general, is one of the possible battlefields
# [09:51] <zcorpan_> yes
# [09:51] <sbuluf> what about textual content?
# [09:53] <zcorpan_> html is already used for textual content
# [09:54] <sbuluf> is there people doing whole sites in flash, including textual content?
# [09:55] <anne> sure
# [09:56] <sbuluf> does that amount effectively to a web fork?
# [09:56] <anne> see threat above
# [09:57] <sbuluf> i see, thanks
# [09:57] * Quits: zcorpan_ (zcorpan@84.216.43.161) (Ping timeout)
# [09:58] * Joins: zcorpan_ (zcorpan@84.216.43.161)
# [10:06] <sbuluf> very curious, this molly post, too. i'm not sure hot to interpret it.
# [10:07] <sbuluf> if i read it correctly, there seem to be four main paths, then (or five, if you count my crazy one)
# [10:07] <sbuluf> 1) molly: lav everything as it is, we can keep living with the old web
# [10:08] <sbuluf> 2) html 5: modify, keep back compat
# [10:08] <sbuluf> 3) xhtml: modify, break back compat
# [10:08] <sbuluf> 4) plugins: modify, go propietary
# [10:09] <sbuluf> s/lav/leave/
# [10:09] <Hixie> the problem with #1 is that the existing specs aren't implementable. 90% of what html5 is doing is fixing the existing specs so that they CAN be implemented
# [10:10] <sbuluf> i see
# [10:11] <sbuluf> i reckon it might be the position of quite a lot of pro webmasters, if they tend to reject what they see in html 5
# [10:11] <sbuluf> so a post somewhere explaining your point, hixie, might be in order. save quite a bit of misunderstanding
# [10:12] <Hixie> oh it's been explained enough. i don't think it really matters if molly is pro html5 or not, at the end of the day.
# [10:12] <Hixie> it's not going to slow down the rate of progress on the spec, nor its adoption in browsers.
# [10:12] <sbuluf> i see
# [10:12] <sbuluf> yes, i see
# [10:13] <zcorpan_> perhaps she will make people at MS ignore html5?...
# [10:13] <Hixie> i think the cause and effect is likely more the other way around
# [10:13] <mjs> what Molly says in practice amounts to "give Microsoft a veto on further innovation in core web standards"
# [10:13] <sbuluf> zcorpan, mjs, i see people in comments asking her if she says it as molly, or as microsoft
# [10:13] <mjs> I'm not sure if that is related to her being paid by them
# [10:13] <Zeros> Hixie, only it's usefulness
# [10:13] <mjs> but that would be the practical effect
# [10:14] <mjs> if anyone even cared what she said
# [10:14] <Hixie> Zeros: why would that depend on her opinion?
# [10:14] <Zeros> Hixie, I meant more to the comments about her slowing or stopping MS's adoption
# [10:15] <Hixie> Zeros: i don't understand then
# [10:15] <mjs> Microsoft's pace of adoption of HTML5 is unlikely to depend on her opinions too much
# [10:16] <Hixie> indeed
# [10:16] <mjs> however, if she wants to encourage them to work on something else, correct DOM Level 2 support (at least Core, HTML and Events) would be nice
# [10:16] <anne> she mentions in the comments that this is her personal opinion and has nothing to do with Microsoft's position
# [10:16] <anne> as I understand it she only works 30% of her time for them
# [10:16] <Zeros> well there we go
# [10:16] <mjs> I doubt anyone cares about them reading the HTML 4.01 entrails more closely
# [10:16] <Hixie> DOM Level 2 HTML is woefully inadequately specified, HTML5 fixes that. So if she wants interoperable DOM Level 2 support, HTML5 is basically a prereq.
# [10:17] <Hixie> hence my not understanding her position
# [10:17] <Hixie> nor particularly caring :-)
# [10:18] <mjs> I think she's more of a standards cheerleader than a standards expert
# [10:18] <sbuluf> would it count if we perceive her as representative of the big majority of standards caring webmasters?
# [10:19] <mjs> I think she's representative only of herself
# [10:19] <Hixie> my point is that it doesn't matter if people think we shouldn't do html5 yet
# [10:19] <mjs> unless she took some kind of opinion poll
# [10:19] <Hixie> it doesn't affect what happens to html5
# [10:19] <Hixie> people shouldn't use html5 yet
# [10:19] <Hixie> it's not ready
# [10:19] <sbuluf> hixie, true, i see your point
# [10:19] <Hixie> so it's fine if they don't want to use it yet
# [10:19] <Hixie> in fact it's positively good
# [10:20] <Zeros> Hixie, tell that to the /browser vendors/
# [10:20] <Hixie> tell what to the browser vendors?
# [10:20] <Hixie> all the browser vendors are working on html5
# [10:20] <Zeros> that HTML5 isn't ready yet
# [10:20] <Hixie> they know
# [10:20] <Zeros> If they add features in html5, and lots of people use it, they can never remove them
# [10:20] <Hixie> they're actively working on making it ready
# [10:20] <Hixie> that's how standards evolve
# [10:20] <Zeros> and then it's effectively frozen in the spec, even if someone suggests a different approach later
# [10:20] <Hixie> we can't write specs in a vacuum
# [10:21] <Hixie> we need experience
# [10:21] <mjs> sadly HTML doesn't have as good support for experimental versions of features as CSS
# [10:21] <mjs> Safari, Firefox and Opera have at least some willigness to fix early-stage implementation bugs to be per spec
# [10:21] <Zeros> Hixie, So if Opera implemented the old repeat model, and webkit did too, you'd be fine to just scrap the new one?
# [10:22] <Hixie> Zeros: the two aren't incompatible
# [10:22] <Hixie> Zeros: so there'd be no problem there
# [10:22] <Hixie> Zeros: but to give a better example, opera implemented parts of wf2 and found ways in which the spec needed to change, so we changed the spec.
# [10:23] <Hixie> Zeros: same with <canvas>, the spec changed to match what implementation experience told us to do
# [10:23] <Zeros> Hixie, It's one thing to implement it internally to figure things out with it, it's another to push it in a release version and ensure changes to the draft spec are impossible
# [10:24] <Zeros> it just submarines the entire spec process
# [10:24] <Hixie> you can only really find out how things work in reality with the web if you release it
# [10:24] <Hixie> we just have to take that into account
# [10:24] <mjs> there's tradeoffs both ways
# [10:24] <mjs> we can't wait the 5-10 years until HTML5 is done to improve HTML in browsers
# [10:25] <mjs> and it's impossible to perfect the spec in a vacuum, without implementation experience
# [10:25] <mjs> at some point, the rubber has to hit the road
# [10:25] <anne> you can't implement the whole thing in one go anyway
# [10:25] <anne> incremental development seems to work reasonably well
# [10:25] <Zeros> mjs, that was the whole point in breaking the spec into modules
# [10:25] <anne> modules are a pain for everyone
# [10:26] <mjs> Zeros: it sounds like a good idea, but it's hard to do in practice
# [10:26] <zcorpan_> if different browsers implement different things, people can't use them anyway :)
# [10:26] <Zeros> html5 takes steps backwards and makes a giant monolithic spec that may or may not change, it's a moving target that subject to browsers picking and choosing to implement whatever they want
# [10:26] <Hixie> modules don't work, just look at css3
# [10:26] <anne> Zeros, how's that a bad thing?
# [10:27] <anne> it makes the spec actually usable for everyone involved, as I see it...
# [10:27] <mjs> Zeros: step backwards from what?
# [10:27] <zcorpan_> how is "browsers picking and choosing to implement whatever they want" any different from modules?
# [10:27] <mjs> HTML 4.01 was monolithic
# [10:27] <mjs> XHTML 1.1 has modules but those modules are not in any way interesting implementation boundaries
# [10:27] <Zeros> anne, no, it means any one browser vendor can implement whatever they want as a market move and force everyone else to do it too, because they can *never* remove it now that it's used
# [10:28] <anne> yeah, that's how stuff works
# [10:28] <Zeros> And you guys complain that MS want's versioning information to deal with the bugs they can never remove
# [10:28] <Zeros> -'
# [10:28] <anne> that's why we have XMLHttpRequest, offsetWidth, etc.
# [10:28] <Hixie> mjs: XHTML 1.1 was not in any way interesting, full stop. :-)
# [10:29] <anne> Zeros, the differences is that we, by means of Hixie, document our extensions so other people can implement them too, and allow feedback on the proposed features from the community
# [10:29] <mjs> Hixie: what do you mean? it makes it way easier to make profile specs that needlessly fragment the web
# [10:29] <Zeros> anne, then versioning information should be just as acceptable honestly. If you expect to implement whatever you want and make everyone else follow when you cry out "we can't remove it now, people use it", the same should extend to MS.
# [10:29] <anne> lots of things in HTML5 have been shaped by comments from contributors
# [10:29] <mjs> you don't think that's a valid use?
# [10:30] <Hixie> mjs: it doesn't actually define anything!
# [10:30] <mjs> Hixie: you're so picky
# [10:30] <anne> Zeros, how is <!doctype html> not enough again?
# [10:30] * anne ponders
# [10:31] <anne> and I don't think much of HTML5 is _that_ frozen
# [10:31] <Hixie> Zeros: versioning the way IE suggests is bad for two reasons -- first of all nothing gets documented (we document our mess, microsoft propose to leave each "non-current" version as an undocumented mass of frozen bugs), and second it means a massively increasing amount of complexity for browser vendors, leading to the point where entering the market is prohibitive and you have a single monopolistic browser instead.
# [10:31] * Joins: heycam (cam@203.214.95.190)
# [10:32] <Zeros> Hixie, that's splitting hairs
# [10:32] <Hixie> if driving the market to a single vendor is "splitting hairs", i intend to continue splitting.
# [10:32] <Zeros> if you expect to implement whatever you want and others should follow because people use it now, then MS should be extended the same means by which to deal with their mess
# [10:32] <Hixie> microsoft is part of the same process as all the other vendors.
# [10:33] <Hixie> in fact microsoft's browser's bugs have had more impact on the HTML5 spec than any other browser.
# [10:33] <Zeros> Hixie, their mess is significantly more problematic
# [10:33] <Hixie> the spec goes through many contortions to be compatible with IE at the expense of other browsers much more than the other way around.
# [10:33] <mjs> Zeros: you can't just ask the browser vendors to stop innovating at all
# [10:33] <Hixie> "their mess" is our mess.
# [10:33] <Zeros> mjs, I didn't say that
# [10:33] <mjs> having a standards process framework in which to do it is a good thing
# [10:34] <mjs> saying the standards must not be implemented would just lead to browser innovation that is totally outside standards
# [10:34] <mjs> and that would clearly be worse
# [10:34] <mjs> it would leave us in the world of mutual reverse engineering
# [10:34] <Hixie> zeros: i don't really understand what the problem you are seeing is
# [10:35] <Zeros> mjs, oh, you mean like canvas? Which was implemented for a non web part of the OS, but in the browser, then duplicated in other browsers and finally approved?
# [10:35] <Zeros> of course any issues with canvas that dashboard requires can never be fixed if they're relied upon.
# [10:35] <mjs> Zeros: that's definitely an example of a worse way to do things than what we are trying to do for new safari features nowadays
# [10:36] <mjs> Zeros: and in fact, we made many <canvas> changes to match the spec that required weird workarounds for dashboard
# [10:36] <anne> yeah
# [10:36] <Zeros> mjs, like, special case behavior on dashboard?
# [10:36] <Zeros> heh
# [10:36] <anne> <canvas> didn't have a end tag for instance
# [10:36] <Zeros> this just proves my point
# [10:36] <mjs> for some we special cased it, for other things we just slightly broke widgets
# [10:36] <mjs> we do plan to phase out dashboard-specific quirks over time
# [10:37] <Zeros> If you had designed canvas and worked with the other browser vendors on it before hand you wouldn't have to work around the dependencies on older or broken behavior
# [10:38] <anne> you would have lost a lot of time
# [10:38] <mjs> yes, it would have been better to take it to standards earlier
# [10:38] <mjs> we are doing that more with new stuff
# [10:38] <Zeros> Hixie, Besides the fact that the whatwg is little more than a forum for the browser vendors to take ideas and then force them on others later?
# [10:38] <mjs> you may have noticed we sent a <video> / <audio> spec long before shipping anything
# [10:39] <Zeros> "oh we like this, lets implement it" "oh sorry your feedback doesn't matter anymore, we can't change that, Opera already implemented it and people use it"
# [10:39] <mjs> Zeros: it's a forum for browser vendors to collaborate with each other and to get design feedback from web standards experts and web developers
# [10:40] <Hixie> Zeros: i disagree with the premise of your description of the problem
# [10:40] <Zeros> that's okay :)
# [10:40] <Hixie> Zeros: it is not the case that browser vendors force anything on the other browser vendors
# [10:40] <Hixie> Zeros: all the browser vendors have in fact been very helpful in working together to coming to compromises that benefit everyone
# [10:41] <Hixie> Zeros: <canvas> being an excellent example of this
# [10:41] <Zeros> Hixie, of course it is. Hyatt has said more than once that they will not break compatibility with sites or applications that rely on their behavior. MS has said the same thing. I imagine Opera feels the same way.
# [10:42] <Zeros> So if they implement part of the spec that is still in flux, or that may be changed later, it can't be changed in any way that would break the existing implementation
# [10:42] <anne> depends on how much it is used
# [10:42] <anne> you phrase things like they are absolutes, they are not
# [10:42] <Hixie> Zeros: that's why it's important to move fast -- so that we get things nailed down before the sites that would break become widespread
# [10:43] <Hixie> Zeros: for example, we fixed <canvas> before yahoo started using it on yahoo pipes
# [10:43] <Hixie> Zeros: now, yahoo pipes uses it and there are parts of <canvas> we can therefore no longer change
# [10:43] <Zeros> and now that they did it can never change
# [10:43] <Zeros> even though the spec isn't done, even though html5 is still a draft, it can never change
# [10:43] <Hixie> i don't see this as a problem
# [10:44] <anne> and <canvas> can certainly still change
# [10:44] <Hixie> i just see this as the reality of how successful specs are developed
# [10:44] <Hixie> anne: parts of it can
# [10:44] <anne> clarifications and fixes have been made after Y! Pipes started using it
# [10:44] <anne> yeah
# [10:44] <Hixie> anne: other parts are indeed frozen now
# [10:44] <Zeros> Hixie, It means you can never fix bugs or change behavior that would break yahoo.
# [10:44] <Hixie> Zeros: yup
# [10:45] <Zeros> that is a problem
# [10:45] <Hixie> i disagree
# [10:45] <Hixie> the alternative is to work like the xhtml2 working group
# [10:45] <Hixie> which can always change anything
# [10:45] <Hixie> because nobody will ever use their spec
# [10:45] <Hixie> i'd rather have a sub-ideal spec that is widely used than an ideal one that nobody uses
# [10:45] <Zeros> every future version of html needs to perpetuate the bugs on past versions to remain compatible, and since people are jumping the gun, we're effectively baking in bugs forever.
# [10:46] <Hixie> that's why we have to move fast
# [10:46] <Hixie> to remove the bugs before the features are widely used
# [10:46] <Hixie> what <canvas> bugs do you think we are stuck with?
# [10:46] <sbuluf> both past and future bugs
# [10:46] <Hixie> what bugs of any kind do you think we are stuck with because of the html5 development model?
# [10:47] <Zeros> Hixie, I'm sure there were API changes that people wanted, issues that yahoo has worked around in current implementations
# [10:47] <Hixie> name them
# [10:47] <Hixie> name a single thing that we have been forced to keep against our will that we can't change
# [10:48] <Zeros> "Hixie anne: other parts are indeed frozen now"
# [10:48] <Zeros> so what can't change?
# [10:48] <anne> fillStyle, fillRect, etc.
# [10:48] <Zeros> and it's not against your will, since you just don't care
# [10:48] <anne> getImageData() and putImageData() prolly can
# [10:48] <Hixie> there are many parts of the spec we can't change, i just don't think that we _want_ to change them
# [10:49] <anne> Zeros, we don't care?!
# [10:49] <Hixie> the frozen parts of canvas are all pretty much as we want them to be
# [10:49] <Zeros> anne, you don't care that you can't change them, hixie doesn't think it's a problem at all
# [10:49] <anne> Zeros, because we think the spec is fine as is
# [10:49] <Hixie> Zeros: you're the one arguing this is a problem. Prove that it's a problem. Show us something we're stuck with because of the problem you describe. Just one thing.
# [10:50] <Zeros> Hixie, fillStyle, fillRect, every canvas API used anywhere
# [10:50] <Zeros> you can't change them
# [10:50] <Zeros> even if someone suggest a better way
# [10:51] <anne> ...
# [10:51] <anne> of course
# [10:51] <anne> that's the case with standards, no matter what development model you pick
# [10:51] <Zeros> Or the repeat model Hixie, If Opera implements it and can't remove it, then you can't make incompatible changes to it. You've boxed yourself into whatever they do.
# [10:51] <anne> once XHTML2 becomes rec, if someone comes up with a better way, you can't change it either
# [10:52] <Zeros> anne, yes, but at that point the spec is done. It's frozen, and parts are frozen as a whole. This is more like playdoh you periodically put a lighter to and make hard.
# [10:52] <anne> it's called incremental development
# [10:52] <anne> where parts of the spec are finished before others
# [10:53] <mjs> Zeros: are there parts you want to change?
# [10:53] <Zeros> anne, but not as logical chunks
# [10:53] <Hixie> Zeros: what development model do you suggest where you can always change the spec if someone comes up with a better way?
# [10:53] <mjs> or are you just concerned that someone hypothetically in the future will want to change them?
# [10:53] <mjs> the only way to keep that possibility open indefinitely is to never implement the spec
# [10:53] <sbuluf> unless a mechanism to guarantee forward compat can be perhaps found
# [10:53] <anne> Zeros, logical chunks?!
# [10:53] <Zeros> mjs, huh?
# [10:53] <Hixie> Zeros: with the repeat model, actually, we have an implementation, and we can change it anyway (nobody depends on it) and even if people depended on it, we could always add an entirely new system (as indeed is the plan)
# [10:54] * Joins: ROBOd (robod@86.34.246.154)
# [10:54] <anne> Hixie, does the new system allow for roughly the same things?
# [10:54] <Zeros> anne, Complete the canvas API, consolidate the feedback, review and if it's all good then freeze the whole thing and let everyone implement it the same.
# [10:54] <mjs> we're doing that incrementally
# [10:54] <mjs> as implementation and author adoption increase, the spec becomes more solid
# [10:54] <anne> I think doing it incrementally works way better
# [10:54] <mjs> at some point, fixing design flaws becomes harder
# [10:55] <mjs> but it is also less likely you will find any
# [10:55] <anne> freezing it before people have had some experience with implementing it and using it makes no sense whatsoever to me
# [10:55] <Zeros> anne, freezing it afterwards means any issues you run into are frozen into it.
# [10:55] <Hixie> anne: the new system is radically different (basically more similar to an xml version of xul templates (which used rdf)
# [10:55] <Hixie> )
# [10:56] <anne> Zeros, I expect you'd encounter those issues during implementation and the first few rounds of feedback
# [10:56] <Hixie> Zeros: in your system, what happens if after the whole thing has been frozen someone comes up with a better way?
# [10:56] <anne> Zeros, this has happened so far with most parts of the HTML5 spec that got implemented
# [10:56] <Zeros> anne, and that can't be done internally where the dependancy isn't placed on websites everywhere?
# [10:56] <anne> Hixie, I understood that, but does it cater for the same stuff?
# [10:56] <anne> Zeros, internally doesn't let the community play with it
# [10:56] <anne> I think that would be a bad thing
# [10:57] <Hixie> there is no "internally" with a public system like the whatwg
# [10:57] <Hixie> anne: yeah, same general area of stuff
# [10:57] <Zeros> Hixie, you misunderstood what I meant
# [10:57] <anne> besides, you never implement a whole spec in one go anyway
# [10:58] <Zeros> somehow I doubt apple is lacking QA and testing people, or Opera, or Mozilla, they don't need to push draft spec features onto the web when the spec is still changing.
# [10:59] <Hixie> Zeros: how is that different to what you propose? how do you get experience in your system if you don't let people play with the draft implementations?
# [10:59] <Hixie> where people = web developers at large
# [10:59] <Zeros> um, that doesn't follow
# [10:59] <Zeros> the same way Adobe gets feedback on PS, or MS gets feedback on Vista, or Apple gets feedback on Leopard.
# [11:00] <Zeros> You don't have to create huge dependancies on the web for incomplete features to test something
# [11:00] <Hixie> Microsoft got feedback on Vista by having public beta programmes
# [11:00] <Hixie> Apple gets feedback on Leopard by having public beta programmes
# [11:00] <Hixie> Vista is in fact a great example
# [11:01] <Hixie> software got written for Vista betas which forced Vista to implement certain APIs in particular ways
# [11:01] <Hixie> exactly the same way in which you are saying we should avoid having happen to HTML5
# [11:02] <Hixie> you didn't answer my question though
# [11:02] <Hixie> Zeros: in your system, what happens if after the whole thing has been frozen someone comes up with a better way?
# [11:03] <Zeros> nothing, the design is complete and other parts of the spec can use it as foundation.
# [11:05] <Zeros> Of course I guess since you're filtering feedback you just as well ignore changes that alter dependencies within the spec itself that would be awkward with frozen features
# [11:06] <Zeros> Hixie, it also allows vendors to implement systems in a linear manner which prevents unnecessary feature fragmentation
# [11:07] <mjs> vendors have different priorities
# [11:07] <mjs> and different opinions on what web developers want
# [11:07] <mjs> they tend to push each other along by what they implement
# [11:07] <Zeros> so how's Opera and FF3's text-shadow support?
# [11:08] <Hixie> Zeros: so what i don't understand is why you are ok with not being able to change the spec when you think the design is complete, but you are not ok with not being able to change a small part of the spec when that small part is complete.
# [11:09] <Hixie> Zeros: it isn't the spec development that prevents vendors from implementing the spec in a linear manner. just look at css2, which has been available for years and is still not fully implemented.
# [11:10] <Zeros> Hixie, no, it's the browser vendors. Of course guaranteeing interop might be reason enough.
# [11:10] <mjs> Zeros: I'm guessing they will be encouraged to implement those as more sites use it
# [11:10] <mjs> Zeros: in the meantime, the fact that it is only in Safari does little harm
# [11:12] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
# [11:13] <Zeros> I suppose
# [11:14] <Zeros> sbuluf, I don't think MS has anything to do with this
# [11:15] <anne> Your time is prolly better spend on suggesting improvements to the current APIs and text than to argue the process behind it
# [11:15] <Zeros> yeah that goes over real well
# [11:16] <anne> Just trying to remain realstic
# [11:16] <Zeros> Hixie wants research, only the research is only good enough if he thinks it is, which is an arbitrary metric.
# [11:17] <anne> You can always raise it with the chairs if you disagree I believe
# [11:18] <anne> Do you have some specific instance of where the above occured?
# [11:18] <Zeros> A single discussion with hyatt gets the repeat model changed, but lots of research for headers, lots of emails, examples, where screen readers use it, how they use it... still not enough.
# [11:18] <mjs> afaik neither has resulted in a change to the spec yet
# [11:19] <Zeros> Hixie still, after all that research into where the feature is currently implemented and used, doesn't think the argument is strong enough.
# [11:20] * Joins: Hixie (ianh@129.241.93.37)
# [11:21] <anne> Zeros, didn't Hixie say he would do his own research into it as well?
# [11:21] * anne isn't entirely convinced about making headers= conforming either. I do think it makes sense to include it in the UA algorithm
# [11:21] <Zeros> anne, maybe, because his personal research is apparently the one research that is good enough
# [11:22] <anne> I don't see what's wrong with trying to verify what others came up with
# [11:22] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [11:22] <Zeros> anne, then should hixie provide the means by which to verify his own research? :)
# [11:22] <Zeros> Of course he can't cite sources and make it duplicable. At least the headers research is documented.
# [11:23] <Zeros> And no matter how many times he scans the web, that ignores intranets and government sites that may utilize the feature, where he can't scan.
# [11:24] <mjs> the bottom line seems to be that Windows-Eyes, the second most popular screen reader, does not support scope=
# [11:24] <Zeros> I'd say that's particularly important to recognize for an accessibility feature.
# [11:24] <mjs> to make accessible content that hits the top two screen readers, you need headers= in your content
# [11:24] <mjs> it would be annoying if to do that you had to make your document nonconforming
# [11:25] <Zeros> yes
# [11:25] <mjs> (assuming, that is, that including headers= makes the content meaningfully more accessible in Windows-Eyes - I am sort of assuming that it does but I have not asked any blind users)
# [11:25] <hsivonen> mjs: I agree. Going forward, though, WindowsEyes should be seriously lobbied to do implied associations right to shift the burden away from page authors in the common case.
# [11:26] <mjs> hsivonen: I agree with that too
# [11:26] <hsivonen> fwiw, I already have conformance checking code that checks that headers points to <th>s in the *same* table
# [11:27] <mjs> that's another reason making headers conforming will be a benefit
# [11:27] <mjs> that way conformance checkers can tell you if you used it right
# [11:27] * Joins: gavin_ (gavin@74.103.208.221)
# [11:28] <mjs> it would be better if windows-eyes supported implicit associations and scope=""
# [11:28] <mjs> but I don't think we can just count on that happening soon enough
# [11:28] <anne> nonconforming or conforming doesn't make much sense anyway at this stage as HTML5 is far from finished
# [11:28] <anne> like 10 years
# [11:28] <anne> in those 10 years hopefully something will change
# [11:29] <Zeros> mjs, I'm curious what the discussion around start on ol was back when they created HTML4
# [11:29] <hsivonen> on the other hand, it is weird that the accessibility folks assume that AT is expensive and frozen but authoring tools can be updated at will to support whatever
# [11:32] <hsivonen> I wonder if the implicit association stuff had a better change in suggeeding if the browser DOM had a method for getting associated headers so that the AT vendors wouldn't have to implement the algorithms themselves
# [11:32] <Zeros> It would be lovely if html5 defined a document outline API and system for accessing the DOM in a unified way for readers.
# [11:32] <hsivonen> s/suggeeding/succeeding/
# [11:32] <Zeros> and accessibility devices in general
# [11:32] <mjs> hsivonen: a defined DOM method for gettiing associated headers would be kinda neat
# [11:33] <mjs> hsivonen: it would be useful for our VoiceOver integration at least, even if it isn't necessarily that useful for web apps
# [11:34] <anne> I wonder how expensive it is... Would it return a HTMLCollection?
# [11:34] <Hixie> the research that was done into headers="" was extremely good
# [11:34] <Hixie> i need to look at it in detail
# [11:34] <Hixie> it isn't clear to me yet that headers="" actually helps accessibility, i have ordered a copy of JAWS to determine that first hand
# [11:35] <mjs> Hixie: JAWS seems to do quite well even in the absence of any special markup on the table
# [11:35] <mjs> Hixie: Windows-Eyes seems to be the one that does a better job of finding headers with headers=""
# [11:35] <hsivonen> Hixie: I think headers='' should be kept around for compat and as a way to override the implicit association algorithm
# [11:35] <Hixie> in which case headers="" wouldn't necessarily be important for JAWS
# [11:36] <Hixie> mjs: yeah, i may have to order Windoes Eyes as well
# [11:36] <hsivonen> Hixie: I also think that for the general case headers='' has an awful placement of burden
# [11:36] <Hixie> though, despite popular belief, google isn't entirely made of money, and each $1000 purchase becomes harder to justify
# [11:36] <Hixie> hsivonen: it's clear that it isn't a good solution, sure. the question is whether it's useful to keep as an override at all.
# [11:37] <Zeros> So what research was done that justifies adding a sql api Hixie? :)
# [11:37] <mjs> Hixie: I'm glad that people finally did actual testing though!
# [11:37] <mjs> I was sick of hearing "screen readers don't support scope" with no supporting evidence
# [11:37] <Hixie> hsivonen: if we get rid of it, we can get rid of the accessibility people's recommendation to use it, which would probably significantly help accessibility just on its own
# [11:38] <Zeros> that's little more than an assumption
# [11:38] <hsivonen> Hixie: yeah, the main problem with keeping it around is how to get AT motivated to support the better stuff and how to get the accessibility advisors change their mantra once better AT is deployed
# [11:38] <mjs> Hixie: you could just promise to eat out for lunch for a month
# [11:38] <mjs> ;-)
# [11:39] <Hixie> Zeros: the google gears work was one of the biggest sources of experience for the sql feature; mozilla's experience with the storage APIs were also important. i also spoke to several other groups and companies about it to determine the requirements.
# [11:39] <Hixie> hsivonen: yeah
# [11:39] <Hixie> mjs: :-P
# [11:40] <mjs> hsivonen: I think informative Notes in the spec could strongly recommend implementation of scope and implicit header association, and indicate that headers="" is there for compat
# [11:40] <mjs> Zeros: Apple has also been internally experimenting with SQL storage for web apps
# [11:40] <Hixie> if it's there for compat only, it doesn't have to be compliant
# [11:40] <mjs> Zeros: though Gears is far ahead of anything we did
# [11:40] <Hixie> indeed, apple was one of the other groups i discussed this with
# [11:40] <Zeros> mjs, okay, good enough then.
# [11:41] <mjs> Hixie: for compat with user agents, not compat with content
# [11:41] * Quits: gorme (gorm@213.236.208.22) (Ping timeout)
# [11:41] <mjs> specifically, with Windows-Eyes
# [11:41] <Hixie> mjs: yeah
# [11:41] <Zeros> Is there a wiki with this stuff documented?
# [11:41] <Hixie> i really wish AT devs would join this group
# [11:41] <mjs> me too
# [11:41] <mjs> maybe we should ask them directly, or get DanC to ask them
# [11:41] <Zeros> It really would be nice if Hixie documented where the research was done and with whom (is there?)
# [11:42] <anne> there's no documentation
# [11:42] <anne> except for the mailing list
# [11:43] <anne> and prolly the IRC channel discussions
# [11:43] <Hixie> Zeros: i don't really have the time to do both the work and document the reasoning. I am certainly happy to informally give reasoning on IRC if someone is willing to then write it up.
# [11:43] <Hixie> so far nobody has volunteered for it
# [11:44] <Hixie> it'd be a full-time job
# [11:45] <Zeros> Maybe if I have some time I'll start going down each change in the spec (removed attributes, new tags, parsing features etc.) and write your responses as I go
# [11:46] <Hixie> the problem is that i have forgotten the reasoning for most things. you'd have to catch the reasoning as i do the changes, while it's still fresh on my mind.
# [11:47] <Zeros> I'd hope big changes you could remember, and changes in the spec itself would be in the svn logs
# [11:48] <Zeros> Like, what finally got you to decide predefined class names were a bad idea?
# [11:48] <Zeros> or rather, should be done better.
# [11:48] <anne> Zeros, would be cool if you researched it a little and feed it back into "HTML5 differences from HTML4"
# [11:49] <Hixie> Zeros: "finally"?
# [11:50] <Zeros> Hixie, there was a lot of discussion about it, I talked about it with you, lots of email, what issues were raised that made you change your mind?
# [11:50] <Hixie> Zeros: i put the idea in the spec, many months later i looked at the feedback on that feature, the feedback pointed out a number of fatal flaws with the idea, the use cases were handled in a different way and i removed the feature.
# [11:50] <Hixie> irc discussion has little effect in terms of the spec changing
# [11:50] <Zeros> I know
# [11:50] <Hixie> changes are caused by e-mails i save to my imap folder
# [11:50] <Zeros> What different ways were "warning" and "copyright" handled?
# [11:51] <Zeros> anne, yeah, notes attached to the differences document would be nice
# [11:51] <anne> and
# [11:51] <Hixie> the use cases that copyright tried to handle that were important enough to warrant handling are handled by
# [11:51] <Hixie> and "warning" seemed equally well handled by
# [11:51] <anne> Zeros, I covered some, but it's not really exhaustive at this point
# [11:52] <Zeros> anne, that's something I'd be willing to contribute to.
# [11:52] <Zeros> Hixie, okay, thanks
# [11:53] <Hixie> the key thing though is that it wasn't anything that "finally" made me change my mind
# [11:53] <Hixie> i looked at all the feedback as a whole, and changed the spec in response
# [11:54] <Hixie> it's not like i was pushing back on changing the spec for a long time or anything
# [11:54] <Hixie> i was just working on other things
# [11:54] <Zeros> ok
# [11:54] <Hixie> (same with headers="" now)
# [11:54] <Zeros> I don't think that's quite true
# [11:55] <Zeros> you've pushed back rather hard. Your response emails mention over and over again that you don't think it helps accessibility.
# [11:55] <Zeros> And you mentioned before that you think removing it would help accessibility
# [11:56] <Zeros> You're not just observing the feedback here, you're positioned on one side.
# [11:57] <Hixie> my "push back" is entirely intended to cause research to be done
# [11:57] <Hixie> it worked, fwiw
# [11:58] <Hixie> i do think, right now, that it probably hurts more than helps, but my opinion will change in an instant if the research shows that i'm wrong
# [11:58] <Hixie> i haven't looked at the research yet
# [11:58] <Hixie> at the end of the day, though, the key thing is to improve accessibility. if headers= improves it, then good, we should have it. if it doesn't, we shouldn't.
# [11:59] <Zeros> Why are you willing to compromise screen reader support and not browser support?
# [12:00] <Hixie> (i made similar comments regarding the class attribute and predefined classes while not working on that part of the spec, and again, it caused very articulate arguments to be put forward, allowing me to see the various sides of the discussion and make a good choice for the spec)
# [12:00] <Hixie> what user agents (screen readers) must do with headers="" will be defined in the spec regardless of whether headers="" is a conforming part of hte language for authors or not
# [12:01] <Zeros> ah
# [12:01] <Hixie> just like has been dropped from the conforming language but what browsers must do will still be defined
# [12:01] <Zeros> well then it'll be just like start on ol now
# [12:01] <Hixie> being an example of something we want to drop to improve accessibility
# [12:01] <Hixie> anyway i should go sleep. early meeting tomorrow.
# [12:01] <Zeros> have a good night
# [12:01] <Hixie> nn
# [12:02] <Zeros> thanks for the discussion :)
# [12:05] <MikeSmith> Hixie: Why not document the rationale for each change in the commit description you make for the change? ... I don't mean a lengthy rationale -- but something that will at least serve as a reminder for later (since you say you have now forgotten the reasoning for most things)
# [12:08] * Joins: gorme (gorm@213.236.208.22)
# [12:13] <MikeSmith> hsivonen - have you tried out oNVDL?
# [12:15] <anne> Zeros, start on ol is reintroduced for good reasons...
# [12:28] * Joins: mjs_ (mjs@64.81.48.145)
# [12:28] * Quits: mjs (mjs@64.81.48.145) (Connection reset by peer)
# [12:33] <hsivonen> MikeSmith: I haven't.
# [12:34] <hsivonen> MikeSmith: oops. I thought you said JNVDL
# [12:34] <hsivonen> MikeSmith: I'm using my own fork of oNVDL but I haven't tried the actual NVDL functionality
# [12:34] <hsivonen> MikeSmith: I'm just treating it as a maintained fork of Jing
# [12:34] <hsivonen> for the time being
# [12:35] <hsivonen> (and I'd love to get my changes in the main oNVDL distro, but my changes involve API changes that would further require changes in oXygen)
# [12:35] <MikeSmith> hsivonen - I remember now you saying that you were using oNVDL ... just got confused
# [12:36] <MikeSmith> Have you talked with George Bina?
# [12:36] <hsivonen> yes, he did not want those API changes (at least not in the release cycle phase he was in when I offered them)
# [12:37] <hsivonen> And I have to have those changes because I need them for security when my app takes untrusted schemas
# [12:37] * MikeSmith finds . -name "*onvdl*" => ./dependencies/onvdl-hsivonen/onvdl.jar
# [12:37] <MikeSmith> hsivonen - may be worthwhile to follow up with him again
# [12:37] * Quits: Zeros (Zeros-Elip@69.140.48.129) (Quit: Leaving)
# [12:38] <MikeSmith> George is usually very open and responsive to suggestions for changes and improvements
# [12:38] <hsivonen> MikeSmith: yeah, I should probably discuss this with him again
# [12:39] <MikeSmith> please do. I like oNVDL and would like to see it improve :)
# [12:39] <hsivonen> I also have a performance improvement for Schematron, but it doesn't fit James Clark's API assumptions, either
# [12:40] <MikeSmith> no surprised to hear that
# [12:40] <MikeSmith> James's code tends to be pretty idiosyncratic
# [12:40] <MikeSmith> and hard to extend on top of
# [12:42] <hsivonen> I made SAXON run in the main thread. but then I instantiate it differenly from what the Jing extension mechanism expects
# [12:43] <hsivonen> Or more to the point, I made it run in the main thread without needing a helper thread that was there previously
# [12:44] <MikeSmith> One thing I wanted to mention is that schema validation error messages from jing are often not particularly helpful -- or at least not as useful as they could be.
# [12:44] <MikeSmith> RNV, for example, provides better ones
# [12:44] <hsivonen> MikeSmith: I've noticed. And I have a plan.
# [12:44] <MikeSmith> hsivonen : good to hear :)
# [12:45] <MikeSmith> care to share that plan? or keeping it under wraps for now?
# [12:45] * Quits: inimino (inimino@75.71.88.233) (Ping timeout)
# [12:45] <hsivonen> MikeSmith: the plan is: 1) Hack oNVDL/Jing to expose DatatypeException messages and 2) make the error handler keep track of the current element and the parent and dump quotes from the spec for the relevant elements on a containment error
# [12:46] <hsivonen> the latter seems more useful for an HTML5 conformance checker than trying to make general-purpose improvements to Jing
# [12:47] <hsivonen> MikeSmith: does #2 make sense in your opinion?
# [12:49] <MikeSmith> hsivonen - wow. yeah, 2 seems like a great approach if you can make it work. fairly radical departure, but would be a much better help to most content authors than trying to decipher esoteric error messages
# [12:50] <MikeSmith> problem would be figuring out how much of the spec to quote
# [12:52] <MikeSmith> though perhaps a short snippet with a URI to full part of the spec where the element is defined?
# [12:53] * Quits: sbuluf (qitywph@200.49.140.173) (Ping timeout)
# [12:53] <hsivonen> I was thinking of the text under "Content model:" for the parent and the text under "Contexts in which this element may be used:" for the child
# [12:53] <MikeSmith> But I guess providing a snippet might require the snippet being provided in the spec itself, marked up in order to make it extractable
# [12:55] <hsivonen> MikeSmith: there's already enough markup in the spec file for that
# [12:56] <hsivonen> MikeSmith: could be easier if Hixie added a class for the relevant <dd>s
# [12:57] <hsivonen> MikeSmith: anyway, my next working item after the tokenizer is a prerequisite for keeping spec extracts efficiently in memory
# [12:58] <hsivonen> MikeSmith: so this improvement will have to wait for a while
# [12:58] <MikeSmith> hsivonen - yeah, I see now (after actually take to open it up and have it front of me) that the data is there ... the "Contexts" part looks to be useful in most cases, but I think there are cases where the "Content model" part doesn't have much info because it's hard to describe the conformance criteria briefly
# [12:58] <MikeSmith> hsivonen - anyway, great to hear that you are thinking about. I should have guessed you already had something like this in mind
# [13:00] <MikeSmith> btw, I messed around a bit with trying to compile oNVDL to make a standalone binary (like James put together for jing and trang) ...
# [13:00] <MikeSmith> ... I think I will ask George if he can add a makefile for doing it (if I can get a working one made, which I haven't yet)
# [13:01] <MikeSmith> add it to the source distro, I mean
# [13:01] <hsivonen> cool
# [13:04] <MikeSmith> well, will be cool if I can make work, not cool if I can't ... there are some serious limitations in gcj
# [13:05] <MikeSmith> which make it hard to compile apps with it sometimes
# [13:05] <MikeSmith> or impossible sometimes
# [13:06] * Joins: myakura (myakura@124.102.34.244)
# [13:15] <anne> DanC, using capital I now
# [13:29] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [13:34] * Joins: gavin_ (gavin@74.103.208.221)
# [13:36] * Joins: myakura_ (myakura@124.102.34.244)
# [13:37] * Quits: xover (xover@193.157.66.5) (Ping timeout)
# [13:38] * Quits: myakura (myakura@124.102.34.244) (Ping timeout)
# [13:41] * Quits: myakura_ (myakura@124.102.34.244) (Quit: Leaving...)
# [13:43] * Joins: myakura (myakura@58.88.37.26)
# [13:58] * Joins: xover (xover@193.157.66.5)
# [14:11] * Quits: zcorpan_ (zcorpan@84.216.43.161) (Ping timeout)
# [14:11] <anne> http://lucumr.pocoo.org/cogitations/2007/06/14/html5-ahead/ "changes from HTML4 — awesome. Let’s forget about XHTML and friends and go with HTML5. The specs rock, rock, rock!"
# [14:11] <anne> there's hope for us :)
# [14:14] <mjs_> anne: the differences doc is missing the "irrelevant" global attribute
# [14:15] <anne> ah, right
# [14:15] <anne> I forgot about recent additions
# [14:16] <mjs_> I bet some of the new global event handler attributes are also new (and similarly that many of the events are new)
# [14:17] <mjs_> "In addition, HTML5 has none of the presentational attributes that were in HTML4" -- it does have width and height on img
# [14:20] <Lachy> mjs, that depends if you consider <img height="" width=""> to be presentational
# [14:21] <Lachy> I'm really surprised by what Molly said about HTML5. I don't know what she was thinking
# [14:21] <mjs_> well, Hixie left off height and width on <video> because they were considered presentational
# [14:22] <mjs_> and width was left off of <table>
# [14:23] <mjs_> I dunno if there is a specific reason for the <img> exception
# [14:23] <mjs_> not that I am objecting to it
# [14:23] <Lachy> he left them on object and embed
# [14:23] <anne> yeah, some of those event listeners are new
# [14:23] <anne> onmessage for instance
# [14:23] <anne> and lots of others too
# [14:24] <Lachy> IMHO, when height and width attrs describe the actual dimensions of the image, they're metadata, not presentational
# [14:24] <anne> besides the fact that they can be placed on each element
# [14:24] <Lachy> but they can be used for presentational purposes
# [14:24] <anne> <canvas> has a nice example of non-presentational height/width
# [14:25] * Joins: zcorpan_ (zcorpan@84.216.43.161)
# [14:32] <MikeSmith> anne - pocoo.org dude gets exxtra props for having created a Vim syntax file for Genshi templates
# [14:47] * Joins: olivier (ot@128.30.52.30)
# [14:55] <anne> mentioned irrelevant and event handler attributes
# [15:18] * Joins: frippz (frippz@193.15.86.38)
# [15:37] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [15:38] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
# [15:42] * Joins: gavin_ (gavin@74.103.208.221)
# [16:09] * Quits: deltab (deltab@82.46.154.93) (Ping timeout)
# [16:43] * Joins: billmason (billmason@69.30.57.156)
# [16:49] * Parts: zcorpan_ (zcorpan@84.216.43.161)
# [16:57] * Quits: edas (edaspet@88.191.34.123) (Client exited)
# [17:27] * Quits: frippz (frippz@193.15.86.38) (Quit: frippz)
# [17:38] <DanC> "none of the presentational attributes" presumes consensus on which those are; I'd rather use that as justification, and enumerate them explicitly.
# [17:44] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [17:49] * Joins: gavin_ (gavin@74.103.208.221)
# [17:58] * Quits: billmason (billmason@69.30.57.156) (Connection reset by peer)
# [18:00] * Quits: myakura (myakura@58.88.37.26) (Quit: Leaving...)
# [18:00] * Joins: billmason (billmason@69.30.57.156)
# [18:24] * Quits: kingryan (rking3@64.81.240.149) (Quit: kingryan)
# [18:49] <anne> DanC, hmm ok, I'll look into that next week or so
# [18:50] <DanC> cool
# [19:16] * Joins: Sander (svl@71.57.109.108)
# [19:19] * Joins: kingryan (rking3@208.66.64.47)
# [19:19] * Quits: kingryan (rking3@208.66.64.47) (Quit: kingryan)
# [19:21] * Joins: kingryan (rking3@208.66.64.47)
# [19:28] * Quits: mjs_ (mjs@64.81.48.145) (Quit: mjs_)
# [19:52] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [19:52] * Joins: mjs (mjs@192.42.249.120)
# [19:55] * Quits: billmason (billmason@69.30.57.156) (Quit: .)
# [19:57] * Joins: gavin_ (gavin@74.103.208.221)
# [19:58] * Joins: billmason (billmason@69.30.57.156)
# [20:02] <gsnedders> DanC: what I've been trying to get at is that once the initial review is over, I have no issue with starting work on the tutorial
# [20:03] <DanC> the initial review is likely to take a few months...
# [20:03] <DanC> ... plus, I expect it involve raising lots of issues and settling few.
# [20:03] <DanC> so I don't expect the text of the spec to change all that much.
# [20:04] <gsnedders> I know. But once we have an idea of what won't radically change (which, as both of us hope, is almost none), it's easier to get to work
# [20:04] <anne> Yeah, features like <canvas> already have tutorials in the wild... They're pretty stable
# [20:04] <DanC> ok, fair enough.
# [20:04] <gsnedders> things like <canvas> can't radically change. things like the exact definition of can.
# [20:05] <anne> Same for contenteditable= for instance
# [20:05] <DanC> I don't have strong feelings about when tutorial work should start. I was just kinda confused about mixed signals. I realize, as the conversation goes on, that I'm sending as many mixed signals as I'm receiving ;-)
# [20:05] * DanC can't imagine a change to that would matter at all to a tutorial
# [20:06] <gsnedders> bad example. :P
# [20:06] <mjs> a tutorial should tell you when it is recommended to use in your document, which might be in the cases suggested now or not at all
# [20:07] <gsnedders> I think the first thing to establish is the target audience of the tutorial.
# [20:07] <mjs> but that's not the biggest deal in the world
# [20:07] <gsnedders> I myself won't start on the tutorial till after the spec review.
# [20:08] <gsnedders> (mainly as I'd rather spent my time reviewing the spec in the short-term, so that the WG can hopefully move forwards)
# [20:11] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
# [20:12] * Joins: deltab (deltab@82.36.30.34)
# [20:17] * Joins: ROBOd (robod@86.34.246.154)
# [20:34] * Quits: mjs (mjs@192.42.249.120) (Quit: mjs)
# [20:41] * Joins: mjs (mjs@192.42.249.120)
# [20:43] * Quits: mjs (mjs@192.42.249.120) (Quit: mjs)
# [20:47] * Joins: dbaron (dbaron@63.245.220.242)
# [20:48] * Joins: mjs (mjs@192.42.249.120)
# [20:51] * Quits: mjs (mjs@192.42.249.120) (Ping timeout)
# [21:43] <Hixie> http://www.w3.org/2002/09/wbs/40318/mtgmv/
# [21:44] <billmason> Small form flaw that even if you're not going, you record a meal requirement. Maybe I can get take out.
# [21:45] <Hixie> heh
# [21:47] * Quits: tH (Rob@83.100.255.229) (Ping timeout)
# [21:53] * Joins: tH (Rob@83.100.255.229)
# [21:59] * Quits: gavin_ (gavin@74.103.208.221) (Ping timeout)
# [22:04] * Joins: gavin_ (gavin@74.103.208.221)
# [22:16] * Joins: mjs (mjs@207.47.10.130)
# [22:46] * Joins: Zeros (Zeros-Elip@67.154.87.254)
# [22:46] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Client exited)
# [22:52] * Quits: xover (xover@193.157.66.5) (Ping timeout)
# [22:53] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro )
# [22:57] * Quits: olivier (ot@128.30.52.30) (Quit: Leaving)
# [23:05] * Joins: xover (xover@193.157.66.5)
# [23:07] * Joins: laplink (link@193.157.66.168)
# Session Close: Sat Jun 16 00:00:00 2007

The end :)