All posts tagged ‘HTML’

File Under: HTML, Web Basics

The Very First Website Returns to the Web

Robert Cailliau’s original WWW logo. Image: CERN.

Twenty years ago today CERN published a statement that made the World Wide Web freely available to everyone. To celebrate that moment in history, CERN is bringing the very first website back to life at its original URL.

If you’d like to see the very first webpage Tim Berners-Lee and the WWW team ever put online, point your browser to http://info.cern.ch/hypertext/WWW/TheProject.html.

For years now that URL has simply redirected to the root info.cern.ch site. But, because we all know cool URIs don’t change, CERN has brought it back to life. Well, sort of anyway. The site has been reconstructed from an archive hosted on the W3C site, so what you’re seeing is a 1992 copy of the first website. Sadly this is, thus far, the earliest copy anyone can find, though the team at CERN is hoping to turn up an older copy.

Be sure to view the source of the first webpage. You’ll find quite a few things about early HTML that have long since changed — like the use of <HEADER> instead of <HEAD> or the complete absence of a root <HTML> tag. There’s also a trace of Berners-Lee’s famous NeXT machine in the <NEXTID N="55"> tag.

CERN has big plans for the original website, starting with bringing the rest of the pages back online. “Then we will look at the first web servers at CERN and see what assets from them we can preserve and share,” writes CERN’s Dan Noyes. “We will also sift through documentation and try to restore machine names and IP addresses to their original state.”

In the mean time, have a look at the web’s original todo list and read more about the project to restore the first website over on Mark Boulton’s blog.

File Under: Browsers, Humor, Visual Design

It’s the End of the ‘Blink’ Tag as We Know It

The end is nigh. Image: Almita Ayon/Flickr.

Mozilla developers are currently debating how to drop support for the much-maligned <blink> tag.

With Opera moving to Google’s new Blink rendering engine, which, despite the name, does not support the blink tag, Mozilla finds itself in the strange position of having the only rendering engine that does in fact parse and display blinking text like it’s 1996.

Originally conceived (and implemented) as a drunken joke, blinking text isn’t just bad usability — usability guru Jakob Nielsen famously called <blink>simply evil” — it can potentially induce seizures. Even if you aren’t prone to seizures, blinking text is downright annoying.

But while few may mourn the passing of the <blink> scourge, really, where would we be without it? Despite never being part of any HTML specification the blink tag managed to take the early web by storm, driven especially by the design prowess of early Geocities homepage creators.

Indeed without <blink> would there have been a Geocities? And without Geocities would there have been a MySpace? And without MySpace would there have been, well, let’s stop there.

Sadly, the end of the blink tag will not mean the end of blinking text on the web. It will ruin this fabulous Twitter Bootstrap theme we’ve had our eye on, but there are still plenty ways to get text to blink — CSS and JavaScript are both, regrettably, up to the task.

So far there’s been little protest about removing <blink> support from Firefox. There’s been some debate as to where or not the CSS 2.1 text-decoration: blink; rule should go with it (yes!), but the tag itself is most likely headed for the dustbin of web history.

File Under: HTML, Web Standards

‘Main’ Element Lands a Starring Role in HTML

Original Image by Christian Haugen/Flickr

HTML5 introduces several new tags that give HTML more semantic meaning. There’s <nav> for navigation elements, <header> for headers, <footer> for footers and now a new element has been added to the HTML draft spec<main>, to wrap around, well, the main content on a page.

As we reported back when the W3C’s HTML Working Group first considered adding it to the list of HTML elements, the primary purpose of the main element is to map the WAI-ARIA landmark role “main” to an HTML element.

Thanks to the hard work of developer Steve Faulkner, who wrote up the proposal for <main> and did much of the hard work convincing the Working Group that it was worth adding to the spec, you can start using the main element today. In fact <main> is already natively supported in nightly builds of Firefox and Chrome.

There’s an ongoing debate as to whether more than one <main> element should be allowed on the page. Currently the W3C’s draft of the spec explicitly prohibits more than one <main> per page, but the WHATWG’s version of the spec is less specific.

It might sound counter-intuitive to have more than one <main> per page, but the argument is that the rest of the new block level tags have no such restrictions. In other words, there can be more than one <header>, more than one <footer> and more than one <nav> so why not more than one <main>? Developer Jeremy Keith has a post on why more than one <main> could be a good idea. [Update: There's also been some discussion on the HTML WG mailing list and a call for supporting data. As Steven Falkner notes in the comments below "the discussion continues, but at this stage there is no evidence that such a change will bring a benefit to users and may well complicate the usage of the feature and dilute its meaning and benefit for users."]

For now we suggest sticking to just one main element per page, which simplifies using <main>. Chances are you have something like <div id="main"> in your code right now. To use the new main element, just rewrite that to be <main role="main">.

The role="main" may seem redundant, and someday it will be, but right now it acts as a polyfill for older web browsers, ensuring that they map the element to accessibility APIs. Older browsers will also need to be told about the element’s block level status with main {display:block;}. HTML5 shiv, a popular way to add support for the new elements to older browsers, has already been updated to support <main>.

File Under: HTML, HTML5, Web Basics

Skip the Lists for a More Accessible Web

Soupe du jour: tags. Image: clogozm/Flickr

Somewhere far in the web’s primordial past it was decided that the best way to mark up a menu in HTML was to use the unordered list element: <ul>. The vast majority of tutorials – if not all – you’ll ever see for creating navigation menus use the familiar list element structure, nesting links inside <li> tags. Menu plugins for WordPress and other popular publishing systems use lists for menus as well. Even the HTML5 spec uses an unordered list in its <nav> element examples.

There is, as CSS-Tricks’ Chris Coyier writes, “no debate” about how menus should be marked up. But HTML5 adds the <nav> element and there’s also a navigation role in WAI-ARIA so should we still be using lists to mark up menus?

Coyier says no. He’s dropped lists from his <nav> elements and instead uses just links and span tags. Coyier cites a talk by Reinhard Stebner, who is blind, and suggests that with most screen readers the far better solution for menus is to use divs and spans for menus.

Be sure to read through Coyier’s post for some more data on why ditching the list might be a good idea and check out Jim Doran’s write up on Stebner’s original talk, which makes a distinction between accessible and usable. That is, a technically “accessible” site might still be a usability nightmare for some users.

However, as Mozilla’s Chris Heilmann points out in the comments of Coyier’s post, the problems lists cause in some screen readers are really a result of the sorry state of screen readers. “Screen readers are damn slow to update and vary immensely between different versions… I gave up a long time ago calling something accessible or not when it works in Jaws.”

Lists for menus have advantages over the div and span route, like some extra elements for styling and the fact that they render as, well, lists even in the absence of CSS.

What do you think? Are lists for menus a legacy workaround we no longer need in the day and age of <nav> and role="navigation"? Or do they still offer enough advantages to keep using for menus?

For his part Coyier says he’s going to keep building list-free menus. “Until I see some solid research that suggests that’s dumb, I’m sticking to it,” he writes. “As always, the best would be to get more information from real screen reader users like Reinhard.”

File Under: HTML5, Web Standards

HTML5 Inches Closer to the Finish Line

Image: Screenshot/Webmonkey.

The W3C has an early Christmas present for web developers: The standards body that oversees the lingua franca of the web has published the complete definition of the HTML5 specification.

HTML5 isn’t an official standard yet, but the move to what the W3C calls “Candidate Recommendation” (CR) status means that the spec is largely stable, features are frozen, and testing can begin. In other words, the W3C is on track to publish the final version of HTML5 by 2014.

While developers targeting modern web browsers are already using HTML5 and many of its accompanying APIs, the move to CR status is nevertheless important because it marks the beginning of the interoperability and testing phase. Testing helps ensure that HTML5 can be implemented compatibly across browsers, servers, authoring tools and the dozens, if not hundreds, of other potential HTML5 clients — think your television, your car, your refrigerator and beyond.

HTML5 will likely be the language of the fabled Internet of Things and the lengthy testing period — the W3C plans for testing to last through 2014 — is designed to make sure that everything in the web of the future plays nicely together.

To go along with HTML5′s progress, the W3C has also published the First Public Working Draft of HTML5′s successor — HTML5.1. Although the W3C has “modularized” much of HTML5 over the years, spinning off sections like Web Workers, WebSockets, Microdata and half a dozen others, which are all now separate specifications at the W3C, the group plans to continue with versioned releases as well.

At the moment there isn’t much to see in the HTML5.1 spec, but look for the HTML5.1 draft to grow as new ideas are proposed.

It’s worth noting that, while the CR publication is generally a good thing, there are still over 100 known bugs and not everyone is happy with the decision to move HTML5 forward. But moving forward it is. After the CR stage is finished, the next step for HTML5 will be “proposed recommendation” status. From there HTML5 will become a final standard — if all goes according to plan — in 2014.