Wednesday, August 14, 2013

CSS: Reality Lies To Us

Well, CSS media queries don't really suck, they just aren't expressive enough to allow a designer to concisely specify the intent of the design, or even to specify intent at all. So, OK, they suck a little, but not totally.

SASSy CSS and LESS CSS compilers can help, but they are mainly server-side technologies. Yes, your browser can be tricked out to run a compiler against them, but until the syntax is embedded in the client that's more of a hack than a deployment technology.

Furthermore, SASS and LESS don't alter the execution context of the decision making in applying CSS stylesheets. The languages support computation and refactoring of sources, but only using a-priori knowledge: discrete facts available outside of any particular deployment context. This is a intentional feature of CSS, not a bug, but the manner in which CSS media queries are written degrades the expressiveness with respect to the designers intent.

For example, why do we write media queries that ask:

@media screen and (orientation: landscape) and (min-device-width: 1024px) and (max-device-width: 2048px) { ... }

... when what we mean to ask if whether or not this is a touchpad similar to an iPad in size?

One thing we could do is use a Web standard. How about the HTML "handheld" media type?

Virtually no mobile device will trigger the "handheld" rule. The first phones to implement the handheld media type were crude affairs, and rather than do the right thing when they rolled out new devices, vendors of smart phones decided to put up their collective middle finger to Web standards and have their browsers lie.  They all claim to be monitor screens, which, by the way, they are not.

It turns out that "handheld" does not really tell us it is a touch pad device anyway. Handheld only tells us only that it is a mobile device. We also have touch screens that are static devices, like Point of Sale terminals, kiosks, and appliance-style surfaces. Even if vendors complied with Web standards and supported "handheld," our pages still wouldn't know if the device supported the touch screen modality and/or provided WIMP cursor-based interactions.

CSS, as implemented by vendors, has made us compound errors upon error. It isn't just imprecision, it is an emphasis on irrelevant precision and a focus on the wrong parameters. Designing using quantized units, such as ems, goes part way in mitigating some of the over-constrained precision. Yet CSS still does not allow us to write what we mean, and still forces us to make assertions that are not correct in order to trip the machine into behavior that looks more or less accidentally correct as a side-effect.

Here's another example: CSS goes out of its way with max-backwards syntax so as to avoid less-than and greater-than operators. This is outstandingly silly as we go forward with HTML5. This is technology: instead of avoiding math we should embrace it.  The algebra isn't really that scary:

@media touchscreen and (52ppi <= resolution <= 104ppi) and ( 7.31in <= device-size <= 9.5in) { ... }

Thursday, August 1, 2013

Software as an Abstraction vs Software as a Practice

This past few months has seen quite some turnover in some groups at my workplace, one an administrative team and the other an I.T./Web-support team.

It got me to thinking this morning. While some churn is unavoidable and at a low level is probably good for an organization, it can also be corrosive when a proportionally large chunk of the team just goes away. It eats away at the knowledge and experience embodied by the team as a whole.

We like to think of operational software as some sort of abstract machine. Yet software is also what a team does to reflect upon, institute, and refine its own knowledge and behavior: it is a professional practice.

So when a bunch of people up and leave an organization, the practice can break down.