Blogging, Programming

CSS learnings from 2013

I don’t do masses of CSS in my work but this year was an interesting one because there was acres of CSS being created due to the general acceptance that we just need to get on with implementing the responsive web. Leaving the fixed-width grid also meant having to rethink the structure and architecture of CSS and modernise the legacy styling which if we’re all honest is actually created organically and piecemeal as requirements drift in.

CSS Architecture

I struggled and fought with SMACSS but I’m now over it and think that the result in practice has shown that it is the most sensible way to do things today.

BEM felt overly complex and fussy while covering pretty much the same ideas as SMACSS. OOCSS was off-putting due to its weird appropriation of object-orientated programming concepts.

I did like its idea of using multiple classes to allow for composition of styles. But using the idea of multiple inheritance as a metaphor for this seemed to be bizarre. Don’t these people know how painful inheritance is?

Isolation

One of the big things I took from SMACSS is that isolation is more valuable than re-use. Using a system that guarantees that your styling rules are not going to have side-effects is massively powerful.

When you then try to abstract components and share rules between them you lose some of that isolation and you begin to recouple components.

Seeing CSS as a conflict between isolation and duplication was a powerful metaphor for making decisions as to how to structure things.

Pre-compilers

I’m pretty sure that when we look back at 2013 the invention of Turing-complete CSS pre-compilers is not going to be a high-point. The CSS generation languages have been important as a way of pushing the CSS specification forward and of proving ideas in practice. I’ve certainly been grateful to be able to use Less in prototyping for example.

The agreement of the need for CSS variables and for being able to do calculations with those variables is a credit to the pre-compilers. The problem they create is the complexity of their abstraction. Turning a declarative language into something more programmatic is problematic for all the reasons that programming languages have problems. DRY is good but compilation errors in your CSS doesn’t feel like progress to me.

Just as with user agent extensions I think that pre-compilers are a great test bed for innovation but what they need to lead to is a better syntax for declaring intention rather than a new language.

Migration

Having new ideas for organising and structuring CSS is great but we also need to reflect our new ideas in our old work. Well, that’s easy right? Now we have new ideas we’ll just call all our existing assets legacy and re-write the whole thing. It’ll probably only take three months or more…

For the project I worked most on I applied a rule of thumb that seemed to serve pretty well. All the new CSS architectures organise themselves around a concept of components or modules. If your existing CSS is more or less built around the same concept you should be able to adapt whatever structure you choose and retroactively apply it to your existing code.

If your existing code though is designed more around concepts of pages or tag styling then you need to rebuild it piecemeal. Introduce the new component with its styling build on the new standard and then go back and

Hacks and shame

I was quite taken by the idea of having the file of shame. However in practice developers preferred to have commented sections of the files with hacks in. And before long we had people accidentally adding non-hack rules after the hack commment-line and we also have hacks liberally sprinkled all over the place.

I lost the battle but the result has convinced me that you want one place for the hackery and you want it right at the bottom of the cascade.

The incentive should be to one day delete the file of shame.

Simplicity

Clearly this year the only person who was talking any sense in CSS (apart from Jonathan Snook) was Harry Roberts as I also liked the presentation where he pointed out that design needs to be regularised in the name of sanity. If we have some components that have a margin of 1rem and and some with a margin of 1.1rem because it looks better we need to be taking into account the cognitive burden of having those additional rules.

Creating independent components encouraged me to allow every one to be a special snowflake. It was good to have a counter-balancing principle to make sure that principal of least surprise applied.

Harry also made the sensible suggestion (in 2012!) that padding and margins be defined in just one vertical and horizontal direction. Thing about flow from top to bottom and left to right also helped me to stop make special cases and look for a more general declaration of what I was trying to describe.

Standard
Programming

Google Chrome wants to sit at the table

I fixed a weird CSS bug last week which I think is an interesting illustration of the difficulties of implementing a standard. One of the ways that I layout our website is by using CSS Tables to provide right-sidebars and content splits. One of our components consists of an image in a left-column, content and then a button bar in a right-column.

The whole strip of content was marked as display: table-row and the columns were display: table-cell.

On Firefox this was fine and the full width of the page was used with the correct proportions for the content blocks. On Chrome however the width of the whole component was around 75% of the whole page width (with the correct proportions). After a lot of examination it appeared that Chrome genuinely felt the page was narrower at that point.

It took a few weeks to get the necessary mindshift to fix it. The problem was the interpretation of how display: table-* works when you don’t have the full hierarchy. My interpretation is that the browser fills in the implied parent elements and that worked correctly in Firefox. In Chrome however I needed to change my table-row to table for the full width of the page to be used. The implied table wasn’t the full width of the page, while the explicit one was with the implied table-row occupying the correct full width.

This worked fine on Firefox as well so the problem was solved! Always have a top-element that defines display: table.

Standard
Web Applications

Important! !important is a danger sign

Until recently I had never seen the CSS keyword !important used in a production site. However just recently I have seen it in use and also had to use it myself to fix a few cascade issues.

CSS selectors work by assigning a “magic number” that indicates how specific the selector is in relation to the other selectors. Important works by boosting that number by a magnitude or ignoring all other selectors entirely. You can read the exact rules in the specification.

Important is really powerful and as a result you never want to use it. It’s kind of like the CSS A-Bomb, if you ever have to use it, something has gone wrong. The biggest problem with !important is that it can “lock” a style element and make it hard to override it in other cascades. Inevitably this becomes a problem because there is pretty much nothing in CSS that can be regarded as universal in the appearance and rendering of a website.

This then leads to other stylesheets also using !important in their selectors to overcome the earlier !important. This limits their reuse as they now, in turn, export their overly powerful rules and therefore require yet more !important use and so on and so on until every selector has !important on it.

Stylesheets should try to have as weak as possible selectors (without going overboard and perhaps applying some styling information too liberally). This makes them more generally useful as often people only dislike a few elements in a style or an individual page only has a few components that do not gel well with the general style.

I think !important should never be used when creating CSS. There are perhaps two exceptions I can think of: firstly client styles, you know best, fill your boots; secondly, stylesheets that you know represent the real bottom of a cascade. For example an optional stylesheet that renders the site in monochrome can reasonably be expected to represent the final word in a cascade.

Standard
Web Applications

CSS Table borders hiccup

Question: why do my HTML table cells have a space around them? Why don’t the join up like a normal table?

Answer: the border-spacing attribute is not set to zero by default. Try setting it explicitly to 0em in the style sheet.

I can’t believe this has caught me out twice! I don’t understand why you would not want the border spacing to anything other than zero by default.

I found this site to be really helpful for understanding the table model in CSS.

Standard