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.