Posts Tagged ‘css’

How I refactored CSS when redesigning a website iteratively

28th April 2019

Nowadays it’s thankfully common that any backend redesign of a system, website or service is done iteratively, bit by bit. I often hear that that cannot be done with the frontend, that redesigning the look of a website always means you have to do a so-called “Big Bang release“, the very risky practice of releasing all relevant changes in one go after months of working on it.
I can prove that this is not true, because I’ve done two iterative redesigns of a website twice in my last job.

When I was rewriting and redesigning most of Zopa’s website iteratively in 2013, I used a specific method to refactor the CSS. When trying to explain how I did that, I found it’s easiest to explain its principles by showing what I did in a simplified version.
Here is that simplified version.

(Note: This blog post was hiding in my drafts folder for a couple of years. Nowadays it is best practice to use encapsulated components to achieve something similar.)


Pure CSS image lightboxes

13th May 2016

I don’t like using JavaScript unnecessarily. That’s why I love pure CSS solutions. As browsers are getting better and better at implementing CSS3 features, pure CSS solutions are getting slicker and more production-ready.

One of the few pure CSS solutions I built recently was a pure CSS lightbox. I built my solution first and then looked at the tens of other solutions out there to compare and check if I missed anything important.


The trouble with HTML and CSS skills

15th November 2012

When talking to recruitment agents, I very often hear that having “just” HTML and CSS skills is no big deal as everyone is good at those. That’s probably because they hear and read so many times from web developers that they are really good at them. So, they think those skills are not very valuable.

But the truth is, while many developers say they have good HTML and CSS skills, most of them really haven’t. The problem is that the languages themselves are very easy (so, they might not be really lying as such). But applying them to real world projects isn’t easy at all. You could also say it’s the distinction between “CSS, the language” and “CSS, the skill”.
If it was easy, why is the quality of at least 90% of the web so crap? While working with other developers I have found that the vast majority (at least about 90%) of them are overestimating their HTML and CSS skills by far.

During the over 10 years of working in this business, I have worked with roughly 100 other web developers. And out of those only five were good enough in HTML and CSS so that I would rate them 4 or 5 (out of 5).


Trick Question: How many link states can be defined in CSS?

10th July 2011

Hint: There is more than one correct answer (well, sort of). I would fail 4 and pass 3 of them, while 2 of the 3 correct answers would get extra points (because it’s rare knowledge).

  1. 1
  2. 2
  3. 4
  4. 5
  5. 8
  6. 16
  7. 20


Basic is the new Reset

8th May 2011

I don’t like reset styles. (And I’m not the only one.) Instead I’m a fan of good basic styles.

Don’t get me wrong, reset styles serve their purpose. They are good for beginners and many intermediates and can save them a lot of trouble. It’s better to use reset styles if you’re not sure why basic styles might be better than not to use any of those two concepts.
Reset and basic styles alike should serve as a reminder to overwrite browser presets.

I don’t see the reason why you might declare, say, the first headline to have no margin (h1 {margin: 0;}), only to redeclare it to have a bottom margin (h1 {margin-bottom: 1em;}) a few lines later.
Basic styles should set all styles instead of resetting them. In order to make reset styles unnecessary, you only need to make sure to style every element and their necessary properties which browser default styles might add. And declare everything else that makes sense in your case.

So, ideally you should set and reset what you need at the same time. That’s what I’m doing with my basic styles.

Most of these styles are quite universal. I tried to keep them as generic as possible (e.g. with many shades of grey). But they are not meant to be taken without adjusting them to each project. You most likely want to change everything I marked with “§font”, “§fsize” and “§colour”.

They are already part of my DokuWiki Starter template and are will therefore be part of the new (soon to come) DokuWiki default template. I will provide an always up-to-date version apart from the following current version (2011-05-08): I will maintain them as basic.css on GitHub.