HTML5 Editor
Use the HCODX HTML5 editor to test semantic markup, native form controls and browser features. Preview a working example and inspect the source.
Choose elements for what the content is
Semantic HTML makes a document easier to navigate, maintain and enhance.
A div is useful when no more meaningful element fits. But replacing every region with a div discards information already available in the platform. Landmarks help assistive technology jump through a page, and a sensible heading outline makes long content easier for everyone to scan.
HTML validity and accessibility are related but not identical. A page can pass a syntax check and still have confusing link text, missing form labels or poor keyboard behavior. Treat semantic elements as a foundation, then test the actual interaction.
One main region
Put the primary page content inside main, separate from repeated navigation.
Headings that describe
Use headings to name sections, not merely to make text large.
Native controls
Use button, input and label before building custom equivalents.
An article with a real form control
The browser understands this structure even before you write a line of CSS.
The form input uses type=email and required, so the browser provides basic format and empty-field feedback. That is helpful client-side behavior, not a substitute for server-side validation if you later submit or store data.
Notice that the article heading is inside its header, while the page navigation sits outside main. This keeps the reading order clear. Add styling after the document makes sense when read top to bottom.
<!doctype html>
<html lang="en">
<head><meta charset="utf-8"><title>Field notes</title></head>
<body>
<header><nav aria-label="Primary"><a href="/">Home</a></nav></header>
<main>
<article>
<header><h1>Field notes</h1><p>One clear subject.</p></header>
<section aria-labelledby="updates"><h2 id="updates">Get updates</h2>
<form><label for="email">Email</label><input id="email" type="email" required>
<button type="submit">Subscribe</button></form>
</section>
</article>
</main>
<footer><small>Example page</small></footer>
</body></html>A semantic page review that catches visual blind spots
A modern element is only useful when it matches the content and the interaction works with a keyboard.
Read the document without CSS
Check whether the heading order, paragraph sequence and navigation still make sense. Styling can disguise a confusing source order but cannot repair its meaning.
Inspect landmark names
A page normally has one main region. If there are multiple nav elements, give them distinct accessible labels such as Primary and Footer so readers can tell them apart.
Try native controls
Tab to each input and button. Activate the label, submit an empty required field and observe the browser’s feedback before adding custom validation.
Check the actual runtime
A form that validates in a preview still needs a destination to process data. Device APIs can require secure contexts, permissions or iframe allowances. Test those in the deployment environment.
Semantic HTML is a strong starting point, not a substitute for an accessibility test with real keyboard and assistive-technology workflows.
Offer a share action only when the browser can try it
Modern browser APIs are capabilities with conditions, not features you can assume every visitor has.
The button below uses a real user action and checks for navigator.share before calling it. If the API is unavailable, the button explains that the visitor can copy the URL instead. This is progressive enhancement: the article remains readable even when the extra browser capability is missing.
Feature detection is not a guarantee. A present API may still reject because of user choice, browser policy, secure-context requirements or iframe restrictions. Test the fallback and the rejection path; do not mark a page broken merely because a preview frame cannot open a device-level sharing dialog. In this editor, location.href belongs to the preview frame, so replace it with the published page URL when this example is deployed.
<button id="share" type="button">Share this page</button>
<p id="share-status" role="status"></p>
<script>
const button = document.querySelector("#share");
const status = document.querySelector("#share-status");
button.addEventListener("click", async () => {
if (!navigator.share) {
status.textContent = "Copy the page URL to share it.";
return;
}
try {
await navigator.share({ title: document.title, url: location.href });
} catch {
status.textContent = "Sharing was cancelled or unavailable.";
}
});
</script>HTML5 is a platform, not a build target
Many features are native to the browser; some are restricted by permissions or require a server.
Forms and constraints
Input types, labels and required fields can be tested in the browser. Persisting a submission is a separate server task.
Media and graphics
Video, audio, SVG and canvas can render in the preview when their resources are available and browser policies allow them.
Storage
Client-side storage is tied to an origin and browser profile. It is not automatically a cross-device database.
Device APIs
Camera, location and other sensitive APIs require permission and may be restricted by HTTPS, browser settings or the preview frame.
Before publishing a modern page
Start with the document, then style it
Build one semantic article and test its native controls before adding a visual layer.
Instant HTML Runner & Viewer with Live Preview
Need to run a short HTML, CSS and JavaScript snippet? The HTML Runner Online has a focused editing surface with live output.
Open HTML Runner Online