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

Re:JavaScript

[Anonymous Coward]

Javascript IS an object-oriented language. And fully-featured, except for things like lack of sockets.

Re:What?

[Anonymous Coward]

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

No.. Actually, Wired doesn't have ad's -this- useless....ok yeah they do. still doesn't make it right, tho.

Re:JavaScript

[DrEasy]

Not only it's object-oriented, it's actually a pretty flexible kind of OO. You can do prototype-based OO out of the box, or class-based with a bit of tweaking.

Re:JavaScript

[starwed]

Javascript 2 is part of mozilla's roadmap, actually. ^_^ Check out some of Brendan Eich's blog entries.

Re:Flash

[Drakonite]

Unfortunately I run into numerous companies that decide I have to navigate their flash filled webpage in order to get to their support page, and yes, had I known that to begin with I would have thought twice about buying their products.

I'm an avid gamer and I like to watch the occasional movie as well, lo and behold it seems if I want to get info about a game or movie I have to navigate their stupid flash pages.

God forbid I'd want to go out to see a movie and decide to check listings online, the website for the local theatres (all own by one company btw, so only once place to check) doesn't work correctly without flash.

Thats just the sites that came to mind while reading your post. Sad part is, almost none of these cases (with the odd exception of the occasional game or movie site, though the same exceptions tend to be the ones with html only versions as well) are an "enhanced experience" because of flash, most often they are worse.

Just to play symantics a bit, no, I do not want flash for any of this, however I need flash to access these resources until someone takes a hammer to the heads of those web developers that think flash is the answer to everything. On second thought, I get the feeling a lot of them took a hammer to the head already...

I use H1 through H6

[Christian Engstrom]

HTML along the lines of using h1 through h6 is foolish, but I've (literally) never seen anyone use any heading smaller than h2.

I use all 6 heading sizes in the documentation I am writing for my open source project, and I don't think it looks that bad. Sure, I could have used some complicated/sophisticated publishing system that did all the layout as flash animations or whatever, but I think it's an advantage to be able to write the documentation as straight-forward text files that can be included in the tar-ball and that anyone can read with any browser.

Different headings are quite useful when you're trying to make documentation readable, so I really don't understand what the author of the article (and possibly you) have against them.

CSS

[zoeblade]

CSS took the totally simple CENTER tag and "improved" it with kludgy auto-width margins that don't work in IE5/Win.

text-align: center;

What CSS does is seperate style from actual content, and also seperate style intended for monitors from, say, style intended for a printed copy of the page. Once you start to think in this mindset, it makes a lot more sense than using HTML to define both the content and style in the same place, all mixed in together.

It can also save a lot of time. For example, with CSS you can specify that every h1 element should be centered with a single line of code, which is much quicker than specifying the alignment of every single h1 element by hand in every page, one at a time.

That and it saves a lot of bandwidth, as each page can link to the same CSS file.

Re:CSS

[loquacious d]

.foo { display: table-cell; vertical-align: center; }

Not sure about IE compatibility. But I'd call that IE's fault.

Re:CSS

[gallen1234]

I think you missed the gp's point. He wants to center a container object, not text or the text within a container. text-align is a text property. If you apply it to a container object the results won't be what you needed. Try an example with and see what you get for your trouble. The output won't be a table centered horizontally on the page.

Re:CSS

[zoeblade]

I think you missed the gp's point. He wants to center a container object, not text or the text within a container. text-align is a text property.

While margin: 0 auto; is the correct way of doing this, IE demands you use text-align anyway, even though it's intended for text (this is IE's fault, not CSS's). Use text-align: center; on the element that the one you want to center is inside of, and then text-align: left; to counteract it again for the element itself.

Which is one of the many reasons why I don't like Internet Explorer.

Re:Packaged HTML

[vidarh]

Except that multiple webpages often share content and rely on caching to prevent repeated requests, HTTP 1.1 has allowed multiple requests to go over the same connection for ages, clients use multiple connections mainly because they specifically DON'T want users to have to wait until the whole page is loaded before starting to see other content appear, a significant portion of pages today are dynamically generated - in which case a packaging system like you suggest would actually add load to the server -, and it already IS possible to compress pages if the client sents the appropriate Accept header.

And what about clients that don't want or don't need the flash, javascript, css files, images or other things you think your page "depends on"?

What you are suggesting is a poor solution to something that isn't a real problem that would likely do more harm than good.

Re:HTML isn't ... very good ... for making Web pag

[VitaminB52]

There's a big difference between putting a document on screen for someone to read and marking it up for semantic content: there's more cruft in HTML than is required for the former and nothing to assist with the latter.

Maybe you shouldn't judge HTML for being (un)able to do the things it is nowadays used for, but for it's ability to do the things it was originally designed for.
If a language fails for a task within it's design limits, then the language (implementation) is bad/broken; if said language fails at a task that's beyond it's design limits, then IMHO the language is OK and you should use another language for the given task.

Re:pick a standard

[Transmogrify_UK]

If time is money, then the "most developers" you're talking about would be absolutely foolish to use tables for layout. I find it amazing how people continue make these uninformed comments on /. Most web developers I've worked with/spoken to actually DO use CSS and not tables based designs. It's not about abandoning tables entirely, it's about using tables correctly.

Faulty Assumptions

[Jerk City Troll]

One faulty assumption I picked out of that read was the mention of header tags.

Why, for instance, does HTML have headings H1 through H6? Who ever seriously used a six-level-deep heading hierarchy?

Well, I have. My company makes a web application where we have some heavily nested data (say, for example, a person nested within another person who is their relative, for any number of levels). Because I try to keep all my mark-up as semantic as possible, I need deeply nested header tags. I can also think of all sorts of technical writing that might use deeper than six levels of section hierarchy.

It is useless to state assumptions which assume a usage will not be necessary. Instead, make as few assumptions as posisble then handle general case which applies as well to everybody’s typical situation but is easy to extend to edge cases. That’s a basic principle anybody in technology should follow. And, in fact, this is precisely what XHTML 2.0 does. It has a "header" tag which is not indexed and styled by CSS which checks for how many ancestor headers there are.

Re:Round 2

[roman_mir]

Just to make life easier, use FF with dev-tools (when installing select to install with dev-tools,) this gives you the DOM inspector. For JS itself install Venkman

Re:JavaScript

[Malc]

There's no reason to lose local context when you do an asynchronous call. JavaScript has closures. The biggest problem with JavaScript is I don't think there is a way to synchronise threads or implement mutexts. Somebody please educate me if this is possible! And BTW, I think I read somewhere that there is a memory leak in IE with closures, but mostly I think they're worthwhile.

I think that JavaScript/DOM implementations have improved somewhat. Unfortunately we require backwards compatibility at times. There are still some deficiencies - native XPath support to help with XML would be nice.

I think the following (untested, I made it up right here) should demonstrate maintaining local context. Here we show an alert asynchronously via setTimeout. When the callback occurs, I use both a local variable (obj), and thus the object's member variable (m_str). It looks rather cumbersome, especially with the inner function. But it works. This is what I do with the callback from XMLHTTPRequest objects so that I keep access to my member variables, etc.

function myClass()
{
    this.m_str = "poo";
 
    this.doAlert = function doAlert()
    {
        alert(this.m_str);
    }
 
    this.func1 = var function func1()
    {
        var obj = this;
        var fn = function doAlert()
        {
// Use a local variable from the closure. This
// restores the this point so that it can be used
// in the function that we call
            obj.doAlert()
        }
 
        setTime(fn, 10000);
    }
}
 
var myObj = new myClass;
myClass.func1();

Re:Flash

[Anonymous Coward]

do not click the link in the parent
it is not safe for work

Re:pick a standard

[soliptic]

I have a few books on CSS but no one actually talks about what CSS can really actually do. It's largely a matter of hit/miss to see what CSS tags have any effect on which elements. While I like the concept, the level of documentation on CSS is beyond pathetic.

CSS books may be pathetic, but they're also redundant, because the level of CSS documentation on the web is truly awesome.

http://www.dezwozhere.com/links.html

I have yet to come across a CSS question that I couldn't answer within 3 clicks of this page. HTH.

Re:pick a standard

[RedSteve]

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.

Strawman. If you truly are rendering out tabular data, you SHOULD be using tables. No CSS advocate would tell you otherwise.

If, however, you are rendering a discrete section of code, yes, you should be encapsulating it with a <div class="foo" and </div> pair of tags and letting a page designer worry about how it renders on the page.

Any time our developers try to tell me that non-tabular output has to be done in tables, I press them and ask them why. Usually it's because they don't understand how to use divs correctly.

Re:Yeah, I've been saying it for months.

[BZ]

> "Um...how to make text bigger? h1,h2,h3,h4,...
> but we'll use "big" tags here.

, etc are not "make text bigger" -- they're "This is a heading". HTML as originally designed didn't have a concept of "make text bigger" at all -- the assumption was that HTML would have logical markup (headings, paragraphs, quotes, etc) and that the renderer would choose the best way to actually present that markup.

Then browser makers started introducing all sorts of presentational markup ( is an example, as are , etc).