bfgeek
A lot of developers who are submitting these AI patches don't necessarily understand the patch, so the onus is on the reviewer/code-owner.
The reviewers are getting swamped (some reviewers are receiving 100s or patches per month). If feedback is provided at lot of the time the patch author will just copy paste from an LLM, so the reviewer is essentially just coding with an LLM with more steps.
Prior to LLMs reviewing code was a mentorship experience, the patch author would likely learn a bunch afterwards. Now less so.
As a result a lot of projects are closing to external contributors.
I'm not sure what the answer is, LLM are great at speeding up coding/understanding/etc, but the valuable/expensive piece of work has shifted to reviewing.
text <b>bold <i>bold-italic</b> italic</i>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.
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.
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.
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).
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...
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.
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"
This proposal extends this mechanism to be more general.
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!
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).
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.
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.
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...
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).
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...
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.
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.
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.
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).
(jsfiddle for previous example: https://jsfiddle.net/vk8fy1bz/ )
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.
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 :).