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

Good

[orta]

I know a lot of web developers who dont know the difference between XHTML and HTML, and I hear XHTML as a buzzword all the time. The less confusion the better in my opinion. The HMTL5 spec is quite readable,but if you've not taken a stab at working with HTML5 (it runs all browsers) yet this article should be pretty useful: http://www.phpguru.org/static/html5

Re:Good

[schon]

I know a lot of web developers who dont know the difference between XHTML and HTML, and I hear XHTML as a buzzword all the time.

Duh. Everyone knows that the "X" is for Xtreme! It's Xtreme HTML, right?

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:Good

[Reaperducer]

Imagine a compiler that would eat any typo. Missing brackets, braces, semicolons, object-function separators, completely meaningless semantic messes. HTML4 browsers eat it all.

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

Re:Good

[grahamd0]

Duh. Everyone knows that the "X" is for Xtreme! It's Xtreme HTML, right?

Brought to you by Doritos, Mountain Dew and the W3C.

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

[dingo8baby]

HTML5 (it runs all browsers)

I don't consider a browser to run HTML5 until it utilizes all tags, not just the ones that are carried over from HTML4

Re:Good

[Anonymous Coward]

Case in point: Why do you think I don't program in perl? Just about everything means something. Typo's are hard to debug, and code written by others might as well be written in Russian. If I ever need to use perl professionally, it will need to be on a daily basis to give it time to really sink in. (much more so than other languages I've used, at any rate)

Re:Good

[omuls are tasty]

Imagine a compiler that would eat any typo. Missing brackets, braces, semicolons, object-function separators, completely meaningless semantic messes.

Must... resist... must... resist...PHP! Bloody PHP! Bloody E_NOTICE!

Oh dear, there goes my karma...

Re:Good

[Anonymous Coward]

No, computer working for people are tools for writing correct HTML (syntax hilight etc...).

Re:Good

[Anonymous Coward]

You know a lot of very mediocre web developers, you mean.

Re:Good

[Anonymous Coward]

SGML doesn't give you any more "freedom" than XML, it's just more difficult to validate, so most web-browsers don't use validating parsers for HTML. When some HTML is missing an end tag (or even a start tag), the parser is supposed to use the schema to decide whether it is permissable, and insert one automatically. XML does not have this ability, so does require such complicated logic.

Re:Good

[Ant P.]

HTML 5 is based on the DOM. The HTML4-compatible syntax is defined from scratch, it isn't based on SGML because no web browser actually parses SGML correctly. Most of them don't do HTML4.01 fully for that matter (IE doesn't do simple things like <q>, Moz doesn't support all the weird table-column align stuff...).

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:Good

[Anonymous Coward]

No. It guesses as to what you were trying to do.

That means that the browser has to have much more code to try and figure out whatever it needs to display; and it might get it wrong.

It means that you should do it properly instead of doing it half-assed and expecting someone else to clean up after you.

Re:Good

[Tacvek]

HTML5 comes in two forms.

It comes in an SGML-inspired format, that is not strictly SGML but matches real word HTML almost exactly. The big difference from HTML4 besides the new tags is that it does not use a DTD, nor does it support the shortag features of SGML, with the exception of the short attribute feature. Thus "<title/</<body/".

(Yes, that has three open brackets, zero close brackets, and 3 slashes) is not valid HTML5, despite being valid HTML4. (At least once you add the DTD).

There is also an XHTML form, which may informally be called XHTML5. Except for the new tags, this is pretty much identical to XHTML 1. In some ways this is the prefered form of HTML5, being that the other form does not support namespaces.

Re:Good

[nadavwr]

Imagine a compiler that would eat any typo. Missing brackets, braces, semicolons, object-function separators, completely meaningless semantic messes. HTML4 browsers eat it all.

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

The computer working for the people would be a fine concept if all you have to maintain is a single implementation of a browser.

Since we have so many browsers in the market and we want them to compete, the standard damn better leave no ambiguity if you ever wish to have simple cross-browser compatibility in web sites -- that's why strictness is important.

Re:Good

[ivucica]

Cleanliness without the target attribute? Excuse me? Fugly javascript so you can open in a new window, which doesn't work with NoScript, is clean? How about iframes? Erm, yes.

Re:Good

[microbox]

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

That was the intention, but the result was a mess. It would have been better if the computer required valid input in the first place, and the world would have saved a fortune.

Re:Good

[Draek]

No, what he's saying is that the computer is telling people what they want instead of the other way around.

Re:Good

[Stan Vassilev]

Must... resist... must... resist...PHP! Bloody PHP! Bloody E_NOTICE!
Oh dear, there goes my karma...

In attempt to preserve your "karma", I give you asolution:

function errorHandler($code, $message, $filename, $line) { die($code .': '.$message.' at '.$filename.' ('.$line.').'); }

set_error_handler('errorHandler');

You know, less talk, more action ;).

P.S.: You could also throw an exception, which is the most convenient option, as you can handle the errors in some cases.

Re:Good

[Blakey Rat]

The real problem is that everybody dropped HTML to work on XHTML in the first place:

"Hey, I know! Let's make a new standard called XHTML Strict which adds *no* new features to the old standard, which doesn't work with the majority of web analytics packages out there, and which adds more complication for browser makers!" "Good idea!"

What a gigantic waste of time and effort-- and now poor browser makers have to support a standard that's completely pointless, and (even worse) was completely pointless even when it was current. Not that the W3C wasting time and effort on pointless things is anything new, but eh.

And now my obligatory "I told you so": I told you so.

Re:Good

[Blakey Rat]

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.

Totally wrong. One of the most important rules in software is: "be liberal in what you accept, and strict in what you output." XHTML does that first part COMPLETELY WRONG.

Here's the thing: while you're going on about dumbing-down, you're completely ignoring the basic power of the web-- the fact that everybody can (and should) participate in it.

You long for a world where, if I put my STRONG tag and my EM tag in the wrong order, a completely trivial error, the browser should show absolutely nothing. Even though it's obvious to everybody what I *meant*, since a computer thinks like a computer and rejects it like a retard.

You know what? I already have enough computer programs that act like retards. I want my software to be smart, so that humans don't have to worry about that trivial shit you seem to relish so much. In the ideal world, software would *do what I mean*, not *do what I say*. Your world sucks.

It doesn't help, BTW, that "dumbing down" is always one of those grouchy "get off my lawn" arguments people make when they don't really have any actual arguments.

And how do we move into your world? Well, first of all we completely and utterly delude ourselves into thinking that HTML4 will disappear overnights and XHTML can make browser simpler to implement. Thus deluded, we then create a new standard which offers absolutely *nothing* new over the old standard, then tell all the browser makers to add that into the already-too-long list of standards they need to support. Oh, and just to cement W3C's isolation from the *actual* work of creating and maintaining webpages, let's make this new standard incompatible with some of the most popular web analytics tags out there.

XHTML was retardation from day 1.

Now the flamebait part: of course what you're probably really after is some kind of elitist high-priesthood-of-technology bullshit for your own selfish reasons.

Re:Good

[pizzach]

It doesn't help, BTW, that "dumbing down" is always one of those grouchy "get off my lawn" arguments people make when they don't really have any actual arguments.

The method for html4 is dumbing down. The method for xhtml1 strict of no displaying nothing is just plain dumb. To many, the web browser is their teacher as that is where they get real world experience. If you hand in your english paper to the teacher and they a) refused to return it and say it was wrong or b) gave it a 100% as long as long as they throught they could understand it, the teaching of English in schools would be a complete farce. This is what is happening with HTML.

Writers need browsers to tell them what went wrong much like a compilers will with errors/warnings. It also needs to be written in a prominent place. That is what I will call dumbing them up. If the errors are inline, even better.

You long for a world where, if I put my STRONG tag and my EM tag in the wrong order, a completely trivial error, the browser should show absolutely nothing. Even though it's obvious to everybody what I *meant*, since a computer thinks like a computer and rejects it like a retard.

Is it really that trivial?

1. The order of how the opening tags is the most important because it is the most prominent.
2. The order of the closing tags is more likely what the user wanted since that is the note they ended on. (Things become more clear as you go along and write your content.)

I'm not seeing what is so obvious. For either there is only an arbitrary % chance you are right. On top of that, if the browser chooses the wrong order, the cascading of the CSS attributes become ALL fucked up.

Re:Good

[Anonymous Coward]

Totally wrong. One of the most important rules in software is: "be liberal in what you accept, and strict in what you output." XHTML does that first part COMPLETELY WRONG.

Far from being "one of the most important rules in software", Postel's law has been all but debunked, at least in this context.

the basic power of the web-- the fact that everybody can (and should) participate in it. You long for a world where, if I put my STRONG tag and my EM tag in the wrong order, a completely trivial error, the browser should show absolutely nothing. Even though it's obvious to everybody what I *meant*, since a computer thinks like a computer and rejects it like a retard.

Maybe *he* does, but many of us don't, and that's not the only reason to advocate XHTML.

As long as HTML is liberal, and we expect people to write it, then browsers all have to have their own intuition at this level. That means anybody writing something that will end up on the web has to know about the whole stack down to the level of the HTML rendering. That seems horribly low-level.

I want XHTML to be rock-solid, with no room for question or interpretation. If it's too hard to write, we can build useful abstractions on it -- like everybody does (Markdown, Wikimedia, etc.) anyway.

I want it to be like those other low-level standards that leave no room for interpretation, like UTF-8. UTF-8 has been a phenomenal success, in part (I believe) because UTF-8 parsers don't have to deal with guessing. Nobody's asking for "well, what if I find four consecutive bytes that start with 10..." in the spec, or in a decoder. If it doesn't look right, the decoder just aborts. (It's largely backwards-compatible with ASCII, so you can sometimes read part of the page if it's wrong, but it's obvious that it's really broken, and you need to fix it.)

HTML should be the same way, and XHTML showed a way to do that. If it's too low-level, you have your tools convert to it. You could even write an HTML4-to-XHTML converter. But the "guess what the user meant" intuition belongs in tools, not in the core specs.

Another big problem is that with all the intuition required in a browser, it makes it virtually impossible for new rendering engines to appear. The web would never get off the ground with the crap we've got out there today. I there to be more than 3 rendering engines in the world, and I want the specs to be simple enough that that's possible to achieve. If you want to talk about "important rules in software" and "the basic power of the web", then we should make implementing a rendering engine that meets the specs *possible*. Right now, no browser will ever come close, and the specs are already 10x more complex than will ever get implemented, but adding "guess what the user meant!" crap just sucks the life out of any progress that these rendering engines have to do. IE8 punted and included IE7-mode -- that's how bad it's getting.

Re:Good

[Waccoon]

I blame development tools.

Every web browser should have a development mode where it will tell you about simple syntax problems with HTML, CSS, JavaScript, and so on. This should have been standard since day one! I mean, really simple things that won't bloat the browser. Complex things like validation can be handled with extensions, like the Web Developer and HTML Validator extensions for Firefox.

Most people I know who do web development aren't aware of a simple typo here and there, and it's hard to validate whole pages when people are making web sites using a mess of templates that requires logins and sessions. You can't use external tools for everything while debugging, and you can't do anything that would risk the end user getting a blank screen or a ton of error messages (as the W3C is trying to do). IMO, web browsers have all done a horrible job of this stuff. Firefox was the first browser I know to even allow debugging of any sort, and even then, everything has to be done with extensions, even though internally, the browser needs to validate everything, anyway.

Nobody can take a browser seriously as a platform (or even as -- *ugh* -- an OS) unless it offers even the most essential debugging tools. Web browsers have done a horrible job of this in the past, and even today the simplest of testing requires a bunch of 3rd party extensions that are usually out of date when new browsers are released. The severe minimalist design of Chrome drives me nuts, too, because it really goes out of its way to hide even the simplest of development features, like View Source, under a complex tree of drop-down menus. WTF? Opera takes development more seriously than other browsers, particularly with image support and limited screen space, but it still lacks many essential validation features.

People can blame IE all they want for standards-compliance issues, but all browsers are to blame for poor web development practices.

Re:Good

[Blakey Rat]

As long as HTML is liberal, and we expect people to write it, then browsers all have to have their own intuition at this level. That means anybody writing something that will end up on the web has to know about the whole stack down to the level of the HTML rendering. That seems horribly low-level.

[snip]

Another big problem is that with all the intuition required in a browser, it makes it virtually impossible for new rendering engines to appear. The web would never get off the ground with the crap we've got out there today. I there to be more than 3 rendering engines in the world, and I want the specs to be simple enough that that's possible to achieve. If you want to talk about "important rules in software" and "the basic power of the web", then we should make implementing a rendering engine that meets the specs *possible*. Right now, no browser will ever come close, and the specs are already 10x more complex than will ever get implemented, but adding "guess what the user meant!" crap just sucks the life out of any progress that these rendering engines have to do. IE8 punted and included IE7-mode -- that's how bad it's getting.

Possibly, and in fact I agree with many of your points. But since there are millions of pages in HTML4 that aren't going away, browsers are *already* stuck having to do that. That's the point that a lot of XHTML advocates don't seem to get-- XHTML doesn't make HTML go away. Nor does any new standard you create, no matter how awesomely great it is.

In a world where you *must* render HTML4, adding XHTML to the mix actually *increases* the complexity of browsers, not reduces it.

Re:Good

[diamondmagic]

Except it does add new features, XML namespaces to start. Embedded RDF, SVG, MathML, and endless other possibilities. You can embed XUL in XHTML in Mozilla, for instance, or vice versa. Plain old HTML has none of these. Plus, stricter rendering that doesn't confuse CSS parsers makes debugging stylesheets much easier.

Re:Good

[Blakey Rat]

No, no, no, those are only features to web developers. What about *users*? Those pink squishy things that actually use the browser? Debugging stylesheets? Christ.

And seriously, how many people use any of those things you listed? I'm pretty sure I've never in my life come across a RDF or MathML or XUL file, and the only thing I know about SVG is that it's a graphics format nobody supports. Isn't Xul the bad-guy from the first Ghostbusters movie?

Re:Good

[colinrichardday]

Without MathML, the only way to have formulas is to treat them as images. As for SVG, firefox supports a good deal of it.

Re:Good

[Anonymous Coward]

Totally wrong. One of the most important rules in software is: "be liberal in what you accept, and strict in what you output."

Totally retarded. We need rules to limit what is accepted because computers are not yet able to read minds. How should a computer interpret the following date?

01-01-01

January 1, 2001? 2001 January 1? 1 January 2001? etc.

Re:Good

[kelnos]

One of the most important rules in software is: "be liberal in what you accept, and strict in what you output."

This "rule" is what has gotten us into the browser incompatibility mess in the first place.

There's certainly some value in an interpreter fixing up minor errors, but the problem is when those fixups make it such that *correct* code can't always be interpreted as it was meant to, or can be interpreted in different, incompatible, non-conforming ways.

You long for a world where, if I put my STRONG tag and my EM tag in the wrong order, a completely trivial error, the browser should show absolutely nothing. Even though it's obvious to everybody what I *meant*, since a computer thinks like a computer and rejects it like a retard.

You've picked a ridiculously simple example that fails to prove your point. The problem is: where do you draw the line? I'm sure many experienced web developers here could come up with some great examples of HTML out in the wild that's incorrect, but the browsers accept it, all in slightly different ways that make the rendered page look different.

This "be liberal in what you receive" tenet is also why we have things like special cases for certain IMAP servers in client code.

Re:Good

[Draek]

In the ideal world, software would *do what I mean*, not *do what I say*.

No it shouldn't, and the reason is quite simple. And no, it's not 'elitism' or any of those red herrings you're throwing.

Lack of formalized languages has done enough harm elsewhere, you can take a relatively complex phrase in English and two people will come up with two different meanings for it. Perhaps they'll only differ sightly, perhaps not, but chances are they won't be perfectly interchangeable. Extrapolate that to software, and you have pretty much the same situation as today only worse: IE interprets your mistakes one way, Firefox another, Opera yet another one and suddenly the stuff that was supposed to be "standardized", ain't.

Take your example of the strong and em tags, but lets extend it a bit further and say you've defined (for some unknown reason) to define in CSS that 'strong' displays in Arial and 'em' in Times. You write <strong><em>hi</strong></em>, simple enough right? yeah, except that which font should it use? assume the standard specifies that inner tags overwrite the style of outer ones. IE decides that, since you wrote <strong> first, thats the outer one and so uses Times. But Firefox sees that <strong> was *closed* first and so is the inner one, therefore it should go with Arial.

Both are valid interpretations for such a simple mistake, yet both produce drastically different results. Make a not-so-trivial example, and the number of possible interpretations increases exponentially.

Computers are designed to be deterministic and therefore so must be the languages that it must speak. And having "intelligent" computers that "guess" what you meant instead of following a predetermined, standardized pattern and complaining loudly if they can't (another very important rule of programming, btw) is not only incredibly more difficult to write, but also to *use*. HTML5 is a step in the right direction since it tries to standardize the ways browsers must deal with faulty input, but had the web be stricter from day one this problem wouldn't have arisen in the first place.

Re:Good

[Anonymous Coward]

No, no, no, those are only features to web developers. What about *users*? Those pink squishy things that actually use the browser?

Do these users care about the underlaying techniques a page is built of? No, they just want it to work. The technical details are of interest for the developer only.

And seriously, how many people use any of those things you listed?

Mainly due to IE6's incapabilities, there's not much out there on web pages. But it would be nice if we had only nice browsers supporting all these great features, wouldn't it?

I'm pretty sure I've never in my life come across a RDF or MathML or XUL file

And I take it you are rather clueless? Unless, of course, you've never in your life come across Firefox or some other XUL-using applications.

Your cluelessness is a weak argument for or against standards.

Re:Good

[Blakey Rat]

Take your example of the strong and em tags, but lets extend it a bit further and say you've defined (for some unknown reason) to define in CSS that 'strong' displays in Arial and 'em' in Times. You write hi , simple enough right? yeah, except that which font should it use? assume the standard specifies that inner tags overwrite the style of outer ones. IE decides that, since you wrote first, thats the outer one and so uses Times. But Firefox sees that was *closed* first and so is the inner one, therefore it should go with Arial.

For the record, the answer is: "I write that code, then I test it and see which font shows up. If it's not the font I want, I re-write the code so the font I want shows up."

I'm actually after reading this thread and some linked articles changing my mind about the problem. But, on the other hand, I also live in the real world where browsers don't have the option of dropping HTML4 support. (Or indeed support of bad HTML of any kind.)

So we end up with this situation:
1) Browsers support bad HTML for legacy/compatibility reasons
2) Bad web developer sees that his bad HTML still works
3) Bad web developer continues to write bad HTML, since that's all he knows
4) Browsers continue to render the new bad HTML, due to point 1

Standards can't re-write the past. I don't know what the solution is, but I know that XHTML certainly wasn't it, and I'm happy to see it dropped for something more promising.

Re:Good

[msclrhd]

It means that if you are wanting to process html (e.g. convert it to text, or transform it's markup to something else), xhtml is far easier as you can take any of the gazillion xml parsers that are available and use either SAX, DOM or XSLT to do what you want.

With non-xml html content, you need to have your own html parser to read the html content and understand it. This means either running it through htmltidy, embedding htmltidy into your application or using another (possibly hand-written) html parser.

If you are dynamically generating html content, doing so programatically via string manipulation is more error prone than either generating the html from DOM manipulation, or (better yet) generating xml via DOM -- expressing the data that you are using -- and then using an XSLT file to transform it to html.

Re:Good

[msclrhd]

Quite a lot of browsers support SVG: http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(SVG) -- at least in later versions. The only ones that don't are Internet Explorer and iCab.

And then there is support for it in graphical applications such as Inkspace, OpenOffice, Adobe products, CorelDraw and others (http://en.wikipedia.org/wiki/List_of_vector_graphics_editors).

Re:Good

[Anonymous Coward]

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.

I'm a big fan of XHTML, but this is simply FUD. While it is true under HTML 4 (and XHTML transitional), a lot of the HTML 5 specification deals with standards on how to account for errors in the code. Errors should be corrected in exactly the same way in all HTML 5 browsers. So even though it may be the most horrendous code ever, it'll still display the same in all browsers. Admittedly there'll be differences in the implementations to consider, but I honestly believe that even Microsoft's offerings are going to follow these quite closely.

Besides, whenever you write XHTML it just gets parsed as HTML in a lot of browsers anyway (and the error correcting code accounts for the XML style closing tags). It only really gets parsed as XHTML when you provide it the proper mimetype - application/xml+xhtml instead of text/html - which just displays a white page in older versions of internet explorer.

Despite all this, I love XHTML because it's taught web developers to actually start giving a toss about their markup, which makes my life so much easier when I have to update it later.

Incidentally, I don't know what sort of place you work for, but "it's your browser's fault" really doesn't cut it with most people; they rightly assume its the website that's broken. As far as I'm concerned, if a website can't display in every major web browser it and still be standards compliant (really not that hard despite IE6's best efforts) it *is* broken.

Re:Good

[wootest]

Right now, no browser will ever come close, and the specs are already 10x more complex than will ever get implemented, but adding "guess what the user meant!" crap just sucks the life out of any progress that these rendering engines have to do. IE8 punted and included IE7-mode -- that's how bad it's getting.

No, IE had stayed such a train wreck for so long that when they tried improving it they had compatibility pushback. Improving is not the problem; improving and maintaining compatibility with a neglected and inefficient engine (completely, by the way, of their own making) is.

Postel's law's not debunked by "Martian Headsets". I like Joel Spolsky, really, but "Martian Headsets" is maybe the worst thing he's ever written. Microsoft put themselves in this mess with Internet Explorer, and the road ahead is *not* to say that we should just hold everything, or to preclude progress because it's so damn hard. Think about what happens on a sub-atomic layer just inside your CPU every damn second; that's damn hard to set up, and we still made it work from the ground up. The correct course of action is to *do something about it*, and that will be painful for everyone, but the reason it's so much more painful for Microsoft than for any other browser vendor is, simply, "Microsoft".

The reason HTML5 defines tokenization and parsing is because it's meant to level the playing field. You're not angry because the rendering will, in the face of real world applications, turn complex, you're angry because it's already complex in the spec. You should be happy, because the reason it's already complex in the spec is because it already works in the real world! You certainly could, but there's not much left to actually amend the rules with, which makes HTML5 a damn good standard -- wasn't one of Joel's points that the reason HTML is so frustrating is because so much is left to the imagination or that it's all but impossible to build interoperable, perfectly implemented rendering?

Furthermore, I'd like to see one editor that neglects to open any text file with broken UTF-8. (I'm sure they exist somewhere, but I haven't ever seen that happen, and I've worked with some real messes.) UTF-8 is a lot easier and the spec is a lot more rigid, but even so you can't just fail in a real application. If you still believe in Postel's law as applied to XHTML, I encourage you to read http://diveintomark.org/archives/2004/01/14/thought_experiment . "Well, the world is just going to have to get more perfect" has repeatedly turned out to not be a workable strategy. (As long as "the world" actually means "the world". Requiring strictness in a closed, scoped system where helpful recovery actually *would* mean disaster is certainly okay.)

Re:Good

[CarpetShark]

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

Or worse, the sane, professional, qualified developer who refuses to do what the so-called developed attempted to do.

Re:Good

[Hurricane78]

No. I'm saying that we should not teach humans to be ambiguous about what they want. But HTML4 rendering engines allow just that.

There is an important difference between efficiency (when the computers helps you save work), and simplification (when you do less work, but also get less).

There is a point to adding that brace here and that thing there. It means something different than leaving it away. And if you know that, you can use it, which will give you more.
But if the interpreter goes, and interprets them the same, you lose that functionality, and gain nothing. Because you let those stupid lazy slobs overpower your reality.

Simplification is not the solution. The concept of simplification itself a bad simplification of efficiency. More efficient is what we all really want, when we call for simpler usage, etc.. More easy isn't the whole thing.
Windows is the best example. The more professional you want to work with it, the harder it gets. You literally often have to think dumber when you use it, to get the problem solved.
(The oder extreme are things like VI, that are just as bad from the efficiency standpoint, when you do not want to work as professionally.)

Re:Good

[amRadioHed]

For the record, the answer is: "I write that code, then I test it and see which font shows up. If it's not the font I want, I re-write the code so the font I want shows up."

But the point is that if you aren't following the standard then the font that shows up when you test it may not be the font a user with a different browser sees. Because your input is ambiguous the best the browser can do is guess what you want to see and hope for the best.

Re:Good

[Blakey Rat]

Since there's no reference implementation, that's *always* true, though. Maybe not for that little particular scenario, but since the standards aren't (and probably will never be) 100% complete, there will always be things like that that browsers do differently.

Re:Good

[pbhj]

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.

Do you think we could organise a crack team of standards enforcers to run pages through the W3C validators and swoop in and give atomic wedgies to any "designer" whose markup doesn't validate.

Pretty please?

Re:Good

[Anonymous Coward]

Right click, view page source. Really complex that Chrome, eh?

Re:Good

[Anonymous Coward]

Most people here would completely disagree with you.
If it supports the typos then it is a complete dumbing down and that is bad, worse than bad, it encourages poor code.
In your Java example, the compiler won't compile unless it is valid syntactically correct code. Should javac accept all kinds of dumb typos ? No way, that would be plain awful.
Correctness is a virtue that the HTML system should embrace.

XHTML merged

[werfu]

They should have never created XHTML. They should have XMLized HTML in the first place. But, XHTML has corrected many wrong thing that HTML developpers used to do. Now, HTML5 should simply pick up the best of both world while still being XML compliant.

Re:XHTML merged

[RaceProUK]

They should have XMLized HTML in the first place.

They did. It's called XHTML.

Unless you mean XML-ise HTML 3.2 or earlier, but I believe XML didn't exist back then.

Re:XHTML merged

[ThePromenader]

Ditto. XHTML is just another "combined technology" term like DHTML (although standardised) imho; it was an incomplete compromise between two still-developing technologies.

XHTML's demise was a natural one. HTML is the foremost "static" web language, and has been for decades already; it is only normal that the "best" of other lesser-used languages be integrated into it to make a more performant protocol whole.

Re:XHTML merged

[sakdoctor]

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.

Re:XHTML merged

[IntlHarvester]

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.

Re:XHTML merged

[Anonymous Coward]

You mean like how Netscape "handled" bad HTML back in those days (showing a blank page). And boy, did they fix that fast. XHTML has been a bad idea from the start IMO, and good riddance. Most people who use it have no clue, they just use it because. (Or because some incompetent developer put it in their CMS). It's like going back to compilers of the 70's: the one that chocked on the first bad line.

Re:XHTML merged

[maxume]

This is one of the biggest reasons xhtml was never widely adopted.

Microsoft screwing up the mime types is also a big one.

Re:XHTML merged

[Anonymous Coward]

Good compilers still choke on syntax error, you idiot. Hell, scripting language will crash immediately if you made a syntax error too.

XHTML isn't worse than programming language compilers and interpreters. It won't detect wrong semantics if you didn't use what you needed but it chokes on syntax error, malformed tag, which is a GOOD thing.

Re:XHTML merged

[xorsyst]

We made great use of it once in an internal web-based system. There was a command-line client that basically just did a GET/POST and then parsed the xhtml with an xml parser to display the output, which made implementing that a doddle. Coding the website to be xhtml compliant added very little overhead, much less than defining a whole separate soap service or similar.

Re:XHTML merged

[DoktorSeven]

Exactly. XHTML is not that hard to get right, and it makes a web page "clean" in that there doesn't have to be any guessing going on in the browser to figure out what a page designer wants.

The best thing in the world would have been browsers adapting a rigid HTML standard to begin with and browsers simply saying "Sorry, this page has invalid HTML" on bad pages.

I can dream, can't I?

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

[Anonymous Coward]

In this case Microsoft doesn't screw up the mime-type, it just doesn't support XHTML (that is the one that is sent with a XML mime-type and that is parsed as XML; the stuff that has a HTML mime-type but a XHTML Doctype is not really XHTML).

Some w3 "Note" allowed to send XHTML with a HTML mime-type (which browsers then handle like HTML) with the result that you get the bad of both HTML and XHTML and some additional bad incompatibilities.
http://www.w3.org/TR/xhtml-media-types/#compatGuidelines

IMHO XHTML failed because IE doesn't support it.
Small incompatibilities (after the parsing) with HTML doesn't help it either. But I don't think the failure behavior of XHTML is a problem hindering it's adoption.

(XHTML means XHTML 1.0 in this post.)

Re:XHTML merged

[sakdoctor]

Yes, we can dream.
How lazy do you have to be not to close your tags, and nest them properly? It's a low barrier, but given people's infinite laziness, they will write their code until it is just not-too-crappy to render in IE. Then call it a day.

A strict standard would also give MS less wiggle room to subvert the standard in their IE implementation of it.

Re:XHTML merged

[Tanktalus]

Getting a web page clean is a hard problem ... when you accept user input in something approaching HTML format, like /. does. Or we can all be forever subjected to incomplete wiki-style markup that can only do about half of what the user wants. I find myself constantly going back to html in mediawiki to get the formating I want - whether mediawiki supports it or not, I don't know, because at some point the wiki markup gets to be just as convoluted and hard-to-read as html, so I use HTML. Other times, I know mediawiki can't do it, so we need to enter in HTML. And mediawiki is probably one of the better user-content web services out there (from a completeness perspective).

I can just see it now: php or mod_perl or CGI apps linking against WebKit or KHTML or xulrunner or whatever just to properly parse out the user input and clean it up, just so that another browser doesn't choke.

I think we're stuck with broken markup for a long while.

Now, if there were a way to "mark" a section of HTML as being "user-content" such that the parsing could be relaxed for small sections, we might get somewhere further. Then again, many lazy developers will mark their entire documents as user-content, and not fix their code.

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:XHTML merged

[maxume]

A key feature of html5 is that is specifies the algorithms to use when normalizing poorly formed markup. It doesn't eliminate ambiguous cases, but it gets rid of many of them, meaning that the presentation and DOM should almost always be the same, regardless of the browser.

Re:XHTML merged

[thetoadwarrior]

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

Re:XHTML merged

[Qzukk]

Good compilers still choke on syntax error, you idiot.

And if you downloaded a program and it choked when you tried to use it, you'd download a different one, now wouldn't you?

Your plan only works if all of the browser vendors promise to obey it all at the same time. The first vendor to break the promise wins.

Re:XHTML merged

[pizzach]

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

No it is not. Have php run the user input through tidy. Even if it doesn't display as the user wanted in their browser, at least it displays consistently between browsers which is more important imho. Just go. Install it now in php. Seriously, if you are not checking html code coming in from users, something is not right. They could destroy your page with some of those unclosed tags.

Re:XHTML merged

[Anonymous Coward]

And the vendor that breaks most promises, will have most security holes -> IE.

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.

Re:XHTML merged

[IntlHarvester]

Yes, that sounds like a perfect application for XHTML.

I wish more people were arguing along your lines instead of simply claiming that it's Better(TM) [actually it slows down page loads considerably while offering no new features], or wishfully thinking it would eliminate their competition for jobs.

Re:XHTML merged

[IntlHarvester]

> The ability to parse a web document using native XML methods is pointless?

In the general sense, yes. Web documents are nearly always served to web browsers, and every single web browser does a faster & better job of parsing HTML over XHTML.

As I mentioned, there certainly are cases when XML can be useful, but the usual situation of serving content to end users isn't one of them.

Re:XHTML merged

[jonbryce]

But when people put <a hrefhttp://www.goatse.cx> in the comments, you can end up with the rest of the page being a hyperlink to some horrible picture. That's not a good thing, and you need to do some checking to stop that from happening.

Re:XHTML merged

[FishWithAHammer]

Seconded. Drupal doesn't parse it directly, but it does use regex replacement to strip out tags an administrator declares unacceptable (usually everything except tables, lists, the basic formatting tags, and links). The only user who defaults to having full HTML (unstripped) is the root user, and you still have to enable another module to allow direct insertion of PHP.

Re:XHTML merged

[Anonymous Coward]

They did. It's called XHTML.

More specifically, it's called XHTML 1.0 (which really literally is precisely that - a reformulation of HTML 4.01 in XML).

XHTML 1.1 then made a bunch of changes, "modularizing" the whole thing and thus always goes beyond merely "XMLizing" HTML.

XHTML 2.0 was supposed to bring even more changes. The problem with XHTML 2.0 is (well, was) that relevant changes were missing (consider the audio and video tags, for example), while the changes that WOULD have been present would've been idiotic and anathema to what HTML is actually supposed to accomplish (for example, removal of the style attribute, removal of the img tag in favor of the general object tag, and so on).

Put more succinctly, the XHTML 2.0 designers lost touch with reality - or perhaps they never had it in the first place. Either way, XHTML 2.0, and, to a lesser extent, XHTML 1.1, were not just stupid but also unnecessary. On the other hand, XHTML 1.0 was a step in the right direction, and I hope HTML5 will continue building on that.

Re:XHTML merged

[moderatorrater]

They should have XMLized HTML in the first place.

They did. It's called XHTML.

And now it's failed. What does that tell us?

Re:XHTML merged

[trifish]

trying to bring their behavior in line with a single unified goal instead of adding their own proprietary features to HTML itself.

I guess that's why Mozilla implemented support for the Ogg Theora codec with the tag? Because that's not in any standard. Firefox 3.5 added a proprietary extension that is not based on any existing standard.

Drafts can change any time. HTML5 is nothing but a draft now.

Re:XHTML merged

[trifish]

Hmm, I posted the message as Plain Text. Yet Slashdot stripped the <video> tag from the sentence.

Re:XHTML merged

[Phroggy]

Slashdot's idea of "plain text" differs from that of any rational human. The option you're looking for is labeled "extrans".

Re:XHTML merged

[Ant P.]

That most web page authors are too incompetent to even follow XML's validity rules, let alone HTML's?

Re:XHTML merged

[Tacvek]

XHTML 2 is being canceled not because it failed, but because the only advantage over XHTML 1 was being more modular, which nobody really cared about. Besides, HTML5 will define XHTML5, which will be a significant improvement on XHTML 1.

Re:XHTML merged

[Tacvek]

Mozilla's video tag support is in no way a propriety extension. It is fully con formant to the current HTML5 draft, excepting perhaps some minor bugs, and perhaps a few attributes not yet supported. Under the current draft, browsers choose what set of codecs/container-formats they support. There are no mandatory codecs or container formats. So for the time being Mozilla's supported video containers are {ogg}, and supported video codecs are {thedora}.

They will almost certainly add additional container formats and codecs in the future.

Mozilla will continue to follow HTML5, making changes as nessisary when the draft changes.

Re:XHTML merged

[styrotech]

XHTML 2 is being canceled not because it failed, but because the only advantage over XHTML 1 was being more modular, which nobody really cared about.

You don't mean XHTML 1.1 do you? That was just a modular version of XHTML 1.0 and as you say didn't offer much to make it worthwhile.

XHTML 2 was quite a radical change and in an ideal world would've been much better I reckon. The trouble was that the real world of legacy browsers and content was never going to manage the transition as it was too different (plus a big chicken and egg problem). So we've ended up with HTML 5, which although not as good as XHTML 2 (IMO) at least degrades gracefully in older browsers and manages the transition much more smoothly. Thus it actually has a good chance of being eventually adopted.

Re:XHTML merged

[Stan Vassilev]

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

You know, I'm not a fan of bad-formed code, and I'm not religious. But when I read statements like yours, I make the sign of the cross and start praying we don't come to this ;)

If you have any confusion about it at this point, the value of the web was never in the markup. It's in the content the markup describes. Strict in what you send, liberal in what you accept, I suppose you've heard that one :)

Re:XHTML merged

[Haeleth]

Lazy? Writing messy HTML takes more effort than writing clean XHTML. If you use a decent editor -- one that can take advantage of the structure and parseability of XML to provide validation, auto-completion, etc. on the fly -- then XHTML practically writes itself.

Re:XHTML merged

[Draek]

Seriously, if you are not checking html code coming in from users, something is not right. They could destroy your page with some of those unclosed tags.

Obligatory XKCD.

Re:XHTML merged

[VGPowerlord]

Under the current draft, browsers choose what set of codecs/container-formats they support.

Yes, and unfortunately, as far as I can tell, this is how support for the two leading hi-def formats is right now:

Chrome 2: Supports both Theora and H.264
Safari 4: Supports H.264
Firefox 3.5: Supports Theora
IE 8: Supports neither.

Congratulations, between the 4 largest browsers we've managed to have all four possibilities you can have with two booleans (2^2)!

Re:XHTML merged

[joost]

You, sir/madam, are clearly not a professional web developer. Writing clean valid xhtml Strict is what I do every single day and not it is not "hard". OMG! I need to like close my LI wtfsrsly?! So HARD! Grow up please or get a different job/hobby.

Re:XHTML merged

[Blakey Rat]

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

Re:XHTML merged

[Anonymous Coward]

Bullshit. The internet is already full of so much useless trash that it's nearly impossible to find anything useful anymore. I don't give a shit if some idiot that uses word to autoformat everything in their life can't build a functional webpage using XHTML since they can't fucking close a tag.

Get the fuck off my internet.

Re:XHTML merged

[IntlHarvester]

I didn't even use the word "hard" in my post, and you entirely missed the point. So it doesn't surprise me that you are a proud professional HTML monkey.

Re:XHTML merged

[Anonymous Coward]

I take it you never heard of the acronym, PEBKAC. I agree that anyone should be able to create web pages, but you shouldn't actually code anything yourself if you don't know what the hell you're doing. You should use a web page creator ( that hopefully produces nice code) or you should learn a language before using it.

Re:XHTML merged

[grcumb]

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

You're conflating 'putting content on the web' with 'writing HTML'. They don't mean the same thing.

There is something to be said for your perspective, though: The majority of the 'tag soup' that's crufted up the Web these days is software-generated, not hand-crafted by so-called stupid users.

XHTML would have forced makers of stupid (i.e. non-XML-compliant) software applications to fix their engines. That would have required lots of effort, but the value of such an effort is philosophically similar to enforcing health and safety standards on manufacturing processes. Yes, it's cheaper to create quick and dirty implementations, but the public good is better served by enforcing minimal levels of quality. It increases the cost of production, but increases the value of the product, too.

HTML5 tries for a middle road wherein the parser tries to be more forgiving while at the same codifying the ways in which it should fail. It tries to make the failure modes as graceful and predictable as possible. It's sold as a more pragmatic approach to Tag Soup, a problem that's bedeviled us since FrontPage first reared its zombie head.

For my part, I think it's the wrong approach. I don't think it's as wrong as some of the sins committed by Netscape (<blink>, frames, etc.) and Microsoft (iframe, marquee) in the early days, when they treated the W3C as their bitch, foisting all kinds of stupidity into their browsers, never making more than a token effort at interoperability and openness. HTML5 is an attempt to move incrementally away from the sins of the fathers.

From that perspective, I'm willing to live with the decision to adopt it, but only because the W3C, as an industry consortium, just doesn't have the leverage to force its members into full conformance with properly machine-readable code.

People have always miscalculated the cost of creating HTML. The goal of allowing everyone and their dog to post content - any content - online was considered more important than making sure the content itself would be parseable, extensible (the 'X' in XML) and translatable into other, unforeseeable permutations.

I fundamentally disagree with this contention. I need only point to the mountain of good content lost in a morass of excreta passing for markup for evidence. When we treat user-generated content as a disposable, one-off product that will never again be parsed, processed or transformed, we devalue it. Essentially, we're stating that user-generated content has no enduring merit.

Now, some slashdot wit is almost certainly going to acerbically observe that the vast majority of user-generated content wasn't worthy of being published even once, let alone stored for posterity. That's as may be, but it's not our job to judge the content. It's our job to ensure that it remains useful. And we've failed at that job, in large part because we got lazy about markup, foisting most of the work on people who shouldn't be expected to know better, telling them to rely on software that should.

Re:XHTML merged

[Blakey Rat]

You're conflating 'putting content on the web' with 'writing HTML'. They don't mean the same thing.

Except that's not what the parent I was replying to said. He said this:

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

Notice how it's not qualified in any way. "Thetoadwarrior" literally thinks that you should be forced to entirely understand XHTML before you should be "allowed" (by whom?) to create a webpage. He's being a total asshat, so please don't attempt to defend him.

XHTML would have forced makers of stupid (i.e. non-XML-compliant) software applications to fix their engines. That would have required lots of effort, but the value of such an effort is philosophically similar to enforcing health and safety standards on manufacturing processes. Yes, it's cheaper to create quick and dirty implementations, but the public good is better served by enforcing minimal levels of quality. It increases the cost of production, but increases the value of the product, too.

Except that's wrong, because XHTML existing doesn't make HTML4 go away. Browsers will have to render HTML4 until the end of time, if only for backwards compatibility purposes-- given that, bad web developers used to HTML4's quirks and idiocies will simply continue to code in HTML4 and ignore XHTML altogether.

And... gasp... after years of XHTML, that's exactly what's happened. The existence of HTML4 hasn't helped this site improve any, and it's one of the most popular e-commerce sites on the web.

What I don't get is why so many people who were behind XHTML believed that it would make HTML4 go away. Either they didn't bother thinking about the situation for more than 10 seconds, or they are entirely clueless about human psychology.

HTML5 tries for a middle road wherein the parser tries to be more forgiving while at the same codifying the ways in which it should fail. It tries to make the failure modes as graceful and predictable as possible. It's sold as a more pragmatic approach to Tag Soup, a problem that's bedeviled us since FrontPage first reared its zombie head.

And exactly what W3C should have done instead of wasting everybody's time on XHTML in the first fucking place.

For my part, I think it's the wrong approach. I don't think it's as wrong as some of the sins committed by Netscape (, frames, etc.) and Microsoft (iframe, marquee) in the early days, when they treated the W3C as their bitch, foisting all kinds of stupidity into their browsers, never making more than a token effort at interoperability and openness.

IFRAMEs make entire industries that could not have existed before possible. One of the huge errors of XHTML Strict was not including IFRAMEs, which breaks an enormous range of analytics and ad-serving tag packages. IMO, the W3C is entirely run by people who have absolutely *no* idea how to actually write or maintain a website. (At least commercially.)

I mean, it took CSS until version 3 to get columns. Version 3?! COLUMNS?! Christ.

I'd also like to point out that:

1) HTML was designed to be extensible. In a sane world, people wouldn't care if IE added a MARQUEE tag because browsers that didn't support it would simply ignore it. Even ActiveX was an extension allowed by the very design of HTML. (Now, it turns out that in retrospect, that making HTML extensible was a bad idea, but you can't fault browser makers for using the capabilities given to them.) In short, Netscape and Microsoft aren't satan because someone told them HTML was extensible and they extended it.

2) The reason those extensions became critical parts of the web infrastructure is because the W3C moves fucking slow.

I need only point to the mountain of good content lost in a morass of excreta passing for markup for evidence.

Wait, slow down a second-- "lost?" Can you explain how content can be "lost" simply because it contains bad markup? Am I missing something? JC Penney's product pages are fucking horrible, but none of the content in them is "lost."

Re:XHTML merged

[Anonymous Coward]

Creating pages does not require typing bare HTML. These people should be using GUI tools that manage the markup for them. If a person doesn't understand how to write proper markup, there's no excuse for them to continue writing bad markup and making everyone else suffer for it. What they should be doing is typing up their page in Word, clicking buttons to bold or italicize or underline, clicking and dragging to create tables, and saving as HTML.

Re:XHTML merged

[Sigg3.net]

They are. And thanks to a pretty good search engine we all know that encourages semantic structure, you can sit back and relax while the web sorts itself out. Survival of the strictest.

Now if I implemented the XHTML 1.0 Strict version of my site that I wrote two years ago anytime soon, I'd probably get a knock up the PageRank ladder.

Re:XHTML merged

[ryan_fung]

But I believe most people shouldn't need to write raw HTML. Things like blog and CMS are are invented for the masses who don't want to invest the time needed to do HTML properly.

With the growth in popularity of things "Web 2.0" things like YouTube, flickr, wiki, blogs etc, I don't think people really need to write raw HTML to share their content anymore. I think those who still write raw HTML (i.e. those who do it professionally) have no excuse not to do it properly. It's not that hard after all.

Re:XHTML merged

[trifish]

Well, the only thing the software needs to do is replace all < with &lt; and > with &gt;. That will render all scripts and tags inactive and will render them as intended in plaintext. We'll be able to mention HTML tags or post script code just like we can do in other plain text messages, such as emails.

Re:XHTML merged

[trifish]

I expect exactly that kind of moronic answer.

You're completely missing the point. There's no HTML 5 yet. If people start using this HTML5 draft and creating "HTML 5" web pages now, and the standard HTML 5 will be different from this draft, then we will have web polluted with non-standard-compliant web pages exactly as it happened with sites built for IE6 proprietary extensions.

So once again HTML 5 as a standard does not exist. It's a standard being discussed. The draft can change anytime. There's not HTML 5 to implement.

Re:XHTML merged

[tchernobog]

Oh, c'mon! XHTML main rule: you opened a tag, you close that tag. It can be so "elitist"!

I remember back in 1997 wondering why not all tags were being closed.
I started leaving them open just for sloppiness, or because others did that too.

It'd probably be more easier for people to understand in a well-structured way like HTML than leaving them looking why that freakin' div doesn't display correctly and then realising they have closed a "li" element outside a "div" element or other crap like that.

PS. given that, I totally agree with you that people should be encouraged to create web pages, and all that "only people who have a master degree in CS should touch the web" nonsense should go away.

Re:XHTML merged

[RaymondKurzweil]

Could you list here the URLs of some the websites you operate?

Re:XHTML merged

[bar-agent]

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

Have you even seen MySpace?

All that background music...and the blinking...the horrible blinking...

Re:XHTML merged

[thetoadwarrior]

Notice how it's not qualified in any way. "Thetoadwarrior" literally thinks that you should be forced to entirely understand XHTML before you should be "allowed" (by whom?) to create a webpage. He's being a total asshat, so please don't attempt to defend him.

Well creating a web page is different from creating content. If you want to voice your opinion but be bothered properly format the code then use facebook or some other blog software.

Except that's wrong, because XHTML existing doesn't make HTML4 go away. Browsers will have to render HTML4 until the end of time, if only for backwards compatibility purposes-- given that, bad web developers used to HTML4's quirks and idiocies will simply continue to code in HTML4 and ignore XHTML altogether.

And... gasp... after years of XHTML, that's exactly what's happened. The existence of HTML4 hasn't helped this site improve any, and it's one of the most popular e-commerce sites on the web.

What I don't get is why so many people who were behind XHTML believed that it would make HTML4 go away. Either they didn't bother thinking about the situation for more than 10 seconds, or they are entirely clueless about human psychology.

HTML hasn't gone away yet but it will. Who's using HTML 2.0?

If you shop at JC Penny,that's not going to help people's image of you. ;)

Just because some people do things wrong doesn't mean they should be allowed to. HTML/XHTML are still languages. We wouldn't accept any old English gibberish within a professional environment so why should we accept gibberish HTML?

JC Penny has no reason to be writing such bad code. Even if they are using a CMS there is no excuse. They have a broken form tag, two opening and closing body tags and that's just two big ones I've noticed a very quick glance. Those aren't mistakes from automation, they're just bad mistakes that should not be made and developers shouldn't have to waste their time accounting for web developer incompetence. The only correct outcome that people should get from viewing that page is that it breaks and doesn't display. Then the web developers fix it. If they can't fix those problems they don't deserve their jobs.

I'm not surprised they use ASP. They clearly aren't the best coders by a long shot so it's only natural they pick a shit language like ASP.

It's no wonder companies want to outsource work to other countries. If the locals won't code it right then who cares if anyone does a bodge job. So you might as well get it done cheap. People need to show that they're worth that extra bit of cash by doing a proper job.

IFRAMEs make entire industries that could not have existed before possible. One of the huge errors of XHTML Strict was not including IFRAMEs, which breaks an enormous range of analytics and ad-serving tag packages. IMO, the W3C is entirely run by people who have absolutely *no* idea how to actually write or maintain a website. (At least commercially.)

I-Frames work in XHTML transitional. No one said you must use XHTML strict at all times nor did anyone say they would never be replaced.

1) HTML was designed to be extensible. In a sane world, people wouldn't care if IE added a MARQUEE tag because browsers that didn't support it would simply ignore it. Even ActiveX was an extension allowed by the very design of HTML. (Now, it turns out that in retrospect, that making HTML extensible was a bad idea, but you can't fault browser makers for using the capabilities given to them.) In short, Netscape and Microsoft aren't satan because someone told them HTML was extensible and they extended it.

2

Re:XHTML merged

[thetoadwarrior]

PS. given that, I totally agree with you that people should be encouraged to create web pages, and all that "only people who have a master degree in CS should touch the web" nonsense should go away.

You certainly don't need a degree to be a web developer but you shouldn't be lazy and you should do things properly.

It helps readability and it would probably help browser performance if they just displayed a broke page rather than wasting resources fixing people's bad code.

Re:XHTML merged

[Nimey]

The point being, I think, that if you feed a browser bad XHTML it won't render at all, and thus you're not relying on the web developer being clueful enough to validate their HTML.

Re:XHTML merged

[Phroggy]

Yes, that's what the "Extrans" option does. What Slashdot calls "Plain Text" is something else entirely. This is a labeling problem, not a technical problem.

Re:XHTML merged

[Phroggy]

The point being, I think, that if you feed a browser bad XHTML it won't render at all, and thus you're not relying on the web developer being clueful enough to validate their HTML.

That might be true if you set the MIME type to application/xhtml+xml, but since that breaks Internet Explorer, nobody does that. If you set the MIME type to text/html, browsers will just ignore your extra slashes and treat bad XHTML exactly like bad HTML, and neither the web developer nor the user will ever know there's a problem with the code.

Broken XHTML does not make people write valid code. Validation makes people write valid code.

Of course, some people became aware of the W3C's validation service at the same time they became aware of XHTML, so they began writing XHTML and validating it. XHTML is not the key here.

Re:XHTML merged

[Tanktalus]

this one, why?

Re:XHTML merged

[Blakey Rat]

Well creating a web page is different from creating content. If you want to voice your opinion but be bothered properly format the code then use facebook or some other blog software.

Weasel, weasel, weasel. And yet when you create a new Facebook account and start blogging with it, you're creating new pages. Stop trying to weasel out of what you said.

HTML hasn't gone away yet but it will. Who's using HTML 2.0?

How will it? There are thousands of completely unmaintained sites in HTML. Some of them are forgotten, some of them have authors who are dead. And, most importantly, all of them contain critical content that shouldn't disappear simply because of the file format they're in.

The great delusion of XHTML advocates is that HTML would somehow disappear. I don't see how they expected that to happen, it makes absolutely no sense to me.

If you shop at JC Penny,that's not going to help people's image of you. ;)

Wow, you're an elitist asshole no matter what the topic. You also completely missed my point.

Millions of people shop at JC Penney. Millions. If you release a browser that won't render bad HTML, you've just released a browser that's absolutely useless for the millions of people who shop at JC Penney. Your marketshare will plummet.

Just because some people do things wrong doesn't mean they should be allowed to. HTML/XHTML are still languages. We wouldn't accept any old English gibberish within a professional environment so why should we accept gibberish HTML?

People accept English gibberish all the freakin' time. What planet do you live on? Pick any random page on IBM.com, or Oracle.com, or read any Microsoft press release. Here's an example from Oracle.com:

"Multi-Dimensional Business Process Management--Provides unified support for human-centric, system-centric, and document-centric processes, and dynamic process adaptation with integrated process intelligence"

JC Penny has no reason to be writing such bad code. Even if they are using a CMS there is no excuse. They have a broken form tag, two opening and closing body tags and that's just two big ones I've noticed a very quick glance. Those aren't mistakes from automation, they're just bad mistakes that should not be made and developers shouldn't have to waste their time accounting for web developer incompetence. The only correct outcome that people should get from viewing that page is that it breaks and doesn't display. Then the web developers fix it. If they can't fix those problems they don't deserve their jobs.

And yet! Despite all your vitriol, that site exists here in the real, non-theoretical, world and therefore real, non-theoretical, browsers need to accept it. Whether or not they "deserve their jobs" is not your call to make-- it's JC Penney's, and they obviously are happy with whatever service they're getting.

Hell, you have no reason to spell "JC Penney" consistently wrong, and yet you're doing it. Human beings make mistakes, eh?

I-Frames work in XHTML transitional. No one said you must use XHTML strict at all times nor did anyone say they would never be replaced.

The fact that XHTML Strict doesn't allow iframes is just evidence that the people who created it from their ivory tower have *no fucking clue* how actual websites in the actual real world work. Like it or not, iframes are as critical a feature to the web as XMLHttpRequest at this point, and any standard that doesn't include them is worthless.

Marquee is an awful tag as is blink. They shouldn't be used because the only reason for making proprietary tags is to lock someone into using your browser and neither side did just to make the web a better place. They did it for the reason to lock people into their browser. Just as MS making their own Java VM was done purely to ruin Java.

Active X isn't a necessary or required extension, it is again something that was meant to lock people in one browser. In an ideal world people would o

Re:XHTML merged

[pbhj]

It tells us that Microsoft's IE6 team need to suffer unimaginable torment for ruining the internet. Again.

If IE6 was able to cope with application/xhtml+xml and properly render XHTML sent like that then the majority of websites would have upgraded from HTML 4.01 and served proper XML that was easier to parse and render without having to allow for all the relative inconsistencies of HTML. We'd have had faster browsers, possibly better SVG support sooner and marshmallows would grow on trees.

OK maybe not that last one.

We'd probably already have XHTML2, HTML would have died and no-one would have mourned the loss.

Of course we get to try all of this again with XHTML5. I wonder which browser won't render it properly without making web designers jump through hoops ... hmmm?!!

Re:XHTML merged

[pbhj]

Under the current draft, browsers choose what set of codecs/container-formats they support.

Yes, and unfortunately, as far as I can tell, this is how support for the two leading hi-def formats is right now:

Chrome 2: Supports both Theora and H.264
Safari 4: Supports H.264
Firefox 3.5: Supports Theora
IE 8: Supports neither.

Who'd have thought it hey. Never mind IE9 will support some proprietary windows format somehow made so that it appears to be Theora and breaks any possibility of providing Ogg Theora and supporting MS's internet browser ...

Re:XHTML merged

[Tacvek]

No. I include everything beyong XHTML 1.0 as a waste. The modularity of 1.1 was the only substancial difference. That was inherited by XHTML 2, and was the only true improvement. The vast majority of the rest of XHTML2 was swapping out lartge chunks of the language for other XML based languages that in reality where not used as often. I've never seen anything that actually uses XForms.

XFrames is clearly still a direct syntactic derivative of HTML frames, but with a brand new set of tag and attribute names, that people would need to learn. It does offer a few advantages, but those are moot, since frame based site designs have been dead for what, like 5 years?

XML Events might be a superior design, but would require a fairly major overhaul to browser engines, and may require an overhaul of the style sheet languages to better support event based styling. Since CSS2 is not even full implemented in most browsers, and CSS 3 support can be pretty darn patchy. XHTML 2 would not be completed without scrapping CSS for an improved version of XST, merely because that is more XML-y.

Alternate content being specifiable on any tag is hardly an improvement. It confuses the tag meanings for one thing. A paragraph tag should not really be specifying an image, with only fallback content for ua's not supporting the image as the tags inner content. That would be what the img tag is for. (I'll admit that the replacing of img tags alt attribute with inner content was a good idea, but that was already possible with object or embed.)

XHTML2 conformance checking requires validation against all three major schema languages: DTD, XML Schema, and RELAX NG. That is far from an improvement. It also was focused on replacing chunks of HTML with other XML based technologies, but did not even bother to replace html hyperlinks with XLink.

As an author who is considering what language to use, I would see nothing in XHTML2 that would make my life easier compared to XHTML 1. I stand by my assertion that the only real improvement in XHTML 2 is the modularization that it inherited from XHTML 1.1. I see plenty in XHTML5 that would make my life easier.

Re:XHTML merged

[Tacvek]

But there is an HTML 5 now. Significant portions of the document will not be changing in any significant manner. Further, the HTML 5 spec explicitly deals with how to handle backwards compatibility with legacy pages, which includes pages made to the draft HTML 5 spec.

The HTML5 committee intends to gradually lock parts of the spec as they are implemented and start being used, such that the final specification will not significantly differ on any features we start seeing in the wild. This is known as standardizing existing practice.

Re:XHTML merged

[Anonymous Coward]

But there is an HTML 5 now.

No there is not. It's just being created right not.

Significant portions of the document will not be changing in any significant manner.

The portion that Mozilla implemented (the video tag) changed just one week ago.

Re:XHTML merged

[Tacvek]

Did it change in any significant way that would invalidate real world documents? I tend to doubt it.

Re:XHTML merged

[Anonymous Coward]

That's just because you're not l33t!

Well this is a surprise...

[Xeriar]

Much like the sun rising in the east tomorrow. I never quite understood what w3c thought it was doing trying to override browser developers.

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.

Re:Well this is a surprise...

[falconwolf]

Much like the sun rising in the east tomorrow. I never quite understood what w3c thought it was doing trying to override browser developers.

Yea, the W3C should have let the browser makers create their own non-compatible markups so we'd have a worthless web. Or one dominated by a single company, sorry to be repetitive.

Falcon

Bullshit summary

[Anonymous Coward]

> 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."

From the linked FAQ:

Does W3C plan for the XML serialization of HTML to remain compatible with XML?

Yes.

Re:Bullshit summary

[RaceProUK]

It wouldn't be an XML serialisation if it wasn't XML compatible.

Yawn

[bwintx]

Combined with this information and the browser manufacturers having whupped the W3C over the codecs stuff, not to mention my continuing requirement to support a large number of slackjawed technophobes who don't know there's something better than IE 6, I can't help but feel I'm gonna be stuck coding "HTML 4.01 strict" for a long, long time.

Re:Yawn

[TranceThrust]

Best standard to date, no?

Re:Yawn

[Trails]

To paraphrase Jean Chrétien: "It's not a good [standard], it's just the best we 'ave".

"...we'll get the best of both worlds."

[John Hasler]

Best or worst?

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:CSS 3 spec

[ccr]

Well, considering that many widely used browsers don't even implement many of CSS 2.1 features correctly (or at all)[1], that might be just a daydream.

[1] http://www.quirksmode.org/css/contents.html

Re:CSS 3 spec

[Bob The Magic Camel]

Hear Hear. I've been waiting for RGBA and embedded fonts for years. Yes, I know I /can/ use it now, and /most/ browsers will accept CSS3, but that's not good enough for me. I see no purpose in adopting a standard before it has become standardised. So, Sir Tim, if you are reading this: hear my plea and please hurry up with CSS3. HTML5 looks interesting, and looks like it has lots of new toys, but that's no good if I still have to use image-hacks to form semi-transparent backgrounds and make items appear in the fonts I want.

On to the main topic, I see this as a great step backwards. Are people really that afraid of the X in front of XHTML? Or are they worried it's inferior because it has a lower number next to it? From the FAQ it does look like they aren't reverting to SGML which is a good thing, but makes me wonder what the point is. Surely then, this makes HTML5 XHTML2, and not the successor to HTML4.01.

Re:CSS 3 spec

[Anonymous Coward]

I think most people see xhtml as an alternative and not the latest version of html. XHTML2 would sound like just an updated xhtml that html authors dont need to use.

Re:CSS 3 spec

[BZ]

There is no "CSS3 spec". There is a whole bunch of separate specs all advancing along the REC track separately. They're at various stages of readiness.

For example, CSS Namespaces is in CR ("spec work done, implement it please"). It'll become a REC once there is a test suite and two interoperable implementations and the various paperwork involved in becoming a REC is done.

Selectors Level 3, CSS Color Level 3, CSS Multi-column layout are all in Last Call, with the next step being either CR or PR (PR is "this is done implemented and all; just needs sign-off from the W3C staff"). Same for Media Queries, CSS Basic User Interface, CSS Marquee Level 3, CSS Print Profile, etc.

Was there a particular part of "CSS3" you were interested in seeing specced and implemented?

Re:CSS 3 spec

[jilles]

That's the whole problem. All the experts are working for the browser vendors. The W3C never had any business overriding them. Css3 will never happen (standardized & widely implemented). But of course the relevant bits have long been implemented and now those await standardization. It would be nice if w3c bureaucracy could catch up here.

Basically what's wrong here is that after a agile start in the nineties, w3c turned into yet another standards organ. Essentially, for most of the past ten years they've done nothing relevant. Most of the good stuff on the web today basically bypassed their processes (AJAX, HTML5, javascript, DOM). At some point XHTML was hijacked by the Semantic Web crowd. This was essentially given a well deserved neck shot today. They never produced standards or products worth reporting here. Meanwhile, browser vendors had to organize outside the W3C to get some progress going. Current HTML5 is the result of that. Anything else ongoing in W3C is pretty much not relevant (unless you are part of the Semantic Web crowd). Css3 is a good example of why standardize first and implement later is a bad idea.

I'm disappointed.

[Anonymous Coward]

XHTML has some great features, notably the ability to embed MathML and SVG in it (great for academic sites) and strict error handling. Unfortunately these features never caught on because Internet Explorer doesn't understand the XHTML MIME type at all. What a shame.

Re:I'm disappointed.

[Phroggy]

XHTML has some great features, notably the ability to embed MathML and SVG in it (great for academic sites) and strict error handling. Unfortunately these features never caught on because Internet Explorer doesn't understand the XHTML MIME type at all. What a shame.

I'm not familiar with the MathML and SVG features. Hopefully there's another (if less elegant) way to do what you want in HTML5.

As for strict error handling, one of the things HTML5 is doing is defining exactly how errors are supposed to be handled. This doesn't mean "strict" error handling in the sense that any page that contains an error will completely fail to load at all, but it does mean we can expect a consistent behavior across multiple browsers even when the HTML doesn't validate.

The trouble with XHTML is that many web pages today are generated from multiple sources; a single page may not really be a single coherent document, but a conglomeration of little pieces. When coders get sloppy, this results in a document that doesn't validate. If you're using XHTML with strict error handling, this can break the entire page. If you're using HTML with clearly defined but less strict error handling, it may result in some of your content not looking quite right, or the browser may be able to guess how it's supposed to work and it ends up looking just fine. This isn't an ideal world, but we don't live in an ideal world; this is what the Web has evolved into, and we need to accept that.

What really killed XHTML is that it became a buzzword used by people who had absolutely no idea what the hell they were doing. A bunch of idiots jumped on the XHTML bandwagon, added lots of slashes to their broken HTML code, and called it XHTML. Browsers ignored the extra slashes and rendered the broken HTML the same way they always had, and the idiots thought XHTML was the greatest thing since sliced bread. Half the Web looks like that now, and there's nothing the W3C can do to make everybody start writing valid XHTML, so why even bother?

Re:I'm disappointed.

[BZ]

> XHTML has some great features, notably the ability to embed MathML and SVG in it

Here's an HTML5 snippet using the non-XML serialization that shows an "x squared" when parsed with the new HTML5 parser in Firefox:

            x
            2

I'm not sure how much more "embed MathML" you could get here... ;)

If you wanted to put xmlns attributes on the and , with the XHTML and MathML namespaces respectively, you could use this snippet as either the XML or non-XML serialization, of course.

Re:I'm disappointed.

[Anonymous Coward]

slashdot eat your code

Re:I'm disappointed.

[Anonymous Coward]

There is, in fact, something they can do: tell browser makers to consider all content to be application/xml+xhtml for a day, and let the idiots find out just how stupid they really are.

Re:I'm disappointed.

[Phroggy]

There is, in fact, something they can do: tell browser makers to consider all content to be application/xml+xhtml for a day, and let the idiots find out just how stupid they really are.

No, they can't. No browser maker (except maybe Opera) would take them seriously.

Re:I'm disappointed.

[Blakey Rat]

What really killed XHTML is that it became a buzzword used by people who had absolutely no idea what the hell they were doing. A bunch of idiots jumped on the XHTML bandwagon, added lots of slashes to their broken HTML code, and called it XHTML. Browsers ignored the extra slashes and rendered the broken HTML the same way they always had, and the idiots thought XHTML was the greatest thing since sliced bread. Half the Web looks like that now, and there's nothing the W3C can do to make everybody start writing valid XHTML, so why even bother?

Write this down:

Any solution that doesn't take into consideration human psychology is a flawed solution.

Re:I'm disappointed.

[tenco]

Well, I don't quite understand if this is feature complete compared to XHTML (the missing metadata confuses me): http://dev.w3.org/html5/spec/Overview.html#mathml

Smart decision

[Chris_Mir]

Sometimes it is good to have various standards within the same area, because of conflicting interests, etc. But when new or modified standards resolve these conflicts, the best this would be to merge with or adapted the new standard. It would be nice if this could happen with more standards (and licences for that matter), just to keep things a bit clean.

No more compound documents?

[otakuj462]

What I liked about XHTML was the conceptual clarity regarding the creation of compound documents. Like XML, XHTML is modular, precise and fully extensible via XML namespaces. This allowed one to augment XHTML without needing to fully revise the XHTML spec: one simply needed to use an alternate XHTML namespace inside of the XHTML document. So, for example, this made it very easy to use XHTML in conjunction with SVG, another XML application. I know that HTML5 defines ways in which it may be used in conjunction with SVG, but I'm not sure if it's extensible in the same way. What happens if we want to mix in another format, like XForms? Will we have to go back and revise the complete HTML5 spec?

Re:No more compound documents?

[TheRaven64]

XHTML 1 is basically HTML4 with the added requirement that the document must also be well-formed XML. This is useful, because it allows you to put any other arbitrary (but properly-namespaced) XML data in the same file. XHTML 2 was meant to dramatically reduce the number of valid tags, clean up HTML even more than HTML 4 did, and split the spec into a large collection of smaller standards. No one really liked it; it was developed in the traditional W3C 'let's create a new standard without thinking too hard about how it will be implemented' way.

HTML 5 is an evolution of HTML 4 backed by people who actually implement these standards and developed in a more incremental way. Unlike HTML 4, HTML 5 doesn't specify the representation. It has SGML and XML bindings. HTML 5 with the SGML binding looks like classic HTML, HTML 5 with the XML binding looks like XHTML. HTML 5 with the XML binding has all of the advantages of XHTML; you can mix it with any other XML data in the same file, and have a unified DOM tree.

Re:No more compound documents?

[RAMMS EIN]

``HTML 5 with the XML binding has all of the advantages of XHTML; you can mix it with any other XML data in the same file, and have a unified DOM tree.''

Thanks for pointing that out. Suddenly, I don't resent HTML5 anymore.

And yes, I lower my head in shame for not having found that out on my own. I've been too busy with other things to find time to try finding good things about something that has been promoted as everything I never wanted HTML to become.

Re:No more compound documents?

[Xest]

"XHTML 1 is basically HTML4 with the added requirement that the document must also be well-formed XML"

It also deprecated a lot of the older tags that were made obsolete by CSS hence encouraging better separation of document structure and presentation. Unfortunately HTML5 undoes this particular good work because it caters to the lowest common denominator (i.e. bad developers who don't "get" separation of concerns and trivially parsable markup).

"HTML 5 is an evolution of HTML 4 backed by people who actually implement these standards and developed in a more incremental way."

The problem is, those people implementing those standards have proven time and time again how incompetent they are at implementing those standards. The state of standards compliance in browsers has for well over a decade been utterly shameful and that really goes for Firefox as much as it does IE. I'd argue it's those who use the standards that know best - people building the biggest sites on the net because they're the ones who need the markup to be able to support large scale application development. Browser vendors need to be able to implement that standard, don't get me wrong, but putting faith in them as the ones who guide the standards has time and time again proven disastrous - look at the HTML5 video tag debacle for perhaps the most recent example.

I'm not disagreeing with you though, XHTML2 wasn't brilliant, but I'm not convinced HTML5 is even any better than XHTML1 which was also an evolution of HTML4 and IMHO a better one. It was designed with those people building enterprise applications for the web in mind rather than joe average, who is more content using the likes of MySpace and Facebook to manage their content for them in the first place.

Of course, HTML5 can do everything XHTML does for the reasons you state, but sadly it seems to encourage bad practice whereas XHTML discouraged it. One final beef I have with HTML5 is that accessibility seems to have been ignored in it's creation, for example there were no real efforts to ensure easy inclusion of subtitles the previously proposed audio/video formats. Again, we really just don't seem to be any further on with web standards than we were at the start of the decade and again, the people to blame are the browser vendors as much as the W3C and it's allowed not particularly ideal or portable proprietary tools such as Flash to gain a lot of ground as a result.

Re:No more compound documents?

[Anonymous Coward]

>[XHTML] also deprecated a lot of the older tags that were made obsolete by CSS hence encouraging better separation of document structure and presentation.

These tags were deprecated in HTML4 too! Part of the problem with XHTML was that its real features (such as its error handling, or XML namespaces) were confused with the mistaken idea that "it separates content from presentation more than HTML does." XHTML1 was just HTML4 implemented in XML. The only differences between the two are those XML features.

Re:No more compound documents?

[Xest]

That's not true, check the spec such as here for some good examples:

http://www.w3.org/TR/html401/present/graphics.html#h-15.2.1

Stuff like bold, italic and so forth which are clearly presentational rather than structural elements aren't deprecated in HTML4.01 and similarly are not so in HTML5 although the meaning has changed somewhat it's not ideal.

Re:No more compound documents?

[TheRaven64]

It also deprecated a lot of the older tags that were made obsolete by CSS hence encouraging better separation of document structure and presentation. Unfortunately HTML5 undoes this particular good work because it caters to the lowest common denominator (i.e. bad developers who don't "get" separation of concerns and trivially parsable markup).

I think you read a different version of HTML 5 to me. It still deprecates or removes all of the tags that HTML 4 and XHTML 1 removed, for example removing the center and font tags which were only deprecated by HTML 4.

Where it introduces new tags, it is for expressiveness. A lot of the 'separation of content and presentation' folks seem to think that HTML just needs three tags; span, div, and object. HTML 5 doesn't add more presentation elements, but it does add more tags with well-defined semantics. Examples of this include section and nav tags. These don't specify anything about the presentation, they just indicate that a part of the document is a section, or a set of navigation commands. A mobile browser, for example, might have an option to hide and show the nav section to conserve screen space.

Take a look at the current draft of HTML 5. You'd be hard-pressed to find anything presentation-related. Presentation still goes in the stylesheets, HTML 5 just adds tags for common things so you don't need quite so many class attributes.

Re:No more compound documents?

[Bogtha]

Unlike HTML 4, HTML 5 doesn't specify the representation. It has SGML and XML bindings. HTML 5 with the SGML binding looks like classic HTML

No, HTML 5 has an XML serialisation and a tag-soup-compatible serialisation that, yes, looks like classic HTML, but in fact isn't based on SGML. It's based on the way popular browsers parse HTML rather than what they are supposed to do according to previous HTML specifications. One consequence of this is that obscure parts of previous versions of HTML that are not well-supported by popular browsers are not supported by HTML 5 - it's not completely backwards-compatible with previous versions of HTML.

Re:No more compound documents?

[Bogtha]

AC is right. XHTML 1.0 is almost identical to HTML 4.01 semantically. Element types like <b> and <i> aren't deprecated in either. Read the specs.

Re:No more compound documents?

[Xest]

"Presentation still goes in the stylesheets, HTML 5 just adds tags for common things so you don't need quite so many class attributes."

Even if that were true, it still leads to the issue of inconsistency where you have half your markup using these pre-defined tags and the other half using the classic spans and divs because there aren't generically predefined tags. It also means that more likely that not, as the web evolves some of those tags will become obsolete and just unneeded cruft on the spec.

The reason I say it's not true is because it takes some stretch of the imagination to suggest the new descriptions for tags like strong, b, i and so on mean anything other than their classic meanings, which are presentation differences. Even if you disagree and take those ambiguous interpretations are not meaning that (and ignore that argument that most people wont even know the definition of them has changed and will assume they're as they always were) it's hard to argue that stuff like the marquee tag is anything other than a presentation tag, and to be honest, a god awful one too.

Re:No more compound documents?

[IntlHarvester]

> Examples of this include section and nav tags

I find this encouraging because it starts to make HTML actually "semantic" for real world web pages, as opposed to the physics paper approach of pretending everything is a heading, paragraph, or generic block (DIV).

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:No more compound documents?

[FishWithAHammer]

So treat the B tag as the STRONG tag and the I tag as the EM tag (that is, semantically identical) and you have structural elements (because, unless I'm misunderstanding the point here, EM and the like were chosen to replace B, I, etc. because of screen readers and such, not because they weren't semantically important).

Something wrong with doing this?

Re:No more compound documents?

[FishWithAHammer]

Count me in as one of the "give me more expressiveness" crowd. Span, div, and object are good enough for most purposes, but have their own problems. Writing [X]HTML/CSS pages for all media--conventional browser, print, and screen readers--is a bear. Having sane defaults for tags like STRONG and EM--that is, a certain inflection for the screen reader, and a decent-looking print default--saves developers a lot of time.

Re:No more compound documents?

[:jax:]

Yes, that is why strong is wrong .

Re:No more compound documents?

[Anonymous Coward]

They should only remove the "center" tag after there is some sort of reliable analogue to it in CSS. You can't get CSS centering to work properly half the time.

Re:No more compound documents?

[FishWithAHammer]

Interesting view. I disagree with it completely. But interesting.

Re:No more compound documents?

[Blakey Rat]

It also deprecated a lot of the older tags that were made obsolete by CSS hence encouraging better separation of document structure and presentation. Unfortunately HTML5 undoes this particular good work because it caters to the lowest common denominator (i.e. bad developers who don't "get" separation of concerns and trivially parsable markup).

Content and presentation are already separated at a higher level: the Content Management System does it.

I'll be 100% frank with you: I don't really "get" it either. The content is the article. The presentation is the templates managed by the CMS that displays the article. Tags inside the article (like EM or STRONG) are part of the content, not part of the presentation-- those sections would still need to be italicized and bolded even if the content was being viewed in an entirely different manner like, for example, in a newspaper.

Oh, it's been explained to me, dozens of times. But I've just never been convinced of the value.

And you know what? Be prepared to hate me: I *like* the CENTER tag. You wrap *anything* in your document with a CENTER tag, and it's centered. It just fucking works, all the time, no matter the element, with no fuss. I'm sure Microsoft, Mozilla, and Apple have written thousands of lines dedicated purely to getting the CENTER tag working, and I really appreciate that work.

Re:No more compound documents?

[:jax:]

Yes, all of these had typographic conventions long before the formalisation of HTML. But does this mean that they don't have semantic meaning? You should ask yourself why these conventions are there. There is a deep difference between an ordered and an unordered list, whether there are many processes to take advantage of this difference is a different question.

The case for 'i' is interesting. I have always been a strong proponent for the 'i' element, in part because it describes something ("alternate voice or mood" is a fair stab of what that something is), and in part because it would be a disaster for semantic markup if it had been removed. If you want to mark up something that in traditional typography is marked up with italics that has a specific semantic meaning like 'em', use 'em'. Otherwise use 'i'.

If 'i' was removed from the spec, the nearest semantic element would be used instead. Thus you get 'em' used to mark up text that clearly isn't meant to be emphasised. A far greater problem for semantic markup than not using the semantic element when you can (e.g. not using 'em' for emphasised text) is to inappropriately use that element (e.g. using 'em' for something not meant to be emphasised text).

Italic is sometimes used for text decoration, e.g. for some aesthetic reason every other paragraph is italicised. In this case italic has no semantic value, and a style sheet should be used instead (with CSS3 Selectors this could be done without polluting the markup at all).

Finally there is a great value in imprecision, but that is a story for later.

Re:No more compound documents?

[Anonymous Coward]

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 ..." - 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.

Actually I work for an (educational) publisher doing the markup for web-specific material and many many times we NEED the whole possible range of different ways of showing that a section of text (from part of one word to a whole section) is different in some way. Underlining, italics, bold and quotes, and sometimes square brackets. OK so most of the time we do this with inline css, but I can imagine that if italic tags were used PROPERLY they could indeed have semantic usefulness etc etc.

Re:No more compound documents?

[Anonymous Coward]

<br> and <pre> - explicitly control line-breaking (<pre> has ASCII art as a use case!)

Your point being? That is a valid use case. Yes, both could be done with plain tags and equivalent CSS styles--but at about ten times the bandwidth. How does that help?

<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.

Well, yeah. Unordered != ordered. They are not the same semantically.

What was your point?

<small> - nuff said

This one I'll give you. :)

<i> - I'll quote this, because it's utterly laughable: "[...]" - 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.

No, they just want to indicate that the text is not the same as the text which surrounds it.

How would you suggest a writer code the thoughts of a character in their prose? A span with a specific style works from a presentation standpoint, but ignores the fact that the text really is different from what surrounds it. There is a semantic difference as well as the obvious difference in presentation.

I agree that <i> doesn't encode this either, but authors are used to seeing italics used in this way, so they built on that expectation. I don't see that as being particularly laughable--I see that as matching the tool to the expectations of its users.

Sounds like a few people are confused...

[MassacrE]

XHTML 1 was the XML-ization of the existing HTML 4 stuff.

XHTML 2 was a new HTML version that sought to remove lots of HTML cruft (including non-XML syntax) and add new capabilities. Basically, it was working toward a new HTML version. This effort has died, because browser makers are not behind it - they are all behind HTML 5.

HTML 5 has always had an XML profile called XHTML 5, and that won't go away.

Re:Sounds like a few people are confused...

[Midnight Thunder]

HTML 5 has always had an XML profile called XHTML 5, and that won't go away.

So, we should still be ensuring that all tags have matching close tags? What will the document header be?

I have been told that making page uses XML compatible HTML makes for a more predictable browsing experience and also lowers memory requirements. This being the case I will try to maintain the approach, on the condition that I can take advantage of HTML5.

Re:Sounds like a few people are confused...

[SurenPala]

I don't understand why they don't just go ahead and drop the SGML parts of HTML 5, if they are going to break backwards compatibility why not move to a completely XML based syntax.

Re:Sounds like a few people are confused...

[SendBot]

So, we should still be ensuring that all tags have matching close tags?

All tags that need a closing tag should have one, yeah. singular tags like br and img simply close themselves, <br /> , <img src="blah" />

Re:Sounds like a few people are confused...

[Hurricane78]

Well, I think the most important thing will be, how strict the browsers will actually be.
If they are just as strict as with XHTML 1.1, then we will get easily parsable, nicely crawlable (eg. by Google) and always properly rendered pages, no matter if it's XML or not. (Although it is sad, that it is not SGML anymore, as I read.)
If they are as "forgiving" (read: crappy messes of interpreters that foster laziness and stupidity) as HTML 4 Transitional browser engines, then we can say goodbye to Google's search quality, to consistent and performant rendering, and to quality in general.

I with there were a markup language, with all the best of SGML, XML and XHTML 2, updated for today.
HTML 5 is by no definition even close to that. (A separate video and audio tag? For *what*? We already have a perfectly flexible object tag, as you can see in in this early alpha that I made in 2004: http://navid.radiantempire.com/windogs/ [Try the file named "Lycos" in the folder. It does not even use AJAX to use the file system on the server, because THAT WORD DID NOT EXIST BACK THEN! :])

Re:Sounds like a few people are confused...

[BZ]

There are no SGML parts of HTML 5. It's not an SGML application at all.

And it doesn't break backwards compatibility. In fact, not breaking backwards compatibility is one of its key design goals (unlike XHTML2).

Re:Sounds like a few people are confused...

[BZ]

> So, we should still be ensuring that all tags have matching close tags?

Only if you want to use the XML serialization.

> What will the document header be?

Not sure what this is asking.

> I have been told that making page uses XML compatible HTML makes for a more predictable
> browsing experience and also lowers memory requirements.

Tossing in random "/>" has no such effect. Properly nesting your tags (i.e. avoiding ) most certainly helps reduce memory requirements.

With HTML5 the browsing experience will be predictable no matter what, since the parsing algorithm is fully specified. This means that any browser implementing HTML5 will parse documents the same way as any other browser implementing HTML5.

Re:Sounds like a few people are confused...

[itsdapead]

So, we should still be ensuring that all tags have matching close tags?

Well, its not going to hurt, even if it won't magically transform stuff into "proper" XML.

What will the document header be?

Anything that cares is supposed to look at the MIME type that it s served with.

Re:Sounds like a few people are confused...

[Midnight Thunder]

> What will the document header be?

Not sure what this is asking.

The doctype.

Re:Sounds like a few people are confused...

[itsdapead]

I don't understand why they don't just go ahead and drop the SGML parts of HTML 5

If they were going to do that, they might as well have dropped the HTML bits of HTML 5 and, on the blank sheet of paper, wrote "WRITE AN XML SCHEMA THAT MATCHES YOUR DOCUMENT AND THEN FORMAT IT WITH CSS"

(Just a few details missing, like I don't see how to embed Javascript...)

Re:Sounds like a few people are confused...

[Serious Callers Only]

The doctype.

Not sure you'll like the answer : ) :

<!doctype html>

I believe because they wanted to keep it short and simple, and hixie doesn't believe in versioning HTML - having a version-less doctype forces people to keep it backwards-compatible when html6 rolls around. Perhaps someone else who followed the process better can chime in here.

Re:Sounds like a few people are confused...

[BZ]

<DOCTYPE HTML>

And even that was only kept in for backwards-compatibility reasons: it's the shortest "doctype" needed to trigger standards mode in all current (non-HTML5-aware) browsers.

Thing is, the XML serialization doesn't really need a doctype (and never has; XHTML1 without the doctype is not conformant, but works just fine in any reasonable XML processor), and the non-XML one is no longer an SGML application, so a doctype doesn't actually make sense.

Re:Sounds like a few people are confused...

[zigurat667]

Looks like your whishes were heard
Some earlier versions of HTML (in particular from HTML2 to HTML4) were based on SGML and used SGML parsing rules. However, few (if any) web browsers ever implemented true SGML parsing for HTML documents; the only user agents to strictly handle HTML as an SGML application have historically been validators. The resulting confusion â" with validators claiming documents to have one representation while widely deployed Web browsers interoperably implemented a different representation â" has wasted decades of productivity. This version of HTML thus returns to a non-SGML basis.
from the HTML 5 specs

Re:Sounds like a few people are confused...

[Homburg]

I have been told that making page uses XML compatible HTML makes for a more predictable browsing experience and also lowers memory requirements.

You've been told wrong. Making your HTML or XHTML valid does make for a more predictable browsing experience, and may even lower memory requirements. Writing HTML that looks a bit like XML (e.g., using self-closing tags) and then serving it as HTML is completely pointless.

Re:Sounds like a few people are confused...

[Homburg]

we can say goodbye to Google's search quality

Yeah, it's a good thing everyone has been using valid XHTML since 1996; Google would just fall apart if it had to crawl non-valid HTML.

Re:Sounds like a few people are confused...

[:jax:]

Making *valid code* makes for a more predictable browsing experience and also lowers memory requirement, whether you use HTML or XML. At the time I worked for a browser company using XML actually made matters worse, and I would be surprised if that isn't still the case. It should be easy to make a test in every browser, my expected result is that a document serialised with XML (served with application/xhtml+xml) will need more processing power and take notably longer to render than one served as text/html. If you want to slow down your web page, serve it as XHTML.

html and xhtml

[falconwolf]

I know a lot of web developers who dont know the difference between XHTML and HTML

I've used both, and because of the strictness and use of lower case tags of xhtml I prefer it. Maybe there's only a few people it bothers but using all large cap tags bothers me. I also like it that xhtml separates content from structure. I don't know much about html5 but I hope it includes these.

The HMTL5 spec is quite readable,but if you've not taken a stab at working with HTML5 (it runs all browsers) yet this article should be pretty useful: http://www.phpguru.org/static/html5

Thanks for the link. Though it's not finalized maybe I can start learning it.

Falcon

Re:html and xhtml

[pizzach]

HTML5 is very similar to XHTML. I think the only major difference in the code is the self closing tags. Just like xhtml, most attributes that have to do with styling in tags have been deprecated.

Re:html and xhtml

[Wraithlyn]

The thing is, you're not really serving XHTML to the browser, the browser still interprets it as text/html. The DOCTYPE does nothing except trigger standards mode in IE.

Unless you're actually getting your server to send content-type: application/xhtml+xml in the response header (which IE6 can't handle, so nobody does it), the browser just treats it as malformed HTML (technically, >br /> is invalid HTML).

I code in XHTML "style" (lowercase, self-closing tags, etc) as well, but "strictness" doesn't really enter into it, nothing is really enforcing that.

Re:html and xhtml

[Neil Hodges]

If you're going to send the header, you might as well detect what it supports first, and send application/xhtml+xml if it's supported. It's a simple stristr() on HTTP_ACCEPT. I've been doing it an all of my sites since I started with PHP, and do it with Perl and Python as well..

Re:html and xhtml

[Homburg]

I've used both, and because of the strictness and use of lower case tags of xhtml I prefer it. Maybe there's only a few people it bothers but using all large cap tags bothers me. I also like it that xhtml separates content from structure.

Neither of these are unique features of XHTML. HTML is case insensitive, so you can use lower case tags if you wish, and XHTML 1 has exactly the same semantics as HTML 4.01, so XHTML and HTML are equally strict and separate content from structure to exactly the same extent.

Re:html and xhtml

[Adm.Wiggin]

What, you don't like your code to yell at you?

BUT CAPSLOCK IS CRUISE CONTROL FOR COOL! <BR>

Re:html and xhtml

[uzytkownik]

Except that with XHTML you can easily embed other XML data such as (but not limited to): - SVG - MathML

Re:html and xhtml

[NickFitz]

Unfortunately, IE sends an Accept header which doesn't include text/html but does include */*, thereby ruling out content negotiation in the case of text/html versus application/xhtml+xml.

Re:html and xhtml

[mcvos]

Unfortunately, IE sends an Accept header which doesn't include text/html but does include */*

IE claims to accept everything (including aplication/xhtml+xml) but doesn't? I didn't think my regard for IE could drop any lower, but there it is.

Incidentally, IE does render application/xml (or was it text/xml?) better than Firefox, which renders it as xhtml if it encounters an xhtml namespace.

Rendering

[wondersparrow]

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 :(

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:Rendering

[Anonymous Coward]

Simple: view source --> use your "The Matrix" vision to render everthing in your brain.
Every serious developer knows how to run code in his brain, that's how I run all my unit tests!

Re:Rendering

[Megaweapon]

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?

It's Slashdot, incompetence is assumed.

Re:Rendering

[Anonymous Coward]

Perhaps it is the fact that several of the sub-domains on here have a working comment-toolbar and the others don't.
Perhaps it is the times when parts of said toolbar end up appearing inside replies, above and around them.
Or perhaps it is those strange little circle icons that seem to appear and nobody knows what the fuck they are even for in the first place.

Someone touched something somewhere and completely fucked shit up big time for quite a few browsers, and it has been like this for a good while now.

Re:Rendering

[Anonymous Coward]

CSS defines how something is rendered. HTML merely define tage to endow blocks of text with certain properties. For instance, this block of text might be a caption. This block of text might be a title. This block of text might just be text that is free to flow as needed. The rendering is 100% up to the the browser. If the browse want to render a title with zigbats in pink, that is fine. If a browser want to read all the text, and yell when an bold tag is encountered, that is fine. It is CSS that defines how and where a block is to be rendered, not HTML.

Re:Rendering

[pbhj]

Simple: view source --> use your "The Matrix" vision to render everthing in your brain.
Every serious developer knows how to run code in his brain, that's how I run all my unit tests!

He's right I run all my unit testing in his brain too.

Still waiting to get back something without a dirty picture pasted over where the results should be.

Mime Type didn't matter

[coryking]

The MIME type sent in the headers never mattered.
If you fed IE7+ a XHTML doctype, it would pretty much render XHTML. Ditto with every other browser.

As has been said, XHTML is basically well formed HTML (with "depreciated tags" that you'd use anyway). When HTML5 rolls around, I expect many people including myself to just use the new tags and attributes and still produce well formed XML. Same as we've done for XHTML--take HTML4 and make it valid. All the browsers will take it and I bet it won't even violate whatever DTD this new thing uses.

In otherwords, there never was a standard and there never will be. The closest standard you can get is "is this valid XML"... if you can get valid XML, all the browsers will *parse* the thing in the same way. Of course, how they render said parsing isn't quite standard. The "rendering differences" is where the fun starts.

Re:Mime Type didn't matter

[Mystra_x64]

The MIME type sent in the headers never mattered.

If you fed IE7+ a XHTML doctype, it would pretty much render XHTML.

Oh, really? Last time I checked Doctype was not the same thing as MIME type. If IE will see application/xhtml+xml MIME type it shows you download file dialog. It can even show you error claiming "unknown feed type" if you give it application/xml MIME typed main page with client-side XSLT. So what's about that never mattered thingy you were talking about?

Re:Mime Type didn't matter

[Haeleth]

The MIME type sent in the headers never mattered.
If you fed IE7+ a XHTML doctype, it would pretty much render XHTML. Ditto with every other browser.

Simply not true. For example, Firefox only renders the XHTML <ruby> tag if you use the XHTML MIME type that messes up IE.

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:HTML 5 parsing is just awful.

[Tiles]

Now try to imagine Microsoft, Opera, Mozilla, and Google implementing that compatibly.

I believe they already do, for the most part. HTML5 parsing rules were mostly reverse-engineered from existing browsers' HTML parsing rules, which are more or less consistent across modern browsers, so it's only documenting what most existing browsers already do.

What the spec is defining is a limited subset of an SGML-like language (whose entire parsing rules, if incorporated into HTML, would span for pages) and how to transform it into a DOM. It isn't mandating any new parser rules, it only documents them for the benefit of new implementations of the spec, and to align what minor variations there are between browser parsing models together. Compared to SGML rules (of which HTML 4.01 is technically a subset), this is a great improvement.

Re:HTML 5 parsing is just awful.

[Animats]

Formally, HTML 5 is no longer based on SGML; the spec says this. The only SGML directive allowed is <!DOCTYPE ... >. One advantage of this is that bogus (but not uncommon) HTML comments of the form <!This is an invalid comment> can now be parsed unambiguously. There's no need to worry about parsing unexpected SGML directives inside HTML.

Re:HTML 5 parsing is just awful.

[Mystra_x64]

GP says "What the spec is defining is a limited subset of an SGML-like language". S/he never stated that HTML5 is an SGML document.

Re:HTML 5 parsing is just awful.

[Blakey Rat]

Now try to imagine Microsoft, Opera, Mozilla, and Google implementing that compatibly.

Well, considering they're already parsing HTML 1-4, they *already have it implemented*. Their logic might not be exactly the same as the HTML5 logic, but it's not like Firefox/IE/Safari have zero code now to handle that situation. HTML5 just means auditing that behavior to ensure its compatible.

Re:HTML 5 parsing is just awful.

[jonaskoelker]

Now try to imagine Microsoft, Opera, Mozilla, and Google implementing that compatibly.

Which is why there should be a reference implementation that's free for anyone to use and relicense for any purpose.

Then anyone can copy that code into their own; either by machine or by hand.

On a related tangent, have any of you wondered why mathematics uses prose rather than some kind of formalized pseudo-code to express algorithms?

Re:HTML 5 parsing is just awful.

[Animats]

Which is why there should be a reference implementation that's free for anyone to use and relicense for any purpose.

The HTML 5 spec describes state machines for the tokenizer and parser, but it describes them in text. They should have been described in some formalism. There are well-known formalisms for describing syntax to a parser (BNF, state transition diagrams, transition tables, "yacc", etc.) that have been developed in the programming language community over decades. But the HTML crowd doesn't seem to like formalism. This is a lack. It would be helpful if all parsers ran exactly the same state machines.

There is, though, a free parser implementation in Python. It's very straightforward code. Take a look at "tokenizer.py", where you can see the HTML 5 tokenization rules written out in Python in a very clear way. It probably won't run fast, though.

On a related tangent, have any of you wondered why mathematics uses prose rather than some kind of formalized pseudo-code to express algorithms?

There's mathematical work that uses a formalized pseudo-code. Look up Boyer-Moore theory.

Come Together

[revxul]

I am glad for this. That major fork is not what we need right now. One unified, open standard is the way to go for the web.

People can piss and moan all they want about the drawbacks, but this does nothing. If it is a problem, push for HTML to integrate the advantages XHTML had over it.

Not true; XHTML is stricter.

[Narcocide]

Not true; XHTML does not have optional closing tags. HTML does. XHTML 1.0 Strict is actually stricter than HTML. Only an XML parser will complain, true, but that does not mean that browsers won't silently poop themselves and render the page wrong on something they should have reported as a parsing error to start with.

Like your mom?

[Anonymous Coward]

I'm not joking; the power of html is that it's simple, human-readable, and error-tolerant enough for anyone to use. If your mom can't learn xhtml, it's not doing its job.

Say goodbye to .Net 2.0+ apps

[HannethCom]

I am referring to webform apps, not MVC.

Unfortunately because of the broken Javascript code that .Net 2.0 - 3.5 uses for some of it's post backs, we are unable to make our pages xhtml compatible. The postback code works fine in IE, but no other browsers if the form tag appears outside of the body tag. Unfortunately because of the design of .Net we have to have the form tag outside of the body, which causes us to do a really ugly hack to get it working in all browsers. That hack is to put a body tag, the form tag, then in our template we have the actual body tag. Of course this makes our pages not xhtml conformant, but it's the only thing we've found that works around the CLR 2 bugs. This was not a problem in .net 1.1 because the postback code was properly written. Hopefully this is fixed in .Net 4, but I doubt it.

Will they roll XHTML 2 features into X/HTML 5?

[Pfhorrest]

I see a lot of debate here about XML versus SGML (or SGML-like) serialization and parsing rules, and plenty of people (rightly) pointing out that there is an XML version of HTML 5.

But what about those features which those of us who already code strictly to spec either way really care about? New elements that were scheduled to debut in XHTML 2.0 such as nl, h and section, the ability to put href and src attributes in any element, etc?

Those are the sorts of things which made the debate for me, not some silly XML vs SGML, strict vs lenient debate - either way I'll be writing my code for strict compliance with spec. I'm more concerned with what the features of the spec will be! Less so with how it deals with people out of compliance with it.

So any news on whether X/HTML 5 will be incorporating any of these, now that it's a W3C project and XHTML 2 is dead?

Re:Will they roll XHTML 2 features into X/HTML 5?

[Anonymous Coward]

Exactly. All those XHTML 2 features that you mentioned are simply beautiful and made mark-up simpler and more semantic. I've been eagerly awaiting being able to use them for years, and now I fear that HTML is getting more complex without any of the simplification that XHTML 2 offered. I have not seen any discussion as of yet of rolling those features into (X)HTML 5, but I hope more people who care (like you) will fight for it. The only discussion I could find is from a year ago and ended up with the rejection of "href anywhere", my favourite XHTML 2 feature. Perhaps this is the right opportunity to try again.

XML mode and separating author/browser concerns

[spage]

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!

1. There is an XML mode for HTML5, see HTML vs. XHTML. HTML5 even uses the same xmlns="http://www.w3.org/1999/xhtml/" namespace.
2. HTML5 tries to defines exactly how a browser should handle the billions of unclean documents out there. This will help browser interoperability in the real worldwide web of garbled HTML, and has huge benefits for script parsing HTML because the DOM contents after reading in HTML should be somewhat similar in different browsers.
3. Despite this, HTML5 specifies very clearly how authors should write HTML. It separates conformance for authors (write stuff correctly!!) from conformance for browsers (there are billions of crappy HTML documents out there, deal with it). Read Why does HTML5 legitimise tag soup?: "Just because browsers are required to handle erroneous content, it does not make such markup conforming. "

Have some faith, the HTML5 spec and its writers are wayyyyy smarter than /. commenters!

your choice: XHTML, HTML, HTML-looks-like-XML

[spage]

So, we should still be ensuring that all tags have matching close tags?

Well, duh, obviously if your document is XML according to its mime type. If it's HTML then it can have matching close tags; from WHATWG's HTML vs. XHTML, "If you attempt to send XHTML as text/html, you are actually just using HTML, possibly with syntax errors."

What will the document header be?

There's a web site that answers such questions.

I have been told that making page uses XML compatible HTML makes for a more predictable browsing experience and also lowers memory requirements.

The first claim is turning off quirks mode and using strict mode in various browsers, a complicated subject. I believe a document authored conforming to HTML5 is always and only strict mode; HTML5 also tries to make browser handling of "tag soup" more predictable. The second claim... {{citation needed}}?

HTML5: Just Say NO

[jonadab]

> so get on the HTML 5 bandwagon now.

Not gonna happen, fanboy.

HTML 5 takes entirely too many steps in the wrong directions. I'm not interested in going there. I'm *definitely* never going back to non-wellformed SGML-oriented markup, and that's just for starters.

Though, to be honest, I wasn't real excited about XHTML2 either. Not so many steps in *wrong* directions, but plenty of *unnecessary* changes. Meh. I'm not really going to mourn its loss.

What I really want is XHTML 1.0.1, the only difference from 1.0 being that you can put block-level elements within a paragraph. That's the only change I really wanted.

So hey, I can live with 1.0. I'll just keep using <div class="p"> like I have been. It's a kludge, but it works.

Or maybe I'll just study up a bit and end up going to straight XML with a custom namespace. Then I can have my block-level elements inside of paragraphs :-)

Re:Off Topic

[Anonymous Coward]

this is a strange result. Just quite as off topic or are we ?

HTML5 is very similar to XHTML.

[falconwolf]

I think the only major difference in the code is the self closing tags.

I have no problem with self closing tags. I started with html4, then when I started xhtml at first some things seemed strange such as self closing tags but I picked them up quickly. Now it makes sense to close all tags.

Just like xhtml, most attributes that have to do with styling in tags have been deprecated.

Currently I don't know CSS well, then again I haven't created webpages much in a few years, but it seems logical to separate content from style.

Falcon

Neither of these are unique features of XHTML.

[falconwolf]

HTML is case insensitive, so you can use lower case tags if you wish

I know but I've tried to read too many html documents where all the tags are capitalized. As strange as it may seem looking at all the caps give me a headache.

XHTML 1 has exactly the same semantics as HTML 4.01, so XHTML and HTML are equally strict and separate content from structure to exactly the same extent.

I've seen many more html pages with inline styles than I have with xhtml, as a ratio between style sheets and inline styles for xhtml and html.

Falcon

IE8 and text/xml for HTML5?

[Midnight Thunder]

Okay, I am now using text/xml, but IE8 is rendering the raw XML. Is there a trick to get IE8 to behave?

Re:IE8 and text/xml for HTML5?

[Midnight Thunder]

Got my answer: You still need to include the XHTML strict doctype.

True; Strict is stricter than Transitional

[:jax:]

You are confusing serialisation with strictness or restrictiveness. The vocabulary of the three versions of HTML4 and of XHTML1 are virtually identical (there are actually a few minor differences between HTML4 and XHTML1 for technical reasons). HTML4 Strict/XHTML1 Strict are stricter than HTML4 Transitional/XHTML1 Transitional. A valid document in HTML4 Strict (or XHTML1 Strict) will be valid in HTML4 Transitional (or XHTML1 Strict), but the reverse need not be the case. The serialisations follow different rules, which has consequence in how the elements are represented. This is the same with HTML5, which also has two serialisations, one using a clearly defined HTML syntax (instead of a conceptual SGML syntax), and the other using an XML syntax (called XHTML5).

Re:True; Strict is stricter than Transitional

[Narcocide]

Oh. I actually didn't realize there was a strict version of HTML4. If there will actually be an XHTML5 that makes me a lot more comfortable with the concept. In my head the "X" is the part that adds the sanity.

Re:True; Strict is stricter than Transitional

[mcvos]

In my head the "X" is the part that adds the sanity.

It helps a bit, but as this discussion proves, the "X" by no means guarantees sanity.