03:35:05 RRSAgent has joined #html-wg 03:35:05 logging to http://www.w3.org/2007/03/21-html-wg-irc 03:35:24 DanC has changed the topic to: W3C HTML WG http://www.w3.org/html/wg/ (this channel is logged for all the world to see) 03:54:43 RRSAgent, make logs world-access 04:15:30 Lachy has joined #html-wg 04:17:22 Lachy has joined #html-wg 04:17:52 Hi DanC 04:25:32 marcos has joined #html-wg 04:50:15 kingryan has joined #html-wg 04:53:22 Kuruman has joined #html-wg 04:53:37 Kuruman has left #html-wg 04:58:28 Owner has joined #html-wg 05:23:06 bill has joined #html-wg 05:24:41 bfults has joined #html-wg 05:50:24 Lachy has joined #html-wg 05:52:15 Lachy has changed the topic to: W3C HTML WG http://www.w3.org/html/wg/ - http://www.w3.org/2007/03/21-html-wg-irc (logged) 06:20:15 Hixie has joined #html-wg 06:23:19 Hixie has joined #html-wg 07:00:51 bosky101 has joined #html-wg 07:01:16 greetings everyone... 07:26:01 Stefan has joined #html-wg 07:27:07 Good morning from austria. 07:36:11 henrik has joined #html-wg 07:37:34 Hello everyone! 07:44:05 Hello 08:00:49 Lachy has joined #html-wg 08:01:04 Lachy has joined #html-wg 08:13:52 NicolasLG has joined #html-wg 08:14:27 Hi everybody ! 08:14:35 hello 08:15:15 is this a post or pre meeting chat ? 08:15:51 I don't know, I just received DanC's mail about this chan 08:16:09 I don't know when it start too.. 08:17:32 Me too 08:18:26 I think it will be dificult to bring everybody at the sametime... 08:18:43 how about a round of introduction first then... 08:19:48 i presume most of you are from the academia? 08:21:05 I'm a 22 yrs old student ^^', I follow the mailing list since yesterday.. 08:23:13 im a developer from india ,keen on all things that deal around events ,xml . 08:25:35 nice :) what time is it in india ? 08:30:09 its 2pm in the afternoon hmmm .... mar 21st ... ok i think i;lll just turn spectator now till we get into any discussions .(apart from the fact that this chat is archived ..so migh as well stick to the topic ) 08:42:11 does anyone here deal with server side events ? 08:49:05 hsivonen has joined #html-wg 08:52:40 icaaq_ has joined #html-wg 09:04:00 krijnh has joined #html-wg 09:19:50 marcos has joined #html-wg 09:25:36 bkode, I think server-side events are beyong the scope of this channel 09:26:20 anne has joined #html-wg 09:28:09 marcos: i agree 09:28:41 :) 09:33:02 servers-side events are part of HTML5, fwiw 09:33:11 (and implemented in Opera) 09:35:28 I was just going to say that that one was best left for anne:) 09:35:59 I have not yet looked at what Opera is doing about that... 09:37:58 and related things 09:38:32 yeah, looks pretty cool. Kinda like flash's xml sockets 09:39:50 icaaq, maybe we make part of the scope :) 09:41:27 marcos: :) 09:41:52 did you guys read the charter? 09:42:08 I'm still in shock about the vision document 09:42:15 what vision document? 09:42:24 oh man, you are gonna love it!!!! 09:42:46 ...searching for it.... 09:43:08 http://www.w3.org/2007/03/vision.html 09:43:10 http://www.w3.org/2007/03/vision.html ? 09:43:14 ok 09:43:18 that's the one :) 09:43:45 anne, I started reviewing XHR tonight 09:44:13 just a few editoral mistakes in it so far, but it's really good (I'm about 1/2 way through) 09:45:15 Hixie was right, it does read like one of his specs :-) 09:45:29 I tried to align it a bit more 09:45:30 the HXR doc? 09:46:08 marcos, please review http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type=text/html;%20charset=utf-8 09:46:16 and not the version on TR/ 09:47:02 that vision document is just there to please IBM and other XForms loving companies I think 09:47:58 anne, ok and ok 09:48:23 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 09:48:58 -Opera 09:49:16 Opera and WebKit are the exceptions 09:49:16 hehe, that one made me laugh too 09:49:35 but opera does tagsoup too, right anne? 09:49:43 yeah, it does both 09:50:36 character decoding is the dirty secret of browser XML support even when the XML support is otherwise non-bogus 09:50:47 marcos, yes, but at worst 09:50:57 although actually, tag soup parsing isn't that bad 09:51:02 it just needs to be standardized 09:51:10 in retrospect, browsers should have supported only UTF-8 and UTF-16 on the XML side 09:51:28 hsivonen, why? 09:51:32 to slow down adoption of XML even more? 09:51:43 not a bad idea, really 09:51:50 Lachy: to get rid of a huge legacy back door 09:51:52 although, I agree it would have been ideal, reality tells me it wouldn't work 09:52:14 anne: getting UTF-8 right is a lot easier than getting the other XML stuff right on the producer side 09:52:22 just as we're now getting requests for lenient XML parsers, we'd also get requests for legacy encodings 09:52:30 anne: most producer objections to UTF-8 are bogus 09:53:38 anne, from the xhr spec, what is the scope of 'this' in the following example: 09:53:40 var a = {funky: function(response){ alert(this)}} 09:53:42 var client = new XMLHttpRequest(); 09:53:44 ... 09:53:46 client.onreadystatechange = a.funky; 09:54:19 this points to the object 09:54:26 as with all event listeners? 09:54:36 (this doesn't work in some browsers today, btw) 09:54:48 that is what I am wondering 09:54:58 because I've had problems with that 09:55:26 in the Yahoo! widget engine, for example, this is [XMLHttRequest] 09:55:58 and I think I got something different in Dashboard 09:56:03 webkit 09:56:24 you can get different results for every single feature I think 09:56:37 I don't recall the xhr spec being clear on this... 09:56:37 one of the reasons we try to standardize it in one way 09:56:51 Having another look 09:56:53 it's implicitly clear by making XHR an EventTarget 09:57:04 and having onreadystatechange take an EventListener 09:57:11 Ashe has joined #html-wg 09:57:39 so my above example would not work 09:58:00 depends on what yo umean with work and it would in Opera 09:58:08 and might work in nightly builds of Firefox 09:58:17 might work in nightly builds of WebKit, dunno 09:59:25 Ashe has joined #html-wg 10:28:47 chaals has joined #html-wg 10:31:05 rrsagent, pointer 10:31:05 See http://www.w3.org/2007/03/21-html-wg-irc#T10-31-05 10:32:03 that's nice 10:33:13 although in amounts of time you prolly lost one 11:00:59 jmb has joined #html-wg 11:08:32 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 ? 11:09:16 dunno 11:09:27 we're already extending HTML 11:09:49 it would make sense if the W3C simply followed what's already been done 11:09:52 (to me, anyway) 11:11:22 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 11:11:57 well, to exit CR sure... 11:12:12 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 ? 11:12:52 is just a convenient shorthand for an API, actually 11:13:19 how close are we to closing in on an implementaion ? 11:13:32 it's implemented already 11:13:34 We have one at Opera. 11:13:52 so what if we found different ways of implementing it . 11:14:12 then we would have two different implementations. 11:14:24 If they are not interoperable, this would be a good argument to think harder... 11:14:33 bkode, what do you mean? Implementation details are not relevant 11:15:14 alright. thanks for enlightening me on that... taking anoterh example... we all know of the onclick 11:15:18 interoperable is quite a heavy term imo, almost nothing is interoperable at this point 11:15:22 but most of it is usable 11:15:49 if you are faimiliar with idempotent events... ie .. basically to prevent duplication . 11:16:18 what would ur thoughts be on introducing an onclickwhen or when attribute 11:16:42 rather than having the complexity in managing idempotent events on the server side 11:17:33 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' 11:18:35 i have a javascript implementaion of this ... just to show how it would be otherwise..and how an could easen things. 11:19:04 do you have some more elaborate documentation? 11:19:08 http://bhaskervk.com/libraries/reusableJS/examples/idempotentEvent.html 11:19:16 anyway, ideas are best posted on some wiki or the whatwg mailing list 11:20:50 thank you . 11:45:46 bkode, when suggesting ideas, it's best to present some clear use cases to be solved, rather than proposing a solution. 11:46:27 it may turn out that existing features can already satisfy those use cases without introducing any more, or a better solution can be found 12:11:42 ROBOd has joined #html-wg 12:33:07 icaaq_ has joined #html-wg 12:43:46 hasather has joined #html-wg 12:45:43 gavin has joined #html-wg 13:08:57 marcos_ has joined #html-wg 13:22:19 Charl has joined #html-wg 13:22:21 :) 13:54:39 glazman has joined #html-wg 13:54:44 hi there 13:55:41 allo 13:57:05 salut glazou 13:57:30 schnitz has joined #html-wg 13:57:38 hi 13:57:50 icaaq_ has left #html-wg 13:59:57 chaals: thanks for the forward to Art 14:00:58 no worries. 14:01:11 (anne is your contact at Opera for the WAF group, BTW) 14:01:40 rotfl 14:04:35 :p 14:07:07 usually reading lets me get to sleep, but last night it kept me up late 14:17:19 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... 14:17:34 169 14:20:59 yup 14:21:14 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? 14:22:30 opera and volantis said yes 14:22:55 apple hasn't checked yet afaik but I believe Maciej intends to fill it in 14:23:45 although actually, volantis didn't say yes for May 14:23:57 I'm a little paralyzed by the prospect of 2 international trips in May. I'm already behind on Banff travel details. 14:24:00 Dave Raggett is busy or something 14:24:19 yeah, the wbs isn't very forthcoming about where people are from. 14:24:50 well, in theory all have equal say... 14:25:49 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 14:26:39 aha... dom points me to http://www.w3.org/2002/09/wbs/40318/ftf07/results?view=compact , which has affiliations 14:28:10 voting theory: http://www.w3.org/2005/10/Process-20051014/policies.html#Votes 14:28:11 i suppose 14:28:51 voting is for when consensus breaks down. if we can't get consensus on a 1st ftf meeting, I won't bother. 14:29:15 consensus meaning: a critical mass in favor, and no objections 14:29:59 for "critical mass", I'm looking for the "3 browsers" from the charter, plus at least a handful of authoring tools, content developers, etc. 14:30:44 hmm... I wonder about a WBS form with boxes for content developer, software library developer, etc. 14:31:01 otoh, F2F meetings can just be planned... iirc no real descisions can be made there anyway, right? 14:31:30 a WBS form can either be started or finished at a ftf meeting, but not both 14:32:21 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. 14:32:52 what's a formal descision? 14:33:44 umm... a decision that follows some articulated form, I guess... 14:34:28 ... i.e. a decision of the WG, which would not be open for further discussion unless new information came to light 14:34:34 say x proposes a feature and y implements it in the spec 14:34:40 does formal descision take place? 14:34:46 a formal* 14:34:52 no 14:35:01 y could undo that part of the spec the next day 14:35:10 right 14:35:17 gorme has joined #html-wg 14:35:36 but then x might complain, and z weighs in, and perhaps consensus seems elusive; the chair then adds it to an issues list... 14:36:17 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. 14:36:39 as are x, z, and everybody else in the WG. 14:37:05 k 14:39:37 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. 14:40:09 that and who'll be the editor is prolly what needs to be decided first, yes 14:40:15 right 14:40:58 and maybe do the form part separately or so, it's not entirely clear from the charter how that should work 14:41:16 agreed, that needs to be figured out 14:41:21 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. 14:42:06 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? 14:42:24 most of it is intertwined 14:42:29 and needs to be 14:42:35 DanC, thats an interesting possibility, I had been thinking in that direction too 14:42:50 i suppose you can split some APIs, but it's not really feasible 14:42:57 also, some folks said that there are part of XHTML2 that seem interesting aswell 14:43:28 s/part/parts 14:43:44 oh? I guess I missed that. who advocated parts of XHTML2? 14:44:03 (btw, why is backwards compatibility not in the charter? is it implied?) 14:44:12 ok, wait, let me dig it up in the archives, brb 14:44:51 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." 14:45:25 billmason has joined #html-wg 14:45:36 yeah, syntax compatible... 14:46:32 oh well, if it's not compatible it won't get passed CR 14:46:34 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. 14:46:35 not much of an issue 14:46:53 oh cool 14:47:27 e.g. "Similarly, there are several things in XHTML2 that are not in HTML5 14:47:27 I don't expect to wait for CR for stuff like compatibility, testing, etc. 14:47:27 but which I think are architecturally more sound and should be in there." 14:47:36 http://lists.w3.org/Archives/Public/public-html/2007JanMar/0085.html 14:48:02 he doesn't really elaborate much 14:48:20 does 0085 give any examples of such things? I don't see any. 14:48:23 or was that the / < section> debate? 14:48:54 I'm starting to think of the HTML WG as the QA department of the WHATWG. 14:49:25 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 14:49:28 some people see it as the getting rid of patents department... 14:49:35 i.e. WHATWG brainstorms and designs, and then the HTML WG plays "defense", makes tests, worries a little about laywers, etc. 14:50:09 schnitz, only parts that are backwards compatible could be taken and afaik that has already happened 14:50:43 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. 14:51:37 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 14:52:02 s/emails/tests/ 14:52:03 bah 14:52:09 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. 14:52:44 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 14:53:05 somebody sent some pointers to tests; was that you, anne? responding to that is on my todo list. 14:53:22 i e-mailed pointers to testsuites for Web Forms 2 and 14:53:28 and HTML parsing 14:53:42 gavin has joined #html-wg 14:53:49 and I think James added some tests for encoding sniffing in text/html which he recently added to html5lib 14:54:03 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." 14:54:26 DanC, aha, good, that was a misunderstanding, thank you 14:55:11 well, I don't want XForms Transitional. It does nothing that WF2 can't handle, and WF2 is already much more well defined 14:55:27 ... and implemented in one UA 14:55:46 Lachy, thats fine, we can debate this in the public-html list 14:55:49 (and has a testsuite + several scripted implementations) 14:55:55 (fwiw) 14:56:45 I thought the WYSIWYM editors thread was great... I hope to explore some of the criticisms of WF2 w.r.t. authoring. 14:57:46 on the other hand, forms authoring is not MacWrite 14:58:52 but right now, I'm off to a GRDDL WG telcon... 14:58:54 DanC, there are some really good tutorials out there :-) 14:59:00 right, me too... 14:59:02 laters... 15:00:07 hasather has left #html-wg 15:02:36 gavin_ has joined #html-wg 15:15:12 mjs has joined #html-wg 15:16:09 mjs has joined #html-wg 15:21:24 http://krijnhoetmer.nl/irc-logs/ logs too 15:21:37 hasather has joined #html-wg 15:21:54 Yeah, it does 15:22:03 Don't know why 15:22:47 wfm 15:23:07 wfm? 15:23:53 krijnh: means works for me 15:24:16 Ow, I thought wait for me :) 16:32:47 Bye everybody ! 16:37:45 danc? 16:38:28 do you have systems foo to sort out an invited exeprt's password problems (Gregory Rosmaita) for joining ths group? 16:38:38 or should I go to sysreq? 16:39:30 hmmm. lunchtime. 16:43:57 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. 16:44:05 oki 16:44:12 dbaron has joined #html-wg 16:44:28 I think I have about a dozen people who wrote to me only and not to karl; I should get back to them sometime. 16:44:57 but considering that now >100 people have learned to jump thru the hoops, I figure people can teach each other at this point. 16:45:39 This one is to do with an old account that is not configured according to the current magic, apparently 16:45:50 let's see... 16:47:07 "Gregory Rosmaita is an invited expert with Member access." which means w3m is in the critical path. :-/ 16:47:43 I forget whether that means karl has to ask w3m, or mauro notices automatically somehow or what. 16:48:17 oki. Gregory and I can chase Karl/Mauro 16:50:25 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 16:50:58 or we could do email introductions 16:51:05 or a WBS survey deely 16:51:18 anne has joined #html-wg 16:52:47 chaals: mail sent to Netvibes CEO 16:53:13 gavin has joined #html-wg 16:54:49 DanC, I think the main problem is that it's not clear whether or not the WG has started 16:56:09 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. 16:56:55 perhaps you should send a new e-mail stating that? 16:57:05 I think we can make a ftf decision, now that we've heard from Chris. 16:57:41 well, I've said it in 4 or 5 different mail messages. will saying it LOUDER help? ;-) 16:57:43 glazou, tusen takk 16:58:03 chaals: var så god 16:58:59 glazou: hi :) 16:59:03 tjena 16:59:55 hey chaaaals :-) 17:00:23 icaaq_ has joined #html-wg 17:00:23 'k 17:01:47 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:02:29 hi Hixie 17:02:48 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:03:16 DanC: so i agree that if we want to avoid overlap, testcase development would be a great thing to work on 17:03:27 DanC: it's also one of the most effective ways to guide what the spec says :-) 17:03:34 yeah 17:04:21 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. 17:04:50 heh 17:05:04 kingryan has joined #html-wg 17:05:12 it's easier to write an e-mail than to actually do something 17:05:14 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 17:05:24 much like chatting is an effective way to keep yourself from real work 17:05:54 sometimes chatting is real work 17:06:42 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 17:06:58 so... experimenting with some pointed questions... chaals, dbaron, what do you think about taking on HTML5 wholesale as the baseline? 17:07:39 tantek and I make important decisions re:microformats while walking to get coffee :D 17:07:49 glazou, IIRC, your mail messages say "HTML5 is worth a review; pls give me a copy that will hold still for a bit" 17:08:13 my suggestion was to use html5 as the ground layer for HTML WG work 17:08:21 to do so, we need the head of svn 17:08:30 and be able to review it before it changes too much 17:08:32 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. 17:08:56 bfults has joined #html-wg 17:09:11 But there is a bunch of good stuff there in terms of cleaning up HTML. 17:09:23 I am not saying HTML WG has to agree on the whole html5 spec 17:09:28 yes, chaals, I haven't read the whole thing, but I could do without, say, the 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. 17:09:32 I am just saying we should probably not reinvent the wheel 17:09:40 well the whatwg hasn't agreed on the whole whatwg spec yet either 17:09:41 so... :-) 17:09:43 Dave has joined #html-wg 17:09:47 My suggestion would be to work through HTML 401 and HTML5 side by side, to get a base... 17:10:09 side question, what's the status of the current discussion ? informal chat ? 17:10:10 (but if you want to know what Opera thinks you should email and get an answer from Lars Erik ... :) 17:10:24 [I believe it is informal chat] 17:10:45 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. 17:10:49 fwiw: there's a list of difference with HTML4 on the WHATWG wiki 17:11:07 (apart of course from obvious differences such as that HTML4 defines almost nothing and HTML5 does) 17:11:13 ooh... pointer to list of diffs? 17:11:33 http://wiki.whatwg.org/wiki/HTML_vs._XHTML#Differences_Between_HTML_4.01_and_HTML_5 17:11:39 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. 17:11:45 later glazou 17:12:28 Hixie, the only problem is the 500 new e-mails every month (onlist) 17:12:49 thats a problem in itself, yes 17:12:50 once i start dealing with them i can go faster than that :-) 17:12:59 that was part of the stability issue we had on the list 17:13:00 for xbl2 i was replying to 50 messages a day 17:13:22 yeah prolly 17:13:29 so long as the rate of new messages is less than 50 a day, it's a solvable problem. 17:13:32 Well, all you need to do is reply to another 100/night and you're set, right? ;) 17:13:45 having such a running target is a problem... 17:13:58 I am not saying development should stop 17:14:07 (50 a day comes out to about 10,000 a year, which is well within our current receive rate) 17:14:11 just thats its about establishing trust 17:14:16 The content model of map changed - it is just area, right? 17:14:22 and thats hard to establish when everything is liquid 17:14:30 if people want to review a particular version of the spec, they can refer to the relevant SVN revision 17:15:01 stability, trust & standard belong together 17:15:33 chaals, is now 17:15:39 icaaq has joined #html-wg 17:15:43 chaals, yes 17:16:03 I think its hard to avoid a fork between html-wg and whatwg 17:16:33 not because of evil action, but dynamics 17:16:35 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 17:16:36 i think Hixie already mentioned that the WHATWG spec would be a superset of the HTML work (unless they are in fact the same) 17:16:49 so that shouldn't be a problem 17:17:00 (though yeah, i expect the whatwg spec will always be more detailed if they're not identical) 17:17:18 lets see, I'm not so optimistic 17:17:40 what do you see happening that would stop that? 17:18:01 well, in some places the HTML WG may decide to alter semantics 17:18:08 like not taking parts of HTML 5 17:18:17 in that case the whatwg would have to retro-fit 17:18:20 gsnedders has joined #html-wg 17:18:21 then WHATWG HTML5 would still be a superset... 17:18:21 well then the whatwg spec would be a superset of html 17:18:30 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. 17:18:38 heh 17:18:39 DanC, sure 17:18:44 there's that too :-) 17:18:56 I suppose another exception clause might be that browser vendors are no longer interested in the HTMLWG for one reason or another 17:19:21 well yeah 17:19:37 i mean this is all assuming that we continue to care about the htmlwg, but i don't see why we would not 17:19:41 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. 17:19:49 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? 17:20:09 depends on the change, no? 17:20:13 chaals, sure 17:20:16 yes, surely it depends on the change 17:20:19 well, the HTMLWG largely consists of WHATWG people... 17:20:19 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. 17:20:19 As a general question it seems a bit unanswerable... 17:20:51 chaals, right, and thats why I am saying it may be that a fork can happen between whatwg and html-wg 17:21:10 :s 17:21:14 doesn't seem like something worth worrying about until it happens 17:21:21 (and if) 17:21:27 sure, I won't expand... 17:22:34 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? 17:22:49 yeah, see my blog :-) 17:22:50 I haven't really heard anybody mention anything apart from the patent policy when it comes to fork WA1.0 17:22:53 let's see if i can get a link 17:23:07 sorry, I don't really have time to respond until after lunch 17:23:22 robert has joined #html-wg 17:23:29 danc: http://ln.hixie.ch/?start=1137740632&count=1 17:23:41 danc: no wait 17:23:43 danc: http://ln.hixie.ch/?start=1037910467&count=1 17:23:46 no problem, dbaron ; here's hoping we both find some spare attention at the same time. 17:24:11 heh, I like how the current random flickr picture is of a volleyball team... 17:25:25 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 17:26:14 thanks, Hixie; I just rea-read 1037910467 ... so is HTML5 incompatible with IE6 in this respect? 17:26:19 and opera, for that matter? 17:26:58 yes 17:27:40 DanC: the HTML5 parsing algorithm is as compatible as it gets while keeping the output as a tree that does not have private annotations 17:28:04 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? 17:28:07 (IE not keeping it as a tree in all cases and Opera having private annotations apparently) 17:28:41 DanC: Howcome said that up front 17:28:45 DanC, howcome I think 17:29:09 what do you mean by "operators" Dan? 17:29:12 so opera is happy to either accept the HTML5 parsing design or argue for something different, I gather. 17:29:25 Operators? people of Opera? 17:29:37 chaals earlier used "operators" to mean "people of Opera", I think 17:29:43 ta 17:30:14 yeah, if we disagree with something we'll just raise that on some list 17:30:23 at least, that's what we normally do 17:30:36 I think Chris Wilson has taken a pretty strong position in the other direction. 17:31:33 maybe he'd be happy to use HTML5 as the starting draft, provided certain things like that parsing example go on the issues list. 17:31:40 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) 17:32:11 hsivonen: I thought he said they wouldn't change HTML4 parsing in any backwards incompatible way 17:32:24 so if it were 100% backwards compatible, they could use it 17:32:55 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? 17:32:55 making it 100% backwards compatible would lead to changes to the DOM and other things we'd rather not do I think 17:33:05 (such as figuring out how CSS applies to a non-tree) 17:33:13 danc, I would have to ask Lars Erik to answer that question, and he has kids so is an early-in-the-day type. 17:33:14 gsnedders: well, 100% compat means having a non-tree in some cases, which would be architecturally bad for the other browsers 17:33:29 anne: I'm aware. But It's a subtle and important difference between what was said and what Chris said 17:33:36 ok, noted, chaals 17:33:53 hsivonen, and for the rest of the specs 17:33:54 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. 17:34:41 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. 17:35:04 yeah, that's why we went to such lengths in the whatwg to avoid that 17:35:12 I should finish my post(s) on my goal(s) for the HTML spec. 17:35:28 DanC: do you really want to be compatible in a way that potentially causes tree algorithms not to terminate? 17:35:42 (that wouldn't be nice for Firefox extension writers etc.) 17:35:50 it wouldn't be nice for CSS and the DOM, either 17:36:04 i mean we'd basically have to rearchitect all of the core W3C browser technologies 17:36:15 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. 17:36:29 if they did, then all other browsers would be broken 17:36:59 to the extent Firefox, Safari and Opera function as Web browsers, it has been proven by demonstration that treeness is sufficiently compatible 17:37:16 -Opera 17:37:28 opera has a tree 17:37:34 anne: you guys do have a tree, right? 17:37:36 well, sort of 17:37:36 it's just a tree with annotations to make the css model different 17:37:54 the DOM represents a tree, yes 17:38:52 zcorpan has joined #html-wg 17:38:58 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 17:39:07 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. 17:39:36 jmb, there are some blogposts... 17:40:02 DanC, IE6 would be doing lots of things wrong, not just parsing 17:40:07 jmb: what IE does is not thoroughly publicly documented. 17:40:08 but what doe agreeing to HTML4 actually mean? 17:40:14 *does 17:40:14 IE6 is already doing things wrong today... 17:40:17 same for all other current browser releases btw 17:40:21 compared to all other w3c specs, i mean 17:40:26 much like every other browser 17:40:45 umm... as far as I can tell, IE6 is doing it right by definition for most web users. 17:40:55 jmb: look at the blog posts i posted earlier 17:41:02 hsivonen: of course. any such resource would have to be best-effort 17:41:02 and for people building bank web sites, etc. 17:41:04 mjs has joined #html-wg 17:41:05 jmb: (there are 5, on ln.hixie.ch) 17:41:14 Hixie: ta, will do (I'm reading them now) 17:41:53 DanC, yes, but that doesn't mean it's bugfree 17:41:55 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 17:42:50 hello 17:43:03 hi mjs 17:43:07 that's an amusing URL 17:43:16 DanC: what "it" is IE6 doing right? 17:43:44 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. 17:44:06 it's de facto right 17:44:09 ergo, bank web site designers code to IE6 17:44:13 sure. i just said that IE6 didn't comply with the specs. 17:44:41 the HTML5 spec has gone out of its way to be more compatible with IE pretty much everywhere. 17:44:53 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. 17:45:38 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 17:46:01 DanC: so the non-tree cases are really for rendering compat with Netscape 3 and 4 17:46:24 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. 17:46:32 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) 17:46:49 DanC: i don't think it matters, really 17:47:01 DanC: so long as all the browsers do the same thing, they can code to whatever browser they want 17:47:26 (people will always code towards browsers) 17:48:00 so how do we get to the point where browsers do the same thing in cases where IE6 doesn't make a tree? 17:48:06 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. 17:48:22 DanC: their non-tree is close enough to the other browsers not that it makes little practical difference. 17:48:31 and going forwards, they should do what the spec says 17:48:38 I don't think we should require non-tree DOMs 17:48:43 (even if, imho misguidedly, they decide to do it by having yet another mode) 17:49:03 that's just too abusive, and it seems unlikely code relies on it for compatibility 17:49:04 non-tree DOMs are really not an option. non-tree DOMs would require changing most of the DOM specs and all of CSS. 17:49:24 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 17:49:32 yeah 17:49:35 i've written such code myself 17:49:38 it's confusing as hell 17:49:45 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. 17:49:52 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" 17:50:24 DanC: it seems we can convince them for new content, but not existing content 17:50:30 Hixie, I don't think it's a foregone conclusion that an interesting new HTML spec is _possible_. 17:50:40 gavin has joined #html-wg 17:50:55 DanC: well a non-existing spec (such as an impossible one), is definitely not interesting from a practical perspective 17:51:48 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 17:52:10 Opera, Safari and Firefox are already much closer to each other (and to standards) than they are to IE 17:52:54 I have to admit that my colleague Dave Hyatt is extremely reluctant to make any changes to HTML parser error handling though 17:53:05 even if it would make us more similar to other browsers 17:53:13 he is probably less stubborn than Microsoft though 17:53:32 so, if we had our other co-chair, here are the questions I would raise on public-html: 17:53:35 mjs: luckily for him, the whatwg spec is basically the safari algorithm 17:53:37 even if he got a good regression testsuite? 17:53:47 Hixie: he's scared to make even the minor remaining changes 17:53:54 I try to soothe him 17:53:55 yeah i can understand that 17:53:58 but that's ok 17:53:59 it'll take time 17:54:00 we do have a lot of regression tests 17:54:13 eventually more and more people will use this algorithm and eventually it'll be shown to be safe :-) 17:54:14 though not a whole bunch specifically for parser error handling 17:54:25 so if we had both our co-chairs, here are the top questions I would raise: 17:55:08 1) should we make it possible for anyone to subscribe to public-html? (I think yes, the current state is kind of annoying) 17:55:47 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) 17:55:53 Zakim has joined #html-wg 17:56:01 agenda + should we make it possible for anyone to subscribe to public-html? [mjs] 17:56:05 I'd especially like to resolve #2 before debating individual technical issues too much 17:56:14 agenda + should we use Web Apps 1.0 as a starting point for work? [mjs] 17:56:19 oh yeah, also 17:56:27 where is the agenda? 17:56:32 agenda? 17:56:43 ah. 17:56:45 3) how should we participate in the joint forms task force with the Forms Working Group? 17:56:56 it's also in http space somewhere; I forget where Zakim puts it 17:57:15 agenda + how should we participate in the joint forms task force with the Forms Working Group? [mjs] 17:57:51 any operators wanna play this Zakim agenda game? or mozilla folk? (I guess dbaron is mostly away until after lunch) 17:58:56 do you have a preference re 3) Forms, mjs? 17:59:26 DanC: I don't know, never been on w3c Task Force before 17:59:47 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:00:23 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:00:31 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:00:49 the Forms Task Force seems way beyond that 18:00:59 yes; well outside my comfort zone 18:01:01 it seems like our charter requires doing a large part of our spec in that task force 18:01:12 which is why I argued for not having it 18:01:42 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:01:44 our charter doesn't actually say that 18:01:45 where did the demand for the task force come from? 18:02:02 the charter says that in the task force we can try to work out differences between the HTML and XForms architecture 18:02:08 but not much is required iirc 18:02:39 "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:02:57 so... 18:02:58 it's also moderately straightforward for the taskforce to elect its own chair... er... maybe not; that would involve enumerating the membership somehow. 18:03:33 has it been pre-established that the new XForms Transitional will be published by the W3C? 18:03:33 hsivonen: I think the demand for a task force came from XForms advocates 18:03:38 if the HTML WG and the Forms WG can agree on a task force chair, that would be straightforward 18:03:47 Zakim, take up item Forms 18:03:47 agendum 3. "how should we participate in the joint forms task force with the Forms Working Group?" taken up [from mjs via DanC] 18:03:49 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 18:03:51 XForms Transitional is not a W3C document of any kind 18:04:09 s/2 with/2 but/ 18:04:29 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) 18:04:39 hsivonen, you're not mistaken 18:04:50 hsivonen: you don't get it because it doesn't really make sense 18:04:54 before the w3c publishes xforms transitional, the small matter of it being provably unimplementable should probably be fixed 18:05:04 (it currently relies on computers being able to solve the halting problem) 18:05:06 XForms Transitional is like Web Forms 2 but then from the Forms WG 18:05:32 Dave Raggett seems to have a strongly held vision of HTML as a language for direct representation of spreadsheet-style documents 18:05:47 that seems to be his goal with XForms Transitional 18:05:58 I don't know if XForms Transitional has many advocates besides him 18:06:05 icaaq has left #html-wg 18:06:51 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. 18:07:04 See my recent email for details on why round tripping of semantics is key to democratising authoring of web content 18:07:44 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. 18:07:50 it's somewhat academic anyway 18:08:01 since it doesn't matter who tries to solve it 18:08:04 it can't be solved. 18:08:05 I agree the discussion of the halting problem is academic 18:08:09 Dave: that assumes that writing mathematic expressions inside imperative event handlers is too hard but that declarative stuff isn't too hard 18:08:19 daves proof-of-concept implementation is a solution of sorts, no/ 18:08:20 ? 18:08:22 I'm not sure if spreadsheets are a hugely compelling use case 18:08:35 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 18:08:35 DanC: his proof-of-concept implementation doesn't implement his spec. 18:08:44 dbaron has joined #html-wg 18:08:49 obviously you can build spreadsheet-like things on top of the language with round tripping by storing the information in some indirect form 18:09:20 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 18:09:20 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... 18:09:24 so the question is, are they so important that we should change HTML itself to support them? 18:09:54 Ian, the implementation came first, which is key as it is easy to write a spec that doesn't work. 18:09:57 I think the answer is no 18:10:06 mjs, I agree that's a very relevant question, but isn't WF2 also a change to HTML? 18:10:08 spreadsheets are not nearly as key to day-to-day computing now as when they first came out 18:10:22 (I know only enough about forms to be dangerous) 18:10:44 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 18:10:50 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... 18:10:52 chaals: but how well do real-world use cases stay in the declarative box without wanting to use full JavaScript? 18:10:54 Simple JavaScript expressions are easy to add - so I don't understand why you want to force editing tools away from HTML 18:11:06 oh hey, there's dave 18:11:07 chaals: it seems to be that VBA is quite popular in Excel 18:11:08 hey dave 18:11:17 Hi Ian, 18:11:25 Dave: i know the implementation came first, but that doesn't make the spec implementable :-) 18:11:32 I think conflating spreadsheets and editing tools is mistaken 18:11:35 just means you specced something else 18:11:49 most editing tools are for documents 18:11:49 The spec should always be testable against implementations. 18:11:52 like emails or blog posts 18:12:04 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... 18:12:04 not really sure what that means 18:12:06 but sure 18:12:38 editing tools are really interesting 18:12:48 mjs, yes, I suspect blog tools and email composers are the really big use cases for editing HTML. 18:13:03 spreadsheets are marginally interesting 18:13:05 (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...) 18:13:20 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? 18:13:23 yes, we've gotten into discussing substance 18:13:29 but I'm still not clear what the procedure is 18:13:36 quaiz has joined #html-wg 18:13:54 hsivonen, yep. They write the forms I have to fill in every day/week/month/year 18:14:28 mjs, I'm not clear on the procedure either. we're making it up. 18:16:26 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? 18:16:57 Yes, I believe so, but you should ask that on www-forms 18:19:46 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. 18:20:59 Trying to derive semantics from JavaScript sounds real hard though. 18:21:09 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 18:21:17 DanC: since it is so easy to join 18:21:31 since we're not planning to be heavy on telecons, the existence of a task force is pretty nominal anyway 18:21:51 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. 18:22:11 Dave: you can't work out the dependencies if you're allowing arbitrary turing complete code 18:22:21 Dave: so that's impossible to implement. 18:22:21 Dave: requiring that the JS expression attributes be side-effect free is, I believe, isomorphic to the halting problem 18:22:33 yes. this is based upon the presence of the references in the expression, just like for spreadsheets. 18:22:39 Dave: (i thought we covered that in the review that karl sent you) 18:23:04 No, your arguments weren't technically sound. 18:23:48 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? 18:24:11 The expression analyser doesn't inspect external functions, so I agree that the spec should note that. (an easy addition) 18:24:26 if it doesn't inspect the functions, how do you find the dependencies? 18:24:36 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 18:25:31 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 18:25:54 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. 18:26:05 you don't need to check that functions are side effect free, the UA behavior is undefined if they aren't. 18:26:09 Dave: with all the magic getters and setter of JS, how do you figure out what the references are? 18:26:36 any spec that falls into "UA behavior is undefined" so readily is not a useful spec 18:26:38 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 18:26:57 undefined behavior is no longer considered acceptable 18:27:07 hear hear 18:27:24 Remember that we are looking at simple expressions and can analyse the references that appear within them using string matching routines (regex etc) 18:27:50 you are looking at simple expressions until someone decides to write one that isn't simple, using the full power of JS 18:28:16 if you want to invent a new simple side-effect-free expression language, then JS is not an option 18:28:26 They are welcome to use scripting more generally but thats for experts. 18:28:28 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. 18:28:30 but that makes the spec far less useful 18:28:42 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. 18:28:44 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. 18:28:48 and so does XFT 18:28:57 DanC: I'd just like the task force to reuse the chairs and mailing list of the HTMLWG 18:29:14 and membership 18:29:34 This is no different from writing scripts for event handlers, there is no guarantee that they will complete either. 18:29:41 right 18:29:42 I see... well, I'm not sure it's reasonable for me to propose that to the Forms WG, mjs. 18:29:52 if actually using arbitrary JS puts you into "undefined behavior", then it does not "cater to" it 18:29:58 dave: but there's no dependency determination and topological sort for event handlers 18:30:15 dave: the execution order is extremely well defined for event handlers, and is independent of their contents 18:30:26 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 18:30:36 True, but within the space of simple expressions and side effect free functions all works fine. 18:30:56 it's not less work than having a neutral forum, mjs 18:31:03 dave: we have to worry about all problems, we can't just limit ourselves to the convenient ones :-) 18:31:28 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" 18:31:52 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. 18:31:53 DanC: well, would we want everyone on the HTMLWG to subscribe to this new list? 18:31:54 bewest has joined #html-wg 18:32:35 dave: the big difference being that xpath extension functions are under the control of the ua, whereas arbitrary js is not 18:32:52 Dave: do XForms implementations interoperate when the functions are not free of side effects? 18:32:58 If you want guarantees either don't use external functions or check them carefully. It works fine. 18:33:16 it's not the authors who want guarentees, so much as the ua implementors and the users 18:33:22 and they're not the ones who write th code 18:33:25 You would be violating the spec if you did so. 18:33:26 Dave: what if authors use functions with side effects and depend on the behavior of one UA? 18:33:42 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 18:33:46 That is like using a UA dependent DOM feature 18:33:55 "undefined behavior" is not an acceptable answer for a modern web standard 18:34:02 end of story 18:34:03 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. 18:34:08 I don't know why we are even debating this 18:34:25 does javascript really have no undefined behaviour? 18:34:49 with the whatwg spec, yeah, pretty much. 18:34:50 Because I want to enable moms and pops to be able to create interesting web content comparable to simple spreadsheets. 18:34:56 DanC: a lot less than HTML 18:35:02 if you mean the actual ECMAScript standard 18:35:13 oh ECMAScript itself is pretty tight, yeah. 18:35:37 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 18:35:43 I should know I spent a lot of time on ECMA 262 a few years back - way too many trips across the atlantic. 18:35:45 Dave: couldn't that be accomplished with an authoring tool that compiles its own stuff to WF 2.0 plus JS? 18:35:57 for example, it's unspecified what order attributes are enumerated in when using a for..in loop 18:36:08 but in fact they must be enumerated in the order they were added 18:36:14 because authors depend on that 18:36:18 yeah. hopefully they'll fix that in ES4 18:36:30 otherwise i guess we'll have to define it in the whatwg spec 18:36:31 so one of the few cases of undefined behavior I can think of was clearly a mistake 18:36:37 hsivonen, yes we can give up on html as an editing format and using something else that compiles to HTML, sure 18:37:12 s/as an editing format/as an editing format for spreadsheets/ 18:37:29 W3C's members have invested heavily in developing declarative XML formats with that in mind. 18:37:49 makes sense that those formats would be used, then, and then exported as html 18:37:51 But I don't want to give up on html just yet. 18:37:53 I thought they were interested in "Enterprise", not "mom and pop" 18:38:15 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." 18:38:21 Dave: how does XForms Transitional protect the technical investment in XForms proper? aren't they technically different even though they share the name? 18:38:25 These days, web apps are all the rage and it isn't just about publishing content to the people. 18:38:34 I'm having trouble coming up with a "mom and pop" use case for creation of interactive spreadsheet documents with HTML. 18:38:50 DanC: actually, we go to great lengths to preserve binary compatibility with documented behaviors that apps actually use 18:39:03 DanC: with undocumented behaviors, rather 18:39:05 wouldn't they use a desktop app, Google Spreadsheets, or a custom CMS? (none authored by mom & pop) 18:39:30 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. 18:39:43 why? 18:39:44 bfults: that's what I meant with tools that compile to stuff that browsers see 18:39:54 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 18:40:03 The issue is when I hit the save button, what does it save? 18:40:04 hsivonen: right. so I fail to see why spreadsheets would have to be natively handled by HTML 18:40:13 bfults: me too 18:40:14 if then why not ? 18:40:34 DanC: we have a number of app-specific compatibility hacks in WebKit 18:40:35 If it saves to XForms, then the semantics are preserved, but if the semantics are compiled to JavaScript the semantics are lost. 18:40:37 it's not fun 18:40:50 bfults: though provides hooks for writing your own calculation engine 18:40:54 we also constantly have trouble with web content authored for Dashboard widgets, it depends on old WebKit bugs / quirks all the time 18:41:01 You have to think of the web as two way. 18:41:19 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 18:41:50 [as creators], mind you 18:41:55 Simple expressions aren't full blown rich app land, if you want to look at those, you are in another space. 18:42:11 zcorpan has left #html-wg 18:42:22 not fun indeed. shipping software products is mostly working around other people's bugs. 18:42:29 so I guess the question becomes: why is XForms insufficient? or why is insufficient? 18:43:08 are we talking about html in here? 18:43:11 (I must have lost track; I thought the discussion was on why XForms-like declarative stuff was necessary or worthwhile) 18:43:34 it still is I think. 18:43:44 I joined late, but it doesn't seem like it 18:44:03 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. 18:44:09 anyway, I think HTML forms improvements should focus primarily on the kinds of ways that HTML forms are used currently 18:44:37 if you look on the web today, you see a lot of login forms, order forms, quizzes, registration forms, search fields, and so forth 18:44:38 are there simpler problems we can solve first? :-) 18:44:42 mjs: app specific meaning for specific apps using the framework, or web apps? 18:44:43 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/ ) 18:44:46 but you don't see a whole lot of spreadsheets 18:44:56 gsnedders: I meant specific apps using the framework, in this particular case 18:45:00 I confess to having lower aspirations than Dave does... "ways that HTML forms are used currently" seems like a sufficiently worthy challenge, to me. 18:45:04 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. 18:45:20 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 18:45:22 agreed with mjs 18:45:27 me too 18:45:35 I don't think we should invent a language for a use case that basically does not happen on the web today 18:45:49 I don't believe that minor tweaks will lead to an explosion of spreadsheet-style content on the web 18:45:50 this method is succeeding in microformat and whatwg communities 18:45:51 After all I have shown that it can be done on perhaps 99% of browsers using a cross browser script that compresses to 6KBytes. 18:46:24 if we are talking about spreadsheets I'm certain we're not talking about html 18:46:25 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). 18:47:06 (dave's code in particular shows how easy it is to do today without html extensions) 18:47:16 (and seems like the best argument against adding it to the language) 18:47:23 Hmm, it seems that HTML as PDF is all that most people here aspire to. 18:47:38 not sure why you would infer that 18:47:45 scope is an issue 18:47:56 But it would be nice to be able to standardize such use of HTML attributes with JS libraries. 18:48:24 lots of JS libraries do just fine without being codified in a web standard 18:48:33 If browser vendors are slow to embrace change that's a shame but it should hold everyone else up. 18:49:01 the most commonly implemented features probably deserve their place in the standards, but spreadsheet-like calculations are very rare 18:49:02 are there simpler problems to solve before spreadsheet? 18:49:04 Being able to validate your documents is seen as important for many. 18:49:08 anyway 18:49:10 simpler/more common? 18:49:36 what is so hard about calculate="x+y" I don't get it? 18:50:08 you can only make it simple by sweeping the hard parts under the carpet 18:50:20 Not at all. 18:50:36 hober has joined #html-wg 18:50:39 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 18:50:44 what's so hard about onforminput="value = x.value + y.value" ? 18:50:45 "undefined behavior" == "sweeping it under the carpet" 18:50:52 Dave: I don't think the complaint is about difficulty 18:50:55 it's about scope. 18:51:22 Dave: are you suggesting that adding a spreadsheet feature is the simplest problem we can talk about wrt html? 18:51:30 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 18:51:41 If Opera had done this in the first place, you would all be arguing for it, this seems like NIH to me. 18:51:59 improvements for spreadsheets are, to me, less interesting than improvements for login forms or checkout forms 18:52:04 agreed 18:52:16 I work for an Opera competitor 18:52:28 yeah, if we're goign to discuss some kind of perhaps we can also discuss or something 18:52:46 I'm not sure how that would lead to me considering something implemented in Opera as IH, and something brand new as NIH 18:52:49 will be my FSM 18:53:04 where is "here" in this context? 18:53:08 I would encourage people that can to join W3C's security context WG as usable security is very important to the web. 18:53:21 if there's one thing that whatwg has been good at, it's ignoring the source of comments, and treating them all equally 18:53:55 NIH is definitely not a problem in the WHATWG, that's one of the few things i can say with certainty :-) 18:54:08 to me, the forms wg attitude towards WF 2.0 has seemed more like NIH 18:54:21 in fact, there's at least one feature in xforms transitional that has been noted already for changes we need to do to wf2 18:54:25 though i've forgotten what it is 18:54:31 it's on the pile somewhere 18:55:46 I hope that you will do me the courtesy of examining the details properly. 18:55:51 (i mentioned it in the review that karl sent you, whatever it was) 18:56:04 That review was laughable. 18:56:27 well it wasn't a formal review :-) 18:56:43 though i'm curious as to what you didn't think was appropriately examined 18:57:10 I am very happy to discuss the technical details, and we could perhaps pick something easier to start with. 18:57:39 For instance, the ability for people to type dates without being forced to use the date picker. 18:57:54 (I'm off to lunch, I think. I wonder if I should dismiss the Zakim agenda deely.) 18:58:00 It's getting late here, so I will have to leave v soon. 18:58:02 wf2 doesn't require uas to do a date picker 18:58:07 it doesn't constrain ui at all, in fact 18:58:21 uas are encouraged to compete to make better interfaces 18:58:25 well anyway this is pretty far off-topic from organization of the Forms Task Force 18:58:56 It would be good to have wider access to WF2 implementations other than Opera9. 18:59:37 I checked and it doesn't seem practical to fully implement WF2 on Firefox just from JavaScript. 18:59:56 robert has left #html-wg 19:00:00 I strongly suspect you could do most of it with XBL 19:00:10 (Mozilla XBL) 19:00:38 certainly more implementations would be nice. but it's early days yet. the draft isn't even in CR yet. 19:00:53 having any implementations at all is impressive, especially in a top-4 web browser 19:00:59 Gecko imposes constraints on the form object model that stopped me from getting the form attribute to work correctly. 19:01:34 Well note that XFT works on perhaps 99% of all modern browsers (based on what browsers we see visiting W3C site) 19:02:33 But it would be great to more implementations of Wf2 to try out. 19:02:48 there's an implementation of wf2 for IE6 19:03:06 That wasn't complete when I looked at it ... 19:03:10 sure 19:03:17 neither's opera9's implementation :-) 19:03:27 anyway time for me to go, enjoy the rest of the day. 19:03:39 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 19:03:42 later 19:06:49 hmm. the log linked to from the topic doesn't seem to be accumulating 19:08:51 RRSAgent, pointer? 19:08:51 See http://www.w3.org/2007/03/21-html-wg-irc#T19-08-51 19:09:42 odd. 19:12:01 tylerr has joined #html-wg 19:12:30 Afternoon all. 19:13:51 tylerr: hi 19:14:33 Hey there hsivonen. 19:16:53 Looking forward to getting involved in this. Awaiting my permissions for joining the WG. **smiles** 19:17:33 kingryan has joined #html-wg 19:25:23 kingryan has joined #html-wg 19:46:36 kingryan has joined #html-wg 19:50:00 anne: it requires a task force, but it's kind of unclear what is supposed to be delegated to the task force 19:51:11 just discussion about architecture it seems 19:51:40 since our architecture is sort of fixed... 19:56:59 gavin has joined #html-wg 19:58:26 I don't understand what "compatible architecture" even means 19:59:24 they have this idea "tag soup -> magic -> xforms -> profit" 19:59:36 i'm not sure if that's feasible though 19:59:53 some of the arrows are in the wrong direction 20:07:00 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? 20:07:22 join the working group, follow the mailing list, give feedback on areas of discussion 20:07:30 tylerr: do you work for a w3c member? 20:07:40 review http://www.whatwg.org/specs/web-apps/current-work/ maybe... 20:08:13 mjs: No, though our biggest client is Microsoft. So almost. **winks** 20:08:46 And I've put in my application to join the WG. 20:09:15 anne: Looking for items that might need clarification and such? 20:09:30 Or review meaning get up to speed? 20:09:45 tylerr: many parts of that spec could use comments 20:09:51 Ah righto. 20:10:31 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 20:15:05 colin_lieberman has joined #html-wg 20:17:49 I think if we adopt Web Apps 1.0, we need to have a featureset review 20:17:57 (and same for WF2) 20:18:06 before reviewing technical details 20:20:30 How much time would you alocate for a featureset review? A week? Less than a week? 20:24:30 I dunno, I have no idea what features may be controversial 20:25:06 I would say people should just flag what they think are problem areas rather than necessarily trying to resolve every point 20:25:09 any idea what features you'd consider out of scope? 20:25:17 like Microsoft may object to the parsing part 20:25:26 so we'd want to discuss that 20:25:42 I dunno, haven't read the whole spec closely enough 20:25:59 What about features where there is a perceived need, but the feature is not currently in the doc? 20:26:04 I think APIs that are language-independent we should consider devolving to Web API 20:26:14 colin_lieberman: I think proposing new features can happen after we have a baseline 20:26:36 Deeder has joined #html-wg 20:27:28 Hello, World ! 20:28:05 mjs: i'm skeptical of doing that given the history of doing that :-) but in principle i agree 20:28:36 Hi Deeder. 20:28:42 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 20:29:34 yeah, i definitely need to start splitting up the spec 20:29:39 should get on that in the coming months for sure 20:31:11 Splitting up in what way? 20:31:27 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 20:31:51 colin_lieberman: chapters and separate specs 20:31:59 mjs: totally 20:32:40 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. 20:34:41 How does that work? 20:34:43 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 20:35:14 his implementation works by doing regexp substitutions on JS code to make the magic variables work, which makes me cry 20:35:32 maybe i'm just too close to the UA side to understand how that counts as declarative 20:35:56 if you have to implement a turing-machine-equivalent UA to do it, it's not declarative, surely 20:36:07 he invented a new ad-hoc quasi-declarative language and is pretending it's JS 20:37:14 and in practice, the rest of JS is available, but actually using it does weird unpredictable things 20:37:38 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 20:44:06 all this seems very hypothetical 20:44:49 I don't think we should keep talking about forms 20:45:14 I'm all for HTML talk. :) 20:49:20 forms are html of course, but I don't think more talk will result in a meeting of the minds 20:49:42 then again, Dave had to go, so I am not sure there is much disagreement left 20:49:59 at some point I'd like to evaluate XForms 2 against what we think are common real-world cases of forms 20:50:34 er 20:50:37 Web Forms 2 20:50:47 sorry, bad thinko there 20:59:03 it might be interressant to have a objective comparative of both forms features 21:04:16 you must be Dutch! 21:14:39 jgraham has joined #html-wg 21:15:29 getting full here 21:15:34 37 vs 28 21:16:29 What's that anne? 21:16:53 the soul match between #whatwg and #html-wg 21:17:46 Ahh. 21:20:13 There's a significant amount of overlap too 21:21:16 I've only just gotten involved (read yesterday) so any overlap is purely more information for me to digest. :) 21:22:33 I'm headed out the door in a minute, but... a parting thought: 21:23:27 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? 21:23:49 and answer questions, of course. 21:24:00 Lovely. I'd attend. 21:24:08 and maybe I'll take issue-list notes while we're at it. 21:24:43 This would be open to anyone? 21:24:44 DanC: not sure what exactly you mean? 21:24:46 I'll try to send mail later today. bonus points to anybody who beats me to it 21:25:21 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 21:25:32 oh wow 21:25:35 that's a big subject 21:25:47 not sure how to summarise it in a 10 minute presentation 21:26:04 i could probably do a 15 second summary followed by a few examples 21:26:05 I was thinking 30 or 40 minutes of presentation. still a challenge, yes. 21:26:38 perhaps you could do a 3 minute intro, and then we could get a few other perspectives. 21:26:46 i don't really think a phone call would be a good medium for this though 21:26:57 I'm inclined to try it 21:27:20 how many people can the bridge carry per call? i don't want to have to do this 15 times or whatever... 21:27:30 wouldn't e-mail be a better medium? 21:27:34 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 ;-) 21:27:57 e-mail preparation would be great; but there's nothing like real-time, undivided attention 21:28:10 Have you considered setting up a Campfire chat? 21:28:25 ok, mostly-un-divided-attention 21:28:33 in fact i'd say reading a mail is less divided :-) 21:28:37 and goes at the pace of the reader :-) 21:28:38 no, I don't know what Campfire is 21:28:56 http://www.campfirenow.com/ 21:29:16 A 37signals product. Business chat for groups. 21:30:43 It could come in handy for group discussions where file/image sharing is needed. 21:33:04 do W3C teleconferences require a long-distance phone call or is participation possible with libjingle, iChat or Skype? 21:37:38 Skype is ok 21:37:51 hsivonen 21:39:10 I don't think a phone call would be a great medium for a technical presentation 21:39:24 I think a summary document of new features might be better 21:40:05 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. :) 21:40:50 "interessant" is also French? 21:40:55 my French is terrible... 21:42:04 "interessant" is french yes, means interesting. 21:42:18 well, I figured that much 21:42:26 we probably stole the word than 21:42:32 s/than/then/ 21:42:48 :) 21:42:58 mjs: Did you take a look at that Campfire link I provided? 21:43:09 It's an interesting take on group chat. 21:43:28 Which might work well for the WG. 21:45:09 Here's a brief overview anne: http://www.campfirenow.com/tour/ 21:45:58 it looks like IRC to me 21:46:26 heh 21:46:53 I suppose I'm just a sucker for inline images, group file sharing and pretty UIs. :) 21:46:56 tylerr: I don't think changing our collaboration tools is super important at the moment, unless there would be some major benefit 21:47:31 Oh sure mjs, I was just suggesting that tool because the topic of teleconferencing came. 21:47:46 Not as a shift in daily communications. 21:47:56 I'd rather avoid telecons entirely 21:48:12 as a matter of personal taste anyway 21:48:20 Do you think sticking to mailing lists and IRC would suffice? 21:48:31 marcos_: ok. good 21:48:51 kingryan has joined #html-wg 21:49:21 certainly e-mail and irc only has worked well for the whatwg 21:49:38 well, email+irc+wiki+forum 21:50:11 For presentations there is always S5 (http://meyerweb.com/eric/tools/s5/), which can be delivered online quite nicely. 21:50:49 meeting face to face can be nice for presentations and selected high-bandwidth conversations 21:51:22 This is why everyone needs iChat. ;) 21:51:59 but phone doesn't really win over emails 21:52:03 plus IRC 21:52:25 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:04:38 gavin has joined #html-wg 22:05:59 hsivonen has joined #html-wg 22:16:47 Lachy_ has joined #html-wg 22:21:05 kingryan has joined #html-wg 23:05:34 kingryan has joined #html-wg 23:07:07 Lachy_ has joined #html-wg 23:53:12 marcos has joined #html-wg 23:55:52 karl has joined #html-wg