Tags: styles

34

sparkline

Wednesday, March 1st, 2017

The Unexpected Power of Viewport Units in CSS | Lullabot

A nice rundown of some of the fun you can have with viewport units.

I’m very glad the problems with vh units I wrote about a little while back is getting fixed in Chrome for mobile.

“Cooking with Design Systems,” an article by Dan Mall

Dan describes his approach to maintainable CSS. It’s a nice balance between semantic naming and reusable styles.

Warning: the analogies used here might make you very, very hungry.

Saturday, February 18th, 2017

Base64 Encoding & Performance, Part 1: What’s Up with Base64?

Harry clearly outlines the performance problems of Base64 encoding images in stylesheets. He’s got a follow-up post with sample data.

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.

Monday, December 12th, 2016

Sunday, October 23rd, 2016

On Style Maintenance | CSS-Tricks

This is a very thoughtful analysis of different approaches to writing maintainable CSS, which—let’s face it—is the hard bit.

I often joke that I don’t want to hire a code ninja. Ninjas come in the middle of the night and leave a bloody mess.

I want a code janitor. Someone who walks the hallways of code, cleaning up pieces, dusting up neglected parts, shinning up others, tossing unnecessary bits. I prefer this gentler, more accurate analogy. This is the person you want on your team. This is a person you want in your code reviews.

Also, can I just say how refreshing it is to read an article that doesn’t treat the cascade like a disease to be wiped out? This article even goes so far as to suggest that the cascade might actually be a feature—shock! horror!

The cascade can help, if you understand and organize it. This is the same as any sophisticated software design. You can look at what you’re building and make responsible decisions on your build and design. You decide what can be at a top-level and needs to be inherited by other, smaller, pieces.

There’s a lot of really good stuff in here to mull over.

My hope for this article is to encourage developers to think ahead. We’re all in this together, and the best we can do is learn from one another.

Wednesday, July 13th, 2016

CSS Diner - Where we feast on CSS Selectors!

Here’s a fun game to help practice those CSS selectors.

Tuesday, July 12th, 2016

CSS Containment Module Level 3

A way of declaring the scope of an element’s layout and paint styles, which browsers can then use as a hint to optimise performance. It’s already shipping in Chrome and Opera.

Monday, May 30th, 2016

marmelab/universal.css: The only CSS you will ever need

Ensure that your class names never go out of sync with your style declarations with this one simple trick:

Take any CSS rule you want to apply, replace : by -, and dots by -dot-, and you get the name of the corresponding universal css classname.

The only thing missing is immutability, so I would suggest also putting !important after each declaration in the CSS. Voila! No more specificity battles.

Thursday, March 10th, 2016

ECSS

Enduring CSS (not int the sense of “put up with” but in the sense of “long-lasting”) is a new book by Ben Frain all about writing and maintaining modular reusable CSS.

You can read the whole thing for free online or buy an eBook.

Monday, February 8th, 2016

Battling BEM – 5 common problems and how to avoid them

We tend to use a variant of BEM in our CSS at Clearleft. Glad to see that when we’ve hit these issues, we’ve taken the same approach.

Wednesday, August 26th, 2015

Whatever works for you

I was one of the panelists on the most recent episode of the Shop Talk Show along with Nicole, Colin Megill, and Jed Schmidt. The topic was inline styles. Well, not quite. That’s not a great term to describe the concept. The idea is that you apply styling directly to DOM nodes using JavaScript, instead of using CSS selectors to match up styles to DOM nodes.

It’s an interesting idea that I could certainly imagine being useful in certain situations such as dynamically updating an interface in real time (it feels a bit more “close to the metal” to reflect the state updates directly rather than doing it via class swapping). But there are many, many other situations where the cascade is very useful indeed.

I expressed concern that styling via JavaScript raises the barrier to styling from a declarative language like CSS to a programming language (although, as they pointed out, it’s more like moving from CSS to JSON). I asked whether it might not be possible to add just one more layer of abstraction so that people could continue to write in CSS—which they’re familiar with—and then do JavaScript magic to match those selectors, extract those styles, and apply them directly to the DOM nodes. Since recording the podcast, I came across Glen Maddern’s proposal to do exactly that. It makes sense to me try to solve the perceived problems with CSS—issues of scope and specificity—without asking everyone to change the way they write.

In short, my response was “hey, like, whatever, it’s cool, each to their own.” There are many, many different kinds of websites and many, many different ways to make them. I like that.

So I was kind of surprised by the bullishness of those who seem to honestly believe that this is the way to build on the web, and that CSS will become a relic. At one point I even asked directly, “Do you really believe that CSS is over? That all styles will be managed through JavaScript from here on?” and received an emphatic “Yes!” in response.

I find that a little disheartening. Chris has written about the confidence of youth:

Discussions are always worth having. Weighing options is always interesting. Demonstrating what has worked (and what hasn’t) for you is always useful. There are ways to communicate that don’t resort to dogmatism.

There are big differences between saying:

  • You can do this,
  • You should do this, and
  • You must do this.

My take on the inline styles discussion was that it fits firmly in the “you can do this” slot. It could be a very handy tool to have in your toolbox for certain situations. But ideally your toolbox should have many other tools. When all you have is a hammer, yadda, yadda, yadda, nail.

I don’t think you do your cause any favours by jumping straight to the “you must do this” stage. I think that people are more amenable to hearing “hey, here’s something that worked for me; maybe it will work for you” rather than “everything you know is wrong and this is the future.” I certainly don’t think that it’s helpful to compare CSS to Neanderthals co-existing with JavaScript Homo Sapiens.

Like I said on the podcast, it’s a big web out there. The idea that there is “one true way” that would work on all possible projects seems unlikely—and undesirable.

“A ha!”, you may be thinking, “But you yourself talk about progressive enhancement as if it’s the one try way to build on the web—hoisted by your own petard.” Actually, I don’t. There are certainly situations where progressive enhancement isn’t workable—although I believe those cases are rarer than you might think. But my over-riding attitude towards any questions of web design and development is:

It depends.

Tuesday, August 26th, 2014

A Single Div

Wonderfully creative use of CSS gradients, borders, box-shadows, and generated content.

Saturday, August 23rd, 2014

A device agnostic approach to inlining CSS | Blog | Decade City

I very much agree with Orde’s framing here: I don’t think it makes much sense to talk about “above the fold” CSS …but it makes a lot of sense to talk about critical CSS.

And, yeah, it’s another example of progressive enhancement.

Monday, June 10th, 2013

Request Quest

A terrific quiz about browser performance from Jake. I had the pleasure of watching him present this in a bar in Amsterdam—he was like a circus carny hoodwinking the assembled geeks.

I guarantee you won’t get all of this right, and that’s a good thing: you’ll learn something. If you do get them all right, either you are Jake or you are very, very sad.

Tuesday, June 19th, 2012

Classes? Where We’re Going, We Don’t Need Classes! | Smashing Coding

This is a well-reasoned, thoughtful article on avoiding class names in CSS …but I don’t agree with it. That said, perhaps there’s a reasonable middle ground to be found between this extreme stance and the opposite (but in some ways just as extreme) stance of OOCSS.

Thursday, March 15th, 2012

Abstract Sequential - Print Styles Are Responsive Design

An excellent piece by Stephanie on how to approach print stylesheets. I’ve always maintained that Print First can be as valid as Mobile First in getting you to focus on what content really matters.

Wednesday, November 16th, 2011

Structuring a Responsive Stylesheet | Sparkbox

Some thoughts on structuring your CSS for responsive designs.

Saturday, October 29th, 2011

What’s slated for CSS4 Selectors? - destroy/dstorey

David gives a quick rundown of some of the selectors we can expect to see in CSS4.

Tuesday, May 17th, 2011

Layer Styles

A handy little GUI for generating CSS declarations for shadows, gradients, opacity and border radius.