--- title: "Every Time Someone Fixed a Typo in This Label, the HTML Entities Got Worse" canonical: https://dxdev.com/blog/2026-05-20_label-that-got-worse-every-time-someone/ datePublished: 2026-05-20 --- # The Label That Got Worse Every Time Someone Fixed It `Coach's "A" Team.` That was what appeared in an edit box when someone opened a navigation label to correct a typo. The label had looked perfectly normal on the website a moment before: `Coach's "A" Team`. Nothing had crashed. No warning had appeared. But the moment I saw the ampersands and semicolons in the box where a person was supposed to type, I knew this was not just an ugly little display problem. The first attempt at the whole job was to protect the text before putting it into a web page. That was necessary, but it did not work as a complete solution because it stopped too early. If someone types quotation marks, an ampersand, or a less-than sign, a website has to be careful with those characters. Otherwise, the page can mistake ordinary writing for instructions. The scary term for that is **HTML encoding**. It simply means swapping certain characters for a safe written version while they travel through a web page. That protection worked when the label was displayed in the navigation. The visible label still read `Coach's "A" Team`. But the first attempt did not account for the label coming back to a person for editing. It was easy to believe the job was done, and that mistake later cost time and patience. Then the label came back through the edit form. The edit box was given the safe written version, `Coach's "A" Team`, instead of the normal words a coach had typed. An edit box is more like a notepad than a web page. It does not translate `"` back into quotation marks. It shows every character exactly as it receives it. To the person trying to fix one typo, the label now looked like computer gibberish. At first, that can seem harmless. The navigation still looks right. The coach can close the window and move on. But the label was being quietly set up to get worse. As soon as someone touched that field and saved it, the system treated the visible gibberish as if the person had typed it on purpose. The next time the label passed through the protection step, the ampersand at the front of `"` was protected too. What had been `"` became `&quot;`. Edit and save again, and another layer could be added. A short label could slowly turn into a little pile of punctuation. That is the part that costs time and patience. A coach who only wanted to change one letter is handed a confusing box. Someone has to explain why the text looks wrong. If the label is saved in its damaged form a few times, getting back to the original may mean manually cleaning it up. The problem does not announce itself with an error. It waits for an ordinary, well-intentioned save. The fix was small, but the order of the work mattered. Before putting the saved label into the edit box, the system changed the safe written forms back into the characters people recognize. `"` became `"`. `&` became `&`. `<` became `<`. The edit box then showed the same words the coach had entered in the first place. That gave the label three clear stages. When it appears on the web page, it stays protected. When a person edits it, it returns to normal text. When it is saved again, it is protected once, and only once. There was one more wrinkle. The ampersand has to be handled carefully. Think of it like a wrapper around a fragile item. In `&lt;`, the `&` part may be protecting the literal characters `<`, not standing in for a real less-than sign. If the wrapper is removed too early, the next step can mistake those four characters for something it should translate. A person who intentionally typed `<` could end up with `<` instead. For the labels in this case, the set of characters was narrow enough that the existing sequence did not cause trouble. But it was still a lucky boundary, not a safe rule to copy everywhere. When handling wider-open text, the ampersand should be converted back last. On the way into storage, it should be protected first. That keeps one step from chewing into the work of another. I think the useful way to see this is not as a website trick. It is a question of what form of information belongs in front of a person. The protected version was right for the page. It was wrong for the notepad-like box where a coach needed to make a change. Those are different jobs, even when they contain the same label. The damage came from treating them as the same job. The system successfully protected the words for display, then forgot to return them to ordinary language for editing. Nobody needed a technical lesson to spot the result. They just needed the edit box to show what they had written. The three stages held: protected on the page, plain in the box, protected once on save. A label that once needed manual cleanup after a few rounds of editing now survives any number of them, because the ampersand is never asked to do two jobs on the same trip through the system.