In HTML, how do data-* attribute names map onto keys of an element's dataset property, and what type do you get back when you read one?

## What dataset is `element.dataset` is a `DOMStringMap` — an object-like view over exactly those attributes on the element whose names start with `data-`. It is live: changing an attribute changes what `dataset` reports, and writing through `dataset` writes a real attribute back into the DOM that you can see in devtools. ```html <li id="row" data-item-id="42" data-item-count="5" data-status="open"></li> ``` ```js const el = document.getElementById("row"); el.dataset.itemId; // "42" el.dataset.itemCount; // "5" el.dataset.status; // "open" el.dataset.missing; // undefined ``` ## The name transformation, in both directions Attribute to key: remove the `data-` prefix, then for every `-` followed by an ASCII lowercase letter, delete the hyphen and uppercase the letter. So `data-item-id` becomes `itemId` and `data-a-b-c` becomes `aBC`. Key to attribute: the reverse. Every uppercase ASCII letter becomes a hyphen plus the lowercase letter, and `data-` is prefixed. Assigning `el.dataset.userName = "ada"` produces `data-user-name="ada"` in the markup — **not** `data-userName`. Two consequences catch people: - **Hyphenated keys are illegal.** `el.dataset["user-id"] = "7"` throws a `SyntaxError`, because the setter rejects any name containing a hyphen followed by a lowercase letter. Use the camelCase key, or drop to `setAttribute("data-user-id", "7")`. - **Source case is lost.** HTML attribute names are lowercased by the parser, so `data-userId` in your markup is really `data-userid`, which is `dataset.userid` — not `dataset.userId`. This is a frequent "why is it undefined" bug. ## Everything is a string `DOMStringMap` is named for exactly this reason. There is no type coercion anywhere in the pipeline: ```js el.dataset.itemCount + 1; // "51" (string concatenation) Number(el.dataset.itemCount) + 1; // 6 ``` The same applies to booleans. `data-active="false"` reads as `"false"`, and every non-empty string is truthy, so `if (el.dataset.active)` is true either way. Two safer patterns: compare explicitly (`el.dataset.active === "true"`), or use presence as the flag — write `data-active` with no value and test `el.hasAttribute("data-active")`. A valueless attribute reads back as the empty string `""`, which is falsy, so even a truthiness test happens to behave for that form. Structured data has the same problem: if you store JSON you must `JSON.parse` it on every read, and any parse failure is a runtime error in the middle of rendering. ## Writing and deleting ```js el.dataset.status = "closed"; // sets data-status="closed" delete el.dataset.status; // removes the attribute entirely ``` Setting a key to `null` or a number does not skip the string conversion — the value is stringified, so `el.dataset.count = 5` produces `data-count="5"`. ## dataset versus getAttribute `getAttribute("data-item-id")` and `dataset.itemId` read the same attribute; the difference is ergonomics and failure mode. `getAttribute` returns `null` for a missing attribute, `dataset` returns `undefined`, and `getAttribute` takes the literal attribute name so it sidesteps the camelCase rules entirely. When a name is computed at runtime, `setAttribute`/`getAttribute` with a template string is usually clearer than trying to build a camelCase key. ## Enumerating `dataset` is enumerable, so `Object.keys(el.dataset)` or `for...in` lists every data-* key on that element — useful when a component reads a bag of options off its own root element. Note that it reflects only that element's own attributes; there is no inheritance from ancestors.