Learning on Web Dev Open is free for all.

Take It Apart > HTML is a data structureThe tags models never reach for
Phase 01HTML is a data structure43 of 434

The tags models never reach for

details, dialog, datalist, output, progress, time, figure, fieldset. Elements that already do the job, which generated code almost never uses because the training data does not either.

Build22 minAI adversary

Run the trap first. Ask your model for an accordion, a modal dialog, and an input with suggestions. Save what it gives you. You will compare against it in a moment.

Now build each one natively. <details> and <summary> are an accordion with open and closed state, keyboard support and correct announcement, in two tags and no script. <dialog> with showModal() is a modal with a backdrop, focus trapping, escape-to-close and inertness of the page behind it, one method call. <input list> with a <datalist> is an autocomplete that works on every browser and needs no library.

Then the others, each of which replaces something people write by hand every week. <output> is a live region for a calculated result and announces changes without you configuring anything. <progress> and <meter> are a loading bar and a gauge, and they are different elements for a reason, one is a task completing, the other is a measurement within a range. <time datetime="2026-09-14"> is a machine-readable date. <figure> and <figcaption> bind a caption to an image so the relationship survives being read aloud. <fieldset> and <legend> group related inputs so a screen reader announces "Shipping address, street" rather than just "street".

Build a single page containing all eight, working, with no JavaScript beyond the one showModal() call. Then open it with a screen reader and confirm each one announces sensibly.

Now be honest about the limits, because this chapter is not "native elements always win". <details> cannot animate its open transition in every browser without work. <dialog> styling of the backdrop is a pseudo-element with its own quirks. <datalist> looks different on every platform and you cannot style the dropdown. For a design system with exacting visual requirements, some of these really will not do, and the right time to discover that is after you have used them, not instead of.

Write a short comparison in your repo: for each of the three widgets your model produced, the native version, the lines of code saved, and the one thing the native version cannot do. That document is the clearer version of this lesson and it is worth more than either extreme position.

Done when

  • A single page using details, dialog, datalist, output, progress, meter, time, figure and fieldset, all working
  • No JavaScript beyond opening the dialog
  • Each element checked with a screen reader and announcing sensibly
  • A written comparison against the model-generated versions, with lines saved
  • At least one honest note on where the native element is not good enough and why

Nobody marks this for you. It goes into your phase checkpoint, where a person does.

Build this in your own editor

This one runs on your machine rather than in the browser workbench. Work to the outcomes below, then come back and mark it complete.

You should now be able to

  • Replace a JavaScript widget with a native element
  • Judge when a native element is not enough
  • Explain why generated code under-uses these specifically
Ask the community

Loading…