It can be shorter even than that: contenteditable is a boolean attribute, meaning that it’s its presence that matters, not its value. In fact, “true” is an invalid value for validation purposes: only the empty string and the attribute name (for stupid-from-the-very-start XHTML convention reasons, XML not allowing omitting attribute values and people probably not being quite comfortable with empty string values) are valid. In HTML syntax, you can (and generally should) just write `contenteditable`, and that’s equivalent to `contenteditable=""`. If you really want to confuse those unfamiliar with boolean attributes, `contenteditable="false"` is editable (or, for a more easily understood one, `disabled="false"` is equivalent to `disabled="true"` or `disabled`).
Indeed, I know about this but generally people who are not familiar with HTML gets tripped up about this and the times I've had to explain it, it's been easier to just make it as explicit as possible.
Although it's possible that `contenteditable="false"` would trip them up even more, so good point.
My apologies: contenteditable isn’t a boolean attribute as I thought, but rather an enumerated attribute, with "", "true" and "false" being valid values.
https://html.spec.whatwg.org/multipage/interaction.html#attr... has the details. It comes down to the ability to specify contenteditable="false" within a contenteditable area, with the absence of a contenteditable attribute corresponding to the inherit state.
I had quite forgotten that it was possible to nest something non-editable within something editable. Fairly similar to user-select behaviour, really.
As observed already in another comment, I erred on the contenteditable attribute, that it’s not actually a boolean attribute like the best-known one disabled; rather, it’s one of the handful of tristate attributes. But take one that’s actually a boolean attribute, and my remarks are completely correct. As for contenteditable, I’d still recommend writing `contenteditable` rather than `contenteditable="true"` (which two are equivalent).
> 0xA000 started out as an experiment in trying to create a pixel font with greyscale squares for anti-aliasing.
What does that mean? Aren't all fonts using grey pixels for AA while pixels are, well, squares (or close enough)? I know about "sub-pixel AA" done using colors but I don't think they're referring to this.
Or do they mean that the font has no AA at all and is just one using regular pixels, all of the same colors? (FWIW I'm using a version of the Terminus font that does just that: "pixel perfect" rendering at several sizes, no AA)
I am a bit disappointed by the squareish-group. The letterbox is far from square. There are not many fonts that are/aim to be square, so I was kinda excited as I noticed this variant.
The web interface is a bit confusing. You need to click "Pixelated" or "aliased rendering" at the top to see how the final result/look.
I think the default landing page is showing the original vector font from which the pixelated one are made
I quite like the final result. It's sorta like a bitmap font but with a more organic feel to it. I wouldn't want to code in it, but I'd add it to a image for instance
Tried zooming out with browser instead. It was surprisingly legible at 30% (the smallest zoom possible in ff) and only with magnifier I noticed the heavy subpixel rendering. Most of the letters were drawn with subpixels in fact.
