Semantic vs Systematized CSS

I largely agree with this Cargo Cult CSS article by Ben Darlow. But I can also appreciate the value of modularity and CSS class names based on visual properties. These ideas don’t have to be exclusive. I draw a distinction on a case by case basis. When a visual construct is thematic enough, in my mind, it becomes a form of semantic understanding - even if it’s decoupled from the content. Definitely code bloat through class-itis is no good, but efficient looking mixins can also generate bloat. Because I see both sides of this coin, I tend to mix and match - e.g. some group of styles for buttons from bootstrap, with my more semantic driven “hand-written” classes. This does not result in code that’s as confusing as it might sound. Ultimately I think coding-it-forward, or coding with the assumption that other people will take it over and need to read/understand it, is the best practice. A little bit of forethought and organization can make a huge difference, no matter what method(s) you choose.

Simple to complex front-end web workflow

Progressive enhancement is starting with a base simple core, usually just simple HTML content that can be read by anything anywhere, and adding on layers of function/style that are more or less optional. I like a similar (although somewhat reversed in spirit) approach to my dev workflow. I start by coding and reviewing in the most modern browsers. These modern browsers have the best tools for diagnosis. Modern browsers also support the latest, and often cleanest, coding style. Later, but well before completion, I re-test things in older browsers and start adding complexity to the code to account for their shortcomings.

One could argue that this workflow goes against the philosophy of progressive enhancement, but in practice it seems well paired because of the simple-to-complex parallels.

Another way of saying this is - if you’re not building a fancy Javascript “space station” of a web app with engineered workarounds for SEO and accessibility, then you need a dumb base layer of just plain ol’ content. But it’s not the base layer that needs much browser testing, it’s the stuff you do beyond - the so-called progressive enhancements.

The approach helps avoid the lowest common denominator effect, an artifact (for me anyway) from table-layout days of making the worst browser my default browser. The idea was “if it works there, it’ll work everywhere.” While it may be safer in some sense, that kind of workflow completely sidesteps innovation.

TLDR: Start simple and raw, but code for the best browsers first.

Solving responsive problems with content

A friend asked me for some thoughts on responsive app building, repurposed notes below:

There’s a conflict with the UX/Design->Build workflow when it comes to responsive sites. The main issue, I think, is that the art of anticipating how things need to be in the form of wireframes becomes less efficient when you start approaching the complexities of multiple interaction modes (mobile/tablet/desk) and infinite screen widths.

Possibly the best solution? Focus on your prototype, and do the following:

  1. strip out all but the most essential
  2. start with bare HTML and make sure you’re leveraging as much as possible for structure
  3. populate your prototype with data or content, lots of it, and ideally realistic data with weird edge cases (long names, etc). I think this will be a much more helpful indicator of which UI choices to make as you go.
  4. build with a mobile-first approach.

The bottom line of this suggestion is that content is king, and if you can look at content in a working prototype, the choices of which responsive solution to pick should become a lot easier.

Blog systems

I’ve been blogging (very unevenly) for a long time now. A friend who was one of the first of a very small group to adopt the term “blog” convinced me to give it a try. At the time the best option available in terms of software to run the blog was a program called Greymatter. After a while I switched to MovableType, which served me well for a long time, and then later WordPress. This blogging was all done under the domain web-graphics.com, and evolved into a somewhat collaborative effort with other authors. Web-graphics died a rather slow and ignored death as I prioritized other things. Over the last six or so years my only web writing has been mostly little drips and drabs on this Tumblr.

Tumblr is pretty great for a number of reasons, but especially for ease of entry. The absence of UI process interference makes writing to a Tumblr less daunting than most other systems. Still, that’s not the only thing that’s important to me in choosing a blog system. Since I’d like to write more, I’m trying to sort out what kind of system to use - and to do that, I’ve made a little spreadsheet.

I haven’t come to a conclusion yet - but I’m leaning towards Middleman. There’s probably 100 other systems I could score on this sheet. To be continued…

Rolling your own CSS selector polyfills with jQuery

It never occurred to me that you can leverage jQuery’s deep browser support for selecting stuff on an ad-hoc basis for your CSS. But now that I found this pattern, I’m seeing it mentioned by folks in a number of places.

Example problem: you want to use :nth-child CSS selection to add margins to every other content block that’s dynamically generated (in other words, markup that you can’t add a class to directly because it changes). But you know old IE (and other old browsers) won’t understand fancier CSS selection like this.

Solution: make a plain old class with the styles you want, and then apply it with jQuery’s addClass function using the fancy selector. It might look like this:

$(‘#container article:nth-of-type(3n-1)’).addClass(‘middle-with-margins’);

Worth noting - it could be confusing later to figure out how you’ve intertwined JS and CSS like this. Adding comments to both the JS and the CSS would help a little.

Related: there’s also this: selectivizr