The rather new WordPress Page Builder Elementor already has over 400,000 active installations. I took a look at this whizkid for you.
The Page Builder developed by Pojo Me Digital Ltd. is only about two years old. Since then, the plugin has established itself and became one of the market leaders in this rather overseeable branch.
Elementor: From 0 to 400,000 Installations in a Bit Over a Year
In 2016 Elementor started under the open source license which was pretty uncommon for this kind of plugin. Thus, I’m not surprised that Elementor got a lot of attention and goodwill right off the bat, especially since the developer promised that nothing would change about the project being available for free.
The development advanced quickly. New features were implemented week after week. Now, the scope of functions leaves little to be desired. For a while now, Pojo has also been offering a commercial version of the Page Builder, called Elementor Pro. Since then, new features have been developed for both the free and the commercial version. It seems like Pojo is set to keep their promise. The free version keeps getting supplied with new features.
Theme developers can integrate the free version into their offers, while the pro version can only be purchased by the end user. Pojo is not only the developer of Elementor but is also a key player in the distribution of ready-made themes. Logically, the company integrates their own Page Builder into each of their themes.
Elementor: Installation and Commissioning
Elementor is installed just like every other plugin. As it is available in the repository, you can actually install and activate it right from within the WordPress backend. Currently, since January 9th of 2018, version 1.9.0 is the most recent one.
Once it’s active, the prominent button above the text editor window shows you the page builder’s availability.
This prominent button starts the editor. (Screenshot: Noupe)
On the left side, in the page navigation, you’ll find a menu item called Elementor. This is where you change global settings, and where you have access to all templates you set up. Maintenance tools and system information regarding the most critical parameters of your WordPress environment round off the basic feature set.
Elementor’s Catchy Interface Concept
Pushing the mentioned button on articles or pages opens a fullscreen editing window.
Elementor in action while working on my article. (Screenshot: Noupe)
The underlying theme’s design elements are displayed unedited, and uneditable. In the shown example, all changes that can be made with Elementor only affect the space dedicated to the article. This allows you to enhance articles in a way that was only known from print magazines before.
Access the templates right from within the editor. (Screenshot: Noupe)
If you’re missing out on ideas, choose one of the over 100 ready-to-use templates. This approach is also recommended for newbies, as each template is entirely editable once it has been implemented. This allows you to learn which results are possible while working on the living object. You can get an overview of all available templates in the Template Library.
Elementor comes with a whole bunch of professional templates. (Screenshot: Noupe)
Aside from the default features, such as adding text, images, or videos, Elementor also provides you with a wide range of additional elements. These include accordions, sliders, carousels, media integrations, tabs, and more. You’re also able to access WordPress standards, such as the latest posts, most recent comments, and so forth.
If a design seems satisfying, you can test it in different resolutions via a small screen icon at the bottom right. Desktop, tablet, and smartphone are available, and Elementor sticks to the conventional breakpoints, such as 360 pixels for smartphones, for instance.
If you want the layout to break out of the theme’s default limitations, you have to head to the post or page attributes, and select the value “Elementor Canvas” instead of the default value “Default Template”.
A simple selection change comes with massive consequences. (Screenshot: Noupe)
With the help of the community, Elementor got translated into several different languages.
I’m especially impressed by two recent new additions that almost revolutionize the feature set of the Page Builder. One of them is called History and provides a full-fledged undo/redo and revision history. This is especially handy as soon as you notice a mistake you made quite some time ago. Instead of having to start over, you simply make use of Elementor’s undo, and reset the project to the last version before the error. Redo, on the other hand, lets you repeat an action.
Elementor’s History function helps you avoid design disasters. (Screenshot: Elementor)
The second innovation is Inline Editing. In Elementor wording, inline editing means that you’re able to create and edit text right from the frontend. This way, you get a much better feel for the look of your content, and you’ll catch yourself trying to realize (typo)graphic ideas more often than before.
All you marketers out there will be happy to hear that, with the latest update, Elementor Pro integrates the most popular and marketing automation and CRM services, namely Drip, ActiveCampaign, ConvertKit, GetResponse, MailChimp, MailPoet 3, HubSpot and Zapier. MailChimp, MailPoet, and Zapier have been available since May 2017 as form integrations, but got updated lately. Now there shouldn’t be a potential Elementor user without his or her marketing automation service unsupported.
What Happens When You Deactivate Elementor?
Page Builders belong to the group of plugins that you can’t just deinstall. Of course, nothing is stopping you from doing so, but you’ll undoubtedly be wondering what happened to your website’s design soon afterward.
Most Page Builders on the market work with shortcodes that they embed in contents. If you deinstall this kind of plugin, all shortcodes remain, but don’t make sense to WordPress anymore, destroying your contents as a result. Other plugins don’t leave their shortcodes behind, but also take all content that was created within the builder with them.
Elementor is a very commendable representative of its kind. While you do lose the entire layout upon deinstallation of Elementor, the contents remain as pure HTML. This doesn’t look as good as before anymore, but it still works.
Conclusion: Page Builder? Elementor
In comparison to others of its kind, Elementor is one of the tops in many regards. You have to keep in mind that switching between different Page Builders comes with a lot of effort. For instance, you’ll lose the layout if you decide to stop using Elementor or any competitor at one point.
Still, I wouldn’t say that Elementor was a bad choice. The opposite is the case. The decisive considerations are of a general nature. Do you want to use a Page Builder or not? As soon as you decide to use a Page Builder, Elementor should be the plugin of your choice.
Enthusiastic feedback on Elementor.com (Screenshot: Noupe)
This evaluation can be verified by the user feedback on the web. Criticism regarding Elementor is pretty rare, while excitement and sympathy for the product are common. According to the developer, the most lauded features are the performance, the compatibility with existing themes, the variety of turnkey templates, and the flexible editing.
Extended Functionality With Elementor Pro
Aside from the free version, there is Elementor Pro, which targets potential power users with its exclusive features. Elementor Pro is an expansion of the free plugin, and can simply be added on top the free variant. From there, you can seamlessly continue to work on your designs, while having additional features available to you.
Elegant search design for your WordPress site. (Screenshot: Elementor)
With the pro version, comfortable ways to integrate WooCommerce elements into Elementor layouts become available. This is not possible in the free version. On top of that, you gain access to the steadily growing number of widgets that affect the entire site, such as the Search Widget, or the Menu Widget. The widget Animated Headline, which lets you use the popular text flip effect which allows you to exchange normally fixed text components, as well as the live form editor, are also exclusive to pro users. If you need more details about the differences between free and pro, you should visit this overview.
The menu widget in action. (GIF: Elementor)
The prices for the Pro version start at 49 USD in the personal plan for a one-year license on one domain. For 99 USD, you can use Elementor on three domains, while 199 USD gets you unlimited domains. The feature set is identical on all three plans. The one-year license means that you have access to all updates and support for one year. After that year, you could still continue to use that, then increasingly outdated version but won’t receive any more updates.
Big Plans for 2018
What sets Elementor apart is its high innovation speed in terms of development. Almost every week, new features, new templates, or other novelties come to life.
Over the course of 2018, the developers want to hit an exceptional milestone. They are working to launch the Elementor Theme Builder. The tool is supposed to allow you to design all of a site’s aspects, including header, footer, as well as product pages or blog posts.
The web’s fastest growing Page Builder project does not seem to plan to slow down anytime soon.
Recently a heated debate was sparked when CSS Tricks’ Chris Coyier dared to say that achieving the goal (the What) is more important than the tool that the goal was achieved with (the How). Of course, he’s right.
The Web Tool Race
Over the past years, a real epidemy has spread. Every day, new tools, frameworks, libraries, and whatnot are released. It almost seems like every developer was trying to go their own way and establish this way as the standard. Here is what that looks like:
In the past years, I’ve been working on a relatively small web project in collaboration with a developer who was meant to lay the groundwork. After I didn’t hear anything about the state of the project in months (!!), I dared to ask him, and received an answer very similar to this one:
Many Cooks and the Spoiled Broth
Now, if both scenarios unite to form a deadly cocktail, the branch is in trouble. Because, and that’s pretty much what Coyier is complaining about, today, there are too many options and different approaches to accomplish the same thing. The newer tool is always regarded as the better one, forcing the modern developer into a constant race against time, trying to refresh his knowledge base almost every week. This is exhausting.
Trying to treat small projects as if they were the hub of the universe is equally exhausting. I don’t mind having high expectations regarding one’s own work, in the sense of professional honor. Nonetheless, we should stay realistic, as there is no award for the most complicated cutting edge website. Especially not handed out by our average client.
With a Focus on the Client, Cutting Edge Falls Off
The client only values a few things. For one, the look has to be right. It has to be modern, and support the project’s purpose. Next, the usability needs to be on point. Users have to be introduced to the page’s goal quickly, allowing for a reliable conversion into customers. Last but not least, the website mustn’t be overly expensive. “Expensive” is also defined by the client, and is unlikely to match our idea of “expensive.”
The tools we choose have to be selected in a way that does not necessarily allow for the absolute state of the art, but is sufficient for a “good enough.” We don’t have to create top sites, but preferably ones that do what they’re supposed to do. In most cases, tools that we have had in our arsenal for over two months will still do the trick.
By the way, the same applies to other branches. Buy a car. Not all of them have a rain sensor 😉 Not all of them have a car computer, satellite navigation, or a rear camera. But all of them drive. You’ll get from A to B. The rest is a question of convenience, a luxury question.
Careful When Selecting Tools
When approaching a commission, you should look for a good solution for the given case, and usually, it will be the same solution that has already been a good pick for yesterday’s project.
It is not necessary to imbibe the newest developments, and trying to work on an almost experimental level, just to be able to brag in front of your colleagues. You won’t impress your client, and you definitely won’t impress your colleagues who have been in the business for more than a few days, maybe even twenty years.
On top of that, it is very likely that you won’t be as experienced with the freshest tools than you’d be with the established solutions that you have used plenty of times already. There’s even the risk of your solution being of worse quality than what you’re usually able to put out due to your infatuation with technology. Let’s hope this doesn’t backfire.
Don’t get distracted by the tech Taliban, and their radical praise for the newest tools. Your target group does not include other web developers; your target group consists exclusively of your potential clients.
Of Course, Progress is Important
Naturally, this does not mean that you should avoid technological progress. In fact, you should be open to it. If you have a tool in your toolbox that no longer meets your requirements, you should replace it with a newer one. But only, if and when it can perform better, and this extra performance is needed for your specific project. Today, however, we experience the phenomenon of having multiple tools on the market with a nearly identical feature set, which can mostly solely be distinguished by their underlying ideological concepts.
Of course, all of this was said under the assumption that you master established tools, and are not new to the branch. Branch newcomers will have a tough time when the industry keeps tossing whole bunches of tools, all of which do the same, at them. As an established developer, however, you are able to make the right choice. Just don’t listen to the call of the tech Taliban.
I wasn’t at this conference, so I have very little context. Normally, I’d consider it a sin to weigh in on a subject brought up by looking at two out-of-context slides, but I’m only weighing in out of interest and to continue the conversation.
The idea seems to be that if you need to select an element in the DOM with JavaScript, don’t use the same selector as you would in CSS.
So if you have…
<article class="article">
</article>
…and you need to apply an event listener to that article for some reason, then don’t use…
$(".article")
(or querySelector or whatever, I assume.)
Instead, apply an attribute intended just for the JavaScript to target, like…
The idea is that you can separate jobs. The class has the job of styling, and the data attribute has the job of JavaScripting. Both can change without affecting each other.
Seems reasonable to me.
Also seems like there is plenty to talk about here. Performance, I suppose, but that’s probably the least-interesting thing since selectors are generally pretty damn fast these days. We could continue the conversation by talking about:
What naming convention?
Should you be naming events?
What if it needs to be selected for different reasons multiple times?
Can you or should you use IDs?
Is it worth avoiding DOM selection at all if you can?
There comes a time in any young app’s life when it will have to monetize. There are a number of ways to become profitable, but accepting cash is a surefire way to make this more direct. In this four-part tutorial, we’ll go over how to set up a serverless function, make it talk to the Stripe API, and connect it to a checkout form that is setup as a Vue application. This may sound daunting, but it’s actually pretty straightforward! Let’s dig in.
We’ve covered serverless concepts before but, in case you haven’t read that article, let’s talk for a minute about what we mean by “serverless” because it’s a bit of a misnomer.
The promise of serverless is to spend less time setting up and maintaining a server. You’re essentially letting the service handle maintenance and scaling for you, and you boil what you need down to functions that run certain code when a request is made. For this reason, people may refer to this as FaaS. This is really useful because you pay for what you use, rather than a large container that you might not need in its entirety. You also primarily hunker down and focus just on the code you need to run instead of babysitting a server, which really appeals to a lot of people who’d like to get up and running quickly.
But FaaS isn’t always the right tool for the job. It’s really useful for small executions but, if you have processes that might hold up resources or a ton of computation, being able to communicate with a server as you normally do might be more efficient.
What we’re going to make is a perfect use case for going serverless. Stripe checkouts are pretty seamless to integrate on both the client and server side, but we do actually need to execute some logic on the server, so we’ll use Azure to help us with this. The portal and Github integration are pretty quick to manipulate, as long as you know where to go. So by all means, let’s make it happen!
Sign up for Stripe
First, we’ll create a Stripe account. We verify our new account via email and then we’ll head over to the API section, where we can retrieve two keys. You’ll note that we’re in test mode right now, which is good! We’ll keep it like that for testing, and unveil the testing key token to use while we set up the application.
Once you’re signed in, go to the API section of your dashboard to retrieve your key.
Setting up Our Serverless Function in the Azure Portal
First, we’ll head over to the portal, (or if you don’t already have an account, you can sign up for a free trial here) and select New > Serverless Function
Setting up a new Servless Function in Azure
When we click on the Serverless Function app, we’ll be taken to a panel that asks for details to help with the setup. As you can see in the screenshot above, it will autofill most of the fields just from the app name, but let’s go over some of these options quickly:
Add in a unique name
A Resource Group (if you don’t already have one, create one)
I use the Windows OS because the Linux is still in preview, so Windows will be more stable
I use the Consumption Plan because this is the one that will have payments that scale with the use, and it will also scale automatically. The other option, App Service Plan, is good for people who prefer everything to be a bit more manual.
Choose a location that is close to your customer base, or a midpoint between two customer bases
Choose a storage, or create one as I’ve done
I’ll also check Pin to Dashboard because I want to be able to retrieve my function quickly later
This will bring you back to the main portal dashboard and let you know that your function is deploying. Once it’s done, it take you to a main screen that has all of your options. From here, we’ll want to create our function, and it will be an HTTP trigger.
We’ll select Functions under our function name, and you’ll see a little table with a plus that says “New Function”:
Once we click here, we have a few options on what we can create. We’ll pick HTTP Trigger:
We’ll be able to select the language (pick “JavaScript”) and then “Create”:
The Default Testing Function
From here, we’re given a default testing function which helps us see how this all works. If we open all of these panels and hit the Run button, we’ll see the output in logs.
Running the function in a test environment
Here’s the code we were given:
module.exports = function(context, req) {
context.log('JavaScript HTTP trigger function processed a request.');
if (req.query.name || (req.body && req.body.name)) {
context.res = {
// status: 200, /* Defaults to 200 */
body: 'Hello ' + (req.query.name || req.body.name)
};
} else {
context.res = {
status: 400,
body: 'Please pass a name on the query string or in the request body'
};
}
context.done();
};
You’ll see here that we’re passing in the context. That allows us to log, which will be shown in the lowest panel below. In the Test panel on the right, we can pass in a request body that can be used to test our application. When it runs, we see the output with a 200 status and know that everything is working. We also have a context.log for the case that it gives us a 400 error. If you’d like to play around with a serverless function and see it in action for yourself, you can create one with a free trial account.
Next Up…
Now that we have the base of our serverless function, let’s set up what we’ll need to communicate with Stripe! More to come in the next post in this series.
A key feature of Flexbox and Grid Layout is that they can deal with distributing available space between, around and inside grid and flex items. Quite often this just works, and we get the result we were hoping for without trying very hard. This is because the specifications attempt to default to the most likely use cases. Sometimes, however, you might wonder why something ends up the size that it is.
(This is a sponsored article.) Everybody’s talking about design systems, but they are more than just a trend. They are a best practice for design consistency and efficiency between designers and developers.
Back in the day, only large companies could afford the effort of building and maintaining a design system. Nowadays, with the growth of new tools and processes, they have become much more feasible for companies of all sizes.
Unlike mobile applications, the web has no set design guidelines to which a designer can refer. Instead, each web project tends to be a blank canvas. There are frameworks like Material, Bootstrap, and others which provide a base, but no set guidelines which span the web as a whole.
The result is a wide-ranging and diverse web, but one with a lack of cohesiveness, particularly in terms of user experience. Navigations differ in placement, structure, and overall design. Layouts alternate in width. Text sizes and typographic scales vary wildly. And a wide range of differing components, interactions, and user interface elements are used.
Design systems ensure consistency between apps, resulting in a more cohesive product
The lack of a set design system for the web is due to its open source nature, and lack of ownership. No company or organization has the power to enforce guidelines or standards. The closest anything or anyone comes to impacting the way we design is Google, who can affect your search rankings based on factors such as user experience, responsiveness, and code structure. On the other hand, mobile operating systems like iOS and Android have the power to enforce certain application structures, user experience practices, and standards. Design systems ensure consistency between apps, resulting in a more cohesive product, and one that is easier to use and understand for the end user. It also enhances performance and optimization, as well as accessibility.
Despite such a defined set of guidelines in both cases of iOS and Android, designers still find ways to differentiate through aspects like color, layout, and design details. In these circumstances it’s still entirely possible to achieve outstanding and unique designs which still fall within the guidelines.
Conversely, the web is an absolute blank canvas. There is the ability to take a design and user experience in any direction desired. On one hand, it’s what makes the web so attractive, diverse, and abundant. On the other hand, it can lead to a confusing experience for many people: one that is highly inaccessible, inconsistent, and uses a variety of sub-optimal and dark user experience practices.
The case of iOS and Android show just how rich and diverse a digital product or ecosystem can be, even under such regulation and moderately-strict guidelines.
This poses the question of whether a set of open source guidelines should be introduced for the entire web. Whether it comes from W3C, is a unified effort between major browsers, or is devised by a group of designers, it could improve the web for all. There would still be great scope for producing unique designs, while ensuring the web reaches much more acceptable levels of accessibility and usability as a whole. Designers and user experience professionals could contribute to this as an open source project, pushing forward the progress of the entire web.
It’s not just web applications this system should apply to. Whether it’s a blog, portfolio, landing page, or wiki, they are all still usable products. They still require important user experience considerations such as accessibility, navigation, color practices, and typography scales. Many companies consider such aspects, while many ignore them either through choice, misjudgement, or lack of consideration. It’s an area which is so fragmented under the current system, and does not work appropriately for everyone. That includes those with a disability, visual impairment, or lack of familiarity with computers and the web. These users should be designed for first.
As it stands, the primary consideration is often the design visuals: making something impressive, unique, and eye-catching. Often this desire to differentiate can lead to oversights with user experience, and design choices like unique navigation solutions which are confusing and unfamiliar to most.
Google is a prime example of a company who have developed a set of guidelines and applied them with absolute consistency across mobile and web. Whether you switch from Google Keep on iPhone, to Google Drive on the web, the user experience and design elements remain consistent. Then when switching between products on the web like Play Store or YouTube, it again remains consistent.
This ease of use and transition from one product or site to another should be a model to follow for others. It puts the user first, making for an entirely accessible and understandable experience. Google is beginning to take this even a step further, as they introduce Android apps and web-based equivalents that work at desktop size. With products like Chromebooks, it makes the transition between devices even more seamless.
The closer we can get to a cohesive design system across the web…the better it will be…for all parties involved
The closer we can get to a cohesive design system across the web as a whole, the better it will be in the long run, for all parties involved. This means having systems span much further than just one company.
IBM or Airbnb may perfect their design systems to the nth degree and apply them with excellent consistency. However, as soon as a user switches to another product or service, their design system is likely to be wholly different, from typography and layout, to navigational practices. That’s why it needs to be looked at as an issue from further afar. And apps are the closest example we have to how successful this can be as a means to improve the everyday lives of users.
Simple screenshots or flat graphics don’t sell well. Today, it takes flashier presentations. Your web design displayed on a current Apple product, your framed poster on the wall. Now, we barely have the time to make every project accordingly appealing. Here’s where turnkey mockups come into play, allowing you to stage your graphics with a single click.
I recommend double-checking the respective license before starting a project with a specific mockup. We did that already, but it’s better to be safe than sorry. Now have fun browsing!
Keith Grant discusses how HTML 5.2 has introduced a peculiar new element: . This is an absolutely positioned and horizontally centered modal that appears on top of other content on a page. Keith looks at how to style this new element, the basic opening/closing functionality in JavaScript and, of course, the polyfills that we’ll need to get cross-browser support right.
Also, I had never heard of the ::backdrop pseudo element before. Thankfully the MDN documentation for this pseudo element digs into it a little bit more.
When I saw the original article on how to recreate this animation, my first thought was that it could all be simplified with the use of preprocessors and especialy CSS variables. So let’s dive into it and see how!
The result we want to reproduce.
The structure
We keep the exact same structure.
In order to avoid writing the same thing multiple times, I chose to use a preprocessor.
My choice of preprocessor always depends on what I want to do, as, in a lot of cases, something like Pug offers more flexibility, but other times, Haml or Slim allow me to write the least amount of code, without even having to introduce a loop variable I wouldn’t be needing later anyway.
Until recently, I would have probably used Haml in this case. However, I’m currently partial to another technique that lets me avoid setting the number of items both in the HTML and CSS preprocessor code, which means I avoid having to modify it in both if I need to use a different value at some point.
To better understand what I mean, consider the following Haml and Sass:
- 6.times do
.item
$n: 6; // number of items
/* set styles depending on $n */
In the example above, if I change the number of items in the Haml code, then I need to also change it in the Sass code, otherwise things break. In a more or less obvious manner, the result is not the intended one anymore.
So we can go around that by setting the number of circles as the value of a CSS variable we later use in the Sass code. And, in this situation, I feel better using Pug:
- var nc = 6; // number of circles
.watch-face(style=`--nc: ${nc}`)
- for(var i = 0; i < nc; i++)
.circle(style=`--i: ${i}`)
We’ve also set the index for every .circle element in a similar manner.
The basic styles
We keep the exact same styles on the body, no change there.
Just like for the structure, we use a preprocessor in order to avoid writing almost the same thing multiple times. My choice is Sass because that’s what I’m most comfortable with, but for something simple like this demo, there’s nothing in particular about Sass that makes it the best choice – LESS or Stylus do the job just as well. It’s just faster for me to write Sass code, that’s all.
But what do we use a preprocessor for?
Well, first of all, we use a variable $d for the diameter of the circles, so that if we want to make them bigger or smaller and also control how far out they go during the animation, we only have to change the value of this variable.
In case anyone is wondering why not use CSS variables here, it’s because I prefer to only take this path when I need my variables to be dynamic. This is not the case with the diameter, so why write more and then maybe even have to come up with workarounds for CSS variable bugs we might run into?
$d: 8em;
.circle {
width: $d; height: $d;
}
Note that we are not setting any dimensions on the wrapper (.watch-face). We don’t need to.
In general, if the purpose of an element is just to be a container for absolutely positioned elements, a container on which we apply group transforms (animated or not) and this container has no visible text content, no backgrounds, no borders, no box shadows… then there’s no need to set explicit dimensions on it.
A side effect of this is that, in order to keep our circles in the middle, we need to give them a negative margin of minus the radius, (which is half the diameter).
Well, we get the above in WebKit browsers and Firefox, as Edge doesn’t yet support mix-blend-mode (though you can vote for implementation and please do that if you want to see it supported because your votes do count), so it shows us something a bit ugly:
The Edge result doesn’t look that good.
To get around this, we use @supports:
.circle {
/* same styles as before */
@supports not (mix-blend-mode: screen) {
opacity: .75
}
}
Not perfect, but much better:
Using @supports and opacity to fix the lack of mix-blend-mode support in Edge (live demo).
Now let’s look a bit at the result we want to get:
The desired result.
We have six circles in total, three of them in the left half and three others in the right half. They all have a background that’s some kind of green, those in the left half a bit more towards yellow and those in the right half a bit more towards blue.
If we number our circles starting from the topmost one in the right half and then going clockwise, we have that the first three circles are in the right half and have a bluish green background and the last three are in the left half and have a yellowish green background.
At this point, we’ve set the background for all the circles to be the yellowish blue one. This means we need to override it for the first half of the six circles. Since we cannot use CSS variables in selectors, we do this from the Pug code:
- var nc = 6; // number of circles
style .circle:nth-child(-n + #{.5*nc}) { background: #529ca0 }
.watch-face(style=`--nc: ${nc}`)
- for(var i = 0; i < nc; i++)
.circle(style=`--i: ${i}`)
In case you need a refresher on this, :nth-child(-n + a) selects the items at the valid indices we get for n ? 0 integer values. In our case, a = .5*nc = .5*6 = 3, so our selector is :nth-child(-n + 3).
If we replace n with 0, we get 3, which is a valid index, so our selector matches the third circle.
If we replace n with 1, we get 2, also a valid index, so our selector matches the second circle.
If we replace n with 2, we get 1, again valid, so our selector matches the first circle.
If we replace n with 3, we get 0, which isn’t a valid index, as indices are not 0-based here. At this point, we stop as it becomes clear we won’t be getting any other positive values if we continue.
The following Pen illustrates how this works – the general rule is that :nth-child(-n + a) selects the first a items:
In order to understand what we need to do next, let’s take a look at the following illustration:
The rightmost circle going from its initial to its final position (live).
The central points of the circles in the initial position are on the same horizontal line and a radius away from the rightmost circle. This means we can get to this final position by a translation of a radius $r along the x axis.
But what about the other circles? Their central points in the final position are also a radius away from their initial position, only along other lines.
All circles: initial position (dead in the middle) is a radius away from the final one for each and every one of them (live).
This means that, if we first rotate their system of coordinates until their x axis coincides with the line between the initial and final position of the central points and then translate them by a radius, we can get them all in the correct final position in a very similar manner.
We have six circles distributed evenly, so the rotation difference between any two consecutive ones is 360°/6 = 60°. Since we don’t need to rotate the rightmost .circle (the second one), that one’s at 0°, which puts the one before (the first one) at -60°, the one after (the second one) at 60° and so on.
Note that -60° and 300° = 360° - 60° occupy the same position on the circle, so whether we get there by a clockwise (positive) rotation of 300° or by going 60° the other way around the circle (which gives us the minus sign) doesn’t matter. We’ll be using the -60° option in the code because it makes it easier to spot a convenient pattern in our case.
However, it’s very repetitive code that can easily be compacted. For any of them, the rotation angle can be written as a function of the current index and the total number of items:
This works in WebKit browsers and Firefox 57+, but fails in Edge and older Firefox browsers due to the lack of support for using calc() inside rotate() functions.
Fortunately, in this case, we have the option of computing and setting the individual rotation angles in the Pug code and then using them as such in the Sass code:
- var nc = 6, ba = 360/nc;
style .circle:nth-child(-n + #{.5*nc}) { background: #529ca0 }
.watch-face
- for(var i = 0; i < nc; i++)
.circle(style=`--ca: ${(i - 1)*ba}deg`)
Note that we don’t need both the 0% (from) and 100% (to) keyframes. Whenever these are missing, their values for the animated properties (just the transform property in our case) are generated from the values we’d have on the animated elements without the animation.
In the circle animation case, that’s rotate(var(--ca)). In the pulse animation case, scale(1) gives us the same matrix as none, which is the default value for transform so we don’t even need to set it on the .watch-face element.
We make the animation-duration a Sass variable, so that, if we ever want to change it, we only need to change it in one place. And finally, we set the animation property on both the .watch-face element and the .circle elements.
$t: 4s;
.watch-face {
position: relative;
animation: pulse $t cubic-bezier(.5, 0, .5, 1) infinite alternate
}
.circle {
/* same as before */
animation: circle $t infinite alternate
}
Note that we’re not setting a timing function for the circle animation. This is ease in the original demo and we don’t set it explicitly because it’s the default value.
We could also tweak the translation distance so that it’s not exactly $r, but a slightly smaller value (something like .95*$r for example). This can also make the mix-blend-mode effect a bit more interesting:
The above is for six .circle petals in particular. Now we’ll see how we can adapt it so that it works for any number of petals. Wait, do we need to do more than just change the number of circle elements from the Pug code?
Well, let’s see what happens if we do just that:
The result for nc equal to 6 (left), 8 (middle) and 9 (right).
The results don’t look bad, but they don’t fully follow the same pattern – having the first half of the circles (the bluish green ones) on the right side of a vertical symmetry line and the second half (yellowish green) on the left side.
We’re pretty close in the nc = 8 case, but the symmetry line isn’t vertical. In the nc = 9 case however, all our circles have a yellowish green background.
So let’s see why these things happen and how we can get the results we actually want.
Making :nth-child() work for us
First off, remember we’re making half the number of circles have a bluish green background with this little bit of code:
But in the nc = 9 case, we have that .5*nc = .5*9 = 4.5, which makes our selector :nth-child(-n + 4.5). Since 4.5 is not an integer, the selector isn’t valid and the background doesn’t get applied. So the first thing we do here is floor the .5*nc value:
This is better, as for a nc value of 9, the selector we get is .circle:nth-child(-n + 4), which gets us the first 4 items to apply a bluish green background on them:
However, we still don’t have the same number of bluish green and yellowish green circles if nc is odd. In order to fix that, we make the circle in the middle (going from the first to the last) have a gradient background.
By “the circle in the middle” we mean the circle that’s an equal number of circles away from both the start and the end. The following interactive demo illustrates this, as well as the fact that, when the total number of circles is even, we don’t have a middle circle.
Mathematically, this is the intersection between the set containing the first ceil(.5*nc) items and the set containing all but the first floor(.5*nc) items. If nc is even, then floor(.5*nc) and ceil(.5*nc) are equal and our intersection is the empty set?. This is illustrated by the following Pen:
If we have 3 items, our selector is :nth-child(n + 2):nth-child(-n + 2), which gets us the second item (the intersection between the {2, 3, 4, ...} and {2, 1} sets)
If we have 4 items, our selector is :nth-child(n + 3):nth-child(-n + 2), which doesn’t catch anything (the intersection between the {3, 4, 5, ...} and {2, 1} sets is the empty set ?)
If we have 5 items, our selector is :nth-child(n + 3):nth-child(-n + 3), which gets us the third item (the intersection between the {3, 4, 5, ...} and {3, 2, 1} sets)
If we have 6 items, our selector is :nth-child(n + 4):nth-child(-n + 3), which doesn’t catch anything (the intersection between the {4, 5, 6, ...} and {3, 2, 1} sets is the empty set ?)
If we have 7 items, our selector is :nth-child(n + 4):nth-child(-n + 4), which gets us the fourth item (the intersection between the {4, 5, 6, ...} and {4, 3, 2, 1} sets)
If we have 8 items, our selector is :nth-child(n + 5):nth-child(-n + 4), which doesn’t catch anything (the intersection between the {5, 6, 7, ...} and {4, 3, 2, 1} sets is the empty set ?)
If we have 9 items, our selector is :nth-child(n + 5):nth-child(-n + 5), which gets us the fifth item (the intersection between the {5, 6, 7, ...} and {5, 4, 3, 2, 1} sets)
Now that we can select the item in the middle when we have an odd number of them in total, let’s give it a gradient background:
The reason why we use a top to bottom gradient is that, ultimately, we want this item to be at the bottom, split into two halves by the vertical symmetry line of the assembly. This means we first need to rotate it until its x axis points down and then translate it down along this new direction of its x axis. In this position, the top of the item is in the right half of the assembly and the bottom of the item is in the left half of the assembly. So, if we want a gradient from the right side of the assembly to the left side of the assembly, this is a top to bottom gradient on that actual .circle element.
Now all that’s left to do is make the symmetry axis vertical.
Taming the angles
In order to see what we need to do here, let’s focus on the desired positioning in the top part. There, we want to always have two circles (the first in DOM order on the right and the last in DOM order on the left) symmetrically positioned with respect to the vertical axis that splits our assembly into two halves that mirror each other.
The fact that they’re symmetrical means the vertical axis splits the angular distance between them ba (which is 360° divided by the total number of circles nc) into two equal halves.
Angles formed by vertical symmetry line and the radial lines to the central points of the top angles are both equal to half a base angle (live).
So both are half a base angle (where the base angle ba is 360° divided by the total number of circles nc) away from the vertical symmetry axis, one in the clockwise direction and the other one the other way.
The upper half of the symmetry axis is at -90° (which is equivalent to 270°).
So in order to get to the first circle in DOM order (the one at the top on the right), we start from 0°, go by 90° in the negative direction and then by half a base angle back in the positive direction (clockwise). This puts the first circle at .5*ba - 90 degrees.
How to get the angle the first circle is placed at (live).
After that, every other circle is at the angle of the previous circle plus a base angle. This way, we have:
the first circle (index 0, selector :nth-child(1)) is at ca? = .5*ba - 90 degrees
the second circle (index 1, selector :nth-child(2)) is at ca? = ca? + ba = ca? + 1*ba degrees
the third circle (index 2, selector :nth-child(3)u) is at ca? = ca? + ba = ca? + ba + ba = ca? + 2*ba degrees
in general, the circle of index k is at ca? = ca??? + ba = ca? + k*ba degrees
So the the current angle of the circle at index i is .5*ba - 90 + i*ba = (i + .5)*ba - 90 degrees:
- var nc = 6, ba = 360/nc;
//- same as before
.watch-face(style=`--c0: #529ca0; --c1: #61bea2`)
- for(var i = 0; i < nc; i++)
.circle(style=`--ca: ${(i + .5)*ba - 90}deg`)
This gives our final Pen, where we only need to change nc from the Pug code to change the result:
