Wow, this is a huge development! WHAT-WG [whatwg.org] was set up specifically to address the exact concerns given in TBL's article. The following is particularly telling:

Some things are clearer with hindsight of several years. It is necessary to evolve HTML incrementally. The attempt to get the world to switch to XML, including quotes around attribute values and slashes in empty tags and namespaces all at once didn't work. The large HTML-generating public did not move, largely because the browsers didn't complain. Some large communities did shift and are enjoying the fruits of well-formed systems, but not all. It is important to maintain HTML incrementally, as well as continuing a transition to well-formed world, and developing more power in that world.

Whilst the W3C is not actually abandoning XHTML development, this is a 180-degree turnaround which will put the emphasis back on the tool of choice for 99% of web developers. HTML is back!

Earlier related threads:

Why most of us should NOT use XHTML [webmasterworld.com]

What do you want to see in HTML 5? [webmasterworld.com]

Hurrah! I always thought that XHTML was overkill.

Now it's roadkill.

Guys:

Unlike the previous one, this one will be chartered to do incremental improvements to HTML, as also in parallel xHTML. It will have a different chair and staff contact. It will work on HTML and xHTML together.

xHTML ain't dead yet ... although it may become disused for simple web page creation.

emphasis added by le_gber

Cool news. Should we start a new thread (since the old one is closed) about what you'd like to see in HTML?

I'd like to see:

1. Combo drop down box in forms. Where you provide a list of choices but if you want to let the client type in an alternate one, you shouldn't have to add an extra element called "other" combined with javascript to enable an input box which has to be hidden when one of the other choices are there.
2. More options in forms for boxes like: email input box, url input box etc. So there will be automatic client validation of proper email or proper url. It won't remove the need for server validation but for security, but it will help make sure your customer type things write in the first place.

How about these:

1.
I use DIVs to display scrolling product lists (if too long). If the page is reloaded the position in the list is lost. Would be cool to have something like an <a> tag inside a scrolling DIV so I can re-display the list at the right position.

something like: mypage.com##divname->a2##divname2->a5

2.
A rich text editing control that works on all major browsers and handles css. Should be possible to configure editor functions, uploads, etc.

nerd.

Hi - I just want to point out something on the 1st "related thread" posted by encyclo
[webmasterworld.com...]
This thread starts w/ a link to a document on problems w/ xhtml sent as text/html at
[hixie.ch...]
One of the next posters ('buckworks") points out that "Ironically, the article referenced in the opening post is totally broken and unreadable in Safari."
I viewed the source & instead got a plaintext file of the article in question. So safari users can read this important article if they right click to view source.

This does not really seem like a positive development. In a way this is saying, "We set the bar too high and we're going to lower it because people are too dumb to add a space and slash at the end of an element."

My early perception of this is that it not only puts a drag on progress but encourages the use of HTML over XHTML. The timing of this directly after the release of IE7 also suggests that this will be a ripe excuse for Microsoft to not support XHTML (by adding support for the application/xhtml+xml mime) in Internet Explorer 8 which I have heard rumors (but unable to personally confirm myself) to be released 18 months after IE7.

This is really only a victory for sites such as Target that use programs instead of programmers.

- John

We set the bar too high and we're going to lower it because people are too dumb to add a space and slash at the end of an element.

Why do you say that? Because html will be extended at the same time xhtml is also improved?

I really see things differently. The issue is creating ever more effective tools to get the job done. And what that job is, exactly, is different in different situations. The tool needs to fit the application, and not the other way around.

As I see it, it's the movement to strict mark-up that matters the most, rather than requiring everyone to use a form of xml, which is overkill in many situations.

In terms of this thread, improving what mark-up offers means extending the tools that delineate semantic clarity in both the html AND xhtml worlds -- which should be understood as different spaces with different requirements.

If there was any particular past error, I feel it was the creation of transitional xhtml. XHTML should have been more rigorous right out of the starting gate. Transitional xhtml allowed people to close a few elements and still keep their fuzzy, ambiguous and presentational approach mark-up.

Argghh! The end is nigh...

What's the problem with XHTML? It's great. And if people are using WYSIWYG programs to create their web pages then can't they set the output as XHTML instead of HTML4? OK, dreamweaver does a pants job of xhtml last time I looked at it, so maybe not...

It seemed to me that XHTML 1.0 was just HTML 4 with the internal inconsistencies tidied up. The differences between the two are minimal. Portraying XHTML 1.0 as a stepping stone to the 1.1 and 2.0 drafts was a bad idea though.

I hope this move doesn't see the W3C's commitment to XHTML 1.0 falter. In concept it's a *good* thing, despite IE's continued lack of support.

Am I the only one who fears 'incremental improvements'? The wildly differing support for the varying increments of CSS has proven that incremental standards have an ugly flip-side.

I can guess what will happen now. Opera and Firefox and Safari will be the first to implement any new changes to HTML over a short period of time. Five years later, Microsoft will implement some, but not all, of the new HTML changes. So hardly anyone will be able to use them. Hope I'm wrong!

I'm quite happy with xhtml, css2 and javascript at the moment. And xhttprequest is making things quite interesting! Rather than mess around making more variations that will be partially supported (like Hester says) wouldn't it be better to educate people to develop better?

Hester has it exactly right. I don't even intend to pay attention to any of this for the next several years, beyond a casual reading of related forum threads if any happen to come up. Any changes should be simple enough to understand, and it will be at least a few years before browser support even approaches reasonable levels.

And is it just me, or shouldn't most of the "missing features" of HTML be done with some kind of programming language in the first place?

The first time I used a WYSIWYG editor, I was surprised to see that the menus were NOT broken down into headings - paragraphs - lists - tables - forms - images - links but were instead broken up by what things LOOKED like. I haven't used one since.

g1smd isn't a WYSIWYG editor some kind of text editor with training wheels and pretty pictures?

Well, it turns out that the effect is WYGIQWYW, so I don't use those at all.

The two obvious missing items from the HTML specification are client-side include of text/html (if images can be shared why not text) and pure html menus.

It is astonishing that either of these should be missing from html but that both are missing is just plain crazy.

In addition, it should be possible to add right-click options to popup menus - this could make web pages feel more like local programs. For instance, it is easy to imagine in a webmail application, right-clicking a link to a mail and selecting the "reply" option from the popup menu. This could function without javascript being enabled.

NOTE TO BROWSER DESIGNERS
Javascript links and target="winname" links should display different cursors to standard links.

Kaled.

client-side include of text/html

Amen to that!

<include type="text/html" src="/copyright-statement.html" />