- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Thu, 08 Jan 2009 21:06:36 +0000
- To: Brett Patterson <inspiron.pattersonb@gmail.com>
- CC: Mark Birbeck <mark.birbeck@webbackplane.com>, David Woolley <forums@david-woolley.me.uk>, Molte <molte93@gmail.com>, Shavkat Karimov <shavkat@seomanager.com>, HTML Working Group Discussion Mailing-List <www-html@w3.org>
On 8/1/09 19:52, Brett Patterson wrote: > All in all, most of > the same problems keep arising as an argument, and instead of trying to > use the same arguments as, well, arguments, can we not try and figure > out how those said arguments can be fixed? Do you have any concrete suggestions? e.g. You mentioned creating Transitional and Strict document types, but it's unclear what user problems this would solve or how exactly it would help merge HTML5 and XHTML2. > As for some of the advantages I see, here goes: > > * stops having to decide which language to go with. Like with any other technology, people should evaluate whether it meets their needs. I don't think that is a problem to be solved by creating fewer technologies. > * it helps to ensure that most browser makers (not counting Internet > Explorer, as we all know how that goes) will not mix old languages > with the new or create their own languages, preventing page read > errors or hard coding times. When you speak of browser vendors mixing "old languages with the new", I'm not sure what you mean, or why it is a problem. Why would combining HTML5 and XHTML2 would prevent browser developers inventing their own language features? > * people can decide which is best for them to code with in general. > (if going with the Strict and Transitional subsets) There are no plans to have a conforming subset of HTML5 including bad features that it has any chance of persuading people not to use. That approach to deprecation does not work, since people simply produce new documents conforming to the bad subset. The failure of HTML 4.01 Transitional to be used only for old documents is testimony to that. > * less of a headache when coding applications, due mostly to less > rift-raft floating in the code. (if going with the cleaner code > from XHTML) What sort of applications are you talking about? What "rift-raft" are you talking about? What "headache" are you talking about? What "cleaner code" are you talking about? (And "cleaner" how?) How would combining HTML5 and XHTML2 reduce this headache? > * makes requirements (or standards, specifications, whatever you > want to call it) for disabled people easier to cope with. How? > * makes keeping requirements from the specifications of the code > itself easier. I don't know what this means. > I have a lot of other advantages, as well. Rather than thinking up advantages, it might be worth trying to work out what the goals of the two projects are and how it would be beneficial to both projects to "combine" them and what "combining" them means in practice. If you cannot be reasonably specific about why and how, it's very difficult for anyone to evaluate such proposals. Mark and I seem to be disagreeing about what the goals of XHTML 2 are. I'm not part of the XHTML 2 WG (not sure about Mark's status), so I don't feel I can speak with any authority on the matter. But I can point you towards public documents describing what these projects are meant to achieve. + HTML5 * HTML WG charter: http://www.w3.org/2007/03/HTML-WG-charter.html * HTML WG Design Principles: http://www.w3.org/TR/html-design-principles/ * WHATWG Charter: http://www.whatwg.org/charter * WHATWG FAQ: http://wiki.whatwg.org/wiki/FAQ * HTML5 Introduction: http://www.whatwg.org/specs/web-apps/current-work/#introduction + XHTML 2 * XHTML 2 WG Charter: http://www.w3.org/2007/03/XHTML2-WG-charter * HTML and XHTML FAQ: http://www.w3.org/MarkUp/2004/xhtml-faq * XHTML 2 Introduction: http://www.w3.org/TR/xhtml2/introduction.html I made a hypothetical proposal in the email you quoted, based on what Mark seemed to be saying about XHTML2's goals. Does that merger match what you're thinking of or not? > But without knowing some of > the more advanced features I will stop now before getting ahead of > myself. [snip] > There is no true part of the two different languages that will prevent a > language merger. How can you say this with such certainty without "knowing some of the more advanced features" that you are proposing be combined? -- Benjamin Hawkes-Lewis
Received on Thursday, 8 January 2009 21:07:14 UTC