Modern HTML and CSS Web Design: Practical Examples for Today's Websites

Modern HTML and CSS let you build sturdier interfaces with far less code, because browsers now ship features that used to require libraries. I have worked on front ends for client projects since 2012. Over the last few years, CSS has absorbed many jobs that once needed JavaScript. In this guide, I walk through semantic HTML, Grid, Flexbox, container queries, custom properties and the :has() selector with practical examples.

This is not a coding course. Instead, I want to share what I see in the field: which technique fits which part of a business website, and which mistakes quietly cost you speed and budget. If you want the bigger picture of how I run design projects, my web design service page explains the process.

What does modern HTML and CSS web design actually mean?

Modern HTML and CSS web design is an approach that marks up content with meaningful HTML elements and builds layout, color and interaction with current CSS features. Grid and Flexbox handle layout, container queries make components adaptable, and custom properties keep a design system consistent. As a result, pages get lighter, more accessible and easier to maintain.

In the old days, we used floats, table tricks or heavy CSS frameworks for layout. Today the browser does most of that work for you. So modern design is less about a new visual trend and more about trusting the platform's own tools.

For a business, the payoff is concrete. Less code means fewer bugs and faster loading. In addition, the next developer who inherits the project can read standard patterns without a long handover. That is why I describe the technical approach even in my proposals.

Are "HTML5" and "CSS3" still the right terms?

Short answer: they work as marketing labels, but they are incomplete as technical terms. HTML no longer moves in numbered versions. The WHATWG community maintains the HTML Living Standard, and after an agreement with the W3C it became the single authoritative version. In other words, "HTML5" today simply means current HTML.

CSS follows a similar pattern. CSS3 is not one document. Instead, it is a family of modules such as Grid, Flexbox, Color and Selectors, and each module matures at its own pace. So do not wait for a "CSS4" release either.

Why does this matter to you? When an agency says "your site will use HTML5 and CSS3", that sentence guarantees nothing, because almost every site fits the description. The better question is which modern features they plan to use. Also ask how they will handle older browsers.

Why is semantic HTML still the foundation of everything?

Semantic HTML means the element itself describes the content. When you mark navigation with nav, the main content with main and a standalone post with article, browsers, screen readers and search engines understand the structure right away.

In practice, the most common problem I find in audits is a page built entirely from div and span elements. It may look perfect. However, keyboard navigation becomes painful, and screen reader users cannot find the heading outline. Patching those gaps later with ARIA attributes costs far more than choosing the right element from the start.

Search engines also benefit. A clear heading order and meaningful sections make the topic of a page obvious. If you want to add structured data on top, my schema markup guide is a good next step. That said, structured data never makes up for a weak HTML skeleton.

Which semantic elements should you use, and where?

Here are the mappings I reuse on almost every business website. This list is my starting point on each project.

• header: The top area with logo, main menu and contact button. A page can have more than one, for example inside an article.
• nav: Major link groups such as the main menu and breadcrumbs. Not every footer link list needs it.
• main: The unique main content of the page. Keep only one visible main per page.
• article: Content that stands on its own, such as a blog post, a case study or a product card.
• section: A thematic block with its own heading. Without a heading, a div is usually enough.
• aside: Related but separable content, for instance a related posts box.
• footer: Copyright, contact and legal links.
• button and a: Use button for actions and a for navigation. Never ship a clickable div.

The last point matters most. Specifically, a clickable div cannot receive keyboard focus, and it does not announce itself as a button. A native button element gives you all of that for free.

What do native HTML form features give you?

Above all, forms are where a business website earns money, so native HTML features here touch conversion directly. For example, type="email" and type="tel" open the right keyboard on mobile. The autocomplete attribute lets the browser suggest saved details, which saves users from typing.

For validation, required, minlength and pattern cover simple checks without JavaScript. Still, never treat them as a replacement for server side validation. Browser checks only give users quick feedback.

Then there is the label question. Every field needs a visible label tied to it. A placeholder does not replace a label, because it disappears once the user starts typing. I cover lead form design in detail in my booking and quote form guide; the technical basics here make most of those ideas possible.

Modern HTML also ships components that once needed a library. You can use details and summary for FAQ accordions and dialog for modals. As a result, your code shrinks and keyboard behavior works out of the box.

Flexbox or Grid: which one should you choose, and when?

Above all, they are partners, not rivals. Put simply, Flexbox aligns content along one axis, either a row or a column. Grid builds a two dimensional layout that controls rows and columns together. The table below is the summary I use when deciding.

In practice, I nest them. The page and the card list use Grid, while the heading, tag and button inside each card use Flexbox. This split keeps the code readable, and each tool works where it is strongest.

How do you build a page skeleton with CSS Grid?

My favorite thing about Grid is responsive card lists without a single media query. For a services list, give the container display: grid; gap: 1.5rem; grid-template-columns: repeat(auto-fit, minmax(16rem, 1fr)); and you are done. The browser opens as many columns as fit, and each card stays at least 16rem wide.

For the page skeleton, grid-template-areas offers a very readable approach. You name areas such as header, sidebar, content and footer, then place them like a map. When you want one column on mobile and two on desktop, you only change that map. The HTML order stays the same.

One warning here. Do not fully detach visual order from HTML order with Grid. Screen reader and keyboard users follow the source order. If visual order and focus order disagree, you create confusion. Therefore, write content in a logical order first, then shape the layout with Grid.

Finally, a word on subgrid. When cards sit side by side with headings of different lengths, their buttons drift out of line. Subgrid ties the inner rows of each card to the parent grid and fixes this without JavaScript. All current major browsers support it.

Where does Flexbox really shine?

Flexbox wins in small components where content size should drive the layout. The main menu, for example, is the classic case. You line up links, add even spacing, keep the logo on the left and push the contact button to the right. Usually display: flex; align-items: center; gap: 1rem; plus margin-left: auto on the button does the job.

I also use it inside cards. Make the card a vertical flex container and give the description flex: 1. The button then always sticks to the bottom of the card, so text of different lengths no longer breaks the layout.

For tag clouds and filter chips that need to wrap, flex-wrap: wrap is a lifesaver. Items move to the next line when they run out of room, and you skip the media query entirely.

On the other hand, do not force Flexbox into two dimensional card lists. Stretched cards in the last row or drifting alignment usually come from picking the wrong tool. In those cases, switching to Grid calms both the code and your nerves.

How are container queries different from media queries?

A media query looks at the viewport. A container query looks at the width of the container that holds the component. That small difference opens a big door for component based design. The same product card can appear horizontal in a wide main area and vertical in a narrow sidebar, and it never needs to know the screen size.

In practice, the syntax stays simple. First, give the container container-type: inline-size. Then write the wide version of the card inside an @container (min-width: 30rem) block. Wherever you drop the card, it adapts to its own space. The MDN container queries guide shows the full syntax with examples.

Container query units also help. For example, the cqi unit refers to a percentage of the container's inline size. If you size a card heading with it, the heading scales with the card.

So are media queries going away? No. Page level decisions, such as when the menu switches to its mobile version, still belong to media queries. My rule is simple: page layout uses media queries, and reusable components use container queries. I explain the wider mobile mindset in my mobile first design article.

How do you build a design system with custom properties?

Custom properties, also called CSS variables, let you define color, spacing and type decisions in one place and reuse them across the site. For example, you define --color-primary: #0b5fff; on the root and write background: var(--color-primary); on buttons. When the brand color changes, you update a single line.

The difference from Sass variables is that CSS variables live in the browser. They can change at runtime, you can redefine them inside a section, and JavaScript can read them. For instance, if you reassign the text color variable inside a dark promo band, every component in that band adapts automatically.

I usually structure the system in three layers:

1. Raw values: Every palette color, the spacing scale and the type scale.
2. Semantic values: Role names such as primary, surface, text and error. Components only use these.
3. Component values: Local settings such as button padding or card corner radius.

This layering makes it easy to carry design tool decisions into code one to one. You can see how I set up variables and components on the design side in my Figma web design process article. For quick color conversions, try the HTML color codes tool.

What did the :has() selector change in CSS?

For years, developers waited for a "parent selector", and :has() finally delivered it. It lets you style an element based on what it contains. For example, .card:has(img) selects only cards with an image. You no longer need separate classes for cards with and without images.

It shines in forms. With .field:has(input:invalid) you can outline the whole wrapper of a field that holds invalid input. Likewise, a rule such as form:has(input[type=checkbox]:checked) can reveal the submit button once the user ticks a consent box. We used to write JavaScript for all of this.

It also helps at page level. For example, you can stop background scrolling while the mobile menu stays open by styling body whenever it contains an open menu. The MDN :has() reference lists current browser support and limitations.

One caution, though. Because :has() feels so powerful, it is tempting to use it everywhere. However, very broad and nested :has() rules can make style recalculation heavier on large pages. So I recommend scoping these selectors to a specific component whenever you can.

How do you handle dark mode and color with modern CSS?

You can read the user's system preference with the prefers-color-scheme media feature. If you redefine the semantic color variables inside that query, the whole site switches to dark mode with one block. This is where variable layering really pays off.

I also recommend adding color-scheme: light dark to the root element. That single line makes browser drawn elements such as form fields and scrollbars follow the theme. Otherwise, you may end up with a bright white input box in the middle of a dark page.

Newer color tools help as well. The color-mix() function blends two colors at a given ratio, so you can generate hover and disabled shades. As a result, you no longer need to define every state of the palette by hand.

That said, always measure contrast. In dark mode, gray text on a dark surface quickly becomes unreadable. Checking text and background contrast separately for each theme prevents accessibility complaints later.

How do you use clamp() for fluid type and spacing?

The clamp() function takes a minimum, a preferred value and a maximum. For a heading, you might write font-size: clamp(1.75rem, 1.2rem + 2.5vw, 3rem);. The heading never drops below 1.75rem on small screens, never exceeds 3rem on large ones, and scales smoothly in between.

Consequently, this removes the chore of setting a separate font size at every breakpoint. I apply the same logic to section spacing. Pages that feel compact on mobile and airy on desktop then emerge from a single clamp() rule.

One detail matters here: always include a relative unit such as rem in the preferred value. If you use vw alone, the heading ignores the user's browser zoom for text, and that hurts accessibility.

Also cap line length for readability. Giving the paragraph container a value such as max-inline-size: 65ch keeps long lines from tiring the eye. If you want to check the text itself, the readability checker can help.

How can you use new CSS features safely in older browsers?

My first stop is always Baseline. The web.dev Baseline initiative shows at a glance whether a feature works across the current versions of all major browsers. Grid, Flexbox, container queries and :has() now sit among the widely supported features.

Still, if part of your audience uses older devices, build a layered strategy. First, write a simple layout that works everywhere. Then place the enhanced behavior inside an @supports block. Browsers without support skip the block and show the simple layout, while modern browsers get the richer version.

For example, if you build a card layout with container queries, make the default a single column vertical card. Then move the wide layout into @supports (container-type: inline-size). Nobody sees a broken page; a few users simply get a plainer version.

When deciding, check the browser breakdown in your analytics. If nearly all visitors run current browsers, spending hours on fallbacks may be wasted effort. In short, your support strategy should rest on your own data, not on assumptions.

How do modern HTML and CSS affect accessibility?

Used well, they help; used badly, they hurt. Native elements and modern CSS give you much of accessibility for free. However, you still need to manage a few points on purpose. These are the checks I run on projects:

• Focus visibility: Use :focus-visible to show a clear focus ring to keyboard users without bothering mouse users.
• Motion preference: Use prefers-reduced-motion to tone down animation for people sensitive to motion.
• Visual order: When Grid or Flexbox changes visual order, test with the keyboard that focus order still makes sense.
• Hidden content: Content hidden with display: none likewise disappears for screen readers. Use a different technique if you only want to hide it visually.
• Contrast: Measure text contrast for every theme and every state, including hover, disabled and error.

Moreover, none of this requires a long audit. Simply putting the mouse aside and tabbing through the page reveals most problems. I run this five minute test before every launch.

How do modern HTML and CSS help page speed and SEO?

The least discussed benefit of modern CSS is that it reduces the need for JavaScript. We used to load separate libraries for accordions, tabs, modals, form highlighting and responsive card grids. Today, HTML and CSS handle most of these. Less JavaScript means less work on the browser's main thread, which especially helps interaction speed.

Also, dropping heavy CSS frameworks can cut a large amount of unused style code. Sending only the rules each page needs helps the first view paint sooner. I cover the search impact of speed in how site speed affects SEO, and the measurement steps in my Lighthouse performance test guide.

Then there are layout shifts. Giving images width and height attributes, or using the aspect-ratio property, stops the page from jumping while images load. This small detail improves both user experience and your scores.

For SEO, semantic structure, a clean heading hierarchy and tidy code help search engines interpret your page correctly. I collected the other technical topics in my technical SEO tips article.

How do CSS nesting and @layer organize your code?

Native CSS nesting used to require a preprocessor such as Sass. Current browsers now support it directly. For example, you can keep a card's heading, image and hover rules inside one block, so related rules no longer scatter across the file.

@layer, in turn, ends specificity wars. You place resets, base styles, components and utilities into separate layers. A later layer beats an earlier one, no matter how weak its selector looks. Consequently, a third party library cannot override your components by accident.

Still, do not overdo nesting. Going deeper than three levels creates selectors that read poorly and carry too much specificity. I usually stay at one level and only go to a second level for states and child elements.

What are the most common modern CSS mistakes?

Because new features feel exciting, some mistakes keep showing up. The most frequent ones are these:

• Trying to solve everything with Grid, even a simple button group.
• Defining custom properties with random names and no semantic layer. Soon nobody knows which variable does what.
• Writing a container query but forgetting to set container-type on the parent. The rules then never fire.
• Animating width, height or top, which triggers layout. Use transform and opacity instead.
• Silencing specificity problems with !important. Organizing styles with @layer scales much better.

What these mistakes share is that they solve today's problem and raise tomorrow's maintenance cost. In large projects with several teams, that cost grows fast. If you are curious how big organizations split their front end, read my micro frontends article.

Which checklist should you follow when a project starts?

When I start a new business website, I work through the front end in this order. The list greatly reduces the need to go back and fix things later.

1. Write the content as semantic HTML before design, and check the heading order.
2. Define color, spacing and type scales as custom properties in three layers.
3. Build the page skeleton with Grid and component internals with Flexbox.
4. Make reusable components respond to their own space with container queries.
5. Make type and section spacing fluid with clamp().
6. Before writing JavaScript, check whether details, dialog or :has() can do the job.
7. Decide from your audience data whether you need @supports fallbacks.
8. Run a keyboard test, a contrast check and a motion preference check.
9. Measure speed and layout shift again before launch.

The logic is simple: content and meaning first, then layout, then decoration. If you start from the other end, you get something that looks nice but is hard to move, translate and maintain.

Conclusion: where should you start with modern HTML and CSS?

In short, modern web design is less about flashy effects and more about using the platform's tools in the right place. Semantic HTML sets a solid foundation. Grid and Flexbox simplify layout, container queries make components independent, and custom properties plus :has() move former JavaScript jobs into CSS.

If you already have a site, you do not need to rewrite everything. First, pick the template with the most traffic, turn div soup into semantic elements and move colors into variables. Next, rebuild one component, such as the service card, with a container query. Even these small steps make maintenance noticeably easier.

If you are planning a new project or want a review of your current front end quality, take a look at my web design process and get in touch. Together we can pin down which techniques will truly add value to your project.