Canonical Voices

Posts tagged with 'css'

Max

Please Note that this theme is not in use anymore. See this post for more info.

Ghost theme - Part 4: Finishing the Sidebar

On mobile Layouts < 360px width the Sidebar still overflows vertically. Lets fix it and implement the features decided on in Part 3.

First a small screenshot of the problem:

Ghost theme - Part 4: Finishing the Sidebar

As you can see the Sidebar flows into the other content.
To fix this lets remove some margins and change the nav to list its items horizontally.

All done with this bit of CSS in the styles.css file since we are changing the default layout.

.sidebar {
  grid-area: Sidebar;
  display: flex;
  flex-wrap: wrap;
  max-height: var(--sidebar-height);

  & .page-title {
      margin: 0px;
  }

  & .page-description {
      margin: 0px;
  }

  & .navigation {
    & .nav {
      display: flex;
      list-style: none;
      padding: 0px;
      margin: 0px;
    }
  }
}
@media screen and (min-width: 961px) {
    .sidebar {
        position: relative;
    }
}

This has actually become quite a lot to keep in the styles.css file.
Lets extract it into components/sidebar.css and import it.

All should look good now. Except when the content doesnt wrap!
Here is a screenshot of what I mean:

Ghost theme - Part 4: Finishing the Sidebar

Everything is in a row. The fix is quite easy with flexbox. Lets just set the flex-direction to column. That should fix it. Right?

Almost. The flex-wrap: wrap from earlier now messes things up. So lets just get rid of it on the sidebar. It worked great when the direction was row but now it is wrapping at the vertical ends, which is not what we want.

Now the sidebar looks pretty nice and our layout is almost done!

The features

Lets go on to the features:

  1. when scrolling the Title disappears
  2. when scrolling the Description disappears
  3. Only the Navigation is shown and the sidebar should shrink to its size but stay at the top

With position: sticky; the last one is pretty easy to do these days.
But to hide the other two we would need to restructure the HTML of our Sidebar since the position is relative to its parent. Which means it would still go out of the screen together with it.

So the last resort here is JavaScript together with position: fixed;. In general we should not use JavaScript for styling, but for this weird case lets make an exception and add a new class to the sidebar when it scrolls out of view.
Using that class we can then use the correct styles to achieve our goal and maybe add some nice CSS Animation.

Lets code

To use JavaScript create the file assets/js/helpers/styling.js.
The gotede build tools will take care of doing all the hard work of getting it onto the page, such as using babel and concatenating the JavaScript files you create.
Just take note that imports wont work. Since this is a Theme for purely Server-side rendered pages, that is totally fine. The JavaScript should be kept to a minimum here.

It should contain the following code, which will attach a new class to the Sidebar when we scroll down and then remove this class again once we scroll to the top:

function initScrollingListener() {
  const sidebar = document.getElementsByClassName("sidebar")[0];

  function addScrollClass() {
    if (window.pageYOffset >= 0) {
      sidebar.classList.add("scrolled");
      window.removeEventListener("scroll", addScrollClass);
      window.addEventListener("scroll", removeScrollClass);
    }
  }

  function removeScrollClass() {
    if (window.pageYOffset == 0) {
      sidebar.classList.remove("scrolled");
      window.removeEventListener("scroll", removeScrollClass);
      window.addEventListener("scroll", addScrollClass);
    }
  }

  if (window.pageYOffset == 0) {
    window.addEventListener("scroll", addScrollClass);
  } else {
    addScrollClass();
  }
}

initScrollingListener();

You should have some basic understanding of programming to really understand what is happening here but here is a small breakdown:

1.  If pageYOffset is 0 we are at the top, so we add a Listener that will call our addScrollClass function once we scroll. Otherwise we are not at the top and can call that function directly.
2. addScrollClass adds the class to the Sidebar element when we are not at the top of the page and the removes the Listener for calling itself on scrolling. Then it adds the Listener that calls removeScrollClass when we scroll.
3. removeScrollClass does exactly the opposite of addScrollClass.

Here is a list of all the DOM functionalities that are used in this piece of code: window, document, getElementsByClassName, window.pageYOffset, Element.classList, addEventListener, removeEventListener

Maybe you notice that we will call one of these functions every time that we scroll. In this case it is a very small amount of code, but it still has to run on the CPU, which is why we should generally avoid these kind of hacks.

Using the new class

So lets go and implement the things that should happen when we scroll in CSS.

.sidebar {
    /* ... */
    position: fixed;
    /* ... */
    &.scrolled{
        height: calc(var(--sidebar-height) / 1.5);
        width: var(--sidebar-width);

        & .page-title {
           display: none; 
        }

        & .page-description {
           display: none; 
        }
      }

This is all we need for now.
It should be inside the .sidebar block and hides both the description and the title when the scrolled class is added.

While it is not an optimal solution, since we use JavaScript for styling, it works in this case and does not put much load on the CPU since we only add two Listeners to our Window.

An Animation

To add some spiciness to our Sidebar suddenly reducing in size, we can add a small Animation when this happens.
Lets just make a dummy one for now where the Background transitions through colors. We can fine-tune this later when we got to the real colors of the theme.

  &.scrolled {
    /*...*/
    animation: background-transition 3s;
    background-color: yellow;
    z-index: 1;
  }
  /*...*/
  
  @keyframes background-transition {
    0% {
        background-color: blue;
    }
    100% {
        background-color: yellow;
    }
  }

One more thing is left to do.
While we have a nice Sidebar for a mobile layout these rules will break the Desktop design. Since we would have to overwrite all these rules in a MediaQuery lets make it easy on us and instead wrap these inside one themselves to keep the default on the other layouts.
To do this put all the CSS we just created for the scrolled class inside @media screen and (max-width: 960px) and dont forget to wrap them inside the .sidebar class as well.

The final sidebar.css should look like this:

.sidebar {
  grid-area: Sidebar;
  display: flex;
  flex-direction: column;
  max-height: var(--sidebar-height);

  position: fixed;
  top: 0;

  & .page-title {
      margin: 0px;
  }

  & .page-description {
      margin: 0px;
  }

  & .navigation {
    & .nav {
      display: flex;
      list-style: none;
      padding: 0px;
      margin: 0px;
    }
  }
}

@media screen and (max-width: 960px) {
    .sidebar {
        &.scrolled {
            height: calc(var(--sidebar-height) / 1.5);
            width: var(--sidebar-width);
            animation: background-transition 3s;
            background-color: yellow;
            z-index: 1;

        & .page-title {
            display: none; 
        }

        & .page-description {
            display: none; 
        }
        }
    }
}

@media screen and (min-width: 961px) {
    .sidebar {
        position: relative;
    }
}

@keyframes background-transition {
    0% {
        background-color: blue;
    }
    100% {
        background-color: yellow;
    }
}

The end

Here is a GIF of the new behaviour:

Ghost theme - Part 4: Finishing the Sidebar

Caught that Image that overflows our page? A Bug, how nice. I will fix it by next time. If you somehow followed along and want to do this as well, check out the class of such and element and try to find a setting that restricts its width ;)

Otherwise it looks like we are done here from a Basic Layouting point of view.
Of course there is still much needed on the visual front, which is what we will start in Part 6, where it is going to be all about Typography and choosing a Font.

Cover: https://unsplash.com/photos/SXihyA4oEJs

Read more
Max

Please Note that this theme is not in use anymore. See this post for more info.

Ghost theme - Part 4: Finishing the Sidebar

On mobile Layouts < 360px width the Sidebar still overflows vertically. Lets fix it and implement the features decided on in Part 3.

First a small screenshot of the problem:

Ghost theme - Part 4: Finishing the Sidebar

As you can see the Sidebar flows into the other content.
To fix this lets remove some margins and change the nav to list its items horizontally.

All done with this bit of CSS in the styles.css file since we are changing the default layout.

.sidebar {
  grid-area: Sidebar;
  display: flex;
  flex-wrap: wrap;
  max-height: var(--sidebar-height);

  & .page-title {
      margin: 0px;
  }

  & .page-description {
      margin: 0px;
  }

  & .navigation {
    & .nav {
      display: flex;
      list-style: none;
      padding: 0px;
      margin: 0px;
    }
  }
}
@media screen and (min-width: 961px) {
    .sidebar {
        position: relative;
    }
}

This has actually become quite a lot to keep in the styles.css file.
Lets extract it into components/sidebar.css and import it.

All should look good now. Except when the content doesnt wrap!
Here is a screenshot of what I mean:

Ghost theme - Part 4: Finishing the Sidebar

Everything is in a row. The fix is quite easy with flexbox. Lets just set the flex-direction to column. That should fix it. Right?

Almost. The flex-wrap: wrap from earlier now messes things up. So lets just get rid of it on the sidebar. It worked great when the direction was row but now it is wrapping at the vertical ends, which is not what we want.

Now the sidebar looks pretty nice and our layout is almost done!

The features

Lets go on to the features:

  1. when scrolling the Title disappears
  2. when scrolling the Description disappears
  3. Only the Navigation is shown and the sidebar should shrink to its size but stay at the top

With position: sticky; the last one is pretty easy to do these days.
But to hide the other two we would need to restructure the HTML of our Sidebar since the position is relative to its parent. Which means it would still go out of the screen together with it.

So the last resort here is JavaScript together with position: fixed;. In general we should not use JavaScript for styling, but for this weird case lets make an exception and add a new class to the sidebar when it scrolls out of view.
Using that class we can then use the correct styles to achieve our goal and maybe add some nice CSS Animation.

Lets code

To use JavaScript create the file assets/js/helpers/styling.js.
The gotede build tools will take care of doing all the hard work of getting it onto the page, such as using babel and concatenating the JavaScript files you create.
Just take note that imports wont work. Since this is a Theme for purely Server-side rendered pages, that is totally fine. The JavaScript should be kept to a minimum here.

It should contain the following code, which will attach a new class to the Sidebar when we scroll down and then remove this class again once we scroll to the top:

function initScrollingListener() {
  const sidebar = document.getElementsByClassName("sidebar")[0];

  function addScrollClass() {
    if (window.pageYOffset >= 0) {
      sidebar.classList.add("scrolled");
      window.removeEventListener("scroll", addScrollClass);
      window.addEventListener("scroll", removeScrollClass);
    }
  }

  function removeScrollClass() {
    if (window.pageYOffset == 0) {
      sidebar.classList.remove("scrolled");
      window.removeEventListener("scroll", removeScrollClass);
      window.addEventListener("scroll", addScrollClass);
    }
  }

  if (window.pageYOffset == 0) {
    window.addEventListener("scroll", addScrollClass);
  } else {
    addScrollClass();
  }
}

initScrollingListener();

You should have some basic understanding of programming to really understand what is happening here but here is a small breakdown:

1.  If pageYOffset is 0 we are at the top, so we add a Listener that will call our addScrollClass function once we scroll. Otherwise we are not at the top and can call that function directly.
2. addScrollClass adds the class to the Sidebar element when we are not at the top of the page and the removes the Listener for calling itself on scrolling. Then it adds the Listener that calls removeScrollClass when we scroll.
3. removeScrollClass does exactly the opposite of addScrollClass.

Here is a list of all the DOM functionalities that are used in this piece of code: window, document, getElementsByClassName, window.pageYOffset, Element.classList, addEventListener, removeEventListener

Maybe you notice that we will call one of these functions every time that we scroll. In this case it is a very small amount of code, but it still has to run on the CPU, which is why we should generally avoid these kind of hacks.

Using the new class

So lets go and implement the things that should happen when we scroll in CSS.

.sidebar {
    /* ... */
    position: fixed;
    /* ... */
    &.scrolled{
        height: calc(var(--sidebar-height) / 1.5);
        width: var(--sidebar-width);

        & .page-title {
           display: none; 
        }

        & .page-description {
           display: none; 
        }
      }

This is all we need for now.
It should be inside the .sidebar block and hides both the description and the title when the scrolled class is added.

While it is not an optimal solution, since we use JavaScript for styling, it works in this case and does not put much load on the CPU since we only add two Listeners to our Window.

An Animation

To add some spiciness to our Sidebar suddenly reducing in size, we can add a small Animation when this happens.
Lets just make a dummy one for now where the Background transitions through colors. We can fine-tune this later when we got to the real colors of the theme.

  &.scrolled {
    /*...*/
    animation: background-transition 3s;
    background-color: yellow;
    z-index: 1;
  }
  /*...*/
  
  @keyframes background-transition {
    0% {
        background-color: blue;
    }
    100% {
        background-color: yellow;
    }
  }

One more thing is left to do.
While we have a nice Sidebar for a mobile layout these rules will break the Desktop design. Since we would have to overwrite all these rules in a MediaQuery lets make it easy on us and instead wrap these inside one themselves to keep the default on the other layouts.
To do this put all the CSS we just created for the scrolled class inside @media screen and (max-width: 960px) and dont forget to wrap them inside the .sidebar class as well.

The final sidebar.css should look like this:

.sidebar {
  grid-area: Sidebar;
  display: flex;
  flex-direction: column;
  max-height: var(--sidebar-height);

  position: fixed;
  top: 0;

  & .page-title {
      margin: 0px;
  }

  & .page-description {
      margin: 0px;
  }

  & .navigation {
    & .nav {
      display: flex;
      list-style: none;
      padding: 0px;
      margin: 0px;
    }
  }
}

@media screen and (max-width: 960px) {
    .sidebar {
        &.scrolled {
            height: calc(var(--sidebar-height) / 1.5);
            width: var(--sidebar-width);
            animation: background-transition 3s;
            background-color: yellow;
            z-index: 1;

        & .page-title {
            display: none; 
        }

        & .page-description {
            display: none; 
        }
        }
    }
}

@media screen and (min-width: 961px) {
    .sidebar {
        position: relative;
    }
}

@keyframes background-transition {
    0% {
        background-color: blue;
    }
    100% {
        background-color: yellow;
    }
}

The end

Here is a GIF of the new behaviour:

Ghost theme - Part 4: Finishing the Sidebar

Caught that Image that overflows our page? A Bug, how nice. I will fix it by next time. If you somehow followed along and want to do this as well, check out the class of such and element and try to find a setting that restricts its width ;)

Otherwise it looks like we are done here from a Basic Layouting point of view.
Of course there is still much needed on the visual front, which is what we will start in Part 6, where it is going to be all about Typography and choosing a Font.

Cover: https://unsplash.com/photos/SXihyA4oEJs

Read more
Max

CSS Modules: the correct code split

There is a lot of talk going on in the JavaScript Frontend Community about using CSSinJS. One example for this are styled-components.
A use of them is explained over at https://www.toptal.com/javascript/styled-components-library .
In this Article I want to name an alternative and talk about some benefits.

What are CSS modules?

According to the css-modules github repo:

A CSS Module is a CSS file in which all class names and animation names are scoped locally by default.

For use in React or Vue f.e. this would mean:
All of the styles inside of a CSS Module will not affect anything else than the Component on which they are imported in.

Using CSS modules

Lets try this out with a a bit of React.
First we write a Box Component like this:

import React from 'react';
import styles from './Box.css';

const Box = () => <div />;

export default Box;

And apply some styles to it:

import React from 'react';
import styles from './Box.css';

const Box = () => <div className={styles.box} />;

export default Box;

Notice how we just import some CSS file into our JavaScript. This is where the magic happens.
In this case the CSS modularization happens through the webpack css-loader.

This is the Box.css file that gets imported.

.box {
    width: 400px;
    height: 300px;
    border-bottom: solid brown 4px;
    border-right: solid brown 4px;
    border-left: solid brown 4px;
}

we can check out the browser to see what the result looks like.

CSS Modules: the correct code split

Notice the class name? This is how CSS Modules achieve the local scoping. The imported class will be added on the correct Components and in the process their names will be changed and a unique hash added.
This will prevent any collisions with rules of other components.

No collision

Lets try this out in the browser.
Here are 2 components that use the same class name in their CSS:

Banana Component

import React from 'react';
import styles from './Banana.css';

const Banana = () => (
  <div className={styles.container}>
    <p className={styles.text}>Banana</p>
  </div>
);

export default Banana;
.container {
    display: flex;
    justify-content: center;
    align-items: center;
    border: solid 1px yellow;
}

.text {
    color: yellow;
}

Apple Component

import React from 'react';
import styles from './Apple.css';

const Apple = () => (
  <div className={styles.container}>
    <p className={styles.text}>Apple</p>
  </div>
);

export default Apple;
.container {
    display: flex;
    justify-content: center;
    align-items: center;
    border: solid 1px green;
}

.text {
    color: green;
}

Both of the components use the same classes inside of them. If we would write normal CSS this should lead to collisions, meaning that one set of rules would overwrite the other.
But checking the website again we can see that everything is normal.
Take note of the hashed class names again.

CSS Modules: the correct code split

All collisions are avoided by making the class names unique. Similar to techniques such as BEM, just in an automated way.

Conclusion

This was a very brief introduction to CSS Modules but should give a good understanding of what they do and how they work.
Some of the features are similar to techniques such as styled-components, but by being just CSS files we can benefit from some advantages.
Lets dive into the Pros and Cons to wrap it up:

Pros

  • Designers do not need to learn new ways of writing CSS in JS. Instead they can easily make changes to the correct CSS files. This way of styling, combined with mental models such a atomic design, can increase communication between Developers and Designers and development speed.
  • Separation of Concerns: We hear this all the time in Web Development and it was regarded as best practice for a long time. Given JSXs popularity one might argue that this is not true anymore, but we should still aim for it.
  • Tools and Preprocessors such as PostCss can be easily integrated to allow CSS Imports, Custom Properties etc.

Cons

  • The build task might be complicated to set up at first
  • Global styles have to be wrapped in a special :global block. Where would such a block belong?
  • The power of JavaScript is not available inside the CSS files

Cover Image is from https://unsplash.com/photos/8EzNkvLQosk

Read more
Max

CSS Modules: the correct code split

There is a lot of talk going on in the JavaScript Frontend Community about using CSSinJS. One example for this are styled-components.
A use of them is explained over at https://www.toptal.com/javascript/styled-components-library .
In this Article I want to name an alternative and talk about some benefits.

What are CSS modules?

According to the css-modules github repo:

A CSS Module is a CSS file in which all class names and animation names are scoped locally by default.

For use in React or Vue f.e. this would mean:
All of the styles inside of a CSS Module will not affect anything else than the Component on which they are imported in.

Using CSS modules

Lets try this out with a a bit of React.
First we write a Box Component like this:

import React from 'react';
import styles from './Box.css';

const Box = () => <div />;

export default Box;

And apply some styles to it:

import React from 'react';
import styles from './Box.css';

const Box = () => <div className={styles.box} />;

export default Box;

Notice how we just import some CSS file into our JavaScript. This is where the magic happens.
In this case the CSS modularization happens through the webpack css-loader.

This is the Box.css file that gets imported.

.box {
    width: 400px;
    height: 300px;
    border-bottom: solid brown 4px;
    border-right: solid brown 4px;
    border-left: solid brown 4px;
}

we can check out the browser to see what the result looks like.

CSS Modules: the correct code split

Notice the class name? This is how CSS Modules achieve the local scoping. The imported class will be added on the correct Components and in the process their names will be changed and a unique hash added.
This will prevent any collisions with rules of other components.

No collision

Lets try this out in the browser.
Here are 2 components that use the same class name in their CSS:

Banana Component

import React from 'react';
import styles from './Banana.css';

const Banana = () => (
  <div className={styles.container}>
    <p className={styles.text}>Banana</p>
  </div>
);

export default Banana;
.container {
    display: flex;
    justify-content: center;
    align-items: center;
    border: solid 1px yellow;
}

.text {
    color: yellow;
}

Apple Component

import React from 'react';
import styles from './Apple.css';

const Apple = () => (
  <div className={styles.container}>
    <p className={styles.text}>Apple</p>
  </div>
);

export default Apple;
.container {
    display: flex;
    justify-content: center;
    align-items: center;
    border: solid 1px green;
}

.text {
    color: green;
}

Both of the components use the same classes inside of them. If we would write normal CSS this should lead to collisions, meaning that one set of rules would overwrite the other.
But checking the website again we can see that everything is normal.
Take note of the hashed class names again.

CSS Modules: the correct code split

All collisions are avoided by making the class names unique. Similar to techniques such as BEM, just in an automated way.

Conclusion

This was a very brief introduction to CSS Modules but should give a good understanding of what they do and how they work.
Some of the features are similar to techniques such as styled-components, but by being just CSS files we can benefit from some advantages.
Lets dive into the Pros and Cons to wrap it up:

Pros

  • Designers do not need to learn new ways of writing CSS in JS. Instead they can easily make changes to the correct CSS files. This way of styling, combined with mental models such a atomic design, can increase communication between Developers and Designers and development speed.
  • Separation of Concerns: We hear this all the time in Web Development and it was regarded as best practice for a long time. Given JSXs popularity one might argue that this is not true anymore, but we should still aim for it.
  • Tools and Preprocessors such as PostCss can be easily integrated to allow CSS Imports, Custom Properties etc.

Cons

  • The build task might be complicated to set up at first
  • Global styles have to be wrapped in a special :global block. Where would such a block belong?
  • The power of JavaScript is not available inside the CSS files

Cover Image is from https://unsplash.com/photos/8EzNkvLQosk

Read more
Max

Please Note that this theme is not in use anymore. See this post for more info.

Ghost theme - Part 3: Mobile Layout

Here is the third part of this series where we will dive into creating the proper layout for the posts on the front page and figure out a way to display our layout on mobilephones.

Just in case lets bring up the inital sketch again

Ghost theme - Part 3: Mobile Layout

But before we can jump in and take care of the posts we have a small problem.
Using the mobile page preview of the browser we can easily spot it.

Ghost theme - Part 3: Mobile Layout

The content inside the sidebar does not fit inside the container anymore. Unfortunately max-width does not help here, as the words are actually too long and the browser cant wrap the text to the next line.

So its time to come up with a new sketch:

Ghost theme - Part 3: Mobile Layout

You have probably encountered this technique before. Here is a break down:

  1. We will make the sidebar go to the top on mobile devices.
  2. The Title and subtitle will scroll out of the screen
  3. The navigation elements will stay on top

Implementation

Responsiveness

The first thing I am going to do is to convert the whole layout to this idea.
This 'old' design will be wrapped via media-queries that activate when a certain screen-size is reached.
This way of doing it is called mobile first.
Since this theme is in an early stage of development it is still easily possible to switch to this approach.

This is the updated CSS:

variables.css

:root {
  /* Container sizes */
  --main-width: 100vw;
  --main-height: 80vh;

  --sidebar-width: 100vw;
  --sidebar-height: 20vh;
}

@media screen and (min-width: 961px) {
  :root {
    /* Container sizes */
    --main-width: 80vw;
    --main-height: 100%;

    --sidebar-width: 20vw;
    --sidebar-height: 100vh;
  }
}

styles.css

@import "./helpers/variables.css";

/* Mobile */
body {
  margin: 0px;
}

.grid-container {
  display: grid;
  height: 100%;
  grid-template-columns: 1fr;
  grid-template-rows: var(--sidebar-height) var(--main-height);
  grid-gap: 0px;
  grid-template-areas: "Sidebar" "Content";
}

.main {
  grid-area: Content;
  max-width: var(--main-width);
}

.sidebar {
  grid-area: Sidebar;
}


/* Desktop */
@media screen and (min-width: 961px) {
  .grid-container {
    display: grid;
    height: 100%;
    grid-template-columns: var(--sidebar-width) var(--main-width);
    grid-template-rows: 1fr;
    grid-gap: 0px;
    grid-template-areas: "Sidebar Content";
  }
  .main {
    grid-area: Content;
    max-width: var(--main-width);
  }
}

Et voila, we have a responsive page.

Mobile:
Ghost theme - Part 3: Mobile Layout

Desktop:
Ghost theme - Part 3: Mobile Layout

The Sidebar

As you can see the content of the Sidebar seems to escape into regions it shouldnt.

To fix this lets first change the default.hbs and remove the <div class="sidebar> and attach that class directly to the <header>.

Back in the styles.css we can now add some rules.
I am going to go for a flexbox solution.

 .sidebar {
  grid-area: Sidebar;
  display: flex;
  flex-wrap: wrap;
  max-height: var(--sidebar-height);
}
  1. Tell the component that its display type is flexbox.
  2. Make sure that the content will wrap when it reaches the bounds of this container
  3. Set a maximum height on the sidebar. To make sure it doesnt grow beyond what we would like to have in our design. This is espacially useful when the sidebar is actually at the side.

Lets leave the additional requirements of hiding the title and subtitle for the next post.

The posts

Lastly its time to implement the post layout.
On the mobile front everything looks good already. One post per row.

For the desktop we need to find a way to display 2 posts next to each other though.

First I will create a new file components/index.css that will hold all the styles for the Index page. All the styling until now was for the default.hbs.
Also do not forget to import this file in the styles.css via @import "./components/index.css";.

Here is the CSS that will accomplish the task:

.index__posts {
  display: flex;
  flex-wrap: wrap;

  & .post {
    width: var(--post-width);
  }
}

You can see that the .post class is nested inside the .index__posts class. This again is taken care of during the build step via postcss-preset-env.

The --post-width variable is inside the variables.css file and looks like this:

/* .... */
:root {
  --post-width: var(--main-width);
}

@media screen and (min-width: 961px) {
  :root {
    /* .... */
    --post-width: calc(var(--main-width) / 2);
  }

This works in the following way:

  1. When the Screen is 961px wide or bigger every post will have the width of half the --main-width.
  2. Posts are inside a flexbox container
  3. Since the flexbox container does not wrap by default and instead rezises our posts to fit inside of it, we tell it to wrap the content.
  4. 2 posts will be shown per 'row' :)

The one thing I have not mentioned until now is the CSS calc function, which allows us to dynamically calculate some values.

Wrap up

Phew, this post had quite a lot of content and advanced techniques. Nevertheless the theme is now in a good state with relatively little CSS and should be pretty maintainable and extendable.

The neat little trick with the custom-properties is something that I have added to postcss-custom-properties while writing this, so it might not yet be released. I will update this post once it is.

Here is a final image of the Desktop page, looks pretty good already :

Ghost theme - Part 3: Mobile Layout

Next post

Whats going to happen in part 4?
Lets fix the Sidebar for mobile layouts. Afterwards in part 5 the Basics should be done to start with Typography and Colours :)

Cover: https://unsplash.com/photos/-1_RZL8BGBM

Read more
Max

Please Note that this theme is not in use anymore. See this post for more info.

Here is the third part of this series where we will dive into creating the proper layout for the posts on the front page and figure out a way to display our layout on mobilephones.

Just in case lets bring up the inital sketch again

Sketch_theme-2

But before we can jump in and take care of the posts we have a small problem.
Using the mobile page preview of the browser we can easily spot it.

mobile_view_broken

The content inside the sidebar does not fit inside the container anymore. Unfortunately max-width does not help here, as the words are actually too long and the browser cant wrap the text to the next line.

So its time to come up with a new sketch:

mobile_sketch-1

You have probably encountered this technique before. Here is a break down:

  1. We will make the sidebar go to the top on mobile devices.
  2. The Title and subtitle will scroll out of the screen
  3. The navigation elements will stay on top

Implementation

Responsiveness

The first thing I am going to do is to convert the whole layout to this idea.
This 'old' design will be wrapped via media-queries that activate when a certain screen-size is reached.
This way of doing it is called mobile first.
Since this theme is in an early stage of development it is still easily possible to switch to this approach.

This is the updated CSS:

variables.css

:root {
  /* Container sizes */
  --main-width: 100vw;
  --main-height: 80vh;

  --sidebar-width: 100vw;
  --sidebar-height: 20vh;
}

@media screen and (min-width: 961px) {
  :root {
    /* Container sizes */
    --main-width: 80vw;
    --main-height: 100%;

    --sidebar-width: 20vw;
    --sidebar-height: 100vh;
  }
}

styles.css

@import "./helpers/variables.css";

/* Mobile */
body {
  margin: 0px;
}

.grid-container {
  display: grid;
  height: 100%;
  grid-template-columns: 1fr;
  grid-template-rows: var(--sidebar-height) var(--main-height);
  grid-gap: 0px;
  grid-template-areas: "Sidebar" "Content";
}

.main {
  grid-area: Content;
  max-width: var(--main-width);
}

.sidebar {
  grid-area: Sidebar;
}


/* Desktop */
@media screen and (min-width: 961px) {
  .grid-container {
    display: grid;
    height: 100%;
    grid-template-columns: var(--sidebar-width) var(--main-width);
    grid-template-rows: 1fr;
    grid-gap: 0px;
    grid-template-areas: "Sidebar Content";
  }
  .main {
    grid-area: Content;
    max-width: var(--main-width);
  }
}

Et voila, we  have a responsive page.

mobile_resp
desktop_resp

The Sidebar

As you can see the content of the Sidebar seems to escape into regions it shouldnt.

To fix this lets first change the default.hbs and remove the <div class="sidebar> and attach that class directly to the <header>.

Back in the styles.css we can now add some rules.
I am going to go for a flexbox solution.

 .sidebar {
  grid-area: Sidebar;
  display: flex;
  flex-wrap: wrap;
  max-height: var(--sidebar-height);
}
  1. Tell the component that its display type is flexbox.
  2. Make sure that the content will wrap when it reaches the bounds of this container
  3. Set a maximum height on the sidebar. To make sure it doesnt grow beyond what we would like to have in our design. This is espacially useful when the sidebar is actually at the side.

Lets leave the additional requirements of hiding the title and subtitle for the next post.

The posts

Lastly its time to implement the post layout.
On the mobile front everything looks good already. One post per row.

For the desktop we need to find a way to display 2 posts next to each other though.

First I will create a new file  components/index.css that will hold all the styles for the Index page. All the styling until now was for the default.hbs.
Also do not forget to import this file in the styles.css via @import "./components/index.css";.

Here is the CSS that will accomplish the task:

.index__posts {
  display: flex;
  flex-wrap: wrap;

  & .post {
    width: var(--post-width);
  }
}

You can see that the .post class is nested inside the .index__posts class. This again is taken care of during the build step via postcss-preset-env.

The --post-width variable is inside the variables.css file and looks like this:

/* .... */
:root {
  --post-width: var(--main-width);
}

@media screen and (min-width: 961px) {
  :root {
    /* .... */
    --post-width: calc(var(--main-width) / 2);
  }

This works in the following way:

  1. When the Screen is 961px wide or bigger every post will have the width of half the --main-width.
  2. Posts are inside a flexbox container
  3. Since the flexbox container does not wrap by default and instead rezises our posts to fit inside of it, we tell it to wrap the content.
  4. 2 posts will be shown per 'row' :)

The one thing I have not mentioned until now is the CSS calc function, which allows us to dynamically calculate some values.

Wrap up

Phew, this post had quite a lot of content and advanced techniques. Nevertheless the theme is now in a good state with relatively little CSS and should be pretty maintainable and extendable.

The neat little trick with the custom-properties is something that I have added to postcss-custom-properties while writing this, so it might not yet be released. I will update this post once it is.

Here is a final image of the Desktop page, looks pretty good already :

desktop_done

Next post

Whats going to happen in part 4?
Lets fix the Sidebar for mobile layouts. Afterwards in part 5 the Basics should be done to start with Typography and Colours :)

Read more
Max

Please Note that this theme is not in use anymore. See this post for more info.

Ghost theme - Part 2: a Grid

In this post I want to start with the styling.
the first thing here is to consult the sketches again.

Ghost theme - Part 2: a Grid

Since we split out the sidebar into the default layout, we should create a Grid for this first.
The technology I am going to use here is CSS-Grid.

The only to be aware of is the browser support. Check caniuse.com to see if it supports the browsers you want.
Since this is my personal blog and the audience is probably using modern browsers (this is an assumption, as I have no tracking yet) I am totally fine with ignoring older and more exotic browsers for now.

Grid

With tools like https://www.layoutit.com/grid we can quickly generate a basic layout.

The generated code for the grid I want on the blog according to the sketches looks like this

.grid-container {
  display: grid;
  height: 100%;
  grid-template-columns: 20vw 80vw;
  grid-template-rows: 1fr;
  grid-gap: 0px;
  grid-template-areas: "Sidebar Content";
}

.main{ grid-area: Content; }

.sidebar { grid-area: Sidebar; }

This will have to go into a css file at assets/css/styles.css in the theme folder.

Make sure to restart the `npm run start` task, so that gulp can pick up on the newly created `.css` file. Unfortunately this is not detected automatically.

In the default.hbs this stylesheet now needs to be imported and the correct classes need to be added to the HTML in the like following:


<head>
...
<link rel="stylesheet" type="text/css" href="{{asset "built/styles.css"}}" />

</head>

<body class="{{body_class}} grid-container">
    <div class="sidebar">
        <header>
            <h1 class="page-title">{{@blog.title}}</h1>
            <h2 class="page-description">{{@blog.description}}</h2>
            <nav class="navigation">
                {{navigation}}
            </nav>
        </header>
    </div>
    <div class="main">
        {{{body}}}
    </div>
    {{ghost_foot}}
</body>

The <body> is acting as the Grid container, and the sidebar and main where already equipped with the correct classes.

With this simple addition the page already looks like this:

Ghost theme - Part 2: a Grid

Variables

Now we have a good base to start introducing variables in CSS.
We can use these due to the postcss-custom-properties that are included in the default gotede gulp task.

What this will allow us is to define certain variables that should be applied throughout our app and then reuse them whenever needed.

By doing this we introduce 2 benefits.

  1. We can easily make a change in 1 place that will be applied everywhere that value was used
  2. There is 1 place to check in order to find out what specific values are

The place to define those is f.e. assets/css/helpers/variables.css, so lets create some, that we can use for our grid.

:root {
  /* Container sizes */
  --main-width: 80vw;
  --sidebar-width: 20vw;

  /* Gutter sizes */
  --gutter-horizontal--small: 2vw;
}

Notice that they are wrapped in the :root{} block.

Once this is done the gulp task will automatically make those 'available' in all our CSS files (This is actually done in the build step, but thats semantics I guess).

Lets import them and use them for the grid like this:


@import "./helpers/variables.css";


.grid-container {
  display: grid;
  height: 100%;
  grid-template-columns: var(--sidebar-width) var(--main-width);
  grid-template-rows: 1fr;
  grid-gap: 0px;
  grid-template-areas: "Sidebar Content";
}

.main {
  grid-area: Content;
}

.sidebar {
  grid-area: Sidebar;
}

You can see that the variables are used with var(VARIABLE_NAME). While this might not seem super important or useful right now, be sure that this will save a lot of headaches down the line.

A break in the layout

There is a little weirdness going on when we head over to the Writing posts with Ghost for example.
You can see that something is breaking on mobile devices. The content seems to escape the website.
Ghost theme - Part 2: a Grid

To fix this lets set a max-width on the main container. This does exactly what the name implies, telling it that its maximum width should be of some value.
Which one is the correct value? Given our Layout it should be the --main-width variable. Already comming in handy :).

Lets add it to the .main block

.main {
  grid-area: Content;
  max-width: var(--main-width);
}

Check out the post again. All good?
Nope, looks like the picture is still escaping to the right.

If you inspect the HTML you can find the picture class .kg-image. For this class we will add a rule of max-width: 100%; for now, until we encounter the styling of the pictures again, later on.

Now it looks good again:
Ghost theme - Part 2: a Grid

By the way, you can ignore the purple lines.
These are added by the Firefox developer tools. You can read about these here if you would like to use them too.

A small task for you

Check out the Publishing options article. On this page you should encounter another problem of content escaping.
I will leave this as a small task for you to fix right now. Should you need help or a hint feel free to drop me a short email or contact me on my new twitter.

What next?

The theme already looks quite a bit like the sketch. One thing we need to ensure though, is that there are always only 2 posts next to each other (and maybe alter this idea for mobile devices?).

So the next post will be focussing on those 2 topics including media-queries and flexbox.

Cover: https://unsplash.com/photos/Vwf8q3RzBRE

Read more
Max

Please Note that this theme is not in use anymore. See this post for more info.

Ghost theme - Part 2: a Grid

In this post I want to start with the styling.
the first thing here is to consult the sketches again.

Ghost theme - Part 2: a Grid

Since we split out the sidebar into the default layout, we should create a Grid for this first.
The technology I am going to use here is CSS-Grid.

The only to be aware of is the browser support. Check caniuse.com to see if it supports the browsers you want.
Since this is my personal blog and the audience is probably using modern browsers (this is an assumption, as I have no tracking yet) I am totally fine with ignoring older and more exotic browsers for now.

Grid

With tools like https://www.layoutit.com/grid we can quickly generate a basic layout.

The generated code for the grid I want on the blog according to the sketches looks like this

.grid-container {
  display: grid;
  height: 100%;
  grid-template-columns: 20vw 80vw;
  grid-template-rows: 1fr;
  grid-gap: 0px;
  grid-template-areas: "Sidebar Content";
}

.main{ grid-area: Content; }

.sidebar { grid-area: Sidebar; }

This will have to go into a css file at assets/css/styles.css in the theme folder.

Make sure to restart the `npm run start` task, so that gulp can pick up on the newly created `.css` file. Unfortunately this is not detected automatically.

In the default.hbs this stylesheet now needs to be imported and the correct classes need to be added to the HTML in the  like following:


<head>
...
<link rel="stylesheet" type="text/css" href="{{asset "built/styles.css"}}" />

</head>

<body class="{{body_class}} grid-container">
    <div class="sidebar">
        <header>
            <h1 class="page-title">{{@blog.title}}</h1>
            <h2 class="page-description">{{@blog.description}}</h2>
            <nav class="navigation">
                {{navigation}}
            </nav>
        </header>
    </div>
    <div class="main">
        {{{body}}}
    </div>
    {{ghost_foot}}
</body>

The <body> is acting as the Grid container, and the sidebar and main where already equipped with the correct classes.

With this simple addition the page already looks like this:

Ghost theme - Part 2: a Grid

Variables

Now we have a good base to start introducing variables in CSS.
We can use these due to the postcss-custom-properties that are included in the default gotede gulp task.

What this will allow us is to define certain variables that should be applied throughout our app and then reuse them whenever needed.

By doing this we introduce 2 benefits.

  1. We can easily make a change in 1 place that will be applied everywhere that value was used
  2. There is 1 place to check in order to find out what specific values are

The place to define those is f.e. assets/css/helpers/variables.css, so lets create some, that we can use for our grid.

:root {
  /* Container sizes */
  --main-width: 80vw;
  --sidebar-width: 20vw;

  /* Gutter sizes */
  --gutter-horizontal--small: 2vw;
}

Notice that they are wrapped in the :root{} block.

Once this is done the gulp task will automatically make those 'available' in all our CSS files (This is actually done in the build step, but thats semantics I guess).

Lets import them and use them for the grid like this:


@import "./helpers/variables.css";


.grid-container {
  display: grid;
  height: 100%;
  grid-template-columns: var(--sidebar-width) var(--main-width);
  grid-template-rows: 1fr;
  grid-gap: 0px;
  grid-template-areas: "Sidebar Content";
}

.main {
  grid-area: Content;
}

.sidebar {
  grid-area: Sidebar;
}

You can see that the variables are used with var(VARIABLE_NAME). While this might not seem super important or useful right now, be sure that this will save a lot of headaches down the line.

A break in the layout

Ghost theme - Part 2: a Grid

To fix this lets set a max-width on the main container. This does exactly what the name implies, telling it that its maximum width should be of some value.
Which one is the correct value? Given our Layout it should be the --main-width variable. Already comming in handy :).

Lets add it to the .main block

.main {
  grid-area: Content;
  max-width: var(--main-width);
}

Check out the post again. All good?
Nope, looks like the picture is still escaping to the right.

If you inspect the HTML you can find the picture class .kg-image. For this class we will add a rule of max-width: 100%; for now, until we encounter the styling of the pictures again, later on.

Ghost theme - Part 2: a Grid

By the way, you can ignore the purple lines.
These are added by the Firefox developer tools. You can read about these here if you would like to use them too.

A small task for you

Check out the Publishing options article. On this page you should encounter another problem of content escaping.
I will leave this as a small task for you to fix right now. Should you need help or a hint feel free to drop me a short email or contact me on my new twitter.

What next?

The theme already looks quite a bit like the sketch. One thing we need to ensure though, is that there are always only 2 posts next to each other (and maybe alter this idea for mobile devices?).

So the next post will be focussing on those 2 topics including media-queries and flexbox.

Read more
Max

Please Note that this theme is not in use anymore. See this post for more info.

Creating a new ghost theme - Part 1

I want to make my blog more unique and fitting to my style both in code and in looks.
Writing my own theme seems like the right thing to do, given that I am currently looking for a job and having both more free time and wanting to look good to possible employers.

So I want to accompany this with a few blog posts on how I am going about this.

All of this will be done incrementally and I will set the theme live, so you can give me some feedback if you can/want. The best way to do this is on Twitter or at max [at] ehlers . berlin.

The development environment

The first thing that I need is a development environment. I wrote this article about a small script I wrote to help with this.

The homepage/index

When you come to this blog via its basic URL the first thing you are going to be greeted with is the index.

So this is also the first thing that I want to work on.

Here is a small sketch I made to get started:

Creating a new ghost theme - Part 1

Now I implemented all the things needed according to the Documentation in the index.hbs of my theme.

It now looks like this

<header>
  <h1 class="page-title">{{@blog.title}}</h1>
  <h2 class="page-description">{{@blog.description}}</h2>
  <nav class="navigation">
    {{navigation}}
  </nav>
</header>

<main role="main">
  {{#foreach posts}}
	<article class="{{post_class}}">
 		<header class="post-header">
   		<h2><a href="{{url}}">{{title}}</a></h2>
    </header>
    <section class="post-excerpt">
 			<p>{{excerpt words="26"}} <a class="read-more" href="{{url}}">...</a></p>
    </section>
    <footer class="post-meta">
      {{authors}}
      {{tags prefix=" on "}}
      <time class="post-date" datetime="{{date format='YYYY-MM-DD'}}">{{date format="DD MMMM YYYY"}}</time>
    </footer>
  </article>
  {{/foreach}}
</main>

{{pagination}}

When you made the changes, make sure to restart Ghost or reenable your theme.
Since my instance in running inside a container I can do a quick docker restart THEME_NAME and reload the page.

This code is only adopted very slightly from the example given in the documentation. All that is removed is the author image for each post, and a navigation is added in the <header>.

I am not worrying about the design yet, this post is only about the structure. Having the sketch just helps me in figuring out what is needed on the page.

Posts

Next up are the posts.
Again a quick sketch:
Creating a new ghost theme - Part 1

We can again consult the Documentation and can copy the example code, so that the post.hbs looks like this:

{{#post}}
              
<article class="{{post_class}}">
  <header class="post-header">
    <h1 class="post-title">{{title}}</h1>
    <section class="post-meta">
      <time class="post-date" datetime="{{date format='YYYY-MM-DD'}}">
        {{date format="DD MMMM YYYY"}}
      </time> 
      {{tags prefix=" on "}}
    </section>  
  </header>
  <section class="post-content">
    {{content}}
  </section>     
</article>

{{/post}} 

Now we will have to somehow add the navigation sidebar here and since it is not supposed to change on any pages on the blog we can use a default.hbs file in our theme.
This file we be applied to all pages that Ghost will display.

First we remove the navigation from our index.hbs file and then create the default.hbs with the following content.
It will include a few helpers from Ghost so that different things can be injected here from the Admin panel.

<!DOCTYPE html>
<html lang="{{lang}}">

<head>
    {{! Document settings and metadata }}
    <title>{{meta_title}}</title>
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta charset="utf-8" /> 
    {{!-- This tag outputs SEO meta+structured data and other important settings --}}
    {{ghost_head}}
</head>

<body class="{{body_class}}">
    <div class="sidebar">
        <header>
            <h1 class="page-title">{{@blog.title}}</h1>
            <h2 class="page-description">{{@blog.description}}</h2>
            <nav class="navigation">
                {{navigation}}
            </nav>
        </header>
    </div>
    <div class="main">
        {{{body}}}
    </div>
    {{ghost_foot}}
</body>

</html>

Once we have this file we need to tell both the index.hbs and post.hbs file that they should use this default file by adding

{{!< default}}

to the top of both files.

We can now restart our Ghost instance and should see the navigation on both pages.

Here is a screenshot of the posts page:

Creating a new ghost theme - Part 1

Wrap up

This should be enough for a start.
The theme now has the basic structure to start with a bit of styling.

Ill cover that in the next article :)

Read more
Max

Please Note that this theme is not in use anymore. See this post for more info.

Creating a new ghost theme - Part 1

I want to make my blog more unique and fitting to my style both in code and in looks.
Writing my own theme seems like the right thing to do, given that I am currently looking for a job and having both more free time and wanting to look good to possible employers.

So I want to accompany this with a few blog posts on how I am going about this.

All of this will be done incrementally and I will set the theme live, so you can give me some feedback if you can/want. The best way to do this is on Twitter or at max [at] ehlers . berlin.

The development environment

The first thing that I need is a development environment. I wrote this article about a small script I wrote to help with this.

The homepage/index

When you come to this blog via its basic URL the first thing you are going to be greeted with is the index.

So this is also the first thing that I want to work on.

Here is a small sketch I made to get started:

Creating a new ghost theme - Part 1

Now I implemented all the things needed according to the Documentation in the index.hbs of my theme.

It now looks like this

<header>
  <h1 class="page-title">{{@blog.title}}</h1>
  <h2 class="page-description">{{@blog.description}}</h2>
  <nav class="navigation">
    {{navigation}}
  </nav>
</header>

<main role="main">
  {{#foreach posts}}
	<article class="{{post_class}}">
 		<header class="post-header">
   		<h2><a href="{{url}}">{{title}}</a></h2>
    </header>
    <section class="post-excerpt">
 			<p>{{excerpt words="26"}} <a class="read-more" href="{{url}}">...</a></p>
    </section>
    <footer class="post-meta">
      {{authors}}
      {{tags prefix=" on "}}
      <time class="post-date" datetime="{{date format='YYYY-MM-DD'}}">{{date format="DD MMMM YYYY"}}</time>
    </footer>
  </article>
  {{/foreach}}
</main>

{{pagination}}

When you made the changes, make sure to restart Ghost or reenable your theme.
Since my instance in running inside a container I can do a quick docker restart THEME_NAME and reload the page.

This code is only adopted very slightly from the example given in the documentation. All that is removed is the author image for each post, and a navigation is added in the <header>.

I am not worrying about the design yet, this post is only about the structure. Having the sketch just helps me in figuring out what is needed on the page.

Posts

Creating a new ghost theme - Part 1

We can again consult the Documentation and can copy the example code, so that the post.hbs looks like this:

{{#post}}
              
<article class="{{post_class}}">
  <header class="post-header">
    <h1 class="post-title">{{title}}</h1>
    <section class="post-meta">
      <time class="post-date" datetime="{{date format='YYYY-MM-DD'}}">
        {{date format="DD MMMM YYYY"}}
      </time> 
      {{tags prefix=" on "}}
    </section>  
  </header>
  <section class="post-content">
    {{content}}
  </section>     
</article>

{{/post}} 

Now we will have to somehow add the navigation sidebar here and since it is not supposed to change on any pages on the blog we can use a default.hbs file in our theme.
This file we be applied to all pages that Ghost will display.

First we remove the navigation from our index.hbs file and then create the default.hbs with the following content.
It will include a few helpers from Ghost so that different things can be injected here from the Admin panel.

<!DOCTYPE html>
<html lang="{{lang}}">

<head>
    {{! Document settings and metadata }}
    <title>{{meta_title}}</title>
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta charset="utf-8" /> 
    {{!-- This tag outputs SEO meta+structured data and other important settings --}}
    {{ghost_head}}
</head>

<body class="{{body_class}}">
    <div class="sidebar">
        <header>
            <h1 class="page-title">{{@blog.title}}</h1>
            <h2 class="page-description">{{@blog.description}}</h2>
            <nav class="navigation">
                {{navigation}}
            </nav>
        </header>
    </div>
    <div class="main">
        {{{body}}}
    </div>
    {{ghost_foot}}
</body>

</html>

Once we have this file we need to tell both the index.hbs and post.hbs file that they should use this default file by adding

{{!< default}}

to the top of both files.

We can now restart our Ghost instance and should see the navigation on both pages.

Here is a screenshot of the posts page:

Creating a new ghost theme - Part 1

Wrap up

This should be enough for a start.
The theme now has the basic structure to start with a bit of styling.

Ill cover that in the next article :)

Read more
Peter Mahnke

Ubuntu is a big Open Source project and there are a lot of websites in our community. The web team at Canonical literally doesn’t even know how many sites there are. We have heard there are over 200 ubuntu.com subdomains alone, but we know that there are many more that are owned by local groups and teams outside that single ubuntu.com domain.

Traditionally most of our work has been on www.ubuntu.com and www.canonical.com, but over the years, we have designed, often built and occasionally are responsible for the content of a series of key sites like: insights.ubuntu.com, design.ubuntu.com, developer.ubuntu.com, design.canonical.com. And we have often attempted to provide on-brand versions of wiki and WordPress templates.

As the number of sites grew, we got tired of re-creating grids, templates, CSS all the time.

Enter guidelines

To resolve these issues, we created Ubuntu web guidelines. Instead of sites of cobbled together CSS and a borrowed grid, guidelines gave us something far more formalised and systematic. A grid, typography, core styles and pattern, all with our beautiful Ubuntu brand guidelines. We were not only able to maintain a whole set of sites from a single hosted set of CSS files, but others could borrow and use it easily. We even transitioned the guidelines to be responsive without breaking our sites. You can read more in our series of posts Making ubuntu.com responsive.

Exit guidelines

Around two years ago, the web team started supporting the design and development of some of Canonical’s cloud apps, including Juju, MAAS, and Canonical OpenStack Autopilot installer. These apps have a different look and feel than ubuntu.com. And they often have special requirements, for example, MAAS is likely to be run in data centres without internet access for things like fonts, images, or CSS, that the guidelines did not natively support.

We looked at how to best adapt the guidelines to work with these web apps. We looked at how we were already making www.canonical.com work, essentially overriding the Ubuntu branded guidelines and decided to change the entire approach.

Enter Vanilla

For Vanilla, we wanted to start over, but not have to rewrite everything. So our quick list of project goals was:

  • Minimise the changes to our existing html
  • Create a core theme that distilled the guidelines to its basic Ubuntu-ness
  • Make everything more modular, easy to add or remove components
  • Make it easy for anyone to create themes for each new project that could borrow from other themes
  • Create themes for ubuntu and canonical websites
  • Remove our reliance on javascript
  • Make it work stand-alone
  • Make it easy to build, develop and update
  • Invite other people both inside and outside Canonical to start using the framework

The future

So now we are close to releasing the first version of Vanilla. Canonical.com and ubuntu.com will be moved over the coming months. Then we will look at moving other projects, like MAAS, jujucharms.com, Landscape to the framework.

Please keep reading these posts, you can see Ant’s first post, Introducing Vanilla. And take a look at the project on GitHub and let us know what you think.

Read more
Anthony Dillon

Why we needed a new framework

Some time ago the web team at Canonical developed a CSS framework the we called ‘Guidelines’. Guidelines helped us to maintain our online visual language across all our sites and comprised of a number of base and component Sass files which were combined and served as a monolithic CSS file on our asset server.

We began to use Guidelines as the baseline styles for a number of our sites; www.ubuntu.com, www.canonical.com, etc.

This worked well until we needed to update a component or base style. With each edit we had to check it wasn’t going to break any of the sites we knew used it and hope it didn’t break the sites we were not aware.

Another deciding factor for us was was the feedback that we started receiving as internal teams started adopting Guidelines. We received a resounding request to break the components into modular parts so they could customise which ones they could include. Another request we heard a lot was the ability to pull the Sass files locally for offline development but keep the styling up to date.

Therefore, we set out to develop a new and improved build and delivery system, which lead us to a develop a whole new architecture and we completely refactored the Sass infrastructure.

This gave birth to Vanilla; our new and improved CSS framework.

Building Vanilla

The first decision we made was to remove the “latest” version target, so sites could no longer directly link to the bleeding edge version of the styles. Instead sites should target a specific version of Vanilla and manually upgrade as new versions are released. This helps twofold, shifting the testing and QA to the maintainers of each particular site allows for staggered updates without a sweeping update to all sites at once. Secondly, allowed us to modify current modules without updating the sites until the update was applied.

We knew that we needed to make the update process as easy as possible to help other teams keep their styles up to date. We decided against using Bower as our package manager and chose NPM to reduce the number of dependencies required to use Vanilla.

We knew we needed a build system and, as it was a greenfield project, the world was our oyster. Really it came down to Gulp vs Grunt. We had a quick discussion and decided to run with Gulp as we had more experience with it. Gulp had all the plugins we required and we all preferred the Gulp syntax instead of the Grunt spaghetti.

We had a number of JavaScript functions in Guidelines to add simple dynamic functionality to our sites, such as, equal heights or tabbed content. The team decided we wanted to try and remove the JS dependency for Vanilla and make it a pure CSS framework. So we stepped through each function and tried to work out if we, most importantly, required it at all. If so, we tried to develop a CSS replacement with an acceptable degradation for less modern browsers. We managed to cover all required functions with CSS and removed some older functionality we did not want any more.

Using Vanilla

Importing Vanilla

To start using Vanilla simple run $ npm install vanilla-framework --save in the root of your site. Then in your main stylesheet simple add:


@import ../path/to/node_modules/vanilla-framework/build/scss/build.scss
@include vanilla;

The first line in the code above imports the main build file of the vanilla-framework. Then included as it is entirely controlled with mixins, which will be explained in a future post.

Now that you have Vanilla imported correctly you should see the some default styling applied to your site. To take full advantage of the framework we require a small amount of mark up changes.

Mark up amendments

There are a number of classes used by Vanilla to set up the site wrappers. Please refer to the source for our demo site.

Vanilla-framework

Conclusion

This is still a work in progress project but we are close to releasing www.ubuntu.com and www.canonical.com based on Vanilla. Please do use Vanilla and any feedback would be very much appreciated.

For more information please visit the Vanilla project page.

Read more
Daniel Holbach

In a recent conversation we thought it’d be a good idea to share tips and tricks, suggestions and ideas with users of Ubuntu devices. Because it’d help to have it available immediately on the phone, an app could be a good idea.

I had a quick look at it and after some discussion with Rouven in my office space, it looked like hyde could fit the bill nicely. To edit the content, just write a bit of Markdown, generate the HTML (nice and readable templates – great!) and done.

Unfortunately I’m not a CSS or HTML wizard, so if you could help out making it more Ubuntu-y, that’d be great! Also: if you’re interested in adding content, that’d be great.

I pushed the code for it up on Launchpad, there are also the first bugs open already. Let’s make it look pretty and let’s share our knowledge with new Ubuntu devices users. :-)

Oh, and let’s see that we translate the content as well! :-)

Read more
Anthony Dillon

I was recently asked to attend a cloud sprint in San Francisco as a front-end developer for the new Juju GUI product. I had the pleasure of finally meeting the guys that I have collaboratively worked with and ultimately been helped by on the project.

Here is a collection of things I learnt during my week overseas.

Mocha testing

Mocha is a JavaScript test framework that tests asynchronously in a browser. Previously I found it difficult to imagine a use case when developing a site, but I now know that any interactive element of a site could benefit from Mocha testing.

This is by no means a full tutorial or features set of Mocha but my findings from a week with the UI engineering team.

Breakdown small elements of your app or website its logic test

If you take a system like a user’s login and register, it is much easier to test each function of the system. For example, if the user hits the signup button you should test the registration form is then visible to the user. Then work methodically through each step of the process, testing as many different inputs you can think of.

Saving your bacon

Testing undoubtedly slows down initial development but catches a lot of mistakes and flaws in the system before anything lands in the main code base. It also means if a test fails you don’t have to manually check each test again by hand — you simply run the test suite and see the ticks roll in.

Speeds up bug squashing

Bug fixing becomes easier to the reporter and the developer. If the reporter submits a test that fails due to a bug, the developer will get the full scope of the issue and once the test passes the developer and reporter can be confident the problem no longer exists.

Linting

While I have read a lot about linting in the past but have not needed to use it on any projects I have worked on to date. So I was very happy to use and be taught the linting performed by the UI engineering team.

Enforces a standard coding syntax

I was very impressed with the level of code standards it enforces. It requires all code to be written in a certain way, from indenting and commenting to unused variables. This results in anyone using the code, being able to pick up it up and read it as if created by one person when in fact it may have contributed by many.

Code reviews

In my opinion code reviews should be performed on all front-end work to discourage sloppy code and encourage shared knowledge.

Mark up

Mark up should be very semantic. This can be a case of opinion, but shared discussion will get the team to an agreed solution, which will then be reused again by others in the similar situations.

CSS

CSS can be difficult as there are different ways to achieve a similar result, but with a code review the style used will be common practise within the team.

JavaScript

A perfect candidate as different people have different methods of coding. With a review, it will catch any sloppy or short cuts in the code. A review makes sure  your code is refactored to best-practise the first time.

Conclusion

Test driven development (TDD) does slow the development process down but enforces better output from your time spend on the code and less bugs in the future.

If someone writes a failing test for your code which is expected to pass, working on the code to produce a passing test is a much easier way to demonstrate the code now works, along with all the other test for that function.

I truly believe in code reviews now. Previously I was sceptical about them. I used to think that  “because my code is working” I didn’t need reviews and it would slow me down. But a good reviewer will catch things like “it works but didn’t you take a shortcut two classes ago which you meant to go back and refactor”. We all want our code to be perfect and to learn from others on a daily basis. That is what code reviews give us.

Read more