bfgeek

One has to wonder if this due to the global memory shortage. ("Oh - changing our memory allocator to be more efficient will yield $XXM dollar savings over the next year").

HTML parsing supports some of this, e.g:

  text <b>bold <i>bold-italic</b> italic</i>

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.

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.

You can exploit flexbox for this type of layout: https://bfgeek.com/flexbox-image-gallery/

"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).

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...

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.

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"

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.

Yeah - this was arguably mostly my fault (sorry!).

There's quite a bit of history here, but the abbreviated version is that the dialog element was originally added as a replacement for window.alert(), and there were a libraries polyfilling dialog and being surprisingly widely used.

The mechanism which dialog was originally positioned was relatively complex, and slightly hacky (magic values for the insets).

Changing the behaviour basically meant that we had to add "overflow:auto", and some form of "max-height"/"max-width" to ensure that the content within the dialog was actually reachable.

The better solution to this was to add "max-height:stretch", "max-width:stretch". You can see the discussion for this here: https://github.com/whatwg/html/pull/5936#discussion_r5136422...

The problem is that no browser had (and still has) shipped the "stretch" keyword. (Blink likely will "soon" - https://groups.google.com/a/chromium.org/g/blink-dev/c/SiZ2n... )

However this was pushed back against as this had to go in a specification - and nobody implemented it ("-webit-fill-available" would have been an acceptable substitute in Blink but other browsers didn't have this working the same yet).

Hence the calc() variant. (Primarily because of "box-sizing:content-box" being the default, and pre-existing border/padding styles on dialog that we didn't want to touch).

One thing to keep in mind is that any changes that changes web behaviour is under some time pressure. If you leave something too long, sites will start relying on the previous behaviour - so it would have been arguably worse not to have done anything.

It may still be possible to change to the stretch variant, however likely some sites are relying on the extra "space" around dialogs now, and would be mad if we changed it again. This might still be a net-positive however given how much this confuses web-developers (future looking cost), vs. the pain (cost) of breaking existing sites.

Sorry!

The point I was after to make is that you can't assume that road wear scales the same way as tyre wear (I was assuming same material fwiw, just different loads). They are being worn under very different modes/scenarios.

I think as a starting point, I would expect that tire wear should remain roughly in proportion to road wear

IMO this would be a suspect assumption to make w/o data to back it up. You've got two dissimilar materials interacting (in very different modes). E.g. rolling a metal ball bearing on a wood surface would obviously cause the wood to degrade far more than the ball bearing, (and even a wooden ball rolling on a wood surface would wear substantially less due to the mode difference).

(If I had to guess the road has a higher wear as the surface has a tensile stress around the contact patch of the tyre, causing most of the damage, but this is just armchair engineering at this stage).

To add to this, (from what I remember reading the study at the time) it was basically racing a car around a track (think lots of tyre squealing around corners), and found that the tyre wear was very high. I haven't seen a study which actually simulates somewhat "normal" driving (presumably because the wear is so low driving like that it's difficult to measure). Also didn't factor in a bunch of different stuff - tyres are effected by lots of things; compound, temperature, pressure, surface abrasion, etc. There might be an effect! But this study was very bad.

You can create a new thread via. `new Worker` but using a worker requires a separate file, and lots of serialisation code as you communicate via `postMessage`. TC39 module expressions helps but not a lot of movement recently. https://github.com/tc39/proposal-module-expressions?tab=read...

A fun simple gear related concept is "hunting tooth".

https://en.wikipedia.org/wiki/Gear_train#Hunting_and_non-hun...

Basically you don't want any common denominators in teeth count, otherwise the same sets of teeth will engage at some frequency. If there is a small imperfection on a tooth it'll wear out quicker. E.g. a set with 5:14 teeth will theoretically wear better than a set with 5:15 teeth.

It depends on the project, but most large scale projects require test(s) for the fix, and will block submission unless its provided.

These types of projects undergo constant code-change/refactoring/re-architecture etc. If you don't add a test for your specific issue, there is a non-trivial change that it'd be broken again in some future release.

Its somewhat worse if an issue gets fixed, and broken again, vs. it being broken the whole time. E.g. with the former users have likely started to rely on the fixed behaviour, then will experience disruption when it breaks again.

These names come from the html spec: https://html.spec.whatwg.org/#workerglobalscope https://html.spec.whatwg.org/#workletglobalscope

Chromium (and most other browser engines) will use the specification names for things like this. E.g. equivalent code in WebKit, and Gecko: https://github.com/WebKit/WebKit/blob/80c1e6d05e4679c08e3a6e... https://searchfox.org/mozilla-central/source/dom/worklet/Wor...

If you have something like:

  columns: 1fr auto max-content

  <!-- items -->
  <div>1</div>
  <div>somethingsuperlong</div>
  <div style="span: 2;">something else</div>

Depending on the non-fixed column type (there are different rules for each type) you want to ensure their constraints are satified (typeically they are big enough to encompass the items).

The requires it for sizing the columns (the step before placing the items into the columns).

Part of the tension with building masonry on top of grid is that they work in fundamentally different ways.

Grid you place everything in the grid first (e.g. an item goes in col:2,row:3), then size the grid. Masonry ideally you want to size the tracks first, then place items in those tracks.

The first Firefox implementation (and the spec at that stage) basically said you don't consider any masonry items for sizing tracks (except for the first row, and some other rules - its complex). This meant that it is trivial to create items that overflow their tracks.

The specification at the moment asks to place every item in every possible track. This has quadratic performance O(N_tracks * N_items) in the worst (and somewhat common case). Quadratic performance is bad[1] and we don't really have this in other layout algorithms.

With nesting introduced the performance goes (sub-)exponential, which is really poor, even if you have a fast CPU.

One may argue that these cases aren't common, but folks always test the boundaries with layout modes in CSS - so things need to be fast by default.

Note: In grid items size themselves differently depending on what tracks you place them in, which is why you need to place in every possible position.

Masonry potentially needs a different algorithm for sizing tracks to mitigate these problems, (the blog post doesn't go into these issues in sufficient detail). There may have been a version of grid sizing which didn't have item positional dependence but that ship has sailed.

[1] https://randomascii.wordpress.com/2019/12/08/on2-again-now-i...

Are you referring to access through a raw pointer after ownership has been dropped and then garbage collection is non deterministic?

No - basically objects sometimes have some state of when they are "destroyed", e.g. an Element detached from the DOM tree[1]. Other parts of the codebase might have references to these objects, and previously accessing them after they destroyed would be a UAF. Now its just a bug. This is good! Its not a security bug anymore! However much harder to determine what is happening as it isn't a hard crash.

[1] This isn't a real case, just an example.

Oilpan can theoretically be used as a library as well - see: https://v8.dev/blog/oilpan-library https://v8.dev/blog/tags/cppgc https://chromium.googlesource.com/v8/v8.git/+/HEAD/include/c...

Due to the nature of web engine workloads migrating objects to being GC'd isn't performance negative (as most people would expect). With care it can often end up performance positive.

There are a few tricks that Oilpan can apply. Concurrent tracing helps a lot (e.g. instead of incrementing/decrementing refs, you can trace on a different thread), in addition when destructing objects, the destructors typically become trivial meaning the object can just be dropped from memory. Both these free up main thread time. (The tradeoff with concurrent tracing is that you need atomic barriers when assigning pointers which needs care).

This is on top of the safey improvements you gain from being GC'd vs. smart pointers, etc.

One major tradeoff that UAF bugs become more difficult to fix, as you are just accessing objects which "should" be dead.

the UAF-ish bugs are still bugs, and code poking at a GC-preserved object that the rest of the code doesn't really expect to still be alive might itself be pretty fraugh

For the LayoutObject heirarchy - the team doing that conversion added a NOT_DESTROYED() macro for this reason. It's gross, but was the least worst option.

As an aside - the performance of oilpan is broadly net positive now if you avoid some of the pitfalls. (The largest being a write into a Member<> requires a write-barrier). E.g. Things become trivially destructible, and no ref incrementing/decrementing, etc.

One interesting thing which folks might not be aware of - most objects in Blink (Chromium rendering engine) are GC'd: https://v8.dev/blog/high-performance-cpp-gc

This is in part due to lots of objects having strong references from JS objects, and the complexity in dealing with already having a GC with reference counting techniques.

Additionally its much harder to introduce UAFs & Type confusion bugs, but also has interesting performance implications (not as simple as GC is slow - a lot of the time GC'ing objects can make things faster).

Additionally this property disables the "compressibility" hack which browsers invoke currently.

(jsfiddle for previous example: https://jsfiddle.net/vk8fy1bz/ )

Suggestions for better names are welcome! Typically values with multiple words (e.g. grow-with-content) are rarely used.

This property will affect form-control elements <textarea> , <input> , <select> etc. Hence "form-sizing" but a better name for is definately welcome (please paint the bikeshed!).

"normal" for the reason to "behave like a normal element". "auto" for "behave like before".

Not great names, (perhaps "content" is better than "normal"?) but again, suggestions welcome.

Its not the same thing. min-content/max-content/fit-content etc for these form control elements are some magical value (for textareas "1lh * attr(rows)") for example. (This works cross browser!)

min-content/etc get invoke in more places than you'd expect. For example:

  <table>
    <tr>
      <td>
        <input style="width: 100%">
      </td>
    </tr>
    <tr>
      <td>
        <input style="width: 100%">
      </td>
    </tr>
  </table>

This property is basically a switch to say "don't use the magical values for the intrinsic sizes size based on your content instead".

With the new form-sizing property (or whatever it gets named) all the inputs in that table will be sized to the maximum input.

I understand its frustrating but changing a 20+ year platform isn't an easy/simple affair sometimes :).

Chromium is currently trying to partition-visited links to prevent this type of history leakage - see: https://groups.google.com/a/chromium.org/g/blink-dev/c/h7Ahp...