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!
I’ve noticed in the comments of other posts recently that some readers would like more “tips and tricks” articles, particularly about CSS. So in today’s post, I’ll be providing what I hope is a useful introduction to a bit of CSS “trickery” that can be used to create compelling microinteractions across your website. Specifically, we’ll be learning how to create CSS transitions and animations. We’ll also be talking about when and where you might want to use them.
What Are CSS Transitions and Animations?
This kind of language maturity, enabled by better browsers and higher web standards (among other things), has been a huge boon to web designers who double as front end developers. They can now do more with less and the whole process of web design/development has become a bit easier.
Nevertheless, CSS transitions and animations are still considered advanced uses of CSS. A spectrum of coding I try to stay away from in most of my articles since I do not consider myself an “advanced developer”–even in language as accessible as HTML or CSS.
That said though, after reading up on W3Schools and elsewhere I think a sufficiently simple introduction to these concepts is within the grasp of not only myself but a good deal of the WTG readership as well.
To begin, I think we need to have a really good idea of what, exactly, CSS transitions and animations are before jumping into examples and code.
A CSS transition allows you to change the property values of an element over a given duration that you set. To create a transition you must first identify which CSS property you want to add an effect to and then specify the duration of the effect. If no duration is set, the transition will not occur.
There are four transition properties:
transition-delay – specifies the delay, in seconds (s), you would like to assign your transition effect.
transition-duration – specifies the duration, in seconds (s) or milliseconds (ms), you would like to assign your transition effect.
transition-property – specifies the name of the CSS property your transition effect is meant for.
transition-timing-function – Specifies the speed curve of the transition effect. Meaning, the type of speed variation you want to select for your transition effect. There is no “fast” or “slow” options. Instead there are speed curve options that go from one speed to another. Such as “ease” which tells your effect to start slow, then go fast, then end slowly.
To create a transition you only need to change one of these properties over the duration you choose. However, it is possible to change more than one property at the same time; resulting in more dramatic transitions.
Where CSS transitions are all about altering element properties as they move from state to state, CSS animations are dependent on keyframes and animation properties.
keyframes – keyframes are used to define the styles an element will have at various times.
animation properties – animation properties are used to assign @keyframes to a specific element and determine how it is animated.
There are eight animation properties:
animation-delay – specifies a delay for the start of an animation.
animation-direction – specifies whether an animation should play in reverse direction or alternate cycles.
animation-duration – specifies how many seconds or milliseconds an animation takes to complete one cycle.
animation-fill-mode – specifies a style for the element when the animation is not playing. Such as when it is finished or when it has a delay.
animation-iteration-count – specifies the number of times an animation should be played.
animation-name – specifies the name of the @keyframes animation.
animation-play-state – specifies whether the animation is running or paused.
animation-timing-function – specifies the speed curve of the animation.
The examples below will show you how these things are used together in various ways. Once you understand the relationships between them you’ll be able to figure out all kinds of interesting ways to use them.
A Quick Note on Vendor Prefixes
In your personal usage of CSS transitions and animations you will most likely need to use vendor prefixes. In some of the code below you will no doubt notice some vendor prefixes. Many of the source examples do not contain vendor prefixes, so if you want to see what the code looks like without them you can check there; I thought it might be helpful to provide a fuller picture.
For the uninitiated, when I say “vendor prefix” I’m referring to a prefix that needs to be added to your CSS based on the range of browsers you want to support your transitions and animations.
A good resource for identifying the necessary prefixes for each browser is caniuse.com. You can also check out the respective pages for transitions and animations on W3Schools. Or, if you’d like to avoid the mess of prefixes altogether, you can use a tool like Bourbon.io.
CSS Transition Examples
The CSS transition examples below are all transitions I’ve found from various sources that show what’s possible with these relatively new CSS capabilities. I’ve chosen to recreate the examples I found using CodePen so you can easily take a peak at the HTML and CSS required for each example while also seeing it in action 1. Linear
Again, the CSS animation examples below are from various sources around the web. Just as above, the CodePen allows you to see the animation and the required code in one place. You can also follow my source links to get more information (in some cases) on each example. 1. Pulse
Potential Use Cases for CSS Transitions & Animations
As I mentioned above, CSS transitions and animations are ideal for creating compelling and delightful microinteractions across your website. A lot of great WordPress themes and plugins come with some of these behaviors in place. A good example being the Divi Builder, which allows you to control transitions and animations within its module controls.
You may however wish to take the basics above and apply them other areas of your site in which a theme or plugin author has not given you easy control over. The following ideas might help you get started.
An email opt-in form that makes a delightful entrance and exist; such as bouncing in and folding closed to disappear.
A form that shakes when the essential information is not and someone attempt to submit it as finished.
Buttons that fold open, bounce, shake, or in some other way respond to hovering and clicking.
Preview images that turn over to reveal more information.
Subtle background graphics that move, creating depth.
Beautiful charts that spring into action as they load.
Google Doodle style experiments, logos, and more.
Games (for the really ambitious).
Ads that you can interact with or that subtly change shape to draw attention.
Beautiful product displays that rotate and respond to the mouse.
Beautiful stat counters.
And whatever else your imagination can think up.
Inspiring Showcases of CSS Transitions and Animations
If you need more visual stimulus than a list of ideas, I’ve take the liberty of compiling a small but impressive showcase of inspiring CSS transitions and animations that I hope will show off the potential illustrated in the rather basic examples I created above.
Logos in Pure CSS
Logos in Pure CSS is a great showcase of world famous logos re-created with nothing but CSS. In their current form they use animations and transitions to show how they are made and how they stack up against their traditional counterparts. However, I think it’s important to note that just creating your logo in HTML/CSS opens up a lot of interesting possibilities.
In Pieces is a magnificent (and highly complex) use case of CSS animation. It’s an interactive exhibition of the evolution of 30 species of animals. Truly breathtaking and a great indicator of just how powerful a tool CSS can be.
In your quest to master CSS transitions and animations, there is a good chance that you’ll need or want more detail than I am able to provide in this post. Additionally, someone else’s writing style may be a bette fit for the way you think. That’s why I’ve compiled a short list of other useful resources and tutorials below for you to take advantage of.
CSS transitions and animations are an extremely useful and versatile set of capabilities. You can do small subtle things or big in-your-face impressive things. But either way, it all starts with mastering the basics and moving on from there.
I hope this post is a welcome change of pace for those who have been requesting more CSS related content. If you have any more thoughts or requests on this post or future posts then please feel free to drop us a line in the comments section below.
A data table can be a pain to work with, perhaps comparable to herding cats or taming a lion. Tons of similar-looking, heavily-nested markup can be viewed as completely inflexible. One of the biggest problems I ever encountered was working on a particular company, whose content was almost exclusively data tables, it involved making tables’ cells line up nicely not only with each other, but also with those cells in other tables on the page.
Example of a data table with css:
There are a lot of headaches we encounter when building tables, and I imagine most of you reading this article will nod along to every point I make; it will be something that will have annoyed us all at some point or another. What this particular (and very specific) problem boils down to is trying to consistently format, size and align complex data layouts across multiple tables. Imagine a financial report; loads of tables of data with differing numbers of cells and columns that—from a purely aesthetic perspective—need to line up in some neat, coherent fashion. Achieving this is made very difficult by a number of different factors…
Tables lay out their cells—by default—in a rather unusual, almost haphazard way. There seems to be no rhyme or reason behind how and why they are rendered at the widths they are, which leads to columns and cells of differing sizes.
In order to have cells span several columns (and rows, but that doesn’t pose the same problems), we have to use the colspan attribute. To have a cell spanning two columns we would write <t[h|d] colspan="2">. These are often unmanageable, and it can be confusing to remember what all your colspans should add up to.
Resizing one cell in one row can, and usually will, affect the layout of the entire table. This is is because all cells’ boundaries have to line up with the boundaries of the rest of the row and column in which it sits. You can’t just change the width of one cell, you have to change them all. This means that, for example, spanning one cell across xcolumns might mean having to update a whole load more colspans elsewhere in thetable.
Tables next to tables
The above problems are further compounded when you begin laying out multiple different tables on any given page. In Sky Bet world, this was pretty much every page. One table’s rendered layout might be vastly different to the tables above and/or below it, creating an unsightly mess of misaligned columns. You might have a tablewith no colspans above a table with some colspans, above a table with lots of awkward colspans. You might have a table with lots of cells above a table with very few. You might have any combination of amounts of cells and amounts of colspans. It all gets very hairy, very quickly.
I’ve come up with what I feel is a solid, very pragmatic solution.
There are two parts to solving this problem. Firstly we need to standardize the number of cells in every table, and then we need to force these cells to all be the same width. Think of this as a grid system for tables.
Think about page layouts that adhere to a grid system; you might have a 24 column grid, but your page might only have two main columns which span, say, 16 and eight columns respectively. You can’t see the 24 columns, but they’re there. You might then have a large footer broken into three columns of eight (again, adding up to 24).
We need to apply this model to tables; we shall give all tables 24 columns, and then use a generous amount of colspans to knock our cells through into each other, into more useful layouts. Now every table we build will be based on a 24 column grid which will, firstly, make everything more consistent, and, secondly, it will make our maths much simpler. We just need to make sure every row’s colspan values add up to 24 every time.
This does mean that every cell in the table now has to carry a colspan, but as I said, this solution is a pragmatic one.
The reason we pick 24 is because it can take halves, thirds, quarters, sixths, eighths and twelfths; we can make a lot of layouts if we have 24 columns to play with.
For all this is more markup, it does mean we can begin to standardise our tables’ layouts so that multiple tables on the same page can share a lowest common multiple and are now able to be aligned to one another.
The short version of this section is basically: we are setting up a grid system for ourtables.
Equal width columns
It’s all well and good that all our tables have the same number of columns, but that doesn’t escape the fact that browsers will still render every table differently, and that the size of these cells will always vary. There’s no point having a 24 column table-grid-system if each column is a different width. Thankfully, this is the easiest part of the puzzle to solve and, probably, the most interesting part of this article: table-layout: fixed;.
Now it’s time to tame a data table with css.
There is a little known, and even less used, CSS property called table-layout. table-layout basically tells a browser how to render the columns in a table, and is, by default, set to auto. auto means that the browser will automatically render the cells in a table based on their width, which leads to the differently and inconsistently sized columns.
Interestingly, table-layout: fixed; is the backbone of my pure CSS, equal-width tabs.
Setting table-layout to fixed however, tells the browser to render every cell the same width as each other. Equally-sized table cells right out of the box!
Combining the two
By giving our tables a common grid system of 24 columns, and ensuring these columns are all of equal width, we can begin throwing together all manner of layouts.
I would propose that you opt into the table-grid-system via a simple helper class, perhaps .table-grid:
Every time we want to build a table to a fixed and consistent layout, we simply invoke the grid and lay it out to that.
Hopefully now you’ve gained an edge and can control a data table with css on your project(s).
User experience is often an overlooked aspect of website design, which is unfortunate, really, because it plays an important and essential role in ensuring visitors can easily use and navigate your site.
It’s in your best interests to make your visitors’ experience seamless and as effortless as possible. After all, you want them to spend time on your site, read your content and even buy your products or services if you offer any.
A small feature that many sites offer is a “back to the top” button, which allows users who have scrolled through pages of content to quickly return to the top of the page. This feature is especially useful for sites that contain a lot of information or have infinite scroll.
In today’s WTG project we’ll show you how to add a dynamic “back to the top” button to your site in a few quick and easy steps.
Before You Begin
The button we’re going to create will sit in the bottom-right of the page, will be fully responsive, fade into visibility when you scroll down and smoothly scroll up to the top of the page when the button is clicked. Neat, right?
First, there is one incredibly important action you should take before you start.
The steps to set up the button are simple, but it will require editing theme files. For this reason, it’s important that you backup your style.css and functions.php files in the theme where you want the button to appear. While you’re at it, back up your whole site just to be safe and because it’s a good habit.
If you want to add a back to top button to an existing theme, it’s a WordPress best practice to create a child theme so that any changes you make will not be erased by future updates of the original theme.
All set? Let’s go!
Copy and Upload the Script
The location of this file may differ from theme to theme, but usually, you’ll find it here. If your theme doesn’t contain a js folder, then go ahead and create one.
In this folder, create a new file called topbutton.js. You can name this file whatever you’d like, but if you do change the name, keep in mind that you will also need to change every reference to it in the code you add. Either way, add the following code In the new file:vtopbutton.js hosted with ❤ by GitHub
You can adjust how fast the button scrolls to the top by editing the number beside var speed = toward the top. The higher the number, the slower the automatic scroll will be.
Similarly, you can adjust the speed of the fade animation by editing the number beside var duration = and how many pixels are scrolled on a page when the button appears by by editing the value for var offset =.
This script is set up to display the button after you’ve scrolled 100 pixels on a page. It’s set low so it’s easier for you to test out even if you have a fresh install with very little to no content.
Realistically, you may very well want to change these values to whatever suits your specific needs. Once you have successfully created this new file, you’re ready to move on to the next step.
Make a Button
Use your favorite image editing software to create a button, purchase a button image or find one with a GPL licence that you can use for free. Upload it to your site and make a note of the image’s direct link. We’ll need it for the next step.
Once you’ve uploaded the image file, you can find the URL you need by viewing your media library and clicking on the thumbnail of your button. An in-line popup will appear and on the right-hand side you’ll find the link.
If you don’t like the idea of adding an image and you’d rather add text, this is also possible.
Keep in mind that the text will likely inherit the color, size and font of your theme so styling the button through CSS will take a bit of skill. The results will be very specific to your theme so using an image for the button as we are doing here is a much simpler solution.
Keep this page open and head on over to the next step.
Edit the style.css File
Open your theme’s CSS stylesheet add the following code anywhere you see fit as long as it’s not in between already existing tags and code. At the very bottom is a great place for it.
Alternatively, if you’ve previously installed a plugin such as Simple Custom CSS, you can add the code right into the area provided. Don’t forget to hit the save button!vstyle.css hosted with ❤ by GitHub
Don’t forget to replace the image link in this snippet of code with your button’s URL you noted in the previous step. If you don’t change the link, no button will appear so don’t forget this step.
4. Edit functions.php
The best place to add the following code is at the very end of the file, that way it will be less likely that it will interfere with other code. functions.php hosted with ❤ by GitHub
Once you’ve either edited and saved the file directly through your control panel or you’ve used FTP to upload the edited file – and replace the old one – you’re all set to start the next step.
Add the Button Link
The last step is to add the actual link to the pages of your site so the back-to-top button will appear.
You could put this link in every page template you have or in the header.php file, but since the button will appear at the bottom of the page, let’s put it in your footer. It will keep things nice and simple in case you decide to make future changes.
Open your footer.php file which will most likely be found in thewp-content > themes > your-theme folder.
The button is set to hover separately over all content of the page at the very bottom, right-hand corner so it doesn’t matter where you put the button link as long as it’s not smack dab in the middle of other code. Placing it between the footer or a div tag is usually a good spot.
If you decide to change the position of the button in the CSS stylesheet, keep in mind that where you put the button link may actually matter. It may appear exactly where you placed the link in the footer.
The CSS is currently set to a fixed position of 5 pixels from the bottom and right-hand side of the window so it shouldn’t currently be a problem. Here’s the link you will need to add to your footer.php file:footer.php hosted with ❤ by GitHub
You may notice the the link doesn’t actually have any text or button associated with it. This is because we’ve already established the button image with CSS so it’s not necessary to add it.
It’s also made clear that we are using a class instead of an id to define the link and its properties. This is simply so you can be free to add more similar buttons to your page, rather than being confined to one button per page. Changing this is not necessary.
The moment you’ve been waiting at the edge of your seat for has arrived! Go ahead, visit a page in your site that requires a lot of scrolling and check out your new “back-to-top” button.
Now your site’s visitors will be able to view your content with a bit more ease. If you’re not too keen on editing your theme’s files yourself, not to worry, there’s an easier alternative.
The easier alternative (plugin):
Scroll Top plugin will enable a custom and flexible Back To Top button to your WordPress website. It allows your visitor to easily scroll back to the top of your page. You will get features such as unlimited color choices, icon font & retina ready.
Now you’re ready to make your visitors’ experience a better one with each and every click.
What do you think of back to top buttons? What would you add to a site to increase UX? Let us know by submitting a comment below.
The single responsibility principle is a paradigm that, very loosely, states that all pieces of code (in our case, classes) should focus on doing one thing and one thing only. More formally:
…the single responsibility principle states that every context (class, function, variable, etc.) should have a single responsibility, and that responsibility should be entirely encapsulated by the context.
What this means for us is that our CSS should be composed of a series of much smaller classes that focus on providing very specific and limited functionality. This means that we need to decompose UIs into their smallest component pieces that each serve a single responsibility; they all do just one job, but can be very easily combined and composed to make much more versatile and complex constructs. Let’s take some example CSS that does not adhere to the single responsibility principle:
Here we can see that—despite being named after one very specific use-case—these classes are handling quite a lot: layout, structure, and cosmetics. We also have a lot of repetition. We need to refactor this in order to abstract out some shared objects (OOCSS) and bring it more inline with the single responsibility principle. We can break these two classes out into four much smaller responsibilities:
Now we have a general abstraction for boxes which can live, and be used, completely separately from our message component, and we have a base message component that can be extended by a number of smaller responsibility classes. The amount of repetition has been greatly reduced, and our ability to extend and compose our CSS has been greatly increased. This is a great example of OOCSS and the single responsibility principle working in tandem.
By focussing on single responsibilities, we can give our code much more flexibility, and extending components’ functions becomes very simple when sticking to the open/closed principle.
Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It is used for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS), or, formerly, its predecessor, Secure Sockets Layer (SSL). The protocol is therefore also often referred to as HTTP over TLS, or HTTP over SSL.
The principal motivation for HTTPS is authentication of the accessed website and protection of the privacy and integrity of the exchanged data while in transit. It protects against man-in-the-middle attacks. The bidirectional encryption of communications between a client and server protects against eavesdropping and in practice, this provides a reasonable assurance that one is communicating without interference by attackers with the website that one intended to communicate with, as opposed to an impostor.
Historically, HTTPS connections were primarily used for payment transactions on the World Wide Web, e-mail and for sensitive transactions in corporate information systems. Since 2018, HTTPS is used more often by web users than the original non-secure HTTP, primarily to protect page authenticity on all types of websites; secure accounts; and keep user communications, identity, and web browsing private.
The web industry is constantly changing. Here are the trends to watch out for in 2019.
Predicting web design trends is always tricky. Get it right and you are praised for being ahead of the curve; get it wrong and you are met with a flood of I-told-you-sos. That said, with 2019 now in full force, I’m going to provide some insight into the trends that will define web design throughout this year and beyond.
We’ve seen some vast changes in the past decade: the HTML5 revolution, mobile-first app development and now native features in web apps, plus more new web design tools than you could imagine. With the increasing use of machine learning, cross-platform frameworks and a more diverse developer base building everything, there’s going to be some exciting changes in our industry. These are my continuing predictions for the biggest web design trends in 2019.
1. AI gets personal
Artificial intelligence is too hot to not bring up. While it might not be as flashy as a self-driving car, the web can certainly connect to AI. Machine learning is going to take analytics to the next level. In the past, analytics offered more of a reactive approach: log the data and then use it for your next release. 2019 and onwards should continue to be about capturing data about how your app is used and improving the user experience by driving the website to change and adapt to this by itself.
This means that, depending on the data available on a user, the application will be able to act like a chameleon and change itself to provide the ideal UX for them. This will create truly personalized sites that behave differently and show different features depending on the individual using it.
2. Voice interfaces take over
With the explosion of voice assistants such as Alexa and Siri, conversational interfaces are bound to become a natural part of an application’s fabric. As more users become accustomed to interacting with the web using their voice, developers will need to ensure they can offer a seamless experience, even in web applications. Imagine having users sit on their couch and view their social media feed or tell their favourite voice assistant to pull up and read a news article for them – all without traditional inputs.
3. Accessibility becomes a requirement
Accessibility is no longer a luxury; it should be an absolute requirement. We’re seeing this pop up more and more, and this trend will just continue next year. Some have pushed hard with Progress Kendo UI to follow common accessibility guidelines like WCAG 2.1 and WAI-ARIA, to ensure web components follow accessibility requirements out of the box.
This positive trend in accessibility focus will continue in the web. Whether this comes from development practices naturally emphasising accessibility, or governments and legislature stepping in to enforce adherence, we will have more accessible applications.
4. Web apps get an AR makeover
Augmented reality will take the web by storm in 2019. AR is already commonplace in scenarios like Snapchat filters or Pokémon Go, but its use of AR will only expand to cover not only social media and games, but also everyday applications.
The beauty of AR is that it does not require full immersion via a clunky headset, as with VR. Instead, it can be used with the phones that we walk around with in our pockets today. Why should AR be limited to just the native mobile applications on a device? Why not use it on the web? Offering AR services through your web application without needing it to be installed as a native app can have huge benefits from a UX perspective.
Imagine being in a grocery store and doing a quick web search for a recipe. AR integration could provide users with turn-by-turn navigation through their mobile device to find all the ingredients within that store – all within a web app.
5. Developers flock to the web
Frameworks such as NativeScript and React Native will also play a big part in bringing more developers to web technologies, since they provide a single codebase for web and native mobile applications.
Additionally, concepts like progressive web applications (PWAs) will continue to blur the line between native mobile apps and web. Developers will then be able to purely focus on the user experience without worrying about specific platform choices.
Web Assembly is another technology that is bringing more developers to the web. Thanks to Web Assembly, C++, C#, Rust and other programming languages can now target the web. Projects like Blazor, which leverages .NET in the web, take advantage of the promise of Web Assembly and will help open the web to even more languages. This means that in the future, all developers can be web developers, regardless of programming language.
Nowadays there are many opportunities to learn new skills and knowledge to change or improve your career, but it requires some time and commitment. Web development is expanding more than ever and the demand for web developers and programmers in general is very high.
Here are top 3 things you need to take to pursue your dream to become a web developer:
Identify your skills.
Start learning and put your knowledge into practice.
Choose between freelancing and working for a company and apply for a job!
Learn as much as you can and take your time. You might also need to learn some basic skills such as graphic designing and marketing. Don’t let discouragements hold you back and keep building!
Spoiler alert: they aren’t little creatures with wings that write your stylesheets for you. In short: CSS Sprites are a means of combining multiple images into a single image file for use on a website, to help with performance.
Sprite may seem like a bit of a misnomer considering that you’re creating a large image as opposed to working with many small ones, but the history of sprites, dating back to 1975, should help clear things up.
To summarize: the term “sprites” comes from a technique in computer graphics, most often used in video games. The idea was that the computer could fetch a graphic into memory, and then only display parts of that image at a time, which was faster than having to continually fetch new images. The sprite was the big combined graphic.
CSS Sprites is pretty much the exact same theory: get the image once, and shift it around and only display parts of it. This reduces the overhead of having to fetch multiple images.
Why use CSS Sprites?
It may seem counterintuitive to cram smaller images into a larger image. Wouldn’t larger images take longer to load?
Let’s look at some numbers on an actual example:
256 x 128
256 x 135
256 x 147
That adds up to a total of 14.38KB to load the three images. Putting the three images into a single file weighs in at 16.1KB. The sprite ends up being 1.72KB larger than the three separate images.This isn’t a big difference, but there needs to be a good reason to accept this larger file… and there is!
While the total image size (sometimes) goes up with sprites, several images are loaded with a single HTTP request. Browsers limit the number of concurrent requests a site can make and HTTP requests require a bit of handshaking.
How do you use CSS Sprites?
Here’s an example sprite, with three different countries flags combined into a single image:
You set the same background-image on several CSS classes and set the background position and dimensions of the individual classes to display a single portion of the sprite. Here’s some code that demonstrates the concept:
If you’re thinking that there has to be a way to automate this so that you aren’t manually creating these sprites and then adjusting your stylesheet to match, you’re right, and you’re in luck!
Generate Sprites with Grunt / Gulp / Node
If you’re using Grunt, Gulp, or Node in general, css-sprite is a wonderful node package that creates sprites from a glob of images. Sprity has a lot of great features including formatting output as PNG, JPG (or Data URIs of those), and stylesheet generation in CSS, LESS, Sass, and Stylus.
To compile sprites via command line, install css-sprite globally with:
$ npm install sprity -g
Then, to generate sprites and the corresponding stylesheet, run:
Generating sprites with Compass takes some additional setup and maintenance, but if you’re already using Compass, it fits in well with your existing workflow.
Start by creating a directory within your `images` directory (yes, it does need to be inside your `images` directory to work) with a name that corresponds to the sprites you’d like to create. Ensure that the images you’re converting to sprites are PNGs and place them in your new directory. I’m creating flag sprites, so I’ve named my directory flags and placed three PNGs in the directory.
In a new SCSS file that I’ve called `flags.scss` (the name here is not important), the following three lines will, in order, import Compass’ sprite making tools, glob import the PNGs to be converted to sprites (notice that the path here does not include images/), and then generate the CSS for the sprites. Be mindful that the @include statement’s middle word needs to match the directory in the line before it.
This will take all the PNG files selected by the glob and concatenate them into a single file, but will not create the corresponding stylesheet. If you use ImageMagick to create your sprites, you may want to read the section below on using Sprite Cow.
Using Sprite Cow with your Sprites
Sprite Cow is a hosted tool for generating a stylesheet corresponding to your sprites. It doesn’t make the sprite for you, it just helps you get numbers you need to use the sprite (the width, height, and background-position of individual parts of the sprite). It boasts 2x image compatibility and a simple interface for quickly designating which areas of the sprite make up each image to create CSS for. You just click the part you need and it gives you the CSS you need.
Generate Sprites with Spritepad
Spritepad is another hosted solution for creating sprites. With Spritepad, you upload individual images, position them however you’d like, and the CSS is updated in real time. When you’re done, download the image and copy the CSS over to your project.
Generate Sprites with SpriteMe
SpriteMe is a bookmarklet that generates a sprite based on what it finds on the current page. So essentially you’d develop without using sprites at all, then use this to sprite things together at the end. Here’s a workflow explaining how that would work.
Should my sprites be horizontal or vertical?
One option is neither. Compact them into a grid, making the smallest size, dimensionally that you can. The dimensional size of an image plays a role in how much memory the image will take up when being used, so the less the better. If you end up laying out your own sprite, Sprite Cow is a good tool to help with the CSS generation part.
If, for simplicity, you’re going to pick one or the other, one way to do that is to look at the largest width and the largest height of your image files. If the largest width is greater than the largest height, the sprite sheet should be arranged horizontally. If the largest height is greater than the largest width, vertically. If you’re using a generation tool, they will generally make this choice for you.
In some situations, it may actually make sense to lay out a sprite diagonally. This can make it possible to use a sprite in an area of unknown width and height, which is pretty cool.
There are a few alternatives to CSS sprites, but, as you might expect, they each have their own benefits and drawbacks.
Data URIs allow you to embed the image data directly into a stylesheet. This avoids additional HTTP requests for images, making it essentially the same thing as a sprite, without the fancy positioning.
Icont fonts are similar to sprites in that the achieve the same thing: combining multiple images into a single request.
SVG images can be combined into a sprite as well and used as an icon system. It’s a slightly different approach though, utilizing the syntax and strengths of SVG. You may need to think about a fallback system though, as SVG doesn’t have as deep of browser support as CSS background-image (which essentially has no browser support issues at all).
Grunticon and Iconizr are possibilities for working with SVG sprites that help with the fallbacks.