はてなブックマーク

2587 days since last revision. Details are possibly out of date. I’m always on the look out for a simple way to undo default user agent styling on some ‘pickier’ elements (it’s what led to app-reset). Right up front, I want to say that unless you are very careful, you probably don’t want to remove the default styling of ALL elements. Form controls, buttons, video tags etc. all have well-considered

1366 days since last revision. Details are possibly out of date. TL;DR solution for 2020/iOS 13+ Thanks to the comments below (and that’s why I love comments so much), we can put a few things together to have a working CSS only solution for iOS 13+: .bg-scrolling-element-when-modal-active { /* when modal active */ touch-action: none; -webkit-overflow-scrolling: none; overflow: hidden; /* Other bro

2959 days since last revision. Details are possibly out of date. I’ve done a lot of CSS debugging. Others code and my own. Mobile platforms and standard desktop browsers. Everything from old versions of Internet Explorer to the latest WebKit nightlies. What became apparent to me as I’ve worked with others, is that many people don’t have a set procedure for debugging CSS. I found, more often than n

3423 days since last revision. Details are possibly out of date. Right now, I have a near frictionless CSS workflow. I write in Sass, compile with Libsass and get vendor prefixes added with PostCSS/Autoprefixer via Gulp/Grunt. Why would I want to upset that? Just under a year ago, my interest was piqued by a post by Nicolas Gallagher. In it he described how he/they (Twitter) were using a JS tool t

3353 days since last revision. Details are possibly out of date. Around a year ago I wrote a couple of CSS performance related posts. The first post centred on CSS selectors and the second on CSS layout methods (Flexbox v Table). Sadly, while I dispelled (at least for myself) some long-standing CSS performance myths (principally that certain CSS selectors should be avoided at all costs for perform

3467 days since last revision. Details are possibly out of date. For many months now, in response to many failed attempts to find a suitable approach to scaling the CSS on the projects I work on, I have been using ‘ECSS’, my own Frankenstein approach to large-scale CSS architecture. It’s detailed more fully in the post, Enduring CSS: writing style sheets for rapidly changing, long-lived projects.

25th September, 2015. The methodology of this post has now been updated, expanded and detailed more fully in my book, Enduring CSS, available from Leanpub. When architecting CSS for a large scale project it’s a common aim to abstract visual patterns for re-use, DRY out code and normalise our designs as much as possible. However, for rapidly changing projects, I’m no longer convinced those principl

3770 days since last revision. Details are possibly out of date. When it came to cross-testing a design on an old Android recently I came across a familiar problem to most front-end developers. The CSS property/value pair of position: fixed; doesn’t work. Update: 2/3/14 – Since writing this post I actually came across and documented a related issue regarding the poor performance of fixed position

What is fast CSS? Where are the bottlenecks? Are the rules of slow and fast selectors even valid anymore? Are the properties we use more important than the selectors? I felt it was time to revisit some of these questions. In the broad scheme of things, CSS optimisation is certainly low down the priority order when trying to speed websites/web applications up. There are so many other optimisations

3710 days since last revision. Details are possibly out of date. Not long ago I wrote about my current modular CSS (BEM/OOCSS) naming conundrum. This is a shorter but related post about how those kinds of selectors can be produced with new features of Sass 3.3. Update 16th March 2014: The final release of Sass of 3.3 changed the way that suffix selectors could be written. This post (now much short

The bigger the Sass project you work on, the slower compilation of your Sass project can become. That's because ordinarily Sass is Ruby based and there's never been a way around that. Until now. If you are interested in Libsass, you might be interested to read another post about migrating a code base from a Ruby based Sass compiler to Libsass? If so, take a look at ‘Is Libsass, the lightning fast

This post is now pretty out of date. I re-added it as the Chrome dev pages and css-tricks were linking in and nobody likes link rot. However, it’s likely things have changed quite a bit since I wrote this. Consider yourself warned! 😉 This is the third re-write of this post since first posting it back in November 2012. I’ll keep trying to update as and when things change as there’s every chance yo

4182 days since last revision. Details are possibly out of date. Update 17th August 2012: The original version of this post was based on the Editor’s Draft, 20 April 2012. Since then, the specification has undergone further changes. The article has now been updated and is based on the Editor’s Draft, 13th August 2012. The current Editor’s draft can be found at http://dev.w3.org/csswg/css3-flexbox/