XHTML 2 Cancelled

Jake Lazaroff writes "According to the W3 News Archive, the charter for the XHTML2 Working Group — set to expire on December 31st, 2009 — will not be renewed. What does this mean? XHTML2 will never be a W3C recommendation, so get on the HTML 5 bandwagon now. According to the XHTML FAQ, however, the W3C does 'plan for the XML serialization of HTML to remain compatible with XML.' Looks like with HTML 5, we'll get the best of both worlds."

Comments

Re:Well this is a surprise...

[werfu]

The W3C oversee current net content standard evolution. As it's name imply, it's a consortium. It regroup browser developpers, server developpers, thier application developpers, and many others. It doesn't try to override browser developpers. It oversee them on a technical standard view point. Browser developpers submit improvement for them to be included in the norm. This way it garantee that browsers don't split too much from each others.

CSS 3 spec

[Piata]

More importantly, when are they going to finish the CSS3 spec?

I love that HTML5 is getting pushed to the forefront and browsers are advancing more than ever, but as a web designer that CSS3 spec needs to get done and pushed on the browser developers because it will be another 2 - 5 years before mass adoption and I'm pretty tired of CSS2.1's limitations.

Re:XHTML merged

[PenguSven]

Agreed. XHTML was rather pointless. It didn't add any particularlly interesting features, made pages more difficult to author, and its claim that it made life easier for browser authors was belied by poor support and slow rendering. Making things more "XMLish" with closed tags and quoted attributes was a good idea, but in reality writing XML-conformant CSS/Javascript XML was a pain in the butt and usually not done. I suppose XHTML might have been useful as part of a document management/transformation system, but it didn't seem to offer much to most web developers.

The ability to parse a web document using native XML methods is pointless? As for CSS/JS in xhtml. How hard is embedding the content as CDATA? Why are you even embedding CSS/JS in the XHTML? If web developers don't need the XML parsing functionality, they can keep using HTML 4.01. As for HTML5 - technically HTML5 consists of HTML5 (using the HTML syntax rules) and XHTML5 (using the XML syntax rules). I think it's great the W3C have "one" standard to work on, but if you think HTML5 is ready to go any time soon, don't kid yourself. Stick with either HTML4 or XHTML for now. It will take some time before it's safe to deploy valid (X)HTML5 documents for general consumption.

Re:XHTML merged

[Phroggy]

But, XHTML has corrected many wrong thing that HTML developpers used to do.

No it hasn't! Writing valid code (be it HTML 4.01, XHTML, or HTML 5) and checking it with a validator is what has corrected many wrong things that HTML developers used to do. Valid HTML 4.01 is still just as legitimate as XHTML ever was.

Re:XHTML merged

[Phroggy]

XHTML would have been great standard.

When fed invalid XHTML, the browser chokes, which would have gone a long way to eliminating much of the crap code, and crap "web developers" out there.
I don't see why it's the browsers business to be THAT lenient, and second guess the developer all the time.

The problem is, a lot of web pages today are not a single coherent document, they're a bunch of little code fragments concatenated together (template, content, advertising, etc.). When coders get sloppy, this can result in invalid markup. When browsers choke, the content producer may have no idea how to fix the problem - it may not even be their problem.

What HTML5 tries to do is clearly define exactly how broken markup is supposed to be handled, so all browsers can try to "second guess the developer" in exactly the same way.

Kudos to Firefox for reigniting the browser war. In Browser War 2.0, all the major players are striving toward standards compliance, trying to bring their behavior in line with a single unified goal instead of adding their own proprietary features to HTML itself. Five years from now, when IE6 and IE7 are as distant a memory as IE4 and IE5 are now, web development is going to be a lot easier.

Re:Rendering

[mat catastrophe]

Does this mean that someday /. will actually render properly in a browser? I used IE, FF, Opera, and Safari all regularly. /. does not reneder 100% in any of them :(

How do you know that one of them isn't proper and the rest are merely deviations from proper? Or, more accurately, how do you know what it is supposed to look like if you say they are all wrong?

Re:XHTML merged

[thetoadwarrior]

Anyone too lazy to code nice neat xhtml shouldn't be allowed to create web pages.

Re:Good

[Hurricane78]

The main key is, that, while HTML5 is based on the superior SGML (because of more freedom), XHTML had started to enforce strictness and cleanness. This meant the browser did not have to support a ton of typos, just because the editor was a freakin' lazy ass. Imagine a compiler that would eat any typo. Missing brackets, braces, semicolons, object-function separators, completely meaningless semantic messes. HTML4 browsers eat it all.

It is horrible, and actively supports the dumbing down of people. (Those who want to write websites.)
Face it: If they have to, they will learn it. Nobody is too stupid for that. Some just repeat so often that they are stupid, that they actually become stupid. But this can be reversed in exactly the same way. (Ask any psychotherapist about self-fulfilling prophecies.)

Another great feature of XHTML, was its modularity and cross-language features.
You could integrate XHTML, SVG, MathML, etc, into one document. Imagine a P tag inside a SVG circe, containing a math formula, and you begin to understand the sheer power of that concept.

Now if they implement HTML5 right, and we get the same cleanness that XHTML 1.1 had (Strict only. No transitional shit.), and they add cross-language abilities too (trough SGML), then I'm all for it!
But if not, this could be a huge step backwards, into the web development mess of IE6 times!

Re:XHTML merged

[TheRaven64]

Getting a web page clean is a hard problem ... when you accept user input in something approaching HTML format, like /. does.

No it isn't. You should not ever, ever, be inserting user-provided HTML directly in to a document. If you do, then well done, you've just created a cross-site scripting vulnerability. And you've let pranksters submit &lt!-- and hide half of your page.

The correct way of handling user-provided HTML is to parse it with an HTML parser, construct a DOM tree, navigate this stripping out any tags that aren't on your whitelisted set, and then use the result. Most of the time, you want to run it through a very relaxed HTML parser because hand-typed HTML in a web form is likely to be full of errors. When you dump the DOM tree as HTML, it can be XHTML 1, HTML 3.2, or any other dialect you want.

HTML 5 parsing is just awful.

[Animats]

At least with XML you have a simple, well-defined way to convert the XML text to a tree. With HTML 5, there's only "well-defined error handling". Read the sort-of specification for this.

Here's what's supposed to happen for just one of the hard cases. (There are dozens of other cases, some at least as ugly.) Parsing is in "body" mode (normal content) and an end tag whose tag name is one of: "a", "b", "big", "code", "em", "font", "i", "nobr", "s", "small", "strike", "strong", "tt", "u" has been encountered.

Follow these steps:

1. Let the formatting element be the last element in the list of active formatting elements that:
   • is between the end of the list and the last scope marker in the list, if any, or the start of the list otherwise, and
   • has the same tag name as the token.

   If there is no such node, or, if that node is also in the stack of open elements but the element is not in scope, then this is a parse error; ignore the token, and abort these steps.
   Otherwise, if there is such a node, but that node is not in the stack of open elements, then this is a parse error; remove the element from the list, and abort these steps.
   Otherwise, there is a formatting element and that element is in the stack and is in scope. If the element is not the current node, this is a parse error. In any case, proceed with the algorithm as written in the following steps.

2. Let the furthest block be the topmost node in the stack of open elements that is lower in the stack than the formatting element, and is not an element in the phrasing or formatting categories. There might not be one.
3. If there is no furthest block, then the UA must skip the subsequent steps and instead just pop all the nodes from the bottom of the stack of open elements, from the current node up to and including the formatting element, and remove the formatting element from the list of active formatting elements.
4. Let the common ancestor be the element immediately above the formatting element in the stack of open elements.
5. Let a bookmark note the position of the formatting element in the list of active formatting elements relative to the elements on either side of it in the list.
6. Let node and last node be the furthest block. Follow these steps:
   1. Let node be the element immediately above node in the stack of open elements.
   2. If node is not in the list of active formatting elements, then remove node from the stack of open elements and then go back to step 1.
   3. Otherwise, if node is the formatting element, then go to the next step in the overall algorithm.
   4. Otherwise, if last node is the furthest block, then move the aforementioned bookmark to be immediately after the node in the list of active formatting elements.
   5. Create an element for the token for which the element node was created, replace the entry for node in the list of active formatting elements with an entry for the new element, replace the entry for node in the stack of open elements with an entry for the new element, and let node be the new element.
   6. Insert last node into node, first removing it from its previous parent node if any.
   7. Let last node be node.
   8. Return to step 1 of this inner set of steps.
7. If the common ancestor node is a table, tbody, tfoot, thead, or tr element, then, foster parent whatever last node ended up being in the previous step, first removing it from its previous parent node if any.
   Otherwise, append whatever last node ended up being in the previous step to the common ancestor node, first removing it from its previous parent node if any.
8. Create an element for the token for which the formatting element was created.
9. Take all of the child nodes of the furthest block and append them to the element created in the last st

Re:No more compound documents?

[Bogtha]

Take a look at the current draft of HTML 5. You'd be hard-pressed to find anything presentation-related.

I think this attitude is more a case of wishful thinking and sometimes outright denial rather than than reality. Take a look at some of these, for instance:

1. <br> and <pre> - explicitly control line-breaking (<pre> has ASCII art as a use case!).
2. <ul> and <ol> - the order of HTML elements already forms part of their semantics. The real reason both element types are kept around is because one is numbered and one is not.
3. <small> - nuff said.
4. <i> - I'll quote this, because it's utterly laughable: "The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, a ship name, or some other prose whose typical typographic presentation is italicized." - or, in other words, "let's list every case we can think of where using italics is the typographical convention so we can pretend it isn't an element type that means use italics." Are there any real shared semantics between a ship name and a thought? No, they just want to use italics.

Re:Good

[css-hack]

But by working that way, the computer encourages people to create unreadable messes, that other developers can't easily understand.

Simpler parsing rules are more a boon for the people than for the computers. Think about it.

Re:Good

[moderatorrater]

It is horrible, and actively supports the dumbing down of people.

This is where I take issue with your argument. I completely agree that having the page break catastrophically when there was an error would be easier and better for people who design websites professionally (like me), especially in this day and age.

However, I don't believe that it supports the dumbing down of people, I believe it support less knowledgeable users. To use the compiler as an example, when my sister-in-law learned programming, she learned Java; to get to the point where she could do basic things like "hello world," she had to instantiate objects and call functions. My wife learned with php, and she had to type one line, a command and a string. The barrier for entry was much lower and she was rewarded much faster, thereby gaining a greater desire to learn more.
Br. At the time, browsers taking incorrect HTML was the same philosophy: you lower the barrier of entry. When someone writes a lot of web pages, they tend to become more knowledgeable, not less. There are exceptions that make everyone serious about the craft cringe and want to beat their heads against a brick wall, but for the most part skills are progressing. I don't know whether the web landscape would be better or worse right now if they'd required strict HTML for every web site, but I can tell you that a lot of people who were enthusiastic supporters and creators of web pages in the early days wouldn't have gone down that route had the barrier for entry been higher.

Re:Good

[ultranova]

So, what you're saying is that the computer works for people instead of the other way around?

No, what it means is that the computer tries to guess what some dyslexic jackass who insists on writing code despite being functionally illiterate and proud of it meant. Since we have no sentient computers yet, and since the markup diarrhea these people produce would be challenging even for a human to decrypt, the task is hopeless, and the websites that result will break in fascinating ways with each new browser version, or whenever whoever visits them has a different screen resolution than the "designer", or the stars are not just right. And whenever that happens, the website gets replaced by a new, equally broken version, and the designer gets paid for delivering said abomination.

And of course whenever the browser fails to extract meaning from the chaos that would horrify even Cthulhu, it's the user who gets blamed: he didn't use the right version of the right browser, running at the right resolution, with the right versions of the right plugins installed. That, or he has Linux installed on another and unrelated machine.

Re:XHTML merged

[Blakey Rat]

Bullshit. Every person on Earth should be allowed, and encouraged, to create web pages. I hate this elitist crap.