In the course of expanding my documentation of color values, I failed to find a table that listed all 147 SVG-and-CSS3-defined keywords along with the equivalent RGB decimal, RGB percent, HSL, hexadecimal, and (when valid) short-hex values. There were some tables that listed some but not all of those value types, and one that listed all the value types (plus CMYK) along with a few hundred other keywords, but none that listed all of the CSS keywords and value types. And none that I saw used precise values for the RGB percent and HSL types, preferring instead to round off at the expense of some subtle differences in color.

So I created my own table, which you can now find in the CSS area of meyerweb. Most of it is dynamically generated, taking a list of keywords and RGB decimal equivalents and then calculating the rest of the values from there. The presentation is still a work in progress, and may change a little or a lot. In particular, if I can’t find a better algorithm for determining which rows should have white text instead of black, I’ll probably shift away from the full-row background colors to some other presentation.

My thanks to Tab Atkins for his donation of the RGB-to-HSL routine I adapted; and to the people who responded positively on Twitter when I mused about the idea there.

As always: share and enjoy!

DAN BENJAMIN is my guest on Episode No. 70 of The Big Web Show, the weekly podcast on “everything web that matters.”

Dan is a broadcaster, screencaster, writer, software developer, designer, and entrepreneur. He is the founder of 5by5 Studios, an internet broadcasting network where he hosts a handful of shows with people like John Gruber, Merlin Mann, and me. Dan is the author of Hivelogic and has written for A List Apart and O’Reilly.

For almost two decades, Dan has created publishing tools including those which have powered A List Apart and 5by5. He devised the Email Address Enkoder, co-founded Cork’d, and founded Playgrounder. The latter two have since been acquired by Gary Vaynerchuk and Uncrate, respectively.

Listen to Episode No. 70 of The Big Web Show, featuring Dan Benjamin.

Subscribe to The Big Web Show

The Big Web Show features special guests and topics like web publishing, art direction, content strategy, typography, web technology, and more.

Get episodes delivered to you automatically:

• Audio RSS Feed
• iTunes Audio

Photo © 2011 Bill Wadman

THANK YOU for the screen shot. I was actually already aware that the type on my site is big. I designed it that way. And while I’m grateful for your kind desire to help me, I actually do know how the site looks in a browser with default settings on a desktop computer. I am fortunate enough to own a desktop computer. Moreover, I work in a design studio where we have several of them.

This is my personal site. There are many like it, but this one is mine. Designers with personal sites should experiment with new layout models when they can. Before I got busy with one thing and another, I used to redesign this site practically every other week. Sometimes the designs experimented with pitifully low contrast. Other times the type was absurdly small. I experimented with the technology that’s used to create web layouts, and with various notions of web “page” design and content presentation. I’m still doing that, I just don’t get to do it as often.

Many people who’ve visited this site since the redesign have commented on the big type. It’s hard to miss. After all, words are practically the only feature I haven’t removed. Some of the people say they love it. Others are undecided. Many are still processing. A few say they hate it and suggest I’ve lost my mind—although nobody until you has suggested I simply didn’t have access to a computer and therefore didn’t know what I was designing. This design may be good, bad, or indifferent but it is not accidental.

A few people who hate this design have asked if I’ve heard of responsive web design. I have indeed. I was there when Ethan Marcotte invented it, I published his ground-breaking article (and, later, his book, which I read in draft half a dozen times and which I still turn to for reference and pleasure), and I’ve had the privilege of seeing Ethan lecture and lead workshops on the topic about 40 times over the past three years. We’ve incorporated responsive design in our studio’s practice, and I’ve talked about it myself on various stages in three countries. I’m even using elements of it in this design, although you’d have to view source and think hard to understand how, and I don’t feel like explaining that part yet.

This redesign is a response to ebooks, to web type, to mobile, and to wonderful applications like Instapaper and Readability that address the problem of most websites’ pointlessly cluttered interfaces and content-hostile text layouts by actually removing the designer from the equation. (That’s not all these apps do, but it’s one benefit of using them, and it indicates how pathetic much of our web design is when our visitors increasingly turn to third party applications simply to read our sites’ content. It also suggests that those who don’t design for readers might soon not be designing for anyone.)

This redesign is deliberately over the top, but new ideas often exaggerate to make a point. It’s over the top but not unusable nor, in my opinion, unbeautiful. How can passages set in Georgia and headlines in Franklin be anything but beautiful? I love seeing my words this big. It encourages me to write better and more often.

If this were a client site, I wouldn’t push the boundaries this far. If this were a client site, I’d worry that maybe a third of the initial responses to the redesign were negative. Hell, let’s get real: if this were a client site, I wouldn’t have removed as much secondary functionality and I certainly wouldn’t have set the type this big. But this is my personal site. There are many like it, but this one is mine. And on this one, I get to try designs that are idea-driven and make statements. On this one, I get to flounder and occasionally flop. If this design turns out to be a hideous mistake, I’ll probably eventually realize that and change it. (It’s going to change eventually, anyway. This is the web. No design is for the ages, not even Douglas Bowman’s great Minima.)

But for right now, I don’t think this design is a mistake. I think it is a harbinger. We can’t keep designing as we used to if we want people to engage with our content. We can’t keep charging for ads that our layouts train readers to ignore. We can’t focus so much on technology that we forget the web is often, and quite gloriously, a transaction between reader and writer. Most of you reading this already know all this and already think about it each time you’re asked to create a new digital experience. But even our best clients can sometimes push back, and even our most thrilling projects typically contain some element of compromise. A personal site is where you don’t have to compromise. Even if you lose some readers. Even if some people hate what you’ve done. Even if others wonder why you aren’t doing what everyone else who knows what’s what is doing.

I don’t think you will see much type quite this big but I do think you will see more single-column sites with bigger type coming soon to a desktop and device near you. For a certain kind of content, bigger type and a simpler layout just make sense, regardless of screen size. You don’t even have to use Typekit or its brothers to experiment with big type (awesome as those services are). In today’s monitors and operating systems, yesterday’s classic web fonts—the ones that come with most everyone’s computer—can look pretty danged gorgeous at large sizes. Try tired old Times New Roman. You might be surprised.

The present day designer refuses to die.

LET’S DIG A BIT DEEPER into the latest conflict between web developers who are passionate about the future of HTML, and the WHATWG. (See Mat Marquis in Tuesday’s A List Apart, Responsive Images and Web Standards at the Turning Point, for context, and Jeremy Keith, Secret Src in Wednesday’s adactio.com, for additional clarification.)

The WHATWG was created to serve browser makers, while its product, HTML5, was designed to serve users first, designers (authors) next, browser makers (implementors) last according to the priority of constituencies, which is one of its founding design principles.

There is a tension between this principle of HTML5 (to serve users above designers above browser makers) and the reality of who is the master: namely, browser makers – especially Google, which pays Hixie, the editor of HTML5, his salary. That’s not a knock on Hixie (or Google), it’s just the reality.

One way the tension between principle and reality plays out is in not uncommon incidents like the one we’re reacting to now. According to the priority of constituencies, designer/developer feedback should be welcomed, if not outright solicited. In principle, if there is conflict between what designer/developers advise and what browser makers advise, priority should be given to the advice of designer/developers. After all, their needs matter more according to the priority of constituencies — and designer/developers are closer to the end-user (whose needs matter most) than are browser makers.

Solicitiation of and respect for the ideas of people who actually make websites for a living is what would happen if the HTML5-making activity had been organized according to its own priority of constituencies principle; but that kind of organization (committee organization) echoes the structure of the W3C, and the WHATWG arose largely because browser makers had grown unhappy with some aspects of working within the W3C. In reality, there is one “decider” — the editor of HTML5, Ian Hickson. His decisions are final, he is under no obligation to explain his rationales, and he need not prioritize developer recommendations above a browser maker’s — nor above a sandwich maker’s, if it comes to that. By design, Hixie is a free agent according to the structure he himself created, and his browser maker end-users (masters?) like it that way.

They like it that way because stuff gets done. In a way, browser makers are not unlike web developers, eager to implement a list of requirements. We designer/developers don’t like waiting around while an indecisive client endlessly ponders project requirements, right? Well, neither do browser makers. Just like us, they have people on payroll, ready to implement what the client requires. They can’t afford to sit around twiddling their digits any more than we can. In 2007, the entire world economy nearly collapsed. It is still recovering. Don’t expect any surviving business to emulate a country club soon.

So, has this latest friction brought us to a tipping point? Will anything change?

In theory, if we are frustrated with Mr Hickson’s arbitrary dictates or feel that they are wrong, we can take our ideas and our grievances to the W3C, who work on HTML5 in parallel with the WHATWG. We should probably try that, although I tend to think things will continue to work as they do now. The only other way things could change is if Hixie wakes up one morning and decides benevolent dictator is no longer a role he wishes to play. If I were in charge of the future of the web’s markup language, with not just final cut but every cut, I’m not sure I’d have the courage to rethink my role or give some of my power away. But perhaps I underestimate myself. And perhaps Hixie will consider the experiment.

For your pleasure:

Jason Grigsby: The Immobile Web

Jason Grigsby (@grigs) discusses the next frontier: web-enabled televisions. Key points from this important BDConf speech transcribed by Brad Frost. With Slideshare video.

Jeremy Keith: Secret Src

As usual, Jeremy Keith is the cluefullest person in the room when it comes to the sexual politics of HTML5.

Context Free Patent Art

Just like it says.

Creative Bloq: Ten Questions for Jeffrey Zeldman

“If you’re complaining about IE in 2012, the problem isn’t Internet Explorer … it’s your job. But you can fix that.” One of several nuggets that emerge from my interview with the new design magazine.

Lea Verou: The top 8 web standards myths debunked

Just like it says.

Double Vision – Global Trends in Tablet and Smartphone Use while Watching TV

“Whether to check email or to look up program or product information, using a tablet or smartphone while watching TV is more common than not according to a Q4 2011 Nielsen survey of connected device owners in the U.S., U.K., Germany and Italy. In the U.S., 88 percent of tablet owners and 86 percent of smartphone owners said they used their device while watching TV at least once during a 30-day period. For 45 percent of tablet-tapping Americans, using their device while watching TV was a daily event, with 26 percent noting simultaneous TV and tablet use several times a day. U.S. smartphone owners showed similar dual usage of TV with their phones, with 41 percent saying their use their phone at least once a day while tuned in.”

How we use feature based development to give better quotes

Just like it says.

The Egotistical Puppet King & I

The latest CSSquirrel comic takes a jaded view of recent goings-on amidst the framers of HTML5. Alas, it’s even worse than he thinks.

LingsCars.com Gets a Makeover

Well done, Adaptive Path.

The fact that this:

h1 {color: red;} h1 {color: green;}

…results in green h1 text, but this:

h1 {background-image: url(red-wave.gif) repeat, url(green-wave.gif) repeat;}

…results in a red wavy h1 background does my head in every single time. And it’s the same with text and box shadows, too! In cases where backgrounds or shadows overlap, the first one you write “wins”, by virtue of being “in front of” the background images that are listed after it.

I know that font stacks are also done in order of most-to-least preferred, but I don’t see them as being equivalent. The reason is that a font stack is a list of fallbacks—use this face unless it can’t render the glyph or doesn’t exist, in which case try the next one in the list, etc., etc. Multiple background images and multiple shadows, on the other hand, are not a series of fallbacks. I expect to see them all, unless I made a mistake of some kind; and I do, constantly, because of this disconnect. Sure, one could use the multiple background image syntax to create a series of fallbacks—first an SVG file, second a PNG, third a GIF—but that’s not its primary purpose, and I certainly wouldn’t teach multiple background images that way. That’s not what they’re designed to do.

Maybe writing the problem down here will purge this daemon, but in all honesty, my hopes are not terribly high.

The fact that this:

h1 {color: red;} h1 {color: green;}

…results in green h1 text, but this:

h1 {background: url(red-wave.gif) repeat, url(green-wave.gif) repeat;}

…results in a red wavy h1 background does my head in every single time. And it’s the same with text and box shadows, too! In cases where backgrounds or shadows overlap, the first one you write “wins”, by virtue of being “in front of” the background images that are listed after it.

I know that font stacks are also done in order of most-to-least preferred, but I don’t see them as being equivalent. The reason is that a font stack is a list of fallbacks—use this face unless it can’t render the glyph or doesn’t exist, in which case try the next one in the list, etc., etc. Multiple background images and multiple shadows, on the other hand, are not a series of fallbacks. I expect to see them all, unless I made a mistake of some kind; and I do, constantly, because of this disconnect. Sure, one could use the multiple background image syntax to create a series of fallbacks—first an SVG file, second a PNG, third a GIF—but that’s not its primary purpose, and I certainly wouldn’t teach multiple background images that way. That’s not what they’re designed to do.

Maybe writing the problem down here will purge this daemon, but in all honesty, my hopes are not terribly high.

IN A SPECIAL ISSUE of A List Apart for people who make websites:

Responsible responsive design demands responsive images — images whose dimensions and file size suit the viewport and bandwidth of the receiving device. As HTML provides no standard element to achieve this purpose, serving responsive images has meant using JavaScript trickery, and accepting that your solution will fail for some users.

Then a few months ago, in response to an article at A List Apart, a W3C Responsive Images Community Group formed — and proposed a simple-to-understand HTML picture element capable of serving responsive images. The group even delivered picture functionality to older browsers via two polyfills: namely, Scott Jehl’s Picturefill and Abban Dunne’s jQuery Picture. The WHATWG has responded by ignoring the community’s work on the picture element, and proposing a more complicated img set element.

Which proposed standard is better, and for whom? Which will win? And what can you do to help avert an “us versus them” crisis that could hurt end-users and turn developers off to the standards process? ALA’s own Mat Marquis explains the ins and outs of responsive images and web standards at the turning point.

I’m working my way through a rewrite of Two Salmon (more on that anon), and I just recently came to the ch unit. Its definition in the latest CSS Values and Units module is as follows:

ch unit

Equal to the advance measure of the “0″ (ZERO, U+0030) glyph found in the font used to render it.

…and that’s it. I had never heard the term “advance measure” before, and a bit of Googling for font "advance measure" only led me to copies of the CSS Values and Units module and some configuration files for the Panda 3D game engine. So I asked the editor and it turns out that “advance measure” is a CSS-ism that corresponds to the term “advance width”, which I had also never heard before but which yielded way more Google results. Wikipedia’s entry for “Font” has this definition:

Glyph-level metrics include … the advance width (the proper distance between the glyph’s initial pen position and the next glyph’s initial pen position)…

My question for the font geeks in the room is this: is that the generally accepted definition for “advance width”? If not, is there a better definition out there; and if so, where? I’d like to be able to recommend the best known definition for inclusion in the specification; or, if there’s no agreement as to the best, then at least a good one. The Wikipedia definition certainly sounds good, assuming it’s accurate. Is it?

In CSS terms, if I’ve understood things correctly, 1ch is equal to the width of the character box for the glyph for “0”. In other words, if I were to create a floated element with just a “0” and no whitespace between it and the element’s open and close tags, then the float’s width would be precisely 1ch. But that’s if I’ve understood things correctly. If I haven’t, I hope I’ll be corrected soon!

I DREAMED that my friend Jason Santa Maria took a job at a popular new startup that had exploded onto the world scene seemingly overnight. A fascinating visual interface was largely responsible for the popularity of the company’s new social software product. It was like a Hypercard stack that came toward you. A post full of exciting social significance just for you would appear in a self-contained deck with rounded corners. The next post would pop up on top of the first. The next, on top of that one. And so on. In my dream, people found this back-to-front pop-up effect thrilling for some reason.

Having imagined the interface, I next dreamed that I went to visit the startup. There were so many cubicles, so many shiny people running around, holding morning standups and singing a strange company song, that I could not locate my friend Jason’s desk. Someone grabbed me and told me the founder wanted to see me.

THE FOUNDER was an ordinary looking white guy in his late twenties. I was surprised that he wore beige chinos with a permapress crease. With all the TV and newspaper hubub around his product, I guess I’d expected a more stylish and charismatic presence.

The founder told me he was concerned because his mother, apparently a cofounder or at least an officer of the company, was of the belief that I had contempt for their product and disliked her personally. I assured him that I liked the product. Further, I had never met his mother, never read or heard a word about her, and felt only goodwill toward her, as I bear toward all people in the abstract. I don’t hate people I don’t know.

“It would be cool if you told mom that yourself,” he said. And suddenly two assistants were whisking me off to speak to her directly.

THE AUDITORIUM-SIZED waiting room outside the founder’s mother’s office was filled with at least a thousand people who had come to talk to her before me. They seemed to have been waiting for hours. There was an air of boredom and rapidly thinning patience, mixed with excitement and the kind of carnival atmosphere that surrounds things that blow up suddenly in the press. It felt like the jury selection room for a celebrity murder case. Only much, much bigger.

The two assistants escorted me to the very front of the auditorium, to an empty row of seats abutting the door to the founder’s mother’s private office. “Special treatment,” I thought. I was thrilled to be cutting to the front of the line, apparently as a result of the founder’s directive to his assistants. The front row chairs were reversed, facing back to the rest of the auditorium, so I was put in the somewhat uneasy position of staring out at the mass of people who had been waiting to see the founder’s mother since long before I arrived.

After a while, Ian Jacobs of the W3C was brought to the front of the room and seated near me.

We waited as other people were shown into the founder’s mother’s presence.

AFTER FIVE or six hours of drowsy waiting, I realized that the room was set up to mirror the software’s interface: people from the very back of the auditorium were first in line, and were shown into the founder’s mother’s presence first. Gradually, the hall of applicants emptied from the back to the front. Those of us in the very front of the line were actually the last people of all who would be admitted to the holy presence. It was a smart marketing touch that apparently permeated the company: everything real people did in the building in some way echoed the characteristics of the software interface — from the end of the line coming first, to the way the rounded conference tables echoed the shapes of individual news posts in the software’s back-to-front news deck.

What a smart company, I thought. And what a good joke on me, as I continued to sit there forever, waiting to see someone I’d never met, who held a baseless grudge against me, which it would one day be my task to talk her out of.

It may be that from the ashes of vendor prefixes will arise a new way forward. As proposed by François Remy, vendor tokens would serve the same basic purpose as prefixes with a different syntactical approach, and with at east a couple of extra benefits. Instead of prefixing properties, you’d instead add vendor tokens to the end of a single declaration, much as you do !important (which of course we never ever use, amirite?).

For example, you might write:

border-radius: 1em !webkit-draft !moz-draft !o-draft;

That’s it. The prefixed alternative, of course, runs to multiple lines and has spawned a whole subindustry of framework plugins and mixins and what-all just to take the repetitive authoring burden off our shoulders.

I’ve been contemplating this proposal all morning, and perhaps not too surprisingly I’ve come down in favor of the idea. I’m on record as being a fan of vendor prefixes, but what I was truly a fan of was the capabilities they offer. The syntax was never a core interest for me, and the ugliness was pretty apparent. Vendor tokens are less tortuous, and even make it much simpler to build in versioning, like so:

border-radius: 1em !webkit-draft-2 !moz-draft !o-draft;

Not that I’m saying this proposal will or even should get to that point, but the ability is there and it feels cleaner than trying to do the same thing with prefixes. I feel they ought to drop the -draft part of the tokens; just saying !webkit !moz !o or possibly !x-webkit !x-moz !x-o should be sufficient. I’m also not a fan of the bang, but then I never have been, and I figure any token marker would suffice. As before, it’s not the syntax I care about so much as the capabilities.

There is a discussion ongoing at www-style, if you’re interested in adding your perspective or even just following along as various stakeholders thrash at the idea. I’m cautiously optimistic. It’s kind of a nice feeling!

IN ISSUE No. 350 of A List Apart for people who make websites: keep your web type looking right across browsers, platforms, and devices; let users do stuff on your site even when they’re offline.

Say No to Faux Bold

by ALAN STEARNS

Browsers can do terrible things to type. If text is styled as bold or italic and the typeface family does not include a bold or italic font, browsers will compensate by trying to create bold and italic styles themselves. The results are an awkward mimicry of real type design, and can be especially atrocious with web fonts. Adobe’s Alan Stearns shares quick tips and techniques to ensure that your @font-face rules match the weight and styles of the fonts, and that you have a @font-face rule for every style your content uses. If you’re taking the time to choose a beautiful web font for your site, you owe it to yourself and your users to make certain you’re actually using the web font — and only the web font — to display your site’s content in all its glory.

Application Cache is a Douchebag

by JAKE ARCHIBALD

We’re better connected than we’ve ever been, but we’re not always connected. ApplicationCache lets users interact with their data even when they’re offline, but with great power come great gotchas. For instance, files always come from the ApplicationCache, even when the user is online. Oh, and in certain circumstances, a browser won’t know that that the online content has changed — causing the user to keep getting old content. And, oh yes, depending on how you cache your resources, non-cached resources may not load even when the user is online. Lanyrd’s Jake Archibald illuminates the hazards of ApplicationCache and shares strategies, techniques, and code workarounds to maximize the pleasure and minimize the pain for user and developer alike. All this, plus a demo. Dig in.

Illustration by Kevin Cornell for A List Apart

I WAS SOBER SIX MONTHS when my Uncle George took me to lunch and told me he believed his sister, my mother, had Alzheimers. She was 60. Via frequent short visits to Pittsburgh and more phone calls than we’d shared in decades, I helped my dad accept that he needed to take her to the doctor for tests. Then I helped him accept the results.

She declined over ten years. It was like a plane crash in slow motion.

At my Aunt Ruth’s funeral, my mother cried and cried, with no clue who she was crying for. When I joined my parents at the grave site, my mother turned excitedly to my father and pointed at me. “I know that man!” she said.

When she couldn’t talk any longer; after all the in-home nurses had quit; after the cousin who’d come to care for her committed credit card fraud while my mother wandered the house unwashed and raving; after that, I helped my dad accept that mom could no longer live at home.

Oh, and I stayed sober.

The final two years she spent in a facility. It was like visiting a statue. My dad would get her an ice cream and wheel her around the nursing home garden. She ate the ice cream. I’m not sure she saw the trees.

She had a little CD player in her room, and when we visited, we would put on music she liked – that is, music she had liked when she liked anything. Once, I swear I saw her shiver at the melancholy sax riff on a Frank Sinatra ballad. As if someone was there.

Then there was the day her hair turned white. I suppose it had probably turned gradually during the few weeks since I’d last seen her. My career was taking off and I couldn’t visit Pittsburgh as often. For that matter, maybe her hair had turned white a decade before, and the attendants at the nursing facility had just one day decided it wasn’t worth coloring her hair any more.

Alzheimer’s can only be proved via autopsy; it can’t be diagnosed with 100% certainty while the patient lives. My dad’s insurance company used that loophole to avoid covering a dime of the cost of the last ten year’s of my mother’s care.

After she died, after months had elapsed and my dad was still living among all her old things, my then-girlfriend and I volunteered to weed through my mother’s possessions, giving nearly everything to charity. In my mother’s desk drawer, we discovered a note she had written to herself at the onset of the disease, acknowledging that her mind was going. She feared the passage into darkness.

April 24th would have been my mother’s birthday. I think of her with some regularity. Sometimes I wish my mother could have lived to know my daughter, who is now seven. And sometimes I indulge the thought that somewhere, somehow, she does.

Adam Yauch, * 5. August 1964 † 4. Mai 2012.

Foto: daigovilla unter CC Lizenz.

HAPPY COG Creative Director Christopher Cashdollar is my guest in Episode No. 69 of The Big Web Show, the weekly podcast on “everything web that matters.”

In 35 lively minutes, Chris and I discuss the joys and challenges of redesigning typography mega-site Fonts.com; nimble versus waterfall; process versus inspiration; running a creative department that is interactive in every sense of the word; the two sides of a design education (learning and teaching); fostering collaboration; and the transition from doodling eight-year-old to graphic design student to interactive creative director.

Chris is a multi-disciplinary graphic designer with twelve years of interaction design experience. He is currently the Creative Director for Happy Cog Philadelphia, and an adjunct instructor for Drexel University’s Westphal College of Media Arts and Design.

Listen to Episode No. 69 of The Big Web Show, featuring Chris Cashdollar.

Links

• Fonts.com Beta
• @ccashdollar
• Christopher Cashdollar
• Articles by Chris Cashdollar
• Cash on Dribble
• Happy Cog
• PhilaMade

Subscribe to The Big Web Show

The Big Web Show features special guests and topics like web publishing, art direction, content strategy, typography, web technology, and more.

Get episodes delivered to you automatically:

• Audio RSS Feed
• iTunes Audio

SEE ME SPEAK about web design, interaction design, publishing, and the future of web content. In the coming months, I’ll be visiting all sorts of nice cities, the better to meet and greet you:

Go Beyond Pixels St. John’s, Newfoundland, Canada

May 25, 2012

Reasons To Be Creative New York

June 14–15, 2012

An Event Apart Boston

June 18–20, 2012

An Event Apart Austin

July 9–11, 2012

An Event Apart DC

August 6–8, 2012

An Event Apart Chicago

August 27–29, 2012

Future of Web and Mobile – London

October 15-17, 2012

An Event Apart San Francisco

November 12–14, 2012

You can keep up with my comings and goings on Lanyrd; follow me on Twitter (@zeldman) and Facebook; and keep watching the skies at An Event Apart, the design conference for people who make websites.

At DrupalCon Denver, I announced the need for a strong focus on Drupal's authoring experience in my State of Drupal presentation. During my core conversation later in the week, I announced the creation of a Drupal 7 distribution named "Spark" (formerly code-named "Phoenix"). The goal of Spark is to act as an incubator for Drupal 8 authoring experience improvements that can be tested in the field.

I hope for Spark to provide a "safe space" to prototype cutting-edge interface design and to build excellent content tools that are comparable with the experience of proprietary alternatives. While not a final list, some initial thinking around the features we want to experiment with is:

• Inline editing and drag-and-drop content layout tools ("true" WYSIWYG)
• Enhanced content creation: auto-save, save as draft and more
• Useful dashboards for content creators
• Mobile content authoring and administration support

The vision behind the Spark distribution is to be "the Pressflow of Drupal authoring experience". Pressflow provided a "spoon" of Drupal 6 with various performance enhancements that made their way into Drupal 7 core while it was in development. The same improvements were made available to Drupal 6 users so they could easily be tested in the field. With Spark, we want to test authoring experience improvements in Drupal 7 on real sites with real users and real content. We also want to target the best improvements for inclusion into Drupal 8 core.

I'm excited to announce that Acquia will fund the Spark distribution. Core developers Gábor Hojtsy and Wim Leers will work on Spark full-time starting in late May. They will work along side Angie Byron (webhchick), Alex Bronstein (effulgentsia), myself and other members at Acquia. While we have some promising candidates so far, Acquia is still seeking applicants to join the Spark team (with a strong preference to candidates located in or willing to move to the Boston area):

• Drupal UX Interaction Designer, who can conceptualize and prototype cutting-edge interface design.
• Senior Front-End Engineer, who eats, sleeps, and breaths JavaScript and jQuery (Drupal experience optional).

The Spark team will collaborate with the Drupal usability and the core development teams.

TANTEK ÇELIK is my guest on Episode No. 68 of The Big Web Show (“everything web that matters”).

Currently web standards lead at Mozilla, Tantek is one of the founders of both the microformats.org open standards community and the Global Multimedia Protocols Group, and an invited expert to the World Wide Web Consortium (W3C) Cascading Style Sheets working group.

Tantek has played a key role in the development and popularization of practical social network portability technologies such as the hCard and XFN microformats. In 2003, Tantek collaborated with Eric Meyer and Matt Mullenweg in the invention of the XHTML Friends Network (XFN), which has since become the most popular decentralized social relationship format in the history of the Web. In 2004 Tantek proposed hCard for representing people and organizations, which has since similarly become the most popular user profile format on the web.

During his years as Technorati’s Chief Technologist, Tantek played an active role in refining and evangelizing hCard, bringing it from a wiki proposal to one that’s endorsed and supported by individuals, numerous small organizations, major companies ranging from AOL to Yahoo, and implemented for over a hundred million user identities and business listings on the web.

At Microsoft, Tantek led the development of Internet Explorer 5 for Macintosh and its Tasman rendering engine, which was the most standards-compliant layout engine of its time. He was also an early member of The Web Standards Project, and is the creator of the Box Model Hack, the first IE hack that let developers work around the incorrect box model in old versions of Internet Explorer.

Listen to Episode 68: Tantek Çelik on Mozilla and Microformats.

Links in this episode

• BrowserID: a better way to sign in
• IndieWebCamp: Own Your Data!
• “Gangbang Interviews” and “Bikini Shots”: Silicon Valley’s Brogrammer Problem
  
• Restyle W3C: Towards a More Usable Spec Template
• hCard 1.0 Specification (rewritten to be human friendly)
• The Vendor Prefix Predicament: ALA’s Eric Meyer Interviews Tantek Çelik
• Responsive Images: How they Almost Worked and What We Need
• Mozilla WIKI
• CNET: Mozilla hires open-standards guru Celik
• hacks.mozilla.org: Interview – Tantek on the importance of web standards
• Why IE5/Mac Matters

Subscribe to The Big Web Show

The Big Web Show features special guests and topics like web publishing, art direction, content strategy, typography, web technology, and more. Get episodes delivered to you automatically:

• Audio RSS Feed
• iTunes Audio

So. Jetzt aber Frühling! Und pünktlich zu den ersten Sonnenstrahlen und Temperaturschüben zieht das musikalische Tempo ein wenig an. Bei mir jedenfalls. Ist ja nun auch schon wieder über ein Jahr her, seit dem letzten Mixtape.

Die meiste Arbeit macht ja sowieso immer die Tracklist.

Linear gradients in CSS can lead to all kinds of wacky, wacky results—some of them, it sometimes seems, in the syntax itself.

Let me note right up front that some of what I’m talking about here isn’t widely deployed yet, nor for that matter even truly set in stone. Close, maybe, but there could still be changes. Even if nothing actually does change, this isn’t a “news you can use RIGHT NOW” article. Like so much of what I produce, it’s more of a stroll through a small corner of CSS, just to see what we might see.

For all their apparent complexity, linear gradients are pretty simple. You define a direction along which the gradient progresses, and then list as many color stops as you like. In doing so, you describe an image with text, sort of like SVG does. That’s an important point to keep in mind: a linear (or radial) gradient is an image, just as much as any GIF or PNG. That means, among other things, that you can mix raster images and gradient images in the background of an element using the multiple background syntax.

But back to gradients. Here’s a very simple gradient image:

linear-gradient(45deg, red, blue)

The 45deg defines the gradient line, which is the line that defines how the gradient progresses. The gradient line always passes through the center of the background area, and its specific direction is declared by you, the author. In this case, it’s been declared to point toward the 45-degree angle. red and blue are the color stops. Since the colors don’t have stop distances defined, the distances are assumed to be 0% and 100%, respectively, which means you get a gradient blend from red to blue that progresses along the gradient line.

You can create hard stops, too:

linear-gradient(45deg, green 50%, lightblue 50%)

That gets you the result shown in Figure 1, to which I’ve added (in Photoshop) an arrow showing the direction of the gradient line, as well as the centerpoint of the background area. Each individual “stripe” in the gradient is perpendicular to the gradient line; that’s why the boundary between the two colors at the 50% point is perpendicular to the gradient line. This perpendicularness is always the case.

Now, degrees are cool and all (and they’ll be changing from math angles to compass angles in order to harmonize with animations, but that’s a subject for another time), but you can also use directional keywords. Two different kinds, as it happens.

The first way to use keywords is to just declare a direction, mixing and matching from the terms top, bottom, right, and left. The funky part is that in this case, you’re declaring the direction the gradient line comes from, not that toward which it’s going; that is, you specify its origin instead of its destination. So if you want your gradient to progress from the bottom left corner to the top right corner, you actually say bottom left:

linear-gradient(bottom left, green 50%, lightblue 50%)

But bottom left does not equal 45deg, unless the background area is exactly square. If the area is not square, then the gradient line goes from one corner to another, with the boundary lines perpendicular to that, as shown in Figure 2. Again, I added a gradient line and centerpoint in Photoshop for clarity.

Of course, this means that if the background area resizes in either direction, then the angle of the gradient line will also change. Make the element taller or more narrow, and the line will rotate counter-clockwise (UK: anti-clockwise); go shorter or wider and it will rotate clockwise (UK: clockwise). This might well be exactly what you want. It’s certainly different than an degree angle value, which will never rotate due to changes in the background’s size.

The second way to use keywords looks similar, but has quite different results. You use the same top/bottom/left/right terms, but in addition you prepend the to keyword, like so:

linear-gradient(to top right, green 50%, lightblue 50%)

In this case, it’s clear that you’re declaring the gradient line’s destination and not its origin; after all, youære saying to top right. However, when you do it this way, you are not specifying the top right corner of the background area. You’re specifying a general topward-and-rightward direction. You can see the result of the previous sample in Figure 3; once more, Photoshop was used to add the gradient line.

Notice the hard-stop boundary line. It’s actually stretching from top left to bottom right (neither of which is top right). That’s because with the to keyword in front, you’re triggering what’s been referred to as “magic corners” behavior. When you do this, no matter how the background area is (re)sized, that boundary line will always stretch from top left to bottom right. Those are the magic corners. The gradient line thus doesn’t point into the top right corner, unless the background area is perfectly square—it points into the top right quadrant (quarter) of the background area. Apparently the term “magic quadrants” was not considered better than “magic corners”.

The effect of changing the background area’s size is the same as before; decreasing the height or increasing the width of the background area will deflect the gradient line clockwise, and the opposite change to either axis will produce the opposite deflection. The only difference is the starting condition.

Beyond all this, if you want to use keywords that always point toward a corner, as in Figure 2 except specifying the destination instead of the origin, that doesn’t appear to be an option. Similarly, neither can you declare an origin quadrant. Having the gradient line always traverse from corner to corner means declaring the origin of the gradient line (Figure 2). If you want the “magic corners” effect where the 50% color-stop line points from corner to corner, with the gradient line’s destination flexible, then you declare a destination quadrant (Figure 3).

As for actual support: as of this writing, only Firefox and Opera support “magic corners”. All current browsers—in Explorer’s case, that means IE10—support angles and non-magic keywords, which means Opera and Firefox support both keyword behaviors. Nobody has yet switched from math angles to compass angles. (I used 45deg very intentionally, as it’s the same direction in either system.)

That’s the state of things with linear gradients right now. I’m interested to know what you think of the various keyword patterns and behaviors—I know I had some initial trouble grasping them, and having rather different effects for the two patterns seems like it will be confusing. What say you?