Apr 13 14:43:51 shanem, exactly Apr 13 14:43:59 this way there is a measure of control. Apr 13 14:44:07 exactly again Apr 13 14:44:14 andf what did he request? Apr 13 14:44:26 (using the little power he had) Apr 13 14:44:50 he has immense power - no document can be published withouth his approval Apr 13 14:45:14 microsft has a lot more power Apr 13 14:45:38 so - what did he request? Apr 13 14:45:41 timbl could spit specs till kingdom come, and if micxrosoft refused, they would not happen. Apr 13 14:45:50 and microsoft refused Apr 13 14:46:05 i think he wants to use the new html wg Apr 13 14:46:23 so that they fix all already existing web content Apr 13 14:46:37 so he can use it in the xhtml way Apr 13 14:46:56 so he asked for two versions, one html, and one xhtml Apr 13 14:47:14 that way, if html5 triumphs Apr 13 14:47:18 I think you give him too much credit. he's not that clever. really he's not. oh - you mean the "XML serialization" of the new HTML? Apr 13 14:47:26 he will have a copy of the whole web, in xhtml Apr 13 14:47:35 yes Apr 13 14:47:46 no... the XML serialization is NOT XHTML. no idea what it is. Apr 13 14:48:05 the point being that as long as it is xml, it can be processed in the xml way Apr 13 14:48:30 I suppose... Apr 13 14:49:12 the XML serialisation of HTML5 is XHTML! Apr 13 14:49:48 if he can provide a new funcionality (semantic web, etc), that is obviously better, i reckon he assumes people will favor it, and keep using just the xml version Apr 13 14:50:07 so, in a way, he is using the html wg as a big tidy Apr 13 14:50:08 Lachy: I dont think so. the XHTML Working Group owns the XHTML specs. Apr 13 14:50:31 The XHTML2WG should hand over everything in the XHTML 1.x namespace to the HTMLWG Apr 13 14:51:02 Lachy: well - that's not gonna happen. the charter of the xhtml2 wg is clear. Apr 13 14:51:03 except, we don't want any of the profile stuff, you can toss those out Apr 13 14:51:50 actually, XHTML5 is going to make everything you have in the XHTML 1.x namespace obsolete, so it doesn't really matter that much Apr 13 14:51:58 ok, shanem, we get toe scenarios: 1) timbl is not smart. if so...then he just dropped xhtml. it will have zero chance, imho. 2) he wants to use the html wg as a tagsoup fixer Apr 13 14:52:13 s/tow/two/ Apr 13 14:53:36 proof of timbl dropping xhtml would be that in all these years, microsoft refused to do implement it. and that he just gave green light to another group which has microsoft as chair, plus all the other browser makers as members Apr 13 14:53:44 Lachy: fwiw, it wont be called xhtml5 i dont think. that would be pretty inappropriate and confusing Apr 13 14:54:03 the name is already widely used. What would you suggest instead? Apr 13 14:54:55 keep in mind that "XML Serialisation of HTML 5" is just a little too long Apr 13 14:54:57 anything withouth XHTML in the name. the xhtml family has clear conformance rules. and that name will never make it through w3c balloting, nor past the w3c comms team. like I said, too confusing. Apr 13 14:55:03 (i could go on with more topics, but i do not want to abuse. what do you people think of that anlysis?) Apr 13 14:55:28 sbuluf: you are not wrong. interesting take on timbl's motivations Apr 13 14:56:13 btw, love chris wilson's mail. thanks for showing it o me Apr 13 14:56:41 shanem, you might want to check exactly what timbl asked for. the html wg charter, to be precise. in that light. Apr 13 14:58:01 shanem, lachy, the story continues: when timbl gave up, the whatwg thought "we won" and "we will be able to do all we wanted". but....microsoft got the chair. and chris wilson wants things that whatwg did not want. Apr 13 14:58:20 (as you can see in that mail, which, imho, is the crux) Apr 13 14:58:24 and so does many w3c members Apr 13 14:58:44 note that w3c members have to vote on any recommendation.... big balloting ahead Apr 13 14:59:41 if the HTMLWG doesn't accept the WHATWG's work and the HTMLWG tries to produce a spec that is incompatible with the WHATWG, the HTMLWG spec will be irrelevant to the real world. But hopefully, that won't happen and we will produce a single spec Apr 13 14:59:50 if xml people get crazy at whatwg people cause they perpetuate all errors, forever...microsoft is even worst. and i think whatwg is finding that out at the moment Apr 13 15:00:54 gonna be interesting. glad I am not sucked into it Apr 13 15:01:06 lachy: "microsoft is to whatwg as whatwg is to xhtml2" <--what do you think of this statement? Apr 13 15:01:41 MS is not opposed to the WHATWG like the WHATWG is opposed to XHTML2, so that's not ture Apr 13 15:01:44 *true Apr 13 15:02:10 lachy, not opposed...but they want even more bugs to be perpetuated: their own set. Apr 13 15:03:12 whatwg wants all current web errors to be perpetuated. but microsoft, *on top* want their own set of bugs, implementation errors, etc, to be perpetuated as well, i mean, apparently Apr 13 15:03:17 whatwg wants to codify what happens when you do things wrong on the web. XHTML refuses to do this. XHTML says.... let me find it. Apr 13 15:03:40 the reality is that we do need to define browser bugs as they are currently, but what MS wants to do is to leave an undocumented set of bugs in IE and require authors to opt-in to the newer, less buggy rendering Apr 13 15:03:59 xhtml is strict, does not want errors. whatwg wants just web errors. and microsoft wants web errors, plus their own errors. Apr 13 15:04:09 XHTML is mostly silent on the issue of error handling Apr 13 15:04:45 beyond the draconian handling of XML (which isn't actually compatible with a large portion of the web these days), XHTML1.x defines no error handling Apr 13 15:04:46 Lachy: well... since I wrote all of the error handling text there is in XHTML... its not that we are silent, its more aggressive than that Apr 13 15:05:09 ok, then show me Apr 13 15:05:16 trying to find it Apr 13 15:05:49 meantime, can i say how this whole battle could be fixed way better (imho, of course)? Apr 13 15:06:01 sbuluf, how? Apr 13 15:06:39 xhtml is strict, does not want errors. whatwg wants errors...cause they think they are unavoidable. but...why is that? Apr 13 15:06:51 because, up to today, we hand code Apr 13 15:07:13 if we hand code, then *of course* we will always have errors Apr 13 15:07:18 because the WHATWG did research to show that a significant portion of the web is filled with errors and there needs to be intereoperability between browsers in how they handle those errors Apr 13 15:07:34 the errors aren't going anywhere, but the browsers are forced to be compatible with them Apr 13 15:08:01 lachy, may i a little bit more? Apr 13 15:08:14 hand coding is not the cause of errors, it is author incompetence and poorly built WYSIWYG authoring tools that generate rubbish Apr 13 15:08:46 we have two problems: old content, and new content Apr 13 15:08:47 sbuluf, only if what you have to say is sensible Apr 13 15:09:01 let's focus on new content for a sec Apr 13 15:09:19 if we hand code it, we will have errors, of course Apr 13 15:09:36 what evidence are you basing that statement on? Apr 13 15:09:39 if we use WYSIYG editors *that exist today* we will have errors as well Apr 13 15:09:43 handcoding != errors in code Apr 13 15:10:10 what we need, instead, is WYMIWYG editors that output perfect code Apr 13 15:10:35 such editors are going to take a long time to come out Apr 13 15:10:43 lachy, well...if we can code wityh no errors, then why is avaryone pushing for error handling? Apr 13 15:10:51 disagree. what we need is user agents that refuse to accept broken code. Apr 13 15:11:05 ShaneM, that is incompatible with the real world! Apr 13 15:11:25 idealism doesn't change reality Apr 13 15:11:29 we need both strict editors, and strict UA's Apr 13 15:11:47 but we can not have strict UA's unless we provide strict editors Apr 13 15:11:48 so? change the world. seriously. new doctype. when I use the new doctype then the user agent rejects broken stuff. Apr 13 15:12:23 its basically a refinement of what chris is saying in his mail. use the switch to turn on strict mode. Apr 13 15:12:27 shanem, i have no problems with breaking compatibility totally, myself, if needed Apr 13 15:13:04 That would not be feasible in the real world because new content will be developed while old browsers are still in use and users would just switch to a much more forgiving/older/less obtrusive browser Apr 13 15:13:20 but...was xhtml, even xhtml2, thought with WYMIWYG editability in mind? no Apr 13 15:13:45 yes, absolutely it was. tools are an essential part of our success strategy for xhml 2. Apr 13 15:14:18 shanem, show me the screenshots, please. it would be really good news, but i don't believe it is the case Apr 13 15:14:31 please prove me wrong. please. Apr 13 15:14:35 I didn't say we were developing the tools. we were designing with them in mind. Apr 13 15:14:49 show me some UI screenshot, please. Apr 13 15:14:53 even a fake one. Apr 13 15:15:00 XHTML2 wasn't developed with reality in mind Apr 13 15:15:12 I think we are going to need to agree to disagree. Apr 13 15:16:02 unless i'm onto something, then to break or not to break compat, is the unsurmontable divide between the two wg's Apr 13 15:16:39 (or unless i'm right about timbl's motives) Apr 13 15:16:43 no - that's right. the xhtml 2 working group is not capricously breaking compatibility. Apr 13 15:17:05 but we have no prohibition against it Apr 13 15:17:11 exactly Apr 13 15:17:22 and the other wg would never agree with it Apr 13 15:17:32 hence, the divide is unsormountable Apr 13 15:17:45 and that's okay. they are different with different goals Apr 13 15:17:46 (you would never agree to the opposite either) Apr 13 15:17:52 and different media types Apr 13 15:17:56 that's fine, yes Apr 13 15:18:32 good lord it is late. I have a meeting in 5 hours. gotta get some sleep Apr 13 15:18:40 night, shanem Apr 13 15:18:53 thanks for your insights Apr 13 15:19:09 thank you, we might keep at it some other time =P Apr 13 15:19:48 did you find that link ShaneM ? Apr 13 15:19:58 the XHTML error handling you were going to show me? Apr 13 15:20:09 Lachy: I can't find the text I was looking for about document conformance. sorry. its not really about error handling. Apr 13 15:20:42 the text said, in effect, that xhtml defines behaviior in the presence of correct data. and does NOT define behaior int he presence of incorrect usage. Apr 13 15:20:44 ok, but if you find it later, show me Apr 13 15:21:01 exactly, so it doesn't define error handling at all Apr 13 15:21:28 but agressively. like - it wasn't an accident. Apr 13 15:21:29 it ignores the fact that authors make errors and browsers will be forced to handle those errors in one way or another Apr 13 15:22:20 (with perfect editors, they would not make errors...right or wrong?) Apr 13 15:22:36 wrong probably. no such thing as a perfect editor Apr 13 15:22:50 but an editor that validated content.... would at least warn you Apr 13 15:22:52 we could discuss ideas. but shanem has to sleep Apr 13 15:22:57 next time, perhaps. Apr 13 15:22:59 yeah... gotta go. thanks again Apr 13 15:23:04 thank you Apr 13 15:23:09 bye Apr 13 15:23:55 there is this text in xhtml2: Note that this specification does not generally specify the behavior of conforming implementations when presented with non-conforming documents. This is either defined by an underlying specification (e.g., [XML]) or left to the implementor. Apr 13 15:24:00 end of section 3.2 Apr 13 15:24:06 http://www.w3.org/MarkUp/2007/ED-xhtml2-20070402/conformance.html#s_conform Apr 13 15:24:26 night Apr 13 15:24:38 night.