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.'
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.
I would have thought that if the devices didn't need to serve up web content, they would use a proprietary system that is best suited for the job. If they did serve up web content, than of course they should support HTML.
Religion for nerds. Stuff that really matters
It would be even better if he was in Congress.
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
Digital TVs have no need to support XHTML 2.0 either. Maybe in the future they'll write their menus in XHTML 2, but why bother? No one is browsing their own TV as a server (although that might be a cool hack). TVs need custom interfaces, not web pages.
Developers: We can use your help.
These are a complete oxymoron. Google and windows live (I hear) are all about reimplenting normal functionality in confusing new ways, that certainly won't work on any simple client.
I think it's time for the internet to stop catering to the past.
Can you imagine our interstates if we still catered to stage coaches, horse drawn carriages, and Model T's?
Can you imagine television if we still catered to black and white TV's?
Change happens. Get over it. It's not like Firefox cost's $3,995.00 per copy.
When people can no longer recognize the sites they like, they'll get the hint and upgrade.
It won't be sites like Amazon.com that bring about this change, it will be sites like HomeStarRunner.com, JibJab, that don't have billions of dollars in sales to lose, but can be just as influential in a grassroots way.
Lose Weight and Feel Great with Isagenix
I'm not entirely familiar with XHTML 2.0 (we have code monkeys who concern themselves with this these days) but is this a case of the standards following the people who will or will not use this as is intended with a begging bowl in hand, or does it really address the many concerns surround HTML/XHTML/CSS?
The Mothership
Why is it that every new product has an 'X' attached to it?
XBox, XForms, XHTML, OSX, Windows XP, x86, xChat, X Multimedia System, Adium X, X drive, and it goes on and on.
So just slap an 'X' on it and instantly beam into the future!
He who knows best knows how little he knows. - Thomas Jefferson
It's HTML 5.
XHTML looks nice in theory, but HTML 5 is being designed for real world use. It can be sent with an xhtml mime-type too.
has in Xhtml(along with the htDP protocol), yet again proven they are one of the primary forces powering advances in network technology.
<h property="title">Welcome to my home page</h>
This denotes the heading as the XHTML 2.0 title of the document, and specifies it as the inline heading. Finally, an end to writing the title out twice in every document!
It seems to me that introduces it's own quirks...
<h property="title">Welcome to my home page</h>
<div property="title">Second title, what now?</div>
-William Shatner can be neither created nor destroyed.
I believe XHTML 2.0 will ultimately receive widespread acceptance and adoption.
Yeah right, just like CSS2. and XHTML1.0... 'Adoption' is not just not exploding when encountering XHTML2.0 - it means full support for the entire standard. And unfortunately we're not there yet for standards which have been around for years. I don't see why things will go differently for XHTML2.0
but i have a hard time taking a guy named Edd Dumbill seriously.
The only way to get rid of a temptation is to yield to it.
-Oscar Wilde
I prefer XHTML. The X makes it sound cool.
Every so many years they come out with this new exciting standard that turns out to go nowhere. That is because technology isn't standards driven, it is standards that are freedom/technology driven. For example, Linux (in spite of all the distros) has done more to standardize the OS that all the POSIX standards committies and Motif (renember that one) and CDE (renember that one too) standards combined. Typically a good stnadard is one where people created it first to meet a need, everyone started using it, then the standards committie eventually get arround to formalizing it. If it doesn't happen in that order, it is most likely crap.
Why do I care what any anonymous person thinks about anything? Why does anyone think that cellphones are going to define *anything* about the generic content on the web? Who cares if my HTML is messy. Don't look at it.
I guess I will prognosticate some... XHTML 2.0 adoption will have nothing to do with cellphones.
I thought Web 2.0 was the future?
Ow wait.. that's right.. that was LAST week's "future". So, shall we take bets on next week's "future"?
"No one is browsing their own TV as a server (although that might be a cool hack). TVs need custom interfaces, not web pages."
For local content,* and services they will.
*Local being defined as anything before the demarcation point.
An rather unfortunate name, don't you think?
It seems reasonable that Edd, or one of his agents, was the one submitting the story.
Does anyone know how the IBM developer pages work? Lately it seems like those pages are being spammed all over the place, and the quality of the content has dropped precipitously. Are these external submitters that get paid per click or something? Something is right about the whole thing.
I wonder when this is going to be released. Most browsers are having a hard time with (X)HTML as it is right now, and now XHTML 2.0... It will probably take years to get browsers to support it properly (looks at IE + CSS). Oh well.
Ryan - http://www.thecosmotron.com/
what's so hard about remembering to close any tag you open? the only validity to your arguement is that people are lazy and don't feel it necesarry to close their tags in the order they opened them.
A few more examples
Xenu loves you!
It looks like XHTML 2.0 is a lot like the previous versions (XHTML 1.0, 1.1) with some new features. I doubt the predicted "wide success" of XHTML 2.0 if no one really seemed to care about the older versions. I sure would have liked it if every web site author was enthuastic enough to have well formatted pages.
I thought HTML 5, a.k.a "Web Applications 1.0" was the future?
(from the my-future-is-better-than-your-future dept.)
XHTML2.0 is nice. I would accept it immediately! But sadly this is not me and this is not you who decides what gets accepted... I'm a web developer and I'm supposed to do the best for my clients. My clients expect me to do the work in the way that the biggest audience available will be able to use it...
:-( )
I will not "accept" the XHTML2.0 as long as I'm not sure that my clients can loose any of potential visitors/customers.
The right question should go to the major browser providers:
"Hey, browser creators, when do YOU and YOUR COMPANIES accept the XHTML2.0?"
(I'm afraid that it is too many years ahead to be worried about
Well, I've got to get back to work. When I stop rowing, the slave ship just goes in circles.
Phones and TVs only have no need to support the existing Internet if their users don't want to see anything but vendor-controlled proprietary content.
Existing web is in html (and bad html at that).
ANYTHING offering 'web access' is going to support
the existing web.
Thus, HTML 5 is the future. Especially since xhtml isn't even supported properly in today's most used browser (ie. IE). And no, sending as html does not count and is even bad (yes, I'll change my own website to reflect this in the future).
Hand-coding HTML is already too hard for most people.
On the other hand, if you use a good web-page editor that supports web standards, it really doesn't matter to the user anymore whether it's generating messy HTML or "XHTML with its rigid rules".
Last I checked w3c complient browsers had less than 20% of the market share. Until IE is either updated or dead, the web is pretty frozen. Don't expect anything to change with IE 7 either.
Microsoft knows that the web is the only real forseeable threat to their operating system. What do you need windows for if you can run your rich business applications on a platform independent web browser?
I believe this a real conflict of interest that should have been addressed in all of the anti-trust hearings. Oh wait, nothing changed even after they were found to be a monopoly...
Change isn't going to happen easily
Here we go again. "Thin client is the future!" -- "No the users demand bloated clients with millions of animated doodads!" .. "No wait, the thick client is a mess full of security holes!" -- "No, the server-side processing and thin clients are future, again" -- "No, wait, the rich contents thick like a brick clients are the future!" --
[interlude] Bah, "the client-server paradigm" is the future! [/interlude]
Seriously though, thin, simple and reliable client coupled with powerful server-side processing is the staple of reliablity and usually the highest performance and security. The "rich client" is a fancy word for going back to "everybody needs a huge multimedia client (i.e a 23GHz CPU 3-core phone) to access this page with 4 lines of text on it!" and fat servers because the clients although bloated and huge are too dumb to do anything besides being pretty and acting like the swiss cheese of security. I think we've been there before, and it was called ActiveX, no?
Read those first. It seemed at the time of the publication that the XHTML 2.0 team were making all the mistakes of the designers of HTML 3.0 - creating teh perfekt markup language, instead of contributing called-for improvements, even if the two overlap a lot to our benefit. And I don't think that's changed. (I don't mean to disparage the many good changes in XHTML 2.0, but I ultimately think that their goal (stripping down and semantically cleansing XHTML 1.1?) is a different one than mine, and that that means we're not getting the improvements we want.)
My money's with, and my faith's in, HTML5.
"So just slap an 'X' on it and instantly beam into the future!"
XXX, Beam me up, Scotty.
Those who forget the past are doomed to repeat it as the saying
goes. The problem with the computer industry is that the people in
the driving seats are so busy looking forward that they don't bother
to look in the mirrors to see the wrecks on the side of the road.
Throw in a bit of marketing logic (ie any change is good no matter
whether is a throwback to a bad idea) and you've got the current
computer industry.
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".
People who find XHTML hard probably aren't the kind of people who are crafting pages by hand anyway. WYSIWYG editors hide those details for them.
The laxer rules of HTML make it easier to write pages that aren't portable. If people can't handle XHTML, can you also expect them to realise their sloppy HTML will only work in the version of IE they're working with?
XHTML is easier for me. My content is in XML, so using XSL to convert it to XHTML is easy. HTML has a mild tendency to break in this setup.
Good, maybe people will stop trying to pretend to be web developers and leave it to those that actually know how to do the job. Back in the day when you needed to know HTML to have a presence on the web this might have been a problem, but now with Myspace, all the blogging software out there, WYSIWYG programs (That will work better with XHTML) etc, I really don't think it's all that important.
...is it Web 2.0 compliant?
We can't fight IE's predominance so lets join forces and extend frontpage beyond the imagination!!!! yay!!!
***Game Over***Insert Coin***
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.
"Greetings, my friend. We are all interested in the future, for that is where you and I are going to spend the rest of our lives. And remember my friend, future events such as these will affect you in the future."
:)
Plan 9 for the Internet
So I'm not the only one who thinks the ultimate goal of the browser is to become an X-Windows server.
All generalizations are false, including this one. Mark Twain
Ok, I'm sorry but anybody who's ever designed web content knows that a "content-rich" standard is a load of crap. Firstly, it's not the standard that makes something "content-rich" it is the developer. Second, hosting companies have not yet measured up to the "content rich futures" that everyone expects. We keep loading up on features yet we're unable to deploy them because of the overhead. Standards and technologies change so fast on the web that by the time I put down my "XHTML 2.0 in 24 Hours" book there will be a new standard released, and they'll probably start using roman numerals too XXVIIHTML.
Can a complete "rich" (gosh, I hate those rich-this, rich-that people) XHTML 2.0 client be implemented with a reasonable amout of code (no multi-megabyte binary)?
Can XHTML 2.0 content be streamed more eficiently through a low bandwidth channel?
Is XHTML 2.0 specially friendly to WYSIWYG development? (let's face it, 90% of the not automatically generated Internet content is developed this way).
Wake me when some of the answers is yes.
XHTML 2 is doomed to remain forever "in the bright future" of geeks, where noone cares for compatibility and real technology benefits, but is entirely consumed by semantics and how pretty his code is.
Look at the benefits if XHTML2 and compare it to HTML5, and you'll quickly see why WHATWG was formed.
As HTML5 offers answers to actual problems in web development, and offers backwards compatibility, XHTML2 pointlessly restructures the language, making it harder to read in the process (quick: count the nested sections spread accross pages of text to guess the heading level you're at).
Also while the author dreams about our XHTML2 future, the next major release of the dominant browser on the market (IE7) doesn't even support XHTML 1.0 yet. And this is the browser that most people will use in the next 5-6 years at least.
The author also calls XHTML's semantics better. This is subjective. HTML5 also offers more semantical tags, but according to my practise, it'll be easier to build sites styled with CSS in HTML5 than XHTML2. XHTML2 doesn't have better semantics, it just has different semantics. HTML5 is the one with better semantics IMHO, that build on top of HTML4.
No major browser supports XHTML2, but they support parts of HTML5 (like the canvas tag, invented by Apple's Safari browser, and included in the spec by WHATWG).
I won't even comment the section about XHTML2 "toys" because the subject is serious.
In conclusion I'll say that it's not likely XHTML2 will become a supported standard while most of us are alive, so better concentrate on good HTML4/XHTML1/CSS/JS/SVG/Flash code and applications, and follow the developments at WHATWG.
safeDisplay(HTML page)
{
try
{ display(page) }
catch(ParseException pe)
{ display(tidy(page));}
}
Tired of the malformed xhtml pages
well, Tidy keeps your webpages clean
http://www.w3.org/People/Raggett/tidy/
Thanks to CSS stylesheets...
Well, "Use XML as much as possible" didn't last too long. Why isn't there a version of CSS defined as XML so you just need a single kind of parser?
Make HTML easier to write
If you want it to be easier to write (and hopefully read), why not use something nicer than XML? XML is easy to parse and easy to generate, but is very messy humans to read & write.
My prediction is that XHTML 2.0 will more likely establish itself first in scenarios other than the classic web (and Web 2.0, for that matter). Now, whenever an XML application designer has a need to spec "rich text"-like embedded payloads, they consider XHTML as the most natural candidate. Look at this XMPP extension proposal for an example. The modular nature of XHTML 2.0 adds versatility: you can lock down your next-gen instant p2p hyperblog protocol to use a safer and saner subset of XHTML and have schemas at hand to verify it.
My exception safety is -fno-exceptions.
Look, the issue everybody is running around screaming about is really a non-issue. Everybody still wants to create the coolness of spinning logos and blink all over again. But this not the issue.
Content is the issue. Data issued on demand and being accessible is the true concern. No, it is not as cool as barking menus, but who will pay for such worthlessness in the long run.
Just as we have moved off (or should be) the notion that a website is like a book with a begginning, middle, and end, so should we move off the idea that everything has to be displayed. What I mean to say is that we don't need a homogeneous web browser for every appliance. You want content on TV? Then apply the video, audio, or static imagery instance to a cascading infrastructure. You watch an American football game? Then you decide to pop-up stats in a PIP (picture in picture), a secondary monitor. Want the game but listen to it from the home team announcer on the auditory channel (FM). Screen caps of a particular play? Save the game to hard drive? Message a friend, "check out the score, loser."
The presentation of these data constructs should be completely different than say a cell phone. You have the same databases (video feed should now be considered one), but a different end-user experience. Less video real estate and limited (less usable) contextual linking.
To say that TV should define standards based upon XHTML is saying that we should dumb down capabilites to give a uniform experience.
I skimmed TFA, and I can't see anything to suggest that CSS has been improved to a point where it is going to enable the sort of layout that most people still implement using TABLEs. As long as managing to produce a webpage with three columns entirely in XHTML and CSS is something to get really excited about, I can't see that strict XHTML compliance has a hope of becoming the de facto standard.
And before everyone bangs on about how CSS is really neat if you understand it, see Eric Meyer - who bought us the W3C CSS1 Test Suite - in "Eric Meyer on CSS", demonstrating how to produce lean and standards-compliant webpages... using TABLEs for layout.
Does anyone know how we got saddled with CSS as a half-baked page description language in the first place?
Virtually serving coffee
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.
The Future is XHTML 2.0 == The future is the next version. O RLY?!?
True, but where's the necessity? Does adding a </p> make my markup any cleaner or less ambiguous? Does requiring me to close my <img> tags help in any way other than making it well formed XML? No. It gives you nothing that you couldn't already do with compliant HTML in the first place. XHTML was a mistake from the beginning, and I hope it falls flat on its face. Of course, with schools and universities now teaching that XML is the One True Way now, I suspect it'll be successful despite its problems. Sigh.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
XHTML is a good illustration why it is a good rule to never finalize a standard without a usable reference implementation. Right now it's just a boring document. I suspect the people who are supposed to implement it have barely read it. And frankly, I don't think they will.
XHTML 2.0 is part of a fictional roadmap that was tossed around late last century and then was discarded. Microsoft decided to sort of stop developing their rendering engine and Netscape was sold to AOL and eventually was liquidated. Microsoft is still pretty happy to not do any significant new standards support in their upcoming browser. Meanwhile the mozilla people, opera people and konqueror/safari people are working outside the w3c to get some real standards work done: like this decade! Html 5.0 is something I can see happen, xhtml 2.0 was dead. on arrival (did they ever bother to make it a recommended spec?). As a matter of fact, XHTML 1.1 is as unlikely to ever be a relevant standard as well. And that one would be relatively easy to implement for browser developers.
Jilles
That's probably where its going. My personal feeling however is that for things like phones and even business applications an efficient VNC-like client is the way to go, as X11 is already a huge overkill for these tasks as far as remote clients go. I see X11 as being useful as the server-side per-user virtual graphics engine which renders its output into a memory buffer which is then analysed for pixel changes, which are then compressed and transmitted to the client.
A lot of people won't adopt a new standard until it offers a clear benefit over what they're already using. So far, most of what you get from XHTML is a bulkier page with more restrictions that no longer displays in 1% of browsers. XHTML 2 will work in even fewer browsers. XHTML 1.0 has been around for 6 years, and hardly anyone uses it. IE tries to parse it as HTML. Browsers parsing XHTML often don't fail gracefully. Sometimes the slightest typo results in a blank page. Google doesn't even use DOCTYPE tags, just plain HTML, and it works in every browser.
If you'd bothered looking at the actual W3C standard, you would see that sending the document as text/html is permitted up to XHTML 1.0 Strict. It is only XHTML 1.1 that requires application/xml+xhtml.
As long as there is more than one product that uses a specification or recommendation, there will be feature competition. Feature competition usually involves bending or breaking the rules to lure customers. To top that off, it isn't as simple as someone creating a completely compliant tool and releasing it. If it did happen, there is not any means to guarantee that it will achieve a sizable distribution. The average user just does not care enough.
In my experience, specifications and recommendations are best followed to the highest level that allows cross-product functionality. To follow something to the letter, will usually narrow the delivery target audience. However, specification and recommendations do well at augmenting style and standard practices - just as long as they guide and not define. ;-)
You are in a maze of little twisting passages, all different.
A markup standard where tags are obligatorily closed makes a parser much, much easier to write.
Has the W3C finally gotten over its hatred of providing any easy tools for centering both text and block elements?
The best way I found so far which I find devious is using
left-margin:auto;right-margin:auto;
I'm still trying to figure out what people mean by 'social skills' here.
No, the new interactive pages allow a person with a fairly limited machine can now communicate more directly with the server therfore redcing the need for a large pipe, which is currently the major limitation on applications.
THIS SPACE FOR RENT
Actually I think that the Graphon technology provides the flexibility of an X Server with reduced footprint and CPU load. Perhaps even the SunRay client if session persistence is a goal. The problem remains that if you want a decent UI you need to design it for the phone or the desktop. CSS will extend the range from small cell phones screens to large ones but not from phone to desktop.
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
"Ajax works with standards, not against them"
Sorry to be pedantic but,
actually, AJAX is "composed of" existing standards. AJAX is just a label put on a set of ways of using various standards together.
It might be even be a little more correct to call AJAX a design pattern. But, I'd start some kind of holy war if I said that.
If the latest articles I've read on AJAX are to believed, I'd say its really composed of venture capital pixie dust. Sprinkle a little on to bring in the bucks.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
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.
They didn't catch the typo. The author's actual name is "Edd Dimbulb".
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Sure, it's permitted, but what AkaXakA was saying is that it doesn't count as supporting XHTML properly when a browser can handle XHTML served as text/html, because the browser just treats it like buggy HTML and not XHTML.
Bogtha Bogtha Bogtha
"standards that Ajax fails at meeting are USABILITY standards"
A good argument but, I feel I should point out that the majority of the web sites out there fail to meet usability standards with or without AJAX.
OTOH, its better that people go crazy with their ideas.
Things that are truly usable (not just those deemed so by the so called advocates) will float to the top, the rest will die off. With the thousands of people developing things I think we will see some good ideas arise. Then everybody else will rip off those ideas and improve and bastardize them. ahh... welcome to the wild wild web...
----- If communism is a system where the government owns business, what do you call a system where business owns govern
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.
Not really. Last night I was watching a show that was only being broadcast in digital HD. Which is pretty much what's being proposed for the web--some content will only be available to those who upgrade to XHTML 2 browsers.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Concidering my age, and concidering my one year formal experience in development thus far, IMHO, _most_ of these authors should be fired. In reality, "web standards" is becomming a new "buzzword". Like anything that grows organically, adoption of these web standards is slow, and slowly accelerating. At some point, there will be a "critical mass", and the rest is history.
Of this I am convinced because the new methods simply make sense. And no matter how much some entity will try to push their crap on people, eventually people have the final say. What they will use will be what makes sense to use based on experience, not marketing.
Keep in mind that the *only* thing that makes you a "big presense" on the Internet is your visitors. If your crapsite doesn't render for them, guess what's easier to change (options: 1. people's devices at home, 2. your bloody code). If you opt for option #1, good luck, this is a high risk, with a potentially big return (probably in the form of sales of the device). Option #2 requires someone with experience and understanding somewhat near my own, and it is NOT hard to get a validator extension for FF. The end result is the same with respect to the visitors aspect, what would you chose?
I suspect that the only company that'll bother maintaining HTML 5 will be Microsoft, because they'll simply "forget" to update their [insert w/e handles this function in the OS now "feature"] to read XHTML properly (again), and an HTML 5 renderer will be the cheapest thing for them to plug in. Then, claim "innovation" & "progress", as well as the use of new HTML5(tm) "standards". But, this is mere speculation on my part. *grumble*
Simply put, software will be looking at your html in order to parse it and render a page.
A parser written to very strictly interpret xml or xhtml can be smaller and faster. These two attributes allow it to function in a limited environment like a cellphone, pda, tv set-top box, or embedded devices.
A lenient parser, like used in current browsers, tends to be slower and have higher memory requirements.
Lower costs and shorter development time: If you only have to worry about very strict standards compliant pages, many off the shelf very well tested parsers are available (apache has some good ones for example). This *could* result in better quality products.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
"the client-server paradigm" is the future!
:)
I knew that if I held onto that VT100, it would come back in style.
Long live the mainframe
----- If communism is a system where the government owns business, what do you call a system where business owns govern
Ahh, but you can make it work in IE.
See, use this (http://www.xsmiles.org/) as an applet. Then the web browser applet inside of your web browser can show you XHTML docuemnts...
what?
why are your laughing?
----- If communism is a system where the government owns business, what do you call a system where business owns govern
Which is usually reasonably easy to achieve as the entire technical staff can concentrate all their efforts on the server where redundant, high-end hardware can be deployed in a rack, under fully controlled conditions, traffic can be monitored and precautions taken to prevent attacks, etc and so on. None of this is possible in a thick client, distributed environment, especially where clients are running on non-homogeneous hardware and are under control of users with next to no knowledge about the technology.
The trick, of course, is what constitutes the "best fit solution." And there is no one answer to that.
Granted, there are many applications (such as heavy-duty, high-performance 3D graphics) which do not lend themselves to a thin-client scenario. But it is my experience of many, many years that a vast majority of applications in business are served far better by client solutions which are as "thin" as possible.
While HTML5 does have some good ideas, as a whole it is merely a revision of HTML4 (as is a stated goal). Nowhere in the HTML5 spec does it explicitly state whether it conforms to XML syntax; the various references to XML make this even less clear. The most conclusive evidence is near the end of section 1.8, where authoring formats are discussed:
This seens to indicate that HTML5 is not XML compliant. Emphasis mine.
Further, HTML5 still contains these presentational tags:
All of these (and many more) could be supplanted by the XHTML2 role attribute. Who ever said semantics must be limited to the element name? Furthermore, some hold HTML4 elements have been repurposed (such as the i tag). This alone will make compatibility with HTML4 difficult.
Overall, HTML5 seems to me like a collection of minimal changes from HTML4, with specific extensions for specific shortcomings added on. Overall, not very elegant.
The power of web markup lies partly in the abstraction and modularization of its structure. XHTML2 and its siblings (XForms, XPath, XBL2, etc) being XML and capable of standing alone are the logical next step in this.
And to those who complain about XHTML(X) not taking off, it is the solely fault of Microsoft. Since apparently no version of IE will ever support the application/xml+html mime type, the web as a whole has two options: abandon IE, or make itself into an even more confusing, hacked up version of itself which makes developers' lives even more difficult.
Which in turn frees up resources for overall improvement of the client.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
man, where's iGopher on this machine?
m.
I think it is going to be hard to turn people away from plain old HTML. That is what I started on and I know how to do so much in that. So I beleive that many people will continue to use that weather W3C pushes XHTML2.0 or HTML5.0 or whatever new thing they want to say this is what people should use. I for one use HTML in my little websites that I do, and I do just fine. Oh well I guess we shall see what happens when W3C decides to push something someday.
hello
I have it on good authority that the WW3C is about to release a Recommendation to deprecate the glyph "X", consequent to the many complaints about its over-use. It is not yet clear which character will be selected as successor to the ex-X in its role as coolness signifier, but a groundswell of support for the Unicode character 0x129F has begun to manifest itself.
Great men are almost always bad men--Lord Acton's Corollary
Your point is a non-issue. The xsl:output element, and it's method attribute allow you to specify HTML output instead of XML.
MS has already fixed a number of CSS bugs in IE7 and has made it mostly standards compliant, from their blog. The major bugs fixed at the time of posting include:
Dave Shea tested the first beta and gave some information on its conformity. IE Blog has also been posting regular updates with ever-new fixes to very annoying bugs. It seems that the IE team is working with web developers in an unprecedented way.
Embrace and extend TBD.
Where do you want to draw the line at things that are optional? What does a P tag closure mean? The paragraph goes on to the end of the page? To the next P tag, or is that one nested? HTML is supposed to be markup that describes the structure of a document. Make it consistent. Make it unambiguous. Yes sure, these are clear to you, but that's because of your experience with it. That doesn't make it right.
Closing P and IMG tags makes HTML more consistent, and thus easier to learn.
some implementations (though not reference impls) are:
f or_Developers
XHTML1.0
- Mozilla Firefox
- Safari supports it but doesn't advertise in the accepts header
- IE7 but it won't support the mime type "application/xml+xhtml"
XHTML1.1
- Mozilla Firefox 1.5
- Opera
XHMTL2.0
- X-Smiles
http://developer.mozilla.org/en/docs/Firefox_1.5_
http://opera.com/features/
http://www.xsmiles.org/features_xhtml2.html
I don't notice any browsers mentioning support for HTML5. Could you share some information about the current support for HTML5, I think it would be interesting to play with.
XHTML support is growing. Which is better? time will tell.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
Actually, the XP in "Windows XP" is an emoticon.
Escher was the first MC and Giger invented the HR department.
it is just a generation X thing?
"22 astronauts were born in Ohio. What is it about your state that makes people want to flee the Earth?" Stephen Colbert
Isn't XML a pretty good counter-example to your claims?
XHTML 2.0 may be the future, but it's certainly the very distant future. Especially when you consider that not only the current version, but also the upcoming version, of the worlds most popular web browser doesn't support XHMTL 1.1, and ony supports XHTML 1.0 when it is written in an HTML 4 compatible manner.
If I don't put anything here, will anyone recognize me anymore?
No it doesn't. Unless you're expected browser vendors to refuse to render a page without closed tags, and I can assure you they're not about to do that. The parser will still have to cater for unclosed tags, so the only change is the added complexity of having to deal with the closed tags in the first place. It might be nicer if we had a world where we could guarantee that page authors would write standards compliant pages. But the reality is that we don't, and are unlikely to ever have. Thus XHTML adds nothing but unnecessary complexity.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
... the CE website. There are some working groups within that organisation defining just that: new standards for embedded (consumer) devices.
You can still ride a horse and buggy through most cities. Let alone Model Ts.
You can still use a black-and-white TV to watch any television broadcast (save HDTV).
Not that you are necessairily wrong, but you gave really horrible examples, that really are counter-arguments to yourself!
Next week's future!
Build a man a fire, he's warm for one night. Set him on fire, and he's warm for the rest of his life.
I'm amazed at how immature some of my /. friends' friends can be.
My exception safety is -fno-exceptions.
One thing I've noticed in the web design community is that everyone whines and complains about how standards support sucks and we'll never get there, etc, etc. But really all the happened is IE stopped developing their browser for 5 years. Other than that progress is actually reasonable, and with the advent of IE 5 and 5.5 falling to negligible percentages means you can now create standards-based sites with a single box model, using much of CSS 2. IE7 looks to raise the bar considerably.
So yeah, it will probably be 10 years before we can use XHTML 2 for big commercial sites... but that day will come. That's why it's important for top web developers to be looking at the working draft of XHTML 2 to make it as good as possible. I've read through it, and it's an amazingly well thought out spec. Much better than CSS 2 and 3 in my opinion, although those are inherently more difficult to get right.
I wish. Sadly, Microsoft are the only major browser vendor who aren't involved in the development of HTML5 (though they've been invited several times).
*Even worse was orthogonal font-style-size menus which would have been much better mediated by style sheets from the beginning.
-- Our systemic servants do not good masters make.
Here's a good place to start. Firefox has full Gopher support.
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
There really was no war. Sloppy HTML has been the status quo since the very beginning of the web.
In fact it's usually cited the main reason that HTML became popular in the first place.
Whenever I hear the word 'Innovation', I reach for my pistol.
Enforcing case rules saves a few milliseconds for parsers
but makes it difficult for people. C freaks may love it
but it is completely beaten by Html / HTML / html when it
comes to an easy, forgiving language for people to start
learning programming or just getting more out of their computers
New web standards mean nothing until large number of end users upgrade their OS beyond Windows XP or earlier Windows versions.
Look beyond the 2.5 year cycle of over-promoted 'new' technology. Develop solutions that will last 5+ years.
The 10 year lesson from attempting WYSIWYG via HTML/script/browsers is that you have two paths:
- WYSIWYG interactive applications via a compiled binary for your platform (using no web technology)
- Close to WYSIWYG layout with a tiny bit of interactivity via 3+ year old web technology (basic HTML, CSS, small amounts of javascript, old school script generation of web pages using php, perl, etc.).
Other paths, such as heavily interactive ASP, are doomed to 3 year or less upgrade/port from hell scenarios, prohibitively expensive cost to enhance an application.
The future is xhtml 1.x served as application/xhtml+xml, which will fail in non-standards compliant browsers such as IE7 (a bonus in my book).
What do you think of HTML 5?
testing out my trending skills
XHTML is HTML, it's HTML formatted so that it is in the form of any other XML language.
You're thinking of XHTML 1.0, which is in essence HTML 4.01 with the SGML underpinnings replaced with XML. XHTML 2.0, on the other hand, is a "clean break" with the existing HTML tradition.
Is your set-top box going to use an OS with an HTML parser or some sort of browser capabilities built in? If yes, why create additional overhead when all you need is to feed your data to that built-in feature?
Because what is claimed to be an HTML/CSS/ECMAScript parser inside, say, Windows XP Embedded is actually IE 6's Trident, a broken HTML/CSS/ECMAScript parser. You need to add on a separate layout engine such as gecko or khtml if you want to get anywhere near conforming behavior.
i was under the impression that the object needed for ajax to work (xmlhttprequest) was not part of the standard DOM.
True, the X in AJAX stands for XMLHttpRequest, but in the absence of XMLHttpRequest a JavaScript application can fall back on using invisible iframe elements. Besides, XMLHttpRequest will be part of WHATWG's HTML 5 spec.
Also there are certain places you don't want the user to be able to bookmark, like the third page in a five page form they are filling out. The user thinks "Hey I'll just bookmark here and finish this later". Instead you could save the state of everything entered so far and return back to the position they left off at a later point with cookies, and your web app actually knows what's going on.
If you implement cookies and/or server-side state properly, such that http://www.mysite.com/survey/3 always loads the information saved by pages 1 and 2, then bookmarks should still work.
Last night I was watching a show that was only being broadcast in digital HD.
ATSC tuner boxes still output a composite signal, which a black-and-white TV can still read. Is there an analogous proxy that can translate XHTML 2 into HTML 4?
Claiming its a standard does not make it a standard.
Is IE's variation on HTML recognized by ISO or ECMA or IETF in the way that some of the W3C's Recommendations have been? How would you define standard?
As we can observe based on much experience, the _ONLY_ way that this new standard can become ubiquitous and remain a truly device independent standard is for the standards body to build or support and maintain a reference implementation, that defines for everybody exactly what the 'correct' rendering is. Otherwise the inevitable minor variations in interpretation of the standard will lead to problems much like the ones we have now. Just as websites developed by many naive developers using canned tools are unviewable by users who are running on different platforms, XHTML 2.0 developers using canned product XHTML development product 'M' will without realizing it, produce documents and data that are rendered differently using non 'M' platforms.
.wmv media files, and DirectX components, inserted by ... those naive developers ... without thinking. No to mention Flash components that can only be run using a version of Flash that hasn't been released yet for my platform. Etc., etc., ...
A reference implementation that is maintained as part of the standards process provides an irrefutable arbiter of 'correct' implementation, and can be modified as part of the process when such ambiguities, omissions and errors are discovered or extensions are proposed.
I would also hope, perhaps vainly, that the standard includes some language to the effect that any 'embedded' object or program must be easily runnable on all platforms. I for one am tired of websites that use only
Fortunately, most of those sites are ones I'm not interested in - but a friend is dealing with a real estate title insurance company whose website, with a critical database he needs access to, is only accessible using Internet Explorer on Windows - not even the Mac version of IE. I'm sure that the title company web developer doesn't have a clue that some percentage of their user base can't use the site - not even the pull down menus on the main page! Of course, my friend is now considering buying a Windows laptop just for this purpose. This is an example of how some companies can use bugs and poor design as a marketing tool in the right circumstances.
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/