This is basically 3,485 nested <div>s (balanced; same number of </div>s) with width and height both set to 10,000px.
I have no idea is this is an internal DOM overflow or it's because of the tiled background-image. (I don't have an iPhone to test against.)
EDIT: I actually read the article properly :) all 3,485 the <divs> have a 10px backdrop-filter set on them.
> He explained that nesting a ton of elements — such as <div> tags — inside a backdrop filter property in CSS, you can use up all of the device’s resources and cause a kernel panic
Fun trivia: ^F for <div> on the GitHub gist page, and Chrome will inch... forward... so... very... slowly... finding... matches. You have to search the raw file if you want it to complete this century.
It's because of the nested backdrop-filters being applied. I would've thought the css parser / rendering engine stops this from happening, but apparently not.
I guess it is because backdrop-filter is a new property. AFAIK backdrop-filter affects everything everything below it, so maybe a sanity check for the number of times the effect applies is missing.
Yeah it looks like its trying to compute thousands of filters stacked on top of each other. Photoshop would take a while to do that too. But safari shouldn’t be able to out of memory so hard it takes down the device.
I have no idea is this is an internal DOM overflow or it's because of the tiled background-image. (I don't have an iPhone to test against.)
EDIT: I actually read the article properly :) all 3,485 the <divs> have a 10px backdrop-filter set on them.
> He explained that nesting a ton of elements — such as <div> tags — inside a backdrop filter property in CSS, you can use up all of the device’s resources and cause a kernel panic
Fun trivia: ^F for <div> on the GitHub gist page, and Chrome will inch... forward... so... very... slowly... finding... matches. You have to search the raw file if you want it to complete this century.