Slashdot Mirror
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."
"Everything will be in Macromedia Flash soon." - 1999
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.
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.
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.
Tarsnap: Online backups for the truly paranoid
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.
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.
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.
There are 11 types of people in the world: those who can count in binary, and those who can't.
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.
Free Blog submission, find blogs, tools and more at LS Blogs
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.
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.
Anagram("United States of America") == "Dine out, taste a Mac, fries"
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!
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
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.
my blog
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.
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.
Karma: NaN
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.
May Peace Prevail On Earth
"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>
-William Shatner can be neither created nor destroyed.
If you start by asserting a falsehood as an axiom, any conclusion you reach is going to be wrong. In this case:
Sorry, wrong.
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.
I'm old enough to remember when discussions on Slashdot were well informed.