The Web Standards Projecthttp://www.webstandards.org
Working together for standardsFri, 01 Mar 2013 18:30:30 +0000enhourly1http://wordpress.org/?v=3.3.1Our Work Here is Donehttp://www.webstandards.org/2013/03/01/our-work-here-is-done/
http://www.webstandards.org/2013/03/01/our-work-here-is-done/#commentsFri, 01 Mar 2013 14:20:11 +0000agustafsonhttp://www.webstandards.org/?p=2161When 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.

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:

A List Apart – The magazine “for people who make websites” is run by WaSP founder Jeffrey Zeldman and is a consistent source of forward-thinking articles and tutorials.

HTML5 Doctor – A solid resource and discussion forum on all things HTML5, brought to you by Bruce Lawson and his team.

WebPlatform.org – A fantastic web standards resource, providing up-to-date documentation, Q&As, tutorials & more. Chris Mills, Doug Schepers, and a number of other standards advocates are involved in this project.

Web Standards Sherpa – An educational resource founded by WaSP which continues to operate under the leadership of Chris Casciano, Virginia DeBolt, Aaron Gustafson, and Emily Lewis.

Web Standards + Small Business – An outreach project started by WaSP that educates small businesses about why they should care about web standards. This project is overseen by Aaron Gustafson.

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.

]]>http://www.webstandards.org/2013/03/01/our-work-here-is-done/feed/89Call for action on Vendor Prefixeshttp://www.webstandards.org/2012/02/09/call-for-action-on-vendor-prefixes/
http://www.webstandards.org/2012/02/09/call-for-action-on-vendor-prefixes/#commentsThu, 09 Feb 2012 14:56:52 +0000randrewhttp://www.webstandards.org/?p=2142When 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.

How can you help?

If you have sites that test for WebKit browsers or only implement -webkit prefixes please take some time and update any -webkit-only property to use the other vendor-specific prefixes and non-prefixed versions.

Sign this petition & pledge telling browser makers not to implement the -webkit-* vendor prefix and promising to update the sites under your control.

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.

]]>http://www.webstandards.org/2011/12/15/an-end-to-aging-ie-installs/feed/18Beyond the Blue Beanie?http://www.webstandards.org/2011/11/30/beyond-the-blue-beanie/
http://www.webstandards.org/2011/11/30/beyond-the-blue-beanie/#commentsWed, 30 Nov 2011 15:53:17 +0000Stephanie (Sullivan) Rewishttp://www.webstandards.org/?p=2050You 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 there is more?

What if wearing that cute little blue toque was only the beginning of a continual journey?

But I’m just a single developer…

I don’t have an organization behind me…

The company I work for doesn’t really care…

I can’t really effect anything, why bother…

I already work 60 hours a week—I can’t fit anything else in…

I don’t really have any original ideas…

Other developers know so much more than me…

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.

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!

]]>http://www.webstandards.org/2011/11/30/beyond-the-blue-beanie/feed/11The Sherpas are Herehttp://www.webstandards.org/2011/03/13/the-sherpas-are-here/
http://www.webstandards.org/2011/03/13/the-sherpas-are-here/#commentsSun, 13 Mar 2011 16:49:51 +0000agustafsonhttp://www.webstandards.org/?p=2030Today, 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.

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.

]]>http://www.webstandards.org/2011/03/13/the-sherpas-are-here/feed/2HTML5? Check. Accessible HTML5? Um…http://www.webstandards.org/2011/02/01/html5-check-accessible-html5-um_/
http://www.webstandards.org/2011/02/01/html5-check-accessible-html5-um_/#commentsTue, 01 Feb 2011 21:22:33 +0000agustafsonhttp://www.webstandards.org/?p=2013In 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.

We can’t thank Steve enough for his work on this and wish him well as these efforts continue.

]]>http://www.webstandards.org/2011/02/01/html5-check-accessible-html5-um_/feed/17HTML5 logo: W3C takes a step in the right directionhttp://www.webstandards.org/2011/01/28/html5-logo-w3c-takes-a-step-in-the-right-direction/
http://www.webstandards.org/2011/01/28/html5-logo-w3c-takes-a-step-in-the-right-direction/#commentsFri, 28 Jan 2011 20:32:04 +0000cmillshttp://www.webstandards.org/?p=2008After receiving a waveof negativefeedbackconcerning 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.

On a related matter…

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

]]>http://www.webstandards.org/2011/01/28/html5-logo-w3c-takes-a-step-in-the-right-direction/feed/4HTML5 logo: be proud, but don’t muddy the waters!http://www.webstandards.org/2011/01/18/regarding-the-html5-logo/
http://www.webstandards.org/2011/01/18/regarding-the-html5-logo/#commentsTue, 18 Jan 2011 20:50:03 +0000cmillshttp://www.webstandards.org/?p=1984Today 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

]]>http://www.webstandards.org/2011/01/18/regarding-the-html5-logo/feed/17Small Business Updatehttp://www.webstandards.org/2010/08/05/small-business-update/
http://www.webstandards.org/2010/08/05/small-business-update/#commentsThu, 05 Aug 2010 21:01:03 +0000agustafsonhttp://www.webstandards.org/?p=1961Back 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.