Archive for the ‘HTML’ Category

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: CSS, HTML, UI/UX, Visual Design

Simplify Responsive Design With ZURB’s ‘Foundation’ Web Toolkit

Foundation 4. Image: Screenshot/Webmonkey.

ZURB has released a major new version of its popular Foundation framework, a web development toolkit for quickly building responsive websites. The new Foundation v4 is a ground-up re-write that sees ZURB taking a mobile-first approach.

Like its erstwhile competitor Bootstrap, Foundation offers a set of HTML and CSS building blocks you can use to quickly develop basic site structure and design — layouts, typography, forms and other common design elements are all available.

There are three ways you can try out Foundation 4. You can download the straight compressed CSS and use that as a starting point for your own customizations. Alternately you can customize your build of Foundation, including only the elements you need; or you can install the SASS version of Foundation and customize it within your SASS code.

If you’re upgrading from Foundation 3 be sure to read through ZURB’s migration guide as the syntax for the grid and other elements has changed.

The real power of Foundation 4 doesn’t really come into play unless you go with the SASS option. Thanks to SASS’s “mixins” concept you can now use the grid tools in Foundation 4 without littering your HTML with the various (purely presentational) grid class names. Using Foundation 4 within your SASS project also makes it dead simple to use only the components you need, for example, you can include the grid mixins, but skip the typography if it’s not to your liking.

Be aware that the new mobile-first approach in Foundation 4 means browsers which don’t support media queries will only get very basic styling for the grid and other UI elements. Yes, that pretty much only affects IE 8. But, if your project needs more robust support for IE 8, there is a modified version of Foundation 4 with support for IE 8 (alternately, you could stick with Foundation 3).

It’s also worth noting that, because Foundation 4 is such a departure from the previous version, ZURB plans to continue supporting Foundation 3 for some time.

If you’ve got questions about Foundation 4, head on over to the official site and check out the documentation. You can also explore the code on GitHub — Foundation is one of the top 20 most-starred projects on the site.

DRM for the Web? Say It Ain’t So

So far it ain’t so, but some form of DRM in HTML is becoming a more likely possibility every day.

The W3C’s HTML Working Group recently decided that a proposal to add DRM to HTML media elements — formally known as the Encrypted Media Extensions proposal — is indeed within its purview and the group will be working on it.

That doesn’t mean that the Encrypted Media Extensions proposal will become a standard as is, but it does up the chances that some sort of DRM system will make its way into HTML.

The Encrypted Media Extensions proposal — which is backed by the likes of Google, Microsoft, Netflix and dozens of other media giants — technically does not add DRM to HTML. Instead it defines a framework for bringing a DRM system, or “protected media content” as the current draft puts it, to the web.

If you think the idea of DRM seems antithetical to the inherently open nature of HTML, you’re not alone. Ian Hickson, former editor of the W3C’s HTML spec, has called the Encrypted Media Extensions proposal “unethical.” Hickson is no longer in charge of the W3C’s HTML spec, but HTML WG member Manu Sporny, has already asked the WG not to publish the first working draft because the “specification does not solve the problem the authors are attempting to solve.”

There are numerous problems with the Encrypted Media Extensions proposal, including the basic fact that, historically, DRM doesn’t work.

Other problems specific to the current draft of the proposal include the fact that it might well be impossible for open source web browsers to implement without relying on closed source components. Then there are the gaping security flaws that would make it trivially easy to defeat the currently defined system.

But Sporny raises a far more ominous objection — that the proposal in its current form does not actually define a DRM system. Instead it proposes a common API, which would most likely lead to a proliferation of DRM plugins. Here’s Sporny’s take:

The EME specification does not specify a DRM scheme in the specification, rather it explains the architecture for a DRM plug-in mechanism. This will lead to plug-in proliferation on the Web. Plugins are something that are detrimental to inter-operability because it is inevitable that the DRM plugin vendors will not be able to support all platforms at all times. So, some people will be able to view content, others will not.

That sounds a lot like the bad old days when you needed Flash, Real Player, Windows Media Player and dozens of other little plugins installed just to watch a video.

That’s a web no user wants to return to.

At the same time there continue to be companies which believe DRM is essential to their bottom line and the web offers no solution. That’s why Flash, Silverlight and other DRM-friendly plugins remain the media players of choice for many content providers.

So the question of DRM on the web boils down to this: should the W3C continue to work on a spec that defines some kind of DRM system or should the interested companies go off and do their own work? For its part the W3C clearly wants to be part of the process, though it remains unclear what, if any, value a standards-based DRM system might have for web users.

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.”