Post pobrano z: Reboot, Resets, and Reasoning

I saw in an article by Nicholas Cerminara the other day (careful visiting that link, looks like they have some tracking scripts run wild) that Bootstrap 4 has a new CSS reset baked in they are calling Reboot:

Reboot, a collection of element-specific CSS changes in a single file, kickstart Bootstrap to provide an elegant, consistent, and simple baseline to build upon.

If you’re new to CSS development, the whole idea of a CSS reset is to deal with styling inconsistencies across browsers. For example, just now I popped a <button> onto a page with no other styling whatsoever. Chrome applies padding: 2px 6px 3px; – Firefox applies padding: 0 8px;. A CSS reset would apply new padding to that element, so that all browsers are consistent about what they apply. There are loads of examples like that.

By way of a bit of history…

In 2007 Jeff Starr rounded up a bunch of different CSS resets. The oldest one dated is Tantek Çelik’s undohtml.css (that’s a direct link to the source). We can see that the purpose behind it was to strip away default styling.

/* undohtml.css */
/* (CC) 2004 Tantek Celik. Some Rights Reserved.             */
/*   http://creativecommons.org/licenses/by/2.0                   */
/* This style sheet is licensed under a Creative Commons License. */

/* Purpose: undo some of the default styling of common (X)HTML browsers */

By far, the most popular reset came shortly after: the Meyer reset. It has different stuff in it than Tantek’s did (it has even been updated with some HTML5 elements) but the spirit is the same: remove default styling. You’ll probably recognize this famous block of code, finding its way into your DevTools style panel everywhere:

html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, embed, 
figure, figcaption, footer, header, hgroup, 
menu, nav, output, ruby, section, summary,
time, mark, audio, video {
	margin: 0;
	padding: 0;
	border: 0;
	font-size: 100%;
	font: inherit;
	vertical-align: baseline;
}

Start with a reset like this (at the top of your production stylesheet) and the styles you write afterword will be on a steady foundation.

Years later, as HTML5 became more real, resets like Richard Clark’s HTML5 Reset gained popularity. It was still a modified version of the Meyer reset, and the retained that spirit.

article,aside,details,figcaption,figure,
footer,header,hgroup,menu,nav,section { 
    display:block;
}

Sprinkled all throughout this, there were plenty of developers who went minimal by just zapping margin and padding from everything and leaving it at that:

* {
  padding: 0;
  margin: 0;
}

Dumb trivia: the CSS-Tricks logo was inspired by the universal selector and that idea.

Along comes Normalize.css…

Normalize.css represents the first meaningful shift in spirit for what a CSS reset should do. This is what seemed so different about it to me:

• It was a fresh evaluation of everything that could be styled different across browsers and it address all of it. Where older CSS resets were a handful of lines of code, the uncompressed and documented normalize is 447.
• It didn’t remove any styling from elements that were already consistent across browsers (for the most part). For example, there isn’t anything in Normalize for h2-h6 elements, just a fix for a weird h1 thing. That means you aren’t zapping away header hierarchy, that default styling remains.
• It was more accommodating to the idea of altering it, rather than just including it. For example, there is a section just for the <pre> tag and one line of that sets its font-family. You could change that to the font-family you want, and it would be just as effective of a reset.

The code is satisfying to read, as it explains what it’s doing without drowning in specifics:

/**
 * 1. Remove the bottom border in Chrome 57- and Firefox 39-.
 * 2. Add the correct text decoration in Chrome, Edge, IE, Opera, and Safari.
 */

abbr[title] {
  border-bottom: none; /* 1 */
  text-decoration: underline; /* 2 */
  text-decoration: underline dotted; /* 2 */
}

Today Normalize is at 7.0.0 and has going on 30,000 GitHub stars. It’s wicked popular.

So… resets can be opinionated?

We’ve seen lots of different takes on CSS resets and we’ve seen fundamental shifts in the approach, so I think it’s fair to say CSS resets can take an opinionated stance.

Let’s consider some ways…

• Does the reset touch every single possible element? Or a subset of elements? How does it decide which elements to touch and which not to?
• What properties are changed? Only ones with cross-browser differences? Or some other criteria, like the similarity to other elements that needed changes? Is it OK to apply properties to elements that don’t have cross-browser issues in the name of consistency and efficiency?
• Do you try to preserve the spirit of the user agent stylesheet? Sensible defaults?
• Do you apply any properties that don’t have cross-browser issues could be considered beneficial to „reset”, like typographic defaults or box-sizing?
• Do you include „toolbox” classes for common needs? Or leave that for other projects to handle?
• Are you concerned about the size of it?
• Do you use a preprocessor or any other tooling?

Take a look at Vanilla CSS Un-Reset. Loads of opinions here, starting with the idea that it’s meant to re-style elements after you un-style then with a reset. It set’s the body font size in pt, set a very specific monospace font stack, includes a ol ol ol ol selector, a clearfix, and alignment helper classes. No judgment there. People make things to help with their own problems and I’m sure this was helpful to the creator. But we can see the opinions shine through there.

Now look at MiniReset.css. Very different! It does wipe out type styles „so that using semantic markup doesn’t affect the styling”, but leaves some defaults in place on purpose „so that buttons and inputs keep their default layout”, puts in some things that don’t have cross-browser problems but are useful globally (box-sizing), and adds some minor responsive design helpers.

Totally different set of opinions there.

Jonathan Neal created a reset called santize.css that is very clear about it’s opinions. Search for the word „opinionated” in the source code and you’ll see it 19 times. All these are choices that Jonathan made based on research and what seem to be modern best practices, and no doubt sprinkled with his own needs and desires for what should be in a reset.

/*
 * Remove the text shadow on text selections (opinionated).
 * 1. Restore the coloring undone by defining the text shadow (opinionated).
 */

::-moz-selection {
	background-color: #b3d4fc; /* 1 */
	color: #000000; /* 1 */
	text-shadow: none;
}

::selection {
	background-color: #b3d4fc; /* 1 */
	color: #000000; /* 1 */
	text-shadow: none;
}

The word „reset”

Personally, I think it’s useful to think of all of them under the same umbrella term and just be aware of the philosophical differences. But, Normalize intentionally separates itself:

A modern, HTML5-ready alternative to CSS resets

Sanitize calls itself a CSS library and doesn’t use the word „reset” anywhere except to cite the Meyer reset.

Reboot

Reboot is interesting as it’s perhaps the newest player in this world. It’s file history dates back to 2015, which is probably related to Bootstrap 4 taking a while to drop after Bootstrap 3. Reboot doesn’t have its own repo, it’s a part of Bootstrap. Here’s the direct file and the docs.

The way they think about it is interesting:

Reboot builds upon Normalize, providing many HTML elements with somewhat opinionated styles using only element selectors. Additional styling is done only with classes. For example, we reboot some <table> styles for a simpler baseline and later provide .table, .table-bordered, and more.

You can have a class that does styling, but if you use a reset, you don’t have to overload that class with reset styles that handle cross-browser consistency issues.

//
// Tables
//

table {
  border-collapse: collapse; // Prevent double borders
}

caption {
  padding-top: $table-cell-padding;
  padding-bottom: $table-cell-padding;
  color: $text-muted;
  text-align: left;
  caption-side: bottom;
}

th {
  // Matches default `<td>` alignment by inheriting from the `<body>`, or the
  // closest parent with a set `text-align`.
  text-align: inherit;
}

It’s definitely opinionated, but in a way that rolls with Bootstrap nicely. The fact that it’s buried within Bootstrap is pretty good signaling this is designed for that world, not as a drop-in for any project. That said, I did my best to compile a straight CSS version of it here.

Tailoring a reset based on browser support

So long as we’re talking about the past and future of resets, it’s worth mentioning Browserslist again, which is a standardized format for declaring what browsers/versions a project supports.

A reset could be built in a such a way that the things it includes know why they are there. Exactly what browser and version it is there to support. Then if browserslist configuration says that particular browser isn’t supported by this project anyway, that CSS could be removed.

That’s what PostCSS Normalize does.

Reboot, Resets, and Reasoning is a post from CSS-Tricks

Post pobrano z: Hexatope

It was awesome to hear Charlotte Dann on CodePen Radio the other day, who is Kickstarting a new jewelry business. The idea is that you draw your own jewelry (everything you draw looks awesome because it’s on this interesting hexagon grid) and then it gets actually made. This tying together of her passions sprang to life on CodePen.

Direct Link to Article — Permalink

Hexatope is a post from CSS-Tricks

Post pobrano z: Breaking down CSS Box Shadow vs. Drop Shadow

Drop shadows. Web designers have loved them for a long time to the extent that we used to fake them with PNG images before CSS Level 3 formally introduced them to the spec as the box-shadow property. I still reach for drop shadows often in my work because they add a nice texture in some contexts, like working with largely flat designs.

Not too long after box-shadow was introduced, a working draft for CSS Filters surfaced and, with it, a method for drop-shadow() that looks a lot like box-shadow at first glance. However, the two are different and it’s worth comparing those differences.

For me, the primary difference came to light early on when I started working with box-shadow. Here’s a simple triangle not unlike the one I made back then.

See the Pen CSS Caret by CSS-Tricks (@css-tricks) on CodePen.

Let’s use this to break down the difference between the two.

Box Shadow

Add a box-shadow on that bad boy and this happens.

See the Pen CSS Caret Box Shadow by CSS-Tricks (@css-tricks) on CodePen.

It’s annoying, but makes sense. CSS uses a box model, where the element’s edges are bound in the shape of a rectangle. Even in cases where the shape of the element does not appear to be a box, the box is still there and that is was box-shadow is applied to. This was my „ah-ha moment” when understanding the box in box-shadow.

CSS Filter Drop Shadow

CSS Filters are pretty awesome. Take a gander at all the possibilities for adding visual filters on elements and marvel at how CSS suddenly starts doing a lot of things we used to have to mockup in Photoshop.

Filters are not bound to the box model. That means the outline of our triangle is recognized and the transparency around it is ignored so that the intended shape receives the shadow.

See the Pen CSS Caret Drop Shadow by CSS-Tricks (@css-tricks) on CodePen.

Deciding Which Method to Use

The answer is totally up to you. The simple example of a triangle above might make it seem that filter: drop-shadow() is better, but it’s not a fair comparison of the benefits or even the possibilities of both methods. It’s merely an illustration of their different behaviors in a specific context.

Like most things in development, the answer of which method to use depends. Here’s a side-by-side comparison to help distinguish the two and when it might be best to choose one over the other.

Wrapping Up

The difference between box-shadow and filter: drop-shadow() really boils down to the CSS box model. One sees it and the other disregards it. There are other differences that distinguish the two in terms of browser support, performance and such, but the way the two treat the box model is the key difference.

Update: Amelia identified another key difference in the comments where the spread of the radius for drop-shadow() is calculated differently than box-shadow and even that of text-shadow. That means that the spread radius you might specify in box-shadow is not one-to-one with the default spread value for drop-shadow, so the two are not equal replacements of one another in some cases.

Let’s cap this off with a few other great examples illustrating that. Lennart Schoors also has a nice write-up with practical examples using tooltips and icons that we previously called out.

See the Pen Drop-shadow vs box-shadow (2) by Kseso (@Kseso) on CodePen.

See the Pen box-shadow & drop-shadow by qnlz (@qnlz) on CodePen.

See the Pen Drop-shadow vs box-shadow (3) en png´s by Kseso (@Kseso) on CodePen.

Breaking down CSS Box Shadow vs. Drop Shadow is a post from CSS-Tricks

Post pobrano z: Creating Vue.js Transitions & Animations

My last two projects hurled me into the JAMstack. SPAs, headless content management, static generation… you name it. More importantly, they gave me the opportunity to learn Vue.js. More than „Build a To-Do App” Vue.js, I got to ship real-life, production-ready Vue apps.

The agency behind Snipcart (Spektrum) wanted to start using decoupled JavaScript frameworks for small to medium sites. Before using them on client projects, however, they chose to experiment on themselves. After a few of my peers had unfruitful experiences with React, I was given the green light to prototype a few apps in Vue. This prototyping morphed into full-blown Vue apps for Spektrum connected to a headless CMS. First, I spent time figuring out how to model and render our data appropriately. Then I dove head first into Vue transformations to apply a much-needed layer of polish on our two projects.

I’ve prepared live demos on CodePen and GitHub repos to go along with this article.

This post digs into Vue.js and the tools it offers with its transition system. It is assumed that you are already comfortable with the basics of Vue.js and CSS transitions. For the sake of brevity and clarity, we won’t get into the „logic” used in the demo.

Handling Vue.js Transitions & Animations

Animations & transitions can bring your site to life and entice users to explore. Animations and transitions are an integral part of UX and UI design. They are, however, easy to get wrong. In complex situations like dealing with lists, they can be nearly impossible to reason about when relying on native JavaScript and CSS. Whenever I ask backend developers why they dislike front end so vehemently, their response is usually somewhere along the lines of „… animations„.

Even for those of us who are drawn to the field by an urge to create intricate micro-interactions and smooth page transitions, it’s not easy work. We often need to rely on CSS for performance reasons, even while working in a mostly JavaScript environment, and that break in the environment can be difficult to manage.

This is where frameworks like Vue.js step in, taking the guess-work and clumsy chains of setTimeout functions out of transitions.

The Difference Between Transitions and Animations

The terms transition and animation are often used interchangeably but are actually different things.

• A transition is a change in the style properties on an element to be transitioned in a single step. They are often handled purely through CSS.
• An animation is more complex. They are usually multi-step and sometimes run continuously. Animations will often call on JavaScript to pick up where CSS’ lack of logic drops off.

It can be confusing, as adding a class could be the trigger for a transition or an animation. Still, it is an important distinction when stepping into the world of Vue because both have very different approaches and toolboxes.

Here’s an example of transitions in use on Spektrum’s site:

Using Transitions

The simplest way to achieve transition effects on your page is through Vue’s <transition> component. It makes things so simple, it almost feels like cheating. Vue will detect if any CSS animations or transitions are being used and will automatically toggle classes on the transitioned content, allowing for a perfectly timed transition system and complete control.

First step is to identify our scope. We tell Vue to prepend the transition classes with modal, for example, by setting the component’s name attribute. Then to trigger a transition all you need to do is toggle the content’s visibility using the v-if or v-show attributes. Vue will add/remove the classes accordingly.

There are two „directions” for transitions: enter (for an element going from hidden to visible) and leave (for an element going from visble to hidden). Vue then provides 3 „hooks” that represent different timeframes in the transition:

• .modal-enter-active / .modal-leave-active: These will be present throughout the entire transition and should be used to apply your CSS transition declaration. You can also declare styles that need to be applied from beginning to end.
• .modal-enter / .modal-leave: Use these classes to define how your element looks before it starts the transition.
• .modal-enter-to / .modal-leave-to: You’ve probably already guessed, these determine the styles you wish to transition towards, the „complete” state.

To visualize the whole process, take a look at this chart from Vue’s documentation:

How does this translate into code? Say we simply want to fade in and out, putting the pieces together would look like this:

<button class="modal__open" @click="modal = true">Help</button>

<transition name="modal">
  <section v-if="modal" class="modal">
    <button class="modal__close" @click="modal = false">&times;</button>
  </section>
</transition>

.modal-enter-active,
.modal-leave-active { transition: opacity 350ms }

.modal-enter,
.modal-leave-to { opacity: 0 }

.modal-leave,
.modal-enter-to { opacity: 1 }

This is likely the most basic implementation you will come across. Keep in mind that this transition system can also handle content changes. For example, you could react to a change in Vue’s dynamic <component>.

<transition name="slide">
  <component :is="selectedView" :key="selectedView"/>
</transition>

.slide-enter { transform: translateX(100%) }
.slide-enter-to { transform: translateX(0) }
.slide-enter-active { position: absolute }

.slide-leave { transform: translateX(0) }
.slide-leave-to { transform: translateX(-100%) }

.slide-enter-active,
.slide-leave-active { transition: all 750ms ease-in-out }

Whenever the selectedView changes, the old component will slide out to the left and the new one will enter from the right!

Here’s a demo that uses these concepts:

See the Pen VueJS transition & transition-group demo by Nicolas Udy (@udyux) on CodePen.

Transitions on Lists

Things get interesting when we start dealing with lists. Be it some bullet points or a grid of blog posts, Vue gives you the <transition-group> component.

It is worth noting that while the <transition> component doesn’t actually render an element, <transition-group> does. The default behaviour is to use a <span> but you can override this by setting the tag attribute on the <transition-group>.

The other gotcha is that all list items need to have a unique key attribute. Vue can then keep track of each item individually and optimize its performance. In our demo, we’re looping over the list of companies, each of which has a unique ID. So we can set up our list like so:

<transition-group name="company" tag="ul" class="content__list">
  <li class="company" v-for="company in list" :key="company.id">
    <!-- ... -->
  </li>
</transition-group>

The most impressive feature of transition-group is how Vue handles changes in the list’s order so seamlessly. For this, an additional transition class is available, .company-move (much like the active classes for entering and leaving), which will be applied to list items that are moving about but will remain visible.

In the demo, I broke it down a bit more to show how to leverage different states to get a cleaner end result. Here’s a simplified and uncluttered version of the styles:

/* base */
.company {
  backface-visibility: hidden;
  z-index: 1;
}

/* moving */
.company-move {
  transition: all 600ms ease-in-out 50ms;
}

/* appearing */
.company-enter-active {
  transition: all 300ms ease-out;
}

/* disappearing */
.company-leave-active {
  transition: all 200ms ease-in;
  position: absolute;
  z-index: 0;
}

/* appear at / disappear to */
.company-enter,
.company-leave-to {
  opacity: 0;
}

Using backface-visibility: hidden on an element, even in the absence of 3D transforms, will ensure silky 60fps transitions and avoid fuzzy text rendering during transformations by tricking the browser into leveraging hardware acceleration.

In the above snippet, I’ve set the base style to z-index: 1. This assures that elements staying on page will always appear above elements that are leaving. I also apply a absolute positioning to items that are leaving to remove them from the natural flow, triggering the move transition on the rest of the items.

That’s all we need! The result is, frankly, almost magic.

Using Animations

The possibilities and approaches for animation in Vue are virtually endless, so I’ve chosen one of my favourite techniques to showcase how you could animate your data.

We’re going to use GSAP’s TweenLite library to apply easing functions to our state’s changes and let Vue’s lightning fast reactivity reflect this on the DOM. Vue is just as comfortable working with inline SVG as it is with HTML.

We’ll be creating a line graph with 5 points, evenly spaced along the X-axis, whose Y-axis will represent a percentage. You can take a look here at the result.

See the Pen SVG path animation with VueJS & TweenLite by Nicolas Udy (@udyux) on CodePen.

Let’s get started with our component’s logic.

new Vue({
  el: '#app',
  // this is the data-set that will be animated
  data() {
    return {
      points: { a: -1, b: -1, c: -1, d: -1, e: -1 }
    }
  },

  // this computed property builds an array of coordinates that
  // can be used as is in our path
  computed: {
    path() {
      return Object.keys(this.points)
        // we need to filter the array to remove any
        // properties TweenLite has added
        .filter(key => ~'abcde'.indexOf(key))
        // calculate X coordinate for 5 points evenly spread
        // then reverse the data-point, a higher % should
        // move up but Y coordinates increase downwards
        .map((key, i) => [i * 100, 100 - this.points[key]])
    }
  },

  methods: {
    // our randomly generated destination values
    // could be replaced by an array.unshift process
    setPoint(key) {
      let duration = this.random(3, 5)
      let destination = this.random(0, 100)
      this.animatePoint({ key, duration, destination })
    },
    // start the tween on this given object key and call setPoint
    // once complete to start over again, passing back the key
    animatePoint({ key, duration, destination }) {
      TweenLite.to(this.points, duration, {
        [key]: destination,
        ease: Sine.easeInOut,
        onComplete: this.setPoint,
        onCompleteParams: [key]
      })
    },
    random(min, max) {
      return ((Math.random() * (max - min)) + min).toFixed(2)
    }
  },

  // finally, trigger the whole process when ready
  mounted() {
    Object.keys(this.points).forEach(key => {
      this.setPoint(key)
    })
  }
});

Now for the template.

<main id="app" class="chart">
  <figure class="chart__content">
    <svg xmlns="http://www.w3.org/2000/svg" viewBox="-20 -25 440 125">
      <path class="chart__path" :d="`M${path}`"
        fill="none" stroke="rgba(255, 255, 255, 0.3)"
        stroke-width="1.2" stroke-linecap="round" stroke-linejoin="round"/>

      <text v-for="([ x, y ]) in path" :x="x - 10" :y="y - 7.5"
        font-size="10" font-weight="200" fill="currentColor">
        {{ 100 - (y | 0) + '%' }}
      </text>
    </svg>
  </figure>
</main>

Notice how we bind our path computed property to the path element’s d attribute. We do something similar with the text nodes that output the current value for that point. When TweenLite updates the data, Vue reacts instantly and keeps the DOM in sync.

That’s really all there is to it! Of course, additional styles were applied to make things pretty, which at this point you might realize is more work then the animation itself!

Live demos (CodePen) & GitHub repo

Go ahead, browse the live demos or analyze/re-use the code in our open source repo!

• The vue-animate GitHub repo
• The vue-transitions GitHub repo
• The Vue.js transition & transition-group demo
• The SVG path animation demo

Conclusion

I’ve always been a fan of animations and transitions on the web, but I’m also a stickler for performance. As a result, I’m always very cautious when it comes to relying on JavaScript. However, combining Vue’s blazing fast and low-cost reactivity with its ability to manage pure CSS transitions, you would really have to go overboard to have performance issues.

It’s impressive that such a powerful framework can offer such a simple yet manageable API. The animation demo, including the styling, was built in only 45 minutes. And if you discount the time it took to set up the mock data used in the list-transition, it’s achievable in under 2 hours. I don’t even want to imagine the migraine-inducing process of building similar setups without Vue, much less how much time it would take!

Now get out there and get creative! The use cases go far beyond what we have seen in this post: the only true limitation is your imagination. Don’t forget to check out the transitions and animations section in Vue.js’ documentation for more information and inspiration.

This post originally appeared on Snipcart’s blog. Got comments, questions? Add them below!