Webmonkey » HTML

The Very First Website Returns to the Web

Scott Gilbertson — Tue, 30 Apr 2013 13:09:54 +0000

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

instead of or the complete absence of a root tag. There’s also a trace of Berners-Lee’s famous NeXT machine in the 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.

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

Scott Gilbertson — Thu, 07 Mar 2013 14:39:36 +0000

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

Scott Gilbertson — Tue, 12 Feb 2013 16:20:13 +0000

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.

‘Main’ Element Lands a Starring Role in HTML

Scott Gilbertson — Mon, 04 Feb 2013 16:03:41 +0000

Original Image by Christian Haugen/Flickr

HTML5 introduces several new tags that give HTML more semantic meaning. There’s

for navigation elements,

for headers,

for footers and now a new element has been added to the HTML draft spec —

, 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

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

is already natively supported in nightly builds of Firefox and Chrome.

There’s an ongoing debate as to whether more than one

element should be allowed on the page. Currently the W3C’s draft of the spec explicitly prohibits more than one

per page, but the WHATWG’s version of the spec is less specific.

It might sound counter-intuitive to have more than one

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

, more than one

and more than one

so why not more than one

? Developer Jeremy Keith has a post on why more than one

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

. Chances are you have something like

in your code right now. To use the new main element, just rewrite that to be

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

Skip the Lists for a More Accessible Web

Scott Gilbertson — Wed, 30 Jan 2013 19:45:36 +0000

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:

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
element examples.

There is, as CSS-Tricks’ Chris Coyier writes, “no debate” about how menus should be marked up. But HTML5 adds the
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
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
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.”

Proposed ‘Main’ Element Would Help Your HTML Get to the Point

Scott Gilbertson — Tue, 11 Dec 2012 19:36:28 +0000

Photo: Horia Varlan/Flickr

HTML5 has several new tags designed to make HTML more semantic — there’s

for navigation elements,

for headers,

for footers and now there just might be

to wrap around, well, the main content on a page.

The W3C’s HTML Working Group, which is charged with creating HTML, has accepted a proposal to add a draft specification for the

tag to HTML. The actual HTML spec hasn’t been updated yet, but you can read through the earlier, unofficial

docs.

The proposal has been around for some time, but former W3C HTML editor Ian Hickson opposed it on the grounds that its use case was too close to

. Since then the mailing list discussion has turned up enough supporters and use cases for a

element — including for a “reader” mode like that offered by Apple’s Safari, or to exclude non-main content from a search — that it looks like it will make the cut (Update: check out this W3C wiki page for more use cases).

It’s unlikely that

will make it into HTML5, which is about to reach the stable stage after which no new elements can be added, but it could make it to HTML 5.1, due to be finalized by 2016.

As Mozilla WHAT WG member Henri Sivonen writes on that group’s mailing list, “I think it was unfortunate that didn’t make it to the same round of added elements as

and

… but it’s not too late to add it — browsers update faster than they used to.”

The purpose behind

is to give web authors a more semantic way to indicate a page’s main content. In many ways it mirrors what WAI-ARIA does with the “main” role.

In fact, because a

element would more or less bring the semantic power of ARIA’s role=main to HTML proper, you can get most of the benefits of the proposed

tag today, by just adding the “main” role to your primary content wrapper, something like:


    
        Top 10 Linkbait Headlines for Hacker News
        December 11th, 2012
        ... etc 
    
    
        
            Comment Title
            Comment body

In this bit of pseudocode the main role tells the user agent — a web browser, search engine spider, etc. — that the primary content of the page is the article and the ensuing discussion in the comments.

So if you can do it already with ARIA why add

? The simple truth is that hardly any sites use ARIA roles. Because

is simple to use, web developers are more likely to use it and use it correctly (try searching for tutorials on how and when to use

and

to see the opposite effect), which in turn makes it a more reliable indicator for search engine spiders.

GitHub’s Tips for Building Faster Websites

Scott Gilbertson — Mon, 10 Dec 2012 19:24:38 +0000

Social code hosting service GitHub isn’t just a free, easy way to host and share your code; it’s also a huge CSS and HTML testing ground with experience writing a fast, scalable code.

So what has GitHub learned from running a hugely successful site? That surprisingly small changes to both HTML and CSS can have a huge impact on performance.

GitHub’s Jon Rohan gave a talk about some of the service’s performance problems and solutions at the CSS Dev Conference in Honolulu earlier this year. (The slides are available on Speaker Deck.) The whole video is worth watching, but the key takeaway is that the right small changes in your code can have a huge impact on performance.

Many of Rohan’s suggestions for faster CSS will be familiar to anyone who’s used YSlow and other performance tools — get rid of unnecessary tag identifiers in your CSS, i.e., div.menu becomes just .menu, eliminate ancestors where possible and avoid chaining your CSS selectors.

On the HTML side — and Rohan says it’s here that GitHub really saw performance improvements — he suggests reducing the amount of matched HTML on the page. That is, look at your pages in a profiler, figure out which tags are being matched and look for ways to simplify the layout to avoid bottlenecks. Among the more depressing things Rohan presents is how much the page load times dropped with switching from anchor links to a JavaScript solution that, while faster, is considerably less accessible.

GitHub is undeniably different than most websites — especially pages like the Git diff views, which involve considerably more code than most pages will need. But, while GitHub may be the extreme example, in many cases the same small changes can help speed up much simpler pages as well.

‘Tis the Season … To Write Better Code

Scott Gilbertson — Tue, 04 Dec 2012 18:37:29 +0000

Image: Instructables, Altoids Advent Calendar/CC.

The holidays are here and for web nerds that means only one thing — another wave of advent tutorials is hitting the web.

It doesn’t feel much like winter right now at the Webmonkey lair, but that’s okay because we mark the start of the holiday season by the launch of 24Ways, the grand poobah of advent calendars for web nerds. 24Ways has been an annual tradition since 2005, offering 24 articles packed with new tips and tricks showcasing some of the year’s best new ideas in web development.

This year’s 24Ways kicked off with a tutorial on HTML5 Video “Bumpers” by 24Ways founder Drew McLellan. Other articles thus far include how to start a project on the right foot, how to contribute code to the community and Geri Coady’s excellent article on Color Accessibility.

While 24Ways may be the biggest name in advent tutorials, it’s not lacking for competition these days. We also recommend the Performance Calendar, which tackles the often confusing world of website optimization. There’s also Digitpaint’s advent calendar which we enjoyed last year and has already published some nice articles this year, including this look at CSS filters.

If you’re missing another favorite, the PHP Advent Calendar, fear not, it has returned, but with a new name and domain: PHP Advent is now Web Advent. The name may have changed, but Web Advent offers similarly great content, like this article on Sharing What You Know by Heather Payne, the founder of Ladies Learning Code.

Bootstrap Framework Plans to Give Twitter the Boot

Scott Gilbertson — Thu, 04 Oct 2012 17:33:13 +0000

Image: vinylsoda89/Flickr.

Web development toolkit Bootstrap is getting ready to part ways with Twitter. The open source project began life at Twitter, but with its two primary developers leaving Twitter for other companies, Bootstrap will be spun off on its own.

Bootstrap co-creators Mark Otto and Jacob Thornton are both leaving Twitter and have announced that Bootstrap will continue but as “its own open source organization.” For now nothing is changing; Bootstrap will remain a Twitter project on GitHub. But eventually the pair plan to give Bootstrap a life of its own.

The Bootstrap project is designed to help you get your website up and running as fast as possible. Somewhere between a framework and a “theme,” Bootstrap offers an HTML, CSS and JavaScript base for your designs, including built-in forms, buttons, tables, grids and navigation elements. Among Bootstrap’s more impressive tricks is the grid layout tool with support for advanced features like nested and offset columns. Bootstrap is also impressively lightweight, weighing in a just 10kb (gzipped).

Bootstrap 2.0, released earlier this year, added some much-needed responsive design tools for creating fluid layouts, including a new flexible 12-column grid system.

The move away from Twitter should be good news for Bootstrap users, particularly with Twitter’s increasingly hostile attitude toward developers. Otto assures anyone worried that Bootstrap will become abandonware that both he and Thornton are dedicated to Bootstrap. “The project has grown beyond us and the Twitter brand,” writes Otto on the Bootstrap blog. “It’s a huge project playing a pretty awesome role in the web development industry, and we’re excited to see it continue to grow.”

To see some real-world examples of what you can do with Bootstrap, head on over to the unofficial showcase, Built with Bootstrap on Tumblr.

W3C Names Four New HTML Editors

Scott Gilbertson — Mon, 30 Jul 2012 16:27:57 +0000

The World Wide Web Consortium (W3C) has named four new editors of the HTML5 spec to replace departing editor Ian Hickson.

The W3C’s HTML Working Group co-chair Paul Cotton announced the four-way editorship in a e-mail to the W3C’s public HTML mailing list.

The four new editors include two Microsoft employees, Travis Leithead and Erika Doyle Navara, Apple’s Ted O’Conner and Silvia Pfeiffer of Ginger Technologies, a company specializing in HTML video.

“The Chairs received a large number of applications for the position of HTML5 editor,” writes Cotton. “After evaluating all the applications, we chose the above HTML5 editorial team based on the individual qualifications of the new editors as well as the combination of the individual appointee’s qualifications.”

The heavy representation of Microsoft is interesting given that Microsoft is not currently a member of the Web Hypertext Application Technology Working Group (WHATWG), the other standards body that oversees HTML. It would seem that Microsoft is doubling down on the W3C version of HTML.

The editor change is part of the recent split that sees the two standards bodies jointly responsible for developing the HTML specification, moving in different directions.

The W3C and the WHATWG have long acted as separate bodies, but previously shared an editor, Ian Hickson, who helped ensure that the two specs remained in sync. Then last year the WHATWG announced it was dropping the “5″ version number and would work on HTML as a “living standard” sans version numbers. The W3C continued to focus on HTML “snapshots” like HTML5.

“The WHATWG effort is focused on developing the canonical description of HTML,” wrote when he stepped down as W3C editor last week. “The W3C effort, meanwhile, is now focused on creating a snapshot developed according to the venerable W3C process.”