/irc-logs / w3c / #html-wg / 2007-03-26 / end

Options:

# Session Start: Mon Mar 26 00:00:00 2007
# Session Ident: #html-wg
# [00:07] * Quits: heycam (cam@203.214.81.60) (Ping timeout)
# [00:14] <anne> thanks zcorpan!
# [00:18] <zcorpan> np
# [00:32] <anne> hsivonen, skype to landline
# [00:32] <hsivonen> anne: ok
# [00:35] <Dashiva> I'm seeing a lot of +1 replies in the mail. I thought that kind of stuff was frowned upon outside AOL :)
# [00:42] <hsivonen> Dashiva: the Atom WG did +1s.
# [00:43] * anne didn't like that
# [00:44] * anne wonders how hard it is to just review the draft and comment on that
# [00:44] <anne> I mean, that's basically what the mailing list is for
# [00:44] <anne> not to figure stuff out
# [00:45] <Dashiva> But we haven't formally decided we're going to use html5 yet ;)
# [00:45] <hsivonen> Dashiva: to make an informed decision, everyone should read the draft. :-)
# [00:49] <mjs> Dashiva: -1 / +1 is a common W3C convention it seems
# [00:49] <mjs> I think HTML5 is a better starting point than HTML4
# [00:49] <mjs> I say that even without having read the draft straight through
# [00:49] <Dashiva> hsivonen: Maybe they're afraid of getting stuck in an infinite loop where Hixie updates before they're done so they have to start reading from the top again
# [00:50] <Dashiva> Been a while since I did the full readthrough, suppose it's time for another
# [00:51] * Parts: hasather (hasather@81.235.209.174)
# [00:51] <anne> mjs, I don't think it's common at the W3C actually
# [00:51] <anne> but I may be mistaken
# [00:52] <mjs> anne: I've seen a fair amount of it on mailing lists, but you're on more of them than I am
# [00:52] <Dashiva> Maybe it's common in the parts mjs frequents and not where anne travels
# [00:54] <mjs> I don't think there are a lot of such parts
# [00:58] <mjs> hmm
# [00:58] <mjs> I think the html5 charset detection algorithm might be insufficient
# [00:58] <mjs> since some browsers (at least Firefox) seem to be able to find charsets anywhere
# [00:58] <mjs> there's so much stuff in here
# [00:59] <zcorpan> mjs: insufficient for what?
# [01:01] <hsivonen> Hixie took some liberties to make the algorithm sane and good enough instead of writing down what browsers do
# [01:01] * Quits: Neovov (me@84.99.121.132) (Ping timeout)
# [01:02] <anne> mjs, yeah, <?xml is dropped for instance since IE doesn't do that
# [01:03] <anne> mjs, it's also restricted to the first 512 bytes as doing much more makes it painful (Firefox I believe detects it until the very end...)
# [01:03] <anne> Not sure what else there is to consider
# [01:03] <mjs> zcorpan: insufficient to handle real web content
# [01:03] <hsivonen> anne: less painful surely?
# [01:04] <zcorpan> mjs: could you point to some pages that would break?
# [01:04] <mjs> zcorpan: we've had to change WebKit to be able to find charsets in meta tags anywhere in the document, not just <head>, for interoperability
# [01:04] <zcorpan> oh
# [01:04] <mjs> zcorpan: I can look them up in our ChangeLog at some point
# [01:04] <Dashiva> Too bad we're doing away with doctypes, or we could've put a BOM-like character sequence in it to ease charset detection
# [01:05] <mjs> I need to make myself a list of issues to follow up on
# [01:05] <zcorpan> not being in <head> isn't the same as not in the first 512 bytes though
# [01:05] <anne> hsivonen, why?
# [01:05] <anne> hsivonen, maybe you missed a word?
# [01:05] <hsivonen> anne: oh. sorry
# [01:05] <anne> Dashiva, BOM is still allowed
# [01:06] <anne> mjs, ouch, the whole document?
# [01:06] <Dashiva> anne: But if it was automated as part of some kind of mandatory header, everyone would have one even if they didn't realize it
# [01:07] <mjs> anne: Mozilla appears to parse with the real parser and re-decode if it hits a new meta tag or something like that, don't remember details
# [01:07] <mjs> olliej and darin from my team reverse engineered what ffx and ie do
# [01:09] <anne> woho
# [01:09] <anne> implemented a probalistic search model in an hour
# [01:10] <anne> knowing how to write some simple scripts is a real time saver for this course...
# [01:11] <anne> (the implied way of doing things is by hand)
# [01:13] * Joins: Lachy_ (chatzilla@58.105.240.232)
# [01:14] * Joins: savage (dave@24.162.10.21)
# [01:15] <anne> ok, maybe an hour and a half
# [01:16] * anne hopes the teacher accepts HTML(5) files as opposed to the Excel form
# [01:17] * Joins: heycam (cam@130.194.72.84)
# [01:27] * Joins: marcos__ (chatzilla@131.181.148.226)
# [01:35] * anne reads hsivonen's blog entry and wonders when he should start getting tickets for XTech...
# [01:38] * Quits: zcorpan (zcorpan@84.216.41.105) (Ping timeout)
# [01:39] * Joins: dbaron (dbaron@71.198.189.81)
# [01:42] <marcos__> anne, pointer?
# [01:44] <anne> marcos__, his blog?
# [01:44] <anne> http://hsivonen.iki.fi/speaking-at-xtech/
# [01:44] <marcos__> yeah. thanks
# [01:55] <marcos__> argh, the abbr vs acronym debate is soooo boring :(
# [01:56] <anne> skip it
# [01:56] <marcos__> good idea
# [01:58] <anne> dbaron, it's http://www.w3.org/2005/06/tracker/ (e-mailed that in a reply)
# [01:58] <dbaron> google might be able to find that better if it had "trackbot" in it :-)
# [02:02] * Joins: zcorpan (zcorpan@84.216.42.63)
# [02:08] <marcos__> hehe, I like dino's before and after using tracker pictures :D
# [02:09] <mjs> we really need a good issue tracking technology
# [02:09] <mjs> tracker ain't it, IMO
# [02:10] <marcos__> what other features would you add?
# [02:10] <mjs> I mean, it might be better than nothing at all, but it is not great
# [02:10] <heycam> trac is pretty good, i like how you can intermingle references between the wiki, svn commits, issues
# [02:10] <mjs> milestones
# [02:10] <marcos__> we've been using it in waf for about a year and it has worked ok... but hat is only a smal group
# [02:10] * anne wonders why the mailing list doesn't work
# [02:10] <mjs> (both internal milestones for one spec, and ability to defer issues to a later spec)
# [02:10] <anne> if there's a single editor there shouldn't be a problem
# [02:10] <mjs> anne: as an issue tracker?
# [02:10] <heycam> if you had that + the action tracking from trackbot, that'd be nice
# [02:11] <mjs> sure, if the single editor is infallible
# [02:11] <anne> if he doesn't do what you want you raise a new issue
# [02:11] <mjs> so that means everyone must personally track all their own issues
# [02:11] <mjs> and no one can practically track status of issues on the spec as a whole
# [02:12] <mjs> this is like saying software with 200 QA engineers and one programmer doesn't need a bug tracker
# [02:12] <anne> there has been some work on marking which parts of the spec need work etc.
# [02:12] <anne> the bug tracker is the e-mail client
# [02:12] <mjs> e-mail is not a bug tracker
# [02:12] <mjs> have you ever tried to use email for bug tracking?
# [02:12] <marcos__> In that case, what we need is a good disposition of comments?
# [02:13] <anne> mjs, I've been doing it since 2004 for HTML5
# [02:13] <anne> works fine for that
# [02:13] <anne> anyway, I'm not opposed to an issue tracker so I'll shut up
# [02:13] <mjs> anne: we need something that works for people with limited bandwidth to devote to the spec
# [02:13] <mjs> if someone has time to raise 5 minor issues, it would be good to give them immediate confidence that their issues are in a list that will not be lost
# [02:13] <mjs> rather than making them check back later
# [02:14] <mjs> W3C sucks at this too
# [02:14] <marcos__> limited bandwidth?
# [02:14] <mjs> I mean attention bandwidth, not network bandwidth
# [02:14] <marcos__> ah
# [02:14] <mjs> as in "they can't follow progress of the group as a full-time job"
# [02:14] <mjs> it's like filing a bug in a bug tracker vs. sending an email to the developer
# [02:15] <mjs> #2 is great if you get an instant reply, but if you don't, it sucks big time
# [02:15] <anne> it's not clear to me how this would be managed though
# [02:15] <mjs> me neither, I have yet to see a good issue tracker
# [02:16] <anne> (and it's not entirely like sending an e-mail to the developer as everyone else gets to see it too)
# [02:16] <anne> (and it's archived)
# [02:16] <mjs> sure, but there's no way to see the list of all issues and their status
# [02:16] <mjs> or to see all issues you submitted
# [02:16] <mjs> reading the whole archive is not a solution
# [02:16] <anne> the former -> spec
# [02:16] <anne> the latter -> dunno
# [02:16] <mjs> the spec does not include a list of all issues
# [02:16] <mjs> or their status
# [02:16] <Lachy_> what are the problems with the W3C tracker tool?
# [02:17] <anne> raising an issue goes through an interface, for one
# [02:17] <anne> although dino had plans to change that at some point
# [02:17] <dbaron> CDF had a decent issue tracker
# [02:17] <mjs> Lachy_: it lacks milestones and is only visible to people in the WG
# [02:17] <Lachy_> how else would one raise an issue?
# [02:17] <mjs> among other things
# [02:17] <anne> mjs, the latter is not true
# [02:17] <marcos__> maybe dino should open up the source for the bot
# [02:18] <dbaron> I actually sort of liked the idea that the raising of the issue went through the tracker (which would email the list with the issue number as part of the subject), and then the tracker would pick up any further messages with ISSUE-NNN .
# [02:18] <mjs> anne: really?
# [02:18] <marcos__> I've never hacked an IRC bot.... it be fun :)
# [02:18] <mjs> isn't the web api issue tracker at a Member URL?
# [02:18] <dbaron> mjs, yeah
# [02:18] <dbaron> mjs, but I'm sure it could be run at a public url
# [02:18] <dbaron> (well, maybe not for security reasons, actually)
# [02:18] <mjs> the other problem is it doesn't let you interestingly search and classify issues
# [02:18] <anne> mjs, http://www.w3.org/2006/webapi/track/
# [02:18] <anne> is public
# [02:19] <anne> (you can't edit or raise issues there though, it's view only)
# [02:19] <mjs> like there's no way to see "all issues I raised"
# [02:19] <anne> (but making it entirely public is simple)
# [02:19] <mjs> in fact you can't even raise one if you are not in the group
# [02:19] <anne> mjs, there is
# [02:19] <anne> mjs, http://www.w3.org/2006/webapi/track/users/17
# [02:19] * anne wonders if mjs looked at tracker before :)
# [02:19] <mjs> anne: those are issues assigned to me, not issues I raised
# [02:20] <anne> mjs, look lower
# [02:20] <anne> mjs, actions are on top
# [02:20] <anne> mjs, creating more of such views is trivial though
# [02:20] <mjs> ok, I guess my main complaint is that I don't like the UI then
# [02:20] <marcos__> hehe
# [02:20] <anne> mjs, that should be trivial to fix if you have a counter proposal
# [02:21] <anne> (the reason it's not open source btw is because of security)
# [02:21] <mjs> and we can see how much not being open source helps the security of IE compared to Firefox
# [02:22] <marcos__> anne, I see.
# [02:22] <mjs> making it open source would make it easier to improve, I guess
# [02:22] <anne> if someone did a security review and fixed all the issues I'm sure dino would make it open source
# [02:22] <mjs> mainly I'd like it to have a useful query interface and milestones
# [02:23] <anne> as i understand it it's a 800 line PHP hack
# [02:23] <mjs> anne: hiding the source isn't going to prevent someone determined from hacking it; the reason it hasn't happened is lack of motivation, not lack of source
# [02:23] <Lachy_> security through obscurity isn't security at all
# [02:23] * anne is just reiterating some arguments here
# [02:23] <marcos__> Lachy_, +1
# [02:24] <marcos__> I wonder if it has some fancy XML output we could work with... make a new interface for it
# [02:24] * marcos__ starts thinking of a funcky tracker widget...
# [02:24] <mjs> I think a query interface and milestones would be my top requests
# [02:24] <anne> eum, just hacking the PHP is way easier
# [02:24] <mjs> also, given how big the HTML spec will be, maybe classifying things by subject area somewhat
# [02:25] <anne> it has subject iirc
# [02:25] <mjs> priorities are probably irrelevant
# [02:25] <anne> called "product"
# [02:25] <mjs> you could use multiple products for one spec, though that would be a bit weird
# [02:25] <mjs> especially since product is also used for versions
# [02:26] <Lachy_> hmm. maybe we could add tagging to the tracker (i.e. rel=tag) to make it more web 2.0 :-)
# [02:26] <marcos__> hehe
# [02:26] <mjs> tagging is an interesting idea
# [02:26] <anne> I suppose someone with some free time should e-mail dino and make it work
# [02:27] <anne> the requests so far don't sound too hard... but I don't think I'll have much time until the summer arrives (after July)
# [02:27] <marcos__> same
# [02:28] <marcos__> it does sound like a fun project
# [02:28] <anne> (I also don't appreciate PHP as much as I used to.)
# [02:30] <marcos__> PHP6 will make everything better
# [02:36] <Dashiva> Sort of like HTML6 and IE8
# [02:37] <marcos__> it was a forward looking statement
# [02:37] <marcos__> so, exacly ;)
# [02:45] <Hixie> about the xref stuff, i actually don't expect that to survive to CR
# [02:45] <Lachy_> Hixie, don't you expect anyone to implement it?
# [02:45] <Hixie> not really
# [02:46] <Hixie> i'm surprised more people haven't complained about it
# [02:47] <Lachy_> I'm sure I complained about how it's designed before
# [02:47] <Lachy_> or maybe I never got around to writing down my issues with it
# [02:48] <mjs> Hixie: I would not mind implementing the version w/ an explicit xref attribute
# [02:48] <mjs> if the corresponding simplifications were made to the rules for what is a cross-reference
# [02:49] <Hixie> Lachy_: i mean, like, compared to the number of people who have complained about <canvas>
# [02:49] <Lachy_> the xref attribute would be inconvenient for authors, the automatic referencing is better (except for the way it's specced)
# [02:49] <mjs> although it would require you to look for an xref-bearing ancestor any time a DOM chance occurs
# [02:49] <mjs> perhaps you could optimize by caching whether the document contains any xrefs at all
# [02:50] <mjs> but any or being an implicit xref is just impractical to implement efficiently
# [02:50] <Hixie> mjs: looking for ancestors is relatively easy
# [02:50] * Joins: karl (karlcow@128.30.52.30)
# [02:51] <mjs> Hixie: not saying it's hard, just that it would affect performance
# [02:51] <mjs> although I guess you could do it on the rendering side
# [02:51] <mjs> (at least in WebKit)
# [02:51] <Hixie> i meant relatively low-perf-hit
# [02:51] <Hixie> compared to other things
# [02:51] <Hixie> the xref attribute thing seems somewhat sensible though it would grow the web apps spec by a few kb i think
# [02:52] <mjs> I think it could shrink it
# [02:52] <mjs> since it would allow removing the quite complex rule for what is a cross-reference
# [02:52] <Hixie> it would shrink it less if you had xref=value where value is the cross reference thing
# [02:52] <Hixie> mjs: hah
# [02:52] <Lachy_> IIRC, my problem wtih xrefs is that the defining term is taken from the title attr in all cases, which doesn't make sense in all cases
# [02:52] <Hixie> mjs: no i mean it would grow it because the spec does a lot of crefs
# [02:52] <Hixie> xrefs
# [02:52] <mjs> oh, grow the size of the spec document
# [02:53] <Hixie> mjs: so almost every <code> and in the spec would not to grow an xref
# [02:53] <Hixie> but right now many of them have a title=""
# [02:53] <Hixie> and that is abuse of title=""
# [02:53] <Hixie> so if we changed that to xref="" that would really help
# [02:53] <Hixie> i like it
# [02:54] <Lachy_> would xref be a global attribute?
# [02:54] <Lachy_> or limited to selected inline elements?
# [02:54] <mjs> the proposal in email limited it to selected inline elements
# [02:54] <Lachy_> I haven't read that e-mail yet, it was too long :-)
# [02:55] <zcorpan> Lachy_: you could skip the irc discussion in the email, it is summarised at the bottom
# [02:56] <Lachy_> I suppose, for back compat, it would be possible to implement xref using script
# [02:56] <Lachy_> ok, I'll read the summary now
# [02:57] <Lachy_> oh, wait, xref is a boolean?
# [02:57] <Lachy_> I thought it would an IDREF a hashed #IDREF
# [02:58] <zcorpan> that wouldn't be much advantage over using <a href>, would it?
# [02:58] <mjs> it's proposed as a boolean, I think Hixie proposes it should be the text of a term
# [02:58] <mjs> I would add that if the value is empty it should use textContent of the element
# [02:58] <zcorpan> ah, yes, xref could replace title="" entirely
# [02:58] <zcorpan> makes sense
# [02:59] <Lachy_> is it intended to be human readable like title="", or just machine readable?
# [02:59] <zcorpan> but what about the <dfn>? use title=""?
# [03:02] <Lachy_> I think this definition of Defining term needs to be improved. http://www.whatwg.org/specs/web-apps/current-work/#defining
# [03:03] <Lachy_> The title="" of an <abbr> shouldn't be the defining term used for xrefs, it should be the text content.
# [03:03] <Hixie> i like this xref=magical-value idea, and xref="" defaulting to textContent
# [03:03] <Hixie> or would link to the first <dfn xref=magical-value/> or <dfn>magical-value</dfn>
# [03:03] <Hixie> s/or/it/
# [03:04] <Lachy_> oh, so, the xref attribute would set the defining term instead of the title.
# [03:04] <Lachy_> I think I'm a little confused
# [03:07] <Lachy_> zcorpan: you really could have made your examples in the e-mail a lot shorter and clearer
# [03:10] <Hixie> yes
# [03:10] <Hixie> the e-mail doesn't cover this, btw
# [03:10] <Hixie> it's a step earlier in the process :-)
# [03:11] <Lachy_> ok, still confused about how it would work. can you give a clear example?
# [03:13] <Lachy_> I think what's really confusing is because I keep thinking xref would sort of work like href as a way to link back to the definition
# [03:13] * Quits: marcos__ (chatzilla@131.181.148.226) (Connection reset by peer)
# [03:30] <zcorpan> Lachy_: <dfn>foo</dfn> ... foo or <dfn xref=more-specific-foo>foo</dfn> ... foo
# [03:30] <zcorpan> or any other combination, you could use textContent in the dfn and xref="" in the
# [03:30] <zcorpan> and vice versa
# [03:31] <zcorpan> although i like using title, because the tooltip is useful. you know which is being discussed without following the xref
# [03:31] <Lachy_> what the? So in the first case, says "Use the textContent to find a matching <dfn>", whereas the second case is matching xref values?
# [03:32] <zcorpan> yes
# [03:32] <zcorpan> not sure about using <dfn xref=...> for defining the term though
# [03:33] <Lachy_> hmm. I'd rather something a little more sane like this...
# [03:33] <Lachy_> <dfn id="foo">Foo</dfn> ... Foo
# [03:34] <zcorpan> the purpose of automatic xrefs is to not having to bother with IDs
# [03:34] <Lachy_> which is what I thought the original idea was
# [03:34] <zcorpan> aiui
# [03:35] <Lachy_> well, in your second example, you're providing an xref attribute on both the dfn and the reference to it, so what's the difference?
# [03:35] <zcorpan> dunno
# [03:36] <zcorpan> perhaps we could use id="" to be the term
# [03:36] <zcorpan> <dfn id=more-specific-foo>foo</dfn> ... foo
# [03:36] <zcorpan> in the general case you just do <dfn>foo</dfn> ... foo
# [03:37] <zcorpan> just when you have several foos...
# [03:37] <Lachy_> I'd rather have sensible automatic xrefs. e.g. <dfn><abbr title="Foo Bar">foo</abbr></dfn> which is referenced later by <abbr>foo</abbr>
# [03:37] <Lachy_> AIUI, that doesn't work in the current spec
# [03:37] <zcorpan> no, the term is "foo bar"
# [03:38] <zcorpan> (as of now, at least)
# [03:38] <Lachy_> and that's my problem with the current auto xrefs
# [03:38] <zcorpan> ok
# [03:39] <Lachy_> to get xrefs to work for that example in the current spec, the second abbr would have to have title="Foo Bar" as well, which loses all the benefits of having xrefs
# [03:39] <zcorpan> when would you want to use <dfn><abbr title="Foo Bar">foo</abbr></dfn> though? as opposed to <dfn>foo</dfn> (Foo Bar)
# [03:40] <zcorpan> or Foo Bar (<dfn>foo</dfn>)
# [03:40] <zcorpan> with <abbr> if you will
# [03:43] <Lachy_> See the example in the spec http://www.whatwg.org/specs/web-apps/current-work/#the-dfn
# [03:43] <Lachy_> The second paragraph should be just Teal'c activated his <abbr>GDO</abbr> and so Hammond ordered the iris to be opened. (without the title='")
# [03:44] <zcorpan> agreed
# [03:44] <Lachy_> so if we can make that work more sensibly with xref, then great!
# [03:44] <zcorpan> but the first paragraph should be The Garage Door Opener (<dfn><abbr>GDO</abbr></dfn>)
# [03:44] <zcorpan> is a device that allows off-world teams to open the iris. imho :)
# [03:45] <Lachy_> why should it be?
# [03:45] <Lachy_> we can't force authors to change the way they write things just to get around markup limitations
# [03:46] <zcorpan> agreed, but that's not why i'd write it like that
# [03:47] <zcorpan> presumably the full form is relevalt, so hiding it in a title="" when defining the term is not appropriate
# [03:47] <zcorpan> if it isn't relevant then why include it at all?
# [03:47] * Quits: Country (Country@82.124.94.238) (Ping timeout)
# [03:47] <Lachy_> because it may be of interest to some people
# [03:47] <zcorpan> fair enough
# [03:48] <Lachy_> if, for example, that was in an article on GateWorld, most of the audience knows what a GDO is. But there may be some new to Stargate that might be interested to see what it stands for
# [03:48] * Joins: Country (Country@90.35.9.111)
# [04:27] <Lachy_> XHTML2 uses <abbr full="IDREF"> for cross references with abbr. http://www.w3.org/TR/xhtml2/mod-text.html#adef_text_full
# [04:29] * Quits: Lachy_ (chatzilla@58.105.240.232) (Client exited)
# [04:33] * Joins: Lachy_ (chatzilla@220.245.91.147)
# [04:38] * Joins: olivier (ot@128.30.52.30)
# [04:38] <olivier> hello
# [04:41] * Joins: h3h (bfults@70.95.237.98)
# [05:43] <karl> ole
# [06:23] * Quits: cwahlers (Miranda@201.68.220.80) (Ping timeout)
# [06:38] * Joins: marcos__ (chatzilla@131.181.148.226)
# [06:52] * Joins: cwahlers (Miranda@201.27.182.230)
# [06:53] * Joins: Shunsuke (kuruma@219.110.80.235)
# [06:58] * Parts: zcorpan (zcorpan@84.216.42.63)
# [07:08] * Quits: h3h (bfults@70.95.237.98) (Quit: h3h)
# [07:10] * Quits: Lachy_ (chatzilla@220.245.91.147) (Quit: Chatzilla 0.9.77 [Firefox 2.0.0.3/2007030919])
# [07:23] * Parts: savage (dave@24.162.10.21)
# [07:30] * Joins: Lachy_ (chatzilla@58.105.240.232)
# [07:31] <Lachy_> karl: http://www.w3.org/2004/CDF/Group/track/ isn't a good example to those of us without member access yet
# [07:37] <karl> ooops
# [07:37] <karl> damn it
# [07:38] <karl> :) thanks Lachy, I will send another
# [07:38] <karl> :)
# [07:38] <Lachy_> Chaals (I think) already posted the Web API WG tracker
# [07:38] <karl> ah cool
# [07:40] <karl> I resent
# [09:59] * Disconnected
# [09:59] * Attempting to rejoin channel #html-wg
# [09:59] * Rejoined channel #html-wg
# [09:59] * Topic is 'W3C HTML WG http://www.w3.org/html/wg/ - http://krijnhoetmer.nl/irc-logs/ (logged)'
# [09:59] * Set by anne on Fri Mar 23 18:23:57
# [10:18] * Joins: Ed_L (irc@125.236.153.49)
# [10:18] * Quits: Ed_L (irc@125.236.153.49) (Quit: Ed_L)
# [10:27] * Joins: Julian (chatzilla@80.143.139.240)
# [10:29] <marcos__> lachy, nice response to Mike Schinkel's email.
# [10:39] * Joins: ROBOd (robod@86.34.246.154)
# [10:44] <anne> is http://www.w3.org/2005/06/tracker/webapi/ public?
# [10:44] * anne doesn't think so
# [10:44] <anne> http://www.w3.org/2006/webapi/track/ is public
# [10:46] <hsivonen> anne: how does the Web API WG deal with overdue actions in practice?
# [10:47] <anne> it doesn't
# [10:47] * hsivonen thought so
# [10:51] <marcos__> hsivonen, In WAF the chair always puts them on the teleconf agenda.
# [10:51] <marcos__> People give an update on how much they have done
# [10:51] <hsivonen> ok
# [10:52] <marcos__> I guess it depends on the chair and how many actions there are.
# [10:52] <marcos__> If people don't complete actions in a timely manner they are assigned to another wg member or deleted.
# [11:04] * Joins: Dave (dsr@128.30.52.30)
# [11:11] * Quits: schnitz (Miranda@90.186.217.154) (Ping timeout)
# [11:18] * anne wonders how much e-mails we'll see today
# [11:20] * marcos__ can't wait :P
# [11:20] <marcos__> actually, I contributed a few of those... so I am to blame too
# [11:22] <marcos__> Anne, thanks for doing a digest of the week on your blog:)
# [11:22] <anne> heh
# [11:22] <anne> maybe I should do a weekly heavily biased report
# [11:23] * anne enjoys the idea already
# [11:23] <marcos__> lol!
# [11:24] <anne> meanwhile, this Kurt "XML fan" Cagle wrote something about the new HTMLWG: http://www.oreillynet.com/xml/blog/2007/03/restarting_the_html_engine.html?CMP=OTC-TY3388567169&ATT=Re-starting+the+HTML+Engine (link from #whatwg archives)
# [11:24] <anne> "[04:47] <Lachy_> I'm only up to the 3rd paragraph, and already come across countless mistakes. Please tell me it gets better?"
# [11:27] <anne> that guy seems to have no idea how browsers work
# [11:27] <marcos__> HTML 4.3 DTD ?
# [11:27] <anne> at all
# [11:28] <anne> can everyone get a blog on oreillynet or something?
# [11:28] <marcos__> hehe, seems like it
# [11:34] <hsivonen> anne: he is one of the xml-dev people
# [11:35] <anne> His world consists of namespaces and DTD; I try to avoid the former and consider the latter to be dead...
# [11:35] <hsivonen> my feeling is that for the most part, the folks on xml-dev aren't particularly Web or browser-oriented
# [11:36] <hsivonen> HTML 4.3???
# [11:37] <anne> see also http://www.oreillynet.com/xml/blog/2007/03/restarting_the_html_engine.html#comment-546879
# [11:37] <anne> (comments)
# [11:37] <Lachy> hsivonen, it came after HTML 4.2
# [11:39] <anne> Dave, guarenteeing the same behavior is one of the goals of this WG
# [11:39] <anne> Dave, I believe it's pretty much shared accross all browser vendors
# [11:44] <Dave> Okay then why do the browsers vary in how they compute the position/size of elements?
# [11:45] <Lachy> because thye have bugs
# [11:45] <anne> Because we're not there yet
# [11:45] <Dave> You never will be either.
# [11:45] <anne> Lots of the stuff the web relies on has no specification yet or testcases.
# [11:45] <Dave> standards only cover the points of agreement.
# [11:45] <anne> Dave, this is long term planning, yes
# [11:45] <Lachy> we will get closer
# [11:46] <anne> Well, I think we disagree there
# [11:46] <Lachy> even if there's never a point where all browsers handle everything 100% identically
# [11:46] <Lachy> everything should be agreed upon, so standards should cover everything
# [11:47] <Dave> for the declarative expressions, you can say the evaluation order relative to other event handlers, and that the behavior of functions is beyond this spec (ie go look elsewhere)
# [11:47] <anne> that's exactly what we don't want
# [11:47] <anne> "go look elsewhere"
# [11:47] * Quits: Julian (chatzilla@80.143.139.240) (Ping timeout)
# [11:47] <Dave> But one spec can't cover everything
# [11:47] <anne> several implementors have said that's unaccpetable
# [11:47] <Lachy> "elsewhere" will end up being the leading browser
# [11:47] <anne> sure it can
# [11:47] <Dave> It is completely unworkable
# [11:48] <anne> it works for HTML5 so far
# [11:48] <Dave> You can't take over all specs and subsume them into one,
# [11:48] <Lachy> that leads to reverse engineering, and the same situation we're trying to recover from
# [11:48] <hsivonen> Dave: the WF 20 spec fills many more screenfuls that the XForms Transitional spec for a good reason
# [11:48] <Dave> It still doesn't do what you say
# [11:48] <Lachy> it comes pretty close
# [11:49] <Dave> It doesn't define all of the DOM for example, for that you have to look elsewhere
# [11:49] <Lachy> much closer than XForms Transitional
# [11:49] <Lachy> no, all of the DOM isn't in the scope
# [11:49] <anne> WF2 is a superset spec
# [11:49] <Dave> What!!!! you just said it was
# [11:49] <Lachy> it defines the DOM for forms
# [11:49] <anne> "This specification is written as a set of "patches" to the existing HTML4 and DOM2 specifications. This is not a particularly effective model for a specification. However, rather than rewrite this specification to address this, the intention is to wait until the features are merged into HTML5 before addressing problems that arise from the current frankensteinesque style."
# [11:49] <Dave> but if you call an event handler you are somewhere else!!!
# [11:49] <hsivonen> Dave: DOM is included by reference
# [11:50] <Dave> But the DOM isn't a 100% spec either
# [11:50] <hsivonen> Dave: however, WF 2.0 say when the event handlers it defines fire
# [11:50] <anne> not yet
# [11:51] <hsivonen> Dave: if a system purports to use side effect free functions, it can re-evaluate at will. but if those functions can have side effects anyway, you need to spec when and in which order the functions are evaluated
# [11:51] <Dave> okay that's fine. The order in which the declative expressions are evaluated relative to event handlers for change and input is easy to define.
# [11:51] <Dave> is that all you want?
# [11:51] <Lachy> Dave, there's not a chance browsers are going to implement any spec that doesn't explicitly define as much as physically possible, and XForms Transitional doesn't even come close
# [11:52] <hsivonen> Dave: I'd also be interested in research supporting the assertion that people who can't work with event handlers can work with a declarative model to a useful degree.
# [11:53] <Dave> I am amazed to think you believe that people will find learning a programming language easier than simple spreadhsheet like expressions, It is very eccentric.
# [11:53] <Lachy> I think it would be much, much better, if, instead of going off and creating your own forms spec, you would document and present the problems and limitations with WF2, so that we can then look at addressing them
# [11:54] <Lachy> but taking the "let's start from scratch" approach after 2 years of prior development on another spec will get you nowhere
# [11:55] <Dave> The idea is to persuade the WG to adopt the idea and to incorporate it into the specs, I don't want to be the editor. Ian is doing a great job already
# [11:55] <hsivonen> Dave: well, I am not a lone eccentric. In Mikko Honkala's thesis defense, he, and XForms implementor, expressed doubt about the assumed learnability properties of imperative vs. declarative
# [11:56] <hsivonen> Dave: moreover, I am not convinced that a *simple* declarative expression language is complex enough to cover enough use cases
# [11:56] <Dave> There are really tough declarative stuff, but we are talking about the really easy stuff that everyone learns - basic expressions.
# [11:56] <Dave> It doesn't have to solve all use cases (neither will HTML5)
# [11:56] <anne> + side effect free functions
# [11:57] <hsivonen> Dave: and when a declarative thing tries to cover complex stuff, the tendency is for it to get harder to grok than imperative stuff
# [11:57] <Lachy> basic expressions certainly can't cover enough use cases for the web
# [11:58] <Lachy> there are an infinite number of use cases, you're right in that no spec can ever cover them all, but we at least need to cover the ones that are being used
# [11:58] <hsivonen> afk
# [11:59] <Dave> The common cases should be available to a much broader pool of developers than the more complicated use cases,
# [11:59] <Dave> easy cases should be easy, harder ones should be possible.
# [11:59] <anne> developers just copy and paste (the broader pool anyway)
# [12:00] <Lachy> learning enough javascript to cover the simple cases is just as easy, if not easier, to learn than some declerative language
# [12:00] <Dave> Perhaps you don't want to make it easier for other people to develop HTML? They shouldn't be forced to use a text editor for instance and to know about HTML, CSS and the JavaScript and the DOM.
# [12:01] <Lachy> you have to remember that JavaScript is a widely deployed technology already. There are millions of authors using it everyday. It would be silly to force them to learn a new approach instead of leveraging their existing skillset
# [12:01] <anne> It's not like the whole universe will suddenly start making spread sheets in HTML...
# [12:01] <Dave> So it's your believe that everyone should learn JS?
# [12:02] <anne> And if they want to I'm sure someone will abstract all the problems away in some editor.
# [12:02] <Dave> the people who won't/can't are relegated to a second class ?
# [12:02] <Lachy> not everyone, only those who need to make use of it, and then only enough to get them by
# [12:02] <Dave> That someone is me, I want to be able to create a standards based editor, but you are preventing it from being HTML
# [12:03] <anne> a.value = b.value + c.value is simple enough
# [12:03] <Dave> It is a lot more that that!
# [12:03] <anne> well, onforminput="..." around it, yes
# [12:04] <Dave> What I want to know is some help in pinning down the specification details for expressions rather than vague comments about solving the halting problem.
# [12:05] <Dave> defining the order of evaluation with respect other event handlers is easy enough.
# [12:06] <Dave> but if someone violates the spec and writes a function that messes with the form dom, what would you expect the spec to say?
# [12:06] * anne is still not convinced this is needed at all
# [12:07] <Dave> well?
# [12:07] <anne> ?
# [12:08] <Lachy> the spec needs to be written in a way that deals with any possible DOM
# [12:08] <Dave> so can you expand on that?
# [12:08] <Lachy> see HTML5 and WF2, they do that
# [12:09] <Dave> I have and I don't understand what they are doing that meets your claim
# [12:10] <Dave> They define a number of testable assertions as I would expect but don't define all posibilities
# [12:11] <anne> such as?
# [12:11] <Lachy> Think of a possibility that you don't think it defines
# [12:11] <anne> (as that would be bug)
# [12:11] <Dave> onforminput="foo()"
# [12:11] <Lachy> that's defined
# [12:11] <Lachy> it called the foo() function on the forminput event
# [12:11] <Dave> where foo is any programm that will ever be written
# [12:12] <Dave> now tell me you can what foo does?
# [12:12] <anne> it doesn't matter what foo does
# [12:12] <Lachy> ECMAScript and DOM specs (including the DOM sections in HTML5) deal with how to execute the function
# [12:13] <Lachy> WF2 defines how and when to fire the forminput event
# [12:13] <Dave> The browsers have additional functions that aren't those specs
# [12:13] <Lachy> yes, and that's a bug
# [12:13] <Dave> on when to fire the event, that's easy.
# [12:13] <anne> (either in the spec or in the browsers)
# [12:14] <Dave> It it isn't a bug for browsers to add their own functions.
# [12:14] <Dave> It is just outside the standard
# [12:14] <marcos__> Dave, what's an example of one of these functions?
# [12:14] <Lachy> It's a missing feature in a spec
# [12:14] <anne> anyway, it doesn't matter here
# [12:15] <Dave> But it does since you assert that the spec has to cover all possible behavior
# [12:15] <Dave> and of course it can't
# [12:15] <Lachy> yes it can, it depends on how it's written
# [12:15] <Dave> so I think you are really asking for something else and that is what I am trying to determine
# [12:15] <Lachy> what?
# [12:15] <Lachy> who's asking for something else?
# [12:16] <anne> the spec has define the exact processing model for the features it defines
# [12:16] <Dave> when events fire is easy, the form DOM is easy
# [12:16] <anne> hah
# [12:16] <Lachy> Dave, would you agree that browsers have to impelement every possible case?
# [12:17] <Dave> but behavior under all circumstances is impossible
# [12:17] <Dave> no
# [12:17] <Lachy> and if browsers can write code that deals with every posslbe case, why isn't it possible to write a spec that does?
# [12:17] <Lachy> of course they do. Some browsers handle it better than others, but they all handle it
# [12:18] <Dave> again what I think you mean is that browsers should pass tests on all normative assertions in the specs
# [12:18] <Dave> all cases is too vague for me to understand
# [12:18] <Lachy> by all cases, I mean any conceible code thrown at them by authors
# [12:18] <Lachy> conveivable*
# [12:19] <Lachy> aargh!, you know what I mean
# [12:19] <Dave> it is impossible for you or I to conceive of all possible code
# [12:19] <anne> assuming an identical API
# [12:19] <Lachy> that's true, but browsers are forced to deal with the inconceivable code too
# [12:20] <Dave> a spec will provide testable assertions but that's all
# [12:21] <Dave> browser will do what they do, but all we can ask of them is to pass on the testable assertions
# [12:21] * Quits: Neovov (me@86.214.41.215) (Ping timeout)
# [12:21] <Dave> so I am asking you what assertions you would expect
# [12:22] <anne> define the output for any given input
# [12:22] <anne> (such as the parsing algorithm does)
# [12:22] <Dave> but for the foo() example where the code for foo is arbitrary that isn't viable
# [12:22] <anne> (it doesn't really matter what features browsers support)
# [12:22] <anne> I think it is
# [12:23] <Dave> but I just disproved that
# [12:23] <anne> I wasn't convinced
# [12:23] * marcos__ neither
# [12:24] <Dave> if a function calls some part of the browser outside of the specs, you can't say what will happen.
# [12:24] <anne> if you define it in such a way and an author uses some function that two browsers support they will give the same output
# [12:25] <anne> (the two browsers)
# [12:25] <anne> if you don't define it for any input they might give different results which is not desirable
# [12:25] <Dave> only if the two browsers define exactly the same API
# [12:25] <anne> as the browsers would have to reverse engineer each other
# [12:25] <Dave> but the API any one browser implements is larger than the spec
# [12:25] <anne> Dave, but that doesn't matter here
# [12:26] <Dave> yes, so lets get back to what you expect here.
# [12:26] <anne> define the output for any given input
# [12:26] <anne> (such as the parsing algorithm does)
# [12:26] <Dave> surely it is that if a function call manipulates the form dom, then the behavior is determined by what that dom defines
# [12:26] <Dave> the parsing algorithm is easy.
# [12:27] <marcos__> yep... go on...
# [12:27] <Dave> it covers both syntax and some semantic constraints.
# [12:27] <Lachy> I wouldn't really call it easy
# [12:27] <Lachy> but it has been done (mostly)
# [12:27] <Dave> i.e. that certain identifiers must be form fields whilst others can't
# [12:28] <Dave> it says that you don't analyse the definition of functions, only the arguments that are passed to them.
# [12:29] * anne was talking about the HTML5 parsing algorithm
# [12:29] <Dave> the spec must cover when the expressions are evaluated relative to other event handlers.
# [12:31] <Dave> and writing an expression refering to a field that has been deleted results in an undefined value, which is handled as per ECMA 262
# [12:32] <anne> I suppose that if calculate just acts on an event handler it might be workable, but it's not really clear to me how it would work
# [12:33] <anne> but then I'm still not convinced of the need etc.
# [12:33] <Dave> Yes, but as a browser vendor you aren't in the business of providing authoring solutions for non-techies
# [12:34] <Dave> most html developers aren't either - they just build websites for customers
# [12:35] <Dave> but I believe in W3C's mission to lead the web to its full potential
# [12:35] <anne> Argument by authority doesn't really work with me
# [12:35] <Dave> and in expanding what ordinary people can do with the web
# [12:36] <Dave> but that doesn't seem to matter to you, which is your perogative.
# [12:36] <Dave> The market will correct for this ...
# [12:38] <anne> that looks like another logical fallacy...
# [12:39] <anne> "Appeal to consequences"
# [12:39] * anne should learn the latin words one day
# [12:44] <marcos__> nah, it would be way cooler to argue in classical Greek :)
# [12:44] * anne has never been good at Greek
# [12:44] * anne tried it for two years
# [12:44] <anne> well, tried, I admit I didn't do much
# [12:45] <marcos__> fair enough... I did the same with french...
# [12:45] <anne> oh, me too, same for German
# [12:45] <anne> (although I did pass French and German in some way)
# [12:46] <marcos__> Don't get me wrong; I passed too, but then just kinda forgot it
# [12:47] <marcos__> I foolishly thought it would be similar to spanish
# [12:47] <anne> lol
# [12:48] <marcos__> :)
# [12:49] <Lachy> how many languages do you know?
# [12:49] <marcos__> anne? or me?
# [12:49] <Lachy> either
# [12:49] <marcos__> 2
# [12:50] <Lachy> English and Spanish?
# [12:50] <marcos__> en-au, sp-ar :)
# [12:50] <marcos__> es-ar
# [12:50] <marcos__> i should say
# [12:50] <marcos__> yeah, english and (some) spanish
# [12:50] <Dashiva> I've been thinking about trying to learn en-GB-Hixie, but it's hard to find proper documentation
# [12:50] <anne> Dutch and Dunglish
# [12:51] <Lachy> Hixie has published his own dictionary for it
# [12:51] * Joins: hasather (hasather@81.235.209.174)
# [12:51] <anne> (although some American think I'm from Britain...)
# [12:53] <marcos__> I got such a messed up accent people have no idea where i am from
# [12:53] <Lachy> are you originally from spain?
# [12:54] <Lachy> someone thought I had an english accent once, which is odd cause I've never been to england :-)
# [12:54] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro)
# [12:54] <marcos__> Lachy, Argentina
# [13:09] * nickshanks speaks en-GB-NTT
# [13:09] <Lachy> what's NTT?
# [13:09] <nickshanks> http://en.wikipedia.org/wiki/ISO_3166-2:GB
# [13:10] <Lachy> oh, I'm en-AU-NS
# [13:11] <Lachy> I mean en-AU-NSW
# [13:11] <nickshanks> (i realised :-) )
# [13:29] * Joins: olivier (ot@128.30.52.30)
# [13:31] <heycam> there are some important differences between en-AU-NSW and en-AU-VIC
# [13:31] <heycam> mostly involving terminology surrounding beer sizes :)
# [13:31] <Lachy> yeah, they're weird down there in vic
# [13:44] <hsivonen> Dave: what's your server-side form submission handler solution for non-techies?
# [13:47] <Dave> That depends on the role of the forms. The authoring tool could provide a number of solutions for different needs.
# [13:48] <Dave> BTW I am organizing a workshop in Dublin on declarative models of distributed web applications and would be delighted if you were to submit a position paper
# [13:49] <Dave> see http://www.w3.org/2007/02/dmdwa-ws/
# [13:49] * hsivonen looks
# [13:51] * Joins: Julian (chatzilla@217.91.35.233)
# [14:12] * anne dislikes stuff like DIAL heavily
# [14:12] <anne> oh, maybe DISelect even more
# [14:16] <Dave> anne, you're so lovable! :-)
# [14:17] <anne> not with specs, sorry :)
# [14:18] * Quits: nickshanks (nicholas@195.137.85.17) (Quit: nickshanks)
# [14:56] * Joins: ROBOd (robod@86.34.246.154)
# [15:02] * Quits: citoyen (eira@195.139.204.228) (Ping timeout)
# [15:17] * Quits: Julian (chatzilla@217.91.35.233) (Ping timeout)
# [15:18] * Joins: Julian_Reschke (chatzilla@217.91.35.233)
# [15:18] * Julian_Reschke is now known as Julian
# [15:26] * Joins: karl (karlcow@128.30.52.30)
# [15:27] * Joins: citoyen (eira@195.139.204.228)
# [15:32] * Quits: olivier (ot@128.30.52.30) (Quit: Leaving)
# [16:28] * Joins: zcorpan (zcorpan@84.216.42.220)
# [16:49] <hsivonen> marcos__: I'll try to remember to share my print style sheet for WA 1.0 tonight
# [16:50] <marcos__> thanks hsivonen! that would be great :) \
# [16:50] <anne> can the next person who replies to the thread on declarative stuff un-cc me?
# [16:50] <anne> cheers
# [16:54] * Joins: edas (edaspet@88.191.34.123)
# [17:04] * Joins: h3h (bfults@66.162.32.234)
# [17:31] <anne> thanks Dave
# [17:41] <Dave> you're welcome!
# [17:48] * Parts: zcorpan (zcorpan@84.216.42.220)
# [17:48] * Joins: zcorpan (zcorpan@84.216.42.220)
# [17:49] * Joins: tylerr (tylerr@66.195.32.2)
# [17:50] * Quits: edas (edaspet@88.191.34.123) (Quit: Quitte)
# [17:53] <tylerr> G'day all.
# [17:53] <krijnh> Ola
# [17:54] <tylerr> Wow, this weekend was sure busy for e-mails!
# [17:54] <krijnh> Yeah, it was
# [17:55] * anne is glad that Dave finally put forward a concrete usecase
# [17:56] <Dave> well several actually
# [17:56] <anne> i meant the last e-mail
# [17:56] <anne> the one about the authoring tool understanding the expression
# [17:57] <anne> (the other use cases could also be addressed by imperative languages easily)
# [18:02] <Dave> Okay, I thought I had covered that in previous emails, but thanks for the feedback.
# [18:03] * Joins: st (st@62.234.155.214)
# [18:12] * Parts: zcorpan (zcorpan@84.216.42.220)
# [18:12] * Joins: zcorpan (zcorpan@84.216.42.220)
# [18:19] * Parts: zcorpan (zcorpan@84.216.42.220)
# [18:20] * Joins: sierk (sborneman@87.162.173.221)
# [18:21] * Joins: dbaron (dbaron@207.47.10.130)
# [18:22] * Parts: sierk (sborneman@87.162.173.221)
# [18:24] * Joins: sierk (sborneman@87.162.173.221)
# [18:39] * Parts: hasather (hasather@81.235.209.174)
# [18:41] * Joins: schnitz (Miranda@90.187.239.255)
# [18:41] * Joins: hasather (hasather@81.235.209.174)
# [18:41] <schnitz> hi
# [18:42] <tylerr> Hi there schnitz.
# [18:42] <schnitz> Hi Tyler
# [18:43] <tylerr> How was the weekend?
# [18:45] * Joins: zcorpan (zcorpan@84.216.42.220)
# [18:47] <schnitz> thanks for asking, a real smash :-)
# [18:47] <tylerr> Lovely!
# [18:48] <schnitz> tylerr, had a good time friday playing jazz (autumn leaves, etc... :-) Then went to Berlin on Sunday, still there, we celebrate the 50. anniversity of the European Union over here
# [18:50] <tylerr> Very nice! Lots of parties and such?
# [18:50] <tylerr> And Jazz eh? I'm a big fan of the stuff.
# [18:51] <schnitz> tylerr, cool, glad you like it
# [18:51] <schnitz> tylerr, its quite fun, I tend to move between free music and jazz back and forth over time
# [18:52] <schnitz> and this very related to what we are doing here
# [18:52] <schnitz> like sometimes, I really just want to play without thinking too much
# [18:52] <schnitz> and I end up with funk
# [18:52] <schnitz> like 2 or 4 chords
# [18:52] <schnitz> but then, every now and then
# [18:52] <tylerr> Very nice. :)
# [18:52] <schnitz> u miss those harmonies
# [18:53] <schnitz> and u only get them if you thoroughly study jazz standards
# [18:53] <Mallory> None of my mails are on the list :(
# [18:53] <schnitz> tylerr, so just a lot like adherend strictly to a declarative spec
# [18:53] <tylerr> Ah see, I just enjoy listening. :)
# [18:53] <schnitz> while funk is more like scripting along...
# [18:54] <tylerr> Hehe
# [18:54] <schnitz> yeah, jazz standards are quite restrictive
# [18:54] <schnitz> u need to get those harmonic changes right
# [18:54] <schnitz> otherwise it dosn't sound nice
# [18:54] * tylerr nods.
# [18:55] <schnitz> whereas e.g. funk is more open and forgiving
# [18:55] <schnitz> but it can easily end up in a mess then
# [18:55] <schnitz> especially when playing together with more people
# [18:56] <tylerr> So then whom would be the version control? ;)
# [18:57] <schnitz> tylerr, interesting one...
# [18:57] * Parts: sierk (sborneman@87.162.173.221)
# [18:57] <schnitz> in jazz, you have about one or two dozen chords per song
# [18:57] <schnitz> so when improvising, you get so much room and possibilities, you can stay in the one big version and evolve within in
# [18:57] <schnitz> with simpler music
# [18:58] <schnitz> you really need to stop playing and tell the other musicians that something is changing now, otherwise it gets dull, so you need versioning
# [18:58] <schnitz> of course, you can continue to play and shout at the other musicion a harmonic change
# [18:58] <schnitz> but thats a hack
# [18:58] <schnitz> you then yell on stage
# [18:59] <schnitz> WE'RE GOING TO A MINOR NOW, OK?
# [18:59] <tylerr> :)
# [19:00] <schnitz> :-)
# [19:03] <tylerr> I'll be back in a few. Morning stand-up at the office, wee!
# [19:04] <schnitz> 'k, later...
# [19:05] <Dashiva> That would be a good analogy for <svg> and <math> elements. The document shouting "WE'RE GOING TO SVG MODE NOW, OK?" to the parser
# [19:06] <schnitz> Dashiva, :-)
# [19:06] * Joins: freels (freels@151.65.27.100)
# [19:07] <Dashiva> And then the parser goes "Eh, A minor? I haven't learned that one yet"
# [19:08] <schnitz> weren't namespaces meant for this?
# [19:08] <gsnedders> schnitz: HTML can't really have namespaces
# [19:09] <schnitz> SGML-based HTML, right
# [19:09] <mjs> there is no SGML-based HTML
# [21:09] * Disconnected
# [21:09] * Attempting to rejoin channel #html-wg
# [21:09] * Rejoined channel #html-wg
# [21:09] * Topic is 'W3C HTML WG http://www.w3.org/html/wg/ - http://krijnhoetmer.nl/irc-logs/ (logged)'
# [21:09] * Set by anne on Fri Mar 23 18:23:57
# [21:16] * Quits: Julian (chatzilla@217.91.35.233) (Ping timeout)
# [21:22] * Joins: mjs (mjs@17.255.97.200)
# [21:25] * Quits: freels (freels@151.65.27.100) (Quit: freels)
# [21:25] <tylerr> Afternoon mjs.
# [21:33] <mjs> hello tylerr
# [21:40] * Quits: dbaron (dbaron@207.47.10.130) (Ping timeout)
# [21:45] * Joins: Electronical (Electronic@81.175.93.238)
# [21:45] * Electronical is now known as erik
# [21:47] * Quits: erik (Electronic@81.175.93.238) (Quit: Chatzilla 0.9.77 [Firefox 2.0.0.3/2007030919])
# [21:55] * Joins: chaals (chaals@84.77.45.214)
# [21:55] * Joins: RogerJohansson (roger@213.64.74.230)
# [21:57] * RogerJohansson is now known as Roger
# [22:19] <anne> hey Roger
# [22:19] <Roger> hey
# [22:19] <Roger> I was just wondering if anyone was here and awake ;)
# [22:20] <Dashiva> There's always someone
# [22:20] <anne> I think we're covered 24/7 :)
# [22:20] <Roger> I didn't see any discussion going on so that's why
# [22:21] <Roger> i figured with the mailing list being on fire this place would be too
# [22:21] * Parts: bewest (ben@209.237.236.227)
# [22:21] <Dashiva> The discussion sort of jumps between here and #whatwg
# [22:21] <Roger> k
# [22:23] <tylerr> It's been quiet today Roger.
# [22:25] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro)
# [22:31] * chaals would be happy to see less mail - and especially less that says "hey there is too much mail"
# [22:32] <gsnedders> less is more.
# [22:32] <tylerr> I just feel for those using mail interfaces that don't group mail by threads.
# [22:33] <gsnedders> I wish Mail.app's threading was better
# [22:35] <tylerr> There needs to be some sort of tool/app developed that takes lists and turns them into discussion threads in a more intuitive and dynamic way than forums can currently produce.
# [22:40] <edas> tylerr, gmane ?
# [22:40] <tylerr> Hi edas.
# [22:40] <edas> hi
# [22:41] <tylerr> Nice tool... but my goodness the UI makes my eyes hurt. ;-)
# [22:43] <edas> you should not use the web interface but the nntp one
# [22:45] <hober> gmane is the best thing that ever happened to mailing lists.
# [22:45] <hober> all hail larsi! :)
# [22:46] <tylerr> Hehe
# [22:50] * Joins: dbaron (dbaron@207.47.10.130)
# [22:55] <tylerr> Is there any insight into when things are going to be moving forward from a milestone perspective?
# [22:56] <tylerr> The site specifies June as a first draft.
# [22:56] <tylerr> What are the steps we'll need to take to get there from where we are right now?
# [22:58] * Quits: Roger (roger@213.64.74.230) (Quit: Roger)
# [22:58] <Lachy> good morning
# [22:58] <hasather> morning
# [22:59] <edas> apart act constructivly and edit this draft ? ;)
# [22:59] <tylerr> Morning Lachy.
# [23:00] <tylerr> edas: I suppose I should say, "I want to help, there isn't much in the way of a 'how you can help' documentation, and I'm eager to contribute." :-D
# [23:00] <hober> The only feasible way to get a draft by June, AFAICT, would be to simply bless the WA1 draft. Also, that would be fine with me. :)
# [23:01] * hsivonen continues to be amazed how anyone could possible want a WG to do serious work on a Web forum instead of email
# [23:01] <tylerr> hober: That does seem to be the only way to meet the June. I know there's some side discussion on whether to start from scratch, build up from HTML4, or take HTML5 for what it is and remove chunks.
# [23:02] <mjs> hsivonen: web forum debate has consumed more email bandwidth than substantial discussion
# [23:02] <mjs> hsivonen: maybe there needs to be a separate public-html-meta list for discussion of tools and organization as opposed to things that substantively affect spec content
# [23:03] <Lachy> people wanting to discuss tools should do it in here where it's easier for most people to ignnore
# [23:04] <tylerr> I've avoided the list until I know what I'm doing. :-)
# [23:04] * Lachy can't believe there were 6 more in the anti-IRC thread overnight :-(
# [23:04] <tylerr> I'm insterested though in doing work on the accessibility side of the WG.
# [23:04] <tylerr> If there's a need.
# [23:05] <edas> please don't bring the tools/forum/email debate on irc, we don't need tools, we need work and discussions
# [23:06] <mjs> less meta, more substance
# [23:06] <mjs> although, I might post some more proposed design principles to go along with dbaron's DBTW proposal
# [23:06] <mjs> but maybe I will do it on one email
# [23:07] <dbaron> I have a few more too, just haven't had a chance to write them up
# [23:07] <dbaron> we'll see if they're the same :-)
# [23:07] * dbaron is in a CSS WG meeting the next 3 days
# [23:08] <mjs> my first one was going to be Degrade Gracefully
# [23:08] <mjs> which is just the converse of yours, in a way
# [23:10] * Joins: erik (erik@81.175.93.238)
# [23:20] <hsivonen> is there something significant about the semantics of concurring and abstaining in a W3C vote that I should know about? why does concur exist?
# [23:21] <mjs> maybe in case there is a quorum?
# [23:22] <mjs> maybe some resolutions can only pass by absolute majority, including abstaining votes?
# [23:22] <mjs> (although that would make abstain equivalent to a no vote)
# [23:22] <hsivonen> mjs: I see. I didn't consider quorum.
# [23:23] <edas> I hope there is no quorum in this group : it is a nearly public wg, there may be many inactive "invited expert" in the future
# [23:24] <tylerr> I'm sure there will be a few rounds of house cleaning.
# [23:26] <tylerr> At least to change membership from "Good" to "Not Good" standing.
# [23:26] <mjs> I don't think we should require quorum
# [23:26] <mjs> especially since we'll give at least a week to give input on decisions
# [23:28] * Quits: chaals (chaals@84.77.45.214) (Ping timeout)
# [23:30] <karl> http://www.w3.org/2005/10/Process-20051014/policies.html#def-Consensus
# [23:30] <karl> Consensus: A substantial number of individuals in the set support the decision and nobody in the set registers a Formal Objection. Individuals in the set may abstain. Abstention is either an explicit expression of no opinion or silence by an individual in the set. Unanimity is the particular case of consensus where all individuals in the set support the decision (i.e., no individual in the set abstains).
# [23:30] <karl> By default, the set of individuals eligible to participate in a decision is the set of group participants in Good Standing. The Process Document does not require a quorum for decisions (i.e., the minimal number of eligible participants required to be present before the Chair can call a question). A charter MAY include a quorum requirement for consensus decisions.
# [23:31] <karl> *may*
# [23:31] <tylerr> Well, there we go. :-)
# [23:31] <edas> thank you for the precision
# [23:36] <hsivonen> karl: thanks. I guess I concur then.
# [23:36] <hsivonen> marcos_: http://hsivonen.iki.fi/printing-wa10/
# [23:41] * Quits: erik (erik@81.175.93.238) (Quit: Chatzilla 0.9.77 [Firefox 2.0.0.3/2007030919])
# [23:46] * Quits: heycam (cam@203.214.81.60) (Ping timeout)
# [23:59] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
# Session Close: Tue Mar 27 00:00:00 2007

The end :)