Form Elements and Browser Defaults

Every <input>, <button>, <select>, and <textarea> on the web starts life looking like a native operating system control — gray borders, Arial font, an appearance designed to match the user’s OS rather than your website. That is not a bug. Browsers intentionally style form elements this way to make them recognizable and usable before any CSS is applied.

The challenge: those defaults conflict with your brand. This module covers how to take control of form elements — resetting the defaults, then building a polished appearance that is consistent with the rest of the STO site.

Why form elements are different

Form elements receive special treatment from browsers that other HTML elements do not. There are two reasons:

1. Usability before CSS. A form needs to be functional even on a page with no stylesheet. Browsers apply default styles that communicate “this is interactive.”

2. OS integration. Browsers historically matched form controls to the operating system’s native UI kit — so a checkbox on macOS looked like a macOS checkbox, and one on Windows looked like a Windows checkbox. This consistency came at the cost of design control.

The result: form elements do not inherit your page’s typography, do not follow the same box model defaults as other elements, and look completely different from every other element you have styled so far.

font: inherit — the first fix

Open contact.html before adding any form CSS. The input fields and buttons use a different font from the rest of the page — typically the browser default (usually Arial or a system UI font) — even if you have set font-family on body.

This happens because form elements do not inherit font-family, font-size, or font-weight from their parent by default. The fix is one line:

input,
button,
textarea,
select {
  font: inherit;
}

font: inherit forces the font shorthand (family, size, weight, style) to inherit from the parent element — the same font your body text uses. This single rule makes form elements feel like they belong to your page.

This is why the CSS reset in Module 08 includes this rule. For now, add it to your style.css above your form-specific rules.

box-sizing on form elements

Form elements also ignore the global box-sizing: border-box reset unless you explicitly include them. The reset from Module 03 uses *, *::before, *::after — which does cover form elements — but it is worth knowing that some older reset patterns missed them.

If your inputs behave unexpectedly when you add padding (growing wider than their container), verify your global reset covers form elements.

appearance: none

appearance is a browser-specific property that controls whether an element renders using the native OS chrome. Setting it to none strips that native rendering:

select {
  appearance: none; /* removes the native dropdown arrow */
}

input[type="checkbox"] {
  appearance: none; /* removes the native checkbox */
}

Use appearance: none carefully. When you remove the native appearance, you must rebuild the visual affordance yourself — otherwise the element becomes invisible or confusing. For select dropdowns, that means adding a custom arrow. For checkboxes, it means rebuilding the checked state with CSS.

You will use appearance: none on the STO select in Lesson 03.

The four main form elements

<input>

The most flexible form element. The type attribute determines its behavior and how much CSS control you have:

• text, email, password, search, tel, url — fully styleable
• number — styleable; the spin buttons (up/down arrows) vary by browser
• checkbox, radio — very limited CSS control without appearance: none
• file — almost no CSS control; only the button label can be styled
• range, color — browser-specific; reliable cross-browser styling requires JavaScript

For the STO contact form, you are styling text and email inputs — both fully styleable.

<textarea>

Behaves like a text input but allows multiple lines. Unique property: a resize handle appears in the bottom-right corner by default. You can control this with the resize property — covered in Lesson 02.

<select>

The most restricted. CSS can style the visible box (border, background, padding), but the dropdown menu that appears on click is rendered by the OS and cannot be styled with CSS alone. appearance: none removes the native arrow so you can add a custom one — but the open dropdown itself remains OS-controlled.

<button>

The most flexible of the four. Buttons accept all box model, typography, and visual CSS. The default OS appearance can be reset cleanly with cursor: pointer, border: none, and font: inherit. Covered in Lesson 03.

What cannot be styled (without JavaScript)

Some form elements are intentionally beyond CSS’s reach:

• <input type="file"> — the “Choose File” button uses OS-native rendering; only limited text styling is possible
• The open state of <select> dropdowns — the dropdown list is OS-rendered
• Checkbox and radio tick marks — the check itself requires appearance: none plus a full custom implementation

This is not a limitation of your skills — these elements require JavaScript for full customization. For this course, the STO contact form uses only text, email, select, textarea, and button — all of which can be styled cleanly.

Exercise

See the font difference before and after fixing it:

1. Open contact.html in the browser without any form CSS. Observe the input fields — they likely use a different font from your page headings and body text.

2. Add the font reset to style.css:

input,
button,
textarea,
select {
  font: inherit;
}

3. Reload the page. The form fields should now use the same font as the rest of the STO site.

4. In DevTools, inspect an <input> element. In the Computed tab, find the font-family property. Before the fix, it shows the browser default. After the fix, it shows the font inherited from body.

5. Also inspect the <select> element. Look at the Styles panel — you should see browser default styles listed in a separate section labeled “user agent stylesheet.” These are the styles you will be overriding in the next four lessons.

Recap

• Browser default styles make form elements look like OS-native controls — different font, border, and appearance from the rest of your page.
• Form elements do not inherit font-family, font-size, or font-weight from their parent by default. font: inherit on all four element types fixes this.
• appearance: none removes the native OS chrome from an element, but you must rebuild the visual appearance yourself.
• <input> (text/email), <textarea>, <select>, and <button> are fully styleable with CSS. File inputs, open dropdowns, and checkbox marks are not.
• The CSS reset from Module 03 handles box-sizing on form elements — but font: inherit must be added separately.

Lesson 02 styles the input fields and textareas — adding borders, padding, background, and the custom focus ring that replaces the default browser outline.