Tags: sass

16

sparkline

Friday, January 5th, 2018

Herman: Automated Pattern Libraries | OddBird

A lightweight style guide generator. This one uses SassDoc to parse out the documentation for colours, type, etc.

Tuesday, November 28th, 2017

V6: Typography and Proportions | Rob Weychert

Rob walks us through the typographic choices for his recent redesign:

Most of what I design that incorporates type has a typographic scale as its foundation, which informs the typeface choices and layout proportions. The process of creating that scale begins by asking what the type needs to do, and what role contrasting sizes will play in that.

Tuesday, July 18th, 2017

Patterns Day 2017: Sareh Heidari on Vimeo

Time for another video from Patterns Day. Here’s Sareh Heidari walking us through Grandstand, the CSS framework at the BBC.

Patterns Day 2017: Sareh Heidari

Wednesday, March 1st, 2017

“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.

Thursday, November 3rd, 2016

Adoption

Tom wrote a post on Ev’s blog a while back called JavaScript Frameworks: Distribution Channels for Good Ideas (I’ve been hoping he’d publish it on his own site so I’d have a more permanent URL to point to, but so far, no joy). It’s well worth a read.

I don’t really have much of an opinion on his central point that browser makers should work more closely with framework makers. I’m not so sure I agree with the central premise that frameworks are going to be around for the long haul. I think good frameworks—like jQuery—should aim to make themselves redundant.

But anyway, along the way, Tom makes this observation:

Google has an institutional tendency to go it alone.

JavaScript not good enough? Let’s create Dart to replace it. HTML not good enough? Let’s create AMP to replace it. I’m just waiting for them to announce Google Style Sheets.

I don’t really mind these inventions. We’re not forced to adopt them, and generally, we don’t. Tom again:

They poured enormous time and money into Dart, even building an entire IDE, without much to show for it. Contrast Dart’s adoption with the adoption of TypeScript and Flow, which layer improvements on top of JavaScript instead of trying to replace it.

See, that’s a really, really good point. It’s so much easier to get people to adjust their behaviour than to change it completely.

Sass is a really good example of this. You can take any .css file, save it as a .scss file, and now you’re using Sass. Then you can start using features (or not) as needed. Very smart.

Incidentally, I’m very curious to know how many people use the scss syntax (which is the same as CSS) compared to how many people use the sass indented syntax (the one with significant whitespace). In his brilliant Sass for Web Designers book, I don’t think Dan even mentioned the indented syntax.

Or compare the adoption of Sass to the adoption of HAML. Now, admittedly, the disparity there might be because Sass adds new features, whereas HAML is a purely stylistic choice. But I think the more fundamental difference is that Sass—with its scss syntax—only requires you to slightly adjust your behaviour, whereas something like HAML requires you to go all in right from the start.

This is something that has been on my mind a lately while I’ve been preparing my new talk on evaluating technology (the talk went down very well at An Event Apart San Francisco, by the way—that’s a relief). In the talk, I made a reference to one of Grace Hopper’s famous quotes:

Humans are allergic to change.

Now, Grace Hopper subsequently says:

I try to fight that.

I contrast that with the approach that Tim Berners-Lee and Robert Cailliau took with their World Wide Web project. The individual pieces were built on what people were already familiar with. URLs use slashes so they’d be feel similar to UNIX file paths. And the first fledging version of HTML took its vocabulary almost wholesale from a version of SGML already in use at CERN. In fact, you could pretty much take an existing CERN SGML file and open it as an HTML file in a web browser.

Oh, and that browser would ignore any tags it didn’t understand—behaviour that, in my opinion, would prove crucial to the growth and success of HTML. Because of its familiarity, its simplicity, and its forgiving error handling, HTML turned to be more successful than Tim Berners-Lee expected, as he wrote in his book Weaving The Web:

I expected HTML to be the basic waft and weft of the Web but documents of all types: video, computer aided design, sound, animation and executable programs to be the colored threads that would contain much of the content. It would turn out that HTML would become amazingly popular for the content as well.

HTML and SGML; Sass and CSS; TypeScript and JavaScript. The new technology builds on top of the existing technology instead of wiping the slate clean and starting from scratch.

Humans are allergic to change. And that’s okay.

Thursday, October 13th, 2016

Thoughtful CSS Architecture | Sparkbox | Web Design and Development

A good overview of ideas and techniques for structuring CSS and naming classes.

Thursday, May 12th, 2016

The Sonos Pattern Library — zdfs

There’s a lot I disagree with here. I don’t think this pattern library process is very elegant or scalable, and it certainly wouldn’t work for me.

But I’m still linking to it. Why? Because I think it’s absolutely wonderful that people share their processes like this. It doesn’t matter one whit whether or not it would work for me.

Frontend development may have gotten a lot more complicated, but the simple premise of sharing what you’ve learned hasn’t.

I couldn’t agree more!

Sunday, February 28th, 2016

How to lint your Sass/CSS properly with Stylelint — Creative Nightly

Linting CSS seems like a very good idea, especially if you’re not the only one writing the CSS. This guide is going to come in very handy when I give it a try.

Thursday, January 8th, 2015

Sass Guidelines

Advice for writing Sass. I don’t necessarily agree with everything, but on the whole, this is a solid approach.

It’s worth bearing Chris’s advice in mind.

Monday, July 28th, 2014

GitHub’s CSS · @mdo

Mark Otto talks through the state of Github’s CSS and the processes behind updating it. There’s a nice mix of pragmatism and best practices, together with a recognition that there’s always room for improvement.

Tuesday, December 17th, 2013

Sasstraction

Emil has been playing around with CSS variables (or “custom properties” as they should more correctly be known), which have started landing in some browsers. It’s well worth a read. He does a great job of explaining the potential of this new CSS feature.

For now though, most of us will be using preprocessors like Sass to do our variabling for us. Sass was the subject of Chris’s talk at An Event Apart in San Francisco last week—an excellent event as always.

At one point, Chris briefly mentioned that he’s quite happy for variables (or constants, really) to remain in Sass and not to be part of the CSS spec. Alas, I didn’t get a chance to chat with Chris about that some more, but I wonder if his thinking aligns with mine. Because I too believe that CSS variables should remain firmly in the realm of preprocessers rather than browsers.

Hear me out…

There are a lot of really powerful programmatic concepts that we could add to CSS, all of which would certainly make it a more powerful language. But I think that power would come at an expense.

Right now, CSS is a relatively-straightforward language:

CSS isn’t voodoo, it’s a simple and straightforward language where you declare an element has a style and it happens.

That’s a somewhat-simplistic summation, and there’s definitely some complexity to certain aspects of CSS—like specificity or margin collapsing—but on the whole, it has a straightforward declarative syntax:

selector {
    property: value;
}

That’s it. I think that this simplicity is quite beautiful and surprisingly powerful.

Over at my collection of design principles, I’ve got a section on Bert Bos’s essay What is a good standard? In theory, it’s about designing standards in general, but it matches very closely to CSS in particular. Some of the watchwords are maintainability, modularity, extensibility, simplicity, and learnability. A lot of those principles are clearly connected. I think CSS does a pretty good job of balancing all of those principles, while still providing authors with quite a bit of power.

Going back to that fundamental pattern of CSS, you’ll notice that is completely modular:

selector {
    property: value;
}

None of those pieces (selector, property, value) reference anything elsewhere in the style sheet. But as soon as you introduce variables, that modularity is snapped apart. Now you’ve got a value that refers to something defined elsewhere in the style sheet (or even in a completely different style sheet).

But variables aren’t the first addition to CSS that sacrifices modularity. CSS animations already do that. If you want to invoke a keyframe animation, you have to define it. The declaration and the invocation happen in separate blocks:

selector {
    animation-name: myanimation;
}
@keyframes myanimation {
    from {
        property: value;
    }
    to {
        property: value;
    }
}

I’m not sure that there’s any better way to provide powerful animations in CSS, but this feature does sacrifice modularity …and I believe that has a knock-on effect for learnability and readability.

So CSS variables (or custom properties) aren’t the first crack in the wall of the design principles behind CSS. To mix my metaphors, the slippery slope began with @keyframes (and maybe @font-face too).

But there’s no denying that having variables/constants in CSS provide a lot of power. There’s plenty of programming ideas (like loops and functions) that would provide lots of power to CSS. I still don’t think it’s a good idea to mix up the declarative and the programmatic. That way lies XSLT—a strange hybrid beast that’s sort of a markup language and sort of a programming language.

I feel very strongly that HTML and CSS should remain learnable languages. I don’t just mean for professionals. I believe it’s really important that anybody should be able to write and style a web page.

Now does that mean that CSS must therefore remain hobbled? No, I don’t think so. Thanks to preprocessors like Sass, we can have our cake and eat it too. As professionals, we can use tools like Sass to wield the power of variables, functions (mixins) and other powerful concepts from the programming world.

Preprocessors cut the Gordian knot that’s formed from the tension in CSS between providing powerful features and remaining relatively easy to learn. That’s why I’m quite happy for variables, mixins, nesting and the like to remain firmly in the realm of Sass.

Incidentally, at An Event Apart, Chris was making the case that Sass’s power comes from the fact that it’s an abstraction. I don’t think that’s necessarily true—I think the fact that it provides a layer of abstraction might be a red herring.

Chris made the case for abstractions being inherently A Good Thing. Certainly if you go far enough down the stack (to Assembly Language), that’s true. But not all abstractions are good abstractions, and I’m not just talking about Spolky’s law of leaky abstractions.

Let’s take two different abstractions that share a common origin story:

  • Sass is an abstraction layer for CSS.
  • Haml is an abstraction layer for HTML.

If abstractions were inherently A Good Thing, then they would both provide value to some extent. But whereas Sass is a well-designed tool that allows CSS-savvy authors to write their CSS more easily, Haml is a steaming pile of poo.

Here’s the crucial difference: Sass doesn’t force you to write all your CSS in a completely new way. In fact, every .css file is automatically a valid .scss file. You are then free to use—or ignore—the features of Sass at your own pace.

Haml, on the other hand, forces you to use a completely new whitespace-significant syntax that maps on to HTML. There are no half-measures. It is an abstraction that is not only opinionated, it refuses to be reasoned with.

So I don’t think that Sass is good because it’s an abstraction; I think that Sass is good because it’s a well-designed abstraction. Crucially, it’s also easy to learn …just like CSS.

Friday, March 22nd, 2013

Specializing yourself into a corner by Scott Kellum

I can empathise with Scott’s worries about fragmentation on the front-end with Saas, Styles, LESS, Compass, yada, yada, yada.

I want to share my code with everyone who writes CSS, not a subset of that group.

Sunday, June 3rd, 2012

IE-friendly mobile-first CSS with Sass 3.2

Jake demonstrates his technique for preprocessor-generated stylesheets for older versions of Internet Explorer (while other browsers get the same styles within media queries).

Issue #408: Generate a separate css with flattened media queries

This is an excellent idea from Jake: use a preprocessor to automatically spit out a stylesheet for older versions of IE that includes desktop styles (garnered from the declarations within media queries).

If you’re a dab hand with Ruby and you’d like to see this in SASS, you can help.

Sunday, March 4th, 2012

How I’m implementing Responsive Web Design – JeffCroft.com

Jeff documents some of the techniques he’s using to tackle responsive design, with some tips specifically for SASS.

Tuesday, November 29th, 2011

“Mobile first” CSS and getting Sass to help with legacy IE – Nicolas Gallagher

If you use Sass, this could be a really handy technique for handling IE<9 support with mobile-first responsive designs.