Tags: css



Thursday, January 19th, 2017

bastianallgeier/letter: Letter is a simple, highly customizable tool to create letters in your browser.

A nice little use of print (and screen) styles from Bastian—compose letters in a web browser.

Instead of messing around in Word, Pages or even Indesign, you can write your letters in the browser, export them as HTML or PDF (via Apple Preview).

Understanding the Critical Rendering Path

A nice and clear description of how browsers parse and render web pages.

Sunday, January 15th, 2017

Browser Support for evergreen websites

Oh, how I wished everyone approached building for the web the way that Rachel does. Smart, sensible, pragmatic, and exciting!

Monday, January 9th, 2017

The Futures of Typography

A wonderfully thoughtful piece from Robin, ranging from the printing technologies of the 15th century right up to the latest web technologies. It’s got all my favourite things in there: typography, digital preservation, and service workers. Marvellous!

Friday, January 6th, 2017

Redesign v15 Notes | CSS-Tricks

Chris redesigned CSS Tricks and it’s got some really nice touches. I particularly like the stacked card view on mobile.

Tuesday, January 3rd, 2017

Kiss My Classname - Zeldman on Web & Interaction Design

I understand how bloated and non-reusable code can get when a dozen people who don’t talk to each other work on it over a period of years. I don’t believe the problem is the principle of semantic markup or the cascade in CSS. I believe the problem is a dozen people working on something without talking to each other.

Vertical limit

When I was first styling Resilient Web Design, I made heavy use of vh units. The vertical spacing between elements—headings, paragraphs, images—was all proportional to the overall viewport height. It looked great!

Then I tested it on real devices.

Here’s the problem: when a page loads up in a mobile browser—like, say, Chrome on an Android device—the URL bar is at the top of the screen. The height of that piece of the browser interface isn’t taken into account for the viewport height. That makes sense: the viewport height is the amount of screen real estate available for the content. The content doesn’t extend into the URL bar, therefore the height of the URL bar shouldn’t be part of the viewport height.

But then if you start scrolling down, the URL bar scrolls away off the top of the screen. So now it’s behaving as though it is part of the content rather than part of the browser interface. At this point, the value of the viewport height changes: now it’s the previous value plus the height of the URL bar that was previously there but which has now disappeared.

I totally understand why the URL bar is squirrelled away once the user starts scrolling—it frees up some valuable vertical space. But because that necessarily means recalculating the viewport height, it effectively makes the vh unit in CSS very, very limited in scope.

In my initial implementation of Resilient Web Design, the one where I was styling almost everything with vh, the site was unusable. Every time you started scrolling, things would jump around. I had to go back to the drawing board and remove almost all instances of vh from the styles.

I’ve left it in for one use case and I think it’s the most common use of vh: making an element take up exactly the height of the viewport. The front page of the web book uses min-height: 100vh for the title.


But as soon as you scroll down from there, that element changes height. The content below it suddenly moves.

Let’s say the overall height of the browser window is 600 pixels, of which 50 pixels are taken up by the URL bar. When the page loads, 100vh is 550 pixels. But as soon as you scroll down and the URL bar floats away, the value of 100vh becomes 600 pixels.

(This also causes problems if you’re using vertical media queries. If you choose the wrong vertical breakpoint, then the media query won’t kick in when the page loads but will kick in once the user starts scrolling …or vice-versa.)

There’s a mixed message here. On the one hand, the browser is declaring that the URL bar is part of its interface; that the space is off-limits for content. But then, once scrolling starts, that is invalidated. Now the URL bar is behaving as though it is part of the content scrolling off the top of the viewport.

The result of this messiness is that the vh unit is practically useless for real-world situations with real-world devices. It works great for desktop browsers if you’re grabbing the browser window and resizing, but that’s not exactly a common scenario for anyone other than web developers.

I’m sure there’s a way of solving it with JavaScript but that feels like using an atomic bomb to crack a walnut—the whole point of having this in CSS is that we don’t need to use JavaScript for something related to styling.

It’s such a shame. A piece of CSS that’s great in theory, and is really well supported, just falls apart where it matters most.

Update: There’s a two-year old bug report on this for Chrome, and it looks like it might actually get fixed in February.

Monday, December 19th, 2016

The math of CSS locks

A very very in-depth look at fluid typography in CSS using calc.

Friday, December 16th, 2016

Print styles

I really wanted to make sure that the print styles for Resilient Web Design were pretty good—or at least as good as they could be given the everlasting lack of support for many print properties in browsers.

Here’s the first thing I added:

@media print {
  @page {
    margin: 1in 0.5in 0.5in;
    orphans: 4;
    widows: 3;

That sets the margins of printed pages in inches (I could’ve used centimetres but the numbers were nice and round in inches). The orphans: 4 declaration says that if there’s less than 4 lines on a page, shunt the text onto the next page. And widows: 3 declares that there shouldn’t be less than 3 lines left alone on a page (instead more lines will be carried over from the previous page).

I always get widows and orphans confused so I remind myself that orphans are left alone at the start; widows are left alone at the end.

I try to make sure that some elements don’t get their content split up over page breaks:

@media print {
  p, li, pre, figure, blockquote {
    page-break-inside: avoid;

I don’t want headings appearing at the end of a page with no content after them:

@media print {
  h1,h2,h3,h4,h5 {
    page-break-after: avoid;

But sections should always start with a fresh page:

@media print {
  section {
    page-break-before: always;

There are a few other little tweaks to hide some content from printing, but that’s pretty much it. Using print preview in browsers showed some pretty decent formatting. In fact, I used the “Save as PDF” option to create the PDF versions of the book. The portrait version comes from Chrome’s preview. The landscape version comes from Firefox, which offers more options under “Layout”.

For some more print style suggestions, have a look at the article I totally forgot about print style sheets. There’s also tips and tricks for print style sheets on Smashing Magazine. That includes a clever little trick for generating QR codes that only appear when a document is printed. I’ve used that technique for some page types over on The Session.

Experiment: Using Picture Element and VW+VH units as a Lightbox

This is a clever technique by Dave—use viewport units to make a lightweight lightbox.

Monday, December 12th, 2016

Friday, December 9th, 2016

Get the Balance Right: Responsive Display Text ◆ 24 ways

Some really great CSS tips from Rich on sizing display text for multiple viewports.

Wednesday, December 7th, 2016

Is JavaScript more fragile? – Baldur Bjarnason

Progressive enhancement’s core value proposition, for me, is that HTML and CSS have features that are powerful in their own right. Using HTML, CSS, and JavaScript together makes for more reliable products than just using Javascript alone in a single-page-app.

This philosophy doesn’t apply to every website out there, but it sure as hell applies to a lot of them.

Eric’s Archived Thoughts: CSS Grid!

Eric is excited about the imminent arrival of grid layout in browsers. And after reading the answers to these sure-to-be-frequently asked questions, you’ll be excited too!

Monday, December 5th, 2016

We’ve updated the radios and checkboxes on GOV.UK | GDS design notes

I always loved the way that Gov.uk styled their radio buttns and checkboxes with nice big visible labels, but it turns out that users never used the label area. And because it’s still so frickin’ hard to style native form elements, custom controls with generated content is the only way to go if you want nice big hit areas.

Monday, November 28th, 2016

Starting out

I had a really enjoyable time at Codebar Brighton last week, not least because Morty came along.

I particularly enjoy teaching people who have zero previous experience of making a web page. There’s something about explaining HTML and CSS from first principles that appeals to me. I especially love it when people ask lots of questions. “What does this element do?”, “Why do some elements have closing tags and others don’t?”, “Why is it textarea and not input type="textarea"?” The answer usually involves me going down a rabbit-hole of web archeology, so I’m in my happy place.

But there’s only so much time at Codebar each week, so it’s nice to be able to point people to other resources that they can peruse at their leisure. It turns out that’s it’s actually kind of tricky to find resources at that level. There are lots of great articles and tutorials out there for professional web developers—Smashing Magazine, A List Apart, CSS Tricks, etc.—but no so much for complete beginners.

Here are some of the resources I’ve found:

  • MarkSheet by Jeremy Thomas is a free HTML and CSS tutorial. It starts with an explanation of the internet, then the World Wide Web, and then web browsers, before diving into HTML syntax. Jeremy is the same guy who recently made CSS Reference.
  • Learn to Code HTML & CSS by Shay Howe is another free online book. You can buy a paper copy too. It’s filled with good, clear explanations.
  • Zero to Hero Coding by Vera Deák is an ongoing series. She’s starting out on her career as a front-end developer, so her perspective is particularly valuable.

If I find any more handy resources, I’ll link to them and tag them with “learning”.

CSS Reference - A free visual guide to the most popular CSS properties.

A whole lotta CSS properties and values gathered together in one place. The one-page view is a bit overwhelming, but search and collections can get you to the right bit lickety-split.

Thursday, November 24th, 2016

Between the braces

In a post called Side Effects in CSS that he wrote a while back, Philip Walton talks about different kinds of challenges in writing CSS:

There are two types of problems in CSS: cosmetic problems and architectural problems.

The cosmetic problems are solved by making something look the way you want it to. The architectural problems are trickier because they have more long-term effects—maintainability, modularity, encapsulation; all that tricky stuff. Philip goes on to say:

If I had to choose between hiring an amazing designer who could replicate even the most complicated visual challenges easily in code and someone who understood the nuances of predictable and maintainable CSS, I’d choose the latter in a heartbeat.

This resonates with something I noticed a while back while I was doing some code reviews. Most of the time when I’m analysing CSS and trying to figure out how “good” it is—and I know that’s very subjective—I’m concerned with what’s on the outside of the curly braces.

selector {
    property: value;

The stuff inside the curly braces—the properties and values—that’s where the cosmetic problems get solved. It’s also the stuff that you can look up; I certainly don’t try to store all possible CSS properties and values in my head. It’s also easy to evaluate: Does it make the thing look like you want it to look? Yes? Good. It works.

The stuff outside the curly braces—the selectors—that’s harder to judge. It needs to be evaluated with lots of “what ifs”: What if this selects something you didn’t intend to? What if the markup changes? What if someone else writes some CSS that negates this?

I find it fascinating that most of the innovation in CSS from the browser makers and standards bodies arrives in the form of new properties and values—flexbox, grid, shapes, viewport units, and so on. Meanwhile there’s a whole other world of problems to be solved outside the curly braces. There’s not much that the browser makers or standards bodies can do to help us there. I think that’s why most of the really interesting ideas and thoughts around CSS in recent years have focused on that challenge.

Style List Markers in CSS | CSS-Tricks

A clever way of styling list numbers and bullets in CSS. It feels like this should be its own pseudo-element already though, right? Well, that’s on the way.

Wednesday, November 23rd, 2016

CSS Inheritance, The Cascade And Global Scope: Your New Old Worst Best Friends – Smashing Magazine

A really terrific piece by Heydon that serves as a rousing defence of the cascade in CSS. It’s set up in opposition to methodologies like BEM (and there’s plenty of back’n’forth in the comments), but the truth is that every project is different so the more approaches you have in your toolkit, the better. For many projects, something like BEM is a good idea. For others, not so much.

Funnily enough, I’ve been working something recently where I’ve been embracing the approach that Heydon describes—although, to be fair, it’s a personal project where I don’t have to think about other developers touching the HTML or CSS.