philo23

I appreciate that there must be a lot of traffic hitting this web server so maybe every little bit of savings counts, but I kinda wish the HTML wasn't so heavily compressed.

I remember getting my start with web development by simply reading the source code of sites I found interesting and trying to recreate them. example.com isn't exactly very interesting but it feels like compressing the HTML isn't in the spirit of things either.

On a side note I'd love to see how complicated (or maybe simple) the hosting setup for this site actually is behind the scenes.

Also worth mentioning that they added an easy way to make passes directly in the wallet app on iOS 27, you can basically scan in existing barcodes and qr codes.

I don't see the appeal of foldables personally but the way the screen animates during folding/unfolding is a very clever touch

The main use case I was thinking of is being able to use an inline SVG, but with external resources inside of it (like say a CSS background image using url(...)) in such a way that it ends up loading that embedded content in a cross-origin anonymous way and blocking all embedded scripts. That way someone can't make requests to CSRF exploitable URLs by setting an embedded images to something like example.com/my-submission/favourite

But also so that setting up a CSS transform: scale(10000) can't take over the entire viewport, it'd be constrained to an iframe-like boundary (exactly like an <img>) but still remain as an inline SVG, sort of like an <iframe srcdoc>. So scripts on the parent/host HTML document can still manipulate it like the rest of the DOM, but the inner <svg> elements are all "inert" for want of a better word.

Actually I don't know off the top of my head what happens with an SVG file inside of a <img> when it references external images (either cross-domain or not.) I know scripts and animations get disabled, so I'd take a guess and say some CSS gets blocked too.

Again I've not really thought terribly hard about it, or if it's actually useful at all, and I'm betting it'd be filled with even more foot-guns than there are right now. I'm just thinking out loud.

> How can you prevent it from accessing a parent doc when its not a separate document.

By turning it into a document boundary when you use the sandbox attribute, kinda similar to loading an svg file inside of an <img> tag.

and yeah you could get 90% of the way there with an iframe srcdoc, but I was imagining some kind of cross between an <iframe> sandboxed into its own origin, and an <img> where it still has its own intrinsic size.

but it was mainly just a throw away thought, I've not really thought it through much deeper than that.

It'd be nice if there was a sandbox attribute you could add to inline <svg> tags, like the <iframe sandbox> attribute that'd let you opt out of all the potentially "dynamic" stuff inside of an SVG like scripts and event handlers, or even just literally sandbox the entire thing from accessing the "parent" HTML page's context/cookies/etc just like an iframe.

I'm sure it'd just open up a whole other can of worms though... not to mention having to wait for browsers to actually support it.

The real solution here is definitely CSP + basic sanitisation though.