XHTML 2 Cancelled 222
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."
Well this is a surprise... (Score:2, Insightful)
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... (Score:3, Insightful)
Yawn (Score:2, Insightful)
Re:XHTML merged (Score:3, Insightful)
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.
CSS 3 spec (Score:5, Insightful)
More importantly, when are they going to finish the CSS3 spec?
I love that HTML5 is getting pushed to the forefront and browsers are advancing more than ever, but as a web designer that CSS3 spec needs to get done and pushed on the browser developers because it will be another 2 - 5 years before mass adoption and I'm pretty tired of CSS2.1's limitations.
Re:XHTML merged (Score:3, Insightful)
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 (Score:5, Insightful)
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 [w3.org] 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 (Score:2, Insightful)
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 (Score:5, Insightful)
XHTML would have been great standard.
When fed invalid XHTML, the browser chokes, which would have gone a long way to eliminating much of the crap code, and crap "web developers" out there.
I don't see why it's the browsers business to be THAT lenient, and second guess the developer all the time.
The problem is, a lot of web pages today are not a single coherent document, they're a bunch of little code fragments concatenated together (template, content, advertising, etc.). When coders get sloppy, this can result in invalid markup. When browsers choke, the content producer may have no idea how to fix the problem - it may not even be their problem.
What HTML5 tries to do is clearly define exactly how broken markup is supposed to be handled, so all browsers can try to "second guess the developer" in exactly the same way.
Kudos to Firefox for reigniting the browser war. In Browser War 2.0, all the major players are striving toward standards compliance, trying to bring their behavior in line with a single unified goal instead of adding their own proprietary features to HTML itself. Five years from now, when IE6 and IE7 are as distant a memory as IE4 and IE5 are now, web development is going to be a lot easier.
Re:Rendering (Score:4, Insightful)
Does this mean that someday /. will actually render properly in a browser? I used IE, FF, Opera, and Safari all regularly. /. does not reneder 100% in any of them :(
How do you know that one of them isn't proper and the rest are merely deviations from proper? Or, more accurately, how do you know what it is supposed to look like if you say they are all wrong?
Re:XHTML merged (Score:3, Insightful)
Re:XHTML merged (Score:3, Insightful)
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:Good (Score:5, Insightful)
The main key is, that, while HTML5 is based on the superior SGML (because of more freedom), XHTML had started to enforce strictness and cleanness. This meant the browser did not have to support a ton of typos, just because the editor was a freakin' lazy ass. Imagine a compiler that would eat any typo. Missing brackets, braces, semicolons, object-function separators, completely meaningless semantic messes. HTML4 browsers eat it all.
It is horrible, and actively supports the dumbing down of people. (Those who want to write websites.)
Face it: If they have to, they will learn it. Nobody is too stupid for that. Some just repeat so often that they are stupid, that they actually become stupid. But this can be reversed in exactly the same way. (Ask any psychotherapist about self-fulfilling prophecies.)
Another great feature of XHTML, was its modularity and cross-language features.
You could integrate XHTML, SVG, MathML, etc, into one document. Imagine a P tag inside a SVG circe, containing a math formula, and you begin to understand the sheer power of that concept.
Now if they implement HTML5 right, and we get the same cleanness that XHTML 1.1 had (Strict only. No transitional shit.), and they add cross-language abilities too (trough SGML), then I'm all for it!
But if not, this could be a huge step backwards, into the web development mess of IE6 times!
Re:XHTML merged (Score:5, Insightful)
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 <!-- 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 (Score:3, Insightful)
> 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.
HTML 5 parsing is just awful. (Score:4, Insightful)
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 [whatwg.org] 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:
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.
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.
Re:No more compound documents? (Score:5, Insightful)
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:
Re:No more compound documents? (Score:3, Insightful)
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:Good (Score:4, Insightful)
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 (Score:4, Insightful)
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 (Score:3, Insightful)
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 (Score:5, Insightful)
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 (Score:3, Insightful)
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:
.': '.$message.' at '.$filename.' ('.$line.').'); }
;).
function errorHandler($code, $message, $filename, $line) { die($code
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:XHTML merged (Score:4, Insightful)
Bullshit. Every person on Earth should be allowed, and encouraged, to create web pages. I hate this elitist crap.
Re:Good (Score:1, Insightful)
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 [joelonsoftware.com], 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 (Score:3, Insightful)
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:XHTML merged (Score:3, Insightful)
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:Good (Score:3, Insightful)
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 (Score:3, Insightful)
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.