Now, I'm going to be frank with you. I'm not trying to be insulting here, I'm just going to list off what's wrong, and then show you a better way of doing it.
Sadly, this another example of why I think people who use SCSS haven't learned enough HTML, CSS, or JavaScript to be looking at SCSS yet. If you had a firmer grasp of any of those things, you wouldn't be writing twice the code needed to do the job and would quickly see SCSS for the LIES its creators and fans endlessly spew.
I mean, it's a form... why isn't it marked up as a FORM? Why all the DIV and SECTION for nothing? Why the H3 doing LABEL's job? Fixed pixel widths with dynamic fonts?!?
I think you also have a minor goof, you have your (pointless) placeholders backwards with what field they are for. Similar goof in the font-stack. Once you declare the fallback family "monospace" nothing past that point in the stack will be obeyed or reached. Hence this:
$header-font-family: "shadow-multiple","3d","Inconsolata",'Courier New', Courier, monospace,'Courier New', Courier, monospace;
Should be just this:
$header-font-family: "shadow-multiple","3d","Inconsolata",'Courier New', Courier, monospace;
Easy enough a typo if you're cutting and pasting. Did that a few times myself two decades ago when I was just learning CSS.
If you reversed the code order of labels and inputs, the HTML "required" attribute along with CSS3's ":valid" and ":focus" could handle that animation, no JS needed, and not even need keyframes to do it since you could use top positioning and "Transition" to more smoothly handle that.
First, let's clean up that markup.
<!DOCTYPE html><html lang="en"><head><meta charset="utf-8">
<meta
name="viewport"
content="width=device-width,height=device-height,initial-scale=1"
>
<link
rel="stylesheet"
href="rewrite.screen.css"
media="screen,projection,tv"
>
<title>
Signup Form Demo
</title>
</head><body>
<form action="#" method="post" id="signUp">
<fieldset>
<h1>SIGN UP</h1>
<div>
<input type="text" name="name" id="signUp_name" required>
<label for="signUp_name">Name</label>
</div><div>
<input type="password" name="pass" id="signUp_pass" required>
<label for="signUp_pass">Password</label>
</div>
</fieldset>
<button>Submit</button>
</form>
</body></html>
Note I condense the DOCTYPE through charset META to a single line, as well as closing HEAD and opening BODY, and closing BODY and HTML. I don't do this to shave off a few bytes, but instead it is a gentle reminder that these elements must appear in that order, and that no other tags or CDATA has any business being placed between them. It's just a good practice to stop yourself from making mistakes. If I cared about the handful of bytes, do you really think I'd have all that whitespace in my other META and LINK tags?
There is NO reason to have a X-UA if you're setting it for "edge" unless you've done something horribly wrong in your HTML or CSS. That META exists to tell modern browsers to behave as older ones, not to try and tell them to behave as the newest they support -- unless you've hit up against the rare case of being blacklisted for compatibility garbage because your old site at the location was outdated / incompatible with newer IE flavors.
You don't need to say "1.0" when declaring a value of 1 on initial-size, and I include device-height as my tablet (an many older Android devices) will report the 'lie' height as WIDTH without that. (serious hurr durrz on Android/Chrome's part)
I include the MEDIA attribute so that I'm not screwing over users on non-screen media by sending them CSS that might be utter and complete gibberish. HTML 5 validation will complain about projection and TV returning warnings, to blazes with that noise. There are still plenty of devices in circulation that will screw with the layout if we don't include those (wii, wiiu, ds, kiosks) and really the "valid" media targets should be none of the HTML specification's business.
I switched it to a H1 since structurally if you don't have an H1, you have no business having a H2. Just like how jumping to H3 to H6 is complete structural/semantic gibberish if the heading tag preceding it is not the immediate higher ordered / lower numbered heading. In production if this were to be something like a modal dialogue you would naturally drop that to H2 depth.
This is a FORM, code it as such. You have LABELS for your inputs, code them as such. Placing the labels after the inputs lets us use some CSS trickery to implement the animations without resorting to scripting.
... and that provides more than enough hooks for the visual style you were applying, which would go something like this:
@import url(fonts.googleapis.com/css);
@import url(fonts.googleapis.com/css);
@import url(fonts.googleapis.com/css);
/* mini reset */
body, form, fieldset, h1 {
margin:0;
padding:0;
}
fieldset {
border:0;
}
/* so we can min-height / display:table center */
html, body {
width:100%;
height:100%;
}
/* remember, these extra tags do NOT inherit font-face */
body, table, input, textarea, button {
font:normal 100%/150% "Tangerine",arial,helvetica,sans-serif;
}
body {
display:table;
font-size:93.75%;
background:#E8E8E9;
/*
don't rgba the body background,
you don't know the browser default!
*/
}
#signUp {
display:table-cell;
vertical-align:middle;
text-align:center;
}
#signUp fieldset {
width:50%;
max-width:33.33em;
margin:0 auto;
padding:3em;
margin-bottom:2em;
text-align:left;
background:rgba(0,9,10,0.03);
box-shadow:0.33em 0.33em 0.5em 1px rgba(0,9,10,0.3);
}
#signUp h1 {
margin-bottom:0.667em;
font:bold 150%/120% "shadow-multiple","3d","Inconsolata","Courier New",Courier,monospace;
text-align:center;
text-shadow:
0.04em 0.04em 0 #FFF,
0.08em 0.08em 0 #AAA;
}
#signUp div {
position:relative;
padding-top:3em; /* excess makes room for label */
}
#signUp label {
position:absolute;
top:0.88em; /* for non-CSS3 browser placement */
left:0.44em;
font-weight:bold;
font-size:113.33%;
text-align:left;
}
#signUp input {
box-sizing:border-box;
width:100%;
padding:0 0.5em 0.1em;
background:transparent;
border:solid rgba(0,9,10,0.713);
border-width:0 0 1px;
}
/* kill default browser styling annoyances */
#signUp input:focus,
#signUp input:required {
outline:none;
box-shadow:none;
}
#signUp button {
color:#FFF;
background:#C43;
border:0;
border-radius:0.33em;
padding:0.33em 0.66em;
}
@media (min-width:1px) { /* Sneaky trick to target just CSS3 browsers */
/*
By isolating our animation code for CSS3 only, legacy browsers
can still access this with no funky side-effects
*/
#signUp label {
top:2.64em;
transition:top 0.3s;
}
#signUp input:focus + label,
#signUp input:valid + label {
top:0.88em;
}
}
A bit cleaner in the style by not willy-nilly mixing pixels and em/%... and if we strip the comments it's 1.76k (2.25k with comments). Your style.scss alone is 1.41k, and that's not counting its two dependencies/imports that are another 1.48k.
Basically meaning you have nearly twice the SCSS needed to do the job, made all the more tragic by your resultant CSS output being 1.78k... near on the same size as mine... You basically wrote -- all combined -- 4.4k in five files deployed as 3.3k in three files to do the job of 2.95k in two files.
Live demo here; look ma, no JavaScript!
cutcodedown.com/for_others/EzeBernardineMay
Much like front-end frameworks, all this SCSS preprocessor nonsense does is make you work harder, not smarter. It provides zero benefits in real world deployment, whilst making you write more code, spread things out making it harder to debug, inspect in a meaningful manner at the browser level, and a host of other problems.
Hope that helps, or at least gets you thinking in different directions. Take my advice, and kick that SCSS rubbish to the curb. You don't need it, and it's teaching you bad habits that will whip around to bite you sooner or later. Everything you're being told about how "useful" and "helpful" it is amounts to little more than a bald faced LIE!