The Future of HTML

An anonymous reader writes "HTML isn't a very good language for making Web pages. However, it has been a very good language for making the Web. This article examines the future of HTML and what it will mean to Web authors, browser and developers. It covers the incremental approach embodied by the WHATWG specifications and the radical cleanup of XHTML proposed by the W3C. Additionally, the author gives an overview of the W3C's new Rich Client Activity."

Comments

its a slow slow process

[BunnyClaws]

I remember them saying HTML was going away 5 years ago.

Re:its a slow slow process

[nicklott]

HTML is never going away. There 3 gazillion sites out there all built with HTML. Which browser is going to be the first to stop supporting HTML?

5 years ago XHTML was going to be a transitional phase on the way to XML. There was actually a small window of opportunity when a switch was possible. A period when most site builders were still programmers and the web was small. Now, however, everyone builds web pages and the web is almost infinite. Inertia now rules.

Of course the browsers don't have to stop supporting HTML, they can just start supporting the new replacement. However, how many years has it taken to get the three major browsers to render any given valid HTML page in the same way? They're close now but it can still be a pain in the arse.

Flash

[mattwarden]

"Everything will be in Macromedia Flash soon." - 1999

Re:Flash

[SnapShot]

I'm going to play devil's advocate here and make the case that Flash is -- or, at least, can be -- a good thing. In fact, there is no reason that a lot of what is currently being implemented as Ajax couldn't be done in a Flash in terms of making a "desktop-like" user interface.

Ignoring the bad flash advertisements -- it's not Flash's fault that it has been co-opted to create "smack the monkey, win an iPod" banners -- an application created by a decent UI engineer in Flash will appear the same (same fonts, same user experience, internationalization, etc..) on any modern browser with the Flash plug in. In particular, Flash can make excellent forms that support all of the bells and whistles that one would expect from a desktop application.

I could be saying the same things about Java Applets, but Sun lost the pissing contest with Microsoft at the same time Macromedia was slipping in under the radar.

There are downsides to Flash, of course. It can be bulky (especially compared to ASCII-based XHTML). You need a plug-in. It's a pain to work with for programmers that are more familiar with structured and pseudo-OO languages like C, Java, and C++ (how the hell do those timelines and stages work anyway?). And, from what I understand, it doesn't currently work with readers for the blind and other ADA requirements. However, Ajax needs JavaScript and a modern browser and applets need the proper JRE version and, finally, standard old HTML 4.01 forms basically suck.

One last plug for Flash, with Flash there is only one point-of-failure on the client. If something's not working go hang out at the Macromedia forums and someone will eventually have a solution or a work-around. If your JavaScript/XHTML/CSS doesn't work there are a lot of potential places where you could have made an error or, more likely, IE simply is not supporting your standards correctly and you'll just ahve to find a work-around.

What?

[Anonymous Coward]

"HTML isn't a very good language for making Web pages."

What? Of course it is. It's perfectly suited for making Web pages. What is this, Wired Magazine?

Everything since HTML has been too complex

[Anonymous Coward]

It hasn't been stated enough. HTML worked (and got up the noses of lots of I.T. people whose power it undermined) because even a child could do it!

The real tragedy has been the unnececesary complexity of what has come since.

A key reason why CSS has taken so long to standardise across browsers is its sheer complexity and contradictions of logic.

Simplicity is the hardest thing to do. W3C needs to return to it.

Re:Everything since HTML has been too complex

[dolphinling]

No.

The only reason "a child could do" HTML is that it doesn't matter if they screw it up, the browser will still display things, and do a pretty good approximation of what they want. With XML, one misplaced & or < kills the whole page, and plenty of people who use it professionally still mess up, especially in dynamic environments, and especially when outside content is being used, like allowing comments.

A child, you'll find, can also do CSS. It takes a small bit of tutorial, and a lot of looking things up or asking around or copying and pasting when they need to do something, but they do it, and it works. This is because CSS has well-defined error handling. The spec says what to do in (nearly) every situation, so all browsers do it the same way, and it's not draconian--one mistake only kills the rule you're working with.

CSS hasn't "standardized across browsers", because the largest-marketshare browser hasn't been updated in 7 years, since around the time CSS 2 first came out. In all modern browsers, all but the most obscure and least tested features of CSS render the same.

Re:Everything since HTML has been too complex

[Fallingcow]

CSS hasn't "standardized across browsers", because the largest-marketshare browser hasn't been updated in 7 years, since around the time CSS 2 first came out. In all modern browsers, all but the most obscure and least tested features of CSS render the same.

It's not just that they havn't updated. They also use a non-standard box model, and since as far as layout is concerned the box model is the most important part of CSS, most non-trivial layouts (and even many trivial ones!) will require hacks to look the same in IE as they do in other browsers.

This, more than the failure to update, is the biggest annoyance for those trying to code standards-compliant CSS, IMO.

Re:Everything since HTML has been too complex

[ArwynH]

The only reason "a child could do" HTML is that it doesn't matter if they screw it up, the browser will still display things, and do a pretty good approximation of what they want. With XML, one misplaced & or > kills the whole page, and plenty of people who use it professionally still mess up, especially in dynamic environments, and especially when outside content is being used, like allowing comments.

And that is bad? One of the reasons alot of websites are so broken is because thier developers didn't realise they had made mistakes. If an error is made in an XML doc it is found quickly because the parser complians, an HTML doc will just be rendered by the browser alot of the time exactly how you expected it, so the error lingers, just to rear it's ugly head at the least expected moment.

Is using XML that much harder? I mean there are only those 4 things to look out for (closing tags, &amp;, &lt; and &gt;). I mean now they have 4 more things to look out for no kid will be able to do it right?

DISCLAMER: yes, you should pass your code through a w3c validator which will find the mistakes for you, but that is not the point. XML strictness makes XHTML more robust, not to mention easier to be read by machines. Less overhead is good you know.

Re:Everything since HTML has been too complex

[killjoe]

Another reason was because you could learn from other people. I don't know how many times I have hit view source to learn how the author did something or another.

HTML was open source and simple source. That's a powerful combination and a lesson waiting to be learned.

HTML = simple.

[ki85squared]

I know that as a novice developer, HTML is the more simple web developing language. I was taught HTML freshman year along with everyone in my grade level, and most people picked it up right away. If schools tried to teach php or something to 14 year olds, I'm not exactly sure they'd quite get it.

History repeats itself..

[js92647]

This isn't different than saying that BASIC will go away.
In my own opinion, I think that, like BASIC, people will make their own variations of HTML to do the job it's made for. Saying "it will go away" is total BS, because really, nothing goes away.

Pascal is how old? What's Object Pascal? That's right, it's Delphi.

Another media exaggaration. Stop with this blatant crap. Same has been said about C/C++ because of .NET and C#, but guess what: I don't see anything happening because you cannot remove a language that does a job that it's actually made for. HTML is simple enough anyone can use it, that's the whole point of having it as a "beginners" web language. It's the lowest common denominator, once again, just like BASIC was (and probably still is). They even rambled on how Java would replace C/C++. Jesus flipping christ.

pick a standard

[badriram]

personally, i would rather them build and pick ONE standard, that works for web pages and applications, and quit changes things as much. Not only does implementation of standards by browsers take a while, most devs cant use it until a significant amount of browsers support.

So quit what you are doing W3C, pick standards you want that are important, pick features, make standard, and FREEZE IT. Dont change dont add, or remove features. Standards are meant to help, if they change more than some propreitary's format, it really does not help anyone at all.

Re:pick a standard

[Eideewt]

I think they're doing all right. It's not possible to anticipate what we'll want to be doing five years from now. Standards need to be replaced. As long as they don't change too often to keep up with change can be a good thing. Especially on the web. Since the web is a content distribution network pages change a lot. It's not much extra work to stay with current standards when you're updating your page all the time anyway.

Re:pick a standard

[dolphinling]

Okay. So design that standard. Seeing as you have prior knowledge of what works well and what doesn't ('cause you've seen the successes and failures of current web languages), we'll give you 10 years--a little less than what current bodies have taken so far.

Only caveat? It has to be good. It has to include any feature there's significant market demand for. (No, you don't get to find out ahead of time what market demand's going to be. That would be cheating.) It has to scale well. It has to be easy to author and easy to implement.

And by your own request, once the time's up you can make no more changes at all.

...or we could just keep on the current track. Revising things as market demand changes, as new things are invented. I think I like that plan better.

As a side note, you're obviously not familiar with CSS's versioning. Anything that worked in CSS 1 worked identically in CSS 2, and anything that worked in CSS 2 will work identically in CSS 3 (with a few exceptions where the spec was bad and the browsers did something different, so the new spec standardized on what browsers already did). Simliarly, WHATWG's Web Forms 2 (and where it makes sense, WA1) are being designed to fall back gracefully to what HTML 4 already does. Anything made for WF2 will still work in an HTML 4 browser (and in IE), just without WF2's special features.

Re:pick a standard

[tomzyk]

What the hell are you talking about?

So quit what you are doing W3C, pick standards you want that are important, pick features, make standard, and FREEZE IT. Dont change dont add, or remove features.

Freeze it ?!? Are you serious? So, you're saying they never should have included background colors or images as part of "the standard" 10 years ago. Or never should have implemented CSS or EMCAScript or the OBJECT tag.... If that's your opinion, maybe we should still be sending our mail via stagecoach and steamboat.

Standards are created to try to have everything compliant, no matter what company implements it. Sometimes you get companies that deviate from the standards because they think they are adding some kind of value to the whole, but that's their choice. [see M$ implementation of the MARQUEE tag. ick.] For the most-part, I think the W3C has been doing an excellent job at designing these standards and making sure to retain backwards-compatibility when possible. But there's no reason to forever lock us into what is currently technologically possible. Web Services would be a complete mess if there were no standards for different companies to agree on how they work.

Re:pick a standard

[squoozer]

I wish the people designing CSS would listen to you. When I tried to convert one of my sites over to using CSS2 I practcally had to give up because the standard 3 column + footer implementation was so difficult. All the solutions I could find were just out and out hacks that relied on either java script or knowing one column was going to be longer than the others etc etc.

I'll use CSS for layout when CSS is fixed.

Re:pick a standard

[Archtech]

"...pick standards you want that are important, pick features, make standard, and FREEZE IT"

Nice idea, with about as much hope of success as the equally good idea of freezing requirements for in-house applications. Developers have had to adopt agile methods because their customers, stakeholders, etc. seemingly won't tolerate freezing requirements. And standards keep churning because vendors - who drive most standards efforts - keep trying to get one up on their competitors.

Besides which, it is true that progress is fastest when there is a seemingly chaotic froth of ever-changing methods. It drives users and developers nuts, costs huge sums of money, forces everyone to "waste" lots of time and attention on learning new stuff all the time... but in the long run, it moves the state of the art on in a hurry. As Churchill said about democracy, it's absolutely the worst system apart from all the others ever tried. We're not smart enough to far plan ahead successfully (i.e. beyond next year).

Re:pick a standard

[onlyjoking]

A breath of fresh air to hear someone buck the trend of paying lip service to CSS and the W3C. CSS for layout has made web page authoring a nightmare for many developers. OK, you can blame IE but there's also the fact that the float model is much harder to implement than what preceded it - tables. After years of wasting whole days getting float-based layouts to render consistently I reverted to tables and am happy. The authors of the CSS specs should learn some simple guidelines - KISS and "If it ain't broke don't replace with something 'semantic' but a pain in the ass to use and likley to waste hours/days of developers' time".

Re:pick a standard

[onlyjoking]

I support the parent. CSS is badly designed and makes easy things difficult for the sake of being semantically correct. It's always been a pain in the ass to develop with and you'll find most developers who want to use their time productively developing dynamic, database-driven sites will still be using tables. That's not because they haven't heard of CSS. It's just that time is money to people other than the CSS/web standards purists and when you're generating rows of data a simple table row is much more efficient than its CSS float 'n div equivalent.

Re:pick a standard

[agraupe]

It wouldn't be that hard if IE supported CSS properly. I made a beautiful site containing a complex CSS layout, but, of course, once I tested it in IE, I had to do it all again without CSS.

Re:pick a standard

[Metasquares]

I think that CSS only makes sense when you combine it with (X)HTML. I frequently hear about people who want to do something very obviously suited to a table (such as lay things out in a 3 column, 5 row grid), but don't want to use a table, because it "combines presentation with semantics". Of course, HTML being a markup language, that makes no sense - presentation is what it's meant to handle. While it is possible to do something like this in CSS, it's way more difficult and tedious than it needs to be, and chances are that your site won't display properly on all browsers (looking at you, IE) if you go that route.

Use CSS where CSS is appropriate. Use HTML where HTML is appropriate. Combine the two to leverage what both give you. You'll get a more effective design in much less time that way.

Re:pick a standard

[Crayon Kid]

Speaking of picking a standard, what these bodies are doing in respect to the future specs of HTML et al reminded me of the recent ICANN talks in Vancouver. Read it, it's a humorous (albeit said) insight into why decision factors can never seem to agree on anything.

Re:pick a standard

[dustinbarbour]

Wah wah wah. "I can't figure out how to get around tables. Tables are so nice and simple. Can't we all just use tables? CSS is hard!"

Ugh... It took me about a month to get over using tables. Now that I don't use them, my code is cleaner, smaller and ten times more elegant. Get over it, man. The W3C is composed of people who live and breathe this stuff. You're just a hack tasked with building some corporate intranet crap (probably a bit simplified, but you get my jist). Leave the thinking to the experts. They tend to know what they're doing.

Clients are becoming too smart

[cperciva]

Yes, there is such a thing as being too smart -- at least if you're a piece of software. These days, if you're a web browser, it isn't good enough to know how to perform HTTP requests and parse HTML; you have to understand images in many different formats, interpret Javascript, keep track of cookies, parse XML, and maybe even execute Java or Flash applets.

So what's the problem? People like having all of these features, right?

The problem is that there is a hidden cost to having all of these features: Security, or rather a lack thereof. Remember that every line of code is a potential security flaw; and then think about the fact that FireFox is about 15x larger than lynx. Unsurprisingly, there aren't many security flaws in lynx.

I'm not suggesting that we should never add new features. Adding support for embedded images, for example, was a pretty significant step forward for the web. However, every time somebody steps forward and says "look at this new feature which I've added to the web browser and all the cool things I can do with it", our first questions should be "how much code does it take?" and "how easily can it be done securely?" -- and if the answers are "lots" and "umm, I haven't thought about that", then it's probably not a worthwhile feature, regardless of the amazing tricks it can be used to perform.

Re:It wont ever leave.

[Mr. Hankey]

I suppose one might have said the same thing about DOS 15 years ago. I even remember an article in a PC magazine back then where a priest condemned the GUI, stating that "Icons belong in the church, not in the computer." Times have changed since then. I'm sure something better and probably even easier than HTML will come along and take over eventually, we just don't know when or what it is yet.

Re:FALSE

[jurt1235]

Sounds like Microsoft to me.
Microsoft has been saying this for years. They invented AJAX as an extention to speed up HTML since it is just not fast enough in their opinion.

I think however that a XML based document style, what HTML in essence is, is extremely easy to use with even the simplest tools. Any other document with that much layout options, needs extended editors (unless you know postscript out of your head, so you can do it in postscript (-: )

All this dynamic stuff requires a server

[Animats]

Web pages that won't run without a connection to the server are limited. They can't be archived. They can't be cached effectively. They can't be viewed offline. They often cannot be printed.

Much of this "dynamic content" is annoying advertising, anyway. So it's going to have to be blocked, like popups and Flash.

Worse, programmability in the browser means advertisers running their software on your machine. You just know they'll try adware and spyware if it can possibly be implemented. Keeping Java and Javascript in their cage is tough enough already.

Web Forms 2.0, though, is a good idea. We should have had more declarative validation years ago. Declarative forms are good - the browser may be able to fill in fields.

HTML and CSS

[PresidentEnder]

I'm a first year Computer Science student. In high school, I took a year of HTML; it's amazing what you can do with it. If you include CSS (our book did) and Server Side Includes (it didn't), you can make extremely streamlined and beautiful pages. HTML along the lines of using h1 through h6 is foolish, but I've (literally) never seen anyone use any heading smaller than h2. Just because a feature exists doesn't mean you have to use it. PHP, Javascript and the like are easier to break, and harder to interpret; for a small business without a dedicated web programmer or a programmer without a lot of time, HTML is *the* way to go. The best web pages I've seen have been courtesy of a text editor and photoshop, using HTML and CSS only. HTML is simply not going away, any more than times new roman is.

HTML is not the problem.

[HoneyBunchesOfGoats]

"HTML isn't a very good language for making Web pages."

Like most languages (including spoken ones), it's not the language itself which is the problem, but rather it is the inability of people to use it correctly.

the future

[lsblogs]

All very nice, but lets face it, the big players cant even get browsers to work in a standardised manner for simpler things like CSS and HTML. God help us with more complex features... HTML will be here for a long time, new things will come out, and will be used, but html itself wont disapear for a long long time. There are far to many webpages out there that cant be updated, or wont be updated for it to just disapear. Not everyone will be able to use the newer, more complex features, so in effect, the rich will get richer, and the poor, poorer - as in general the ones with the money will have the ability to hire people to upgrade, or buy tools to do it themselves. Plus where do they draw the line, its great new features may be on the way, but most people know that software is usually out of date by the time the programmer has nearly finnished writing it.... Does this mean they will keep re-inventing the wheel and forcing people to redo sites each year to keep up with newer gadgets and gizmos? (saying that, thats pretty much the current state of things anyway) Then there will be all the extra processing power that will be required just to display what should really be a simple page.. I will probably have to upgrade my pc just to view the next gen websites.

Round 2

[umbrellasd]

I work with Javascript every day to achieve advanced web application functionality. It is object-oriented now, but I'm not much for alert messages as my preferred method of debugging. It does not have to be that way, true. But I think more than anything that the reason I really do not enjoy using Javascript is that tools support is very limited.

Even now, we are still in the world of dueling standards on the web where what would really be best is a single standard. I write JScript for my Internet Explorer web applications. Javascript for non-Microsoft browsers. I want a single language, and I want a single development environment that can give me "Intellisense" (object delving and code completion), and dynamic help that is linked against Javascript/JScript reference material. I want that environment to target all browser platforms that comply with a standard, and I really do not want people to continue disagreeing on the standard because then tool support will lag and my work is made more difficult.

When I glanced through the referenced article, I was rolling my eyes, because here again you have two answers to similar problems, each with support from different camps and the result will probably be more browser compatibility work for every developer.

After many years, you get really tired of people coming up with "that one extra feature" or "that totally amazing completely different way to solve the same problem". Each EMCAScript engine on each browser adheres to a slightly different specification. Lovely. CSS is exactly the same. There you have a single set of specifications, but you still have people interpreting things in vastly different ways and Internet Explorer still (a few years) has trouble with something as simple as bottom:0.

Anyway. I think the real opportunities in the future are for much better tools and a much stronger effort to reach standards agreement and compliance. I could care less which of the two standards described in the article actually becomes mainstream. They are all smart people. I'm quite certain either standard will get us great benefits and move us along nicely. Pick one and run with it. That would be nice. But, no. Everyone wants "their approach" to be the one because they are so certain it is "infinitely better" than what the other 30 brilliant guys came up with.

That said, I doubt we are going to see convergence. The things that really converge and become solid standards are the things that have been around so long and are used so ubiquitously, no one finds it possible or worthwhile to make changes because there are lower fruit to pick on the "It's new, New, NEW!" tree. Those two standards in the article will likely not converge for 5 years, minimum.

give it a rest!

[penguin-collective]

We have barely scratched the surface of what is possible with the current generations of HTML, JavaScript, and SVG. The two areas where a little bit of standardization would be nice would be in support for drag-and-drop (for simplifying uploads) and rich text editing. Other than that, these people should just give it a rest and let us digest the current set of technologies.

Re:JavaScript

[Vo0k]

The problem is implementation of Javascript/DOM. Every browser does this differently. Some in a broken way.
And Javascript still lacks access to some essential stuff. Try grabbing and processing the binary data of a linked image. Try to make a program run continuously without hogging 100% the CPU and without kludges like calling itself within given timeout (and losing all the local context in the meantime). sched_yield() in js anyone? fork? use strict; ? kill? At best you find ugly kludges. The language seems like it was still in early development phase, far pre-alpha with specs still in early drafts.

html isn't going anywhere

[circletimessquare]

it's like ipv6: obviously superior to what we got, but too complicted or costly to implement

there isn't a lot of overhead required to write an html webpage, there is no educational or infrastructure barrier to entry

that defines the success of html

meanwhile, all the replacement specs i see trotted out all over the place are often far more complicated. and i recognize that this is by design, not a failure to grasp the concept of simplicity. they are so complicated because they are trying to do so many things, these more sophisiticed protocols and doc templates. well then that's the error: setting your sites too high. people don't want more options, they just want to do something

this megalomaniacal approach: "do everything" is not a superior way to design a spec. like electronics makers putting television on cellphones or ipods now. this is so stupid, and doomed to failure. christ, people just want to make phone calls

so what new webservices or protocols will be successful? THE SIMPLE ONES. i even have an example: rss. simple and straightforward. a raft of services similar to rss aren't nearly as successful. too complicated

KISS, people, KISS

never forget the KISS principle: Keep It Simple, Stupid!

3D Graphics

[hayriye]

From the article:

And why, in this era of 3D-accelerated graphics cards and sophisticated user interfaces, are Web pages limited to clunky text boxes and radio buttons for user input?

Why do we need sophisticated user interfaces? The existing controls are easy and universally understood.

Re:Web Forms 2.0

[panaceaa]

As a web developer, I find that the advantage of Web Forms 2.0 is not field validation, but the formal declaration of field types so that browsers can assist users to enter proper data without getting confused. For example, the 'email' input type can offer to bring up the user's address book, and can provide context-based feedback of errors on manually typed addresses. If browsers truly adopted Web Forms 2.0, web developers could stop worrying about writing form validation Javascript while providing a more standardized interface for entering strongly-typed data.

everything must go!

[5plicer]

let's just deprecate all tag except div :p

HTML is good

[mymaxx]

HTML is good for making web pages, but bad for web apps. For that you have DHTML, CSS, JavaScript, AJAX, etc...

Why use XHTML when IE cannot parse it?

[perkr]

As long as IE doesn't understand application/xhtml+xml I see no reason to switch.

Read more about it here: Sending XHTML as text/html Considered Harmful.

Re:Web Forms 2.0

[tonydiesel]

You're missing the point. Of course you will still have to do server side validation (at least, you should). The advantage here is that you provide a better user experience. The user can click the "Submit" button (or whatever) and instantly know if the entered data is valid. Sure, you can fake your way around it, but it isn't designed to prevent script kiddies from doing their stuff, its to tell Grandpa that he mistyped when he entered his email address.

Re:No it is not.

[SolitaryMan]

It's everything inside of <script></script> that needs cleaning.

It is so dirty because HTML is not fine in the first place. Many JS on the page usually just compensates for HTML incapability of providing good widget set and rich controls. I don't like JS, and I think that controls such as trees, popups etc. is a MUST for web markup.

Re:It wont ever leave.

[Mr. Hankey]

That (the relative difficulty) is part of why the current set of proposed technologies aren't going to replace HTML completely. Once someone comes up with a sane web-friendly document description language without the rendering ambiguity of HTML, that is also as easy to write for a human and efficient to parse, then we'll have a good replacement for HTML. As long as it's unencumbered by patents, of course. I'm sure it will happen, I just don't know when.

Re:JavaScript

[EntropyEngine]

I loathe having to use JavaScript and usually work to avoid having to us it at all.

In my experience, more often than not, JavaScript is a hinderance and is the cause of more problems than it solves...

Improvements are eventually going to come...

[Regnard]

My take on this matter is that HTML is good up to until a certain point (e.g. creating a richer user experience). As a standard, I'd take some of the tweaks the working groups are proposing (e.g. Web Forms, Web Applications) but I'd avoid too complex additions (e.g. canvas).

I've taught web programming and HTML is really one of the "bright spots" that students appreciate and relatively easy to grasp. I'd hate to see some additions that would muddle the simplicity of HTML. So in the end, improvements are welcome, but avoid "improving" too much.

HTML is dead... long live HTML!

[shotgunefx]

"HTML isn't a very good language for making Web pages."

This is based on what? That it's not postscript or flash? Granted there are improvments that could be made, but by and large, it works wonderfully. A simple and universal UI and a markup that almost anyone can learn.

How is bloating it to do everything you could ever want going to improve things?

Why do I need to be able to use it as an etch-a-sketch? You want to be able to draw or run around a maze? Get a plugin. Now if they want to standardize plugins, that's another issue.

Forms could use some work, but personally, I think the limited control of layout is a big plus. Almost anyone who has filled out a form, can figure out any other form. Client side validation? What's the point? Still need to validate server side. Maybe it saves a trip, but that is probably negated by all the extra markup that will be coming over the pipe.

I like the direction google is taking things. I think incorporating a few smaller changes and we can get most of what's desirable.

<RANT>
And author control over auto-completion of form elements? Maybe an author hint, but control? Um, no. Fuck off. For some reason, this somewhat benign point really vexes me. Not to go off on too much of a Dennis Leary tangent, but goddamn it, I'm getting sick of computers and devices doing what they feel like and not what I tell them to. Like power buttons. I want a power button that shuts off that fucking power, not suggests that it should, if it feels it's appropriate. I press open on a drive tray, it better damn open.
</RANT>

Wrong premise, wrong answer

[Simon Brooke]

If you start by asserting a falsehood as an axiom, any conclusion you reach is going to be wrong. In this case:

HTML isn't a very good language for making Web pages.

Sorry, wrong.

• HTML is a relatively compact, low overhead markup. An HTML page is much more compact than, for example, a PDF or a Word file containing exactly the same data. The consequence of this is it makes good use of low bandwidth links, without needing compression - a benefit I'll return to later.
• HTML leverages SGML's experience in dealing with multiple character sets, scanning directions, etc; it's therefore effective as a universal markup, not limited to any particular natural language or culture.
• HTML separates data from presentation, allowing the same content to be made available on a wide range of devices, and to people with a wide range of special needs.
• HTML is extremely simple to parse; the parser can be extremely lightweight. This in conjunction with the fact that the data representation is compact and doesn't need decompression means that HTML can easily be rendered on extremely low powered devices.
• HTML's forms extension is admittedly a hack. But it's a successful hack because it's a good hack - it allows system designers to make use of ubiquitous low cost clients. There is a tradeoff between simplicity and functionality and admittedly HTML forms err on the side of simplicity; some more input types would be beneficial. But the XForms proposal is woefully over complex and will fail to be widely deployed for that reason.
• Finally, HTML is universal and ubiquitous. A huge range of devices out there can accept well formed HTML and render it usefully; there's no need to worry about whether this or that extension or plugin is available on the client.

In summary, HTML has been so successful largely because it's an extremely good language for writing Web pages. It's become universal and ubiquitous because it's simple, flexible and lightweight. Admittedly HTML is weak in the area of representing special technical formatting such as mathematical formulae; there is a place for such things as MathML et al.

Yes, there are a huge number of proposals to give us more prolix, more byzantine languages in which to write Web pages. They are going to have to co-exist in a darwinian environment with HTML, and outcompete it. They won't, in my opinion, succeed. In ten, or twenty, years time there will be devices out there which will render formats we haven't yet imagined, and there will be a fragmented web of pages which can only be read on this or that specialised device. But there will still be a web of plain old vanilla flavoured [X]HTML, because that will be the lingua franca that every device can use.

Validation results: failure

[Antiocheian]

Oh. Another article about the future of HTML specifications that fails to validate:

http://www.htmlhelp.org/cgi-bin/validate.cgi?url=h ttp%3A%2F%2Fwww-128.ibm.com%2Fdeveloperworks%2Flib rary%2Fx-futhtml1%2F%3Fca%3Ddgr-lnxw01FutureHTML&w arnings=yes

Enough said.

Don't take this article seriously. Instead of pursuing 3D appliances in web pages your time will much better be invested in playing a 3D game.

Yeah, I've been saying it for months.

[Hosiah]

HTML is worse than bad; it needs to be buried. It looks like whoever wrote it must have been swigging absinthe while taking a case-by-case approach and writing *whatever* popped into their mind at the moment. "Um...how to make text bigger? h1,h2,h3,h4,...but we'll use "big" tags here. And change the font size there. And make it so you can also specify size in percent, pixels, *and* points, so no two pages will handle sizing of text the same way. Now, what else can I screw up?"

CSS, once I learned it (getting the excellent http://www.nvu.com/nvu helped), struck me as the way the web should have been designed to start with. At least all the style twiddling is done in one place. At least I use just *one* command to do one thing. Never mind "50 creative ways to do it."; just give me ONE way: the RIGHT way!

As for TFA, I love canvas and can't wait to start working with it. It looks like the kind of thing javascript was meant to do 20 years ago when everybody started trying to gangbang it. But javascript itself...I would still like to see java and css integrate themselves closer. In fact (as I've said before in these very hallowed halls) I wish for ONE language that does EVERYTHING with one unified syntax - not using this fourth of a language to write this module, and this tenth of a language to write that section. How about making a *whole* web language that can stand on it's own for a change? Since when is trying to knit five baby languages together to make one little page a good idea, when I only needed one language to write the whole operating system and the web browser on?

Last but not least, forget the backward compatibility. These days, my philosophy is: "Use the brightest and best technology that pleases me at the time, and if it's not compatible, tell 'em to get a REAL browser." I'm sick and tired of trying to build a page that will accomodate *any* Rube Goldberg contraption that *any* moron whacks together and calls a web browser. Do we make our freeways to accomodate ruk-tuks, Big Wheel tricycles, and pack elephants? Come to that, are the roads in a Tibetan temple designed to accomodate Mac trucks and American Monster SUVs? The time has come to say: "If you insist on traveling the world using only a Conestoga, there are certain places you just won't be able to go. We can't pave the ocean just for you."

Re:Obvious

[juiceCake]

And how intuitive is using a table for layout? Tables are for tabular data. However, many of us are used to using them and going through elaborate methods like using spacer gifs, row spans and column spans, setting alignment here and there, using sliced up graphics (now that's super duper intuitive), etc.

There are definitely parts of CSS that aren't intuitive, just as with HTML. Both are in evolution, and guess what, the bugs and methods are ironed out.

Now that I'm used to CSS I'd never go back. I had to make a layout in a table for a lesson deprecated production methods. It was unfathomnably painful, counter-intuitive, limited in options, and clunky.

HTML is for markup, not page layout

[egarland]

HTML was originally desigend to allow for marking the different types of text as the type they were so the USER could pick how they were displayed. This is a code snippet, this should be fixed width, this is preformated text, etc.

This delegation of display style was and is a great idea empowering browsers to make things look good and users to pick the fonts they liked the best on "their" machines. It has since been undemined by a flood of additions giving authors the ablity to choose font names for text which most web sites employ (not slashdot though.. thanks guys!) set widths of pages (your new layout sucks arstechnica), pop up new windows without address bars (who was the moron at netscape that decided that was a good idea?) and other fine grained page-layout style things added since.

HTML was and is an excellent tool for making web sites. It scales all the way from <b>HI</b> to google. It's because it was so very very good at doing what it does that the web is now in the position of global general purpose use and these kids are whining about how hard it is.

HTML will be around for a long time

[recharged95]

HTML isn't a very good language for "making Web pages"

The above notion is inaccurate. HTML was very good in making web pages, especially back in 1995, but the hardware and requirements have evolved, but HTML has not. More accuracy, it should be that HTML isn't a good syntax for making web applications.