MyFonts sells fonts that you can use on your websites directly through @font-face. They are a one-time fee - no subscriptions or recurring payments. Host the files however you would like, there is no third-party to rely on. Not only that, but you can try any font on your site free for 30 days.
Inspired by Mark Otto's tour of GitHub's CSS and Ian Feather's tour of Lonely Planet's CSS, I thought I would join the party and talk about how we do CSS at CodePen.
The following is a guest post by Katy Decorah (edited by Jason Morris). Katy was researching CSS columns and how they can work responsively, as there wasn't much information she could find out there on the subject. So, like a hero, she wrote it all up. Here's Katy:
With CSS columns you can create a print-inspired layout with little added markup that can adapt beyond a fixed canvas. A supported browser will make calculations to wrap and balance content into tidy columns. If you're already working with a fluid layout, the columns will reflow automatically. With the right combination of properties, CSS columns can be an interesting layout option that is responsive-friendly while degrading gracefully.
Where to declare columns
You can declare columns on any block level element. Columns can be applied to a single element or applied to multiple elements by targeting their parent.
In the image below, the left side depicts CSS column rules being applied to the second paragraph to transform just that content into columns. The right side depicts the rules being applied to a container element such as a
or
to transform the elements into a multi-column layout.
How to declare columns
There are three different ways to declare columns:
Declare column-count.
Declare column-width.
Declare both (recommended).
Let's explore the different ways to declare columns.
1. Declare column-count
Use column-count to declare the number of columns.
The number of columns remains consistent even as the browser width changes as demonstrated in the gif below.
2. Declare column-width
Use column-width to declare the width of the columns.
The specified value is not an absolute value, but rather a minimum width. Given the column-width, the browser will decide how many columns of at least that width can fit in the space. The browser will also take into account the gutter, or gap between columns in this calculation (more on that later). Then the browser will expand the columns to evenly distribute to fill the width of the container.
For example, if you inspect the paragraph in the live demo below, you will find that the width of the column is actually greater than 150px, which is the set value of column-width.
Once the browser cannot fit at least two columns as wide as the column-width then no columns will appear and the layout will return to a single column layout.
The gif below demonstrates how the columns release as the browser width narrows. Unlike column-count this property is inherently responsive.
3. Declare both (recommended)
Use column-count and column-width together for the best control over CSS columns. You can declare each property or use the shorthand columns.
When both properties are declared, column-count is the maximum number of columns and column-width is the minimum width for those columns.
Like column-gap, the vertical line will exit once the browser width is too narrow as demonstrated in the gif below.
column-span
To break the column flow temporarily, declare column-span on a child element. Currently, Firefox does not support this feature (but you can go vote for it on Bugzilla).
The image below contains a heading that indicates the start of a new chapter in the story, but it continues with column flow.
To break the heading out of the column flow, add column-span: all to the element. This declaration will temporarily stop the column flow to allow the element to span the columns, but will restart the columns with the next element.
To change how the content fills the columns, declare column-fill. Currently, this property is only available in Firefox.
When height is added to a columned element, Firefox behaves differently than the other browsers. Firefox will automatically balance the content, while the other browser will fill the columns sequentially.
The image below demonstrates how Firefox behaves compared to the other browsers when height is added to a columned element.
In Firefox, you can change this behavior by declaring column-fill: auto. This rule will make the columns fill sequentially, as shown in the live demo below.
Since a height must be declared for Firefox to enable column-fill, the height constraint breaks the fluid pattern. The content expands horizontally because it cannot flow vertically as demonstrated in the gif below. In this case, a media query could be added to manage the height (more on that later).
The other browsers don't support column-fill and will fill columns sequentially when a height is declared on a columned element. It's worth noting that when height is added to any columned element, regardless of browser or use of column-fill, the constraint will break the fluid pattern.
Limitations
Columns can be an elegant way to deliver content, so long as the content remains readable. A multi-column layout can become difficult to read when the content overflows horizontally or the columns become taller than the viewport.
Content overflows horizontally
As shown in the column-fill section, if height is added to a columned element, then the element will expand horizontally to fit the content. The overflow will break the layout and send users in a different direction.
Possible Solution: create a min-width media query to declare the height rule.
In the demo below, I narrowed the browser window to find when the columns began to overflow and wrote down that number. Next, I wrote a min-width media query using the value of when the columns overflow and moved the height rule to the media query.
As demonstrated in the gif below, when the columns release the height rule is out of bounds and the columns flow vertically.
Columns become taller than the viewport
If your column height extends beyond the viewport then users will need to scroll to follow the column flow.
Possible Solution: create a min-height media query to activate the columns.
In the example below, the columns will only activate if the columned element has a min-height: 400px;. I came to this number by shrinking the browser width to the point just before the columns release. Next, I adjusted the height of the browser to find where the columns began to fall under the viewport. I used that number for the value of the min-height media query.
The gif below demonstrates that the columned element must be at least 400px tall to display the content in columns.
Support
CSS columns have decent support (IE10+) and still require prefixes on all properties. Find out more details about the multi-column properties on Can I Use....
Even if your favorite browser doesn't support multi-column layouts, keep in mind that they degrade gracefully into a single column layout. CSS columns are like the escalators of content delivery (as so eloquently put by Mitch Hedberg):
A multi-column layout cannot break, it can only become a single column layout.
JavaScript Event Madness! Capturing *all* events without interference
The following is a guest post by Matthias Christen and Florian Müller from Ghostlab. Ghostlab is cross-browser cross-device testing software for Mac and PC. One of the things I'm very impressed Ghostlab can do is sync the events from one browser to all the others. Scroll one page, the others you are testing scroll. Click somewhere on one page, that same click happens on the others. I asked them about how the heck it does that when there is so much that could interfere. Matthias and Florian explain:
We have been developing Ghostlab, a tool for cross-device and cross-browser testing your websites. In essence, it syncs any number of clients that view a website and makes it easy to go through that site and make sure it works great and looks good on all viewports and platforms. A central component is the replication of events across clients - when the user clicks on a button, scrolls, or enters text into a form field on one client, we have to make sure that the very same thing happens on all others.
Capturing missed events
The client side script component of Ghostlab is listening for all sorts of events that happen, tries to catch them, and replicate them to all the other clients. At some point, we noted that we didn't quite catch all events. We had to figure out what the problem was, and came up with a solution that allows you to catch any events that happen on your site, no matter how they are handled by any custom JavaScript.
How can it be that you are listening for an event, but don't catch it? That's because any event handler has the option of doing several things with an event. You'll know the ability to prevent the default action usually taken by the browser (preventDefault()). It allows you, for example, to have a link (<a>) for which the user does not go to its href on a click event.
In addition to telling the browser to not do the default action whenever the event occurs, an event handler can also stop the propagation of an event. When an event is triggered on an element, say a link, any event handler that is attached to this specific element will be allowed to handle the event first. After it is done, the event will bubble up until it reaches the document level. Every listener for this event at any parent of the original element will be able to react to the event - that is, unless a lower event handler decides to stop propagation, in which case the event will no longer go further up in the DOM.
Our example 1 demonstrates this. When you click on the inner div (Level 3), the click handler for this element will handle the event first. Unless it prevents propagation, the parent elements (Level 2, Level 1) will afterwards be able to react to the event in order. In case you tick the "Stop Propagation" checkbox, the event handler will prevent further propagation - so, click events on Level 3 will no longer reach Levels 1 and 2, and click events on Level 2 will no longer reach Level 1.
In example 2, we demonstrate the effect of stopping immediate propagation. This method implicitly stops the bubbling up of the event, so if there were any parent elements, we would observe the same behavior as in example 1. In addition, it also prevents any additional handlers of the same event on the same element from being executed. In our example, we have to click event handlers registered on our element. If we choose to stop immediate propagation, only the first responder will be able to handle the event, and after calling stopImmediatePropagation, no other handler will be called.
So if you would want to listen to all the events that happen in the DOM, that's quite difficult. To prevent missing events due to cancelled bubbling up, you'd have to register all the event handlers on every single element of the DOM. And even then, in case a developer chooses to stop immediate propagation, this would only work if you were the first one to register for the event.
If we want to be absolutely sure that we are informed of any event, no matter what its handlers do with it, we have to get in the loop at the very beginning of event registration. For that purpose, we override the addEventListener function of the EventTarget object. The basic idea is simple: every event handler registration will, in the end, call this method. If we override it, we have full control of what happens when any event handler registers.
The original addEventListener function takes an event handler function (the "original event handler") as its second argument. If we don't override the addEventListener function, the original event handler function will be called whenever the specified event occurs. Now, in our custom addEventListener function, we simply wrap the original event handler in our own event handler (the "wrapper function"). The wrapper function contains any logic we require, and can ultimatelly call the original event handler - if we desire to do so.
Example 3 demonstrates this. The three click events attached to the "Level" elements are registered through our custom addEventListener function, so any time a click event occurs on these elements, our wrapper function is called. There, we observe the status of the checkbox - if it is ticked, we simply do not call the original event handler, thereby preventing any click events to trigger any original event handler. A little side note: if you want to make sure that you take control of all events, you have to make sure that you override the addEventListener function before any event is registered.
While this solution has helped us improve Ghostlab, you may ask yourself what this could be good for? Well, there are several possibilities. We have sketched two possible use cases below - if you can come up with any other, please share!
Possible Application 1: Event Visualizer
There are tools to help you visualize events on your website (we love, for example, VisualEvent Allan Jardine). Using our technique we can quickly implement such a tool ourselves. In our example, for every registered event, we simply draw a little square on top of the element for which the event was registered. On hover, we display the source code of the (original) registered event handler function.
Instead of drawing event indicators onto the screen, you can also display that information in another manner. This example shows you a tabular overview of the registered events on any page (given that you inject the code into it), and updates the triggered events in real-time. This can, for example, be helpful when you are experiencing performance issues and are suspecting it might be because there are too many event handlers.
Events are just a small part of the huge complex world of Front End Development. At Vanamco we are excited to bring you tools that help simplifiy and streamline your processes whilst keeping you upto date with bets practice.
Take our quiz and win a free Ghostlab license
We've put together a JavaScript quiz to test your knowledge! Two winners will be chosen to win a free Ghostlab license and more.
When you change a CSS properties value, the browser needs to react to your change. Some values change the layout of the page. For instance, a change in width requires the browser to update layout, then "paint" any pixels that have changed, then "composite" them together. That's a lot of work. Some CSS properties can be changed more inexpensively. For instance, a change in background-image doesn't require any layout changes, but does require paint and composite.
Paul Lewis did all the research on which properties do what. A good reference to help you think about what kind of changes you can make that are easy for the browser (thus fast) and what kind of changes are hard (thus slow).
Dave Rupert does an in-depth analysis of his own responsive site to figure out where he's at, identify places to improve, and evaluate the idea going around that responsive design is at fault for bloated websites.
