A lightbox is one of those tools that work great on the desktop but often fail on small mobile devices. These days, finding a plugin that is responsive and that displays content right away is hard. For this reason, I created Magnific Popup, an open-source lightbox plugin focused on performance.
Shame they didn’t incorporate touch swipe events…
Capturing sounds like exactly what is needed for the ideal bridge between having a single code base and a truly device-responsive site! Very interesting…
Indeed, a slight performance hit on the initial load, but then it caches the results to improve later loads.
The subject that just won’t go away, because it is so vital to a good browsing experience, and no proper solution yet exists…
This author takes the stand that new mark-up is not the solution, that ideally what we need is a better image format, but while we’re waiting for that, let’s get back to basics: anyone remember image optimization?
[W]hen considering a jpeg image’s file size, the level of compression makes more of a difference than its physical dimensions. In other words, given two identical images that are displayed at the same size on a website, one can be dramatically smaller than the other in file size if it is both highly compressed and dramatically larger in dimensions than it is displayed.
If you want to display an image at 400 pixels width and 300 pixels height, saving it with those dimensions and displaying at 100% size, with a typical 90% quality jpeg compression from Photoshop, weighs 95kb.
The same image, however, saved with the dimensions 1024x768px and scaled down by the browser, with a 0 (zero!) quality jpeg compression from Photoshop, weighs 44kb!
And will then scale very well, without compression issues…
While mobile browser support for the
<progress> element is not very good, it will get better fast, especially in 3d-party browsers, and we can start using it now, with a simple fallback:
<img alt="Loading..." src="spinner.gif" />
Which looks like this:
So, browsers that can’t handle the
<progress> will get the
spinner.gif, and browsers that can handle it, will get the modern HTML element, with no need for the image.
An additional benefit of this method is that the
<progress> element will automatically be responsive, with need for resizing, or fetching different images, etc.
And of course, you could even improve that a little by making the
spinner.gif a very basic spinner, and converting it to a Data URI…