I feel like the option for simplicity lies between "web component" and "make 4 pages". Something near "the button changes the CSS variable controlling the size".
You lose out on pre-downscaled images but gain that the images look sharper for high DPI users and don't have to maintain the image sets or deliver multiple copies when the size changes.
Love this approach and use it often, usually with a Go backend. Blazing fast, simple, respects the way the web is supposed to work. Really nice touch using the CSS transitions.
This is a weirdly unpopular opinion here when it comes to HTML & JS, but there's a time and place for everything. This is a neat small example, but hardly worth the effort of changing something that was already working fine.
With the change, I now need another roundtrip network request to get new sizes of the same content on the current page that would have been able to be done in just a couple hundred bytes of JavaScript.
Edit: also there is still no view-transition support on Firefox.
You would have needed the round-trip network request anyway to get the new images, no?
The lack of Firefox support isn't a big deal because this is a progressive enhancement. Firefox users will still be able to switch icon sizes; they just won't see the fancy transition.
> You would have needed the round-trip network request anyway to get the new images, no?
It'd be a shared round trip request for all images (so long as you aren't still using HTTP/1.1) in the 1st example vs a request for the immediate images and then a separate page load.
Both have their upsides/downsides depending on the rest of the page and how users usually use it.
the web platform is making slow and not-so-steady progress as a hypermedia system, but things do seem to be picking up a bit
we are working on a proposal to bring more general transclusion and a few other things here:
https://triptychproject.org
I feel like the option for simplicity lies between "web component" and "make 4 pages". Something near "the button changes the CSS variable controlling the size".
You lose out on pre-downscaled images but gain that the images look sharper for high DPI users and don't have to maintain the image sets or deliver multiple copies when the size changes.
Love this approach and use it often, usually with a Go backend. Blazing fast, simple, respects the way the web is supposed to work. Really nice touch using the CSS transitions.
This is a weirdly unpopular opinion here when it comes to HTML & JS, but there's a time and place for everything. This is a neat small example, but hardly worth the effort of changing something that was already working fine.
With the change, I now need another roundtrip network request to get new sizes of the same content on the current page that would have been able to be done in just a couple hundred bytes of JavaScript.
Edit: also there is still no view-transition support on Firefox.
You would have needed the round-trip network request anyway to get the new images, no?
The lack of Firefox support isn't a big deal because this is a progressive enhancement. Firefox users will still be able to switch icon sizes; they just won't see the fancy transition.
> You would have needed the round-trip network request anyway to get the new images, no?
It'd be a shared round trip request for all images (so long as you aren't still using HTTP/1.1) in the 1st example vs a request for the immediate images and then a separate page load.
Both have their upsides/downsides depending on the rest of the page and how users usually use it.
The images will always need a network request, but the non-JS version requires another request for the new HTML source.
And with the previous implementation, all users would get the progressive enhancement, not just non-Firefox users.