As time goes on, web design is getting more innovative. Rather than just displaying information, websites are works of art, featuring complex animations, unique layouts, and micro-interactions. So many of these things are possible through CSS. CSS gives style to normal, boring web pages, and enables everything that makes websites enjoyable to interact with. 2019 brings with it plenty of new horizons for web design, and these are the 10 best CSS trends that will define the year.
1. Mobile First
Of all the CSS trends, the most current and continuing to grow CSS “sentiment” is towards Mobile First. Historically, web designers have developed web applications for computers first, and then added responsive web design to make sure the web looks good when viewed on a tablet or a phone. This CSS trend is shifting towards designing for mobiles first, and then add responsive design to make a site work on desktops and laptops.
50/50 is an easy way to achieve web design for responsive webs. With 50/50 design, the screen can show two pages on large screens and one page on narrow screens.
Most typical cards are rectangles with an image and some text. Cards have become a common structure for organizing headlines, images, and text on an equal plane. Cards can be small or large, with or without pictures, and with or without shadows. One of the most notable CSS trends and ubiquitous examples is Google Feed cards.
That new contender is Grid. Still young and only seeing use on about 2.25% of page loads, it has still skyrocketed in popularity, only representing 0.25% of page loads at the start of 2018.
Grid is being hailed as better than Flexbox. Flexbox gives you control of vertical or horizontal alignment, but not both at once. Grid, on the other hand, does.
CSS experts attribute the lack of popularity to the fact that most major websites are not using it. After all, that data above is based on page views, not the raw number of pages that use Grid. It was only fairly recently that major sites adopted Flexbox, so it makes sense that they don’t want to make the switch just yet.
2019 will definitely see the growth of Grid, however, because it unlocks a degree of creative freedom that other options do not offer.
4. CSS Writing Mode
Not all languages are written and read from left to right. For languages that go in other directions, you can use the writing-mode CSS property.
Flow text from top to bottom or from right to left and adjust the horizontal and vertical values. You can even display text sideways vertically, rotate the text for certain designs, and mix scripts.
5. Mobile Animations
Animations as a tool for engagement are increasingly popular. Websites will start to use more and more animated loading icons, page loads with limited design, etc. to keep the user’s attention.
An example of this from a popular website is YouTube. Open the YouTube mobile app and scroll through the videos. If you stop for a second, the video will autoplay with the sound off and show captions.
Animations are also used as indicators for an action or a task. Animated buttons and lists are becoming common too. You read all about using CSS animations from Mozilla.
6. Popular Frameworks (Bulma, Tailwind, Bootstrap 4, etc.)
CSS frameworks have been around for a while, but they’ve only been growing in popularity in recent years. If you need a primer on what a framework is, read this.
“A framework is a standardized set of concepts, practices and criteria for dealing with a common type of problem, which can be used as a reference to help us approach and resolve new problems of a similar nature.”
As we move to a more mobile web, frameworks are adjusting to compensate. Styling and design are changing, animations and action are becoming more common, and a focus on simplicity and end user experience are more important than ever!
In 2019, many well designed frameworks are taking the lead and helping developers and designers to ship faster than ever. A few of the most notable frameworks being used around the web in 2019 are:
Foundation – Responsive, mobile-first framework and used as enterprise solution;
Bootstrap 4 – Bootstrap is one of the biggest CSS frameworks used worldwide, version 4 comes with new features for color schemes and utility classes;
Materialize – Popular framework focused on material design styles;
With websites becoming almost as synonymous as having your own profile on social networks, more users are turning to simpler solutions and single page options to send traffic out to other locations.
Common examples include:
Linktree – Simple page with links to your socials, products, etc.;
Carrd – Simple, free, fully responsive one-page sites for pretty much anything;
About.me – More professional focused portfolio site, similar to LinkedIn but with room for creativity;
Instapage – Top landing page builder for businesses and startups;
These single page websites are being taken further with the creative use of CSS and styling to enhance the experience. The Next Web highlighted ‘large and experimental navigations’ as one of their ‘10 exciting web design trends you can’t hide from in 2019’. So why are people moving to these interesting layouts?
Because of action. With the focused large buttons and navigation, users immediately click to the desired location. Whether that be a shop, informational page with hours/details, or just a new video/song.
More and more websites are simply set up as directing points for companies, individuals, or groups to send traffic to and then distribute out. Musicians use Linktree and other services to share their new songs on all streaming platforms, and get a cut of the affiliate revenue in the meantime.
8. Variable Fonts
Highlighted by Carrie Cousins for Designmodo’s ‘Top 17 Web Design and UI Trends for 2019’, variable fonts are defined as “a collection of master styles, with one central ‘default’ master (usually the Regular font style) and multiple registered “axes” which tie the central master to the other masters. For example, the Weight axis might connect a Light style master to the default style and through to the Bold style master. The individual styles that can be located along this axis are called “instances”.
What this means is that fonts are more responsive and seamless across devices and platforms. You can scale the width, sizing, and other aspects of the font more easily without jumping from font weight to font weight or switching fonts entirely.
Check out an example of the variable typeface ‘Amstelvar’ on GitHub. Also read the full analysis on variable fonts and how they will change the web from Google.
9. Scroll Snapping
Scroll snapping is one of the relatively new CSS trends, and is a technique used for snapping users to certain scroll points. Rather than a fluid motion down the page or left to right, you can have the page scroll in increments. Popular uses of this are for swiping through products or details on a page, scrolling through a book/reading experience, and sliding down a page with incremental blocks of information.
Last but not least of the CSS trends is the use of full screen inputs. More and more sites are using full screen for inputs like signups and logins, instead of using only a small part of the page. Full screen often uses a screen overlay or modal instead of redirecting to a new page.
If you enjoyed this article regarding the best CSS trends for 2019 and want even more CSS info check out our other CSS Guides.
I did a bunch of research on proxy-browsers for a few projects I worked on. Rather than sitting on it all, I figured I’d write a post sharing what I learned in case it’s helpful to anyone else. This post looks at the general architecture of proxy browsers with a performance focus.
In the original story of the Wizard of Oz, the Emerald City isn’t actually green nor made entirely of emeralds. All of that came later. In the original story, before entering the city each person had to put on a pair of glasses. These glasses, they were told, would protect them from the bright glow of all the emeralds that would surely damage their sight. These glasses were attached and never removed. You wore them while eating, while going to the bathroom, while walking outside—you wore them everywhere and all the time.
This was all a ruse. The glow of the city wouldn’t damage anybody’s sight because there was no glow. That all came from the glasses which just happened to be tinted green. Through the lens of those glasses, everything glowed. The lens through which those people viewed their world shaped their perception of it.
I’d venture to say that most developers and designers are not big fans of proxy browsers—assuming they pay attention to them at all. They don’t behave in ways a typical browser does, which leads to frustration as we see our carefully created sites fall apart for seemingly no reason at all. And frankly, most of us don’t really need to use them on a day-to-day basis. Through the lens we view the web, proxy browsers are merely troublesome relics of a time before the idea of a “smartphone” was anything other than a pipedream.
But our view of the web is not the only view of the web. People all over the world face challenges getting online—everything from the cost of data and poor connectivity to religious and political obstacles. In these environments proxy browsers are far from troublesome; they are essential.
So while most of us building for the web have never used a proxy browser (outside of the quick spot check in Opera Mini, perhaps), they remain incredibly popular globally. Opera Mini, the most popular of all proxy browsers, boasts more than 250 million users. UC, another popular proxy browser, boasts 100 million daily active users and is the most popular mobile browser in India, China and Indonesia.
These browsers perform optimizations and transcoding that can provide significant improvements. Several proxy browsers claim up to 90% data savings when compared to a typical browser. That’s the difference between a 2MB site and a 200kb site—nothing to sneeze at.
To understand how they accomplish this—and why they behave the way they do—we first need to revisit what we know about how browsers work.
Typical Browser Architecture
A typical modern browser goes through a series of steps to go from the URL you enter in your address bar to the page you ultimately see on your screen. It must:
Resolve the DNS
Establish TCP connection(s) to the server(s)
Request all the resources on a page
Construct a DOM and CSSOM
Build a render tree
Paint to the screen
That’s a very simplified list and some of them can happen in parallel, but it’s a good enough representation for the purpose of highlighting how proxy browser architecture differs.
We can break these steps out into two general buckets. Steps 1-3 are all network constrained. How quickly they happen, and the cost, depends mostly on the characteristics of the network: the bandwidth, latency, cost of data, etc.
Steps 4-8 are device constrained. How quickly these steps happen depends primarily on the characteristics of the device and browser: the processor, memory, etc.
Proxy browsers intercede on behalf of the user in an attempt to reduce the impact of one, or both, of these buckets. You can broadly classify them into two categories: browsers with proxy services, and remote browsers.
Browsers with proxy services
The first category of proxy browsers are really just your plain-old, everyday browser that happens to offer a proxy service. These browsers alter the typical browser behavior only slightly, and as a result they provide the least benefit for end users as well as—usually—the least noticeable impact on the display and behavior of a web site. (While not really tied to a browser, look at Google’s search transcoding service for an example of how substantially a proxy service could alter the display of a page.)
Instead of requests being routed directly from the client to the web server, they are first routed through some intermediary layer of servers (Google’s servers, UC’s servers, Opera’s servers, etc). This intermediary layer provides the proxy service. It routes the request to the web server on behalf of the client. Upon receipt of the request, it sees if there are any optimizations it can provide (such as minification, image compression, etc) before passing back the potentially altered response to the client.
The browser-specific behavior (steps 4-8) remains the same as the typical browsers you’re used to testing on. All of the optimizations that take place focus primarily on the reducing the impact on the network (1-3).
There are many examples but at the moment of writing some of the more popular options in this category are Google’s Data Compression tool (Flywheel), UC Web’s Cloud Boost, and Opera Turbo.
Remote browsers push the limits a bit more. They aggressively optimize as much as possible providing a much larger benefit for the end user, but also a lot more trouble for developers. (If that bothers you try to remember that the proxy browsers exist because users need them, not because developers do.) These are the browsers you more typically think of when hearing the term “proxy browser”. With the increase in browsers offering proxy services, I think referring to these as remote browsers can be a helpful way of distinguishing them.
Unlike their more conservative brethren, remote browsers are not content to merely make a few optimizations on the network side of things. They’ve got more ambitious goals.
When a website is requested through a remote browser, the request is routed through an intermediary server first before being forwarded on to the web server. Sounds familiar right? But here’s where remote browsers start to break away from the traditional browser model.
That’s why calling them “remote browsers” makes so much sense. The browser as we know it is really contained on the server. The application on the phone or tablet is nothing more than a thin-client that is capable of serving up some proprietary format. It just so happens that when it serves that format up, it looks like a web page.
The most important thing to remember for remote browsers is that because all they are doing is displaying a snapshot of a page, anything that might change the display of that page requires a trip back to the server so an updated snapshot can be generated. We’ll discuss that in more detail in a later post as the implications are huge and the source of most proxy browser induced headaches.
There are many options, but Opera Mini, UC Mini and Puffin are some of the more popular.
A website consists of many files: text content, stylesheets, scripts, media content, and so on. When you’re building a website, you need to assemble these files into a sensible structure on your local computer, make sure they can talk to one another, and get all your content looking right, before you eventually upload them to a server. Dealing with files discusses some issues you should be aware of so you can set up a sensible file structure for your website. Some of the following information may be basic to more advanced users, but perhaps can be used as a reminder guide. Let’s go ahead and further discuss how to manage website files locally.
Where should your website live on your computer?
When you are working on a website locally on your own computer, you should keep all the related files in a single folder that mirrors the published website’s file structure on the server. This folder can live anywhere you like, but you should put it somewhere where you can easily find it, maybe on your Desktop, or at the root of your hard drive. For the optimal setup you could utilize cloud storage that is accessible locally on multiple clients (including mobile) with services like Dropbox and Microsoft Onedrive.
Choose a place to store your website projects. Here, create a new folder called web-projects (or similar). This is where all your website projects will live.
Inside this first folder, create another folder to store your first website in. Call it test-site (or something more imaginative).
An aside on casing and spacing
You’ll notice that throughout this guide, we ask you to name folders and files completely in lowercase with no spaces. This is because:
Many computers, particularly web servers, are case-sensitive. So for example, if you put an image on your website at test-site/MyImage.jpg, and then in a different file you try to invoke the image as test-site/myimage.jpg, it may not work.
Browsers, web servers, and programming languages do not handle spaces consistently. For example, if you use spaces in your filename, some systems may treat the filename as two filenames. Some servers will replace the spaces in your filenames with “%20” (the character code for spaces in URIs), breaking all your links. It’s better to separate words with dashes or underscores: my-file.html or my_file.html.
For these reasons, it is best to get into the habit of writing your folder and file names lowercase with no spaces, at least until you know what you’re doing. That way you’ll bump into fewer problems.
What structure should your website have?
Next, let’s look at what structure our test site should have. The most common things we’ll have on any website project we create are an index HTML file and folders to contain images, style files, and script files. Let’s create these now:
index.html: This file will generally contain your homepage content, that is, the text and images that people see when they first go to your site. Using your text editor, create a new file calledindex.html and save it just inside your test-site folder.
images folder: This folder will contain all the images that you use on your site. Create a folder called images, inside your test-site folder.
styles folder: This folder will contain the CSS code used to style your content (for example, setting text and background colors). Create a folder called styles, inside your test-site folder.
Note: On Windows computers, you might have trouble seeing the file names, because Windows has an annoying option called Hide extensions for known file types turned on by default. Generally you can turn this off by going to Windows Explorer, selecting the Folder options… option, unchecking the Hide extensions for known file types checkbox, then clicking OK. For more specific information covering your version of Windows, do a Yahoo search!
To make files talk to one another, you have to provide a file path between them — basically a route so one file knows where another one is. To demonstrate this, we will insert a little bit of HTML into our index.html file, and make it display the image you chose.
Copy the image you chose earlier into your images folder.
Open up your index.html file, and insert the following code into the file exactly as shown.
<!DOCTYPE html><html><head><metacharset="utf-8"><title>My test page</title></head><body><imgsrc=""alt="My test image"></body></html>
The line <img src="" alt="My test image"> is the HTML code that inserts an image into the page. We need to tell the HTML where the image is. The image is inside the images directory, which is in the same directory as index.html. To walk down the file structure from index.html to our image, the file path we’d need is images/your-image-filename. For example, our image is called firefox-icon.png, so the file path is images/firefox-icon.png.
Insert the file path into your HTML code between the double quote marks of the src="" code.
Save your HTML file, then load it in your web browser (double-click the file). You should see your new webpage displaying your image!
Some general rules for file paths:
To link to a target file in the same directory as the invoking HTML file, just use the filename, e.g.my-image.jpg.
To reference a file in a subdirectory, write the directory name in front of the path, plus a forward slash, e.g. subdirectory/my-image.jpg.
To link to a target file in the directory above the invoking HTML file, write two dots. So for example, if index.html was inside a subfolder of test-site and my-image.png was inside test-site, you could reference my-image.png from index.html using ../my-image.png.
You can combine these as much as you like, for example ../subdirectory/another-subdirectory/my-image.png.
For now, this is about all you need to know.
Note: The Windows file system tends to use backslashes, not forward slashes, e.g. C:\windows. This doesn’t matter — even if you are developing your web site on Windows, you should still use forward slashes in your code.
What else should be done?
That is about it for now. Your folder structure should look something like this:
Feel free to share your perhaps newly found information regarding how to manage website files locally on your pc. Spread the wealth (of knowledge).
WordPress inc and lib folders (directories) aren’t something that I would say belong solely in themes or only in plugins. Instead, I’ve used the inc directory and lib directory in both themes and plugins.
The inc Directory
As my general rule, I use the inc directory primarily to place collections of functions that are related to core functionality but aren’t necessarily meant to clutter up the primary core of the theme or plugin.
For example, if I’m working on a theme and I have a collection of functions for said theme that I use as helper functions, I’d much rather create inc/helpers.php than to drop them in functions.php. Over time, more helpers can be added.
In more specific cases, I also use the inc directory as a way to store core theme files such as theme-customizer.php or custom-header.php. This way, these files are focused solely on a single purpose and are easier to maintain over time. Plus, they are self-descriptive.
This keeps functions.php lean, and it keeps procedural programming files slightly more organized than having one giant “god-file” by the time of delivery.
In the case of plugins, I generally use object-oriented programming so the inc directory is normally used to hold additional classes that I write that are used as part of the core plugin file, but are dependencies.
This means that if I have the core plugin that depends on, say, a custom CSV parser or a serialization / de-serialization class, then these files would reside in inc.
The lib Directory
In short, the lib directory is used for third-party libraries. That is, these are used to make sure that I place code written by another author or team of developers in a place that I can easily retrieve (and attribute – don’t forget! :)) in my project.
Also, I know that an alternative to this is using a vendors directory. Though I’ve seen the convention and think it’s just as good, I’ve personally just stuck with lib.
Please feel free to share to this information to anyone who would like to learn more about the use of WordPress inc and lib folders. Of course also feel free to submit a comment.
If you want a recommendation of some high quality WordPress themes, plugins, and other digital assets, you should check out what envato.com is currently offering below.
Using web fonts can be a great way to improve the look and feel of your website. I love tinkering with different font combinations on websites and seeing the changes they make. Unfortunately, adding web fonts to your site adds extra overhead to your site and can often slow your page load times. If you’ve worked hard to ensure that your application has a fast load time, the last thing you want to do is slow it down with extra HTTP requests that carry unnecessary weight.
There might be a time when you know in advance which particular letters of a web font that you’ll need. This often occurs when you’re using a web font in a logo or heading. Fortunately, Google Fonts allows you to specify the exact text that you might be using in the text= value in your font request URL.
For example, you would call the font resource like so:
By specifying the exact text you require, Google Fonts will provide you with a font file that is up to 90% smaller than the original file size! Whoa! In order to add more letters, simply add more characters to the text value in the font request URL.
On this page, only text was needed for the H1 tags in the header and footer. By specifying just the text you need, you manage to reduce the original file size from 18 KB to 3 KB.
CHOOSE A SUBSET
The average webpage often doesn’t require the entire unicode character set of a font file, which means it is best to restrict the character subset to the characters that your page requires. There is no need to support a language set that your site may never use!
In order to use this functionality, you simply need to use the subset=value in your font request URL.
Open Sans, which is one of the most popular Google web fonts, provides support for 20+ languages, and comes in at 217 KB total, but only 36 KB when restricted to a latin subset.
COMBINE MULTIPLE FONTS
Depending on your application, you might want to use font combinations to enhance the design. Instead of making a separate request for each font file, rather consider chaining the request together. To request multiple font families, separate the names with a pipe character (|).
In the request URL above, I am asking for the Yellowtail font and the Roboto Condensed font in one request. This simple trick will improve the load times of your font families.
PUTTING IT ALL TOGETHER
Because we want to keep our website pages as lean and fast as possible, this functionality allows us to combine all of these parameters together to produce a minimal font set. There is no reason why you can’t add web fonts to your site and still achieve fast load times!