W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2006

[whatwg] several messages about XML syntax and HTML5

From: Mike Schinkel <mikeschinkel@gmail.com>
Date: Mon, 4 Dec 2006 06:14:28 -0500
Message-ID: <029501c71795$5e2a39a0$2102fea9@Guides.local>
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

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:31 UTC