Posts in the Standards Category

Color Easing Isn’t Always Easy

Published 1 month, 3 weeks ago

A fairly new addition to CSS is the ability to define midpoints between two color stops in a gradient.  You can do this for both linear and radial gradients, but I’m going to stick with linear gradients in this piece, since they’re easier to show and visualize, at least for me.

The way they work is that you can define a spot on the gradient where the color that’s a halfway blend between the two color stops is located.  Take the mix of #00F (blue) with #FFF (white), for example.  The color midway through that blend is #8080FF, a pale-ish blue.  By default, that will land halfway between the two color stops.  So given linear-gradient(90deg, blue 0px, white 200px), you get #8080FF at 100 pixels.  If you use a more generic 90deg, blue, white 100%, then you get #8080FF at the 50% mark.

linear-gradient(90deg, blue, white 100%)

If you set a midpoint, though, the placement of #8080FF is set, and the rest of the gradient is altered to create a smooth progression.  linear-gradient(blue 0px, 150px, white 200px) places the midway color #8080FF at 150 pixels.  From 0 to 150 pixels is a gradient from #F00 to #8080FF, and from 150 pixels to 200 pixels is a gradient from #8080FF to #FFF.  In the following case, #8080FF is placed at the 80% mark; if the gradient is 200 pixels wide, that’s at 160 pixels.  For a 40-em gradient, that midpoint color is placed at 32em.

linear-gradient(90deg, blue, 80%, white 100%)

You might think that’s essentially two linear gradients next to each other, and that’s an understandable assumption.  For one, that’s what used to be the case.  For another, without setting midpoints, you do get linear transitions.  Take a look at the following example.  If you hover over the second gradient, it’ll switch direction from 270deg to 90deg.  Visually, there’s no difference, other than the label change.

linear-gradient(<angle>, blue, white, blue)

That works out because the easing from color stop to color stop is, in this case, linear.  That’s the case here because the easing midpoints are halfway between the color stops—if you leave them out, then they default to 50%.  In other words, linear-gradient(0deg, blue, white, blue) and linear-gradient(0deg, blue, 50%, white, 50%, blue) have the same effect.  This is because the midpoint easing algorithm is based on logarithms, and is designed to yield linear easing for a 50% midpoint.

Still, in the general case, it’s a logarithm algorithm (which I love to say out loud).  If the midpoint is anywhere other than exactly halfway between color stops, there will be non-linear easing.  More to the point, there will be non-linear, asymmetrical easing.  Hover over the second gradient in the following example, where there are midpoints set at 10% and 90%, to switch it from  270deg to 90deg, and you’ll see that it’s only a match when the direction is the same.

linear-gradient(<angle>, blue, 10%, white, 90%, blue)

This logarithmic easing is used because that’s what Photoshop does.  (Not Mosaic, for once!)  Adobe proposed adding non-linear midpoint easing to gradients, and they had an equation on hand that gave linear results in the default case.  It was also what developers would likely need to match if they got handed a Photoshop file with eased gradients in it.  So the Working Group, rather sensibly, went with it.

The downside is that under this easing regime, it’s really hard to create symmetric non-linear line gradients.  It might even be mathematically impossible, though I’m no mathematician.  Regardless, its very nature means you can’t get perfect symmetry.  This stands in contrast to cubic Bézier easing, where it’s easy to make symmetric easings as long as you know which values to swap.  And there are already defined keywords that are symmetric to each other, like ease-in and ease-out.

If you’re up for the work it takes, it’s possible to get some close visual matches to cubic Bézier easing using the logarithmic easing we have now.  With a massive assist from Tab Atkins, who wrote the JavaScript I put to use, I created a couple of CodePens to demonstrate this.  In the first, you can see that linear-gradient(90deg, blue, 66.6%, white) is pretty close to linear-gradient(90deg, blue, ease-in, white).  There’s a divergence around the 20-30% area, but it’s fairly minor.  Setting an interim color stop would probably bring it more in line.  That’s partly how I got a close match to linear-gradient(90deg, blue, ease-out, white), which came out to be linear-gradient(90deg, blue, 23%, #AFAFFF 50%, 68%, white 93%).

Those examples are all one-way, however—not symmetrical.  So I set up a second CodePen where I explored recreations of a few symmetrical non-linear gradients.  The simplest example matches linear-gradient(90deg, blue, ease-in, white, ease-out, blue) with linear-gradient(90deg, blue, 33.3%, white 50%, 61.5%, #5050FF 75%, 84%, blue 93%), and they only get more complex from there.

I should note that I make no claim I’ve found the best possible matches in my experiments.  There are probably more accurate reproductions possible, and there are probably algorithms to work out what they would be.  Instead,  I did what most authors would do, were they motivated to do this at all: I set some stops and manually tweaked midpoints until I got a close match.  My basic goal was to minimize the number of stops and midpoints, because doing so meant less work for me.

So, okay, we can recreate cubic Bézier easing with logarithmic midpoints.  Still, wouldn’t it be cool to just allow color easing using cubic Béziers?  That’s what Issue #1332 in the CSS Working Group’s Editor Drafts repository requests.  From the initial request, the idea has been debated and refined so that most of the participants seem happy with a syntax like linear-gradient(red, ease-in-out, blue).

The thing is, it’s generally not enough to have an accepted syntax—the Working Group, and more specifically browser implementors, want to see use cases.  When resources are finite, requests get prioritized.  Solving actual problems that authors face always wins over doing an arguably cool thing nobody really needs.  Which is this?  I don’t know, and neither does the Working Group.

So: if you have use cases where cubic Bézier easing for gradient color stops would make your life easier, whether it’s for drop shadows or image overlays or something I could never think of because I haven’t faced it, please add them to the GitHub issue!


CSS4 Color Keyword Distribution Visualization

Published 2 months, 2 weeks ago

Long, long ago—not quite seven years ago, in fact—I built a canvas-based visualization of the distribution of CSS3/SVG color keywords and released it.  And there it’s sat, static and inert (despite being drawn with a whooooole lotta JS) ever since.

I’ve always meant to get back to it and make it more interactive.  So over the past several evenings, I’ve rebuilt it as an SVG-based visualization.  The main point of doing this was so that when you hover the mouse pointer over one of the little color boxes, it will fill the center of the color wheel with the hovered color and tell you its name and HSL values.  Which it does, now.  It even tries to guess whether the text should be white or black, in order to contrast with the underlying color.  Current success rate on that is about 90%, I think.  Calculating perceived visual brightness turns out to be pretty hard!

Other things I either discovered, or want to do better in the future:

  • Very nearly half the CSS4 (and also CSS3/SVG) color keywords are in the first 90 degrees of hue.  More than half are in the first 120 degrees.
  • There are a lot of light/medium/dark variant names in the green and blue areas of the color space.
  • I wish I could make the color swatches bigger, but when I do that the adjacent swatches overlap each other and one of them gets obscured.
  • Therefore, being able to zoom in on parts of the visualization is high on my priority list.  All I need is a bit of event monitoring and some viewbox manipulation.  Well, that and a bit more time. Done, at least for mouse scroll wheels.
  • I’d like to add a feature at some point where you type text, and a list is dynamically filtered to show keywords containing what you typed.  And each such keyword has a line connecting it to the actual color swatch in the visualization.  I have some ideas for how to make that work.
  • I’d love to create a visualization that placed the color swatches in a 3D cylindrical space summarizing hue, lightness. and saturation.  Not this week, though.
  • I’m almost certain it needs accessibility work, which is also high on my priority list.
  • SVG needs conic gradients.  Or the ability to wrap a linear gradient along/inside/around a shape like a circle, that would work too.  Having to build a conic gradient out of 360 individual <path>s is faintly ridiculous, even if you can automate it with JS.
  • And also z-index awareness.  C’mon, SVG, get it together.

Anyway, here it is: CSS4 Color Keyword Distribution.  I hope you  like it!


How Do I Increase Accessibility?

Published 1 year, 5 months ago

I have an accessibility question.  Okay, it’s a set of questions, but they’re really all facets of the same question:

How do I make my site’s structure the most accessible to the most people?

Which sounds a bit broad.  Let me narrow it down.  Here’s the basic layout order of most pages on meyerweb:

  1. Masthead
  2. Navigation (in a <nav> element)
  3. Main page content (in a <main> element), occasionally with a sidebar
  4. Footer (in a <footer> element)

But this is, at the moment, the source order of those pieces:

  1. Masthead
  2. Main page content (in a <main> element), occasionally with a sidebar
  3. Navigation (in a <nav> element)
  4. Footer (in a <footer> element)

The difference is the navigation.  I put it later in the source order because I want those using speaking browsers to be able to get the content quickly, without having to tab through the navigation on every page.

But is that actually a concern, given my use of a <main> element for the main content of the page?  And the <nav> and <footer> elements, do those also help with jumping around the page?  If not, what’s the best-practice structural order for those pieces?

If so, does that mean it’s okay to put the navigation back up there in the source order, and stop doing wacky things with the order element to place it visually where it isn’t, structurally?

I have the same questions for those who use keyboard tabbing of the visual layout, not speaking browsers.  What’s the best way to help them?  If it’s tabindex, how should I order the tabbing index?

And in either case, do I need skip links to get people around quickly?  Do I want skip links?  Do my assistive-technology users want skip links?

Maybe the real question is “Given this layout, and my desire to make getting to main content and other pieces of the page as easy as possible for those who rely on assistive technology, how should I structure and annotate the content to raise the fewest barriers for the fewest people?”

Unless, of course, the real question is one I don’t know enough to ask.

Can you help me out, accessibility hivemind?  I’d really appreciate some expert insight.  All my instincts are more than a decade out of date.


CSS Grid!

Published 2 years, 6 months ago

The Grid code is coming!  The Grid code is coming!  It’s really, finally coming to a browser near you!  Woohooooo!

Whoa, there.  What’s all the hubbub, bub?

CSS Grid is going to become supported-by-default in Chrome and Firefox in March of 2017.  Specifically, Mozilla will ship it in Firefox 52, scheduled for March 7th.  Due to the timing of their making Grid enabled-by-default in Chrome Canary, it appears Google will ship it in Chrome 57, scheduled for March 14th.  In each case, once the support is enabled by default in the public-release channels—that is to say, the “evergreen” browser releases that the general public uses—every bit of Grid support now in place in the developer editions of the browsers will become exposed in the public releases.  Anything Grid will Just Start Working™®©.

Are those dates an ironclad guarantee?

Heck no.  Surprise problems could cause a pushback to a later release.  The release schedule could shift.  The sun could explode.  But we know the browsers already have running code for Grid, and when they mark something as ready for public release, it usually gets released to the public on schedule.

So Grid support in March, huh?

Yep!

How long until I can actually use Grid, then?  Two or three years?

March 2017.  So about four months from now.

But it won’t be universally supported then!

Rounded corners aren’t universally supported even now, but I bet you’ve used them.

Now you’re just being disingenuous.

Look, I get it.  Base layout’s a little different than shaving pixels off corners, it’s true.  If you have a huge IE9 user base, converting everything to Grid, and only Grid, might be a bit much.  But I’m guessing that you do have a layout that functions in older browsers, yes?

Of course.

Then my original answer stands: March 2017.  Because any browsers that understand Grid will also understand @supports(), and you can use that to have a Grid layout for Grid-enabled browsers while still feeding a float-and-inline-block layout to browsers that don’t understand Grid.  Jen Simmons wrote a comprehensive article about @supports(), and I wrote a short article demonstrating its use to add layout enhancements.  The same principles will apply with Grid: you can set up downlevel rules, and then encapsulate the hot new rules in @supports().  You can retroactively enhance the layouts you already have, or take that approach with any new designs.

Writing two different layouts for the same page doesn’t sound like a good use of my time.

I get that too.  Look at it this way: at some point, you’re going to have to learn Grid.  Why not learn it on the job, experimenting with layouts you already understand and know how you want to have behave, instead of having to set aside extra time to learn it in a vacuum using example files that have nothing to do with your work?  You’ll be able to take it at your own pace, build up a new set of instincts, and future-proof your work.

Can’t I just wait until someone creates a framework for me?

You could, except here’s the thing: as Jen Simmons has observed, Grid is a framework.  Using a framework to abstract a framework seems inefficient at best.  I mean, sure, people are going to do it.  There will be Gridstraps and GAMLs and 1280.gses and what have you.  And when those are out, if you decide to use one, you’ll have spend time and energy learning how it works.  I recommend investing that time in learning Grid Actual, so that you can build your own layouts and not be constrained by the assumptions that are inevitably baked into frameworks.

Grid sounds like tables 2.0.  I thought we all agreed tables for layout were a bad idea.

We agreed table markup for layout was a bad idea, particularly because at the time it was popular, it required massive structural hacks just to get borders around boxes, never mind rounded corners.  The objection was that it took 50KB of HTML tags and three server calls just to do anything, and 100 times that to set up a whole page’s layout, plus table markup locked everything into a very precise source order that played merry hell with any concept of accessible, searchable content.  The objection wasn’t to the visual result.  It was to what it took to get those results.

With Grid, you get the ability to take simple, accessible markup, and lay it out pretty much however you want.  You can put the last element in the source first in layout, for example.  You can switch a couple of adjacent bits of the page.  Questions like “how do I order these elements to get them to lay out right?” become a thing of the past.  You order them properly, and then lay them out.  It’s the closest we’ve ever gotten to a clean separation between structure and presentation.

Not only that, but thanks to CSS transforms, clipping paths, float shapes, and more, you don’t have to make everything into a perfectly-edged grid layout.  There is so much room for visual creativity, you can’t even imagine.  I can’t even imagine.  Nobody can.

So Grid solves every single layout question we’ve ever had, huh?  Layout Nerdvana for all?

Oh, no, there are still things missing.  Subgrid didn’t make it into these releases, so there will still be some gridlike layouts that seem like they should be simple, but will actually be difficult or impossible.  You can’t style a grid cell or area directly; you have to have a markup element of some sort to hang there and style.  All grid areas and cells have to be rectangular—you can’t have an L-shaped area, for example.  Grid gaps (“gutters”) can only be of uniform size on a given axis, very much like border-spacing in table CSS.

You can usually fake your way around these limitations, but they’re still limitations, at least for now.  And yeah, there will probably be bugs found.  If not bugs, probably unexpected use cases that the spec doesn’t adequately cover.  But a lot of people have worked really hard over an extended period of time on stamping out bugs and supporting a variety of use cases.  This is solid work, and it’s going to ship in that state.

What happens if Firefox or Chrome pushes Grid back a release or two, but the other ships on schedule?

In that case, it will take a little longer for your @supports()-encapsulated Grid rules to be recognized by the tardy browser.  No big deal.  The same applies to MS Edge, which hasn’t caught up to the new Grid syntax even though it was the first to ship a Grid implementation—with different rules, all behind prefixes.  Once Edge gets wise to the new syntax and behaviors, your CSS will just start working there, same as it did in Firefox and Chrome and any other browser that adds Grid.

All right, so where can I go to learn how to use it?

There are several good resources, with more coming online even now.  Here are just a few:

  • The Experimental Layout Lab of Jen Simmons — great for seeing layout examples in action using a variety of new technologies.  If you’re laser-focused on just Grid, then start with example #7, “Image Gallery Study”, but the whole site is worth exploring.  Bonus: make sure to responsively test the top of the page, which has some great Grid-driven rearrangements as the page gets more narrow.
  • Rachel Andrews’ Grid By Example — a large and growing collection of examples, resources, tutorials, and more.  There’s a whole section titled “Learn Grid Layout” that’s further broken up into sections like “UI Patterns” and “Video tutorial”.
  • CSS-Tricks’ A Complete Guide to Grid — a boiled-down, pared-down, no-nonsense distillation of Grid properties and values.  It might be a bit bewildering if you’re new to Grid, but it’s the kind of resource you’ll probably come back to again and again as you’re getting familiar with Grid.
  • CSS Grid Layout specification — if all else fails, you can always go to the source, Luke.

But remember!  If you hit these sites before March 2017, you’ll need to make sure you have Grid support enabled in your browser so that you can make sense of the examples (not to mention anything you might create yourself).  Igalia has a brief and handy how-to page at Enable CSS Grid Layout, and Rachel also has a Browsers page with more information.

I’ve been hurt by layout promises before, and I’m afraid to trust.

I feel you.  Oh, do I feel you.  But this really looks like the real thing.  It’s coming.  Get ready.


Workshopping

Published 2 years, 8 months ago

I’m criminally behind in sharing this with everyone, so I’m jumping straight to the bottom line here: I’m teaching a workshop on advanced CSS layout techniques in October, and co-teaching another workshop on CSS animation in November with the inestimable Val Head.  Both are courtesy O’Reilly & Associates, and will be conducted at their offices in Boston.

A few more details:

  • New CSS Layout (October 17-18) is two days of deep diving into flexbox, multicolumn, grid, and related technologies.  There will be a heavy emphasis on Things You Can Use Today, including bugs and how to handle them, with a keen focus on using everything in a progressively enhancing way.  In other words, you should walk away knowing how to use new technologies right away, without leaving behind users of older browsers, and have a good sense of what you’ll be able to do in the next 6-12 months.  This will be hands-on, interactive, and very much a dialogue with technical instruction.  If you’re looking for two days of watching me drone in front of a slide show, this is not that.  I’m not even sure I’ll have any slides at all—I’ll probably spend the entire time in BBEdit and a browser instead.  The class size is limited to 40 people.
  • CSS Animation (November 17-18) is another two days of diving deep into the topic.  For this one, I’ll spend the first day going through every last piece of CSS transition and animation syntax, with generous helping of transform.  On the second day, Val will show how to put that syntax to use in a way that serves and strengthens your design, instead of undermining it.  It’s basically a day of learning how the tools work, and a day of learning how to properly use the tools.  Again, class size of 40; and again, very much hands-on and interactive.

So that’s what’s up.  Looking for ways to seriously expand your skills in layout or animation or both?  Come, join us!


Unsupportable Promises

Published 6 years, 3 months ago

Over the past year and a half, the CSS Working Group has been working on a CSS Conditional Rules Module Level 3 module.  Now, don’t get overexcited: this is not a proposal to add generalized, formal if/then/else or switch statements to CSS—though in a very limited way, it does just that.  This is the home of the @media rule, which lets you create if/then conditions with regard to the media environment.  It’s also the home of the @supports rule, which lets you…well, that’s actually more complicated than you might think.

I mean, what do you think @supports means?  Take a moment to formulate a one-line definition of your understanding of what it does, before moving on to the rest of this piece.

If you’ve never heard of it before and wonder how it works, here’s a very basic example:

body {background-color: white;}
@supports (background-color: cornflowerblue) {
	body {background-color: cornflowerblue;}
}

The idea is that if the browser supports that property:value combination, then it will apply the rule or rules found inside the curly brackets.  In this sense, it’s just like @media rules: if the conditions in the parentheses are deemed to apply, then the rules inside the declaration block are used.  The module refers to this ability as “feature queries”.

There are some logical combination keywords available: and, or, and not.  So you can say things like:

body {color: #222; background-color: white;}
@supports ((background-color: cornflowerblue) and (color: rgba(0,0,0,0.5))) {
	body {background-color: cornflowerblue; color: rgba(0,0,0,0.5);}
}

Okay, but what does that actually mean?  Here’s what the specification says:

A CSS processor is considered to support a declaration (consisting of a property and value) if it accepts that declaration (rather than discarding it as a parse error). If a processor does not implement, with a usable level of support, the value given, then it must not accept the declaration or claim support for it.

So in that first sentence, what we’re told is that “support” means “accepts [a] declaration” and doesn’t drop it on the floor as something it doesn’t recognize.  In other words, if a browser parses a property:value pair, then that qualifies as “support” for said pair.  Note that this sentence says nothing about what happens after parsing.  According to this, a browser could have a completely botched, partial, and generally unusable implementation of the property:value pair, but the act of recognizing means that there’s “support”.

But wait!  That second sentence adds an additional constraint, after a fashion: there must be “a usable level of support”, the lack of which means that a browser “must not…claim support”.  So not only must a browser parse a property:value pair, but support it to “a usable level”.

But what constitutes a “usable level”?  According to everyone who’s told me that I was wrong about vendor prefixes, any browser implementation of a feature should be complete and error-free.  Is that what’s required to be regarded as a usable level?  How about if the implementation has one known bug?  Three?  Ten?  Can any of them be severe bugs?  What about merely serious bugs?  What if two browsers claim usable support, and yet are not interoperable?

So.  How does the definition of @supports match the one-line definition I asked you to formulate, back at the beginning?  Are they exactly the same, or is there a difference?

I suspect that most people, especially those coming across @supports for the first time, will assume that the word means that a browser has complete, error-free support.  That’s the implicit promise.  Very few people think of “supports” as a synonym for “recognizes” (let alone “parses”).  There’s a difference, sometimes a very large one, between recognizing a thing and supporting it.  I’m sure that browser teams will do their best to avoid situations where a property:value pair is parsed but not well supported, but it’s only a matter of time before a “supported” pair proves to be badly flawed, or retroactively made wrong by specification changes.  Assuming that such things will be allowed, in an environment where @supports exists.

If feature queries were set with @feature, as media queries are set using @media, or even if the name were something along the lines of @parses or @recognizes, I’d be a lot less bothered.  The implicit promise would be quite a bit different.  What I feel like we face here is the exact inversion of vendor prefixes: instead of a marker for possible instability and a warning that preserves the possibility of changing the specification when needed, this pretends to promise stability and safety while restricting the WG’s ability to make changes, however necessary.  My instinct is that @supports will end up in the same place: abused, broken, and eventually reviled—except this time, there will be the extra bitterness of authors feeling that they were betrayed.


The Stinger

Published 6 years, 3 months ago

(In television, the “stinger” is the clip that plays during or just after the closing credits of a show.)

On Friday, the Web Standards Project announced its own dissolution.  I felt a lot of things upon reading the announcement, once I got over my initial surprise: nostalgia, wistfulness, closure.  And over it all, a deep sense of respect for the Project as a whole, from its inception to its peak to its final act.

In some ways, the announcement was a simple formalization of a longstanding state of affairs, as the Project has gradually grown quieter and quieter over the years, and its initiatives had been passed on to other, more active homes.  It was still impressive to see the group explicitly shut down.  I can’t think of the last time I saw a group that had been so influential and effective recognize that it was time to turn off the lights, and exit with dignity.  As they wrote:

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.

I have a long history with the WaSP.  Way, way back, deep in the thick of the browser wars, I was invited to be a member of the CSS Action Committee, better known as the CSS Samurai.  We spent the next couple of years documenting how things worked (or, more often, didn’t) in CSS implementations, and—and this was the clever bit, if you ask me—writing up specific plans of action for browsers.  The standards compliance reviews we published told browsers what they needed to fix first, not just what they were getting wrong.  I can’t claim that our every word was agreed with, let alone acted upon, but I’m pretty confident those reviews helped push browser teams in the right direction.  Or, more likely, helped browser teams push their bosses in the direction the teams already wanted to go.

Succumbing to a wave of nostalgia, I spent a few minutes trawling my archives.  I still have what I think is all the mail from the Samurai’s mailing list, run through Project Cool’s servers, from when it was set up in August 1998 up through June of 2000.  My archive totals 1,716 messages from the group, as well as some of the Steering Committee members (mostly Glenn Davis, though George Olsen was our primary contact during the Microsoft style sheets patent brouhaha of February 1999).  If I’m not reading too much into plain text messages over a decade old, we had a pretty great time.  And then, after a while, we were done.  Unlike the WaSP itself, we never really declared an end.  We didn’t even march off into the sunset having declared that the farmers always win.  We just faded away.

Not that that’s entirely a bad thing.  At a certain point, our work was done, and we moved on.  Still, I look back now and wish we’d made it a little more formal.  Had we done so, we might have said something like the WaSP did:

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 so it is.  These last years have shown that the job is in very good hands.

“Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has.” said Margaret Mead.  I see now that the way those small groups truly change the world is by convincing the rest of the world that they are right, thus co-opting the world to their cause.  Done properly, the change makes the group obsolete.  It’s a lesson worth remembering, as we look at the world today.

I’m honored to have been a part of the WaSP, and I offer my deepest samurai bow of respect to its founders, its members, and its leaders.  Thank you all for making the web today what it is.


Sixth Annual Blue Beanie Day

Published 6 years, 6 months ago

I just recently stumbled across a years-ago post where I said, almost as an aside:

Web design isn’t like chemistry, where the precipitate either forms or it doesn’t. If chemical engineers had to work in conditions equivalent to web developers, they’d have to mix their solutions in several parallel universes, each one with different physical constants, and get the same result in all of them.

While that’s still true, the constants are a lot less divergent these days.  The parallel universes that are web browsers are much closer to unity than once they were.

Remember those days?  When major web sites had a home page with two links: one for Netscape users to enter, the other for IE users?

Madness.

We know better now, of course.  Thanks to early pioneers like the organizers of the Web Standards Project, the path of web development was bent to a much saner course.  We still have little glitches and frustrations, of course, but it could be so unimaginably worse.  We know that it could be, because it was, once.

Along the way, the book cover of my friend and business partner’s book, Designing With Web Standards, gave rise to Blue Beanie Day, the day on which we give visible presence to our solidarity with the idea that web standards make possible the web as we know it.  Pictures go up on Twitter, Instagram, and Flickr with the tag #bbd12, and can be added to the Flickr group if you post there.

In this rapidly unfolding age of multiple device platforms and web access experiences, standards are more important than ever, even as they come under renewed pressure.  There will always be those who proclaim that standards are a failed process, an obstruction, an anachronism.  The desire to go faster and be shinier will always tempt developers to run down proprietary box canyons.

But so too will there always be those of us who remember the madness that lies that way.  Come November 30th, thousands of us will don our blue beanies.  I hope you’ll be among us.

Image © Kevin Cornell.  Used with permission.