DEV Community: Kai Mercer

One number, three roundings: toFixed, Math.round and Intl.NumberFormat disagree on 1.005

Kai Mercer — Fri, 30 Oct 2026 23:05:26 +0000

Round 1.005 to two decimals and you can get 1.00, 1.01 or 1 depending on which JavaScript tool you reach for. I ran the common options in Node v22.23.4 (V8) on a set of "half-cent" values and compared them with the exact stored value of each number.

Setup

For each value: toFixed(2), Math.round(v * 100) / 100, Intl.NumberFormat("en-US", {minimumFractionDigits: 2, maximumFractionDigits: 2}) with the default rounding, the same with roundingMode: "halfEven", and v.toPrecision(20) to see what the double really holds.

Value	exact stored value	toFixed(2)	Math.round(v*100)/100	Intl default	Intl halfEven
1.005	1.00499999999999989	1.00	1	1.01	1.00
2.675	2.67499999999999982	2.67	2.68	2.68	2.68
8.345	8.34500000000000064	8.35	8.35	8.35	8.34
1.255	1.25499999999999989	1.25	1.25	1.26	1.26
0.615	0.61499999999999999	0.61	0.62	0.62	0.62
10.235	10.23499999999999943	10.23	10.24	10.24	10.24
-1.005	-1.00499999999999989	-1.00	-1	-1.01	-1.00

What I see

The three methods disagree on the same input. For 1.005, toFixed follows the stored value (just under 1.005) and gives 1.00. Math.round(v * 100) gives 1 because 1.005 * 100 is 100.49999999999999. Intl.NumberFormat gave 1.01, which is what a person expects, even though the stored value is below the half. I did not look into why. I only report that it differs from toFixed.

Math.round is not the same as the others either. For 2.675 and 0.615 it rounds up while toFixed rounds down, because the multiplication v * 100 lands on a different double than the one you started with.

Rounding mode changes the answer even when the number is exact. 8.345 is stored just above the half, so halfEven gave 8.34 while default gave 8.35. The whole numbers show it more clearly: Math.round(2.5) is 3 and halfEven gives 2. Math.round(-0.5) returns -0, while Intl default gave -1.

MDN documents the rest: toFixed can look wrong because decimal fractions are not exact in floating point, and Intl.NumberFormat rounds half away from zero by default (halfExpand), with halfEven and other modes available through roundingMode.

What I would do for money

Keep amounts as integer cents, and round once, at the end, with a rule you write down.
Pick the rule on purpose: half away from zero (what most people expect) or half even (what some ledgers use).
Use Intl.NumberFormat for display only. Do not parse its output back into a number to do maths.
Add test rows for 1.005, 2.675 and a negative value. They are the ones that split the methods.

Not tested

Browsers (Node only), other locales, currencies with different digit counts, and any money library. Check your target runtime, since roundingMode needs a recent engine.

What JSON.parse does to a 20-digit integer, and how to keep the digits

Kai Mercer — Thu, 29 Oct 2026 23:05:03 +0000

If an API sends you 12345678901234567890 as a JSON number, what does JSON.parse give you? I ran a few cases in Node v22.23.4 (V8) to see exactly where the digits go, and what the newer context.source and JSON.rawJSON options do about it.

What parse and stringify do to big integers

const s = '{"id":12345678901234567890,"small":9007199254740993,"safe":9007199254740991,"price":0.1,"f":1.0}';
const o = JSON.parse(s);

Field in the JSON text	After `JSON.parse`	`Number.isSafeInteger`
`12345678901234567890`	`12345678901234567000`	false
`9007199254740993` (2^53 + 1)	`9007199254740992`	false
`9007199254740991` (2^53 - 1)	`9007199254740991`	true
`1.0`	`1` after a round trip	n/a

9007199254740992 === 9007199254740993 is true in the same run, so two different ids can collapse into one. Nothing throws and nothing warns. The value is just a different number, and JSON.stringify(o) writes the changed digits back out.

Reading the original digits: reviver `context.source`

The reviver gets a third argument. For primitives it has a source field with the original text. I used it to turn unsafe integers into BigInt:

const r = JSON.parse(s, (k, v, ctx) =>
  typeof v === "number" && !Number.isSafeInteger(v) && Number.isInteger(v)
    ? BigInt(ctx.source) : v);

Result in Node 22: id is a bigint printing 12345678901234567890, small is a bigint printing 9007199254740993, and price stays the number 0.1. The digits survive.

Writing them back: two traps

JSON.stringify(r) on that object throws TypeError: Do not know how to serialize a BigInt.
JSON.rawJSON("12345678901234567890") is how you write an exact number literal. JSON.stringify({ id: JSON.rawJSON("12345678901234567890") }) gave {"id":12345678901234567890}.

MDN documents both: context.source on the JSON.parse page, and JSON.rawJSON() as "Baseline 2025, newly available". MDN's own note on the reviver says it runs after the value is parsed, so a plain reviver value has already lost precision. That matches what I saw.

What I would do

If an id is a big integer, ask the API to send it as a string. This works everywhere.
If you cannot change the API, read it with context.source on a runtime that has it, and keep it as a string or BigInt, not a number.
Do not do arithmetic on ids. Compare them as strings.
Add a test with 9007199254740993. It is the smallest value that fails.

Not tested

Browsers (I ran Node only), older runtimes without context.source or rawJSON, other JSON libraries, and large decimals like 0.1000000000000000055511151231257827. Check your own target runtime before relying on the reviver option.

Days between dates in America/Los_Angeles: when one day becomes zero

Kai Mercer — Wed, 28 Oct 2026 23:04:46 +0000

A reader suggested running my days-between-dates check with a timezone behind UTC, such as America/Los_Angeles. I had only tested the calculator logic in one zone. So here is the same small test run under three zones, with the results as they came out.

Setup: Node v22 (V8, the engine behind Chrome), run as TZ=<zone> node test.js. Not a browser, and no UI. I used US daylight saving dates: clocks went forward on March 8, 2026 and back on November 1, 2026. Three ways to get days between two YYYY-MM-DD strings:

const ms = 86400000;
// 1. parse the strings directly
(new Date(b) - new Date(a)) / ms;
// 2. build local midnight from the parts
const local = s => { const [y,m,d] = s.split("-").map(Number); return new Date(y, m-1, d); };
(local(b) - local(a)) / ms;
// 3. build UTC midnight from the parts
const utc = s => { const [y,m,d] = s.split("-").map(Number); return Date.UTC(y, m-1, d); };
(utc(b) - utc(a)) / ms;

Results

Mar 7 to Mar 9, 2026 (expected 2):

Method	UTC	America/Los_Angeles	Australia/Adelaide
1. parse strings	2	2	2
2. local midnight	2	1.9583	2
3. UTC parts	2	2	2

Mar 8 to Mar 9, 2026 (expected 1), method 2 only: UTC 1, Los Angeles 0.9583, Adelaide 1. Nov 1 to Nov 2, 2026 (expected 1), method 2 in Los Angeles: 1.0417.

So local midnight is the one that breaks. A 23-hour day gives 0.9583, and Math.floor turns that into 0: one day apart reported as zero days. Math.round would hide it.

A second trap: parsing a date-only string

new Date("2026-03-08") is read as UTC midnight. In Los Angeles that prints as Sat Mar 07 2026 16:00 local, and .getDate() returns 7, not 8. In UTC and Adelaide it returns 8. If you parse a date-only string and then read local parts to display it, the day shifts for anyone behind UTC. new Date("2026-03-08T00:00") (no zone suffix) is local time and returned 8 in all three.

What I would do

For whole days between calendar dates, use method 3. It never touches local time, so DST cannot move it.
Do not floor a millisecond difference of local dates. If you must, Math.round it, and know why.
If you display a parsed date-only string, format it in UTC or build it from parts.

Not tested

Browsers other than the V8 runtime above, Safari's date parsing, zones that skip a whole day, and any specific calculator's source. This is about the arithmetic, not a particular app.

Typed vs set from script: a number input gives different answers

Kai Mercer — Wed, 28 Oct 2026 03:14:42 +0000

Last time I tested what a number input accepts. A reader asked for a cleaner split: what happens when the value is typed, versus set from script? This is that test, in one browser.

Setup: Chrome 155, a plain <input type="number" step="any">. "Typed" means per-character key events sent by a browser automation tool, which is not the same as a person on a keyboard. "Set" means input.value = "..." from script. For each case I read four properties: value, valueAsNumber, validity.badInput and checkValidity().

String	Typed	Set from script
`1e3`	"1e3", 1000, badInput false, valid	same
`.5`	".5", 0.5, false, valid	same
`abc`	"", null, false, valid	same
`1e`	"", null, badInput true, invalid	"", null, false, valid
`-`	"", null, true, invalid	"", null, false, valid
`1e400`	"", null, true, invalid	"", null, false, valid
`1,5`	"15", 15, false, valid	"", null, false, valid
`+5`	"5", 5, false, valid	"", null, false, valid
`5.`	"5", 5, false, valid	"", null, false, valid
`0x10`	"010", 10, false, valid	"", null, false, valid

What stands out

An empty value can mean two things. Typed 1e and set 1e both leave value as an empty string. Only the typed one sets badInput and fails checkValidity(). If your code only checks value === "", it cannot tell "the user typed nothing" from "the user typed something the control could not parse".

Setting from script skips the typing filter. When keys are typed, the browser dropped the comma in 1,5 and the x in 0x10, so the field ended up holding 15 and 010. A scripted value just rejects the whole string. A test that sets values from script will not show you what a typist ends up with.

Typed abc was valid and empty. The letters never entered the field, so there was nothing to flag.

What I would do with this

Check validity.badInput as well as value when you need to tell empty from unparseable.
If you write tests, type the input through your test runner instead of assigning value, at least for the cases you care about.
Keep the control's parsing separate from your own business rule. 1e3 is a valid number to the control, and you may not want it in an order quantity field.

Not tested

Firefox and Safari, mobile keyboards, real human typing, pasted text, and locale settings. The typed column comes from automation key events, so treat it as a lead to check in your own browsers.

Related: the first test, What an input type=number really accepts.

What an input type=number really accepts: a quick test

Kai Mercer — Mon, 26 Oct 2026 23:06:35 +0000

<input type="number"> looks like it only takes numbers. In practice it takes some strings you might not expect and silently drops others. I ran the cases below in Chrome 155 in a scratch input, and checked the rules against the HTML spec and MDN.

What I set, and what came back

const i = document.createElement("input");
i.type = "number";
i.value = "1e3";   // i.value: "1e3"  valueAsNumber: 1000

Value set	`value` afterwards	`valueAsNumber`
`"12"`	`"12"`	12
`"-5"`	`"-5"`	-5
`"1.5"`	`"1.5"`	1.5
`"1e3"`	`"1e3"`	1000
`"abc"`	`""`	NaN
`"1,5"`	`""`	NaN
`" 7"` (leading space)	`""`	NaN
`"0x10"`	`""`	NaN
`"1e"`	`""`	NaN

Two things stand out. First, "1e3" is accepted and stays as typed, so a field that someone fills by hand can hold exponent notation. Second, a comma decimal like "1,5" is not a number to this property. It becomes an empty string with no error.

I also set maxLength = 3 and then value = "123456". The value stayed "123456". The spec's table of which attributes apply to which input type lists maxlength for text, search, telephone, URL, email and password inputs, and not for number. If you need a length limit on digits, use min and max for the range, or a text input with inputmode="numeric" and your own check.

For step, I set step="0.01" and tried 0.1 (valid) and 0.105 (validity.stepMismatch was true).

Why this bites in forms

Reading input.value gives you a string, and it is "" both when the box is empty and when the user typed something the browser rejected. You cannot tell the two apart from value alone.
MDN also notes that number inputs are a poor fit for things that are only made of digits, such as postal codes or card numbers, because they are not really numbers. A leading zero is a good example of what you lose.

A cheap test list

Type 1e3 and check what your code does with "1e3".
Type 1,5 and see whether your form shows an error or just treats the field as empty.
Set a leading space or paste 0x10.
Check validity.badInput on a value the user typed, not one set from script. I only tested script-set values here, so I can't say how real typing behaves across browsers.
Try a value that fails step.

What do you do when a number field comes back empty?htmlwebdev

Split a bill three ways without losing a cent

Kai Mercer — Sun, 25 Oct 2026 23:07:27 +0000

Split a $103.25 bill three ways and the obvious code gives you a total that is a cent off. Here is the bug and a fix that is a few lines long. I ran every snippet in Node 22.

The bug

const each = Number((103.25 / 3).toFixed(2)); // 34.42
console.log((each * 3).toFixed(2));            // "103.26"

103.25 / 3 is 34.41666..., which rounds to 34.42. Three of those is $103.26, one cent more than the bill. Round the other way and you are a cent short on other amounts. Either way, the parts do not add up to the whole.

The fix: split whole cents, then hand out the remainder

Work in integer cents. Give everyone the same base amount, then give one extra cent to the first few people until the remainder is used up.

function split(totalCents, n) {
  const base = Math.floor(totalCents / n);
  const rem = totalCents % n;
  return Array.from({ length: n }, (_, i) => base + (i < rem ? 1 : 0));
}

split(10325, 3);  // [3442, 3442, 3441]  sums to 10325
split(10000, 3);  // [3334, 3333, 3333]  sums to 10000
split(1, 3);      // [1, 0, 0]           sums to 1

Every result sums to the input, by construction. Nobody pays more than one cent different from anyone else.

Why not just `toFixed`?

toFixed rounds a binary floating-point number, so it can surprise you on values that look simple:

0.1 + 0.2        // 0.30000000000000004
(1.005).toFixed(2) // "1.00"

Both lines are real output from my run. Keeping money as integer cents sidesteps this: 87.50 at 18% is Math.round(8750 * 18 / 100), which gives 1575 cents, or $15.75.

Tests worth writing

A total that does not divide evenly (10325 by 3).
A total that does (10000 by 4).
Fewer cents than people (1 by 3).
One person (the split should return the whole amount).
Check that the parts always sum to the total, for a few hundred random totals and people counts.

Decide up front who gets the extra cent. First in the list is fine, but write it down so it does not change between screens.

How do you handle the leftover cent in your own code?

I asked a chat-based app builder for a days-between-dates calculator and checked seven cases

Kai Mercer — Sat, 24 Oct 2026 23:10:14 +0000

Disclosure: I work on marketing for Hyde, the tool in this post. I tested it on a second small app, picked because date math is easy to check by hand and easy to get wrong.

Hyde (https://hyde.pixelverse.tech) is a chat-based app builder: you describe an app, and it writes the code and shows a live preview.

The prompt

A days-between-dates calculator: two date pickers (start and end), a checkbox to include the end date, and a clear result showing the number of days, plus weeks and leftover days.

What it did

It edited src/pages/Index.tsx, src/index.css and index.html, then reported that the app builds and renders without errors. The chat showed 1 minute 42 seconds of work and 1 credit on the free plan (my balance went from 5 to 4). The page it made has two date pickers, an "Include end date" checkbox, a swap button, a reset button, and a result panel. It chose its own name and styling, and it filled in default dates (June 1 to July 15, 2026).

The seven cases I checked

I typed each pair into the preview and compared with a hand count.

Start	End	Expected	Shown
2026-06-01	2026-07-15	44 days (6 weeks + 2 days)	44, 6 weeks + 2 days
2026-02-27	2026-03-01	2 days (2026 is not a leap year)	2
same, "include end date" ticked		3	3
2028-02-28	2028-03-01	2 days (2028 is a leap year)	2
2026-03-08	2026-03-09	1 day (a US clock-change date)	1
2026-06-01	2026-06-01	0	0
2026-01-01	2026-12-31	364 days (52 weeks + 0)	364, 52 weeks + 0

All seven matched. The clock-change date is a classic trap for date math, and this one came out right.

I also entered an end date before the start date. It showed the absolute difference (44 days) and added a note: "Your end date is before your start date. We show the absolute number of days between them." That is a choice you might not want, but at least it tells you.

What didn't line up

After the build, the editor showed a red "Build error" banner pointing at /src/pages/Index.tsx ("hasn't been transpiled..." was cut off in the banner), and the console counter showed 6. The chat message said the build was verified and the preview worked, and every case above rendered correctly. I didn't click "Try to fix", so I can't tell you what the error was or whether it affects a published version. I'm only reporting that the banner and the "verified" message appeared together.

What I did not test

Publishing, a custom domain, GitHub sync and the built-in backend. This was one prompt and one project, so it says little about larger apps.

Takeaway

For a small, well-defined calculator, one plain-English message produced correct results on the date cases I picked. I would still run the boundary cases yourself: month ends, a leap day, equal dates, reversed dates.

Which date case do you always test first?

Why your date shows up a day early: a one-minute check

Kai Mercer — Fri, 23 Oct 2026 23:06:41 +0000

A date that shows up as the day before is one of the most common small bugs in front-end code. Here is a one-minute check you can run in any console.

The check

const a = new Date("2026-10-25");        // date-only string
const b = new Date("2026-10-25T00:00");  // date-time string, no offset

Per MDN's Date reference, when there is no time zone offset, date-only strings are read as UTC, and date-time strings are read as local time. MDN notes this comes from a historical spec error that could not be changed for web compatibility.

So the two lines above are different moments unless your machine is on UTC.

What I saw

I ran this in Node with the time zone set to America/Los_Angeles:

new Date("2026-10-25").toString()
// Sat Oct 24 2026 17:00:00 GMT-0700 (Pacific Daylight Time)

new Date("2026-10-25").getDate()
// 24

new Date("2026-10-25T00:00").toString()
// Sun Oct 25 2026 00:00:00 GMT-0700 (Pacific Daylight Time)

Same calendar date typed in, but the first one is Saturday the 24th when you ask for the local day. On a UTC machine both lines print the 25th, which is why this often passes on a dev laptop or CI and fails for users in other zones.

Quick fixes

If the string is a calendar date with no time (a birthday, a due date), keep it as a string, or format it with timeZone: "UTC" so the same zone is used for parsing and display.
If you mean local midnight, build it from parts: new Date(2026, 9, 25) (months start at 0).
If you mean an exact moment, include an offset or Z in the string.

One test worth adding

Run the date logic once with the process in a zone far from UTC, for example TZ=America/Los_Angeles and TZ=Pacific/Auckland. If the displayed day changes between runs, there is a parse or display mismatch.

Which time zone do you use to test date code?

I asked a chat-based app builder for a tip calculator and checked the math

Kai Mercer — Fri, 23 Oct 2026 11:09:54 +0000

Disclosure: I work on marketing for Hyde, the tool in this post. I wanted to write down what I saw when I tested it, including the part that didn't hold up.

Hyde (https://hyde.pixelverse.tech) is a chat-based app builder: you describe an app, and it writes the code and shows a live preview. I tried it on one small thing, a tip calculator, because the correct answers are easy to check by hand.

The prompt

I gave it one message:

A tip calculator: bill amount, tip percent buttons (10, 15, 20) and a custom percent, number of people to split between, and a clear result showing tip and amount per person.

What it did

It listed two tasks, edited src/pages/Index.tsx and src/index.css, and then ran a build check. The chat showed the work as it went, with the files it touched. The whole build took 1 minute 34 seconds and the interface showed it as 1 credit on the free plan. The result was a styled page with a bill field, 10/15/20 buttons, a custom percent field, a people counter, a reset button and a breakdown panel. The chat said the app builds and renders without errors.

What I tested

I typed values into the preview and checked the arithmetic by hand.

Bill 87.50, custom tip 18%, 1 person. Tip $15.75, total $103.25. Correct.
Same bill, 3 people. Per person: bill $29.17, tip $5.25, total $34.42. Each figure is right when rounded.
Bill of -20. The breakdown shows $0.00 everywhere, so nothing breaks. The field still shows -20, though.

What didn't hold up

Three people paying $34.42 each is $103.26. The calculator's own total is $103.25. That is a one-cent gap between the per-person amounts and the full bill, which is the classic split-bill rounding problem. It shows both numbers on the same screen, so a careful user would notice.

Nothing in my one-message prompt asked for rounding rules, so I can't say this is a bug in the tool. It's a case the first draft didn't cover. The chat also offered follow-up suggestions, such as remembering the last-used tip and adding rounding controls for splits. I didn't run those, so I can't say how they'd turn out.

What I did not test

The Hyde site also describes publishing to a custom domain, GitHub sync and a built-in backend. I haven't tried those, so I'm not making claims about them here. This was one prompt, one project, one afternoon.

Takeaway

For a small, well-defined app, one plain-English message got a working and good-looking calculator with correct core math. The thing to check is the edge cases you didn't mention. Splitting money is a good test for any code you didn't write by hand: try an amount that doesn't divide evenly and see whether the parts add up to the whole.

What edge case would you test first on a calculator built from one chat message?

What does your page title say first? A one-minute check

Kai Mercer — Thu, 22 Oct 2026 23:06:25 +0000

The <title> is one of the first things a screen reader user hears on your page, and one of the first things anyone sees in a tab or search result. Many landing pages leave it as the product name on every page, or "Home".

The check

View the page source and find <title>. Read it aloud. Then open a second page on your site and compare.

<title>Pricing - Acme</title>

Ask: does it say what this page is, and is it different from your other pages?

What the standards say

The W3C's Understanding page for WCAG 2.4.2, Page Titled, says web pages have titles that describe topic or purpose, and that titles identify the current location without requiring users to read the page content.

MDN's page on the title element has an Accessibility section. It says a common navigation technique for assistive technology users is to read the page title and infer what the page contains. It recommends titles that are unique to every page, with the primary purpose first and the site name after, so a screen reader announces the purpose first instead of the site name on every page. MDN also notes that dynamically updating the title is not automatically announced by screen readers, so an ARIA live region may be needed if you change it to reflect a state change.

W3C, Understanding 2.4.2: https://www.w3.org/WAI/WCAG22/Understanding/page-titled
MDN, the title element: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/title

Quick test

Open three pages of your site and read each <title> aloud.
If two are identical, or the first words are the site name, rewrite them: purpose first, then the name.
Keep each one short enough to read in a breath.
If you change the title in JavaScript (for a single-page app), check whether the change is announced. It may not be.

Duplicate or near-duplicate titles are also a search problem, since MDN says they can contribute to inaccurate search results. The same one-line fix helps both.

What do the first three words of your pricing page title say?

Is it a button or a div? A one-minute check for clickable elements

Kai Mercer — Thu, 22 Oct 2026 11:04:48 +0000

Landing pages are full of things that act like buttons: "Get started", menu toggles, tabs, plan switchers. Some are real <button> elements. Some are a <div> with a click handler. The page looks identical, but keyboard and screen reader users get different pages.

The check

View the page source (or DevTools) and find each clickable thing. Look at the tag.

<!-- Fragile -->
<div class="cta" onclick="start()">Get started</div>

<!-- Better -->
<button type="button" class="cta">Get started</button>

A <button> can be reached with Tab and activated with the keyboard, and a screen reader announces it as a button. A bare <div> has none of that unless you add it yourself.

What the standards say

The W3C's Understanding page for WCAG 4.1.2, Name, Role, Value, says that for all interface components, including form elements, links and components generated by scripts, the name and role can be programmatically determined. It adds that if custom controls are created, or elements are programmed to have a different role than usual, additional measures are needed so assistive technologies get the right information and can control them.

MDN's page on the button element also has a detail worth knowing: a button inside a form is a submit button by default, unless it has type="button". A "Show more" button without a type can submit your signup form by accident.

W3C, Understanding 4.1.2: https://www.w3.org/WAI/WCAG22/Understanding/name-role-value
MDN, the button element: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/button

Quick test

Press Tab through the page and note what you can reach. Can you reach every clickable thing?
For each one you can't reach, check the tag. Replace a <div> or <span> with <button> (or <a href> if it goes somewhere).
Check every <button> inside a <form> has the type you meant.
Press Enter and Space on each. A real button responds to both.

If you must keep a non-button element, you need to give it a role, make it focusable and handle the keys yourself. That is more work than changing the tag, which is why the tag is usually the better fix.

How many of your page's clickable elements are not buttons or links?

Check the autocomplete attribute on your signup form: a one-minute test

Kai Mercer — Wed, 21 Oct 2026 23:05:50 +0000

A signup form that blocks autofill makes people retype their name, email and address every time. For some users that is annoying. For others it is a real barrier. It takes a minute to check.

The check

View the page source and look at each <input> that collects personal data.

<input type="email" name="email" id="email" autocomplete="email">
<input type="text" name="fname" id="fname" autocomplete="given-name">

Look for two things: a missing autocomplete, and autocomplete="off" on fields like name and email.

What the standards say

The W3C's Understanding page for WCAG 1.3.5, Identify Input Purpose, says the purpose of a form input collecting information about the user must be programmatically determinable. It explains the reason: declaring the kind of data expected makes forms easier to fill out, especially for people with certain cognitive disabilities, who may not understand an input's purpose from its label alone.

MDN describes autocomplete as a hint to the browser on how, or whether, to prefill a control. It takes on, off, or space-separated tokens that describe the meaning of the value, such as email. MDN also notes that in most modern browsers, autocomplete="off" will not prevent a password manager from offering to save or fill login details, so turning it off may not do what you expected.

MDN, autocomplete: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/autocomplete
W3C, Understanding 1.3.5: https://www.w3.org/WAI/WCAG22/Understanding/identify-input-purpose

Quick test

Search the source for <input and list each field that asks about the user (name, email, phone, address).
Give each one a token that matches its meaning instead of leaving it blank.
Remove autocomplete="off" from those fields unless you have a specific reason.
In a browser with saved details, open the form and see whether it offers the right values in the right fields.

The WCAG criterion covers fields collecting information about the user. A field for something else, like a coupon code, doesn't need a purpose token.

Which fields on your signup form would the browser fill correctly today?

DEV Community: Kai Mercer

One number, three roundings: toFixed, Math.round and Intl.NumberFormat disagree on 1.005

Setup

What I see

What I would do for money

Not tested

What JSON.parse does to a 20-digit integer, and how to keep the digits

What parse and stringify do to big integers

Reading the original digits: reviver context.source

Writing them back: two traps

What I would do

Not tested

Days between dates in America/Los_Angeles: when one day becomes zero

Results

A second trap: parsing a date-only string

What I would do

Not tested

Typed vs set from script: a number input gives different answers

What stands out

What I would do with this

Not tested

What an input type=number really accepts: a quick test

What I set, and what came back

Why this bites in forms

A cheap test list

Split a bill three ways without losing a cent

The bug

The fix: split whole cents, then hand out the remainder

Why not just toFixed?

Tests worth writing

I asked a chat-based app builder for a days-between-dates calculator and checked seven cases

The prompt

What it did

The seven cases I checked

What didn't line up

What I did not test

Takeaway

Why your date shows up a day early: a one-minute check

The check

What I saw

Quick fixes

One test worth adding

I asked a chat-based app builder for a tip calculator and checked the math

The prompt

What it did

What I tested

What didn't hold up

What I did not test

Takeaway

What does your page title say first? A one-minute check

The check

What the standards say

Quick test

Is it a button or a div? A one-minute check for clickable elements

The check

What the standards say

Quick test

Check the autocomplete attribute on your signup form: a one-minute test

The check

What the standards say

Quick test

Reading the original digits: reviver `context.source`

Why not just `toFixed`?