By Kevin Yank

HTML’s Uncertain Future

By Kevin Yank

The following is republished from the Tech Times #152.

What would you change if you were in charge of the next version of HTML? Would you add new tags for things that you need to mark up in your documents? Would you remove tags that you never use? What makes a good HTML tag, and how do you accommodate specific needs that don’t justify adding tags to HTML?

All of these questions have been asked and answered by members of the W3C, but not all of the answers have stood the test of time. In a landmark blog post late last month, W3C Director Tim Berners-Lee acknowledged that XHTML has failed to deliver on the promise of well-formed, extensible markup, mainly because browsers continued to process good old “tag soup” HTML without complaint.

As a result of this, he announced that the W3C would revise its approach to HTML, starting with a new working group to resume development of the long-abandoned HTML specification. This group will add new features to HTML and XHTML in parallel, operating independently from continued efforts to develop the next version of XHTML.

If we can expect one thing to come out of this, it’s a range of new W3C-endorsed HTML tags. And disagreement has already sprung up over just what those tags should be.

On the one hand, the W3C itself has been toiling in obscurity on XHTML 2.0, which makes recommendations that are at turns reasonable, controversial, and strange.

Meanwhile, frustrated parties that tired of the W3C’s insistence on the Web being a medium for documents (to the exclusion of applications) formed the Web Hypertext Application Technology Working Group (WHAT WG) to begin work on a new version of HTML that they call, confusingly, “HTML 5” even though it’s made up of two specifications: Web Applications 1.0 and Web Forms 2.0. These specs contain their own set of recommendations for new HTML tags, some of which have even begun to see adoption in the latest browsers.

Though these issues have been simmering for years, Tim Berners-Lee’s announcement has reignited the conversation. Some influential members of the community have begun to post their wish lists, others have questioned the W3C’s track record of selecting sensible additions to HTML, and still others have rallied against this perceived step backwards, calling for a renewed focus on XHTML.

What isn’t at all clear at this stage is what involvement, if any, the WHAT WG will have with this new effort to develop HTML within the W3C. Berners-Lee’s announcement only made an indirect reference to the group’s work, acknowledging that Web Forms 2.0 would “inform” the W3C’s new work on forms in HTML.

Disappointingly (for the W3C), the WHAT WG has made the first meaningful move following Berners-Lee’s announcement, posting an invitation for web developers to share their ideas, needs, and questions about the future of HTML. Not wanting to get left out of the process, it seems the group is eager to demonstrate its willingness to involve the developer community at large—something the W3C has consistently failed to do.

The idealist in me wonders if the WHAT WG might find a natural fit as the voice of the developer community within the W3C. If the W3C can’t forge a meaningful link with developers in the trenches, maybe the WHAT WG can. This would require funding to pay for W3C membership fees and the time of the people involved, but private donations and contributions from professional organizations might go a long way towards this.

In the end, it will be years before the effects of these announcements are felt in the day-to-day work of developers, but I need to agree with the WHAT WG here: if there is to be a new beginning for HTML, it will require our involvement in the process now, at the beginning, to ensure this isn’t just another false start.

  • Michael Long

    One thing I’d like to see is a client-side “include” tag that would make it possible for sites to syndicate HTML snippets, content, lists, and so on, and for other sites to easily “include” them.

    <include src=””>

    There’s no good way to do this currently. If you use an iframe the content isn’t really part of your page and can’t be styled to match your site.

    You can use JavaScript, if it’s enabled, to “write” to the page or insert items into the DOM, but both methods are problematical and don’t always work, requires the syndicator to convert his content from simple HTML to JS, and again, the content isn’t really part of the page, visible to search engines and spiders.

  • Michael, the main reason that hasn’t been done is that there are security implications with allowing any site to request data from another site on your behalf and then have access to it (say through JavaScript) as if it were part of the requesting site. That said, with appropriate security extensions to the DOM (similar to what’s in place to protect frames), it could work very nicely.

  • hannson

    I don’t have any particular issues with HTML. In a pure HTML document (with no css or js) HTML 4.01 can handle most or everything I do.

    I don’t see the need for a tag, I’d just use server-side includes and eliminate the problem of XSS which so far has been an issue.

    I think we need to take a step back and look at things from a different perspective; We need to look at what new features we could use and then see if they already have a working solution. Because the way I see it it’s not just about HTML or CSS or JS – It’s about all these technologies combined together with or without server-side scripting and to me THAT’S what matters.

    That said; What do we really need in HTML? Or rather, in all of the client-side languages together?

    For web designers I believe existing problems are in inproper CSS and JS implentions rather than the HTML itself.

  • Etnu

    HTML will be mostly replaced by XUL & XAML applications (eventually we’ll get agreement on a standard here, I wager). I don’t think anyone really cares about xhtml anymore.

  • HardCoded

    @Michael: including HTML snippets in that fashion wouldn’t be seen as part of your site by spiders either.

    @Kevin: You say the structural module is ‘reasonable’, but the separator tag just looks like bad old presentational br to me.

  • @HardCoded: From where I’m sitting, <separator> is a semantically meaningful equivalent of <hr>. Many narrative documents (e.g. novels) use a separator to cut between “scenes” or indicate a passage of time. This is a semantic element of the content, and does not imply any particular style or display (as the “horizontal rule” that gives <hr> its name does).

  • Ryan Bates

    I would like to see HTML and CSS revamped together – or perhaps replaced entirely. Although they get the job done, the way the two relate to one another feels awkward. It’s pretty much impossible to build a mildly complex layout without resorting to CSS hacks or HTML tables – both are being used how they weren’t originally intended.

    Perhaps HTML could be replaced completely by XML – no prespecified tags, you just organize the data how you want with custom tags. Then, CSS could be replaced with a more powerful layout language – kind of a mix between current HTML and CSS with a dash of a scripting language. This way it can take the XML data and have complete control on how it is displayed to the user.

    This will never happen though. There is too much momentum behind the current technologies and it takes ages to make significant changes (will CSS 3 ever come?). On the bright side, server-side technologies seem to be moving faster which helps overcome some of the problems with the client-side languages.

  • I would like to see a tag which makes objects on the page blink.

    ….wait a minute

  • Joshua Angnoe

    @Ryan Bates: Isn’t that just what XML and XSLT does?

  • stridox

    I would remove a lot of the unused tags, and definitely no more frames or iframes, using AJAX and/or PHP to take care of that.

    no blinking!

  • Chris Conn

    Ryan Bates said:
    It’s pretty much impossible to build a mildly complex layout without resorting to CSS hacks or HTML tables—both are being used how they weren’t originally intended.

    The funny thing is that I doubt that cars were originially developed for killing people, but they sometimes are used specificially for that. :)

    Most browsers seem to have CSS turned on, but since Firefox allows me to turn it on/off at will (using Chris Pederick’s WebDeveloper add-in), I do. That’s the nice thing. If one wants a web site to be valid for older browsers and newer browsers, they can use a combination of these techniques dependent upon the browser’s agent information. Thus, the web page can be custom built for each web browser as necessary (using appropriate server side scripts of course).
    Imagine what those “poor” text only browsers are like … uuuggghhh, my brain can’t take that. Think about the crap they have to weed through. :-P

  • Joe

    They can’t even organize themselves, how are they going to write a specification for HTML? These guys are idiots. As if Microsoft will even adhere to the spec anyway. There’s nothing wrong with HTML at the moment.

  • hannson

    There’s nothing wrong with HTML at the moment.

    But maybe we need to think ahead. I’d like to see more features but they are more related to the browsers rather than being HTML specific. For example, instead of using AJAX hacks to create a calendar/date drop down (like in Google Calendars) when a user has to type in a date – as a part of forms, it could have it’s own drop down date-tag. Then you could style it like you want via CSS.

    But then again, introducing new tags like these will be dangerous for compatibility.

  • @Etnu

    It’s XAML to win the day, just wait til Microsoft push it with the platform! ;)
    They’ve done it before and now they’ll do it again.

    Bet my career on it.

  • Oyun

    I would remove a lot of the unused tags, and definitely no more frames or iframes, using AJAX and/or PHP to take care of that.

Get the latest in Front-end, once a week, for free.