New Project 28 for SOURCE now available at PROJECT28
Think of a Screens type layout but one where you have the positioning power of Source, the ability to hide anything at any breakpoint, and the option to scale any specific text. The navigation arrows are automatically generated or can be selectively hidden and any button or link can be used to navigate (pages can also be linked to). Thumb swipe and mouse drag is present to create a web site for the TikTok generation of thumb swipers. These features make this type of horizontal and vertical full page scrolling web site a viable solution for many applications including being used for creating online learning and presentations.
I have updated this Project to v1.01 with a new feature and a new capability.
By adding some short code to your HTACCESS file on your server, this Project will now serve the original jpg or png images, or new webP images, if your browser is capable of displaying webP images.
The process is that the HTACCESS code detects the webP capabillity of the web visitors device, and if it is webP capable, AND if a webP version of the same image exists, then the webP version will be downloaded and displayed. This will reduce the download time by using smaller optimised webP images and can be significant way to speed your site up.
This will work with all jpg & png images including background images, slide images, Poster2 images, etc and no change is required at the Stacks level. You just enter a jpg or png image URL as normal and make sure there is an additional webP version with the same name at the same location.
A folder of these new optimised webP images is included with full instructions and a sample htaccess file in the Project.
The new feature is that a test message will appear at the bottom of the Project 28 home page that will display whether your browser can display webP images. This is useful when starting to use webP images.
Images must be warehoused images and your server must be running Apache (most are)…
Make sure you backup your current .htaccessfile if it exists.
Google PageSpeed won’t see the webP images becasue it checks the page code, but it will see jpg and png images that are the same size as webP images, so it will treat them as images that cannot be further optimised.
Existing customers can login to their Paddle Account to download new version.
If you are not happy editing your htaccess file, then just leave it as it is and the normal optimised jpg & png images will be used.
Stuart has a stack called SRCERER that does this for individual images.
However, Stacks doesn’t provide a functionallity like this so a stack to do this is not feasible.
However, by doing it this way, you are serving the webP images outside of the code generated by RW + Stacks and as long as you use warehoused images, you just need to add the webP images to your warehouse folder and you are good to go.
That’s really what my Projects are all about and particularly this one. The best way to understand how to build a web design is to see it all laid out and documented. In the new update there is also a ready made .htaccess file that you could drop into your site and as long as you have warehoused images setup, then you just need to add the webP images alongside the jpg or png versions.
It’s unfortunate that serving webP images and providing a fallback image is such a potentially time consumimg thing, but until there is widespread webP support, the method that is used in PR28 is the probably the easiest way to do it. Once you have used it on one site it would be quicker to implement on others.
PS 21% of browsers don’t support webP yet and I really can’t see Apple implementing it on Safari v15 earlier than BigSur. That means there is a great many Macs, iPhones and iPads that can’t display webP and therefore need a fallback jpg or png.
I agree, the code snippet detecting if the browser supports WebP images and then serving a .webp image instead of jpg / png if a .webp file is available in the same location as the provided jpg / png / gif is a great solution, as there is currently no full webp compatibility for browsers. Rightly, both the idea of this solution with htaccess, which for me is brilliant even if it is said on the net that it is not preferable, and the hours of code design and work spent to find this solution must also be rightly paid.
Thanks also to @GKs, for the suggestion, I did a search, and I understand better how the code works.
There isn’t any secrecy about this method, but it does require careful testing and careful thinking about how to implement it and then test it fully.
I suspect there are many RW users who add webP images and incorrectly assume that all web users can see them.
That interesting statement I believe applies to any competent HTML coder who is building a web site from scratch.
RW users are at the opposite end of this skill spectrum, and I am not aware of any complete RW solution to build a new site that will correctly deliver webP or jpg / png images for all site images, BG images, slider images, navigation bar logos, etc… AFAIK, doing this for an existing RW site would be a considerable rebuild even if a complete Stacks solution becomes available.
There is a great elegance to this solution in that it will automatically convert the selection of all images to webP in the future, should one day, browser support increase from 79% to 100%.
Another great looking project Gary. Really linking the continuous background effect in demo 3!
Am working on an update to Splider currently that would allow top-to-bottom slides like this to be navigated using the mouse wheel / trackpad. Think that would work well for this kind of full page setup.