Slashdot Mirror
The Future is XHTML 2.0
An anonymous reader writes "As with its past, the future of HTML will be varied, some might say messy, but I believe XHTML 2.0 will ultimately receive widespread acceptance and adoption. A big move in this direction will be in Embedded devices such as phones and digital TVs, which will have no need to support the Web's legacy of messy HTML, and are free to take unburdened advantage of XHTML 2.0. This Developer Works article examines the work of the World Wide Web Consortium (W3C) in creating the next-generation version of their XHTML specification, and also their response to the demand for 'rich client" behavior exemplified by Ajax applications.'
You're right in that the best cellphone webpages are specifically designed for the purpose. This site makes it possible to view regular webpages on cellphones, however.
Religion for nerds. Stuff that really matters
Ajax works in conjunction with:
Furthermore, the WHATWG are formally specifying the XMLHttpRequest interface, which they will probably submit to the W3C once complete.
In what way are these "versus" Ajax? Ajax works with standards, not against them.
Bogtha Bogtha Bogtha
Because making use of data is easier than presentation. The things that aren't widely implemented in CSS are *hard*, and there isn't really a comparison for HTML. Any browser that supports real XHTML (ie. not IE) can easily support XHTML 2. New functionality is limited, it's just the way that it gets marked up that has changed. Example: if you've already coded support for , then it shouldn't require too much effort to call the same code on <[whatever-element-the-page-author-feels-like] href=""/>
As noted on the IE blog, IE 7 won't support the "application/xml+xhtml" MIME type. That means that all of your XHTML 2.0 documents will still need to be sent as "text/html", and will thus be parsed as HTML. Yay, progress!
Sounds like, when they say "future", they mean "fuuuuuuuuuuture".
Just wanted to point this out:
XHTML2 -- with navigation lists, links on any element, sections and headings -- is optimized for web documents.
HTML5, officially Web Applications 1.0 -- with canvas, a drag and drop API, and XMLHTTPRequest standardization -- is optimized for web applications.
CSS3 is going to be extremely cool.
XHTML is not rigid - it simply takes the old HTML 4 tags and adds a few constraints, so that the resulting document is XML-compliant. Its readability isn't affected, it's easy to look at the structure of the document, the learning curve from HTML 4 is minimal, and it makes parsing it much much simpler as there is a well-defined document structure.
It's probably because there are tradeoffs with any approach:
1) thin client - low demands on end user hardware, but heavily dependant on working central server. One point of failure for many users (server) and one place to concentrate attacks - server must be very robust because it is a single, fixed, information rich target.
2) thick client - high demands on end user hardware, and a maintainance nightmare for tech support. The security situation will vary widely between individual setups. However, a failure of one machine causes only limited damage, and doesn't impair other machines. If desired (e.g. home hobby applications) a high degree of self reliance is possible.
Different situations require different solutions. There are intermediate solutions, like a client which doesn't maintain any of the software but does have its own graphics acceleration hardware, in order to avoid straining the server's resources when running something like a CAD or raytracer program. The trick, of course, is what constitutes the "best fit solution." And there is no one answer to that.
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
All that I can say is I hope they keep TABLE in XHTML2 because tables gives the designer more control over the design look and positioning rather than DIV. DIV is extremely difficult to place in that right place. i have tried both code -- tables are easier.
Personally, I'm still waiting for XHTML 1.0.
Seriously, how many pages currently on the web would survive a simple XML validation? Most commercial tools I've seen, even those current, make no real attempt to break away from HTML 4 + cute junk standard. And XHTML 1.0 was introduced in January 2000...
Until the browsers that constitute the bulk of the market share support this kind of thing in a meaningful way, it's doomed. Period.
One way to move this stuff along would be a develop a fully compliant plugin for current browsers that could support standards in spite of the platform. Once it's clear you need 3rd party tools to support what's supposedly a web standard, maybe the bigger browsers will be guilted into supporting it natively.
I'd love to see something like XHTML 2.0 adopted with gusto, but if history is any indication then something major will have to change.
You silly dork. He does that ON PURPOSE in the earlier chapters, because he's demonstrating how to transition from old table layouts into proper CSS.
That's funny, because I'm pretty sure that changing to XHTML 2.0 would still use the same Internet connection I already have, as well as the same protocol (HTTP 1.1). XHTML 2.0 has a different mime-type, so you can tell whether XHTML or HTML is being used.
Before you say it, yes, XHTML 1.x does work with text/html, but you'll also notice that XHTML 1.x has not removed support for any tags, unlike XHTML 2.x.
To be exact, XHTML 2.0 does away with the following tags:
- br
- hr
- h1-h7
- img (all elements will now support src=)
- form, input, textarea
- ins, del
- script
- frame functions - Has been relegated to XFrames
It addsGLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
When you first glance at this data I would agree with you:
Google stats on 1 billion web pages.
IE users: You need SVG support to see the graphs. (Hint: Firefox supports SVG.)
I wish they had looked at DOCTYPES, that would have told us a lot. But even so, you don't know whether there are a few large sites that put out really bad (X)HTML, or a lot of little sites. That makes a difference. The little sites, especially the rarely-changed little sites, are not the ones that drive the desire for improved standards. It's the new and growing sites like deli.cio.us and reddit or the services like Google Maps that need new and better ways of doing things.