Live Q&A: Miriam Suzanne on Susy and the need for toolkits on 18th Aug, 2pm (PST)

, ,

So we’re trying to build tools that describe patterns, without describing how you will use them. Like a hammer, the tool is just there, and you can build anything you want with it. Do you need to hit something? Hammers are great for that! And they never say “wait! you’re building a chair? I’m a table-building hammer!”

2 Likes

what do you recommend for a beginner to learn?

1 Like

What is the best toolkit out there to work with static sites built with a tool like Jenkins?

1 Like

Yeah. I guess maintenance is a big problem, especially when projects last for much longer than they were expected to. It feels like many code-bases are expected to last for several years, and keep on being used for many more. When maintained properly, that’s less of a problem than it could be.

Also, nods. Stepping back into the more abstract has many benefits, I’m sure. Multi-purpose tools are way more useful than single-use ones, in that sense.

But the Accoutrement are still only part of the solution. Sass has been great for helping us define CSS patterns, but I don’t think HTML patterns get enough attention. I want to see more attention given to that — something better than “we’ll just turn everything into javaScript!” An HTML templating language should:

  • allow you to define re-usable patterns, using mixins/macros and functions.
  • allow enough logic to solve display problems like turning a timestamp into a readable format
  • be a superset of HTML, so pure HTML is a completely valid template
  • make it clear what will be compiled, and what won’t be. HTML should look like HTML, and the template code should look like template code
  • compile to DOM
5 Likes

nods Thank you, excellent answer.

Everything they find interesting! I never would have learned CSS if I started with the basics. I started with Eric Meyer’s old CSS Edge gimmics, because they got me excited.

But also: the basics are fine. You don’t need to learn any special tools to get your hands dirty. I think one of the best things about Sass is that you can start slowly. Pure CSS is valid Sass. Just add one thing at a time, as you have the chance to learn it. Sass can build hugely powerful tools, but it can also just store a variable, or help you organize your code in partials. Learn tools that excite you, or ease the pain.

5 Likes

Ha. This is a great question for me, and I wish I knew the answer. I maintain 4 different static sites, and I just use the first tool I learned. It’s called rstBlog, and it’s completely undocumented and un-maintained — BUT I KNOW IT SUPER WELL, and I’ve learned to make it do what I need in weird custom ways. Some day, maybe, I’ll look around at the alternatives. For now, I use what works.

3 Likes

I think this is a lesson we all get to learn now that the web is growing up. :slight_smile:

3 Likes

Heh heh, so true :slight_smile:

Yeah, but you get there by solving real problems. Our first solutions were much more opinionated. The more projects we use it on, the more we are able to see what is essential, and trim away the cruft. That’s also why Susy 3 is planning to be so tiny compared to Susy 2.

2 Likes

Oh, yes. It’s hard to see what is essential at the outset.

We’re in the very early stages of working on a style-guide generator (Herman) that understands both Sass and Jinja/Nunjucks (our template language of choice). The goal is to have a generator that we never need to touch, because it is so well integrated into the code and development. We’ll see! :slight_smile:

3 Likes

That looks really neat. :slight_smile: I’m looking forward to it already! What’s the projected timeline on that?

(Herman looks really neat) :slight_smile:

Would you go over the similarities and differences of using Susy vs. border-box sizing vs. flexbox in Sass for a novice who wants to build a responsive multi-column site?

3 Likes

No timeline! We just keep adding to it as we have time. The entire goal is that it shouldn’t get in our way, so I expect it to come along slowly. We’ll focus on writing well-patterned code, and then keep looking for ways to document those patterns better.

One of the most difficult problems to solve is the integration between languages. A good style guide is about all your code coming together in one place. That means CSS/Sass, JS, HTML/templates, etc. If you can’t document them all together in a meaningful way, you’re not quite there.

We haven’t solved that problem yet.

4 Likes

Nice!

1 Like

You can use all three together!

These actually solve slightly different problems:

  • flexbox is what I call a “layout technique” (similar to floats, inline-block, tables, etc). It’s a way that the browser understands creating regions on the page, and managing how they flow. All of these techniques have advantages and drawbacks. But flexbox was the only one designed to handle layout. Currently, that makes it my favorite, despite the issues. Soon, we’re also getting Grid layouts in CSS, so that will be another option. I recommend learning how they all work, so you can use each one where it makes the most sense. One tool is never enough!
  • border-box helps you to describe the size of a single element in new ways. Do you want to define the content, and let the padding expand? If so, use content-box. If you want to describe the outer size, and let the content adjust, use border-box. Having that flexibility is huge, and a big upgrade from what we had 7 years ago. Again, learn how both options work, so you can be more flexible.
  • Susy is just a calculator. If you find yourself doing a lot of math to get the grid you want, use Susy. Or, in many cases I think it would be better to say: maybe your grids don’t actually need to be that complex?
4 Likes

Well, it’s time to wrap up the Q&A.

@mirisuzanne, we still have a few questions to answer from before the event went live. Would you like to answer those first before we say bye?