When The Web Standards Project (WaSP) formed in 1998, the web was the battleground in an ever-escalating war between two browser makers—Netscape and Microsoft—who were each taking turns “advancing” HTML to the point of collapse. You see, in an effort to one-up each other, the two browsers introduced new elements and new ways of manipulating web documents; this escalated to the point where their respective 4.0 versions were largely incompatible.
Realizing that this fragmentation would inevitably drive up the cost of building websites and ran the risk of denying users access to content and services they needed, Glenn Davis, George Olsen, and Jeffrey Zeldman co-founded WaSP and rallied an amazing group of web designers and developers to help them push back. The WaSP’s primary goal was getting browser makers to support the standards set forth by the World Wide Web Consortium (W3C).
In 2001, with the browser wars largely over, WaSP began to shift its focus. While some members continued to work with browser vendors on improving their standards support, others began working closely with software makers like Macromedia to improve the quality of code being authored in tools such as Dreamweaver. And others began the hard slog of educating web designers and developers about the importance of using web standards, culminating in the creation of WaSP InterAct, a web curriculum framework which is now overseen by the W3C.
Thanks to the hard work of countless WaSP members and supporters (like you), Tim Berners-Lee’s vision of the web as an open, accessible, and universal community is largely the reality. While there is still work to be done, the sting of the WaSP is no longer necessary. And so it is time for us to close down The Web Standards Project.
Many (if not all) of us are continuing to work in the world of web standards, but our work is now largely outside the umbrella of WaSP. If you are interested in continuing to work on web standards-related projects along with us, we humbly suggest you follow these projects:
The job’s not over, but instead of being the work of a small activist group, it’s a job for tens of thousands of developers who care about ensuring that the web remains a free, open, interoperable, and accessible competitor to native apps and closed eco-systems. It’s your job now, and we look forward to working with you, and wish you much success.
Nota bene: In the near future, we will be making a permanent, static archive of webstandards.org and some of our other resources like WaSP Interact to preserve them as a resource and to provide a record of our 15-year mission to improve the web.
Bruce Lawson and Steph Troeth contributed to this post.
When I first became involved with The Web Standards Project I was, like most of my peers, either building two completely different sites to support the version 4 behemoths – Internet Explorer and Netscape, or making a decision as to which browser people should use to view the site.
Internet Explorer 6, despite all of the well known issues, was a breath of fresh air. We could use a lot of CSS2, we could lay out our pages using CSS, and many people decided that Internet Explorer was the browser they were going to support. This led to a raft of “only works in Internet Explorer” sites and applications, the reason why we are still stuck with IE6 today.
Ten years later. In many ways we are in the place that we wanted to be, when we were campaigning for web standards adoption by developers and browser manufacturers. Our browsers do support W3C specifications. We don’t have rafts of crazy bugs in standard features or vendor specific implementations of those features that vary wildly. I can build a complex layout and load it up in Internet Explorer 9, the latest Firefox, Opera, Safari and Chrome and it all look pretty much the same. This is what we were asking for.
It could not be said however, that all browsers are equal in 2012. Some have moved more quickly to implement parts of the CSS3 specification even when they are just at Working Draft status. Browsers have implemented these new features using Vendor Prefixes, enabling them to implement a feature that might change as it goes through the W3C process. Vendor Prefixes to some extent have helped to prevent the situation arising again where we have a standard feature implemented in different ways by different browsers. Thinking back over our history I believe that to be a good thing.
Whether you like Vendor Prefixes or not, we have a problem. Due to the rise in mobile browser usage, and many of those mobile browsers being based on WebKit, many developers have decided to essentially only use the -webkit- prefix, even for properties that have been implemented by other browsers. Today Daniel Glazman, W3C CSS Working Group Co-chairman, wrote a blog post, Call for action: the open web needs you now!. He, and the W3C CSS Working Group is concerned that if this continues, other browser manufacturers will simply start implementing the -webkit prefix.
This approach seems very likely. If other browser manufacturers have implemented these features under their own prefix, yet web developers do not use those prefixes, then it makes their browsers look less capable than those based on WebKit. By simply implementing the -webkit prefix sites will look better in these browsers.
If this happens then we end up with a web once again controlled by one browser manufacturer. Once again we run the risk of having sites built only for one platform, and finding it very hard to get that platform to go away if things move on. Please read the above post. Please think about it every time you have to ensure your site works well in a browser that is over ten years old. Please do your bit to prevent -webkit becoming a de facto standard and hurting the Open Web.
-webkit-*
vendor prefix and promising to update the sites under your control.As professional web builders we know that the web is constantly changing and our methods and practices must respond and adapt as well.
There are so many new disciplines web professionals need to be know about, if not specizlized in, that weren’t around ten or even five years ago.
It’s not always easy to keep on the latest and greatest in web and mobile tips, tricks and techniques.
Sometimes it’s downright difficult.
If it’s hard to keep up with the changes as professionals, so it must be even more so for our teachers of the craft.
For the past several years, a group of dedicated and talented volunteers have been working to help fix that.
Our Education Task Force has developed a world-class curriculum – we’re talking about tools for teaching.
Materials such as syllabii, quiz questions, recommended readings, and more aid in creating web professionals that are ready for the job market that so desperately needs young, competent web builders.
With such a strident resource, professors, educators to teach standards-based web design and development in their own classrooms.
Available on our web site, Web Standards Project InterACT Curriculum have found their way into some forward-thinking classrooms all over the world.
And it’s totally free.
In addition, the Education Task Force published a textbook based off the curriculum titled InterACT with Web Standards.
This web standards textbook is a available from Peachpit, which has published classics such as Jeffrey Zeldman and Ethan Marcotte’s Designing with Web Standards and Dave Shea and Molly E. Holzschlag’s The Zen of CSS Design.
Today, I’m happy to announce that the curriculum reaches even more people than ever before.
The InterACT Curriculum developed through Web Standards Educational Task Force has been licensed to W3C.
Through their resources and network, the curriculum will be used to teach companies and organizations, large and super-large, about standards-based education.
And it only seems appropriate that InterACT finds yet another home that is the W3C.
The Educational Task Force’s InterACT was one of the primary catalytics that led to the formation of the Open Web Education Alliance (OWEA) under the W3C.
To continue to expand the curriculum, the Education Task Force needs your help.
You don’t need to be a self-proclaimed web guru or a mobile ninja to help.
We people that specialize in all facets of web and mobile design and development that includes copywriters, content strategists, user experts, project managers, and more.
There’s room for everyone and, frankly, it has been and will continue to be people like yourself reading this message right now that will make world-caliber educational material.
Contribute to a curriculum that gets in the hands of tomorrow’s builders today.
Fill out the contribution form or reach out to EduTF leaders, Glenda Sims and Mark DuBois to ask how you can get more involved.
]]>Today is a momentous day.
After spending years of griping about IE6’s staying power and lamenting Microsoft’s earlier decision to advocate against upgrading to IE7 (a decision they didn’t stick with, thankfully), Microsoft has turned a new leaf today, announcing that they will be pushing updates to IE to anyone who takes part in their Windows Update service.
What does this mean? Well, it means that grandma will be upgraded to IE8 if she’s still on Windows XP or IE9 if she’s on Vista or Windows 7.
Corporations (and individuals) still have the ability to opt-out of these updates, but this move should put an end to upgrades that haven’t happened purely because users didn’t know how to upgrade to a new version of IE. As Microsoft’s own Peter Laudati so eloquently put it, “Upgrade Your Parents Browser Weekend” is now officially obsolete.
]]>You put on your blue beanie every year. But you can make a difference throughout the year.
For several years, web workers passionate about web standards have donned blue beanies for one day to bring attention to the importance of using web standards, keeping the web open, and continually moving it forward. We dutifully change our avatars on social media sites and the pictures on our web sites for a single unified day—this year on November 30. Of course this bewilders high school, college, and other non-tech friends on sites like Facebook, but we disregard their confusion in our eagerness to advocate the advancement of something we believe in. The following day, we return to our typical avatars and photos, all while making plans for a funnier, more creative blue beanie avatar for the next year.
What if wearing that cute little blue toque was only the beginning of a continual journey?
These are just a few of the excuses that play in our heads when we contemplate doing more than putting on the beanie once a year. Today I’m happy to announce a new project, put together by a group of very passionate web folks, that can enable your entry into the process of moving the web forward—no matter what skill level you’re currently at—Move the Web Forward.
From the site:
Our goal is to make it easy for anyone to get started contributing to the platform, whether that’s learning more about how it works, teaching others, or writing specs. The web has grown due to people like you, and we want to make it even easier for people like you to give back.
The web page is packed full of a generous range of ideas, from how to learn, and how to help other people learn, to how to hack the web and contribute to specs. There are few excuses left when the ideas are well organized allowing you to pick and choose what you, or your organization can handle. I’m impressed with the generosity of time and effort this group of devs have contributed to put this amazing resource together. Don’t miss it — Move the Web Forward!
You can make the web as awesome as you want it to be. Browser vendors, standards editors and library creators actively seek your voice and your contribution. Together we can move the web forward.
Also check out Addy Osmani’s article on Smashing Magazine with more details on just how you can help move the web forward.
As the saying goes, many hands make light work. How fantastic would it be if there were so many hands that the burden didn’t fall on just a few? Together, let’s make the web rawk even harder!
]]>Today, I am very proud to announce the launch of our newest endeavor: Web Standard Sherpa. This project has been the better part of a year in the making and we’re really excited to see it finally launch.
Web Standards Sherpa came about because we wanted to create a repository of best practices information while, at the same time, providing mentorship opportunities for practicing web professionals. With those goals in mind, we began to throw around ideas of what that could look like and we realized a pseudo-critique site could fit that bill perfectly. We say “pseudo” because the reviews we’ll be posting on Web Standards Sherpa are not traditional critiques, but rather focused reviews of a particular aspect of a site.
The elevator pitch on the site sets it up well:
Web Standards Sherpa’s experts provide helpful, pragmatic and up-to-date advice on best practices for web professionals everywhere.
In terms of format, our plan is to bring on amazing authors for a period of 3-6 months or more at a time, with new articles coming out weekly. We’ve kicked things off with pieces by Erin Kissane, Jared Spool, and yours truly; Dan Rubin and Derek Featherstone are on deck for the next two issues.
In order to get the ball rolling, we’ve chosen a handful of sites to look at, but our goal is to have users submit their own work to get honest feedback. We’re not looking to tear down your work, but we are looking to help everyone get better at their job. If you’re struggling with your navigation, for instance, you could submit your site and ask for our thoughts. If you’re unsure your approach to scripting a particular widget is the most efficient or are concerned about its accessibility, you should submit that too. We see Web Standards Sherpa as a way to let you glean advice from some of the smartest folks in the industry and provide you with the opportunity to learn from real world examples of what people are doing right and where there is room for improvement.
We hope you’ll help us out by “feeding Shirley” (our mountain goat mascot) and submit your sites for review.
]]>In a recent blog post, Steve Faulkner of the Paciello Group began to examine how HTML5, which is supposed to help improve the accessibility of web sites and applications, is being exposed to assistive technologies. The current state of things, as documented on HTML5Accessibility.com, leaves a considerable amount to be desired.
The current accessibility support implemented in browsers lags behind their implementations of the sexy new features themselves. These are still early days in the implementation of HTML5 features, so lets keep our fingers crossed that Google, Apple (Safari on Windows) and Opera will get their acts together to provide at least a basic level of HTML support in their browsers for assistive technology users. Equally it is hoped Mozilla, Apple (Safari on Mac) and Microsoft will strive to have their rate of accessibility support match their rapid implementation of the new HTML5 features.
To address the need for standardizing the implementation of accessibility features, Steve and others have begun working on the HTML to Platform Accessibility APIs Implementation Guide.
We can’t thank Steve enough for his work on this and wish him well as these efforts continue.
]]>After receiving a wave of negative feedback concerning the HTML5 logo, the W3C have made steps towards righting things. If you read the HTML5 logo FAQ, you’ll see that they’ve made some significant changes, including adding this:
Is W3C saying that CSS3 is part of the HTML5 specification?
No. However, many HTML5 Web sites and applications do take advantage of CSS3 for styling and presentation.
This is a good start, but there is still a lot to be done. The main HTML5 logo page still includes non-HTML5 (or event HTML5 web app-related) technologies such as CSS3, SVG, etc. And the Badge Builder still assembles a badge that makes these technologies appear subordinate to HTML5 as opposed to framing them as complementary, but distinct entities. We hope the FAQ change is not the end of their efforts to fix the potential confusion they have caused and that they will continue putting things right over coming days.
As you probably heard, the WHATWG has decided to drop the “5” from their work on the HTML language:
…we realised that the demand for new features in HTML remained high, and so we would have to continue maintaining HTML and adding features to it before we could call “HTML5″ complete, and as a result we moved to a new development model, where the technology is not versioned and instead we just have a living document that defines the technology as it evolves.
At first blush, many of us were a little distraught by this decision because we thought the W3C might decide to follow suit, but after thinking on it a bit, the decision makes sense: the WHATWG can work on the HTML markup language in a fluid way and the W3C can take snapshots of that work and christen it with a version number for reference purposes.
Some might argue that version numbers are meaningless on the ever-evolving web, but they do help us establish mile-markers or guideposts which aid in both education and accountability. Sure, both versions 4 and 5 of HTML are still HTML, but, as the saying goes, you can’t build on shifting sands. It’s frustrating to teach from an ever-changing spec. The same goes for authoring to one. Some manner of stability is necessary so you know what is “true” now (or at least at some point in time), even if those circumstances may change in six months or six years. Not having a version number will make it really hard to educate people about the current set of new HTML features, and how they differ from the old version (which rather contradicts the purpose of the HTML5 logo in the first place).
Not that there was really a question, but we stand by our sentiment that the final (as in W3C) version of HTML5 should continue having a version number while the version-less WHATWG version is used for continuing development.
]]>Today brings to us the news that the W3C have unveiled a logo for HTML5. Does an open technology need a logo? Perhaps not, but many see it as a good idea, including myself. I think it is a great idea to create a rallying flag/focus point for people to use to show their support of HTML5, and to help increase awareness and propagation of this important new technology, thereby aiding the evolution of the open web.
But wait, things are not quite right. If you delve deeper you’ll see that, included in their definition of the technology that comprises HTML5, is CSS3, WOFF, SVG, and a few other cuckoos in the HTML5 nest. If you look at the HTML5 Logo FAQ, you’ll find the following:
The logo is a general-purpose visual identity for a broad set of open web technologies, including HTML5, CSS, SVG, WOFF, and others.
This really isn’t good—I appreciate that it is good to have an umbrella term for a group of related technologies and techniques that would otherwise be difficult to talk about in conversation. “Ajax” and “Web 2.0” serve that purpose well. And it is ok to talk about closely-related specs such as Geolocation and Web Sockets as being under the HTML5 umbrella, as long as you clarify it somewhere (you can find a good example in Get familiar with HTML5!). But this is different—HTML5 and CSS3, for example, are two distinctly different technologies, and should not be confused with one another. To do so will impede learning and cause problems with development, documentation, and all manner of other things.
You could perhaps forgive marketers for getting it confused, but then again their confusion is not so critical as long as their end product looks and works great, and they have a web developer behind them to put them right at critical points. But I have talked to many web developers that are confused, and honestly think that CSS3 and SVG are part of HTML5.
There has understandably been some bad feeling about this in the web community. Jeremy Keith put it nicely in Badge of Shame
, and Bruce Lawson also gave a good view in On the HTML5 logo, as well as providing a good rant to put things straight: HTML5 != CSS3. At Opera, my colleagues and I are constantly reiterating a more accurate definition of HTML5 to help overcome such confusion, and many allies at other browser vendors are doing the same.
But standing against the W3C is not the way to solve this either. In light of this, we at the WaSP are sending an open letter to folks at the W3C, urging them to fix this oversight. The letter is thus:
]]>Dear W3C,
We are writing to address a major concern we at WaSP (and in the web professional community in general) have with the newly-unveiled HTML5 brand. While we are excited that the W3C is doing so much to promote new technologies being developed, we are incredibly concerned that using “HTML5” as the umbrella for these technologies does more harm than good.
“HTML5,” as a term, has become a bit of a beast and is already presenting problems:
First, you’ve got HTML5 “the spec” which isn’t just HTML markup anymore, but includes specifications for everything from local databases to web workers. Explaining what we mean when we talk about “HTML5” requires use of modifying phrases, as in “HTML5 the markup language” or “HTML5 geolocation”.
Then Apple and Google began promoting the use of “HTML5” as as a catch-all term for marketing their browser advancements, much as Microsoft and Netscape (and journalists) had used “DHTML” in the past. The term became less meaningful because it was being used to cover more ground and, consequently, it made communications between developers and clients more difficult because both sides did not have the same understanding of what HTML5 meant.
Now the W3C has come out and essentially condoned the branding of everything from CSS to actual HTML5 to WOFF as “HTML5”. We can’t imagine a single action that will cause more confusion than this misguided decision (and the W3C has produced some pretty impenetrable specs in its time). Our own Jeremy Keith summed it up perfectly when he said
What we have here is a deliberate attempt to further blur the lines between separate technologies that have already become intertwingled in media reports.
We need for the W3C, as a standards body, to understand the importance of clarity with regard to the term “HTML5”. Without being able to draw clear distinctions between technologies, clear communication about those technologies becomes increasingly difficult if not impossible. As an organization of web professionals promoting the inclusion of web standards in the education of future web professionals and the adoption of web standards among practicing professionals, we are deeply concerned that your decision will make our job even harder.
So, when push comes to shove, what do we want you to change? Well, we think a good place to start is backing away from the use of “HTML5” as a catch-all term. If you feel you need a catch-all term, come up with something else, but as Jeremy also said
We [developers] never needed a term to refer to “XHTML 1.0 plus CSS2.1” or “HTML4.01 plus JavaScript” or “any combination of front-end technologies.” Why this sudden all-conquering need for a term that covers so many different technologies as to be completely meaningless?
With a new moniker for the umbrella of modern web technologies, the blurred distinction between the diverse languages and systems that comprise it will evaporate and we won’t have to worry (as much) about the potential for miscommunication. Hey, it will even give you a chance to create another logo.
Signed,
The Web Standards Project
Back in February, I announced that one of WaSP’s new efforts was going to be in the direction of outreach to small businesses. Since that time, things have looked pretty quiet from the outside, but the Small Business Outreach Committee has actually been quite busy gathering materials and putting together our first document which aims to help small business owners evaluate the competencies of those seeking to do web work for them.
Thanks to the efforts of a handful of WaSP members and a cadre of other web professionals, we’re making great progress. We’ve just wrapped up the material organization phase and are beginning to work on drafting the document, which we hope to have out before the end of the year. We’re also in the process of putting together a website to house “living” versions of the materials we produce and assist with the promotion and distribution of this document and any others we generate in the future.
We’ll post further announcements on this project as we get closer to the launch date.
]]>