Responsive · Forms · HTML/CSS Recap

Today we closed out the HTML and CSS half of the course. We finished responsive design, spent the longest stretch on forms (the bridge between the front end and the back end), did a short recap of everything we have built so far, and wrapped up with a quick reflection. JavaScript starts next class.

The goal is one page that looks right on any screen, from a phone to a wide desktop monitor, with one URL instead of a separate mobile site.

• Always start with the viewport meta tag: <meta name="viewport" content="width=device-width, initial-scale=1.0">. Without it, a phone pretends it is about 980 pixels wide and shrinks the desktop layout down, so you get tiny text and a sideways scroll bar. Modern templates and AI already add this, but check that it is there.
• Design mobile first: style the small screen first, then add exceptions for wider screens with media queries. A block like @media (min-width: 768px) { ... } is just a wrapper that swaps in different CSS once the screen is wide enough.
• Reach for relative units before fixed pixels. A fixed width is the single most common thing that breaks a layout on a phone, so use percentages, em or rem, and a max-width to keep a block flexible without letting it grow forever on a huge screen. And width: 100% means 100 percent of the parent, not the whole page.
• Most of the time Flexbox and Grid already handle this for you. When a page will not cooperate, a stray fixed width is usually the culprit. Look there first.
• Test as you go. Open the page in Live Server, then use the DevTools device toolbar (the phone icon, or Ctrl+Shift+M / Cmd+Shift+M) to step through different device sizes.

In class I asked AI to add a navigation bar that collapses into a burger menu, then went down a rabbit hole figuring out why it switched at 588 pixels instead of 600. The number did not matter. The habit did: when something surprises you, screenshot it, hand it to AI, and ask why. That is how you keep learning while you build.

A form on its own is just for looks. A form that sends its data somewhere is what lets a website actually do something: log in, search, submit, contact. This is the first real bridge to a back end, so it matters.

• Every form needs two attributes: action (the address the data is sent to, also called an endpoint) and method (how it is sent).
• GET vs POST is the choice that trips people up. GET attaches the data to the URL after a ?, so you can see it and it lands in your browser history. That is fine for a search. POST sends the data in the request body instead, so it does not show in the URL. Use POST for passwords and anything sensitive, and for long data or file uploads. Two quick questions decide it: is the data sensitive, and is it long?
• Inspect a real form to see this in the wild. Open DevTools on Google or any site you use, find the <form> tag, and read its action, method, and the <input> elements inside. Once you start looking, almost every site is full of forms.
• The input type does real work for you: text, email (basic built-in checking, though it is loose, so do not lean on it), password (masked on screen, which is not the same as secure), number (a numeric keypad on mobile), and date (a native date picker). For longer or structured input there is textarea, select for a dropdown, checkbox, and radio (give radios in a group the same name so only one can be chosen).
• Always wire up your labels. Connect each <label> to its input with for and id, and clicking the label focuses the input and lets a screen reader announce it. AI skips this surprisingly often, so check.
• A few attributes come free: required, minlength, min, max. Group related fields with <fieldset> and a <legend>, and style the :focus state so people can see where they are typing.

The class form endpoint

I built a small endpoint for the class: https://oim.zhili.dev/echo/view. Point your form's action at it and it shows you whatever you submitted, so you can see GET vs POST for real. While you test, I can see the request come in, including the city it came from. Nothing scary, but a good reminder that hitting a server sends real information. Later, once we know JavaScript and fetch, you can do much more with this same endpoint. If you are curious now, feed its page to AI and ask what else it can do.

Labels and ARIA attributes such as aria-label and aria-required let screen readers describe a form to people who cannot see it. Building a modern website means building one that everyone can use, so treat accessibility as a baseline, not an extra.

We started from the basic page structure and tags, learned CSS selectors and properties, added Flexbox and Grid for layout, and today made things responsive and accessible. That completes the front-end foundation. From here, responsive is assumed: I will stop listing it as a separate requirement, and every page you build should already work on a phone.

1. Finish and submit Mini Project 1 by Friday 6/12. Deploy it, make sure it is responsive, put the live URL in the repo's About box (open About, then check "Use your GitHub Pages website"), and submit the repo link on Canvas. The deadline is a first draft, not the end. Keep improving it.
2. Get ready for the Monday showcase. Each of you will give a short walkthrough of your project, and I will ask a few questions about your repo and how it is put together. You do not need slides. The site should speak for itself. This counts toward participation.
3. Add a contact page with a form to your OIM3690 course repo. Create contact.html, add a form that uses the action and method I gave you (https://oim.zhili.dev/echo/view), and include as many different input types as you can, with proper labels and accessibility. Then switch the method between GET and POST and watch what changes. This is part of Checkpoint 2.
4. Check that your sites are responsive. Open your personal website and your Project One in Live Server, toggle the device sizes in DevTools, and confirm the viewport meta tag is present.
5. Update your weekly log logs/wk04.md with what you learned about responsive design and forms this week, plus anything from the reflection that stood out.
6. Checkpoint 2 is due Sunday 6/14: MP1 deployed, logs up to date, and the contact form added. I will check over the weekend.
7. Still shaky on Flexbox or Grid? A few levels of Flexbox Froggy and Grid Garden go a long way. Note your highest level in wk04.md.

Monday we open with the MP1 showcase and then begin our JavaScript journey.