Issue 5385 - Create Site Header Component for Help Center

static/scss/base/_variables.scss

 // This file is part of help.eyeo.com.
 // Copyright (C) 2017 Eyeo GmbH
 //
 // help.eyeo.com is free software: you can redistribute it and/or modify
 // it under the terms of the GNU General Public License as published by
 // the Free Software Foundation, either version 3 of the License, or
 // (at your option) any later version.
 //
 // help.eyeo.com is distributed in the hope that it will be useful,
 // but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ skipping 12 matching lines @@
 $gray-light: #ECECEC;
 $gray-medium: #AEAEAE;
 $gray-dark: #757575;
 $black: #161616;
 
 // Brand colors
 
 $eyeo-black: $black;
 $abp-red: #C70D2B;
 $abb-blue: #0D79C7;
+
+$primary: $eyeo-black;
 
 // Typography //////////////////////////////////////////////////////////////////
 
 // Font stack
 
 $primary-font: "Source Sans Pro", sans-serif;
 
 // Font colours
 
 $font-color-default: $eyeo-black;
@@ skipping 14 matching lines @@
 $tiny-font: 0.8em;
 
 // Font weights
 
 $bold-weight: 700;
 
 // Sizes ///////////////////////////////////////////////////////////////////////
 
 // Container widths
 
-$content-width: $desktop-width;
+$content-width: 960px;
 $navbar-width: $content-width + 100px;

[juliandoucette, 2017/08/23 14:39:07]

I think it's a better idea to start from the $desktop-width and move inwards
instead of outwards. e.g. use .container inside .navbar instead of
.navbar-wrapper and make $content-width = $desktop-width - 100px.

[ire, 2017/08/25 08:27:10]

I like the idea of moving inwards instead of outwards, but I think the
.container class is a bit restrictive. Since it uses fixed widths, it doesn't
really take advantage of the space available like the current implementation
does. There are viewport sizes in which the container could/should be wider, but
maintains a smaller fixed width. 

[juliandoucette, 2017/08/29 16:17:27]

Acknowledged.

I see what you mean now. And I agree with your implementation. It may be useful
to add a comment about this. I'll leave it up to you to decide whether you think
this is necessary.

[ire, 2017/09/01 10:57:18]

I don't think my comment would be more explanatory than "navbar width is content
width plus 100px", so I'll leave it out

 
 // Header & Footer
 
 $site-header-height: 70px;

[juliandoucette, 2017/08/23 14:39:07]

If these variables only apply to the site header like their name implies then I
think we can move them to _header.scss. The same applies to $search-form-*
below.

[ire, 2017/08/25 08:27:11]

I'm undecided on whether it's better to have all the variables in one file, or
to have them closer to where they are used. One reason I kept the
$site-header-height variable in this file in particular was because the variable
was also used in the layout file (when the header was stuck to the top). Even
though this is the $site-header-height, I can imagine cases where the variable
may be referenced elsewhere (and it would still be correct to call it
$site-header-height). Also, I think it's easier to change (and share) when all
variables are in one file. 

[juliandoucette, 2017/08/29 16:17:26]

Acknowledged.

I concede this point.

 $site-header-content-line-height: 40px;
 
 // Search form
 
 $search-form-width: 320px;
 $search-form-height: 35px;
 
 // Spacers /////////////////////////////////////////////////////////////////////
 
 $xl: 60px;
 $lg: 30px;
 $md: 15px;
 $sm: 10px;
 $xs: 5px;
 
 // Columns /////////////////////////////////////////////////////////////////////
 
 // Breakpoints /////////////////////////////////////////////////////////////////
 
-$mobile-breakpoint: 544px;

[juliandoucette, 2017/08/23 14:39:06]

The website-default grid considers anything less than tablet-breakpoint to be
mobile. We don't currently support phablets (less than 768px and more than
544px) differently than mobile devices (between 320px - 544px).

[ire, 2017/08/25 08:27:09]

What is the reason for not having a difference? Because those are significant
differences in size, a mobile phone versus an iPad, for example. I think at the
size of tablets (greater than 544px), there is still a lot of screen space to be
used and switching to mobile styles (full widths etc) may be underutilising the
space available.

Also, I think the variable names in themselves are more for us to to easily
understand the size, and could as easily be something like $small-breakpoint,
$medium-breakpoint, and $large-breakpoint.

[juliandoucette, 2017/08/29 16:17:26]

There seems to be a miscommunication here about where a phone ends and a tablet
begins. You are saying that a phone ends and a tablet begins at 544. I am saying
that a phone ends and a tablet begins at 768.

I chose the tablet breakpoint (minimum width) (768) based on [the width of the
browser screen on the first ipad when held portrait, the width at which you can
comfortably fit two columns in most layouts].

I will certainly acknowledge that there is room between 544 and 768 for
optimization. And encourage you to optimize for this size (which I would call
"phablet size") if you can. 

(I didn't include a phablet width or breakpoint in website-defaults grid because
none of our existing website designs explicitly support these sizes.)
I agree. But I'm not sure that [small, medium, large] are better than [mobile,
tablet, desktop]; yet?

[ire, 2017/09/01 10:57:19]

Changed to $phablet-breakpoint

+$phablet-breakpoint: 576px;
 
 // Placeholders ////////////////////////////////////////////////////////////////