Don't Blame Opera, Blame Devs

On Wednesday news broke that Opera was going to support some Webkit CSS vendor prefixes. On its surface I thought this wasn't exactly big news. There was a good deal of hubbub about this back in February (Browser Makers Caving to Vendor Prefix Misuse) when word got out that Mozilla, Opera and Microsoft were all considering supporting the -webkit prefix.

Many standards-focused developers (including me) were horrified, even though this has been a concern for over two years (as I note in Perplexing Prefixes). Some of them even took action to either convince developers to fix their code, get like-minded developers to fix others' code, or petition browser makers not to cave.

I think it's fair to say that the first two tactics haven't worked. In light of that, it was just a matter of time before the browser makers would start supporting the dominant codebase — even if it's only dominant because of developer misuse.

Now Opera is catching a lot of heat from people for caving. Some are pointing to Microsoft's statement that it won't support the -webkit prefix as an example of how not to play the game. Others feel betrayed that Opera, often the most standards-compliant of all the browsers, would now make such a move. Few of these people consider the business case for Opera. Opera has dominated the mobile market, and when web sites don't render properly — because of a developer who is either not coding to standards or is not including the -o prefix alongside the -webkit prefix — users may move to the browser that doesn't look broken. Opera is making a business decision to protect itself.

Wednesday on Twitter I placed the blame at the feet of lazy web developers. I still feel that way. My previous posts on this topic have been clear on this. If web developers took the time to learn the specifications, look at code generated by editors (if they use them), tested in other browsers, and shed their myopic view of how people surf, we would not be in this position. Developers can fix the code, see errors when testing, and otherwise not cut corners. I suspect there are lots of developers who know this and lots more who can be educated by the names and voices on the web now.

And then I saw this, retweeted by Zeldman, possibly in a show of support:

I don't include the -o- prefix because I don't test in Opera because it accounts for 0.3% of our visitors. Not because I'm lazy or inept.

— Stephanie Hobson (@stephaniehobson) April 26, 2012

If her percentage is not hyperbole and applies to all the sites she manages, then the time it took her to see those numbers and produce that tweet is about how long it takes to open Opera and paste in a web address.

This is why the browser makers are caving. This attitude is pervasive. Hers is just one example. I have seen similar comments around the web, ranging from those who have no idea what browsers visit their sites to those who just don't care. Telling someone they are wrong, myopic, and definitely not serving the needs of their users, clients, or even the rest of the web, just causes that person to ignore you or lash out.

You can run the math yourself using the percentage in the tweet. Take a site with a million visitors and you'll see that 0.3% is 3,000 users. In accessibility circles, that's an unacceptable number of users to shut out. Imagine 0.3% is an acceptable number to ignore on a larger site, perhaps even as big as Facebook with 800 million users. At 0.3% that's 2.4 million users. At what number of users is 0.3% acceptable? How many developers of large sites feel bolstered by such an attitude, reinforcing their own poor habits?

The question to web developers really should be, how many users are you willing to sacrifice because you are too lazy to open a browser and at least look?

This example of webs.com shows that just opening the home page in Opera would have shown it's broken, meaning either they didn't look or they don't care. In Opera it looks like this (as compared to Safari), hiding its main sales pitch (the issue starts at line 86 of the webs.com CSS file):

There just isn't an excuse. Stop blaming the browsers and the editors and instead review your code and test in browsers.

Related

• Opera confirms WebKit prefix usage at .net Magazine. Read the comments, they include an Opera employee explaining the reasoning behind the -webkit support.


• Opera's supporting of the -webkit- prefix by Niall McMahon.


• A lively debate at Hacker News.


• On vendor prefixes and WODs by Ian Devlin.


• Opera Confirms WebKit Prefix Usage by Faruk Ateş.


• The Open Web and CSS prefixes by Daniel Glazman.

Posts that pre-date this news from Opera:

• CSS vendor prefixes considered harmful, March 22, 2010 by Peter-Paul Koch.


• Not Supported, March 22, 2010 by Jonathan Snook.


• Coping with CSS vendor prefixes, March 22, 2010 by Stephen Hay.


• CSS vendor prefixes redux, March 23, 2010 by Peter-Paul Koch.


• Vendor Prefixes Are Hurting the Web, November 15, 2011 by Henri Sivonen.


• CSS vendor prefixes, an answer to Henri Sivonen, November 16, 2011 by Daniel Glazman.


• Vendor Prefixes Are A Rousing Success, November 18, 2011 by Alex Russell.


• Perplexing Prefixes, November 22, 2011 by me.


• The vendor prefix mess, February 9, 2012 by Peter-Paul Koch.


• Browser Makers Caving to Vendor Prefix Misuse, February 9, 2012 by me.


• Vendor prefixes are not developer-friendly, March 4th, 2012 by Paul Irish.

And a post that pre-dates all of this stuff:

• To Hell with Bad Editors, February 28, 2001 (also at evolt.org) where 11 years ago I don't accept that browsers are the issue (To Hell With Bad Browsers), I put the blame squarely on developers. Apparently we are doomed to keep repeating the same mistakes.

Update 11:40am

Opera has posted the announcement about the vendor prefix changes: Opera Mobile Emulator build with experimental WebKit prefix support. If you read through it, you will see only 13 -webkit properties (shadow, transform, border, transition) which are just being aliased to existing -o prefixes. It looks like Opera is not trying to mimic how Webkit renders the styles, only map the prefixes to Opera's existing support.

Update April 30, 2012

More posts and articles have surfaced over the weekend and today. I link them here:

• Concerns About Opera Rendering Webkit Properties by Ian Lunn.


• On Opera’s Implementation of WebKit Aliasesby Peter Gasston.


• Prefixes by Anne van Kesteren.


• Opera Mini Now Has 169 Million Users, 56% Of Them Only Use The Mobile Web at TechCrunch.

Update May 2, 2012

• Why O, why? Thoughts on Opera's Implementation of WebKit's Prefixes at WebKitbits.


• Vendor Prefixes, the wider problem by Matt Wilcox.


• CAFBank and Server Side User Agent Sniffing from Opera, showing how a bank ignores a 5-year-old request from users and Opera to stop explicitly blocking Opera. An example of blocking for no good (presented) reason.

Update July 6, 2012

Thiemo Mättig tried to comment below, but had trouble with the form. He let me know that he reached out to Webs.com to notify them of the bad CSS I mention above. All Webs.com did was add a solid background color, no -o- prefix and no unprefixed version.

@maettig Thanks for the notice

— Webs.com (@webs) May 2, 2012

@maettig This is not one of the browsers that we currently support at this time.

— Webs.com (@webs) May 14, 2012

Read More

WHATWG as W3C Community Group in Name Only

As of Monday, April 23, The W3C has announced that it is looking for a new editor for the HTML Working Group specifically tasked with shepherding HTML5 through the process until it reaches a formal recommendation. Ian Hickson (Hixie) made the request for a call for his replacement so he could focus on ongoing HTML development, such as HTML.Next. With that announcement the W3C is also making the following changes:

• The W3C is beginning its replacement editor search specifically for HTML5 and HTML Canvas 2D Context to carry them both through the Recommendation phase of the specification process. The W3C expects the process to take 30 days, though it isn't clear if that means it will have candidates to consider at the end of the 30 days or a new editor by then.


• The W3C reminds us that W3C Community Groups and HTML WG Task Forces can continue to submit proposals to the specification.


• Hixie, the current HTML5 editor, will continue working on the WHATWG HTML specification. Though it will be versionless, the W3C expects it to spin off proposals to its HTML WG.


• The W3C states that editors of "Recommendation-Level" specifications (specs going through the W3C process, with versions) and authors of HTML.next (the WHATWG versionless specs) are free to make changes directly to their own specs, but the W3C is urging them to work together.


• The W3C is expanding the W3C HTML WG charter to allow it to work on HTML.Next at the same time the HTML5 specification is snaking its way through the official process. Once that happens, the W3C will be looking for more editors.


• The W3C is making clear that it plans to continue its partnership with WHATWG.

The W3C also created the Web Hypertext Application Technology Community Group on Monday. Given that W3C Community Groups allow open participation and can submit proposals for the specification, it looked like the W3C and WHATWG might be coming together and possibly opening up to more community feedback.

The potential and hope of moving all HTML5 (etc) development under one organization was quickly dashed when Hixie sent this message to the WHATWG mailing list:

[…] [I]t means we have a clear patent
policy. Historically, we've relied on the W3C HTML working group for this,
but as the W3C has focused on stablising their HTML5 snapshot, newer
features have not enjoyed the same coverage. […] This will basically have no effect
on how the WHATWG operates, except that when we make use of the W3C
Community Group "Final Specification Agreement" (FSA) mechanism, anyone
who wishes to co-sign the agreement [2] will be invited to do so.

The W3C Web Hypertext Application Technology Community Group echoes that message:

This is the W3C community group for the WHATWG, a mechanism through which the WHATWG can publish specifications with patent agreements.

At first glance it may have looked like WHATWG was coming together with the W3C, and by using a W3C Community Group allowing anyone to participate, but that does not appear to be the case. Instead this move seems to primarily be a method to bring WHATWG into the patent protection that the W3C enjoys through some of its partnerships, as suggested by Steve Faulkner:

but the Hypertext Application Technology Community Group appears to be
nothing more than a ploy to get microsoft on board at the WHATWG via the
provision of a patent policy.

Any hints of bringing WHATWG into the W3C fold appear to be gone. Any hope that anyone can participate appears to be dashed as well, since it doesn't look like the Community Group will have its own mailing list and the forum will likely be ignored.

Unfortunately, I was quick to sign up for the Web Hypertext Application Technology Community Group but took far too long to realize it wasn't going to change the process of participation. I suppose I could blame patent chaos for all of this, or I could just accept that the HTML5 process isn't going to change.

Read More

Dining in the Dark

A blindfolded photo attempt of my meal, served and eaten in near darkness. Thankfully it turns out that my aim with my fork was better than my aim with my cellphone camera.

Two weeks ago our longtime client Olmsted Center for Sight (formerly the lengthily-named Elizabeth Pierce Olmsted, M.D. Center for the Visually Impaired) held a benefit dinner titled “Dining in the Dark.” The concept was quite simple and given away by its name — attendees would enjoy a meal in total darkness. Not only did my company co-sponsor the event, I attended it and had the pleasure of dining with Olmsted's president.

The meal started off with wine and salad, which you were allowed to eat in light. Then we were presented with bibs and blindfolds, and the lighting was turned down to just the candles on the table (the servers needed to see, after all). And so in darkness we set upon the main course followed by the dessert course and wrapped up with coffee service. During the main course an Olmsted representative guided us through techniques to get the lay of the land, identify foods, cut meat, find drinks and so on. I ignored all this and dove in with my characteristic nonchalance about my meal and found myself stymied by the simplest things — it takes a couple tries to realize your knife is upside down and that you are cutting with the blunt edge and not the sharp edge.

I have spent over a decade working with Olmsted Center for Sight. I have had the opportunity to see how its clientele/constituency uses computers and surfs the web. I have attended seminars, spoken at events, been a part of lawmaking discussions, implemented software and web sites, all in my time consulting with Olmsted. I have been working with low-vision and blind users for most of my professional career, but nearly always in the form of technology. Though I had some time running concerts for thousands of attendees and making sure outdoor and non-standard venues were handicapped accessible, this dinner afforded the chance for me to experience some of the day-to-day tasks that I take for granted, but this time without sight.

This post may seem to be a little outside of my generally technical discussions here, but I believe that experiences like this are important for anybody who cares about inclusive design or accessibility. Some day everyone reading this will have reduced vision, mobility, hearing, and so on. Learning now how to design and build to support those changes serves to position future generations of developers to design and build to support the future you. That's just a good investment in your long term well-being.

Consider spending an hour blindfolded and try to do a mundane task like get dressed, eat a meal, or even use the web to look up a menu on a web site (you've already seen me rant about how awful that experience is for average users). Consider limiting your movement, restricting yourself to a chair, putting in earplugs, and so on. You may find your get far more insight into daily life as well as software and web development than you expected.

If you're still reading and also care about accessibility, then in keeping with the low vision theme of this post here are some resources to use when developing sites for the blind. This is not an exhaustive list by any means, but there are links to many others within.

• Screen reader demos, research and resources by Alistair Duggin. Written the day after my dinner.


• Web Accessibility Toolbar 2012 from The Paciello Group. A handy resource to validate and review any page you are viewing.


• The NonVisual Desktop Access (NVDA) screen reader (MS WIndows) is a free resource (for which you should donate) that can help you understand how a site is "heard" by a blind user.

This handy video shows you how blind people use the iPhone 4S. It's worth a couple minutes of your time.

This link isn't a resource, instead it's a story of a police department using its forensic techniques to help save 26 pages of hand-written content after the blind writer's pen ran out of ink.

Read More

Speaking at Buffalo's Entrepalooza 2012 - May 10

Buffalo has had an Entrepalooza event for eight years now that caters to small businesses, start-ups, and any manner of entrepreneur. University at Buffalo's Center for Entrepreneurial Leadership Alumni Association (CELAA) has also run an Ask the Experts session of round-table discussions along with an expo for local small businesses. This year they have been merged into one. Combined with the efforts of Buffalo Niagara Partnership and Buffalo Niagara Sales and Marketing Executives, this looks to be be a sizable event.

I will be running one of the round-table discussions as an invited expert, which will consist of attendees of varying levels of technical skill and knowledge. It's a great opportunity for me to hear about the needs and expectations of small businesses and get away from just talking to people who live in my world all day long, or in the case of clients, much of their day. The description of my discussion:

Small businesses have different needs on the web, but also common goals. We'll address how to keep your business goals in mind as we discuss creating a web presence. Expect to cover mobile trends, social media, HTML5, sites powered by content management systems, Facebook pages, how to debunk bad SEO advice, and other web-related questions you pose.

I argue that the price of admission is worth it just to come and ask me questions.

You can find more information about the event in the press release at the BNSME site or the same press release at the CELAA site.

To sign up, press the "Continue" button below the event info on the BNSME page. For those web pros reading this, I have nothing to do with these sites.

More information:

The Signature Event With Expo & Experts

Thursday – May 10, 2012

Buffalo Niagara Convention Center / Downtown Buffalo

A New Twist on Two Major Events!

The 8^th Annual Entrepalooza and the CELAA Expo & Experts

Combining the highly successful Entrepalooza with the CELAA Ask the Experts & Expo event brings together more than 300 business owners, executives, and members of the Western New York business community. You will meet 60 exhibiting businesses, share roundtable discussions with 27 unique Experts and learn how to become a Breakthrough Company, the Entrepalooza Main Event, featuring renowned international speaker and author Keith McFarland.

Read More

Where's the Viewport Size Data?

StatCounter released data on Wednesday showing that the screen resolution of 1,366 x 768 has surpassed 1,024 x 768 as the most common screen resolution. If you've paid attention to the drive for widescreen displays on newer machines, this may not come as much of a surprise to you. I find it more surprising nobody has commented on the decline of most higher resolutions.

What was surprising was this quote in the release:

The screen resolution size people are using is a critical factor for developers when it comes to web design, particularly in the case of fixed width web pages.

For web developers who still develop fixed-width layouts, especially targeting 1,024 x 768, this doesn't matter. Those developers are already lost to us.

For developers who know that screen resolution doesn't necessarily equate to window, and by extension viewport, sizes then this still doesn't matter.

For developers who actually understand the concepts behind responsive web design (RWD) then this doesn't matter.

As anyone in this space knows, that minor shift in numbers that put the wider screen resolution (still the same height) just above the previous champ doesn't require a change to our processes. A skilled developer already has taken the time to assess the audience of a site, or when that data is unknown, is already coding and designing to accommodate various screen resolutions and window sizes. The only real challenge here is protecting our clients from hearing those data points in a vacuum and trying to react. We just need to be smart about counseling them.

That hasn't stopped it from getting a fair amount of attention from the more well-known web folk. Over at .net Magazine (Browser screen resolution stats rile devs) there are some quotes that seem a bit too reactive, along with some that are a fair bit smarter.

If you are somehow caught up with concerns over screen resolutions (and there are some valid reasons to be), then just don't forget that viewport sizes aren't the same as screen resolutions. Scrollbars, button bars, and other browser chrome all take away from that space. Twelve (12!) years ago I wrote a couple of articles addressing that, one of which gathered and presented all the data: Real-World Browser Size Stats, Part II. Last year Chris Coyier wrote a similar article: Screen Resolution ≠ Browser Window. This isn't new stuff.

If you want to take StatCounter to task for anything, then ask them this — where is the viewport size data?

Read More

Announcing PrintShame.com

For many years I've pushed for print styles for sites. It's an easy step to take in the course of developing a site, easy to test, and the techniques to do it have been around for over a decade. Something as rigid as a tabled layout could be relatively easily wrangled into a print-friendly document — without breaking any budgets.

With all the excitement over supporting mobile devices, web developers have been adopting the concept of responsive web design (RWD), which allows your layouts to scale and reflow based on the device and browser size the visitor is using. Yet somehow the gee-whiz factor of these techniques has not helped the printed page, particularly on web sites that are often regarded as great examples of RWD.

This weekend I was looking at sample sites that either proudly proclaim their RWD heritage, or which are held up by others as great examples of RWD. Having already been burned by sites that take a dozen pages to print one tiny piece of content I started testing their print styles and found that, for the most part, they had none. I decided that perhaps the only way to get anyone to address this was to use shame.

I registered PrintShame.com, made a new Blogger site (the same platform my personal blog uses), and got to work gathering the printed output of sites as PDF files to share with everyone.

I am only grabbing sites that claim to be the result of RWD and for now I am pulling URLs from Media Queries, a site that gathers examples of responsive design. The collection of sites can be ordered by popularity and so that's how I've started. I am excluding some that aren't fully built (though I have no idea why they are listed and ranked so well), but for the most part I am just grabbing what's there. I will probably also grab other sites that folks recommend, as I did in one of the posts I link below.

The process is quite simple: I capture a screen shot of the site in my 1,024 x 1,024 Firefox window with all my normal chrome. I also print the page to PDF. Usually I use the home page, but sometimes it's not appropriate and so I grab a contact page, an article, a product page, or even an event schedule. Then I post the screen shot and the PDF to Print Shame with a link to the original page.

Sometimes the printed pages are abysmal, and sometimes they aren't so bad. I am only posting them if there is something that I find poorly done. This ranges from excessive number of pages to failure to include the brand on the printed page. I am also posting without comment. I figure if a site owner sees his or her site there and thinks that the print output looks good, then that site owner probably needs to redefine his or her goals with the site.

You may note that Print Shame doesn't have print styles. That's a function of using Blogger. I don't really care to make a full RWD site with print templates and the like when it's far faster to just do fly-by postings in my otherwise busy life. Poorly-built sites without print styles have already taken enough of my time.

With this site I hope to demonstrate how some of these well-regarded responsive sites and show how they fall short in the most basic ways. Perhaps this is the only way to get site owners to pay attention.

Some relevant articles / blog posts:

• More Evidence of the Need for Print Styles, April 6, 2012.


• Test in Lynx and Print, It's Your Job, December 12, 2011.


• More Samples of Responsive Web Design ≠ Print, October 13, 2011.


• Print Styles Forgotten by Responsive Web Developers, October 3, 2011.

Read More

More Evidence of the Need for Print Styles

Readers of this blog know of my regular frustration with web sites that don't have print styles. Part of this is fueled by all the lip service supposed responsive web developers pay to adapting to different screen sizes, but who fail to consider the printed page when we've had support for over a decade now.

Yesterday I stumbled across the site PrintFriendly. It promises to remove "Ads, Navigation and web page junk" (odd capitalization theirs). It positions itself as a way to save paper and ink and offers both a button for your browser toolbar to clean up sites like CNN when you print them, and a button for your own site to allow users to print your content. It can also output PDF documents if you don't want to print to paper.

For End Users

As someone who frequents sites that don't print well, I can tell you that this service can be handy. For the CNN page I tested (PDF of page fed through PrintFriendly) — which is linked off the PrintFriendly home page as an example — it clears out the banner imagery, advertisements, navigation, and lots of other cruft. It also removes the branding and turns the links in the page to light gray, making them a bit hard to see. As someone who has chosen to print a page from CNN, I know where it came from, but I can't quite forgive the too-light links.

In a previous post, you may recall samples I provided of highly-regarded responsive sites that have terrible print styles, specifically the Ampersand Conference (PDF of the printed schedule) and the New Adventures in Web Design 2012 conference (PDF of the printed schedule).

other than some minor oddities, the New Adventures in Web Design 2012 conference (PDF of page fed through PrintFriendly) fares pretty well. The Ampersand Conference page (PDF of page fed through PrintFriendly), however, doesn't and all the content is lost beyond the logo and a quick intro.

I may use it for those rare times I need to print an article from a major site that doesn't provide any print options at all. It can come in handy.

For Businesses/Organizations

PrintFriendly gives you the option to add its print button to your web site. This is geared to web site owners who don't have print friendly pages as well as blog owners who have no control over print styles (or lack thereof).

That there are organizations out there that consider this a viable option at all is absurd. Let me explain why…

To test it, I dropped the JavaScript-powered widget on an article on my site and printed some pages. You can compare the PDF version of my article using my print styles with the PDF version of the same article from PrintFriendly.

Loss of Control over Content

When I use the feature to print a page, I am given the option to remove imagery and any other element on the page. I can remove entire paragraphs of content from the printed page of a site I do not control. In addition, my footer is removed, which means if my contact information was there (phone, mailing address), it's gone now. The footer is also where I keep my copyright statement and some additional branding, which are both lost as a result.

Users may have a valid reason to remove elements of your content, usually to fit on a page, but what about users who may just want to print cherry-picked content to push an agenda? Are you also willing to let whatever content sits in your footer be purged? Someone motivated by your content while reading from paper is already offline, and a phone number or address is that much more valuable to display.

Advertisements Presented to Users

After printing I am presented with a box of advertisements. I saw ads for used tennis machines, metal forming machines, ultrasonic cleaners, and one large graphic ad for vending machines. None of these compete with what I offer in any way. They don't appear to be keyed off my content, but I cannot be certain.

If you sell a service or a product, are you willing to take the risk that users to your site, when printing a page, may be offered advertisements for your competition? Will those users understand that you don't endorse those services or products even if they aren't competition? Are you willing to take that risk?

Loss of Branding

The first thing I noticed on the printed pages I tried was that the branding was typically removed. Seemingly whatever lives at the top of the page, which probably contains your logo, tagline, and perhaps other important details, is removed. Even my site was affected, and I use text for my "logo" and tagline.

Considering how much effort (time and money) you may have spent in tweaking your brand and message for your site, are you comfortable having it summarily removed from every printed page? When the end user passes this printed page along to another, do you feel you are losing an opportunity to present your brand to the next reader?

Page Reformatting

There are elements of copy or imagery that are intentionally positioned in my content to draw visual connections. For non-visual users I make sure it linearizes (that's how it starts). But since the printed page is a visual medium, I often rely on the ability to continue to maintain those visual relationships. Those are discarded in the PrintFriendly version of the page.

If you have sidebars, pull-quotes, or other elements that are distinct from the main content and may be confusing to users not used to seeing content linearized (which are nearly all sighted users), then you may find reading comprehension suffers. It will take some effort to identify all the elements of content on your site and test how they behave in this model.

Find a New Web Developer

Any current web developer who cannot or will not create print styles for your site is probably not someone you want to use anymore. Even if your web developer isn't up on the new hotness of responsive web design techniques, that's not an excuse. Print styles pre-date nearly everything going on with the web now. Print styles work with tabled layouts, with ads, with all sorts of elements on your page. There is no good excuse not to include them in any web site built within the last 10 years.

If your web developer recommends PrintFriendly, make sure you understand why. If the answer is couched in lack of technical ability to develop print styles or just laziness, the decision should be pretty easy.

Related

• Test in Lynx and Print, It's Your Job


• More Samples of Responsive Web Design ≠ Print


• Print Styles Forgotten by Responsive Web Developers

Read More

W3C CSS Odor Module Released

The web was always a visual medium, but with the addition of sound and video it has locked up two human senses. With development of specifications and techniques around vibration, the internet you "feel" is getting closer, too. That leaves only a couple senses left to cover

Ever since the late 90s, companies have proposed different methods for bringing the sense of smell to the web. If successful it's a necessary lead-in before taste can be transmitted (since so much of taste is based on smell). That day is even closer as of this week.

Previous attempts failed (DigiScent, RealAroma) partly because they were attempting to encode core odor indicators in markup, making for bulky pages with strings of adjectives to describe certain smells. They lacked more subtle indicators of smells, relying instead on keywords (such as rose, which can vary greatly depending on many biological factors). This variance in odor has contributed to the other key reason other proposals have failed — hardware makers struggling with consistent smells. These are the reasons that the ATML (Aroma Text Markup Language) and OML (Olfactory Markup Language) never took off.

The W3C is now trying its hand at bringing smell to the web. Just as CSS separates things like color style from markup, it will also be the driving force behind smell — W3C CSS Odor Module.

Just as colors are defined in CSS3 as RGB values with transparency (RGBA), smells are defined in Odor CSS by the base taste flavors (to promote accessibility for those with reduced or damaged olfactory function) along with intensity. The base taste flavors should look familiar to most of us: sweet, bitter, sour, salty, and umami.

Future plans for taste will include texture, but that will rely on coming haptic technology development that doesn't exist yet.

The CSS markup will look familiar too, since the syntax is designed to lean on developers' experience with color, using percentages for the base "flavors" and a decimal value for intensity (similar to transparency):


#rose {

  odor: s(78%,7%,3%,0%,23%,0.4);

  /* sweet, bitter, sour, salty, umami, intensity */

}

#steak {

  odor: s(5%,18%,8%,27%,89%,0.8);

  /* sweet, bitter, sour, salty, umami, intensity */

}


Browser makers are already throwing support behind the specification, probably because they only need to put together an API. Producing the smells will be up to hardware makers. If you want to experiment, Opera and Firefox are already working support into their plans, and Webkit nightlies have support for it as well. A pre-fixed version of the above would like this:


#rose {

  -mozilla-odor: s(78%,7%,3%,0%,23%,0.4);

  -webkit-odor: s(78%,7%,3%,0%,23%,0.4);

  -o-odor: s(78%,7%,3%,0%,23%,0.4);

  odor: s(78%,7%,3%,0%,23%,0.4);

  /* sweet, bitter, sour, salty, umami, intensity */

}

#steak {

  -mozilla-odor: s(5%,18%,8%,27%,89%,0.8);

  -webkit-odor: s(5%,18%,8%,27%,89%,0.8);

  -o-odor: s(5%,18%,8%,27%,89%,0.8);

  odor: s(5%,18%,8%,27%,89%,0.8);

  /* sweet, bitter, sour, salty, umami, intensity */

}


Now all we need is some sort of hardware to identify the different intensities that make up an odor, otherwise experimentation might make for some awful results. I doubt a Smell of Books-style solution will fit for this since I don't have enough hands to spray five different flavors, nor the skill to spray in the right intensity.

Update, April 1, 2013

It is my understanding from the folks at Opera who are working on all-things-web-for-your-TV that the CSS Odor Module will play a big part in the technology behind this story from New Scientist: Smell-o-vision screens let you really smell the coffee (March 29, 2013).

When Matsukura, the inventor of the display, says the next stage is to incorporate a cartridge, like those for printers, which allows smells to be changed easily, what he's referencing is the mapping of the odors as outlined in the specification.

Update, November 21, 2013

Example of this technology in action (read more):

Read More