Brendan - well you’d have to agree that sites like Facebook (for profile pages) and Amazon (for reviews, comments, lists, etc.), among many others, hide the complexity of authoring HTML from average users. Perhaps we’ll never have a really effective WYSIWYG HTML editor, because WYSIWYG is simply poorly adapted to authoring markup (I don’t believe this to be the case, but I can certainly see the argument), but one future I don’t see happening is the average Joe or Jane authoring HTML by handcrafting tags.

They out number XML freaks 1,000,000 to 1. Please get a grip! Open your eyes to reality!

XML was a nice idea, but I’m a python coder and I still find XML to be verbose, ill defined, and mostly useless.

.csv is the future baby.

monk.e.boy

First, there are lots of WYSIWYG editors that create invalid markup (some popular SVG ones led to a bugzilla bug asking us to impute xmlns= settings just to interoperate — this while SVG has tiny “web content market share”!).

Second, so long as the web is alive in the sense that new combinations (mashups) of existing and new content can be cheaply created, whether or not tools are in the loop, you will get copy/paste injection of markup that violates well-formedness; and at the margins you will get (and should want!) hand-tweaking.

I’ll believe the WYSIWYG utopia when I see it, which may be the same as saying when I kick the bucket (not saying whether it will be heaven or hell ;-).

/be

Google data

Microsoft reference

It would be nice if I could avoid having to type that icky HTML, though….

1) About 7% of the feeds Google Reader runs into are not well-formed XML. See . Feed readers apparently vary in how they handle the problem. Firefox doesn’t enforce encoding validity (a bug); not sure about the rest. IE7 at least planned to enforce well-formedness, apparently: see . Not sure whether they stuck by that.

2) A very large number of (popular) RSS feeds are not served with an XML MIME type. This has necessitated that Firefox sniff _all_ incoming content to determine whether it might be an RSS feed. Dedicated RSS readers ignore the MIME type altogether (treat everything as a feed), which is how we got to this mess.

If this is the future XML web, I want out.

IE needs to be fixed to play nicely with HTML served as XML, or XHTML. The other browsers seem to have their mime types in order, but until the big one does, we won’t seem much change. Maybe IE8?

The problems with XML namespaces wouldn’t be too hard to fix. This isn’t to say that XML is perfect, but most of its flaws are man-made, not inevitable.

I’m not sure that I agree about the web continuing to be hand-crafted. More and more pages are coming out of publishing engines: Wordpress, Facebook and Amazon to name a diverse sample. And I would tend to believe that where people are publishing markup by hand, they’ll use some sort of WYSIWYG tool. I know that usable HTML WYSIWYG editors have been a long time coming, but someone has to get it right eventually.

But I think there are severe usability problems with XML apart from this “how to get there” issue. Micah Dubinko and Oliver Steele have blogged about just the problems with namespace usability, and we see this all the time in SVG content, with E4X users, etc.

What’s more, I contend that the Web is and will remain a human-crafted artifact, not mostly machine produced in its hypertext content, therefore error correction must be part of normative specs for its main text-like content languages.

Finally, I dispute both claims in this paragraph: “The good news is that if major browser vendors enforced correct markup, authors would rapidly get a clue, just as they have been scrambling to fix pages that don’t play well in Firefox as the latter’s market share has grown.”

Too many pages still don’t work with Firefox, and often the page author (a consultant to some bigdumbcompany.com) is long-gone. Sure, this may be a variation on the Prisoner’s Dilemma, but I wanted to point out that your hopeful statement here is over-optimistic, in our experience. The WHATWG work may pay off in a few years and change my reading of reality, but we’re not there yet.

/be

Regarding WHAT WG: I totally agree, this is a great effort and certainly a highly pragmatic approach to a really thorny issue. A true XML web would still be better but even to a dreamer like me that’s years away, so a better HTML web would be a great way to tide us over in the meantime.

The good news is that if major browser vendors enforced correct markup, authors would rapidly get a clue, just as they have been scrambling to fix pages that don’t play well in Firefox as the latter’s market share has grown.

The problem with this argument is that major browser vendors would simply never choose to break 97%+ of exisiting content, let alone simultaneously, and even if they did, it would not have the effect that you describe. Any browser vendor who did refuse to render “broken” HTML would find that no user would be prepared to use their browser. Even if somehow all vendors decided to simultaneously release super-strict versions of their browsers, the net effect would be users sticking with their current web-compatible browser rather than taking an upgrade that would break the vast majority of the web. No doubt, in time, many sites would be fixed to adhere to the new requirements but there would still be a great deal of valuable legacy content that would work better in a less strict browser. What are the odds that every browser vendor would stick with the coallition when, by loosening up a bit they could capture a huge chunk of the market? Indeed, such loosening up need not be intentional; simple bugs in popular UAs can become depended on to the extent that the buggy behaviour must be copied by other UAs. Therein lies the heart of the problem; requiring strictness in content handling is requiring everyone to maintain an unstable equlibrium. It may sound good in theory but it can’t happen in practice.

By far the most significant argument for XML on the web, however, is the complexity of existing HTML processors, a direct result of the compatibility hacks required to deal with naughty content.

Hopefully that argument has been substantially weakened now the WHATWG has invested significant effort in documenting the behaviour required by a web-compatible HTML parser. That takes most of the effort out of implementing a HTML parser because you don’t have to come up with your own scheme to deal with the hard issues like residual style. Indeed the general feeling amonst people familiar with both the WHATWG spec and the XML spec is that it is not significantly harder to implement the WHATWG spec than the XML spec (XML has a lot of complexity to do with the DTD, entities in the internal subset, etc.), nor need the result be significantly less performant. Of course a HTML parser still has to do unintuitive things, like magically inserting tbody elements, at times but that is apparently not so difficult to understand that it has significantly affected the popularity of HTML.