Image: W3C

Among the highlights are Eric Meyer’s talk on Flexbox, and the future of sane layout tools — what Meyer calls “the Era of Intentional Layout.” Meyer’s talk is also notable for the reminder that, in Mosaic, styling a webpage was something users did, not page creators.

Another highly recommended talk is Lea Verou’s “Another 10 things you didn’t know about CSS.” The “Another” bit in the title refers to a talk Verou gave last year entitled “10 things you might not know about CSS 3.” Also be sure to read our recent interview with Verou for more on the W3C and web standards.

There are quite a few more videos available over on the W3Conf YouTube page, including Jacob Rossi’s talk on Pointer Events, which we linked to in yesterday’s Pointer Events coverage.

Image: Lea Verou

This is the first in a coming series of interviews with web developers. We’re excited to start with Lea Verou, a front-end web developer from Greece who has not only made lots of cool stuff we’ve linked to, but also recently joined the W3C to help work on web standards.

Webmonkey: You joined the W3C Developer Relations last year, which is a relatively new thing at the W3C, actively reaching out to web designers and developers. What does the day to day work of a W3C Developer Relations person look like?

Lea Verou: You’re absolutely right Scott, it’s a new initiative that Doug Schepers started last year. W3C was interested in outreach for years, but there was no official Developer Relations activity before.

My role is pretty mixed. I help organize W3Conf, our conference for web designers and developers, I help develop and promote WebPlatform.org, presenting at conferences around the world, I write articles about web standards in industry media and many other things.

WM: You were interested in web standards very early on, what was it that made standards important to you?

Verou: When I started developing for the web, IE6 was the most widely used browser. As you probably remember, making websites that work cross-browser was way harder back then than it is today. We had to rely on browser detection, ugly hacks and whatnot. I wished browsers could just agree on some common ground and implement that. A couple years later, I discovered that this is actually a thing and it’s called web standards. Since then, I made it one of my personal goals to raise awareness in fellow web developers, get browsers to implement them and advance the standards themselves for the common good.

WM: Of course many of those ugly hacks remain, especially for developers still wrestling with IE7 (IE6 seems to have been put to rest for the most part). What’s your take on supporting older browsers? Is that an important thing to do or is it time we leave them behind because they’re holding back the web?

Verou: I’m a big supporter of progressive enhancement and graceful degradation. Websites should be usable, if possible, in older browsers, but they don’t need to have all the bling. However, graceful degradation is not black & white. Everyone seems to have a different definition of what is “graceful” and what is “enhancement”.

Is a solid color an acceptable fallback for a pattern? What if your lightbox has no overlay? What if your stripes become a solid color? What if your transitions are not there? What if your code has no syntax highlighting? I tend to lean towards being more permissive instead of looking for perfection in older browsers, especially on websites targeted to a more technical audience. I will provide fall-backs, but I will not go out of my way and use proprietary IE7-specific stuff to make something look good there. With a < 0.5% global market share, it’s just not worth it.

WM: A lot of the developers I know have a kind of love-hate relationship with the W3C. But you wrote on your site that working for the W3C was “a dream of mine ever since I learned what a web standard is.” Can you talk a little bit about what makes the W3C great and why you wanted to work there?

Verou: Like I said before, promoting web standards was something I was already doing for years anyway. I felt that working for W3C itself would enable me to do it more systematically and have a bigger impact. For instance, one of my main tasks has been helping organize W3Conf — happening this February in San Francisco — which is aimed at showing web professionals that web standards are not some utopian ideal but practical to adhere to in everyday work, as well as educate them about recent developments that they can use today. Connecting those two worlds is a fun challenge!

WM: Standards do at times feel less than practical, especially because they’ve been changing a lot lately — e.g. WebSockets got a rewrite after it had already shipped in multiple browsers, ditto CSS Flexbox. So there’s these seemingly rapid changes, and then on the other hand it seems like we’ve been waiting for other things forever. I know the W3C recently launched, WebPlatform.org for developers, but what other resources would you suggest for web professionals who’d like to educate themselves about web standards, and more importantly stay up-to-date?

Verou: W3C is well aware of the fact that sometimes we can be slow and we are trying to speed things up to meet developer needs. This is why we are encouraging implementors (like browser vendors) to implement earlier on in the process so we can get feedback by developers and we’re putting more emphasis on testing, which is going to improve interoperability.

All this means that experimental features will ship which still need work. Having shipped in browsers is not an indication of stability. Browsers often ship experimental features so that developers can play with them and give feedback. This doesn’t mean the feature is frozen — quite the opposite, it means we need feedback to make it better.

Regarding resources, I know I’m weird, but I often read about new features in specs. I search for a feature, come across the spec, take a look on what else is there and then see if it’s implemented anywhere. I also often find good information on Twitter and looking at others’ code. There are also some websites with good information like:

• html5doctor.com
• css-tricks.com
• smashingmagazine.com
• netmagazine.com
• sitepoint.com
• alistapart.com

and many others.

WM: Now that you’re actually working for the W3C has your perspective on standards changed? Is there anything that looks different from the other side of the fence?

Verou: I was involved in standards before I joined W3C, so many things already looked different. For instance, many developers tend to blame W3C for being slow with standardization, whereas the reality is that often implementors are just busy with other things (we need multiple implementations for a spec to exit CR level) or spec editors are focusing their attention elsewhere.

Another common misconception is that spec editors and Working Group members are exclusively or mostly W3C staff. Whereas many W3C Team members do edit specs and participate in WGs, the majority of spec editors are employees of member companies, as evident in most specifications (you can see a list of the editors in the header). W3C is not some authority that dictates standards from up high, but merely a forum for interested parties to get together and collaborate on advancing the web.

WM: How can developers who aren’t (yet) well-known contribute to the process or give feedback about what works and what doesn’t?

Verou: Participating in web standards is a matter of joining the conversation. W3C is very open. Technical discussion happens in the public mailing lists and IRC, which you can join. Pragmatic feedback from anybody is welcome, especially from people who have tried using the feature in question. Experiment, try to make it work for you and share experiences — good or bad — about it. It might seem at first that you’re just one voice among many, but if your feedback is good, your voice is going to be heard. Technical arguments are judged on their merit and not their origin.

WM: I get tired just looking at your GitHub page — Pattern Gallery, -prefix-free, Dabblet, Prism and a bunch of other useful tools — where do you find the time to build all this cool stuff? And are you going to be able to keep doing it now that you’re at the W3C?

Verou: I actually released another tool after I joined W3C: Contrast Ratio. W3C supports me in making tools to help developers use open web technologies more effectively. In fact, improving Prism and Dabblet is one of my tasks at W3C since we are going to be using them in WebPlatform.org, our vendor-neutral documentation effort, where all the big players of the Web are working in harmony to create a valuable resource. However, I plan to slow down on releasing new things, so I can maintain the existing ones. Nobody likes to use abandoned scripts and tools, right? :)

WM: The first time I recall landing on your blog was for a post about CSS abuses, like making the Mona Lisa in pure CSS. Which is of course silly, but what caught my eye was that you wrote about how people should be using SVG, which is an awesome tool that almost no one seems to use (despite the fact that it often has better browser support than most CSS 3 features and works great on every screen resolution). Why is SVG still the neglected stepchild of the web stack and do you think that’s ever going to change?

Verou: SVG was significantly held back by a number of different factors. One was the lack of proper support in browsers for many years. Internet Explorer was promoting VML (a proprietary technology that influenced SVG) until IE8 and only implemented SVG in IE9, which is not that long ago. In addition, there are far more browser bugs in SVG implementations across browsers, since fewer people use it, so fewer of them get reported and fixed.

Last but not least, there just aren’t many extensive resources for SVG documentation, a gap that WebPlatform.org is trying to cover (and since it’s a wiki, you can help too!).
However, SVG is certainly picking up in the last few years, either directly by people using the format, or indirectly, through many of its features getting added in CSS. For example, CSS Transforms, CSS Filter Effects, Blending and Compositing, as well as CSS Masking, are all basically SVG applied to HTML with a simpler syntax.

WM: Everyone has their pet standard, personally I’d like to see CSS Flexbox get better browser support and end the float insanity — what’s at the top of your web standards wish list?

Verou: As an editor of CSS Backgrounds & Borders Level 4 I can’t wait for it to get more attention. Regarding other specs however, I’m very interested in the new SVG-inspired specs like Filter Effects, Compositing and Masking. They allow us to do things we badly needed for years and for the most part, they degrade pretty gracefully, unlike the new Layout modules or the syntax improvements.

To keep up with Verou’s latest projects and musings on web standards, check out her blog and follow her on Twitter and GitHub.

Image: Screenshot/Webmonkey.

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.

The W3C, the group that oversees the development of HTML and other web standards, is moving beyond dry, boring specifications with a new venture into developer documentation. The W3C has just launched an alpha preview of Web Platform Docs, a community-driven site the W3C is hoping will become the go-to source for learning how to build the web.

In other words the W3C is competing with Webmonkey.

We’re okay with that because there’s no such thing as too much high-quality, accurate info on the latest in HTML5, CSS 3 and other W3C standards. And quite frankly, HTML and CSS have grown considerably since the days when Webmonkey’s cheat sheets could tell you everything you needed to know.

Now there’s a plethora of resources for learning how to build the web — the Mozilla Developer Network, the Opera Developer Network and Microsoft’s developer site, to say nothing of the thousands of tutorials on developer blogs. But while there’s plenty out there to teach you what you need to know, finding exactly what you need to know can be challenging. You’re a web developer; you should spend your time building a better web, not searching Google for accurate info on web standards.

The goal of the W3C’s Web Platform Docs is twofold: get tons of great documentation all under one roof, and then — the most challenging part — make sure that it stays up to date. Solving the second problem is no small task. The web is currently littered with great tutorials on CSS Flexbox, which are, unfortunately, all wrong now that the Flexbox spec has been changed. The same is true of Web Sockets tutorials, Indexdb tutorials and any other tutorial on a spec that has changed or might change in the future.

These days keeping up with the rapidly changing world of web standards is a full-time job and who better to tell you what’s going on, how you can use new tools and when browsers will support them than the people actually writing standards and building browsers?

The W3C has managed to bring together some of the biggest names on the web to help create Web Platform Docs. Representatives from Opera, Adobe, Facebook, Google, Microsoft, Mozilla and Nokia will all be lending their expertise to the new site.

While the list of participating companies is impressive, Web Platform Docs is also a wiki that anyone, not just W3C reps, can edit. As the W3C’s Douglas Schepers tells Webmonkey, “anyone can contribute and everyone is on equal footing.”

If your head is bursting with tutorials, code snippets, examples or solutions to common development problems, head on over to the site and sign up so you can contribute. Bear in mind that this is an alpha release. While the site looks great and has the basic features of a wiki up and running, many of the features Schepers mentions in the intro blog post aren’t available just yet. “In the spirit of ‘release early, release often’, we decided to announce the site at the earliest possible point and improve it in public,” writes Schepers.

Right now the content of the site is primarily documentation, but the plan is to include tips and best practices along with up-to-date information on standardization progress and browser support for individual features. Other cool planned features include a way to share code snippets and an API for some aspects of the site.

For an overview of the site and to learn a bit more about where the W3C plans to go with Web Platform Docs, check out the video below.

Image: Screenshot/Webmonkey.

Like the Cylons, HTML5 was created by man. It rebelled. It evolved. It looks and feels like HTML. And now, it has a plan.

Namely, to be done in 2014.

The W3C has formalized its plan to move the HTML5 spec to the official “Candidate Recommendation” status by the end of 2014. That might seem like a long time from now, especially if, like most of us, you’ve been using the bulk of HTML5 for some time, but 2014 is quite a bit better than the 2022 date that used to be tossed around.

But there’s a catch. In order to get HTML5 to the Candidate Recommendation stage on time the W3C is going to move some less stable parts of the spec to the newly designated HTML 5.1.

HTML5 has already been “modularized” 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.

Now the W3C plans to split the remaining chunk of HTML 5.0 into HTML 5.0 and HTML 5.1. Each spec will then move through the process of becoming an official web standard. Here’s the W3C HTML Working Group’s plan for HTML5:

• we determine which features are likely to meet the “Public Permissive” CR exit criteria,
• we create a “stable HTML5.0″ draft which includes just those “stable” features, and which omits the remaining “unstable” features
• we create an HTML 5.1 editor’s draft which is a superset of the stable HTML5.0 but with the “unstable” features included instead of omitted, and also with any new proposed features included

The HTML WG would then rinse and repeat with HTML5.1 in 2016. And then HTML5.2 and so on. The result will hopefully be a faster evolving series of specs, which in turn means more features reach the Recommendation stage in less time.

For web developers in the trenches finalizing HTML5 might seem irrelevant — after all, browsers already support most of it so who really cares? There are two reasons reaching the Candidate Recommendation stage matters: It usually means improved cross-browser support and it always means that the spec is covered by the all important W3C patent policy, which ensures that HTML5 remains a royalty-free standard.

For a complete list of everything that’s “unstable” in the current draft of HTML5, as well as the plan for how to handle it, be sure to read through the W3C’s plan.

The two standards bodies that are jointly responsible for developing the HTML specification have cut the final tie that was binding them together.

The World Wide Web Consortium (W3C) and the Web Hypertext Application Technology Working Group (WHATWG) began to move apart last year when the WHATWG announced it would drop the version number and work on a “living standard” sans version numbers. The W3C continued to focus on HTML “snapshots” like HTML5.

However, despite that split the two shared an editor, Ian Hickson, who oversees both specs. Or did. In an e-mail to the WHATWG mailing list, Hickson announced that he is no longer the editor of the W3C HTML WG spec. The change isn’t unexpected; in fact Hickson announced it would happen over a year ago, but it does emphasize the growing distance between the two standards.

“The WHATWG effort is focused on developing the canonical description of HTML,” writes Hickson on the mailing list. “The W3C effort, meanwhile, is now focused on creating a snapshot developed according to the venerable W3C process.”

With different goals for each version of the spec Hickson says that “the chairs of the W3C HTML working group and myself decid[ed] to split the work into two, with a different person responsible for editing the W3C HTML5, canvas, and microdata specifications than is editing the WHATWG specification.”

Now, more than ever before there seems to be two versions of HTML. The question for developers is, what does this mean for the future of HTML? In the short term, very little.

The W3C will continue to develop its fixed-in-time snapshot of HTML5 and the WHATWG will keep going with the “living standard” approach. What some developers fear is that down the road the two specs will diverge in significant ways and HTML will become a messy set of forked standards and varying browser support that lands us back in the bad old days of IE 6.

Anything is possible, but we remain hopeful that that won’t happen, at least in part because the W3C standard is more of a branch than a fork.

If all goes well the process will remain essentially as it has been for the last few years: a browser adds some shiny new feature, the WHATWG documents it and other browsers implement their own versions. There’s an awkward, sometimes frustrating period for web developers while browsers tweak and refine their support, but eventually the dust settles and a new standard is added to the W3C’s version. It may not be a completely ideal process, but it is what’s managed to bring us this far.

There’s a hint of friction in W3C member Paul Cotton’s post to the HTML Working Group, suggesting that the W3C feels Hickson overstepped his bounds in removing <time>. “Therefore we direct the HTML5 Editor to NOT process this bug further,” writes Cotton, who goes on to say that the <time> element will be reinstated to the spec by Nov. 8.

The HTML WG wants, ahem, more time to hash out <time>.

It’s unclear exactly what this means for the WHATWG version of the HTML5 spec (see our article on the Difference Between the WHATWG and the HTML WG), but the W3C’s new love for time should be welcome news for web developers who’ve already deployed <time> on their sites.

While Hickson’s move to toss time out was probably premature, there are nevertheless some problems with <time>. The <time> element offers the ability to add semantic meaning to pages by marking up dates and other time data, but not all use cases have been covered and some gray areas still exist. For example, the code <time>2:30</time> could refer to a time of day or perhaps the length of a movie. Both are theoretically valid uses and figuring out the details and the various potential use cases, is exactly what the HTML WG wants more time to do.

In the minutes from the last HTML WG meeting developer Tantek Çelik, makes the case for re-instating <time> just as it was, but also adding several new capabilities. Çelik suggests accounting for use cases like a <time> tag with only a year (commonly used on sites like Wikipedia or for copyright), and also for using <time> with only a day and month, commonly used when specifying dates like Christmas — 12/25 or 25/12, depending on where you live. Still to be decided are use cases like duration and some details around time zones.

Like the rest of HTML5, <time> remains a work in progress. Now that it’s once again a part of the HTML5 spec that work can resume and those who are already using <time> in some of its well-established roles can breathe easier.

See Also:

• HTML5 Drops the Time Element
• Microdata: HTML5’s Best-Kept Secret
• Using Microformats in HTML5

Behavioral advertising, as such tracking is known, is becoming increasingly common on the web. Advertisers use cookies to follow you around the web, tracking which sites you visit, what you buy and even, in the case of mobile browsers, where you go. The U.S. Federal Trade Commission has already outlined a Do Not Track mechanism (PDF link), which would work much like the FTC’s Do Not Call list, offering a way to opt-out of online tracking.

While the new DNT header is already part of Firefox, Internet Explorer and Safari, and a wide range of sites now respect it, it has lacked one key ingredient — standardization. The new Tracking Protection Working Group is the first step on the road to standardization and will hopefully mean Opera and Chrome will both soon adopt the DNT header.

To help web developers get a handle on the new header Mozilla has put together a Developer Guide on DNT. The guide includes a walk through of how to detect a DNT header, and what to do about it when you do, as well as some sample code to help developers build DNT compliant sites and apps.

See Also:

• Mozilla Plans ‘Do-Not-Track’ Privacy Tools for Firefox
• Mozilla’s ‘Do Not Track’ Header Is Starting to Catch on With Advertisers
• Chrome Add-on Kills Tracking Cookies

Footprints photo by Vinoth Chandar/Flickr/CC

The World Wide Web Consortium (W3C), the web’s governing body, has launched a new "Community Groups" plan designed to help speed the development and standardization of HTML, CSS and other web tools.

Despite the W3C’s role as overseers of web standards, the W3C has never moved at the speed of the web. Much of the HTML5 and CSS 3 that powers the web today won’t officially be a standard for several more years. For those hoping to move the web forward the pace of the W3C sometimes makes the organization seem like a joke. Ten years to standardize HTML5? But HTML5 is already here.

Well, now is your chance to do something more than whine about the slow pace of standards on your blog. The W3C’s new community groups are designed so that anyone can contribute to the development of HTML. Just head over to the site and join a group that interests you. There are eight groups at the moment, including groups dedicated to topics like semantic news, web payments and web education.

The groups also go a long way toward making the W3C more accessible for mere mortals. With the new community groups you don’t need to be a Google or Apple employee to catch the attention of the W3C’s members, you just need to sign up and post your ideas for everyone to read.

The web is changing at an ever-accelerating pace and the W3C knows that if it doesn’t keep up, it’s going to be left behind. The W3C has already been abandoned once. When the W3C decided in 2004 that it would bow out the HTML standardization process, browser makers and web developers wasted no time creating their own separate standards body known as the Web Hypertext Applications Technology Working Group (WHATWG). The WHATWG is largely responsible for creating what we now call HTML5.

Clearly the web will move forward with or without the W3C, though as those who lived through the dark days of the blink tag can attest, the web is a better place with the W3C and web standards at its back.

See Also:

• W3C Publishes an HTML5 Spec for Web Developers
• Damn the W3C, HTML5 Is Already Here
• The Difference Between the WHATWG and the HTMLWG