Tag Archives: css

Programming

State of the Browser 2022

I’ve attended a few of these conferences and have always found them helpful. This year it had relocated to the Barbican Centre with the food and drink area overlooking the beautiful Conservatory there, great choice as a venue.

The conference was a hybrid in-person/online event that I think could serve as a model for other conferences that seem to only be focusing on their return to in-person. Due to other commitments I wasn’t able to be at the venue all day and so at lunchtime I headed home and picked up a few of the rest of the talks on the livestream. It was great to have the flexibility and made the whole conference more accessible.

Talks-wise it was interesting as ever and a little bit less inward looking or niche interest that it has been in the past. There were the usual mix of upcoming standards and challenges in implementing them, how to apply techniques to the current broad mainstream of browsers and a little bit of evangelism for playfulness and environment impact.

One of my key takeaways was on this last point; using an image CDN that can do automatic content negotiation to use an efficient modern image standard has a huge carbon saving. It feels a bit crazy that so many companies are still serving fixed sizes and formats off things like Cloudfront and S3.

Bruce Lawson kicked off the event with a good historical perspective talk on the history of standards (and the struggle to create and maintain them) and brought the issues of standardisation through the search for technical solutions to the world of regulation and better digital policy. Engaging with law makers is a more realistic way to improve the online world that the search of technical solutions to social problems.

More practically we can hope that Apple will be compelled as a digital gatekeeper to allow competition on browser implementations on its platform and maybe even fund its Safari team properly to have better compatibility with the general web standards on iOS. I felt it was nice for a recognition that government organisations can be engaged and willing to listen and that progress can be made be working together rather than outside of regular power structures.

Probably the best talk I heard was “Be the browser’s mentor not it’s micromanager” by Andy Bell this talk neatly encompassed two major ideas: the first was the way that layout systems in CSS have advanced to the point where you are describing structure and allowing the layout manager to actually decide the rendering and secondly on how digital design approaches have managed to fall between the abstractions of the grid system and the precise layout of magazine style layout.

By leaning on the layout engines the amount of CSS we have to write is much more minimal than the micromanaging fussiness typical to component design systems. It is also more powerful and expressive, avoiding the overly complex muddle that is often associated with component style systems but also not going too far down the class frenzy of utility class systems.

Sophie Koonin taught me how to use the prefers-reduced-motion preference via the medium of late 90s website chaos. A good example of the mixture of fun and practical content.

I also enjoyed Alistair Shepherd‘s talk which had a few technical bits and pieces but managed to bridge the themes of the conference by wanting to create a personal website that first and foremost reflected his personal interests and then used the tech to deliver the vision he had for himself. Although the idea to have websites that vary according to the time of date is quite an interesting idea.

I didn’t catch the last few talks so I’m hoping to be able to watch them when they come to YouTube (or maybe some federated alternative!).

Overall still one of the necessary conferences to catch for web technology and now easier to engage with than ever before.

Links

Standard
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