Sorry for the delay, old man ended up needing his afternoon nap.
Let's break down the CSS. Follow the bouncing ball at:
https://cutcodedown.com/for_others/Exodus_AU/testing1/screen.cssFirst up we have modern webfont declarations. See how both of them use the same font-family name, and explicity declare weight and style? That's how it's SUPPOSED to be used. It's shocking how many places -- even ones I use to handle format conversions like Font Squirrel, or good documentation like MDN -- fail to mention that little detail.
As I mentioned in the last post, we only really need woff and woff2 at this point. OTF is old outdated IE 5 nonsense, with the more modern formats being both smaller, and tend to render better on non-Microsoft platforms.
Next is that reset... just big enough to reset what NEEDS to be reset without screwing over elements that have 'issues', whilst just small enough to not piss all over the place.
I set the border-box box-model on all elements because it's just easier to work with. For all the years of asshats running their mouths about the "standards box model" and how IE's "broken box model" was bad, now we have a means of actually triggering said "border and padding are inside width" behavior, and those same asshats run around singing its praises. This is why I have a lot of disgust with fellow developers. I've been saying the "incorrect" IE way was better for 20+ years...
Now we can use it with impunity.
I hide HR on pages because they exist as a semantic element, marking a change in topci/subject basically saying "this text is not part of the headings before it". (which is why HTML 5's "footer" is a pointless redundancy). IT DOES NOT MEAN DRAW A LINE ACROSS THE SCREEN! Most people hear "horizontal rule" and think drawing a line with a ruler, and not a grammatical or structural RULE.
Kind of like vertical breaks -- or as some mouth breathers now call it a "pipe".
The first media query fixes some older iOS and Windows Mobile devices that pre-date the viewport META. If the -webkit- version is sent to desktop Safari it can break the ability to zoom
(but not on mobile, way to herp that derp there Apple!) but few desktop users would make their window narrower than 480px, and every device that "needs' this fix is smaller than that.
At this point said devices are probably dead and buried in terms of userbase, but it's 105 bytes of code, so no harm in including it.
Remember, when I'm talking about minimalism I don't mean byte obsession.
I always set 100% height on html and body just because some layouts need it, sometimes backgrounds get choppped if you don't set it, and child elements cannot set % heights if the parent doesn't have a height on it.
From here out I'm going to summarize by selector. When making the primary layout before I write the big media queries, I like to start with desktop then pare it down. A lot of people will tell you to start with mobile and work your way up, but I find that approach utterly back-assward. We can target any mobile we care about with media queries... you know what we can't target with media queries? Old desktops, that's what!
body, button, input, table, textarea, select -- This nabs the elements that don't inherit from body for our primary font properties. As well as body itself. I use a 1.5em line-height on flow text as it aids legibility the longer your paragraphs get and/or wider the screen is.
body -- upping the letter spacing makes Avante Garde look more like nexa, and improves overall legibility. I've always liked this font as it's got that same style but without the rail thin glyphs... but the low default letter spacing needs some help, so help we provide.
for normal/16px/vga/100%/96dpi/"windows vista+ small" / pickAdamnedNameAlready users, 0.0625em will be 1px. For large/20px/8514/125%/120dpi/"windows vista+ medium" / pickAhuffingName already users like myself it's 1.25px... and on my 4k media center it's 2px.
Aren't EM fun to work with?#toggle_mainMenu -- you know what this is. IE doesn't obey label clicks if the input is "hidden", so we set display block to show it, then sneakily hide it off screen.
#top -- I called this <header> #top so if you want to add a "back to top" link later, it's just <a href="#top"> and you're off and running. Bottom margin pushes the content area off of it.
#top > div your "webBanner" area. Doesn't really need a class or ID since it's the only div that's a direct child of #top. The cute trick here is that I use padding to push the text off the image, then set the background-size to auto-adjust width whilst filling 100% of the DIV container.
h1 -- as there should only be one H1 if we use the 'classic' structural rules, no reason for this to have a class or ID. The padding actually sets the large height of the banner area, which we'll be able to exploit to shrink it later in the media queries. I also lower the line-height since this isn't flow text.
h1 small -- the display:block actually makes it obey its own line-height instead of its parent -- the <br> in the markup mostly being there for non-CSS users. SMALL does not mean "this text should be displayed smaller", it means "this text would be smaller for gramamtical reasons in a professionally written document, such as for de-emphasis"... a tagline under a heading fits that description as it's a subtext of the numbered heading. We explicity restate the line-height because Chakra based Edge is an idiot.
Thankfully with Chromium based edge slowly replacing the old Edge, we won't have to deal with that derpitude forever!#mainMenu -- kill the bullets, fix it on the screen. Not complicated.
#mainMenu li -- inline-block puts them all on one line (duh), and basically strips LI of formatting. Given the plethora of rendering issues that can arise when trying to style LI, it's often better to just set it to inline and target the child elements (anchors) instead.
#mainMenu a -- inline-block so they can accept padding, margin to space them apart, coloration. I added a translucent white background so when you scroll, they're still legible.
#mainMenu a,
.ctaButton -- both of these share these same basic styles, so group their selectors to reduce the overall code, AND to make it easy to change both of them at the same time. Also helps to set up any transitions we might want.
#mainMenu a:focus,
#mainMenu a:hover,
#mainMenu a.current,
.ctaButton,
#contactUs > div,
#contactUs button:hover -- ditto, these all get the same colouration, so set them together. This is why "mixins" and other such CSS pre-processor crap just reeks of being for people who don't know how to use CSS
#mainMenu a:focus,
#mainMenu a:hover,
.ctaButton:focus,
.ctaButton:hover -- for hover on these elements I decided to add a scale transform to enlarge them, which is animated thanks to the transition declared on the anchors. When setting hover ALSO set your :focus so that people using keyboard navigation aren't left out in the cold.
.ctaButton -- gets some style that isn't in common with the other groupings, like larger text and some bottom margin.
.ctaButton:focus,
.ctaButton:hover -- likewise it gets a different background color on hover, since its default state looks like the menu hover state.
.tiles -- these looked like a list of anchors, so I coded them as such. Kill the bullets, set up flex, turn on wrapping for flex if things don't fit, and set an alignment just in case.
.tiles li -- the display:inline is for browsers that don't support flex and again the "issues" I mentioned with styling LI before. Remember that the condensed flex property is "grow, shrink, basis"... in this case we want auto width, it can grow to fit the available space (1), but not shrink below its content size (0)
.tiles a -- the block setting makes it fill the parent container. The min-width makes sure that they stay visible and wrap as needed. I chose 10em as that's typically the maximum text width I'd expect with those "lights" once you have more text inside them. Adjust as necessary. From there it's just padidng, margin, and alignment. The 1px bottom margin is just so that when it word-wraps there's a small border created by the box-shadow.
... and again notice how I'm doing almost everything in EM. The fractional pixel that 0.625em would create on that margin-bottom looked like ass, so that got 1px. One of those rare exceptions and why no "good practice" rule should be inviolate.
.tiles i -- again they don't need that "icon" class, they're the only italic tags inside these tiles, and it seems unlikely you'd be using book or document titles
(the grammatical/semantic reason to use <i> when not <cite>ing said source) inside these "tiles".
body > section -- our main content "sections" can all easily be grabbed without throwing extra classes at things.
You might be starting to see a trend in my thinking. The > says "only those that are direct children of" so you can use sections inside sections without this rule applying. The mix of 90% width with a max-width gives us a nice accessible limit, but again nothing you would be unfamiliar with. I tweaked the box-shadow so that there's 0.25em faint hairline at the top to make it clearer the start of the sections, whilst maintaining a nice bottom shadow.
Oh, and when you declare box-shadow, you can omit the "growth" number if it's going to be zero. Hence:
box-shadow:0 0.25em 0.75em 0 rgba(0,0,0,0.2);
and
box-shadow:0 0.25em 0.75em rgba(0,0,0,0.2);
Are functionally identical.
h2 -- I set these to inline block so they shrink to their content. Since a H2 is usually sibling to block-level elements (p, ul, ol, pre, form etc) and not inline / phrase level ones, this works well. This way we can use border-bottom instead of text-underline, since text-underline-color has spotty/unreliable support and doesn't even exist on Microsoft browsers (last I checked)
#aboutUs p -- enalrge the text to match what you were doing. I'm not wild about it that big, but it's not horrible.
#contactUs -- use flex to make the equal height columns. This way it at least has a chance at working in IE11. Again, set up wrapping just in case.
#contactUs > div -- that first level DIV we don't want to grow or shrink, so 0 0 on that. This allows the form to grow to fill the most space.
I do not set a bottom padding because flex elements compact out bottom padding and margins when possible to try and "make the most room" for mobile. The workaround for this I use:
#contactUs:after -- Just stuffs an element in there to make the gap. Normally you wouldn't say "width:100%" on a block level container, but as we're inside a flex we have to, otherwise it would ride up next to the form. Hence this too gets flex:0 0 auto;
#contactUs h2,
#contactUs h3 -- again these get the same basic values, so group their selectors.
#contactUs ul -- strip bullets, pad, yawn.
#contactUs Form -- this we want to grow to fill, but not shrink smaller than its contents allow for, hence flex:1 0 auto; I pad the top 1.5em to match the padding on the sibling DIV, making our H2 and H3 line up with each-other.
#contactUs input,
#contactUs textarea -- again, shared style, and since we set box-sizing:border-box on everything, the padding and border are inside the width not around it... making it easy for us to make them grow to the available width. I gave them a bit of a style tweak whilst here.
#contactUs input:focus,
#contactUs textarea:focus -- I turn off the default outline because Chromium/Blink based browsers do a SQUARE outline even if the element has rounded corners... so instead I apply a pretty box-shadow much akin to Safari's default focus behavior, just an off-magenta to match the layout instead of blue.
#contactUs button -- again, full width, padded, font-size... you know what this is. The hover state shared with the main menu becasue it's declared with a pseudo-class will override our background declaration here.
body > footer -- remember sections can have header and footer too, so a simple immediate child combinator works just like it did for <section>. Pad it, center content, color -- you know what all that does.
... and that's the base desktop layout! I did some of the groundwork for responsive layout as well, so let's summarize that by media query. Again note that since we're using dynamic fonts, our queries should also be in EM.
(max-width:85em) -- having just one tile drop and become full width looks silly, so if we set the min-width to 25% it will reduce it to a mix of 4 and 3, which looks far better. Depending on how many of these "tiles" you have in production you may end up adjusting this query width.
(max-width:70em) -- Changing the padding for the h1 and the DIV to be based on VW -- viewport width -- we're able to make it start scaling down smaller as the display shrinks, without it becoming a massive mess on displays over 1080p.
(max-width:66em) -- at this size it just helps to shrink and remove padding to better use the dwindling screen space, improving the user expierience. Likewise that massive default H2 size gets dropped a wee bit.
(max-width:42em) -- Shrink the banner image spacing even further, and lower the H1 padding to the smallest that still looks good. Likewise the fixed menu just looks better centered down this small, we kill the flex layout on #contactUs so the two sections are reduced to one column, and we shrink that oversized #aboutUs p for more comfortable reading on smaller displays.
... and that in a nutshell is how I'd have gone about what you have so far.
I know this is all a lot to take in, so study, try it, play with it, and come back with questions when you're ready.
