For the purpose of this tutorial, I’ve used Scout-App to handle the compiling as I’ve wanted to have the tooling at the bare minimum.
#HTML SLIDESHOW CODE#
SCSS gives you the advantage of using variables, nested selection, mixins, and other cool stuff, but it needs to be compiled into CSS to have the browser read the code as it should. The source CSS code is written in SCSS, a CSS pre-processor which is then compiled into regular CSS which the browser can interpret. We have a logo at the top, static info which tells the user which page they are on, some description, and slider current/total indicator. The rest of our HTML is pretty straightforward as well. Similarly, the title slides inside of the aux holder: #64 ParadigmĮach slide title is an H2 tag with the corresponding data attribute and a link to be able to lead to that project’s single page. Images are rendered inline as if they were coming directly from a CMS and are set by the end user.
The abs-mask div we’ll use to create an interesting transition effect and the slide-image div contains the specific featured image. The index data attribute is what we’ll use to keep track of where we are at in the slideshow. Here we have an image slide inside of the main holder:
The structure of each slide inside of these two holders is pretty basic. Main is the div which contains featured images while aux holds image titles. Let’s focus on the slideshow section since that is our point of interest in this article.
#HTML SLIDESHOW FULL#
In this scaled-down approach, I’ll cover the basic HTML structure you would expect to be delivered from a CMS back-end, modern CSS ( SCSS) layout techniques, and vanilla JavaScript coding for full interactivity.
This article is aimed to show a pure CSS/JS approach in developing a fullscreen scroll-triggered slider layout with custom content animation. When it comes to doing your own thing this way, it requires a bit more coding knowledge and experience to know what you are looking for, but in the end, you should get a piece of code that does one thing and one thing only the way you want it to. I’m not saying using a third-party plugin of any kind is naturally a bad thing, I do it on a daily basis in my projects, just that it is generally a good idea to weigh pros and cons of each approach as it is a good practice in coding. But still, you get a full-size library included in your project for maybe only one or two different things it provides. Also, most plugin authors optimize their code, make it cross-browser and cross-platform compatible, and so on. You’ll get a variety of options you can use to tweak to your needs without having to do much coding. On the other hand, I see many JavaScript developers tend to reach for their favorite slider JS plugin to make their job easier, even though the task may not need all the bells and whistles a certain plugin provides.ĭisclaimer: Using one of the many plugins available out there has its perks, of course. Whether it be a time-triggered complex timeline of transitions or a scroll-based user-driven set of events, in most cases, the UI requires more than just using an out-of-the-box plugin solution with a few tweaks and changes. Usually, these layouts imply a substantial amount of interaction and animation. I work with custom full-screen layouts a lot, practically on a daily basis.
0 kommentar(er)
