January 2016

Today we're releasing 20 new videos in the "Front End Development" collection, this time covering the basics of Responsive Design and adding responsive images. This is some fun and mind-bending stuff if you've never seen it before. If you have, you might find some fun tidbits in there you didn't know.

In this video we create a high resolution image, demonstrate how browsers interpret those extra pixels, and how we can wrangle the image with CSS to get it to display at the size we originally intended.

So far we've simply been opening up a .html file in the browser in order to run our example. However, with the introduction of Retina.js, we're going to need a server of some kind since our browser is limited in the kinds of local files it has access to. Here we quickly install a Node.js extension that can spin up a lightweight server so we can get Retina.js working.

In the previous video we fixed some JavaScript errors, but we're still getting some 404 browser errors due to images that Retina.js is looking for and can't find. No worries, it's simple to tell Retina.js to look for images that actually exist.

The solution of serving a high-resolution image only to browsers that can support it is fantastic, but there are some downsides. Here we talk about what those are and pave the way for an alternative, future-proof solution that's sure to excite and enthrall!

If you started watching this series because you wanted to learn more about "responsive design," it probably seems like it's taken a long time to get to this point. But rest assured that everything you've learned so far will help to serve your understanding and mastery of responsive design. In this video we summarize what responsive design is and why it's better than some of the alternatives front end developers have used in the past.

While we'll find that it's relatively simple to support responsiveness for a number of HTML elements, one of our biggest challenges is working with images. It's not that they're impossible to work with, it's just that many of us have become used to the idea that images are a simple tag you can slap into the site and be done. Once we realign our expectations to include the diverse possibilities for our images, we'll be set up to enjoy what the following videos illustrate for a solution.

Browsers are smart because they know when to be stupid. If a browser makes too many calls to the server, or waits to load a page until it has all the information it could possibly use from the server, us users of the web would revolt because we've come to expect a faster web. Because of this, there are some things a browser can't know unless we tell them, and we explain how that works for images here.

Even though browsers can't know the resolution and density of images on the server, we can tell them before they go fetch the image by using the "srcset" HTML attribute. Though browser support for this attribute is slim at the time of this recording, in the future all major browsers will support it.

Giving the browser information about the resolution and density of images on the server is just part of the solution for building responsive images. The second factor has to do with telling the browser when different sizes of browsers might trigger a different layout, and thus a different image. The way we explain these scenarios to the browser is through something called a "media query."

Now that we understand how media queries work, the "sizes" attribute for images will make a lot more sense. With "sizes," we can tell the browser what size the image will be in different browser situations, something the browser usually can't know until it loads the complete CSS from the server.

From this point on, we'll be using the term "breakpoint" to make reference to media queries where the condition has to to the size of the browser. It's a cooler word, but is really more along the lines of slang in the front end world.

The "srcset" and "sizes" attributes are a lifesaver when it comes to coding responsive images, and because the attributes are part of the HTML spec now, eventually all browsers will support it. In the meantime, however, we need a way to improve browser support and the way we do that is through a JavaScript polyfill called "picturefill."

So far we've used a couple kinds of images: We've used a bitmap PNG file for our logo, and vector font icons for our icons. In this video we introduce another vector option that can give you greater versatility than a font icon, but with better scalability than a bitmap. That is, an SVG or "Scalar Vector Graphic" file.

In this video we explore several CSS properties at our disposal for adjusting the behavior of background images. While it's all good to know, we eventually discover the killer combination that will give us exactly what we want, which is to align the image to the bottom and have the image stretch to fit our entire element. It sounds like a tall order, but CSS has us covered.

So, I'm not able to make it to DrupalCon Asia this year, but with the funds that I would have spent, I'd like to help some locals help get to the Con. So, I'm giving away 6 DrupalCon Asia tickets in a lottery next week. To enter the lottery, I ask the following:

1. That you live in or near India.

2. That you volunteer in some way at the Con (mostly because it's an awesome way to connect with the community).

3. That you plan on using the ticket yourself.

Just reply to this email with your Drupal.org profile page URL and email address and I'll enter you in.

I will be drawing winners next week on Tuesday, January 12th. If you win, I'll be sure to let you know by the 13th.

I'm also releasing 20 new videos in the "Upgrading to Drupal 8" collection this week. Enjoy!

In Drupal 7, Views can be used to rewrite the output of fields. With it, you can add HTML and text to a field as well as merge additional fields into a single field's display. Additional modules like Display Suite and Panels could also adjust your field output for content pages. In core Drupal 8 the only way to customize a field's output is through Views, so here we demonstrate here how to replace a content page entirely with a View so we can customize fields as needed without going through the theming system.

In Drupal 8, comment settings are no longer part of the content type, but instead are associated with a comment field. This a welcome architectural change, and in this video we compare how to adjust comment settings in both 7 and 8.

Just like content and blocks, there are now comment "types," which allow you to create different groups of fields for multiple types. Here we walk through the interface for adding and manipulating comment types.

In Drupal 8, blocks work more like block factories. In Drupal 7, each block could only be used once, but in Drupal 8 a block can have multiple instances that are displayed in different locations and under different conditions. In this video we compare the workflow in both 7 and 8.

Custom blocks in Drupal 8 have been vastly improved from Drupal 7. In addition to being able to create a new block and use multiple instances of it throughout the layout, we can also create new "block types" which include fields just like content types or comment types. Here we demonstrate how these work.

Drupal 8 ships with a form builder in the guise of the "contact" module. With it we can create field-able forms whose content gets emailed to form-specific email addresses. In many ways it mimics the contributed Webform module's toolset, which is a huge improvement over the Drupal 7 version of the "contact" module. In this video we compare the two.

Even though the Drupal 8 form builder is very useful, it's still missing some important features that come bundled with Webform. Here we demonstrate these features so you can figure out if you really need Webform or can use the core form builder instead.

If you're used to the process of disabling and uninstalling a module in Drupal 7, then Drupal 8's interface might be a little confusing. In 8, the disabling and uninstalling process has been merged into a single action, making it more straightforward, but also meaning that there's now no way to just disable a module without losing the data associated with it. Here we talk about this important change as well as a few differences in the modules listing layout.

It looks like there might be an issue playing videos in this browser. We're working on better cross-brower experience, but in the meantime please try the latest Chrome or Firefox browsers. Or, you may be able to watch the video directly without progress tracking or transcript: