Add the Blue Bar

[coreymckrill]

Introduces the "Blue Bar" or, more accurately, header navigation. It includes a simple taxonomy-based breadcrumb on the left and a dropdown menu of categories on the right. The color scheme changes ("The Not Blue Bar") for certain categories. The layout responsively handles mobile, tablet, and desktop views.

The categories dropdown functionality is entirely CSS-based. I'm not sure if this is the right approach, as it made the stylesheet a bit more complex, but it's nice that no JS file is required.

This also makes the entire site header (including the global header) fixed to the top when not in a narrow mobile viewport, as called for in the design.

This does not yet handle the "All Posts" large heading for the Posts Page view, due to the issue described below.

Fixes #32

[coreymckrill]

Noting that there currently isn't a very good way to show the "All Posts" title, which should appear in the Blue Bar on the Posts page if the site is configured to have a static homepage. Ideally we'd use the query-title block since that outputs the category term names when viewing category archives. I suggested that this block should also cover the Posts page title here.

The alternative for now, I think, is to copy the header-navigation.html block template part directly into a template specifically for the Posts page view (home.html I think?) and replace the query-title block with a hard-coded "All Posts" heading block.

[coreymckrill]

The alternative for now, I think, is to copy the header-navigation.html block template part directly into a template specifically for the Posts page view (home.html I think?) and replace the query-title block with a hard-coded "All Posts" heading block.

On second thought, the "All Posts" heading block could probably live outside the header.html block template part. So the home.html file would be identical to index.html, but with the addition of a heading block above the <main> tag. We'd have to figure this out first, though.

[iandunn]

made the stylesheet a bit more complex, but it's nice that no JS file is required.

i'll check when i get into the code, but I generally prefer that tradeoff too, seems less fragile and more straightforward. might be more reliable for screen readers too?

makes the entire site header (including the global header) fixed to the top

• should that style go in the block stylesheet, since it'll be needed when we roll the global header out?
• <rant>i hate fixed navigation, it's one of my biggest pet peeves on the web.</rant>. nothing actionable there, just needed to say it 😆

copy the header-navigation.html block template part directly into a template specifically for the Posts page view

Another idea would be to have both query-title and hardcoded All Posts in the template part, but hide one or the other w/ CSS until the G issue is resolved. No preference, just throwing it out there.

[coreymckrill]

should that style go in the block stylesheet, since it'll be needed when we roll the global header out?

I guess the question is if the global header will always be fixed, or if that's specific to the News site...

Another idea would be to have both query-title and hardcoded All Posts in the template part, but hide one or the other w/ CSS until the G issue is resolved. No preference, just throwing it out there.

🤔 That might work. I'll try it.

[iandunn]

Left some comments, but no blockers 👍🏻

[iandunn]

The partial class names feels kind of awkward to me; if I don't remember what the containing SCSS block is named, then I have to scroll back up to the top to find out.

PhpStorm does show it in its breadcrumb toolbar, but it still feels less readable to me, especially in long blocks like this.

I don't feel strongly though.

[iandunn]

the question is if the global header will always be fixed, or if that's specific to the News site...

The former seems like a safe assumption. @beafialho, is that what you were thinking?

[beafialho]

Yes @iandunn I was thinking the global header would be fixed for all the site's pages.

[coreymckrill]

I was just reading this, and thinking that after all this, it might actually be simpler and more robust to use CSS grid for the layout of this bar and manage the positions of things responsively. It might not be worth the refactor time at this point, though.

@iandunn I'm going to go ahead and merge this, and you can revisit with CSS grid if layout bugs crop up later.