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

Flash

[mattwarden]

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

FALSE

[majest!k]

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

Sounds like one of those stupid True/False questions from my highschool computer class

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.

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.

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.

HTML is fine

[NittanyTuring]

HTML is fine. CSS is great. It's everything inside of that needs cleaning.

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.

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.

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:ATL GURU CHALENGE:

[Vo0k]

Anyone know how to render an html string to an hdc?

echo $thestring | lynx -stdin -dump | dd of=/dev/hdc

Why would you want to do this though?

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.