- From: Mike Schinkel <mikeschinkel@gmail.com>
- Date: Mon, 4 Dec 2006 06:14:28 -0500
Ian Hickson wrote: >> I've been having a lot of trouble following this >> discussion Are there other requests? What are they? 1.) Minimize the changes *required* for existing documents to validate as HTML5 2.) Provide strategies that make transitionality possible, and provide incentives for moving in that direction. For example, it could be a new media type that encompases many different media types first trying XHTML and then trying HTML5, where the user agent allows uses to try different subset media types if the one chosen by the browser did not display well. Of coruse the fastest to display would be XHTML, giving site owners a reason to go with that. OR the user agent could be given the authority to try the different ones whenever it sees text/html. ( 3.) Not to incorporate additions to HTML5 which cannot be added to XHTML. 4.) Minimize the number of differences for people to have to learn and implement HTML and XHTML. That would mean avoid divergence whenever possible. This could even mean planning to change XHTML at some point in the future. Or it could mean having the W3C deprecate XHTML and withdrawn it from recommended use. >> > Mike Schinkel wrote: >> > "Striving to be XHTML, but if not consider me HTML5." >> Browsers wouldn't implement this due to performance concerns >> (it was considered for XHTML-as-text/html back in the day). >> It also would result in dramatically different renderings, just >> because there was a minor well-formedness error one day. Even if the spec said they MUST do it, they wouldn't? Even if the user had the option to toggle through different renderings? >> I have huge doubts that this would pass even elementary >> usability testing, because most users would just say "I >> don't care". But that's the thing; usability wouldn't matter; let users ignore it. But site owners would fear that it turned off users and they would then be motivated to fix it, especially if the echo chamber that clamors for standards makes a big stink about it. You need a forcing factor to empower change; Google (and Yahoo and MSN) could make it happen. Hell, why not test it for a while (like you tested Google Answers) and see if it works or not. Certainly it couldn't be worse than not doing it. >> There is work on this. Join #whatwg on Freenode to take >> part if you're interested. Unfortunately, using IRC doesn't allow me to schedule my time like I need to. >> > And what MIME type should he be using that will work on today's >> > Internet? >> text/html. Which means using HTML, not XHTML, because text/html >> content is processed as HTML, not XHTML. Why not have text/html5? (If that's a stupid question, please realize I'm writing this really late.) >> Mostly because they have almost as much in common with XML >> as HTML5 does. (That is to say, they aren't XML Data Islands, >> they're "Microsoft Custom Markup Extensions For HTML".) How about *real* XML Data Islands then? >> Drop the string concatenation, and move to outputting HTML5 >> using an XML pipeline with an HTML5 serialiser on the end. (This >> would basically mean dropping the HTML4 code, simplifying the >> CMS, and making very few changes to the XML serialiser.) >> >> Move to HTML5 with an XML pipeline. (This is basically the same >> as number 6, except that there's no code to drop first.) You do realize that this will happen over a period of many years if it happens at all? And in the mean time...? >> > That's an excellent point. My answer is that I was sold on the benefits >> > of XHTML, and I still believe in them so I don't want to give up on the >> > hope that I can eventually get there. >> Just out of interest, could you say what those are? It's likely that HTML5 >> actually has the same benefits, so that you don't lose them by using HTML5 >> instead of XHTML5. * A single direction, not multiple (Fan in, not fan out) * Reduction is the number of ways to do things (XHTML vs. HTML) so we don't have to ponder over too many options. I'd be happy to see XHTML deprecated; I just want one standard that is ideally backward compatitble with a workable transition strategy to a more elegent subset. If HTML5 can be that, then great. IMO, there should effectively be only *one* standard for displaying content on a website home page (and other pages that aren't specific something else like PDF.) Having more than one just ends up metaphorically creating the same problems experienced in the biblical tower of babel. Okay, as I'm reading all the writing about there being no point to XHTML vs. HTML 5 let me make this distinction between XHTML and HTML: * For XHTML there is mostly one good way to do this. * Because HTML is so lax, there is no standardized and universally accepted advice (AFAICT) for what constitutes the best way to code an HTML document. Will there (could there be) a subset of HTML5 that is presented as the preferred way to code HTML5? And if XHTML is going to continue to exist, can that preferred way be as close to XHTML as possible? -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ P.S. One final note. I think your job keeping track of everyone's issues here is overwhelming, and I'm amazed that you can do it. Kudos.
Received on Monday, 4 December 2006 03:14:28 UTC