Not even that. That code would be “HTML in quirks mode” or “HTML with errors”.
That’s just because there are still people using browsers such as Internet Explorer 8 that don’t support XHTML. Once those browsers are dead then XHTML will be able to be used - including all of the benefits that it offers that are not available in HTML - it will actually become eXtensible as the X in the name indicates. There is no benefit UNTIL IE8 dies and it can be served as XHTML. The benefit is that it will not need to be rewritten in order to do sithat - just a change of MIME type will do it.
If XHTML were truly dead then why is XHTML5 currently under development?
For the past 10 years that was the line that “helped” people to serve browsers with HTML content and HTML features in a XHTML syntax and with a HTML mime, which browsers had to correct over and over again, just so that those people feel somewhat better than others.
Which, obviously, was, and still is wrong in more that just one way.
If you don’t use it than don’t serve it. If you can’t serve it, than don’t build it. What future may bring, that’s in the future. And XHTML has been in the future for so many years, it’s become a joke.
The bottom line is, don’t use XHTML syntax if you:
- don’t use XHTML features
- can’t serve it with the right mime
XHTML syntax alone it’s really not a good indicator on how well versed one is in web development. At all.
And let me share something with you. The moment IE8 is gone and we could start building and properly sending XHTML docs, that’s the moment when the life has become much harder for browser vendors.
Because that’s the exact moment when they have to implement graceful degradation for badly written XHTML docs. Since this is the moment when HTML started to get a bad name, when they had to account for any malformed web page and still render it, no matter what.
Or do you believe HTML couldn’t have been as strict as XHTML and be able to hold rendering on stupid little errors like a little missing >? Guess what, they learned pretty fast that dumb-stopping the rendering was not the solution.
Furthermore, I’m not looking forward to live-debugging my web pages by serving users stopped renderings. That’s just wrong, and this type of live debugging is not a feature for XHTML, for any web developer.
I imagine few people today actually hand-code every bit of their web page. Templating systems, dynamic generation, even blogs use CMSs like these. So it’s not so unheard, that no matter how careful the web developer was, that a glitch would occur somewhere and render the web page… renderless.
And the user certainly won’t appreciate this live debugging, the render stop. And neither will you, the developer, no matter how much you took pride in your XHTML badge up to that point.
So browsers would have to compensate for that, in order to remain in the game.
Realistically, HTML or XHTML, “The show must go on”. Content is king, and it must be delivered at any price to the user, without some fancy slap in the face about some smarty pants XHTML being malformed.
And that’s how, the moment XHTML can be properly sent, it’s the moment it loses any upper hand over HTML, regarding the “benefits” in code strictness. Those that wrote bad HTML code will now write bad XHTML code and still get away with it. Those that wrote good HTML code, would write better HTML code, leaving aside any other imaginary XHTML benefits, and will continue to stay out of the browsers way by not sending text/html with XHTML syntax.
Guys, I’m watching you 
-
XML is still used. AJAX and RSS are real-world examples of XML in use. XML can also used as flat-file databases.
-
On a personal note, I was a big fan of the XHTML syntax because it was semantically correct (in terms of a tag-based language, anyway). But, now, I don’t really care too much either way. I’ve moved away from it and gone with HTML5–even though I don’t use many of its features, it’s simply the new direction of the web. HTML5 can be written in the XHTML or traditional HTML syntax if you still prefer one way or the other.
I hope not - the best part of XHTML is that browsers refuse to display the page at all if there are ANY XHTML errors. Unfortunately some browsers have already b roken the rule about refusing to serve badly written XHTML.
What’s the point of XHTML if the browsers will accept any old errors the way they do with HTML - might as well stick with HTML if you want the browser to fix your errors for you.
What would be really interesting is if we could tell the browser – either through an HTTP header or a meta tag – whether it should error correct or fail. That way, we could set it to fail in dev environments but error correct in production.
Because that’s not the main feature of XHTML, syntax strictness. Like I said before, we could have had that with HTML. HTML docs could have as well break rendering upon any error, big or small, but it turns out that that’s not a valid scenario in the real world. And once XHTML joins the mainstream, breaking the rendering on any errror, big or small, it won’t be a valid scenario either.
So forget about syntax, it’s a small fish to fry and strictness it’s something HTML could have done it itself. Most importantly, the gains of using XHTML are things like interoperability, namespaces, new elements and such. Though since SVG and MathML are available with plain HTML in HTML5 semantics, using something like a XHTML <object> for this type of integration inside a HTML document would be best, IMO.
WebSockets, hopefully, will replace AJAX. Or any other AJ***. Maybe even AJAJSON.
RSS is becoming redundant. (Apple drops RSS in OS X 10.8 Mountain Lion.)
Too verbose for that. JSON, YAML,…
Simply put, the web will never be the place where browser vendor punish web developers for syntax errors in extreme ways. Especially since it may not even be the web developer’s fault, but a crazy glitch in one of the supporting systems.
The point is that XML is still in active use. It hasn’t been abandoned. I’m just not sure why you are so vehemently against it.
WebSockets are interesting, but since most browsers out in the wild don’t actually support them, they are impractical for real-world use. [ot]Especially until 2017. This is when support Windows Vista ends, and Microsoft has already stated that IE9 will be the lastest browser version deployed to Vista. WebSocket support is planned for IE10.[/ot]
RSS is becoming redundant. (Apple drops RSS in OS X 10.8 Mountain Lion.)
Redundant how? What’s replacing it?
All apple did was remove it from their browser and mail applications (as a side note: I’ve been questioning some of Apple’s strategies and decisions as of late; this being one of them). RSS is also still supported through Apps in the app store. Other browsers still support it, and there are plenty of other 3rd-party stand-alone RSS readers still available.
Too verbose for that. JSON, YAML,…
JSON is great for transferring simple data. JSON is strongly tied to Javascript, while XML is language-independent. XML tends to be a better for longer-term storage because it’s structured and standardized. And XML can be as verbose or as concise as you want it to be.
Here’s a quick comparison between what you can do with JSON and what you can do with XML.
JSON:
{ "firstName": "John",
"lastName": "Smith",
"age": 25,
"address": {
"streetAddress": "21 2nd Street",
"city": "New York",
"state": "NY",
"postalCode": "10021"
},
"phoneNumber": [
{
"type": "home",
"number": "212 555-1234"
},
{
"type": "fax",
"number": "646 555-4567"
}
]
}
XML:
<person firstName="John" lastName="Smith" age="25">
<address streetAddress="21 2nd Street" city="New York" state="NY" postalCode="10021" />
<phoneNumbers>
<phoneNumber type="home" number="212 555-1234"/>
<phoneNumber type="fax" number="646 555-4567"/>
</phoneNumbers>
</person>
(Source: http://en.wikipedia.org/wiki/JSON#XML)
YAML is problematic because it isn’t a tag-based language, but a tab-delimited based language. It’s way too easy to end up with a malformed document, and thus makes it impractical. With XML, formatting and spacing doesn’t matter since it’s a tag-based language (although it helps so that the data is more easily human-readable).
I’m not against it, I’m pointing out what XML is not. Yes, is still active, and I’ve said that my self, but only because of backward compatibility issues. But it stopped having a future.
Wikipedia is not the best reference to quote, and, as such, you are inaccurate on a number of things.
-
XML can be as verbose or as concise as you want it to be.
That’s a hack and you know it. No serious data storage is going to use attributes instead of nodes for information. -
JSON is strongly tied to Javascript.
Wrong.
http://www.json.org/
JSON is a text format that is completely language independent.
- XML tends to be a better for longer-term storage because it’s structured and standardized.
Wrong again.
Here’s are the languages with JSON implementations:
http://www.json.org/
ASP:
JSON for ASP.
JSON ASP utility class.
ActionScript:
ActionScript3.
JSONConnector.
Ada:
GNATCOLL.JSON.
Bash:
Jshon.
JSON.sh.
BlitzMax:
bmx-rjson.
C:
JSON_checker.
YAJL.
js0n.
LibU.
json-c.
json-parser.
jsonsl.
M's JSON parser.
cJSON.
Jansson.
jsmn.
cson.
C++:
JSONKit.
jsonme--.
ThorsSerializer.
JsonBox.
jsoncpp.
zoolib.
JOST.
CAJUN.
libjson.
nosjob.
rapidjson.
C#:
fastJSON.
JSON_checker.
Jayrock.
Json.NET - LINQ to JSON.
LitJSON.
JSON for .NET.
JsonFx.
JSON@CodeTitans
How do I write my own parser?
JSONSharp.
JsonExSerializer.
fluent-json
Manatee Json
Clojure:
clojure-json.
API for json.
Cobol:
XML Thunder.
ColdFusion:
ColdFusion 8.
toJSON.
D:
Cashew.
Libdjson.
Dart:
json library.
Delphi:
Delphi Web Utils.
JSON Delphi Library.
JSON Toolkit.
tiny-json.
E:
JSON in TermL.
Erlang:
ejson.
mochijson2.
Fantom:
Json.
Go:
package json.
Haskell:
RJson package.
json package.
haXe:
hxJSON.
Java:
org.json.
org.json.me.
Jackson JSON Processor.
Json-lib.
JSON Tools.
Stringtree.
SOJO.
Jettison.
json-taglib.
XStream.
Flexjson.
JON tools.
Argo.
jsonij.
fastjson.
mjson.
jjson.
json-simple.
json-io.
JsonMarshaller.
google-gson.
Json-smart.
JavaScript:
JSON.
json2.js.
json_sans_eval.
clarinet.
Lisp:
Common Lisp JSON.
Yason.
Emacs Lisp.
LotusScript:
JSON LS.
Lua:
Json4Lua.
LuaJSON.
LuaJSON C Library.
Fleece.
Lua CJSON.
dkjson.
Matlab:
JSONlab.
JSON Parser.
(another) JSON Parser.
Objective C:
json-framework.
MTJSON.
JSONKit.
yajl-objc.
TouchJSON.
OCaml:
Yojson.
jsonm.
OpenLaszlo:
JSON.
Perl:
CPAN.
perl-JSON-SL.
PHP:
PHP 5.2.
json.
Services_JSON.
Zend_JSON.
Solar_Json.
Comparison of php json libraries.
Pike:
Public.Parser.JSON.
Public.Parser.JSON2.
PL/SQL:
pljson:
Librairie-JSON.
PowerShell:
PowerShell.
Prolog:
SWI-Prolog HTTP support
Puredata:
PuRestJson
Python:
The Python Standard Library.
simplejson.
pyson.
Yajl-Py.
ultrajson.
Qt:
QJson.
R:
rjson.
Racket:
json-parsing.
Rebol:
json.r.
RPG:
JSON Utilities.
Ruby:
json.
yajl-ruby.
json-stream.
Scala:
package json.
Scheme:
MZScheme.
PLT Scheme.
Squeak:
Squeak.
Symbian:
s60-json-library.
Tcl:
JSON.
Visual Basic:
VB-JSON.
PW.JSON.
Visual FoxPro:
fwJSON.
JSON.
- And XML can be as verbose or as concise as you want it to be.
While this “postalCode”: “10021” will always be shorter then this <postalCode>10021</postalCode>, JSON can also be as concise as you want it to be:
"address": {
"21 2nd Street",
"New York",
"NY",
"10021"
},
JSON is built on two structures:
A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array.
An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence.
These are universal data structures. Virtually all modern programming languages support them in one form or another. It makes sense that a data format that is interchangeable with programming languages also be based on these structures.