Hacker News Reader

Comment by n0w | Hacker News Reader

We've started trimming the whitespace from the top/bottom of blocks of text so that the bounding box is effectively from the top of the cap to the baseline.

Mark Dalgleish describes the technique in this video (around 9:45) https://m.youtube.com/watch?v=jnV1u67_yVg

It's made it a lot easier to reason about the layout of text compared to other elements on the page and achieve more consistent use of spacing.

View on HN

"Reason" about it -- typography is art. There are many issues that started around when GUI word processing started. For example -- the "spring space" is simply gone. As is the "set indent to current (horizontal and vertical)". Kerning tables are pretty much gone (we used to have kerning by size/font font/combinations. This has not been simple. But typography is, basically, dead.

I have given up "teaching typography".

At the end of the day I'm a developer, not a designer, so I'm not confident to speak to the art/design side of typography.

Having said that, I believe that art (and design) requires intention and thus some amount of "reasoning".

Think of it like this, though. Suppose books were invented second to the computer, not first. They'd be the hottest thing. Everyone would be reading in public and giving up their unreliable and vulnerable smartphones, who could resist the atomic collateral of a book, it simply uses so many more atoms per bit than a chip. Books are so much more trustworthy! I've only witnessed one hack on a book whereas I've seen so so many on computers.

So then, someone would post exactly your comment, but in reverse, "I have given up 'teaching typography'." Why? Because nobody cared about subpixel rendering, rotating screens, SVGs versus rasters, because everyone would be exploring kerning tables and spring space.

I've been doing this as well in some projects. I use Capsize, which I believe is the result of his team's work extracted into its own tiny library. Interestingly, it no longer uses a transform, and now applies negative margins in :before and :after pseudo-elements, as such:

.capsizedText { font-size: 19.25px; line-height: 24px; }

.capsizedText::before { content: ""; margin-bottom: -0.2597em; display: table; }

.capsizedText::after { content: ""; margin-top: -0.2597em; display: table; }

https://seek-oss.github.io/capsize/

Doesn't this necessarily mean that descenders will intersect with the next element? See the `space="xxsmall"` example at 14:17 – "lazy dog" has its "g" dipping into the Submit button sibling.

Depending on how you're calculating the offset, this may also have problems with things like diacritics and non-Latin text, which may be taller (e.g Thai).

Sure, if you put things too close together they will intersect/overlap.

This isn't an inherent problem of the technique though. You should be giving things enough space so that this kind of thing doesn't happen. It should be pretty simple to check that the smallest unit of space used anywhere isn't smaller than the amount being trimmed from the top/bottom of the text box.

> It should be pretty simple to check that the smallest unit of space used anywhere isn't smaller than the amount being trimmed from the top/bottom of the text box.

It might be worth doing that, but note that there is still no guarantee of any reasonable upper bound on the vertical dimensions text will render within. Zalgo text is a famous example that very clearly illustrates this state of affairs [0]. The fact is that no current web design can guarantee that no text glyphs will overlap, short of using some non-standard font that prevents it, or perhaps by greatly restricting the usable Unicode characters.

[0] https://en.wikipedia.org/wiki/Zalgo_text

This is trading typographical consistency issues, then. In this described setup, you'll have glyphs poking into the margin and padding between elements – which is what the existing bounding boxes work to prevent.

Here's an editable interface from that talk: https://seek-oss.github.io/braid-design-system/playroom/#?co...

You can see the issues when we write Hello World in Thai: https://i.imgur.com/MaHfPr3.png

You're wrapping your two Text components with a Stack component which lays out its children vertically, and you're explicitly specifying that Stack uses zero space between each of its children. This doesn't have anything to do with Thai characters specifically. The glyphs already overlap with common English characters like "j" and punctuation like commas. Moreover, you can get glyphs to overlap between two lines of a normal HTML element with line-height: 1 (and obviously even more easily with line-height less than 1).

Yes, but this is true already. Here's a screenshot of how Hacker News looks on MacOS Chrome with some diacritics pasted into the beginning of your two paragraphs:

https://imgur.com/a/nH3KDbZ

Reply on news.ycombinator.com