Opens in a new tab

HTML & CSS

HTML and CSS are the foundation of nearly every web interface I build.

I use HTML to define structure and meaning, and CSS to control layout, presentation, responsiveness and visual systems.

Even when I work with WordPress, Bricks Builder, JavaScript frameworks or application-style interfaces, HTML and CSS remain underneath everything.

For me, they are not “basic frontend technologies”.

They are the layer that determines whether a website is structurally correct, accessible, responsive, maintainable and fast.

How I use HTML and CSS

I use HTML and CSS for tasks such as:

  • complete website layouts,
  • responsive interfaces,
  • design systems,
  • component styling,
  • WordPress templates,
  • Bricks Builder customization,
  • application interfaces,
  • forms,
  • dashboards,
  • content-heavy websites,
  • interactive tools,
  • accessibility,
  • performance optimization.

I prefer using native web-platform capabilities before adding unnecessary frameworks or JavaScript.

Semantic HTML

I use semantic HTML whenever the content has a meaningful structure.

That includes elements such as:

  • header,
  • nav,
  • main,
  • section,
  • article,
  • aside,
  • footer,
  • headings,
  • lists,
  • forms,
  • buttons,
  • links.

The goal is not merely to make the page look correct.

The document should also make sense structurally.

Semantic markup improves:

  • accessibility,
  • search-engine understanding,
  • maintainability,
  • interoperability with browsers and assistive technologies.

Document Structure

A page should have a clear hierarchy.

I pay attention to:

  • logical heading order,
  • meaningful page regions,
  • appropriate navigation structure,
  • clear content grouping.

I avoid using arbitrary containers when a more meaningful HTML element exists.

The visual hierarchy and document hierarchy should support each other.

Headings

Headings are structural elements, not styling shortcuts.

I use them to represent the hierarchy of the document.

For example:

H1
→ Page topic

H2
→ Major section

H3
→ Subsection

I avoid selecting heading levels purely because one happens to have a desirable font size.

Typography belongs in CSS.

Document meaning belongs in HTML.

Buttons and Links

I distinguish between navigation and actions.

A link is for moving somewhere.

A button is for doing something.

I avoid using clickable div elements where a native interactive element already exists.

Correct elements provide useful behavior automatically, including:

  • keyboard interaction,
  • focus handling,
  • semantics.

This reduces the amount of custom accessibility work required.

Forms

Forms are one of the areas where correct HTML matters most.

I use:

  • proper labels,
  • appropriate input types,
  • required-state semantics,
  • descriptive validation messages,
  • logical grouping.

A visual placeholder is not a replacement for a real label.

I design forms so they remain understandable for keyboard and assistive-technology users.

Input Types

I use the most appropriate native input type where possible.

Examples include:

email
url
number
date
tel

Correct input types can improve validation and mobile keyboard behavior.

Native browser functionality is often more reliable than recreating basic input behavior manually.

Accessibility

Accessibility begins with markup and layout architecture.

I consider:

  • semantic elements,
  • keyboard accessibility,
  • focus visibility,
  • readable contrast,
  • touch targets,
  • scalable typography,
  • screen-reader semantics.

I prefer solving accessibility structurally rather than adding large amounts of ARIA to compensate for incorrect HTML.

Native semantics should be used wherever possible.

ARIA

ARIA is useful when native HTML cannot fully express the required behavior.

I use it carefully.

ARIA should enhance semantics, not replace correct HTML unnecessarily.

For complex custom controls, I consider:

  • roles,
  • labels,
  • expanded state,
  • selected state,
  • live regions.

If a native HTML element already provides the required semantics, I usually prefer the native element.

CSS

I use CSS as a layout and design-system language rather than a collection of isolated visual overrides.

A maintainable stylesheet should express consistent rules for:

  • typography,
  • spacing,
  • layout,
  • color,
  • responsive behavior,
  • component states.

I prefer reusable systems over one-off declarations repeated across individual pages.

Modern CSS

Modern CSS can solve many problems that previously required substantial JavaScript or external frameworks.

I use features such as:

  • Flexbox,
  • Grid,
  • custom properties,
  • clamp(),
  • logical properties,
  • media queries,
  • modern selectors.

I prefer using the browser’s native layout engine instead of adding complexity where CSS already provides the solution.

Flexbox

I use Flexbox for layouts where elements primarily need to align along one axis.

Typical use cases include:

  • navigation,
  • button groups,
  • card rows,
  • header layouts,
  • alignment inside components.

It is particularly useful when content dimensions are dynamic.

I avoid using manual margins and positioning when Flexbox can describe the intended relationship directly.

CSS Grid

I use CSS Grid for layouts with stronger two-dimensional structure.

Examples include:

  • card collections,
  • dashboards,
  • content grids,
  • complex page sections.

Grid allows the structure to be expressed explicitly rather than simulated with nested containers.

A typical responsive grid can adapt automatically as available width changes.

Grid and Flexbox Together

I do not treat Grid and Flexbox as competing technologies.

They solve different problems.

A page may use Grid for its overall structure and Flexbox inside individual components.

Choosing the correct layout model usually results in simpler CSS.

Responsive Design

I build layouts that respond to available space rather than one fixed device size.

I consider:

  • narrow phones,
  • larger phones,
  • tablets,
  • desktop screens,
  • zoom,
  • font scaling.

The goal is not simply to add a few breakpoints.

The interface should remain usable as its environment changes.

Mobile-First Design

Where practical, I begin with the essential layout and progressively enhance it for larger screens.

This can produce simpler CSS and helps ensure the mobile experience remains intentional.

I still choose the approach according to the actual project.

The important part is that mobile behavior is designed, not treated as an afterthought.

Fluid Layouts

I prefer flexible sizing where appropriate.

Instead of relying entirely on fixed pixel widths, I use combinations of:

  • percentages,
  • min(),
  • max(),
  • clamp(),
  • flexible grid tracks.

This allows layouts to adapt smoothly rather than changing only at a handful of arbitrary breakpoints.

Fluid Typography

Modern CSS can scale typography between sensible minimum and maximum sizes.

For example:

font-size: clamp(1.8rem, 4vw, 3.5rem);

This can produce more natural scaling across different viewport sizes.

I still make sure the result remains readable and predictable.

Container Widths

Readable content should not simply stretch across an entire large monitor.

I use appropriate maximum widths for:

  • text,
  • forms,
  • application panels,
  • full-width sections.

Different types of content can require different width constraints.

Long-form text, for example, benefits from more controlled line length than a data dashboard.

CSS Custom Properties

I use CSS custom properties to create shared design values.

For example:

:root {
    --space-sm: 0.75rem;
    --space-md: 1.5rem;
    --space-lg: 3rem;
    --radius-card: 1rem;
}

These variables can represent:

  • colors,
  • spacing,
  • typography,
  • radii,
  • dimensions.

This makes a design system easier to change globally.

Design Tokens

For larger projects, I think in terms of design tokens rather than isolated style values.

A token represents a deliberate design decision.

Examples include:

primary text color
surface color
small spacing
large spacing
card radius
heading scale

Components then consume these shared decisions.

This produces a much more coherent interface.

Typography

Typography is one of the main structural tools in an interface.

I consider:

  • font size,
  • line height,
  • weight,
  • line length,
  • hierarchy,
  • spacing.

I avoid defining typography independently for every individual element.

A consistent type scale makes both the design and the CSS easier to maintain.

Line Height

Readable text needs appropriate line spacing.

I avoid excessively tight line heights for body content.

At the same time, large headings may benefit from tighter spacing.

Typography should reflect the type of content rather than one universal value.

Color Systems

I define semantic colors rather than using arbitrary values throughout the stylesheet.

For example:

text-primary
text-muted
surface
surface-raised
accent
error

This makes the interface easier to theme and change later.

The meaning of a color is more useful than its hexadecimal value.

Dark Mode

Where appropriate, I design color systems that can support both light and dark themes.

Using semantic variables makes this much easier.

Components should not depend on assumptions such as:

background is always white
text is always black

They should consume theme-level values.

CSS Architecture

As a project grows, stylesheet organization becomes important.

I prefer clear separation between:

  • global foundations,
  • layout,
  • components,
  • utilities,
  • page-specific exceptions.

I avoid allowing the stylesheet to become an accumulation of increasingly specific overrides.

Good CSS architecture reduces the need for !important and selector escalation.

Specificity

CSS specificity should remain predictable.

I prefer reusable classes over deeply nested selectors such as:

.page .section .card .content span

Overly specific selectors make later changes difficult.

A component should usually be styleable through a clear and relatively shallow selector.

Avoiding !important

I use !important only where there is a clear reason.

Frequent reliance on it usually indicates a specificity or architecture problem.

It can make future overrides harder and hide the actual structure of the stylesheet.

Component Styling

I build styles around reusable components.

For example:

.card
.card__title
.card__content
.card--featured

The exact naming strategy can differ between projects.

The important principle is that the component has a clear boundary and predictable variants.

Utility Classes

Small utility classes can be useful for common layout behavior.

Examples may include:

  • visually hidden text,
  • spacing helpers,
  • alignment utilities.

I keep the utility layer controlled.

If every visual property becomes its own utility without a coherent system, the HTML can become difficult to read.

CSS Nesting

Where supported and appropriate, modern CSS nesting can make related selectors easier to organize.

I still avoid deeply nested structures.

Nesting should improve readability, not recreate the problems of highly specific selector chains.

Logical Properties

Logical CSS properties can make layouts more adaptable to writing direction.

Instead of thinking only in terms of physical left and right, modern CSS can express:

  • inline start,
  • inline end,
  • block start,
  • block end.

This is useful when interfaces may need broader localization support.

Internationalization

Different languages can significantly affect layout.

Translated text may be:

  • longer,
  • shorter,
  • written in a different direction,
  • rendered using different scripts.

I avoid designing components that only work for one exact English label length.

Layouts should tolerate realistic content variation.

Images

HTML image markup affects both usability and performance.

I consider:

  • meaningful alt text,
  • intrinsic dimensions,
  • responsive image sources,
  • lazy loading where appropriate.

The browser should know enough about an image to reserve layout space and select an appropriate resource.

Responsive Images

Different devices do not always need the same image resolution.

I use responsive image mechanisms where appropriate so the browser can select a suitable asset.

This can reduce unnecessary transfer size, particularly on mobile devices.

Aspect Ratio

I use CSS aspect-ratio where useful to reserve predictable media space.

This can help reduce layout shifts while content is loading.

It also makes responsive image and video containers easier to manage.

Performance

HTML and CSS directly affect frontend performance.

I pay attention to:

  • DOM size,
  • stylesheet complexity,
  • unused CSS,
  • image delivery,
  • web fonts,
  • layout shifts.

Adding more markup is not free.

A deeply nested DOM can make both styling and browser rendering more expensive.

DOM Complexity

Page builders can make it easy to create unnecessary wrappers.

I try to keep markup as shallow as the layout allows.

Instead of:

container
→ container
→ container
→ container
→ content

I prefer using only the structure that has an actual purpose.

Cleaner markup is easier to inspect, style and maintain.

Layout Stability

Pages should not move dramatically while loading.

I reduce layout shifts by defining predictable dimensions for content such as:

  • images,
  • embeds,
  • dynamic sections.

A stable page feels significantly more polished than one where buttons and text continually move during loading.

Web Fonts

Fonts can have a substantial impact on page loading.

I consider:

  • how many font families are required,
  • how many weights are actually used,
  • fallback fonts,
  • loading behavior.

A design does not automatically become better because it downloads many font files.

Performance and visual quality need to be balanced.

Native CSS Before JavaScript

Many interface behaviors can now be implemented with CSS.

Where appropriate, I prefer CSS for:

  • layout,
  • transitions,
  • responsive behavior,
  • simple states.

JavaScript should be introduced when actual application logic or interaction requires it.

Reducing unnecessary JavaScript usually makes interfaces more robust.

Transitions

I use CSS transitions for subtle interaction feedback.

Examples include:

  • hover states,
  • focus changes,
  • expanding visual states,
  • button feedback.

Transitions should reinforce interaction.

I avoid adding animation to every property or making interfaces feel unnecessarily slow.

Motion Preferences

Some users prefer reduced motion.

Where substantial animation is used, I consider the user’s reduced-motion preference.

An interface should remain understandable without relying on animation.

Hover States

Hover is useful on pointer-based devices but should not be required for essential functionality.

Touch devices do not provide the same interaction model.

I design components so important actions remain accessible without hover.

Focus States

Keyboard users need visible focus indication.

I avoid globally removing focus outlines without providing an accessible replacement.

A focus state should be clearly visible and consistent with the visual system.

Pseudo-Classes

Modern pseudo-classes provide powerful styling possibilities.

I use them for state such as:

  • hover,
  • focus,
  • checked,
  • disabled,
  • validation.

This keeps visual state connected directly to semantic browser state where possible.

Native Form States

Browser form controls already expose useful states.

I use CSS to communicate:

  • focus,
  • invalid input,
  • disabled state,
  • checked state.

I prefer enhancing native behavior rather than replacing every form control with a custom implementation unnecessarily.

CSS Grid for Application Interfaces

Grid is particularly useful for application-style layouts containing:

  • sidebars,
  • toolbars,
  • content areas,
  • data panels.

These layouts can adapt from multi-column desktop structures to simpler mobile views without changing the underlying HTML significantly.

Sticky Positioning

I use sticky positioning where it genuinely improves usability.

Examples may include:

  • navigation,
  • table headers,
  • contextual controls.

I avoid making too many interface elements sticky, especially on small screens where they can consume valuable viewport space.

Overflow

Scrollable content needs deliberate overflow handling.

I pay attention to areas such as:

  • tables,
  • code blocks,
  • horizontal collections,
  • dialogs.

An element unexpectedly overflowing the viewport is a common source of mobile layout problems.

Tables

For genuine tabular data, I use HTML tables.

I do not replace semantic tables with arbitrary grid layouts simply to achieve a particular visual appearance.

For narrow screens, I design an appropriate responsive strategy rather than destroying the relationship between headers and data.

Content-First Layout

I prefer letting real content influence layout decisions.

A design that only works with perfect placeholder text often fails once real content is entered.

I test interfaces with:

  • short text,
  • long text,
  • missing optional content,
  • translated labels.

Robust layouts should tolerate all of these conditions.

WordPress

HTML and CSS remain fundamental when I work with WordPress.

Themes and builders eventually produce HTML that the browser renders.

Understanding that generated output allows me to:

  • diagnose layout problems,
  • improve semantics,
  • optimize responsiveness,
  • reduce unnecessary markup.

I do not treat WordPress as a black box.

Bricks Builder

I use Bricks Builder as a visual development layer while still working directly with HTML and CSS concepts.

I use:

  • semantic elements,
  • global classes,
  • CSS Grid,
  • Flexbox,
  • custom properties,
  • custom CSS.

The visual editor accelerates development, but the underlying browser technologies still determine the result.

Advanced Custom Fields

ACF controls structured content.

HTML and CSS determine how that content is presented.

A dynamic field may contain:

  • text,
  • image,
  • metadata,
  • relationships.

The template still needs correct markup and layout for that data.

WooCommerce

WooCommerce interfaces require careful HTML and CSS because commerce workflows need to remain usable and accessible.

I pay attention to:

  • product layouts,
  • variation controls,
  • cart actions,
  • forms,
  • checkout,
  • validation.

Visual customization should not make the transaction flow harder to use.

JavaScript

HTML, CSS and JavaScript have different responsibilities.

I generally think of them as:

HTML
→ structure and meaning

CSS
→ presentation and layout

JavaScript
→ behavior and application logic

Real projects naturally have overlap, but keeping these responsibilities conceptually separate leads to cleaner interfaces.

Browser APIs

When I build browser applications, HTML and CSS provide the interface around functionality powered by APIs such as:

  • File API,
  • Canvas,
  • Web Workers,
  • WebAssembly,
  • Web Audio.

Even technically complex applications still need a clear and usable frontend.

Progressive Enhancement

Where appropriate, I build interfaces so their basic structure remains useful before advanced JavaScript functionality is added.

This can improve:

  • resilience,
  • accessibility,
  • compatibility.

Not every application can function fully without JavaScript, but its HTML should still represent the interface meaningfully.

SEO

HTML structure is directly relevant to search-engine understanding.

I pay attention to:

  • meaningful titles,
  • heading hierarchy,
  • semantic content,
  • internal links,
  • image alternatives.

I avoid using visual presentation as a substitute for structural meaning.

Search engines consume the document structure, not the design file.

Crawlability

Important content should be represented in a form that can be understood reliably.

For content-heavy websites, I avoid unnecessary architectures that hide essential content behind fragile client-side behavior without a real technical reason.

The implementation should support both users and automated systems consuming the site.

Maintainability

The best HTML and CSS are not the most complicated.

I prefer implementations where another developer can understand:

  • the document structure,
  • the layout model,
  • the component hierarchy,
  • the design variables.

A design system should make future changes easier rather than forcing developers to trace hundreds of isolated overrides.

Browser Compatibility

Modern browsers support an increasingly capable web platform.

I use modern CSS features when they are appropriate for the target audience.

For newer functionality, I consider:

  • browser support,
  • graceful fallback,
  • whether the feature is genuinely required.

I avoid unnecessary compatibility hacks for obsolete environments unless the project specifically requires them.

Debugging

Browser developer tools are central to my HTML and CSS workflow.

I use them to inspect:

  • DOM structure,
  • computed styles,
  • inherited properties,
  • layout dimensions,
  • Grid and Flexbox behavior,
  • responsive breakpoints.

I prefer identifying the actual cause of a layout problem rather than adding random overrides until the problem disappears.

Avoiding CSS Patchwork

A stylesheet can gradually become a chain of patches:

original rule
→ override
→ mobile override
→ later override
→ !important

I try to avoid this pattern.

When the underlying component is wrong, I prefer fixing the structure or original rule instead of endlessly adding exceptions.

HTML & CSS in My Technology Stack

I commonly use HTML and CSS alongside technologies such as:

  • JavaScript,
  • TypeScript,
  • WordPress,
  • Bricks Builder,
  • Advanced Custom Fields,
  • WooCommerce,
  • PHP,
  • REST APIs,
  • browser APIs,
  • Three.js.

They provide the structural and visual foundation underneath these higher-level technologies.

Why I Use HTML & CSS Directly

I use frameworks, CMS platforms and visual development tools when they improve productivity.

But I still rely on HTML and CSS knowledge underneath them.

That matters because eventually every web interface becomes:

HTML
+
CSS
+
browser behavior

Understanding that layer gives me control over semantics, accessibility, performance, responsiveness and maintainability.

It also means I am not dependent on a builder or framework to solve every frontend problem.

HTML provides the structure.

CSS provides the visual system.

Everything else builds on top of them.

That is why I consider HTML and CSS fundamental engineering tools in my web development stack rather than introductory technologies that become irrelevant once higher-level tools are introduced.

Back to main page