- bfgeekYou 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:
You first need to decide how big each of the three columns are going to be, then you want to place the items in each of the columns.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.