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

Options:

# Session Start: Wed Mar 21 10:17:40 2007
# Session Ident: #html-wg
# [21 10:17] * Logging #html-wg to 'http://krijnhoetmer.nl/irc-logs/html-wg/20070321'
# [21 10:17] * Joins: marcos (chatzilla@131.181.148.226)
# [21 10:23] <marcos> bkode, I think server-side events are beyong the scope of this channel
# [21 10:24] * Joins: anne (annevk@81.68.67.12)
# [21 10:25] <icaaq> marcos: i agree
# [21 10:26] <marcos> :)
# [21 10:30] <anne> servers-side events are part of HTML5, fwiw
# [21 10:31] <anne> (and implemented in Opera)
# [21 10:33] <marcos> I was just going to say that that one was best left for anne:)
# [21 10:33] <marcos> I have not yet looked at what Opera is doing about that...
# [21 10:35] <anne> <event-source src> and related things
# [21 10:36] <marcos> yeah, looks pretty cool. Kinda like flash's xml sockets
# [21 10:37] <marcos> icaaq, maybe we make part of the scope :)
# [21 10:39] <icaaq> marcos: :)
# [21 10:39] * anne doesn't think HTML5 has much of a scope
# [21 10:39] <anne> did you guys read the charter?
# [21 10:39] <marcos> I'm still in shock about the vision document
# [21 10:40] <Lachy> what vision document?
# [21 10:40] <marcos> oh man, you are gonna love it!!!!
# [21 10:40] <marcos> ...searching for it....
# [21 10:40] <marcos> http://www.w3.org/2007/03/vision.html
# [21 10:40] <Lachy> http://www.w3.org/2007/03/vision.html ?
# [21 10:41] <Lachy> ok
# [21 10:41] <marcos> that's the one :)
# [21 10:41] * Lachy reads...
# [21 10:41] <Lachy> anne, I started reviewing XHR tonight
# [21 10:41] * icaaq to, again. more carefully
# [21 10:41] * marcos was surprised RDFa was not mentioned :D
# [21 10:42] <Lachy> just a few editoral mistakes in it so far, but it's really good (I'm about 1/2 way through)
# [21 10:42] * marcos intends to do that too, anne.
# [21 10:42] * marcos has only gone through quickly. but it's great work.
# [21 10:43] <Lachy> Hixie was right, it does read like one of his specs :-)
# [21 10:43] <anne> I tried to align it a bit more
# [21 10:43] <marcos> the HXR doc?
# [21 10:43] <anne> marcos, please review http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type=text/html;%20charset=utf-8
# [21 10:44] <anne> and not the version on TR/
# [21 10:44] <anne> that vision document is just there to please IBM and other XForms loving companies I think
# [21 10:45] <marcos> anne, ok and ok
# [21 10:46] <Lachy> oh man, I'm in the second paragraph, and "for the mobile market..." has already made me laugh, cause mobile browsers are just tag soup at best
# [21 10:46] <anne> -Opera
# [21 10:47] <Lachy> Opera and WebKit are the exceptions
# [21 10:47] <marcos> hehe, that one made me laugh too
# [21 10:47] <marcos> but opera does tagsoup too, right anne?
# [21 10:47] <Lachy> yeah, it does both
# [21 10:48] <hsivonen> character decoding is the dirty secret of browser XML support even when the XML support is otherwise non-bogus
# [21 10:48] * anne ponders about the teleconference
# [21 10:48] <anne> marcos, yes, but at worst
# [21 10:48] <anne> although actually, tag soup parsing isn't that bad
# [21 10:48] <anne> it just needs to be standardized
# [21 10:48] <hsivonen> in retrospect, browsers should have supported only UTF-8 and UTF-16 on the XML side
# [21 10:49] <Lachy> hsivonen, why?
# [21 10:49] <anne> to slow down adoption of XML even more?
# [21 10:49] <anne> not a bad idea, really
# [21 10:49] <hsivonen> Lachy: to get rid of a huge legacy back door
# [21 10:49] <Lachy> although, I agree it would have been ideal, reality tells me it wouldn't work
# [21 10:50] <hsivonen> anne: getting UTF-8 right is a lot easier than getting the other XML stuff right on the producer side
# [21 10:50] <Lachy> just as we're now getting requests for lenient XML parsers, we'd also get requests for legacy encodings
# [21 10:50] <hsivonen> anne: most producer objections to UTF-8 are bogus
# [21 10:51] * anne will do his bachelor project on writing a lenient XML parser + spec
# [21 10:51] <marcos> anne, from the xhr spec, what is the scope of 'this' in the following example:
# [21 10:51] <marcos> var a = {funky: function(response){ alert(this)}}
# [21 10:51] <marcos> var client = new XMLHttpRequest();
# [21 10:51] <marcos> ...
# [21 10:51] <marcos> client.onreadystatechange = a.funky;
# [21 10:52] <anne> this points to the object
# [21 10:52] <anne> as with all event listeners?
# [21 10:52] <anne> (this doesn't work in some browsers today, btw)
# [21 10:52] <marcos> that is what I am wondering
# [21 10:52] <marcos> because I've had problems with that
# [21 10:53] <marcos> in the Yahoo! widget engine, for example, this is [XMLHttRequest]
# [21 10:53] <marcos> and I think I got something different in Dashboard
# [21 10:53] <marcos> webkit
# [21 10:54] <anne> you can get different results for every single feature I think
# [21 10:54] <marcos> I don't recall the xhr spec being clear on this...
# [21 10:54] <anne> one of the reasons we try to standardize it in one way
# [21 10:54] <marcos> Having another look
# [21 10:54] <anne> it's implicitly clear by making XHR an EventTarget
# [21 10:54] <anne> and having onreadystatechange take an EventListener
# [21 10:54] * Joins: Ashe (Ashe@213.47.199.86)
# [21 10:55] <marcos> so my above example would not work
# [21 10:55] <anne> depends on what yo umean with work and it would in Opera
# [21 10:55] <anne> and might work in nightly builds of Firefox
# [21 10:56] <anne> might work in nightly builds of WebKit, dunno
# [21 10:57] * Quits: Ashe (Ashe@213.47.199.86) (Connection reset by peer)
# [21 10:57] * Joins: Ashe (Ashe@213.47.199.86)
# [21 10:57] * marcos thinks we should prolly be having this discussion in #webapi, sorry
# [21 11:26] * Joins: chaals (chaals@70.21.184.118)
# [21 11:28] <chaals> rrsagent, pointer
# [21 11:28] <RRSAgent> See http://www.w3.org/2007/03/21-html-wg-irc#T10-31-05
# [21 11:29] * chaals just gained a day
# [21 11:29] <anne> that's nice
# [21 11:30] <anne> although in amounts of time you prolly lost one
# [21 11:58] * Joins: jmb (jmb@81.179.74.126)
# [21 12:06] <bkode> i'd like to ask a general question . what would it take to add an tag or an attribute to an existing tag to be accepted by the w3c ? has it been made clear that it is saturated -or is there scope for more ?
# [21 12:06] <anne> dunno
# [21 12:07] <anne> we're already extending HTML
# [21 12:07] <anne> it would make sense if the W3C simply followed what's already been done
# [21 12:07] <anne> (to me, anyway)
# [21 12:08] <chaals> This is something the working group will sort out for themselves. But I would suggest it would take more or less interoperable implementation in several browsers
# [21 12:09] <anne> well, to exit CR sure...
# [21 12:09] <bkode> alright... the reason for that is that ... because it seems to me that more and more scripting functionality is being bundled into a tag. foe eg: the event-source . im sure as much the w3c wud like to accept it ...confinig to a sinle way is at best debatable ..right ?
# [21 12:10] <anne> <event-source> is just a convenient shorthand for an API, actually
# [21 12:10] <bkode> how close are we to closing in on an implementaion ?
# [21 12:11] <anne> it's implemented already
# [21 12:11] <chaals> We have one at Opera.
# [21 12:11] <bkode> so what if we found different ways of implementing it .
# [21 12:11] <chaals> then we would have two different implementations.
# [21 12:11] <chaals> If they are not interoperable, this would be a good argument to think harder...
# [21 12:12] <anne> bkode, what do you mean? Implementation details are not relevant
# [21 12:12] <bkode> alright. thanks for enlightening me on that... taking anoterh example... we all know of the onclick
# [21 12:12] <anne> interoperable is quite a heavy term imo, almost nothing is interoperable at this point
# [21 12:12] <anne> but most of it is usable
# [21 12:13] <bkode> if you are faimiliar with idempotent events... ie .. basically to prevent duplication .
# [21 12:13] <bkode> what would ur thoughts be on introducing an onclickwhen or <event>when attribute
# [21 12:14] <bkode> rather than having the complexity in managing idempotent events on the server side
# [21 12:15] <bkode> eg . a bank gateway...where duplicate clicks complexity could very well be made easier with a click that only accepts for say 'a time perio of 5 seconds'
# [21 12:16] <bkode> i have a javascript implementaion of this ... just to show how it would be otherwise..and how an <event-when> could easen things.
# [21 12:16] <anne> do you have some more elaborate documentation?
# [21 12:16] <bkode> http://bhaskervk.com/libraries/reusableJS/examples/idempotentEvent.html
# [21 12:16] <anne> anyway, ideas are best posted on some wiki or the whatwg mailing list
# [21 12:18] <bkode> thank you .
# [12:43] <Lachy> bkode, when suggesting ideas, it's best to present some clear use cases to be solved, rather than proposing a solution.
# [12:43] <Lachy> it may turn out that existing features can already satisfy those use cases without introducing any more, or a better solution can be found
# [13:09] * Joins: ROBOd (robod@86.34.246.154)
# [13:30] * Quits: icaaq (icaaaq@85.228.53.245) (Ping timeout)
# [13:30] * Joins: icaaq_ (icaaaq@85.228.53.245)
# [13:41] * Joins: hasather (hasather@81.235.209.174)
# [13:43] * Joins: gavin (gavin@74.103.208.221)
# [13:50] * Quits: henrik (henrik@158.39.30.58) (Quit: henrik)
# [14:06] * Joins: marcos_ (chatzilla@203.206.31.102)
# [14:19] * Joins: Charl (charlvn@196.21.192.15)
# [14:19] <krijnh> :)
# [14:51] * Joins: glazman (daniel@80.118.184.70)
# [14:51] <glazman> hi there
# [14:52] * glazman is now known as glazou
# [14:52] <anne> allo
# [14:54] <chaals> salut glazou
# [14:54] * Joins: schnitz (Miranda@85.181.61.46)
# [14:54] <schnitz> hi
# [14:54] * Parts: icaaq_ (icaaaq@85.228.53.245)
# [14:57] <glazou> chaals: thanks for the forward to Art
# [14:58] <chaals> no worries.
# [14:58] <chaals> (anne is your contact at Opera for the WAF group, BTW)
# [14:58] * chaals is just a clueless manager
# [14:58] <glazou> rotfl
# [15:01] * anne doesn't think that's funny
# [15:01] <anne> :p
# [15:03] * @DanC is booting up a bit slowly today...
# [15:03] * chaals woudln't either, if he didn't get to laugh at the poor guy who has to work for such a clueless manager :P
# [15:04] <@DanC> usually reading lets me get to sleep, but last night it kept me up late
# [15:13] * chaals ditto :(
# [15:13] * chaals waves to danC
# [15:14] <chaals> But mostly I am just lurking here a bit, since i have a day job already and we have a real live rep in the working group as well as zillions of people subscribed...
# [15:14] <glazou> 169
# [15:14] * chaals meant zillions of operatives, but I think the real number is about 8
# [15:18] <anne> yup
# [15:18] <@DanC> any volunteers to collate http://www.w3.org/2002/09/wbs/40318/ftf07/results by member org? i.e. do we have interest in a May ftf from Apple, Opera, Volantis, etc?
# [15:19] * @DanC will ask the fols with SQL-level access to the database
# [15:19] <anne> opera and volantis said yes
# [15:19] <anne> apple hasn't checked yet afaik but I believe Maciej intends to fill it in
# [15:20] <anne> although actually, volantis didn't say yes for May
# [15:21] <@DanC> I'm a little paralyzed by the prospect of 2 international trips in May. I'm already behind on Banff travel details.
# [15:21] <anne> Dave Raggett is busy or something
# [15:21] <chaals> yeah, the wbs isn't very forthcoming about where people are from.
# [15:21] <anne> well, in theory all have equal say...
# [15:22] <@DanC> hmm... what theory is that? I think it's worth giving priority to people that have a lot of influence in the way HTML is produced and consumed
# [15:23] <@DanC> aha... dom points me to http://www.w3.org/2002/09/wbs/40318/ftf07/results?view=compact , which has affiliations
# [15:25] <anne> voting theory: http://www.w3.org/2005/10/Process-20051014/policies.html#Votes
# [15:25] <anne> i suppose
# [15:25] <@DanC> voting is for when consensus breaks down. if we can't get consensus on a 1st ftf meeting, I won't bother.
# [15:26] <@DanC> consensus meaning: a critical mass in favor, and no objections
# [15:27] <@DanC> for "critical mass", I'm looking for the "3 browsers" from the charter, plus at least a handful of authoring tools, content developers, etc.
# [15:27] <@DanC> hmm... I wonder about a WBS form with boxes for content developer, software library developer, etc.
# [15:28] <anne> otoh, F2F meetings can just be planned... iirc no real descisions can be made there anyway, right?
# [15:28] * anne checks the charter
# [15:28] <@DanC> a WBS form can either be started or finished at a ftf meeting, but not both
# [15:29] <@DanC> I expect to give everybody a week to think about any formal decision; so that means proposals can be generated by ftf meetings, or proposals launched before ftf meetings can be finished, but not both ends.
# [15:29] <anne> what's a formal descision?
# [15:30] <@DanC> umm... a decision that follows some articulated form, I guess...
# [15:31] <@DanC> ... i.e. a decision of the WG, which would not be open for further discussion unless new information came to light
# [15:31] <anne> say x proposes a feature and y implements it in the spec
# [15:31] <anne> does formal descision take place?
# [15:31] <anne> a formal*
# [15:31] <@DanC> no
# [15:32] <@DanC> y could undo that part of the spec the next day
# [15:32] <anne> right
# [15:32] * Joins: gorme (gorm@213.236.208.22)
# [15:32] <@DanC> but then x might complain, and z weighs in, and perhaps consensus seems elusive; the chair then adds it to an issues list...
# [15:33] <@DanC> then, when a critical mass in some direction seems evident, the chair puts the question, collects positions for a week, and announces whether the question carried. if so, y is bound by the result.
# [15:33] <@DanC> as are x, z, and everybody else in the WG.
# [15:34] <anne> k
# [15:36] <@DanC> the 1st technical question is what spec(s) to start with. I have seen HTML5 advocated, but only buried in threads. I haven't lifted it to its own thread, because until Microsoft joins the WG, I can't compell them to give their considered opinion on the matter.
# [15:37] <anne> that and who'll be the editor is prolly what needs to be decided first, yes
# [15:37] <schnitz> right
# [15:38] <anne> and maybe do the form part separately or so, it's not entirely clear from the charter how that should work
# [15:38] <schnitz> agreed, that needs to be figured out
# [15:38] <@DanC> well, if the WG adopts the current HTML5 draft, Hixie is clearly part of the package; he has offered, and noone else has his knowledge of the text. I wouldn't formally decide who's the editor until we released a WD.
# [15:39] <@DanC> some people have suggested that the only choices are HTML5 and "start from scratch". I can imagine adopting parts of HTML5 but not others. e.g. there are more and less stable parts of it, yes?
# [15:39] * @DanC has a telcon in 8 minutes...
# [15:39] <anne> most of it is intertwined
# [15:39] <anne> and needs to be
# [15:39] <schnitz> DanC, thats an interesting possibility, I had been thinking in that direction too
# [15:39] <anne> i suppose you can split some APIs, but it's not really feasible
# [15:39] <schnitz> also, some folks said that there are part of XHTML2 that seem interesting aswell
# [15:40] <schnitz> s/part/parts
# [15:40] <@DanC> oh? I guess I missed that. who advocated parts of XHTML2?
# [15:41] <anne> (btw, why is backwards compatibility not in the charter? is it implied?)
# [15:41] <schnitz> ok, wait, let me dig it up in the archives, brb
# [15:41] <@DanC> searching for "compatibility", I find "A serialized form of such a language using a defined, non-XML syntax compatible with the 'classic HTML' parsers of existing Web browsers."
# [15:42] * Joins: billmason (billmason@69.30.57.156)
# [15:42] <anne> yeah, syntax compatible...
# [15:43] <anne> oh well, if it's not compatible it won't get passed CR
# [15:43] <@DanC> if "compatibility" isn't sufficiently explicit in the charter, I'd welcome a brainstorming goal thread about it. I have a draft in progress on doing that for the 10% market threshold.
# [15:43] <anne> not much of an issue
# [15:43] <anne> oh cool
# [15:44] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [15:44] <schnitz> e.g. "Similarly, there are several things in XHTML2 that are not in HTML5
# [15:44] <@DanC> I don't expect to wait for CR for stuff like compatibility, testing, etc.
# [15:44] <schnitz> but which I think are architecturally more sound and should be in there."
# [15:44] <schnitz> http://lists.w3.org/Archives/Public/public-html/2007JanMar/0085.html
# [15:45] <anne> he doesn't really elaborate much
# [15:45] <@DanC> does 0085 give any examples of such things? I don't see any.
# [15:45] <anne> or was that the <h> / < section> debate?
# [15:45] <@DanC> I'm starting to think of the HTML WG as the QA department of the WHATWG.
# [15:46] <schnitz> well, without getting in too much detail, there might be the option of taking parts of HTML5 and XHTML2, and when discussion starts, some folks might provide more details... its a possibility, thats all, as DanC said
# [15:46] <anne> some people see it as the getting rid of patents department...
# [15:46] <@DanC> i.e. WHATWG brainstorms and designs, and then the HTML WG plays "defense", makes tests, worries a little about laywers, etc.
# [15:47] <anne> schnitz, only parts that are backwards compatible could be taken and afaik that has already happened
# [15:47] <@DanC> well, it's not a sufficiently clear possibility to act on, at this point. That's why I asked people to flesh out the details of any goal/issue/proposal to the point of attaching an example/test document.
# [15:48] <schnitz> DanC, thats right, and I thought that was a good start, lets see if people are holding back on issues just because we're not in shape yet
# [15:48] * anne could e-mail cc lots of e-mails but isn't sure that's the way to go
# [15:49] <anne> s/emails/tests/
# [15:49] <anne> bah
# [15:49] <@DanC> we're holding back on *group decisions*; anybody who is holding back on their own goals or issues is not doing what I'd like.
# [15:49] <schnitz> DanC, ah ok, but for example the stuff around XForms Transitional is very much in this regard, and I thought it should be held back
# [15:50] <@DanC> somebody sent some pointers to tests; was that you, anne? responding to that is on my todo list.
# [15:50] <anne> i e-mailed pointers to testsuites for Web Forms 2 and <canvas>
# [15:50] <anne> and HTML parsing
# [15:50] * Joins: gavin (gavin@74.103.208.221)
# [15:50] <anne> and I think James added some tests for encoding sniffing in text/html which he recently added to html5lib
# [15:51] <@DanC> what should be held back is talk about what "we" should do. but anybody who wants XForms Transitional should be saying "I want XForms transitional; the attached document shows something cool you can do with it."
# [15:51] <schnitz> DanC, aha, good, that was a misunderstanding, thank you
# [15:52] <Lachy> well, I don't want XForms Transitional. It does nothing that WF2 can't handle, and WF2 is already much more well defined
# [15:52] <Lachy> ... and implemented in one UA
# [15:52] <schnitz> Lachy, thats fine, we can debate this in the public-html list
# [15:52] <anne> (and has a testsuite + several scripted implementations)
# [15:52] <anne> (fwiw)
# [15:53] <@DanC> I thought the WYSIWYM editors thread was great... I hope to explore some of the criticisms of WF2 w.r.t. authoring.
# [15:54] <@DanC> on the other hand, forms authoring is not MacWrite
# [15:55] * @DanC should really call time out for 3 days and actually learn XForms enough to be able to effectively chair discussions about this stuff
# [15:55] <@DanC> but right now, I'm off to a GRDDL WG telcon...
# [15:55] <schnitz> DanC, there are some really good tutorials out there :-)
# [15:55] <schnitz> right, me too...
# [15:56] <schnitz> laters...
# [15:57] * Parts: hasather (hasather@81.235.209.174)
# [15:59] * Joins: gavin_ (gavin@63.245.208.169)
# [16:12] * Joins: mjs (mjs@64.81.48.145)
# [16:12] * Quits: mjs (mjs@64.81.48.145) (Client exited)
# [16:13] * Joins: mjs (mjs@64.81.48.145)
# [16:18] <anne> http://krijnhoetmer.nl/irc-logs/ logs too
# [16:18] * Joins: hasather (hasather@81.235.209.174)
# [16:18] <krijnh> Yeah, it does
# [16:18] <krijnh> Don't know why
# [16:19] <anne> wfm
# [16:20] <krijnh> wfm?
# [16:20] <hasather> krijnh: means works for me
# [16:21] <krijnh> Ow, I thought wait for me :)
# [16:22] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
# [16:44] * Quits: gorme (gorm@213.236.208.22) (Ping timeout)
# [16:59] * Quits: anne (annevk@81.68.67.12) (Ping timeout)
# [17:28] * Quits: gavin (gavin@74.103.208.221) (Quit: gavin)
# [17:29] <NicolasLG> Bye everybody !
# [17:30] * Quits: NicolasLG (me@86.220.190.51) (Quit: NicolasLG)
# [17:34] <chaals> danc?
# [17:35] <chaals> do you have systems foo to sort out an invited exeprt's password problems (Gregory Rosmaita) for joining ths group?
# [17:35] <chaals> or should I go to sysreq?
# [17:36] * chaals goes there anyway...
# [17:36] <chaals> hmmm. lunchtime.
# [17:36] * glazou is tired and should sleep again at night
# [17:37] * chaals plans to sleep tonight (unlike last night :(
# [17:39] * @DanC finishes GRDDL WG telcon, tunes in...
# [17:40] <@DanC> I have authorization do do some parts of the IE process and not others. My mode of working for the most part is to let karl do it until gets stuck.
# [17:40] <chaals> oki
# [17:40] * Joins: dbaron (dbaron@71.198.189.81)
# [17:41] <@DanC> I think I have about a dozen people who wrote to me only and not to karl; I should get back to them sometime.
# [17:41] <@DanC> but considering that now >100 people have learned to jump thru the hoops, I figure people can teach each other at this point.
# [17:42] <chaals> This one is to do with an old account that is not configured according to the current magic, apparently
# [17:42] <@DanC> let's see...
# [17:43] * @DanC makes it as far as http://www.w3.org/2004/01/pp-impl/invitedExpert?login=grosmai ...
# [17:43] <@DanC> "Gregory Rosmaita is an invited expert with Member access." which means w3m is in the critical path. :-/
# [17:44] <@DanC> I forget whether that means karl has to ask w3m, or mauro notices automatically somehow or what.
# [17:45] <chaals> oki. Gregory and I can chase Karl/Mauro
# [17:45] * @DanC waves to dbaron
# [17:47] <@DanC> my brainstorming excercise didn't go quite as I'd hoped... it didn't result in each of mozilla, apple, etc. stating their goals. I wonder if a telcon is the best icebreaker of that sort
# [17:47] <@DanC> or we could do email introductions
# [17:47] <@DanC> or a WBS survey deely
# [17:48] * Joins: anne (annevk@86.90.70.28)
# [17:49] <glazou> chaals: mail sent to Netvibes CEO
# [17:49] * Joins: gavin (gavin@74.103.208.221)
# [17:51] <anne> DanC, I think the main problem is that it's not clear whether or not the WG has started
# [17:52] <@DanC> indeed, some parts have started, some have not. People keep asking for group decisions. I don't want to do that until Microsoft joins. But I'd like people to separate group decisions from their own goals/issues/requirements.
# [17:53] <anne> perhaps you should send a new e-mail stating that?
# [17:53] <@DanC> I think we can make a ftf decision, now that we've heard from Chris.
# [17:53] * glazou was about to write the same as anne
# [17:54] <@DanC> well, I've said it in 4 or 5 different mail messages. will saying it LOUDER help? ;-)
# [17:54] <chaals> glazou, tusen takk
# [17:54] <glazou> chaals: var s� god
# [17:55] * glazou sees at least one swede here
# [17:55] <hasather> glazou: hi :)
# [17:55] <glazou> tjena
# [17:55] * chaals waves to schnitz
# [17:56] <schnitz> hey chaaaals :-)
# [17:56] * chaals back in a minute or 5
# [17:57] * Joins: icaaq_ (icaaaq@85.228.53.245)
# [17:57] <schnitz> 'k
# [17:58] <@DanC> I'm not sure I can make the point about group decisions vs people's own goals in email. I think synchronous contact makes it clear in a way that no mail message can. the catch-22 is that calling a teleconference is a group decision. Maybe today I can un-paralyze myself on that one.
# [17:58] * Hixie looks in and waves
# [17:59] <glazou> hi Hixie
# [17:59] * @DanC tries to remember how well Hixie and dbaron know each other
# [17:59] <Hixie> DanC: test case development is certainly one thing that the whatwg has done very little of (we have a few hundred tests for a few specific things like parsing, but that's all)
# [17:59] <Hixie> DanC: so i agree that if we want to avoid overlap, testcase development would be a great thing to work on
# [18:00] <Hixie> DanC: it's also one of the most effective ways to guide what the spec says :-)
# [18:00] <@DanC> yeah
# [18:01] <@DanC> it seems that for every person willing to craft a test case, 100 people are willing to wax philosophical about the merits of this tag or that. I suppose that's just life.
# [18:01] <anne> heh
# [18:01] * Joins: kingryan (kingryan@66.92.180.242)
# [18:01] <anne> it's easier to write an e-mail than to actually do something
# [18:01] <@DanC> maybe if I started making it clear that the W3C HTML WG is mostly about making a test suite, we'd stop getting a dozen people joining a day
# [18:02] <anne> much like chatting is an effective way to keep yourself from real work
# [18:02] <@DanC> sometimes chatting is real work
# [18:03] <glazou> anne: you can't imagine how many decisions in W3C WGs were taken in the corridor during informal chats with a coffee mug in hand
# [18:03] <@DanC> so... experimenting with some pointed questions... chaals, dbaron, what do you think about taking on HTML5 wholesale as the baseline?
# [18:04] <kingryan> tantek and I make important decisions re:microformats while walking to get coffee :D
# [18:04] * glazou thinks it's the only choice, DanC...
# [18:04] <@DanC> glazou, IIRC, your mail messages say "HTML5 is worth a review; pls give me a copy that will hold still for a bit"
# [18:04] <glazou> my suggestion was to use html5 as the ground layer for HTML WG work
# [18:05] <glazou> to do so, we need the head of svn
# [18:05] <glazou> and be able to review it before it changes too much
# [18:05] <chaals> My reservations: There are a bunch of new elements that as far as I know are not implemented anywhere. That seems like a tricky thing to take on sight-unseen.
# [18:05] * schnitz agrees with chaals
# [18:05] * Joins: bfults (bfults@66.162.32.234)
# [18:05] <chaals> But there is a bunch of good stuff there in terms of cleaning up HTML.
# [18:06] <glazou> I am not saying HTML WG has to agree on the whole html5 spec
# [18:06] <@DanC> yes, chaals, I haven't read the whole thing, but I could do without, say, the <m> thingy. The question is whether it's an acceptable burden on those who want it out to ask them to argue their case with the editor.
# [18:06] <glazou> I am just saying we should probably not reinvent the wheel
# [18:06] <Hixie> well the whatwg hasn't agreed on the whole whatwg spec yet either
# [18:06] <Hixie> so... :-)
# [18:06] * Joins: Dave (dsr@128.30.52.30)
# [18:06] <chaals> My suggestion would be to work through HTML 401 and HTML5 side by side, to get a base...
# [18:06] <glazou> side question, what's the status of the current discussion ? informal chat ?
# [18:06] <chaals> (but if you want to know what Opera thinks you should email and get an answer from Lars Erik ... :)
# [18:07] <chaals> [I believe it is informal chat]
# [18:07] <@DanC> the whatwg has agreed that the HTML5 spec will stay like it is unless/until somebody convinces hixie to change it. that's more than the W3C HTML WG has agreed, though it's not out of reach.
# [18:07] <anne> fwiw: there's a list of difference with HTML4 on the WHATWG wiki
# [18:07] <anne> (apart of course from obvious differences such as that HTML4 defines almost nothing and HTML5 does)
# [18:07] <@DanC> ooh... pointer to list of diffs?
# [18:07] * anne looks for a pointer
# [18:08] <anne> http://wiki.whatwg.org/wiki/HTML_vs._XHTML#Differences_Between_HTML_4.01_and_HTML_5
# [18:08] <Hixie> DanC: in a way, yeah. there's several 1000 outstanding comments for me to deal with that i'm going through now. the comment-responding speed is slowly ramping up.
# [18:08] * glazou has to go on daddy duty for the evening/night ; bye people
# [18:08] <Hixie> later glazou
# [18:08] * Quits: glazou (daniel@80.118.184.70) (Quit: daddy duty)
# [18:09] <anne> Hixie, the only problem is the 500 new e-mails every month (onlist)
# [18:09] <schnitz> thats a problem in itself, yes
# [18:09] <Hixie> once i start dealing with them i can go faster than that :-)
# [18:09] <schnitz> that was part of the stability issue we had on the list
# [18:09] <Hixie> for xbl2 i was replying to 50 messages a day
# [18:10] <anne> yeah prolly
# [18:10] <Hixie> so long as the rate of new messages is less than 50 a day, it's a solvable problem.
# [18:10] <chaals> Well, all you need to do is reply to another 100/night and you're set, right? ;)
# [18:10] <schnitz> having such a running target is a problem...
# [18:10] <schnitz> I am not saying development should stop
# [18:10] <Hixie> (50 a day comes out to about 10,000 a year, which is well within our current receive rate)
# [18:10] <schnitz> just thats its about establishing trust
# [18:10] <chaals> The content model of map changed - it is just area, right?
# [18:11] <schnitz> and thats hard to establish when everything is liquid
# [18:11] <kingryan> if people want to review a particular version of the spec, they can refer to the relevant SVN revision
# [18:11] <schnitz> stability, trust & standard belong together
# [18:12] <anne> chaals, is now
# [18:12] * Joins: icaaq (icaaaq@85.228.53.245)
# [18:12] <anne> chaals, yes
# [18:12] * Quits: icaaq_ (icaaaq@85.228.53.245) (Ping timeout)
# [18:12] <schnitz> I think its hard to avoid a fork between html-wg and whatwg
# [18:13] <schnitz> not because of evil action, but dynamics
# [18:13] <Hixie> well, if html-wg doesn't take on the whatwg work wholesale, i'll be making sure whatwg stays in sync with whatever htmlwg does anyway
# [18:13] <anne> i think Hixie already mentioned that the WHATWG spec would be a superset of the HTML work (unless they are in fact the same)
# [18:13] <anne> so that shouldn't be a problem
# [18:13] <Hixie> (though yeah, i expect the whatwg spec will always be more detailed if they're not identical)
# [18:13] <schnitz> lets see, I'm not so optimistic
# [18:14] <Hixie> what do you see happening that would stop that?
# [18:14] <schnitz> well, in some places the HTML WG may decide to alter semantics
# [18:14] <schnitz> like not taking parts of HTML 5
# [18:14] <schnitz> in that case the whatwg would have to retro-fit
# [18:14] * Joins: gsnedders (gsnedders@86.139.123.225)
# [18:14] <anne> then WHATWG HTML5 would still be a superset...
# [18:15] <Hixie> well then the whatwg spec would be a superset of html
# [18:15] <@DanC> to be frank, so far, I don't see anybody other than Hixie doing any actual spec writing. Until that changes, the options are few.
# [18:15] <Hixie> heh
# [18:15] <schnitz> DanC, sure
# [18:15] <Hixie> there's that too :-)
# [18:15] <anne> I suppose another exception clause might be that browser vendors are no longer interested in the HTMLWG for one reason or another
# [18:15] <Hixie> well yeah
# [18:16] <Hixie> i mean this is all assuming that we continue to care about the htmlwg, but i don't see why we would not
# [18:16] <@DanC> and I'm not inclined to hand out writing assignments to anybody who volunteers. volunteers should be willing to write something without being asked, and take the risk that nobody will ever read it.
# [18:16] <schnitz> hixie, interesting question is, in case the HTML WG decides to significantly change a portion of HTML5, will the WHATWG be willing to accept that? Or stay in its original, current version?
# [18:16] <chaals> depends on the change, no?
# [18:16] <schnitz> chaals, sure
# [18:16] <@DanC> yes, surely it depends on the change
# [18:16] <anne> well, the HTMLWG largely consists of WHATWG people...
# [18:16] <Hixie> schnitz: i will keep both in sync, whether that means arguing the change in the html wg, or just accepting the change in the whatwg.
# [18:16] <chaals> As a general question it seems a bit unanswerable...
# [18:17] <schnitz> chaals, right, and thats why I am saying it may be that a fork can happen between whatwg and html-wg
# [18:17] <anne> :s
# [18:17] <bfults> doesn't seem like something worth worrying about until it happens
# [18:17] <bfults> (and if)
# [18:18] <schnitz> sure, I won't expand...
# [18:19] <@DanC> hmm... dbaron didn't bite on the HTML5 question, so perhaps I'll try a different topic: IE doesn't always parse to a tree. sometimes it makes a lattice, I gather. But the HTML5 spec always gives a tree. does anybody have a test case to illustrate this issue?
# [18:19] <Hixie> yeah, see my blog :-)
# [18:19] <gsnedders> I haven't really heard anybody mention anything apart from the patent policy when it comes to fork WA1.0
# [18:19] <Hixie> let's see if i can get a link
# [18:19] <dbaron> sorry, I don't really have time to respond until after lunch
# [18:19] * Joins: robert (rbrodrec@66.151.50.244)
# [18:20] <Hixie> danc: http://ln.hixie.ch/?start=1137740632&count=1
# [18:20] <Hixie> danc: no wait
# [18:20] <Hixie> danc: http://ln.hixie.ch/?start=1037910467&count=1
# [18:20] <@DanC> no problem, dbaron ; here's hoping we both find some spare attention at the same time.
# [18:20] <gavin> heh, I like how the current random flickr picture is of a volleyball team...
# [18:21] * Quits: Charl (charlvn@196.21.192.15) (Quit: Charl)
# [18:22] <Hixie> DanC: actually both of those have a testcase. see also http://ln.hixie.ch/?start=1138169545&count=1 http://ln.hixie.ch/?start=1155195074&count=1 http://ln.hixie.ch/?start=1158969783&count=1
# [18:22] <@DanC> thanks, Hixie; I just rea-read 1037910467 ... so is HTML5 incompatible with IE6 in this respect?
# [18:22] <@DanC> and opera, for that matter?
# [18:23] <anne> yes
# [18:24] <hsivonen> DanC: the HTML5 parsing algorithm is as compatible as it gets while keeping the output as a tree that does not have private annotations
# [18:24] <@DanC> I'm trying to remember... has anybody from opera said "let's start with HTML5" in so many words in public-html? or are any operators interested to offer a position now?
# [18:24] <hsivonen> (IE not keeping it as a tree in all cases and Opera having private annotations apparently)
# [18:25] <hsivonen> DanC: Howcome said that up front
# [18:25] <anne> DanC, howcome I think
# [18:25] <Dave> what do you mean by "operators" Dan?
# [18:25] <@DanC> so opera is happy to either accept the HTML5 parsing design or argue for something different, I gather.
# [18:26] <bfults> Operators? people of Opera?
# [18:26] <@DanC> chaals earlier used "operators" to mean "people of Opera", I think
# [18:26] <Dave> ta
# [18:26] <anne> yeah, if we disagree with something we'll just raise that on some list
# [18:26] <anne> at least, that's what we normally do
# [18:27] <@DanC> I think Chris Wilson has taken a pretty strong position in the other direction.
# [18:28] <@DanC> maybe he'd be happy to use HTML5 as the starting draft, provided certain things like that parsing example go on the issues list.
# [18:28] <hsivonen> DanC: in the comments section of his blog, Wilson said MS won't change HTML 4 parsing but they'd be open to implement a de jure algorithm for HTML5 (presumably by sniffing the doctype)
# [18:28] <gsnedders> hsivonen: I thought he said they wouldn't change HTML4 parsing in any backwards incompatible way
# [18:28] * chaals usually says "Operatives" ...
# [18:29] <gsnedders> so if it were 100% backwards compatible, they could use it
# [18:29] <@DanC> well, hsivonen, my impression is that Wilson said MS won't change how any existing documents are parsed, but if we make some new never-before-used signal (a la a new DOCTYPE), MS could implement new rules for that. but the HTML5 spec is *specifically* targetted at existing content, yes?
# [18:29] <anne> making it 100% backwards compatible would lead to changes to the DOM and other things we'd rather not do I think
# [18:29] <anne> (such as figuring out how CSS applies to a non-tree)
# [18:29] <chaals> danc, I would have to ask Lars Erik to answer that question, and he has kids so is an early-in-the-day type.
# [18:29] <hsivonen> gsnedders: well, 100% compat means having a non-tree in some cases, which would be architecturally bad for the other browsers
# [18:30] <gsnedders> anne: I'm aware. But It's a subtle and important difference between what was said and what Chris said
# [18:30] <@DanC> ok, noted, chaals
# [18:30] <anne> hsivonen, and for the rest of the specs
# [18:30] <hsivonen> DanC: my understanding is that the HTML5 algorithm is designed to work with existing content. but that's no reason for MS not to implement it for new content.
# [18:31] <@DanC> well, it's pretty boring if the W3C comes out with a new HTML spec that is still inconsistent with IE on some large portion of the web.
# [18:31] <Hixie> yeah, that's why we went to such lengths in the whatwg to avoid that
# [18:31] <@DanC> I should finish my post(s) on my goal(s) for the HTML spec.
# [18:32] <hsivonen> DanC: do you really want to be compatible in a way that potentially causes tree algorithms not to terminate?
# [18:32] <hsivonen> (that wouldn't be nice for Firefox extension writers etc.)
# [18:32] <Hixie> it wouldn't be nice for CSS and the DOM, either
# [18:32] <Hixie> i mean we'd basically have to rearchitect all of the core W3C browser technologies
# [18:32] <@DanC> well, I don't want to... but I want to learn more about whether authors depend on that behaviour of IE and why before we make a decision.
# [18:33] <Hixie> if they did, then all other browsers would be broken
# [18:33] <hsivonen> to the extent Firefox, Safari and Opera function as Web browsers, it has been proven by demonstration that treeness is sufficiently compatible
# [18:33] <anne> -Opera
# [18:34] <Hixie> opera has a tree
# [18:34] <hsivonen> anne: you guys do have a tree, right?
# [18:34] <anne> well, sort of
# [18:34] <Hixie> it's just a tree with annotations to make the css model different
# [18:34] <anne> the DOM represents a tree, yes
# [18:35] * Joins: zcorpan (zcorpan@84.216.40.185)
# [18:35] <jmb> is there any record of the differences between the whatwg algorithm and what IE does? that'd give some kind of focus on whether those differences are important
# [18:35] <@DanC> hm... so the question is whether MS would agree to a new HTML spec that says IE6 is doing it wrong. I suppose they agreed to HTML4.
# [18:36] <anne> jmb, there are some blogposts...
# [18:36] <anne> DanC, IE6 would be doing lots of things wrong, not just parsing
# [18:36] <hsivonen> jmb: what IE does is not thoroughly publicly documented.
# [18:36] <gsnedders> but what doe agreeing to HTML4 actually mean?
# [18:36] <gsnedders> *does
# [18:36] <Hixie> IE6 is already doing things wrong today...
# [18:36] <anne> same for all other current browser releases btw
# [18:36] <Hixie> compared to all other w3c specs, i mean
# [18:37] <Hixie> much like every other browser
# [18:37] <@DanC> umm... as far as I can tell, IE6 is doing it right by definition for most web users.
# [18:37] <Hixie> jmb: look at the blog posts i posted earlier
# [18:37] <jmb> hsivonen: of course. any such resource would have to be best-effort
# [18:37] <@DanC> and for people building bank web sites, etc.
# [18:37] * Joins: mjs (mjs@17.255.99.134)
# [18:37] <Hixie> jmb: (there are 5, on ln.hixie.ch)
# [18:37] <jmb> Hixie: ta, will do (I'm reading them now)
# [18:38] <anne> DanC, yes, but that doesn't mean it's bugfree
# [18:38] <@DanC> I'm interesetd in having test cases and materials linked from http://esw.w3.org/topic/HTMLAsSheAreSpoke ; I'll add a link to http://ln.hixie.ch/?start=1037910467&count=1 after lunch if nobody beats me to it
# [18:39] <mjs> hello
# [18:39] * Quits: dbaron (dbaron@71.198.189.81) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [18:39] <anne> hi mjs
# [18:39] <mjs> that's an amusing URL
# [18:39] <Hixie> DanC: what "it" is IE6 doing right?
# [18:40] <@DanC> a large part of the web-using population sees the web thru IE6. As far as they're concerned, whatever IE6 does _is_ the web.
# [18:40] <robert> it's de facto right
# [18:40] <@DanC> ergo, bank web site designers code to IE6
# [18:40] <Hixie> sure. i just said that IE6 didn't comply with the specs.
# [18:41] <Hixie> the HTML5 spec has gone out of its way to be more compatible with IE pretty much everywhere.
# [18:41] <@DanC> a useful spec is one where if you code to it, you interoperate with a critical mass of the web. From that perspective, HTML4 is boring. HTML5 is much more interesting.
# [18:42] <hsivonen> DanC: however, if you do Ajax stuff and rely on non-tree DOMs in IE, life is miserable. so it is rather safe to assume that advanced scripting-based Web app only use tree DOMs in IE
# [18:42] <hsivonen> DanC: so the non-tree cases are really for rendering compat with Netscape 3 and 4
# [18:42] <@DanC> maybe if the W3C HTML spec were close enough to IE, bank web site designers could be taught to code to HTML5 rather than to IE. but it's a tall order.
# [18:43] <robert> i believe IE's dom ignores text nodes at the beginning of elements and that developers prefer that (e.g. .firstChild returns an element in IE instead of #text)
# [18:43] <Hixie> DanC: i don't think it matters, really
# [18:43] <Hixie> DanC: so long as all the browsers do the same thing, they can code to whatever browser they want
# [18:44] <anne> (people will always code towards browsers)
# [18:44] <@DanC> so how do we get to the point where browsers do the same thing in cases where IE6 doesn't make a tree?
# [18:44] * Quits: gavin (gavin@74.103.208.221) (Quit: gavin)
# [18:44] <Dave> The blank text node case is where scripts have to work around the difference behaviors between IE and other browsers - not difficult to do though.
# [18:44] <Hixie> DanC: their non-tree is close enough to the other browsers not that it makes little practical difference.
# [18:45] <Hixie> and going forwards, they should do what the spec says
# [18:45] <mjs> I don't think we should require non-tree DOMs
# [18:45] <Hixie> (even if, imho misguidedly, they decide to do it by having yet another mode)
# [18:45] <mjs> that's just too abusive, and it seems unlikely code relies on it for compatibility
# [18:45] <Hixie> non-tree DOMs are really not an option. non-tree DOMs would require changing most of the DOM specs and all of CSS.
# [18:45] <mjs> in fact, a lot of JS library code probably assumes that the DOM is a tree and could break if put in an invalid document that makes a non-tree DOM in IE
# [18:46] <Hixie> yeah
# [18:46] <Hixie> i've written such code myself
# [18:46] <Hixie> it's confusing as hell
# [18:46] <@DanC> the HTML5 spec says to do something different from what IE6 does, on existing content. Do you think we can get MS to agree to that? It's possible for us to proceed over their objection, but will that result in a useful spec? hmm.
# [18:46] <mjs> I've spoken to several JS library authors who said things along the lines of "that explains the infinite loops walking the DOM I've heard reported"
# [18:46] <kingryan> DanC: it seems we can convince them for new content, but not existing content
# [18:47] <@DanC> Hixie, I don't think it's a foregone conclusion that an interesting new HTML spec is _possible_.
# [18:47] * Joins: gavin (gavin@74.103.208.221)
# [18:47] <Hixie> DanC: well a non-existing spec (such as an impossible one), is definitely not interesting from a practical perspective
# [18:47] * hsivonen has also spent hours tracking down an IE non-treeness-related bug in a scripted app
# [18:48] <mjs> even a spec that IE does not implement would be useful, since then content authors will be closer to having 2 targets instead of 4
# [18:48] <mjs> Opera, Safari and Firefox are already much closer to each other (and to standards) than they are to IE
# [18:49] * @DanC takes a call
# [18:49] <mjs> I have to admit that my colleague Dave Hyatt is extremely reluctant to make any changes to HTML parser error handling though
# [18:49] <mjs> even if it would make us more similar to other browsers
# [18:49] <mjs> he is probably less stubborn than Microsoft though
# [18:50] <mjs> so, if we had our other co-chair, here are the questions I would raise on public-html:
# [18:50] <Hixie> mjs: luckily for him, the whatwg spec is basically the safari algorithm
# [18:50] <anne> even if he got a good regression testsuite?
# [18:50] <mjs> Hixie: he's scared to make even the minor remaining changes
# [18:50] <mjs> I try to soothe him
# [18:50] <Hixie> yeah i can understand that
# [18:50] <Hixie> but that's ok
# [18:50] <Hixie> it'll take time
# [18:50] <mjs> we do have a lot of regression tests
# [18:50] <Hixie> eventually more and more people will use this algorithm and eventually it'll be shown to be safe :-)
# [18:50] <mjs> though not a whole bunch specifically for parser error handling
# [18:50] <mjs> so if we had both our co-chairs, here are the top questions I would raise:
# [18:51] <mjs> 1) should we make it possible for anyone to subscribe to public-html? (I think yes, the current state is kind of annoying)
# [18:52] <mjs> 2) should we use Web Apps 1.0 as a starting point for work? (I also think yes, although we'd want to review feature set and technical details)
# [18:52] * Joins: Zakim (rrs-bridgg@128.30.52.30)
# [18:52] <@DanC> agenda + should we make it possible for anyone to subscribe to public-html? [mjs]
# [18:52] * Zakim notes agendum 1 added
# [18:52] <mjs> I'd especially like to resolve #2 before debating individual technical issues too much
# [18:52] <@DanC> agenda + should we use Web Apps 1.0 as a starting point for work? [mjs]
# [18:52] * Zakim notes agendum 2 added
# [18:52] <mjs> oh yeah, also
# [18:52] <gsnedders> where is the agenda?
# [18:53] <@DanC> agenda?
# [18:53] * Zakim sees 2 items remaining on the agenda:
# [18:53] * Zakim 1. should we make it possible for anyone to subscribe to public-html? [from mjs via DanC]
# [18:53] * Zakim 2. should we use Web Apps 1.0 as a starting point for work? [from mjs via DanC]
# [18:53] <gsnedders> ah.
# [18:53] * Quits: schnitz (Miranda@85.181.61.46) (Ping timeout)
# [18:53] <mjs> 3) how should we participate in the joint forms task force with the Forms Working Group?
# [18:53] <@DanC> it's also in http space somewhere; I forget where Zakim puts it
# [18:53] <@DanC> agenda + how should we participate in the joint forms task force with the Forms Working Group? [mjs]
# [18:53] * Zakim notes agendum 3 added
# [18:54] <@DanC> any operators wanna play this Zakim agenda game? or mozilla folk? (I guess dbaron is mostly away until after lunch)
# [18:55] <@DanC> do you have a preference re 3) Forms, mjs?
# [18:55] * anne would rather not have the task force
# [18:55] <mjs> DanC: I don't know, never been on w3c Task Force before
# [18:56] <mjs> I don't know what the norm is for how working groups send representatives, or if such task forces have a chair, or anything
# [18:56] <hsivonen> DanC: personally, I'd like to see the html wg adopt both WA 1.0 and WF 2.0 as starting points. what is the forms task force expected to do?
# [18:57] <@DanC> the task forces that I'm most comfortable with are sorta glorified action items; i.e. it's 3 people noodling on something for a few weeks
# [18:57] <mjs> the Forms Task Force seems way beyond that
# [18:57] <@DanC> yes; well outside my comfort zone
# [18:57] <mjs> it seems like our charter requires doing a large part of our spec in that task force
# [18:57] <mjs> which is why I argued for not having it
# [18:58] <@DanC> it's moderately straightforward for this WG to appoint one or more representatives to the task force, and then ask them to report every once in a while.
# [18:58] <anne> our charter doesn't actually say that
# [18:58] <hsivonen> where did the demand for the task force come from?
# [18:58] <anne> the charter says that in the task force we can try to work out differences between the HTML and XForms architecture
# [18:58] <anne> but not much is required iirc
# [18:59] <anne> "The HTML WG and the Forms Working Group will work together in this Task Force to ensure that the new HTML forms and the new XForms Transitional have architectural consistency and that document authors can transition between them"
# [18:59] <anne> so...
# [18:59] <@DanC> it's also moderately straightforward for the taskforce to elect its own chair... er... maybe not; that would involve enumerating the membership somehow.
# [19:00] <hsivonen> has it been pre-established that the new XForms Transitional will be published by the W3C?
# [19:00] <mjs> hsivonen: I think the demand for a task force came from XForms advocates
# [19:00] <@DanC> if the HTML WG and the Forms WG can agree on a task force chair, that would be straightforward
# [19:00] <@DanC> Zakim, take up item Forms
# [19:00] <Zakim> agendum 3. "how should we participate in the joint forms task force with the Forms Working Group?" taken up [from mjs via DanC]
# [19:00] <anne> i'm all for the XForms guys giving concrete suggestions on what's wrong with Web Forms 2 with going into some silly architecture debate seems like a waste of our time
# [19:00] <mjs> XForms Transitional is not a W3C document of any kind
# [19:00] <anne> s/2 with/2 but/
# [19:01] <hsivonen> mjs: but XForms Transitional is neither XForms nor WF 2.0. isn't it XForms only in the name? (sorry if I appear not to get it. I am a bit confused about this)
# [19:01] <anne> hsivonen, you're not mistaken
# [19:01] <mjs> hsivonen: you don't get it because it doesn't really make sense
# [19:01] <Hixie> before the w3c publishes xforms transitional, the small matter of it being provably unimplementable should probably be fixed
# [19:01] <Hixie> (it currently relies on computers being able to solve the halting problem)
# [19:01] <anne> XForms Transitional is like Web Forms 2 but then from the Forms WG
# [19:02] <mjs> Dave Raggett seems to have a strongly held vision of HTML as a language for direct representation of spreadsheet-style documents
# [19:02] <mjs> that seems to be his goal with XForms Transitional
# [19:02] <mjs> I don't know if XForms Transitional has many advocates besides him
# [19:02] * Parts: icaaq (icaaaq@85.228.53.245)
# [19:03] <@DanC> Hixie, are you sure it doesn't require people to solve the halting problem? The C spec says things about C programs that amount to the halting problem; compilers aren't required to detect them.
# [19:03] <Dave> See my recent email for details on why round tripping of semantics is key to democratising authoring of web content
# [19:04] <Hixie> DanC: it requires that the ua be able to solve the halting problem. presumably a human is going to have to implement the ua, but that isn't required.
# [19:04] <Hixie> it's somewhat academic anyway
# [19:04] <Hixie> since it doesn't matter who tries to solve it
# [19:04] <Hixie> it can't be solved.
# [19:04] <@DanC> I agree the discussion of the halting problem is academic
# [19:04] <hsivonen> Dave: that assumes that writing mathematic expressions inside imperative event handlers is too hard but that declarative stuff isn't too hard
# [19:04] <@DanC> daves proof-of-concept implementation is a solution of sorts, no/
# [19:04] <@DanC> ?
# [19:04] <mjs> I'm not sure if spreadsheets are a hugely compelling use case
# [19:05] <Dave> Spreadsheets were one of the 1st killer apps for personal computers and HTML has still to catch up with the simplicity and ease with which anyone can create spreadsheets without needing to learn programming
# [19:05] <Hixie> DanC: his proof-of-concept implementation doesn't implement his spec.
# [19:05] * Joins: dbaron (dbaron@63.245.220.242)
# [19:05] <mjs> obviously you can build spreadsheet-like things on top of the language with round tripping by storing the information in some indirect form
# [19:05] * Hixie points to google docs and spreadsheets
# [19:05] <hsivonen> Dave: I have no research to back me up, but I would guess that people who actually develop Web apps are comfortable with imperative programming but aren't necessarily thinking in the terms required by declarative or functional programming
# [19:05] <chaals> hsivonen, not quite. The idea is that a tool can readily parse the typical highly constrained declarative markup, but not arbitrary imperative code. So you can move stuff from one tool to another...
# [19:05] <mjs> so the question is, are they so important that we should change HTML itself to support them?
# [19:06] <Dave> Ian, the implementation came first, which is key as it is easy to write a spec that doesn't work.
# [19:06] <mjs> I think the answer is no
# [19:06] <@DanC> mjs, I agree that's a very relevant question, but isn't WF2 also a change to HTML?
# [19:06] <mjs> spreadsheets are not nearly as key to day-to-day computing now as when they first came out
# [19:06] <@DanC> (I know only enough about forms to be dangerous)
# [19:07] <mjs> DanC: I'm not saying "don't change HTML", we just need to know what the design target is to know what kind of change is best
# [19:07] <chaals> hsivonen, that would fit with my experience. But the flip side is that there are more people who can't really get imperative code (at best they copy/paste and tweak to see if it does what they expected) but who can understand markup, and even more who can understand a half-decent user interface that hides the magic code...
# [19:07] <hsivonen> chaals: but how well do real-world use cases stay in the declarative box without wanting to use full JavaScript?
# [19:07] <Dave> Simple JavaScript expressions are easy to add - so I don't understand why you want to force editing tools away from HTML
# [19:07] <Hixie> oh hey, there's dave
# [19:07] <hsivonen> chaals: it seems to be that VBA is quite popular in Excel
# [19:07] <Hixie> hey dave
# [19:07] <Dave> Hi Ian,
# [19:07] <Hixie> Dave: i know the implementation came first, but that doesn't make the spec implementable :-)
# [19:08] <mjs> I think conflating spreadsheets and editing tools is mistaken
# [19:08] <Hixie> just means you specced something else
# [19:08] <mjs> most editing tools are for documents
# [19:08] <Dave> The spec should always be testable against implementations.
# [19:08] <mjs> like emails or blog posts
# [19:08] <chaals> hsivonen, right. I wrote my first HTML authoring tools in WordBasic. But most of the people I get Excel from have no idea how it works beyond doing the point-and-click sum of a range thing...
# [19:08] <Hixie> not really sure what that means
# [19:08] <Hixie> but sure
# [19:09] <mjs> editing tools are really interesting
# [19:09] <chaals> mjs, yes, I suspect blog tools and email composers are the really big use cases for editing HTML.
# [19:09] <mjs> spreadsheets are marginally interesting
# [19:09] <@DanC> (we've strayed somewhat from the topic of "how should we participate in the joint forms task force with the Forms Working Group"... which I don't mind too much, I guess...)
# [19:09] <hsivonen> chaals: but are those who are only able to use a range tool potential form authors or users of spreadsheet apps created by real programmers who write JS?
# [19:09] <mjs> yes, we've gotten into discussing substance
# [19:09] * chaals leaving that for Lars Erik, so happy to stray from it.
# [19:09] <mjs> but I'm still not clear what the procedure is
# [19:10] * Joins: quaiz (quaiz@66.162.32.234)
# [19:10] <chaals> hsivonen, yep. They write the forms I have to fill in every day/week/month/year
# [19:10] <@DanC> mjs, I'm not clear on the procedure either. we're making it up.
# [19:12] * @DanC should grab lunch... or breakfast, for that matter
# [19:12] * gsnedders tries to remember if he's had lunch… it's 6PM, anyway
# [19:12] <hsivonen> btw, are there real working interoperable authoring tools for XForms that deliver on the promise of being able to move declarative stuff between authoring tools?
# [19:13] <Dave> Yes, I believe so, but you should ask that on www-forms
# [19:16] <Dave> hixie, I don't understand your halting issue, surely all event handlers should terminate in a short time for the UI to behave nicely, that's just one of the areas where people can go wrong but it isn't up to us to vet their code for them.
# [19:17] <Dave> Trying to derive semantics from JavaScript sounds real hard though.
# [19:17] <mjs> DanC: I think instead of having a task force, the interested members of the Forms WG should join the HTML WG and collaborate on that part of the HTML spec
# [19:17] <mjs> DanC: since it is so easy to join
# [19:18] <mjs> since we're not planning to be heavy on telecons, the existence of a task force is pretty nominal anyway
# [19:18] <Hixie> Dave: the spec says that the attributes can call arbitrary js, but it also says that you do a topological sort to determine evaluation order.
# [19:18] <Hixie> Dave: you can't work out the dependencies if you're allowing arbitrary turing complete code
# [19:18] <Hixie> Dave: so that's impossible to implement.
# [19:18] <mjs> Dave: requiring that the JS expression attributes be side-effect free is, I believe, isomorphic to the halting problem
# [19:19] <Dave> yes. this is based upon the presence of the references in the expression, just like for spreadsheets.
# [19:19] <Hixie> Dave: (i thought we covered that in the review that karl sent you)
# [19:19] <Dave> No, your arguments weren't technically sound.
# [19:20] <Hixie> if the arbitrary js function does an XMLHttpRequest to a random number generator server to pick a field each time it is called, and changees the value of that field, how do you work out the dependencies?
# [19:20] <Dave> The expression analyser doesn't inspect external functions, so I agree that the spec should note that. (an easy addition)
# [19:20] <Hixie> if it doesn't inspect the functions, how do you find the dependencies?
# [19:21] <mjs> seriously, how is it checkable that JS expressions are free of side effects? you could have a special JS interpreter mode to prevent it at runtime (although you'd have to know the full set of native methods and properties that have side effects), but there is no way to determine it just examining the expression
# [19:22] <Dave> It is just like I said, you look for the references and then look at their properties, but you don't analyse the bodies of functions
# [19:22] <Hixie> dave: if it doesn't inspect the functions, how do you find the dependencies? surely your dependency list will be wrong if you don't look everywhere.
# [19:22] <Dave> you don't need to check that functions are side effect free, the UA behavior is undefined if they aren't.
# [19:22] <hsivonen> Dave: with all the magic getters and setter of JS, how do you figure out what the references are?
# [19:23] <mjs> any spec that falls into "UA behavior is undefined" so readily is not a useful spec
# [19:23] <Hixie> dave: ua behaviour being undefined is exactly what caused tag soup in the first place, and it is our #1 goal to remove anything with undefined behaviour
# [19:23] <mjs> undefined behavior is no longer considered acceptable
# [19:23] <Hixie> hear hear
# [19:23] <Dave> Remember that we are looking at simple expressions and can analyse the references that appear within them using string matching routines (regex etc)
# [19:24] <mjs> you are looking at simple expressions until someone decides to write one that isn't simple, using the full power of JS
# [19:24] * @DanC catches up...
# [19:24] <mjs> if you want to invent a new simple side-effect-free expression language, then JS is not an option
# [19:24] <Dave> They are welcome to use scripting more generally but thats for experts.
# [19:24] <hsivonen> Dave: I have serious doubts that real use cases stay in that box. I am inclined to believe arbitrary JS will be used anyway. And WF 2.0 caters for that.
# [19:24] <mjs> but that makes the spec far less useful
# [19:25] <@DanC> mjs, having no task force seems like a big enough charter change that we'd have to do another AC review. Maybe we'll do that anyway, but having a nominal task force seems easier.
# [19:25] <Hixie> dave: even if your syntax was very limited and not turing complete, and even if you defined behaviour for things outside that syntax was to abort processing, if you allow calls to arbitrary turing comptele languages (like JS functions) your dependency tree cannot be proved correct, and your topological sort will fail.
# [19:25] <Dave> and so does XFT
# [19:25] <mjs> DanC: I'd just like the task force to reuse the chairs and mailing list of the HTMLWG
# [19:25] <mjs> and membership
# [19:26] <Dave> This is no different from writing scripts for event handlers, there is no guarantee that they will complete either.
# [19:26] <Hixie> right
# [19:26] <@DanC> I see... well, I'm not sure it's reasonable for me to propose that to the Forms WG, mjs.
# [19:26] <mjs> if actually using arbitrary JS puts you into "undefined behavior", then it does not "cater to" it
# [19:26] <Hixie> dave: but there's no dependency determination and topological sort for event handlers
# [19:26] <Hixie> dave: the execution order is extremely well defined for event handlers, and is independent of their contents
# [19:26] <mjs> DanC: well, there's a lot more people in the HTMLWG than the Forms WG, so it's less work for them to come over here
# [19:27] <Dave> True, but within the space of simple expressions and side effect free functions all works fine.
# [19:27] <@DanC> it's not less work than having a neutral forum, mjs
# [19:27] <Hixie> dave: we have to worry about all problems, we can't just limit ourselves to the convenient ones :-)
# [19:27] <mjs> the correct way to describe something "something that works only in a subset of cases, and a subset that is not checkable" is "does not work"
# [19:28] <Dave> XForms for example allows you to call out to functions from bind constraints expressed in XPath, but its on your own head if the functions are not side effect free.
# [19:28] <mjs> DanC: well, would we want everyone on the HTMLWG to subscribe to this new list?
# [19:28] * Joins: bewest (ben@209.237.236.227)
# [19:29] <Hixie> dave: the big difference being that xpath extension functions are under the control of the ua, whereas arbitrary js is not
# [19:29] <hsivonen> Dave: do XForms implementations interoperate when the functions are not free of side effects?
# [19:29] <Dave> If you want guarantees either don't use external functions or check them carefully. It works fine.
# [19:29] <Hixie> it's not the authors who want guarentees, so much as the ua implementors and the users
# [19:29] <Hixie> and they're not the ones who write th code
# [19:29] <Dave> You would be violating the spec if you did so.
# [19:29] <hsivonen> Dave: what if authors use functions with side effects and depend on the behavior of one UA?
# [19:30] <@DanC> I don't think so, mjs. as I said earlier, what looks straightforward to me is for the HTML WG to appoint a few representatives to the task force and have them report back now and again. That would happen concurrent with Forms design work in the HTML WG
# [19:30] <Dave> That is like using a UA dependent DOM feature
# [19:30] <mjs> "undefined behavior" is not an acceptable answer for a modern web standard
# [19:30] <mjs> end of story
# [19:30] <Hixie> Dave: 93% of the web is syntactically incorrect according to a study of several billion documents i did last year. we have to assume people will violate the spec more than they won't. we still have to interoperate on those documents.
# [19:30] <mjs> I don't know why we are even debating this
# [19:30] <@DanC> does javascript really have no undefined behaviour?
# [19:31] <Hixie> with the whatwg spec, yeah, pretty much.
# [19:31] <Dave> Because I want to enable moms and pops to be able to create interesting web content comparable to simple spreadsheets.
# [19:31] <mjs> DanC: a lot less than HTML
# [19:31] <mjs> if you mean the actual ECMAScript standard
# [19:31] <Hixie> oh ECMAScript itself is pretty tight, yeah.
# [19:32] <mjs> it does have some cases of undefined behavior, but in many cases a de facto standard has evolved to fill those gaps because authors depend on it
# [19:32] <Dave> I should know I spent a lot of time on ECMA 262 a few years back - way too many trips across the atlantic.
# [19:32] <hsivonen> Dave: couldn't that be accomplished with an authoring tool that compiles its own stuff to WF 2.0 plus JS?
# [19:32] <mjs> for example, it's unspecified what order attributes are enumerated in when using a for..in loop
# [19:32] <mjs> but in fact they must be enumerated in the order they were added
# [19:32] <mjs> because authors depend on that
# [19:32] <Hixie> yeah. hopefully they'll fix that in ES4
# [19:32] <Hixie> otherwise i guess we'll have to define it in the whatwg spec
# [19:32] <mjs> so one of the few cases of undefined behavior I can think of was clearly a mistake
# [19:33] <Dave> hsivonen, yes we can give up on html as an editing format and using something else that compiles to HTML, sure
# [19:33] <mjs> s/as an editing format/as an editing format for spreadsheets/
# [19:33] <Dave> W3C's members have invested heavily in developing declarative XML formats with that in mind.
# [19:34] <Hixie> makes sense that those formats would be used, then, and then exported as html
# [19:34] <Dave> But I don't want to give up on html just yet.
# [19:34] <mjs> I thought they were interested in "Enterprise", not "mom and pop"
# [19:34] <@DanC> mjs, what you say makes a lot of sense. It seems mildly ironic coming from an apple person. Apple has a history of saying "your app doesn't work with the new version of MacOS? well, clearly you were depending on an undocumented behaviour. you lose."
# [19:34] <hsivonen> Dave: how does XForms Transitional protect the technical investment in XForms proper? aren't they technically different even though they share the name?
# [19:34] <Dave> These days, web apps are all the rage and it isn't just about publishing content to the people.
# [19:35] <bfults> I'm having trouble coming up with a "mom and pop" use case for creation of interactive spreadsheet documents with HTML.
# [19:35] <mjs> DanC: actually, we go to great lengths to preserve binary compatibility with documented behaviors that apps actually use
# [19:35] <mjs> DanC: with undocumented behaviors, rather
# [19:35] <bfults> wouldn't they use a desktop app, Google Spreadsheets, or a custom CMS? (none authored by mom & pop)
# [19:35] <Dave> Okay, I want to create a simple spreadsheet like page and save it on the web and use it just like I would use excel.
# [19:36] <bfults> why?
# [19:36] <hsivonen> bfults: that's what I meant with tools that compile to stuff that browsers see
# [19:36] <@DanC> perhaps my impression is from long ago, mjs. or perhaps it's just that microsoft had a reputation of going to even greater lenghts; to the extent of not really bothering with documented behaviour
# [19:36] <Dave> The issue is when I hit the save button, what does it save?
# [19:36] <bfults> hsivonen: right. so I fail to see why spreadsheets would have to be natively handled by HTML
# [19:36] <hsivonen> bfults: me too
# [19:36] <bfults> if <spreadsheet> then why not <cookbook>?
# [19:36] <mjs> DanC: we have a number of app-specific compatibility hacks in WebKit
# [19:37] <Dave> If it saves to XForms, then the semantics are preserved, but if the semantics are compiled to JavaScript the semantics are lost.
# [19:37] <mjs> it's not fun
# [19:37] <hsivonen> bfults: though <datagrid> provides hooks for writing your own calculation engine
# [19:37] <mjs> we also constantly have trouble with web content authored for Dashboard widgets, it depends on old WebKit bugs / quirks all the time
# [19:37] <Dave> You have to think of the web as two way.
# [19:37] <bfults> hsivonen: right, which I think handles the general case well enough without going into full-blown rich app land where mom & pop are never going to want to dabble
# [19:38] <bfults> [as creators], mind you
# [19:38] <Dave> Simple expressions aren't full blown rich app land, if you want to look at those, you are in another space.
# [19:38] * Parts: zcorpan (zcorpan@84.216.40.185)
# [19:38] <@DanC> not fun indeed. shipping software products is mostly working around other people's bugs.
# [19:38] <bfults> so I guess the question becomes: why is XForms insufficient? or why is <datagrid> insufficient?
# [19:39] <bewest> are we talking about html in here?
# [19:39] <@DanC> (I must have lost track; I thought the discussion was on why XForms-like declarative stuff was necessary or worthwhile)
# [19:39] <Dave> it still is I think.
# [19:40] <bewest> I joined late, but it doesn't seem like it
# [19:40] <Dave> some people don't agree that HTML should be more than a write only format as far as a broader audience of authors are concerned.
# [19:40] <mjs> anyway, I think HTML forms improvements should focus primarily on the kinds of ways that HTML forms are used currently
# [19:41] <mjs> if you look on the web today, you see a lot of login forms, order forms, quizzes, registration forms, search fields, and so forth
# [19:41] <bewest> are there simpler problems we can solve first? :-)
# [19:41] <gsnedders> mjs: app specific meaning for specific apps using the framework, or web apps?
# [19:41] <hsivonen> as I side note, I found the discussion about declarativeness vs. scripting at Mikko Honkala's thesis defense interesting. (my notes are at http://hsivonen.iki.fi/honkala-xforms/ )
# [19:41] <mjs> but you don't see a whole lot of spreadsheets
# [19:41] <mjs> gsnedders: I meant specific apps using the framework, in this particular case
# [19:41] <@DanC> I confess to having lower aspirations than Dave does... "ways that HTML forms are used currently" seems like a sufficiently worthy challenge, to me.
# [19:41] <Dave> The idea is to be able to use simple declarative techniques for common kinds of form logic in place of scripting as a way to enable better authoring tools.
# [19:41] <mjs> I think html forms improvements should "pave the cowpaths" and make current use cases work better and go beyond some of their most painful limitations
# [19:41] <bfults> agreed with mjs
# [19:41] <bewest> me too
# [19:42] <mjs> I don't think we should invent a language for a use case that basically does not happen on the web today
# [19:42] <mjs> I don't believe that minor tweaks will lead to an explosion of spreadsheet-style content on the web
# [19:42] <bewest> this method is succeeding in microformat and whatwg communities
# [19:42] <Dave> After all I have shown that it can be done on perhaps 99% of browsers using a cross browser script that compresses to 6KBytes.
# [19:42] * chaals sees zillions of spreadsheets :(
# [19:42] * hsivonen agrees with mjs, too
# [19:42] <bewest> if we are talking about spreadsheets I'm certain we're not talking about html
# [19:42] <Hixie> as the only person here who works for a company running a web-based spreadsheet tool, i have to agree that while html should provide better primitives, having the spreadsheet calculation part in the ua doesn't seem critical, as it is easily done in JS (and if done in JS, we can expose whatever language we want, instead of only what the spec wants).
# [19:43] * Dave feels sorry for chaals and suggest that a few beers will make see better at least for a while
# [19:43] <Hixie> (dave's code in particular shows how easy it is to do today without html extensions)
# [19:43] <Hixie> (and seems like the best argument against adding it to the language)
# [19:43] <Dave> Hmm, it seems that HTML as PDF is all that most people here aspire to.
# [19:44] <bewest> not sure why you would infer that
# [19:44] <bewest> scope is an issue
# [19:44] <Dave> But it would be nice to be able to standardize such use of HTML attributes with JS libraries.
# [19:44] <mjs> lots of JS libraries do just fine without being codified in a web standard
# [19:44] <Dave> If browser vendors are slow to embrace change that's a shame but it should hold everyone else up.
# [19:45] <Hixie> the most commonly implemented features probably deserve their place in the standards, but spreadsheet-like calculations are very rare
# [19:45] <bewest> are there simpler problems to solve before spreadsheet?
# [19:45] <Dave> Being able to validate your documents is seen as important for many.
# [19:45] <Hixie> anyway
# [19:45] <bewest> simpler/more common?
# [19:46] <Dave> what is so hard about calculate="x+y" I don't get it?
# [19:46] <mjs> you can only make it simple by sweeping the hard parts under the carpet
# [19:46] <Dave> Not at all.
# [19:47] * Joins: hober (ted@66.162.32.234)
# [19:47] <hsivonen> Dave: the problem I have with it is that I don't believe that real world will be as simple as that, so the use case will call for JS onchange handlers anyway
# [19:47] <Hixie> what's so hard about onforminput="value = x.value + y.value" ?
# [19:47] <mjs> "undefined behavior" == "sweeping it under the carpet"
# [19:47] <bfults> Dave: I don't think the complaint is about difficulty
# [19:47] <bfults> it's about scope.
# [19:47] <bewest> Dave: are you suggesting that adding a spreadsheet feature is the simplest problem we can talk about wrt html?
# [19:47] <bfults> going beyond the scope of what the WHAT WG has already done in the direction of spreadsheets seems contrary to the more practical goals of this WG
# [19:48] <Dave> If Opera had done this in the first place, you would all be arguing for it, this seems like NIH to me.
# [19:48] <mjs> improvements for spreadsheets are, to me, less interesting than improvements for login forms or checkout forms
# [19:48] <bfults> agreed
# [19:48] <mjs> I work for an Opera competitor
# [19:48] <bewest> yeah, if we're goign to discuss some kind of <spreadsheet> perhaps we can also discuss <openid> or something
# [19:49] <mjs> I'm not sure how that would lead to me considering something implemented in Opera as IH, and something brand new as NIH
# [19:49] <bfults> <cookbook> will be my FSM
# [19:49] <Hixie> where is "here" in this context?
# [19:49] <Dave> I would encourage people that can to join W3C's security context WG as usable security is very important to the web.
# [19:49] <Hixie> if there's one thing that whatwg has been good at, it's ignoring the source of comments, and treating them all equally
# [19:50] <Hixie> NIH is definitely not a problem in the WHATWG, that's one of the few things i can say with certainty :-)
# [19:50] <hsivonen> to me, the forms wg attitude towards WF 2.0 has seemed more like NIH
# [19:50] <Hixie> in fact, there's at least one feature in xforms transitional that has been noted already for changes we need to do to wf2
# [19:50] <Hixie> though i've forgotten what it is
# [19:50] <Hixie> it's on the pile somewhere
# [19:52] <Dave> I hope that you will do me the courtesy of examining the details properly.
# [19:52] <Hixie> (i mentioned it in the review that karl sent you, whatever it was)
# [19:52] <Dave> That review was laughable.
# [19:52] <Hixie> well it wasn't a formal review :-)
# [19:53] <Hixie> though i'm curious as to what you didn't think was appropriately examined
# [19:53] <Dave> I am very happy to discuss the technical details, and we could perhaps pick something easier to start with.
# [19:54] <Dave> For instance, the ability for people to type dates without being forced to use the date picker.
# [19:54] <@DanC> (I'm off to lunch, I think. I wonder if I should dismiss the Zakim agenda deely.)
# [19:54] <Dave> It's getting late here, so I will have to leave v soon.
# [19:54] <Hixie> wf2 doesn't require uas to do a date picker
# [19:54] <Hixie> it doesn't constrain ui at all, in fact
# [19:54] * Quits: bkode (bosky101@125.16.223.235) (Ping timeout)
# [19:54] <Hixie> uas are encouraged to compete to make better interfaces
# [19:54] <mjs> well anyway this is pretty far off-topic from organization of the Forms Task Force
# [19:55] <Dave> It would be good to have wider access to WF2 implementations other than Opera9.
# [19:56] <Dave> I checked and it doesn't seem practical to fully implement WF2 on Firefox just from JavaScript.
# [19:56] * Parts: robert (rbrodrec@66.151.50.244)
# [19:56] <mjs> I strongly suspect you could do most of it with XBL
# [19:56] <mjs> (Mozilla XBL)
# [19:57] <Hixie> certainly more implementations would be nice. but it's early days yet. the draft isn't even in CR yet.
# [19:57] <Hixie> having any implementations at all is impressive, especially in a top-4 web browser
# [19:57] <Dave> Gecko imposes constraints on the form object model that stopped me from getting the form attribute to work correctly.
# [19:57] <Dave> Well note that XFT works on perhaps 99% of all modern browsers (based on what browsers we see visiting W3C site)
# [19:58] <Dave> But it would be great to more implementations of Wf2 to try out.
# [19:59] <Hixie> there's an implementation of wf2 for IE6
# [19:59] <Dave> That wasn't complete when I looked at it ...
# [19:59] <Hixie> sure
# [19:59] <Hixie> neither's opera9's implementation :-)
# [19:59] <Dave> anyway time for me to go, enjoy the rest of the day.
# [20:00] <Hixie> also, wf2 is designed from the ground up to be usable without implementations, e.g. the combo-box control will gracefully degrade in legacy UAs to a text field and a select box
# [20:00] <Hixie> later
# [20:00] * mjs is now known as mjs_lunch
# [20:03] <hsivonen> hmm. the log linked to from the topic doesn't seem to be accumulating
# [20:05] <@DanC> RRSAgent, pointer?
# [20:05] <RRSAgent> See http://www.w3.org/2007/03/21-html-wg-irc#T19-08-51
# [20:06] <@DanC> odd.
# [20:08] * Joins: tylerr (tylerr@66.195.32.2)
# [20:08] <tylerr> Afternoon all.
# [20:10] <hsivonen> tylerr: hi
# [20:10] * Quits: kingryan (kingryan@66.92.180.242) (Ping timeout)
# [20:10] <tylerr> Hey there hsivonen.
# [20:13] <tylerr> Looking forward to getting involved in this. Awaiting my permissions for joining the WG. **smiles**
# [20:13] * Joins: kingryan (kingryan@66.92.180.242)
# [20:21] * Quits: kingryan (kingryan@66.92.180.242) (Ping timeout)
# [20:21] * Joins: kingryan (kingryan@66.92.180.242)
# [20:35] * Quits: kingryan (kingryan@66.92.180.242) (Quit: kingryan)
# [20:42] * Joins: kingryan (kingryan@66.92.180.242)
# [20:43] * Quits: kingryan (kingryan@66.92.180.242) (Quit: kingryan)
# [20:46] * anne still isn't convinced the charter requires a separate Task Force to work on forms...
# [20:46] * mjs_lunch is now known as mjs
# [20:46] <mjs> anne: it requires a task force, but it's kind of unclear what is supposed to be delegated to the task force
# [20:47] <anne> just discussion about architecture it seems
# [20:48] <anne> since our architecture is sort of fixed...
# [20:48] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [20:53] * Joins: gavin (gavin@74.103.208.221)
# [20:54] <mjs> I don't understand what "compatible architecture" even means
# [20:55] <anne> they have this idea "tag soup -> magic -> xforms -> profit"
# [20:55] <anne> i'm not sure if that's feasible though
# [20:56] <mjs> some of the arrows are in the wrong direction
# [21:03] <tylerr> Here's a question for you. I'm interested in working in any capacity on this so long as it doesn't interfere (too) much with my normal work schedule. Where would you suggest I start?
# [21:03] <mjs> join the working group, follow the mailing list, give feedback on areas of discussion
# [21:03] <mjs> tylerr: do you work for a w3c member?
# [21:04] <anne> review http://www.whatwg.org/specs/web-apps/current-work/ maybe...
# [21:04] <tylerr> mjs: No, though our biggest client is Microsoft. So almost. **winks**
# [21:05] <tylerr> And I've put in my application to join the WG.
# [21:05] <tylerr> anne: Looking for items that might need clarification and such?
# [21:05] <tylerr> Or review meaning get up to speed?
# [21:06] <mjs> tylerr: many parts of that spec could use comments
# [21:06] <tylerr> Ah righto.
# [21:06] <mjs> there are all sorts of issues, ranging from compatibility with existing practice, to implementability, to spec lawyering detail, despite Hixie's best efforts to avoid such issues in the more complete parts
# [21:07] * tylerr nods.
# [21:11] * Joins: colin_lieberman (colin@69.17.50.227)
# [21:14] <mjs> I think if we adopt Web Apps 1.0, we need to have a featureset review
# [21:14] <mjs> (and same for WF2)
# [21:14] <mjs> before reviewing technical details
# [21:16] <colin_lieberman> How much time would you alocate for a featureset review? A week? Less than a week?
# [21:20] <mjs> I dunno, I have no idea what features may be controversial
# [21:21] <mjs> I would say people should just flag what they think are problem areas rather than necessarily trying to resolve every point
# [21:21] <Hixie> any idea what features you'd consider out of scope?
# [21:21] <mjs> like Microsoft may object to the parsing part
# [21:21] <mjs> so we'd want to discuss that
# [21:22] <mjs> I dunno, haven't read the whole spec closely enough
# [21:22] <colin_lieberman> What about features where there is a perceived need, but the feature is not currently in the doc?
# [21:22] <mjs> I think APIs that are language-independent we should consider devolving to Web API
# [21:22] <mjs> colin_lieberman: I think proposing new features can happen after we have a baseline
# [21:22] * Joins: Deeder (Deeder@86.192.25.183)
# [21:23] <Deeder> Hello, World !
# [21:24] <Hixie> mjs: i'm skeptical of doing that given the history of doing that :-) but in principle i agree
# [21:24] <tylerr> Hi Deeder.
# [21:25] <mjs> Hixie: well, it might not require a person doing it, just more work to make a more modular spec, and yes, I realize some things are hard to split out cleanly
# [21:25] <Hixie> yeah, i definitely need to start splitting up the spec
# [21:26] <Hixie> should get on that in the coming months for sure
# [21:27] <colin_lieberman> Splitting up in what way?
# [21:27] <mjs> but basically I chewed out the SVG WG a lot for speccing things that should be cross-language APIs and I would rather not appear unprincipled on this point
# [21:28] <Hixie> colin_lieberman: chapters and separate specs
# [21:28] <Hixie> mjs: totally
# [21:29] <Hixie> i don't understand Dave's post to public-html just now. he says he'd like to make things more declarative and less scripting-based, and then says his proposal is based on javascript.
# [21:31] <tylerr> How does that work?
# [21:31] <mjs> Hixie: I think his idea is that in practice people should use a vaguely defined subset of JavaScript that is side-effect free and easily parseable
# [21:31] <mjs> his implementation works by doing regexp substitutions on JS code to make the magic variables work, which makes me cry
# [21:31] <Hixie> maybe i'm just too close to the UA side to understand how that counts as declarative
# [21:32] <Hixie> if you have to implement a turing-machine-equivalent UA to do it, it's not declarative, surely
# [21:32] <mjs> he invented a new ad-hoc quasi-declarative language and is pretending it's JS
# [21:33] <mjs> and in practice, the rest of JS is available, but actually using it does weird unpredictable things
# [21:34] <mjs> I think if you want to define a JS subset for round-trippable expressions, you could just as well use WF2 and have an authoring tool that won't work if you don't stick to the subset
# [21:40] * bewest still hasn't heard any html discussion
# [21:40] <bewest> all this seems very hypothetical
# [21:41] <mjs> I don't think we should keep talking about forms
# [21:41] <tylerr> I'm all for HTML talk. :)
# [21:45] <mjs> forms are html of course, but I don't think more talk will result in a meeting of the minds
# [21:46] <mjs> then again, Dave had to go, so I am not sure there is much disagreement left
# [21:46] <mjs> at some point I'd like to evaluate XForms 2 against what we think are common real-world cases of forms
# [21:46] <mjs> er
# [21:47] <mjs> Web Forms 2
# [21:47] <mjs> sorry, bad thinko there
# [21:50] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro)
# [21:55] <Deeder> it might be interressant to have a objective comparative of both forms features
# [22:00] <anne> you must be Dutch!
# [22:00] * anne wonders how many Dutch people joined the WG
# [22:02] * Quits: chaals (chaals@70.21.184.118) (Ping timeout)
# [22:02] * tylerr considered moving there at one point.
# [22:11] * Joins: jgraham (jgraham@85.210.140.237)
# [22:11] <anne> getting full here
# [22:11] <anne> 37 vs 28
# [22:12] <tylerr> What's that anne?
# [22:13] <anne> the soul match between #whatwg and #html-wg
# [22:14] <tylerr> Ahh.
# [22:14] * Quits: colin_lieberman (colin@69.17.50.227) (Quit: colin_lieberman)
# [22:16] <hober> There's a significant amount of overlap too
# [22:17] <tylerr> I've only just gotten involved (read yesterday) so any overlap is purely more information for me to digest. :)
# [22:18] <@DanC> I'm headed out the door in a minute, but... a parting thought:
# [22:19] <@DanC> how about a teleconference to give an FYI presentation of HTML5 ... maybe some HTML 4 too... or just the diffs or something. Hixie? Chaals? anne? interested to put together 10 or 20 slides?
# [22:20] <@DanC> and answer questions, of course.
# [22:20] <tylerr> Lovely. I'd attend.
# [22:20] <@DanC> and maybe I'll take issue-list notes while we're at it.
# [22:21] <tylerr> This would be open to anyone?
# [22:21] <Hixie> DanC: not sure what exactly you mean?
# [22:21] <@DanC> I'll try to send mail later today. bonus points to anybody who beats me to it
# [22:21] <@DanC> I mean you'd say what HTML5 is, or at least how it's different from HTML4, by way of getting some of us who haven't followed whatwg quite so closely, up to speed
# [22:21] <Hixie> oh wow
# [22:21] <Hixie> that's a big subject
# [22:22] <Hixie> not sure how to summarise it in a 10 minute presentation
# [22:22] <Hixie> i could probably do a 15 second summary followed by a few examples
# [22:22] <@DanC> I was thinking 30 or 40 minutes of presentation. still a challenge, yes.
# [22:23] <@DanC> perhaps you could do a 3 minute intro, and then we could get a few other perspectives.
# [22:23] <Hixie> i don't really think a phone call would be a good medium for this though
# [22:23] <@DanC> I'm inclined to try it
# [22:23] <Hixie> how many people can the bridge carry per call? i don't want to have to do this 15 times or whatever...
# [22:23] <Hixie> wouldn't e-mail be a better medium?
# [22:23] <@DanC> it's fine by me if you'd rather have somebody else do the presenting. Anybody who knows more than I do is qualified to give the talk ;-)
# [22:24] <@DanC> e-mail preparation would be great; but there's nothing like real-time, undivided attention
# [22:24] <tylerr> Have you considered setting up a Campfire chat?
# [22:24] * Hixie wouldn't really call a telecon "undivided attention"
# [22:24] <@DanC> ok, mostly-un-divided-attention
# [22:24] <Hixie> in fact i'd say reading a mail is less divided :-)
# [22:25] <Hixie> and goes at the pace of the reader :-)
# [22:25] <@DanC> no, I don't know what Campfire is
# [22:25] <tylerr> http://www.campfirenow.com/
# [22:25] <tylerr> A 37signals product. Business chat for groups.
# [22:26] * @DanC is away: out of the office
# [22:27] <tylerr> It could come in handy for group discussions where file/image sharing is needed.
# [22:29] <hsivonen> do W3C teleconferences require a long-distance phone call or is participation possible with libjingle, iChat or Skype?
# [22:34] <marcos_> Skype is ok
# [22:34] <marcos_> hsivonen
# [22:35] <mjs> I don't think a phone call would be a great medium for a technical presentation
# [22:35] <mjs> I think a summary document of new features might be better
# [22:36] <Deeder> anne : I apologize but i'm French, not Dutch (not really better I know...) and here it's now 10.30pm and i'm a little bit tired. So, my previous sentence was obviously awful but I have an excuse. :)
# [22:37] <anne> "interessant" is also French?
# [22:37] <anne> my French is terrible...
# [22:38] <Hixie> "interessant" is french yes, means interesting.
# [22:38] <anne> well, I figured that much
# [22:38] <anne> we probably stole the word than
# [22:38] <anne> s/than/then/
# [22:39] <Deeder> :)
# [22:39] <tylerr> mjs: Did you take a look at that Campfire link I provided?
# [22:39] <tylerr> It's an interesting take on group chat.
# [22:39] <tylerr> Which might work well for the WG.
# [22:40] * anne wonders how it's different from IRC + sharing URLs
# [22:41] <tylerr> Here's a brief overview anne: http://www.campfirenow.com/tour/
# [22:42] <anne> it looks like IRC to me
# [22:42] <Hixie> heh
# [22:42] * tylerr chuckles.
# [22:43] <tylerr> I suppose I'm just a sucker for inline images, group file sharing and pretty UIs. :)
# [22:43] <mjs> tylerr: I don't think changing our collaboration tools is super important at the moment, unless there would be some major benefit
# [22:43] <tylerr> Oh sure mjs, I was just suggesting that tool because the topic of teleconferencing came.
# [22:44] <tylerr> Not as a shift in daily communications.
# [22:44] <mjs> I'd rather avoid telecons entirely
# [22:44] <mjs> as a matter of personal taste anyway
# [22:44] <tylerr> Do you think sticking to mailing lists and IRC would suffice?
# [22:44] <hsivonen> marcos_: ok. good
# [22:45] * Joins: kingryan (kingryan@66.92.180.242)
# [22:45] <Hixie> certainly e-mail and irc only has worked well for the whatwg
# [22:46] <hober> well, email+irc+wiki+forum
# [22:46] * tylerr nods.
# [22:46] <tylerr> For presentations there is always S5 (http://meyerweb.com/eric/tools/s5/), which can be delivered online quite nicely.
# [22:47] <mjs> meeting face to face can be nice for presentations and selected high-bandwidth conversations
# [22:47] <tylerr> This is why everyone needs iChat. ;)
# [22:48] <mjs> but phone doesn't really win over emails
# [22:48] <mjs> plus IRC
# [22:48] <mjs> IRC does suck in the lack of inline images and the sucky file transfer (other than URLs, but that means you have to post something)
# [22:49] * tylerr nods.
# [22:55] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [23:00] * Quits: hsivonen (hsivonen@130.233.41.50) (Ping timeout)
# [23:01] * Joins: gavin (gavin@74.103.208.221)
# [23:02] * Joins: hsivonen (hsivonen@130.233.41.50)
# [23:13] * Joins: Lachy_ (chatzilla@220.245.91.147)
# [23:15] * Quits: kingryan (kingryan@66.92.180.242) (Quit: kingryan)
# [23:17] * Joins: kingryan (kingryan@66.92.180.242)
# [23:22] * Quits: Deeder (Deeder@86.192.25.183) (Client exited)
# [23:59] * Quits: anne (annevk@86.90.70.28) (Ping timeout)
# Session Close: Thu Mar 22 00:00:00 2007

The end :)