CSS Rants

Responsive Design is a Hack

Responsive design has become a quick-and-dirty way to say “Hey! We looked at this on not-just-a-PC!” Our users deserve so much better — something that intentionally works with the ever-increasing array of input methods. Keyboards, cursors, touch, voice, & motion; the digital world has never been simultaneously as accessible and as overtly complicated as it is today.

Netflix does a pretty good job at wrangling the chaos, designing experiences around the input method, reducing touches and navigational elements on more simple devices and taking advantage of all available screen real-estate to maximize an interfaces usefulness.

Maybe we’ll call it “Input Aware” or “Device Aware” design — I guess I don’t really care about the name as much as distinguishing the approach from the myriad of responsive hacks and shims floating aimlessly around our collective github toolboxes.

I was recently reminded of the spectrum of media-types available to the CSS2.1 media spec, which largely got me thinking about how bad we are at utilizing them:

  • all — Suitable for all devices.
  • braille — Intended for braille tactile feedback devices.
  • embossed — Intended for paged braille printers.
  • handheld — Intended for handheld devices (typically small screen, limited bandwidth).
  • print — Intended for paged material and for documents viewed on screen in print preview mode. Please consult the section on paged media for information about formatting issues that are specific to paged media.
  • projection — Intended for projected presentations, for example projectors. Please consult the section on paged media for information about formatting issues that are specific to paged media.
  • screen — Intended primarily for color computer screens.
  • speech — Intended for speech synthesizers. Note: CSS2 had a similar media type called ‘aural’ for this purpose. See the appendix on aural style sheets for details.
  • tty — Intended for media using a fixed-pitch character grid (such as teletypes, terminals, or portable devices with limited display capabilities). Authors should not use pixel units with the “tty” media type.
  • tv — Intended for television-type devices (low resolution, color, limited-scrollability screens, sound available).

CSS2.1 even comes with a handy media-groups spec to pair media-types to devices based on their anticipated attributes:

Media Types Media Groups
continuous/paged visual/audio/speech/tactile grid/bitmap interactive/static
braille continuous tactile grid both
embossed paged tactile grid static
handheld both visual, audio, speech both both
print paged visual bitmap static
projection paged visual bitmap interactive
screen continuous visual, audio bitmap both
speech continuous speech N/A both
tty continuous visual grid both
tv both visual, audio bitmap both

Typical responsive design approaches target the screen type (and maybe print) which is accidentally celebrating doing-responsive-design-wrong. To correctly respond to different devices, we need to target more than max-width and min-width in the screen media-type, and let browsers and rendering engines on our televisions and refrigerators do their jobs.

Unfortunately for me, the software libraries I live most of my life in right now (WordPress, BuddyPress, and bbPress) are all pretty bad at this. The WordPress iOS app is a crippled version of WordPress’s relatively fantastic interface; WordPress itself barely functions on small screens and touch devices; BuddyPress & bbPress do the bare minimum to inherit surrounding styling, but don’t own the experience or set a great example in this regard as much as they might in others.

The greater tech community needs to target more input devices, intentionally design better experiences, and stop patting ourselves on our backs for doing the bare minimum of design.

Sure… it’s an iterative process, and yes… we’re all working hard and putting in the long hours together to improve the digital world around us, but it’s a great time to lift up our heads, unsquint our eyes, and design for the world around us instead of for ourselves.

CSS bbPress Software WordPress

Retina 2x downsampling

While working on some 2x retina images for, and the bbPress and WordPress open-source projects, I found an image rendering issue that I haven’t seen documented anywhere yet. Here’s the WordPress core retina ticket, for reference.

The first image highlights the difference between the WordPress core 2x icons, and the bbPress 2x icons. Notice how the icons next to Forums, Topics, and Replies have a slightly thicker black outline, specifically in 2x mode. The icons next to Posts, Pages, et all, are WordPress’s icon32 equivalents, with the same border thickness as the original 32px icons used in the 1x headers.

Using the original 32px icons was a great idea for a first-pass win at having 2x icons in WordPress core, and there are 64px equivalents now too! The difference between the WordPress and bbPress icons is subtle but important when you look at the second image in the gallery.

If the browser loads 2x images, but the display (for whatever reason) renders in 1x mode, you naturally end up with downsampled 2x images. To purposely duplicate this behavior:

  • Have a Retina MacBook Pro.
  • Connect Cinema Display.
  • Open Safari.
  • Move Safari 50% between the rMBP display, and the Cinema Display.
  • Watch any 2x images downsample to 1x size.

While edge case, the circumstances where a browsers’ calculated pixel ratio does not match the display are a new bug from a new convention. Arguably, operating systems and graphics cards should handle this more smoothly, and I suspect they will eventually. Until then, if the risk is providing a worse experience than plain-old 1x images, it’s our responsibility to include 2x images that will downsample to a usable state in 1x mode.

Weird, wild stuff!