HTML parsing supports some of this, e.g:
Readit Newsbfgeek commented on Overlapping Markup en.wikipedia.org/wiki/Ove... · Posted by u/ripe
bfgeek commented on Text rendering hates you (2019) faultlore.com/blah/text-h... · Posted by u/andsoitis
> This approach is different to how many text layout engines approach this problem e.g. by adding "one word at a time" to the line, and checking at each stage if it fits.
Do you know why Chrome does it this way?
We found it was roughly on par performance wise for simple text (latin), and faster for more complex scripts (thai, hindi, etc). It also is more correct when there is kerning across spaces, hyphenation, etc.
For the word-by-word approach to be performant you need a cache for each word you encounter. The shape-by-paragraph approach we found was faster for cold-start (e.g. the first time you visit a webpage). But this is also more difficult to show in standard benchmarks as benchmarks typically reuse the same renderer process.
bfgeek commented on Text rendering hates you (2019) faultlore.com/blah/text-h... · Posted by u/andsoitis
> Don’t ask about the code which line-breaks partial ligatures though.
Wondered about this. All the circular dependencies sound like you could feasibly get some style/layout combinations that lead to self-contradictory situations.
E.g. consider a ligature that's wider than the characters' individual glyphs. If the ligature is at the end of the box, it could trigger a line break. But that line break would also break up the ligature and cause the characters to be rendered as individual glyphs, reducing their width - which would undo the line break. But without the line break, the ligature would reconnect, increase the width and restore the line break, etc etc...
Blink's (Chromium) text layout engine works the following way.
1. Layout the entire paragraph of text as a single line.
2. If this doesn't fit into the available width, bisect to the nearest line-break opportunity which might fit.
3. Reshape the text up until this line-break opportunity.
4. If it fits great! If not goto 2.
This converges as it always steps backwards, and avoids the contradictory situations.
Harfbuzz also provides points along the section of text which is safe to reuse, so reshaping typically involes only a small portion of text at the end of the line, if any. https://github.com/harfbuzz/harfbuzz/issues/224
This approach is different to how many text layout engines approach this problem e.g. by adding "one word at a time" to the line, and checking at each stage if it fits.
Just curious, what algorithm is good for laying out images of arbitrary orientations, sizes, and aspect ratios? That seems like a pretty difficult problem. Some sort of variation of knapsack problem maybe?
You can exploit flexbox for this type of layout:
https://bfgeek.com/flexbox-image-gallery/
bfgeek commented on Passwords and Power Drills google.github.io/building... · Posted by u/harporoeder
> "At this point, the engineers in Australia decided that a brute-force approach to their safe problem was warranted and applied a power drill to the task. An hour later, the safe was open—but even the newly retrieved cards triggered the same error message."
What happened here (from what I recall) was far funnier than this does it credit.
The SREs first attempted to use a mallet (hammer) on the safe (which they had to first buy from the local hardware store - don't worry it got expensed later), then after multiple rounds of "persuasion" they eventually called in a professional (aka. a locksmith) who used a drill+crowbar to finally liberate the keycard.
The postmortem had fun step by step photos of the safe in various stages of disassembly.
One thing to keep in mind when developing these large lists of fonts is that they are generally terrible for performance if the appropriate glyphs for what you are trying to display aren't present in the first font (and the font is available - this isn't an issue if the font isn't available at all).
This is generally more of an issue with non-latin scripts (or when emoji is present for example), and developers adding a font which doesn't have glyph coverage - or sparse glyph coverage.
Chrome/Firefox devtools both have a section "Rendered Fonts"/"Used Fonts" which show which gylphs are used from which font.
Additionally if you are showing non-latin, make sure to language tag your markup: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
`font-family: sans-serif` if not language tagged with incur a similar fallback perfromance penalty (the browser will have to change the "english" sans-serif font, find no glyphs, then use the "other-lang" sans-serfic font).
bfgeek commented on Liquid Glass in the Browser: Refraction with CSS and SVG kube.io/blog/liquid-glass... · Posted by u/Sateeshm
backdrop-filter is supported by all major browsers, but specifically using SVG filters, which are more powerful and is out-of-spec, is only supported in Chromium-based browsers.
> which are more powerful and is out-of-spec
These are in the specification here: https://drafts.fxtf.org/filter-effects-1/#typedef-filter-url
And used by backdrop-filter here: https://drafts.fxtf.org/filter-effects-2/#BackdropFilterProp...
bfgeek commented on It is worth it to buy the fast CPU blog.howardjohn.info/post... · Posted by u/ingve
I wish developers, and I'm saying this as one myself, were forced to work on a much slower machine, to flush out those who can't write efficient code. Software bloat has already gotten worse by at least an order of magnitude in the past decade.
My biggest pet peeve is designers using high end apple displays.
You've average consumer is using a ultra cheap LCD panel that has no where near the contrast ratio that you are designing your mocks on, all of your subtle tints get saturated out.
This is similar to good audio engineers back in the day wiring up a dirt cheap car speaker to mix albums.
Just wrap it in a container with fixed height and "overflow: hidden".
Now the layout engine knows that it doesn't need to recalculate positions of elements outside that wrapper, and it's much faster.
By the way, the same trick was speeding up large <table> rendering back in the day. As long as you know the size of your rows or columns ahead of time, which kinda defeats the purpose of <table>.
This likely more effective quite a few years ago, but not particularly important today.
Changing height typically only shifts elements, and browser engines typically wont relayout them due to position changes.
"overflow: clip" is also much more lightweight than "overflow: hidden"
bfgeek commented on Minding the gaps: A new way to draw separators in CSS blogs.windows.com/msedged... · Posted by u/SigmundurM
Was just wondering that myself.. why they went with "rule" in `column-rule` and now `row-rule`
Part of the design constraint here is to reuse the existing properties that exist for multi-column layout which have existed for a long time - https://developer.mozilla.org/en-US/docs/Web/CSS/column-rule
This proposal extends this mechanism to be more general.