IRC log of html-wg on 2007-03-21

Timestamps are in UTC.

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