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

Options:

# Session Start: Sun Mar 25 00:00:00 2007
# Session Ident: #html-wg
# [00:09] * Joins: hasather (hasather@81.235.209.174)
# [00:32] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [00:37] * Joins: gavin (gavin@74.103.208.221)
# [01:18] * Quits: heycam (cam@203.214.72.79) (Ping timeout)
# [01:35] * Joins: heycam (cam@203.214.81.60)
# [01:37] * Parts: hasather (hasather@81.235.209.174)
# [03:39] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [03:44] * Joins: gavin (gavin@74.103.208.221)
# [04:18] * Joins: zcorpan (zcorpan@84.216.40.60)
# [04:19] * Joins: Shunsuke (kuruma@219.110.80.235)
# [04:20] * Joins: Shunsuke_ (kuruma@219.110.80.235)
# [04:20] * Quits: Shunsuke (kuruma@219.110.80.235) (Connection reset by peer)
# [05:13] * Joins: Preston (chatzilla@70.181.71.135)
# [05:47] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [05:49] * Joins: marcos (chatzilla@131.181.148.226)
# [05:49] * Quits: Preston (chatzilla@70.181.71.135) (Quit: Chatzilla 0.9.77 [Firefox 2.0.0.2/0000000000])
# [05:51] * Joins: gavin (gavin@74.103.208.221)
# [06:39] * Quits: zcorpan (zcorpan@84.216.40.60) (Ping timeout)
# [07:16] * Quits: Deeder`aw (Deeder@83.198.51.9) (Ping timeout)
# [07:17] * Deeder`aw is away: Être absent à partir de maintenant.
# [07:17] * Joins: Deeder`aw (Deeder@86.208.131.124)
# [07:20] * Joins: h3h (bfults@76.171.163.147)
# [07:38] * Quits: quaiz (quaiz@70.181.154.111) (Quit: quaiz)
# [07:49] * Quits: marcos (chatzilla@131.181.148.226) (Ping timeout)
# [07:54] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [07:59] * Joins: gavin (gavin@74.103.208.221)
# [08:56] * Quits: h3h (bfults@76.171.163.147) (Quit: h3h)
# [09:13] * Quits: st (st@62.234.155.214) (Quit: st)
# [09:46] * Joins: dbaron (dbaron@71.198.189.81)
# [10:02] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [10:07] * Joins: gavin (gavin@74.103.208.221)
# [10:13] * Quits: @DanC (connolly@128.30.52.30) (Client exited)
# [10:20] * Joins: marcos (chatzilla@131.181.148.226)
# [10:51] * Joins: chaals (chaals@84.77.45.214)
# [11:01] * Quits: dbaron (dbaron@71.198.189.81) (Ping timeout)
# [11:02] * Deeder`aw is back.
# [11:02] * Deeder`aw is now known as Deeder
# [11:04] * Joins: dbaron (dbaron@71.198.189.81)
# [11:08] * Quits: dbaron (dbaron@71.198.189.81) (Ping timeout)
# [11:10] * Quits: Shunsuke_ (kuruma@219.110.80.235) (Connection reset by peer)
# [11:11] * Joins: Shunsuke (kuruma@219.110.80.235)
# [11:19] * Joins: ROBOd (robod@86.34.246.154)
# [11:39] * Joins: hasather (hasather@81.235.209.174)
# [12:10] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [12:15] * Joins: gavin (gavin@74.103.208.221)
# [12:24] * Parts: hasather (hasather@81.235.209.174)
# [12:30] * Joins: hasather (hasather@81.235.209.174)
# [12:46] * Quits: Shunsuke (kuruma@219.110.80.235) (Ping timeout)
# [13:23] * Quits: marcos (chatzilla@131.181.148.226) (Ping timeout)
# [13:39] * Joins: Shunsuke (kuruma@219.110.80.235)
# [13:39] * Parts: Shunsuke (kuruma@219.110.80.235) (See you...)
# [13:39] * Joins: Shunsuke (kuruma@219.110.80.235)
# [13:40] * Quits: chaals (chaals@84.77.45.214) (Ping timeout)
# [13:40] <Lachy> it would be cool if we could use Skype for the telcon, as Henri said in his last e-mail, though I don't expect that's possible with the W3Cs system
# [14:01] * Joins: Julian (chatzilla@80.143.176.110)
# [14:17] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [14:18] * Julian is now known as julianreschke
# [14:18] * julianreschke is now known as Julian
# [14:22] * Joins: gavin (gavin@74.103.208.221)
# [14:40] * Joins: edas (edaspet@88.191.34.123)
# [14:47] * Quits: Shunsuke (kuruma@219.110.80.235) (Connection reset by peer)
# [14:48] * Joins: Shunsuke (kuruma@219.110.80.235)
# [16:24] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [16:29] * Joins: gavin (gavin@74.103.208.221)
# [16:51] * Joins: balac (Good@211.240.40.76)
# [16:53] * Joins: anne (annevk@83.82.206.111)
# [16:55] * Joins: nickshanks (nicholas@195.137.85.17)
# [17:17] * Joins: dbaron (dbaron@71.198.189.81)
# [17:30] * Joins: colin_lieberman (colin@24.5.197.118)
# [17:41] * Quits: colin_lieberman (colin@24.5.197.118) (Ping timeout)
# [18:08] * Joins: st (st@62.234.155.214)
# [18:23] * Quits: dbaron (dbaron@71.198.189.81) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [18:32] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [18:37] * Joins: gavin (gavin@74.103.208.221)
# [18:39] * Joins: colin_lieberman (colin@24.5.197.118)
# [18:48] * Quits: colin_lieberman (colin@24.5.197.118) (Ping timeout)
# [19:03] * Quits: mutilator (WebChat@65.111.201.122) (Quit: The difference between involvement and commitment - in a ham and egg breakfast the chicken is involved, the pig is committed.)
# [19:05] * Quits: anne (annevk@83.82.206.111) (Ping timeout)
# [19:13] * Joins: dbaron (dbaron@63.245.220.228)
# [19:53] * Quits: Julian (chatzilla@80.143.176.110) (Quit: Chatzilla 0.9.77 [Firefox 2.0.0.3/2007030919])
# [19:59] * Joins: anne (annevk@81.68.67.12)
# [20:11] * Quits: anne (annevk@81.68.67.12) (Ping timeout)
# [20:19] * Joins: icaaq (icaaaq@85.228.55.162)
# [20:21] * Joins: anne (annevk@81.68.67.12)
# [20:21] * Quits: Ashe (Ashe@213.47.199.86) (Ping timeout)
# [20:21] <anne> DaveR, the new grammar still doesn't solve the problem...
# [20:23] <anne> It's also not clear to me how you keep the semantics in the language this way... as you're essentially putting them in some subset of ECMAScript too...
# [20:26] <anne> hsivonen, maybe you should post about versioning on your blog too?
# [20:26] * anne reads http://lists.w3.org/Archives/Public/public-html/2007JanMar/0433
# [20:27] * Joins: Ashe (Ashe@213.47.199.86)
# [20:29] <DaveR> Good evening Anne! Can you explain why the grammar + semantic constraints don't solve the problem. This shouldn't be rocket science as excel and XForms have no problems with such expressions.
# [20:29] <anne> what if the function is not side effect free?
# [20:30] <anne> (as I understand it XForms doesn't allow authors to use functions that have side effects)
# [20:30] <anne> (I'm not familiar enough with Excel scripting languages.)
# [20:30] <DaveR> so I am looking to describe what the UA reasonably needs to do, but we can't easily stop people who insist on shooting themselves in the foot when using scripting languages.
# [20:31] <anne> the behavior would need to be defined exactly otherwise it's not really feasible
# [20:31] <DaveR> If you write a function, it is up to you to avoid doing something silly. That has always been the case for scripting.
# [20:31] <anne> I think that was already mentioned in the previous thread we had about this
# [20:31] <DaveR> Surely you are not telling me that Opera statically analyses all scripts set as event handlers?
# [20:33] <anne> event handlers have a clear defined processing model
# [20:33] <DaveR> huh!
# [20:33] <anne> anyway, this is just reiterating the same thread as before
# [20:33] <anne> I don't see much value in that
# [20:33] * Quits: Ashe (Ashe@213.47.199.86) (Quit: Quit)
# [20:34] * Joins: Ashe (Ashe@213.47.199.86)
# [20:34] <DaveR> That thread wasn't satisfactory from a technical view point nor from consideration of authors who don't know and don't want to learn scripting.
# [20:35] <DaveR> The market will fix this if HTML isn't a good authoring language.
# [20:35] * Quits: Shunsuke (kuruma@219.110.80.235) (Quit: See you...)
# [20:38] <anne> It's still not clear to me why authors would not learn HTML but would learn you expression language and why they can't use some simplified expression language that's mapped to ECMAScript by some tool (as I assume Google Docs does it if they offer such functionality).
# [20:39] * Quits: gavin (gavin@74.103.208.221) (Ping timeout)
# [20:39] <DaveR> It you want to create a spreadsheet you just need to understand how to write simple formulae, and how to set cell types, e.g. to dates.
# [20:40] <DaveR> That is really nice for non-technical types.
# [20:40] <DaveR> A good editor would allow them to do the same for web base apps without having to learn html or css.
# [20:40] <DaveR> Not everyone is a programmer.
# [20:41] <anne> Well yes, I agree with that.
# [20:42] <anne> s/you expression/your expression/
# [20:43] <DaveR> Would you instead accept a subset of XPath?
# [20:43] <DaveR> This could be reversably mapped to something like JavaScript expressions for the author, to address ease of use.
# [20:44] * Joins: gavin (gavin@74.103.208.221)
# [20:44] <anne> As said above, it's not clear to me what's wrong with event handlers. Especially since the people who are building this stuff don't have much interest in it and not much people see obvious use cases for it.
# [20:45] <DaveR> What's wrong with event handler is that they require you to be a programmer to understand what the script does and how to write an event handler.
# [20:45] <DaveR> That's not very considerate to the majority of the population.
# [20:45] <anne> The majority of the population would use an editor, right?
# [20:45] * anne doesn't see why the editor can't abstract away the "complexity"
# [20:46] <DaveR> The HTML WG is a self selecting bunch of geeks - I don't see anyway around that, but we do have a duty of care to other people.
# [20:46] <anne> The majority of the population won't get XPath or your subset of ECMAScript with side effect free functions either.
# [20:46] <DaveR> How would the editor be able to understand the semantics of code?
# [20:46] <DaveR> We all agree the impracticality of machine reasoning over turing complete code.
# [20:47] <anne> presumably editors would figure that out amongst themselves
# [20:47] <DaveR> how, are they AI complete?
# [20:47] <DaveR> The only way they could is for them to save a declarative representation somewhere.
# [20:47] <anne> if they can write it they can prolly read it too
# [20:48] <DaveR> That pretty much eliminates interoperability doesn't it?
# [20:48] <anne> "presumably editors would figure that out amongst themselves"
# [20:48] <DaveR> You would only be able to use the editor the document was created with - sounds like a great lockin for a proprietary format,
# [20:49] <DaveR> I thought we all agreed on the need for open standards and interoperability
# [20:49] <anne> anyway, it would make more sense to me if you actually said this on the mailing list instead of trying to abstract around it with some proposal everybody objects against
# [20:50] <anne> then again, I'm not sure many people were convinced of the need for this...
# [20:50] <DaveR> yes, I will try to capture this in my email reply to your response.
# [20:51] <DaveR> If the HTML WG only addresses the needs for people who are programmers, HTML will become increasingly irrelevant except as a delivery format.
# [20:51] <DaveR> The market will see to that.
# [20:52] <anne> I haven't seen that happening so far
# [20:52] <anne> so far HTML is pretty much the only delivery format on the web...
# [20:53] <DaveR> Open Office is an example that is picking up, especially in government circles.
# [20:53] <anne> as a replacement for Word documents, maybe
# [20:54] <DaveR> Companies producing content for mobile devices are increasingly using more declarative formats than HTML - my company is thriving on that trend.
# [20:54] <anne> guess you have different clients from us :)
# [20:55] <DaveR> yes.
# [20:55] <DaveR> your clients presumably only need to worry about delivery content to opera browsers, right, :)
# [20:57] <anne> given that we focus a lot on interop such content should prolly work elsewhere too
# [20:57] <DaveR> that would be nice, but sadly, the devices vary so so much.
# [20:58] <anne> i suspect that will get better in due course
# [20:58] * Parts: icaaq (icaaaq@85.228.55.162)
# [20:58] <DaveR> different versions of different standards, different amounts of memory, bandwidth, etc. etc.
# [20:58] <anne> market is still pretty new
# [20:59] <DaveR> but there is increasing interest in how to build rich web apps by combining components
# [20:59] <DaveR> an ecosystem will emerge over time to support this
# [21:00] <DaveR> and declarative means to manipulate such components will be crucial
# [21:20] * Joins: zcorpan (zcorpan@84.216.41.105)
# [21:24] * Quits: DaveR (dsr@128.30.52.30) (Quit: be seeing you ...)
# [21:27] * Quits: Lachy (Lachlan@210.84.40.143) (Ping timeout)
# [21:53] * Quits: ROBOd (robod@86.34.246.154) (Quit: http://www.robodesign.ro)
# [21:57] * Joins: NicolasLG (me@84.99.121.132)
# [22:00] * Joins: Country (Country@82.124.94.238)
# [22:01] * NicolasLG is now known as Neovov
# [22:03] * Quits: balac (Good@211.240.40.76) (Ping timeout)
# [22:07] <Neovov> Hi everybody !
# [22:08] <zcorpan> Neovov: hi
# [22:13] * Quits: dbaron (dbaron@63.245.220.228) (Ping timeout)
# [22:19] <hsivonen> anne: hmm. perhaps I indeed should edit a blog post out of the email
# [22:23] <anne> there's lots of stuff in it anyway
# [22:23] <anne> dbaron also has one: http://dbaron.org/log/2007-03#e20070325a
# [22:29] <hsivonen> I hadn't seen it yet
# [22:29] <hsivonen> I haven't read the entire acrynym thread, but I wonder it has been pointed out that HTML5 already *obsoletes* <acronym>
# [22:30] <anne> you're planning on reading it?
# [22:30] <hsivonen> I guess I have to for completeness
# [22:30] <anne> why? the issue is already settled...
# [22:31] <hsivonen> in case there's good stuff in tangential comments with the same subject
# [22:31] <edas> anne, is there somewhere a list of issues aloready resolved and task to be done ?
# [22:32] <anne> hsivonen, some are interesting, indeed
# [22:32] <anne> hsivonen, about screen readers not adopting aural CSS for instance
# [22:32] <anne> (and the reason is given too)
# [22:32] <anne> edas, well, in theory nothing is resolved I suppose
# [22:33] <edas> in practice ? ;)
# [22:33] <anne> quite a bit more than nothing :)
# [22:33] <anne> see http://www.whatwg.org/specs/web-apps/current-work/ for the only proposal for HTML5 I'm aware of
# [22:34] <edas> I will be pleased to avoid reading a thread that is "done" like you seem to point for acronym
# [22:34] <anne> (around which the charter seems to be built as well...)
# [22:35] <anne> There's no real list of resolved issues though. It's just that no new arguments are likely to come up in favor of keeping them both.
# [22:35] <edas> ok
# [22:35] <anne> (for this case)
# [22:36] <anne> I think <video> and <audio> for instance are becoming more and more settled as well...
# [22:36] <mjs> eventually you want to feature-freeze the spec
# [22:37] <mjs> <video> and <audio> are still in flux but I don't think there is much serious debate on whether to have them, and roughly what the featureset should be
# [22:37] <anne> Yeah, I believe Hixie is working towards that
# [22:37] <anne> (the feature-freezing bit)
# [22:37] <mjs> I have to write some carefully researched emails about some of the features in there now
# [22:37] <mjs> specifically autolinking and the networking stuff
# [22:37] <anne> autolinking?
# [22:38] <mjs> but I need to review the other features too
# [22:38] * anne thinks networking is ideally done by the Web API WG
# [22:39] <mjs> probably so, but I think the proposed design is wrong whichever WG does it
# [22:40] <anne> fair enough :)
# [22:40] <mjs> but I have to show you can have reasonable persistent 2-way networking using http
# [22:40] <anne> oh, you mean the <code>test</code> <dfn>test</dfn> stuff
# [22:41] <mjs> yes
# [22:41] <mjs> what the spec calls "automatic cross-references"
# [22:41] <mjs> I think there should be a specific element for a cross-reference
# [22:42] <mjs> the current design is easy to process staticaly but bad for dynamic updates, I think
# [22:42] <anne> why?
# [22:42] <anne> ah, ok
# [22:42] <anne> the current design is great for spec writing
# [22:43] <anne> <code>readyState</code> and such
# [22:43] <mjs> yeah, I am not sure the feature is even worthwhile, since I don't think it has a lot of use cases besides standards documents
# [22:43] <anne> (I'm using a generator from the CSS WG to make that into actual links, as HTML5 isn't supported yet.)
# [22:44] <anne> Well, papers and such would use it too, but for the majority of documents it's prolly not needed.
# [22:45] <mjs> to deal with dynamic updates, you need to have a hashtable of all dfn defined terms, and the text contents of all span, abbr, code, var, samp and i attributes (excluding ones that currently have an interactive element or dfn as an ancestor or descendant, etc etc
# [22:46] <mjs> I mean, the rule defining what elements it applies to is a 6-line sentence
# [22:46] <mjs> the spec really needs to be fixed not to have such complex sentences
# [22:46] <mjs> if a rule is that complicated, it needs to be written as an algorithm in list form
# [22:47] <anne> at some point Hixie switched to algorithms I think
# [22:47] <anne> this is prolly from before that
# [22:47] <mjs> anyway, it would be much simpler if there was a <term> element
# [22:47] <anne> there actually used to be <x>
# [22:48] <mjs> then the rule can be much simpler, and you don't need to keep a big hashtable on the side for documents that use <i> just to italicize
# [22:48] <anne> for cross references
# [22:48] <mjs> x for cross-reference?
# [22:48] <anne> but then it was dropped
# [22:48] <mjs> I don't like one-letter tag names so much
# [22:48] <mjs> HTML has enough of those
# [22:48] <mjs> anyway
# [22:49] <mjs> I should write up why I think this is bad for UAs that need to handle dynamic updates, and why a specific element (term, x, crossref, whatever) would be better
# [22:49] <anne> (it could be used in addition to the other tags, fwiw)
# [22:49] <anne> s/tags/elements/
# [22:50] <anne> Although I suppose implementing it is complex introducing <term> makes authoring a lot more involved.
# [22:50] <anne> Instead of typing <code>foobar</code> you have to type <term><code>foobar</code></term>
# [22:51] <anne> that's an additional 11 characters each time you use the term
# [22:51] <anne> (otoh, it saves you at least six characters if you don't want the cross referencing to happen)
# [22:51] <anne> (but that's rare)
# [22:52] <mjs> <x> would be better that way I guess
# [22:52] <mjs> hey, maybe it can be role="crossreference" :-)
# [22:53] <mjs> the problem w/ the current design isn't mainly that implementing is complex
# [22:54] <anne> s/11/13/
# [22:54] <mjs> it's more that you have a choice of either: (a) regenerating the cross-references on any dynamic update will be very slow or (b) you have to waste a lot of memory in documents that don't use cross-references
# [22:54] <mjs> (to track the state needed in case you dynamically update)
# [22:55] <mjs> those seem like a big cost for a feature with a pretty specialized use case
# [22:55] <anne> well, you only need to start using memory when you encounter both a <dfn> and one of the others
# [22:56] <anne> (or after they're both inserted)
# [22:56] <mjs> but that means when you do encounter a <dfn> you now have to walk the whole document
# [22:57] <anne> if you also encountered one of the others, yes
# [22:57] * Joins: dbaron (dbaron@63.245.220.228)
# [22:57] <mjs> but maybe you have one of those rare documents that does not contain any <span> or <i> elements
# [22:57] <mjs> those are the main problematic ones
# [22:57] <mjs> the others are rare enough in normal documents that always hashing their contents is reasonable
# [22:58] <mjs> but you still have the problem of how complex the rule is, presumably to avoid accidental cross-references
# [22:58] <mjs> hi dbaron
# [22:59] <anne> the rule is complex due to potential nesting issues
# [23:01] <mjs> with a specialized element you would not need to worry about that, since you could make nesting of that element non-conformant for documents, and then let both cross-references happen
# [23:01] <anne> <dfn><x>test</x></dfn>
# [23:02] <zcorpan> an attribute? <code xref>foo</code>
# [23:03] <zcorpan> that's clearer than <code title>foo</code> when you don't want it to be a xref, imho
# [23:04] <mjs> anne: I see no deep problem w/ making that a cross-reference to itself, but you could also make <x> in <dfn> non-conforming
# [23:04] <anne> well, non-conforming doesn't help UAs
# [23:04] <zcorpan> perhaps i should propose xref="" to the list (or is there a better name?), i like it
# [23:05] <mjs> anne: well, then you don't need to worry about the weirdness of it being an xref to itself
# [23:05] <mjs> anyway, <a id="foo" href="#foo">foo</a> is legal
# [23:05] <anne> yes, I'm just saying that you have to define what the UA has to do
# [23:05] <anne> the current draft does that
# [23:05] <mjs> zcorpan: global attributes suck, though in this case it makes some sense
# [23:06] <mjs> anne: yeah, it defines it with a very complex rule
# [23:06] <zcorpan> mjs: i didn't say it should be global :)
# [23:06] <mjs> anne: I'd rather have a design that has a simple rule
# [23:06] <anne> it also avoids <a>test <code>test</code></a> for instance (although arguably <x> can be nested there)
# [23:06] * Joins: Lachy (Lachlan@210.84.40.143)
# [23:06] * anne sort of likes the boolean attribute idea
# [23:06] <zcorpan> mjs: it would only do anything on the elements that are currently xref elements
# [23:06] <mjs> <x> in <a> and vice versa could be disallowed, just as <a> in <a> is
# [23:07] <mjs> zcorpan: that's not a bad idea
# [23:07] <mjs> zcorpan: although it still leaves the complicated rules about interactive elements
# [23:07] <anne> mjs, you're talking authoring and I'm talking UA criteria
# [23:07] <anne> <a> in <a> has to be handled by the UA, for instance
# [23:08] <zcorpan> mjs: how so? can't we just say that it's always a "link", regardless of where you put it? just like <a> inside <a>?
# [23:08] * Quits: Deeder (Deeder@86.208.131.124) (Client exited)
# [23:08] <mjs> anne: I'm saying if something is non-conformant, then the UA handling can be something that gives a weird result
# [23:08] <anne> yeah, with the attribute you could make stuff less complex
# [23:08] <mjs> anne: just like <a> in <a>
# [23:09] * zcorpan composes a proposal
# [23:09] <anne> mjs, sure, as long as it's the same accross UAs
# [23:09] <mjs> well, that saves me one complicated email I have to write
# [23:09] <mjs> anne: an example of a very simple rule would be to totally ignore nesting
# [23:09] <mjs> I think that's a fine rule if you explicitly ask for an xref, whether it's with an xref attribute or an <x> element
# [23:10] <anne> yeah
# [23:10] * anne is ok with that too :)
# [23:11] <mjs> the reason for the weirdness about nesting is really only needed because cross-ref semantics are overloaded onto elements that you may well be using for a totally different purpose
# [23:12] <anne> yeah, I'm convinced opt-in is better here
# [23:12] <anne> well, I am now
# [23:13] <mjs> I like the way media elements are coming along
# [23:13] <anne> yeah, looks quite good
# [23:13] <anne> did you mention timed text somewhere btw?
# [23:14] * anne vaguely remembers some mentioning of another media element thing that hasn't been proposed yet on the list
# [23:15] <mjs> someone mentioned it - I don't think timed text needs its own element
# [23:15] <mjs> but videos often have timed text tracks
# [23:18] <zcorpan> mjs: can i quote you in the proposal?
# [23:20] <zcorpan> is the log bot running, btw?
# [23:20] <anne> yeah
# [23:20] <mjs> zcorpan: you may
# [23:20] <anne> so you can just provide a pointer
# [23:21] <anne> including WF2 we're at a 100 elements now
# [23:22] <anne> (per http://simon.html5.org/html5-elements )
# [23:22] <anne> The plan was to include Ruby as well in due course iirc.
# [23:23] <mjs> I'd love to see a version of that which showed delta to HTML4
# [23:23] <anne> there's a sort of delta available
# [23:23] * anne looks up a pointer
# [23:23] <anne> http://wiki.whatwg.org/wiki/HTML_vs._XHTML#Obsolete_Elements
# [23:24] <mjs> input types deserve separate listing too, since they are almost as different as different elements
# [23:24] <anne> only obsolete elements...
# [23:24] <anne> prolly need a list of new elements too
# [23:26] <zcorpan> anne: can i quote you, too?
# [23:26] <anne> yes
# [23:26] <anne> (people can always quote me when stuff is archived)
# [23:29] <hsivonen> is http://www.w3.org/2007/03/XForms-Transitional/ the whole spec for XForms Transitional?
# [23:30] <anne> yes
# [23:31] <hsivonen> mmkay
# [23:32] <anne> apart from the calculations must be declarative thingie I'm not sure I get it
# [23:33] * anne forgot about step=any
# [23:33] <hsivonen> it seems to me that the spec is nowhere near precise enough to see what implementors should implement and how to do it interoperably
# [23:33] <anne> that's what some of us said to Dave
# [23:35] <mjs> he seems to get upset when people point out that it's not precise enough and possibly unimplementable
# [23:36] <mjs> because obviously they would only do that if they hate the common man, are against spreadsheets, and want HTML to be only a delivery format like PDF
# [23:36] <anne> I think it'd be much more sense if he argued for use cases and such instead of trying to propose a specific implementation.
# [23:36] <anne> s/it'd be/it'd make/
# [23:36] <mjs> I don't mind if he proposes specific features, but yes, it would be good to agree on model use cases
# [23:37] <mjs> I think the model use cases for HTML forms should be the kinds of forms you see on the web today
# [23:37] <mjs> he thinks the model use case should be spreadsheets
# [23:38] <anne> He wants people to be able to enter expressions and editor tools to interoperate on that expression language. Which is kind of hard if the expressions are tied into ECMAScript event handlers.
# [23:38] <hsivonen> mjs: when you say "model", do you mean "example" or MVC?
# [23:38] <anne> But then he also allows external functions which allows exactly the vendor lock in (plus other problems, such as non-side effect free functions) that he wants to prevent
# [23:39] <mjs> hsivonen: I mean the primary use cases to consider when designing the feature
# [23:39] <mjs> the "what is this feature for" use case
# [23:39] <hsivonen> mjs: ok
# [23:39] <mjs> as opposed to "well you *could* use it for this other thing"
# [23:39] <mjs> anne: you could ban external functions, but then you also need event handlers
# [23:40] * Quits: dbaron (dbaron@63.245.220.228) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [23:40] <hsivonen> I think the idea that non-programmers can do declarative programming without learning but can't learn to do imperative programming in unfounded
# [23:40] <anne> or you need to go the XForms way I suppose, which is not really compatible with HTML forms
# [23:40] <anne> and not really author friendly either
# [23:40] <hsivonen> also, I am pretty sure that an average code grinder is better at imperative programming than in declarative programming
# [23:41] <mjs> hsivonen: I would say the ease of learning XSLT for novices vs. the ease of learning Visual Basic proves the opposite
# [23:41] * Quits: edas (edaspet@88.191.34.123) (Quit: Quitte)
# [23:41] <hsivonen> mjs: opposite of my first or second statement?
# [23:41] <mjs> (it shows that an imperative language is easier to learn, at least past a certain complexity level)
# [23:41] <hsivonen> mjs: agreed
# [23:42] <mjs> I mean, you don't see a whole lot of demand for Visual Prolog
# [23:42] <hsivonen> :-)
# Session Close: Mon Mar 26 00:00:00 2007

The end :)