Founder Mantras

Founder Mantras seen across 4 different viewports
Founder Mantras seen across 4 different viewports

Visit site

This is a lovely site! Very reactive and the use of the transitions between each mantra for each day and sliding across to the story behind the Mantra is just lovely.

They take care to ensure that the right logo is being shown as well, super crisp but without burdening users with a few extra bytes. IN saying that though, the logo is in a png sprite so it would interesting to see how much extra the file size would be and weigh that up against the workflow to make this happen. This is how it looks...


.full-logo {
  background-image: url(http://foundermantras.com/css/../img/icons-s5cd628bebb.png);
  background-position: -92px -284px;
  background-repeat: no-repeat;
  overflow: hidden;
  display: inline-block;
  height: 72px;
  width: 115px
}

@media all and (-webkit-min-device-pixel-ratio:2) and (max-width:767px),all and (min--moz-device-pixel-ratio:2) and (max-width:767px),all and (-o-min-device-pixel-ratio:2 / 1) and (max-width:767px),all and (min-device-pixel-ratio:2) and (max-width:767px),all and (min-resolution:192dpi) and (max-width:767px),all and (min-resolution:2dppx) and (max-width:767px) {

.full-logo {
  background-image: url(http://foundermantras.com/css/../img/icons2x-s667950b8d3.png)!important;
  background-size: 300px 480px!important;
  background-position: -105px -423px!important
}
}

Based upon this format we can also summise that they are using a breakpoint mixin to declare breakpoints and their associated rules within the context of the module they are currently writing (https://responsivedesign.is/articles/helpful-sass-mixins).

There is a bit of duplication when it comes to declaring the different sprites as well with the same background image being declared each time instead of just updating the background position. This is only going to be an issue if they haven't set the image itself as a Sass variable as there's lots of places to update it when it changes, however from a size point of view GZIP will gobble all of that up... if only gzip was enabled. For all the good work they've done tryig to inline this stuff GZIP isn't actually enabled on the server meaning that for every request they're sending an additional 193.5 KB down the wire Getting started with Gzip.

The breakpoint sizes are hovering very closely around the ipad dimensions. This in itself isn't a problem but I've talked before about staying away from device specific breakpoints (https://responsivedesign.is/articles/why-you-dont-need-device-specific-breakpoints).

The great thing about all this CSS is that it's entirely within the head of the document, so no waiting for another http request before it can be seen. It does appear as though they are using a Critical CSS technique because once all the JS has fired there is a app.min.css request in the head, however I couldn't find where that request was being made.

There seems to be a few bizzare things happening on the first load as well, lots of inline Jquery with both jQuery v1.11.2 and jQuery v1.9.0 being inlined.

Like I said it is a lovely site though and my only complaint is that there is no fallback in the case where JS fails.

Founder Mantras technical details

Meta Viewport

<meta name="viewport" content="width=device-width, minimum-scale=1.0, maximum-scale=1.0, user-scalable=no" />

media-queries

@media all and (max-width:767px) { }
@media all and (min-width:768px) and (max-width:1023px) { }
@media all and (max-height:550px) { }
@media all and (min-width:1600px) { }
@media all and (-webkit-min-device-pixel-ratio:2) and (max-width:767px),all and (min--moz-device-pixel-ratio:2) and (max-width:767px),all and (-o-min-device-pixel-ratio:2 / 1) and (max-width:767px),all and (min-device-pixel-ratio:2) and (max-width:767px),all and (min-resolution:192dpi) and (max-width:767px),all and (min-resolution:2dppx) and (max-width:767px) { }

Framework

These are the frameworks

Javascript