Email developers, as you know, are trapped in the 90s when it comes to HTML. (Or perhaps trapped in a steampunk world where Web-0.9-era HTML4 mixes with time-jumping CSS3.)
So they’re used to setting the ancient
height HTML attributes on an element (not to be confused with
height CSS properties). For example, to give a table cell a certain pixel width:
Where a unit-less numeric string represents a length in pixels. A numeric string followed by
% represents a percentage.
For the longest time, I thought those were the only 2 options, either
10%, and it was invalid HTML to even attempt to use
10px (let alone other units not supported in HTML4, like
Turns out it’s not invalid. So many apps were forgiving and assumed you meant just
10 that the forgiveness made its way into the current HTML standard. Yes, in the standard,
height are marked obsolete in favor of CSS. But if you do use them, the parser looks for a sequence of one or more numeric characters, and any non-numeric characters after that are simply ignored.
The path through the spec goes like this:
- the table rendering rules say that
heightmap to dimensions
- the dimension property definition points to the rules for parsing lengths or percentages from string values
- the parsing rules dictate that a sequence of contiguous digits
9at the start, after stripping whitespace, is the effective value — regardless of what follows:
This means the following values are all valid and interpreted as 10 pixels:
Doesn’t mean you should push your luck, as people reading your code may think you’re wrong (I certainly used to). But teeeeechnically it’s allowed. Interesting, I thought.