The world of web development has always had a gap between the design-to-development handoff. Ambitious designers want the final result of their effort to look unique and beautiful (and true to their initial vision), whereas many developers find more value in an outcome that is consistent, dependable, and rock solid (and easy to code). This dynamic can result in sustained tension between the two sides with both parties looking to steer things their own way.
While this situation is unavoidable to some extent, new front-end technology can play a role in bringing the two sides closer together. One such technology is CSS grid. This post explores how it can be used to write CSS styles that match design layouts to a high degree of fidelity (without the headache!).
A common way that designers give instructions to front-end developers is with design mockups (by mockups, we’re talking about deliverables that are built in Sketch, XD, Illustrator, Photoshop etc). All designers work differently to some degree (as do developers), but many like to base the structure of their layouts on some kind of grid system. A consistent grid system is invaluable for communicating how a webpage should be coded and how it should respond when the size of the user’s screen differs from the mockup. As a developer, I really appreciate designers who take the trouble to adopt a well thought-out grid system.
A 12-column layout is particularly popular, but other patterns are common as well. Software like Sketch and XD makes creating pages that follow a preset column layout pretty easy — you can toggle an overlay on and off with the click of a button.
A grid layout designed in Sketch (left) and Adobe XD (right)
Once a grid system is implemented, most design elements should be positioned squarely within it. This approach ensures that shapes line up evenly and makes for a more appealing appearance. In addition to being visually attractive, a predictable grid gives developers a distinct target to shoot for when writing styles.
Unfortunately, this basic pattern can be deceptively difficult to code accurately. Frameworks like Bootstrap are often used to create grid layouts, but they come with downsides like added page weight and a lack of fine-grained control. CSS grid offers a better solution for the front-end perfectionist. Let’s look at an example.
A 14-column grid layout
The design above is a good application for grid. There is a 14-column pattern with multiple elements positioned within it. While the boxes all have different widths and offsets, they all adhere to the same grid. This layout can be made with flexbox — and even floats — but that would likely involve some very specific math to get a pixel-perfect result across all breakpoints. And let’s face it: many front-end developers don’t have the patience for that. Let’s look at three CSS grid layout strategies for doing this kind of work more easily.
The most intuitive way to write an evenly spaced 12-column layout would probably be some variation of this. Here, an outer container is used to control the outside gutter spacing with left and right padding, and an inner row element is used to restrain content to a maximum width. The row receives some grid-specific styling:
This rule defines the grid to consist of 12 columns, each having a width of one fractional unit (fr). A gap of 20px between columns is also specified. With the column template set, the start and end of any child column can be set quite easily using the grid-column property. For example, setting grid-column: 3/8 positions that element to begin at column three and span five columns across to column eight.
We can already see a lot of value in what CSS grid provides in this one example, but this approach has some limitations. One problem is Internet Explorer, which doesn’t have support for the grid-gap property. Another problem is that this 12-column approach does not provide the ability to start columns at the end of gaps or end columns at the start of gaps. For that, another system is needed.
Although grid-gap may be a no go for IE, the appearance of gaps can be recreated by including the spaces as part of the grid template itself. The repeat function available to grid-template-columns accepts not just a single column width as an argument, but repeating patterns of arbitrary length. To this end, a pattern of column-then-gap can be repeated 11 times, and then the final column can be inserted to complete the 12-column / 11 interior gap layout desired:
grid-template-columns: repeat(11, 1fr 20px) 1fr;
This gets around the IE issue and also allows for columns to be started and ended on both columns or gaps. While being a nice improvement over the previous method, it still has some room to grow. For example, what if a column was to be positioned with one side spanning to the outer edge of the screen, and the other fit within the grid system? Here’s an example:
A grid Layout with an that’s item flush to the outer edge
In this layout, the card (our left column) begins and ends within the grid. The main image (our right column) begins within the grid as well, but extends beyond the grid to the edge of the screen. Writing CSS for this can be a challenge. One approach might be to position the image absolutely and pin it to the right edge, but this comes with the downside of taking it out of the document flow (which might be a problem if the image is taller than the card). Another idea would be to use floats or flexbox to maintain document flow, but this would entail some tricky one-off calculation to get the widths and spacing just right. Let’s look at a better way.
This technique builds on the idea introduced in the last revision. Now, instead of having the grid exist within other elements that define the gutter sizes and row widths, we’re integrating those spaces with the grid’s pattern. Since the gutters, columns, and gaps are all incorporated into the template, child elements can be positioned easily and precisely on the grid by using the grid-column property.
Yes, some math is required to get this just right. It’s important to have the template set differently before and after the maximum width of the row has been realized. I elected to use SCSS for this because defining variables can make the calculation a lot more manageable (not to mention more readable for other developers). What started as a 12-part pattern grew to a 23-part pattern with the integration of the 11 interior gaps, and is now 25 pieces accounting for the left and right gutters.
One cool thing about this approach is that it can be used as the basis for any layout that adheres to the grid once the pattern is set, including traditionally awkward layouts that involve columns spanning to outside edges. Moreover, it serves as a straightforward way to precisely implement designs that are likely to be handed down in quality mockups. That is something that should make both developers and designers happy!
There are a couple of caveats…
While these techniques can be used to crack traditionally awkward styling problems, they are not silver bullets. Instead, they should be thought of as alternative tools to be used for the right application.
One situation in which the second and third layout patterns are not appropriate are layouts that require auto placement. Another would be production environments that need to support browsers that don’t play nice with CSS grid.
Creating an HTML email can feel like stepping back a few years as a web developer. All of our new layout functionality is unavailable to us &mdasj; email clients render the same layout in completely different ways. Just when we think we have it all fixed, another email client shows up with a new set of bugs.
Not too long ago, Rémi Parmentier, an HTML Email developer, ran a session with practical front-end techniques for building modern, cross-client emails. A few weeks later, he gave a wonderful talk at SmashingConf Freiburg highlighting some of the common struggles and shared useful strategies for avoiding problems in email development.
There was so much useful information contained in these sessions that we wanted to release them more widely — including the webinar transcript and references to slides and resources. If you have ever struggled with email development, these will give you a great starting point to understand why an email isn’t rendered properly, and how to squash those nasty bugs quickly.
If you enjoy learning from these videos, check out Smashing Membership. Starting from this month, we will be showing some of the live sessions we run every month to a wider audience — absolutely free of charge to view. However, if you’d like to join the discussion live and perhaps have your work reviewed by an expert, join Smashing Membership. For the price of one coffee a month, you can support the creation of more content like this.
Now get ready to learn everything you need to know about HTML email!
Rémi Parmentier: Thanks, everyone, for coming to my presentation. My name is Rémi Parmentier. Some of you might know me from Twitter or from my blog under the nickname hteumeuleu. I’ve been doing HTML emails for as long as I’ve been working in this industry. For the past few years, I’ve started to give training in HTML emails as well I am spending a lot of time online on Slack, on Twitter, on forums to help people find solutions for their email problems. This gave me a pretty good view of most of the coding problems that people have and how to actually solve them. I started working on this email coding guidelines project this year. This was greatly inspired by some of the work that’s been done on the web about I think a decade ago.
Rémi Parmentier: About a decade ago, there was a lot of trends of web guidelines being shared by people from many different companies. First one was the most famous one was this code guide by Mark Otto, who was then working at Twitter. The point of the document was to share a lot of guidelines about how HTML and CSS should be coded within the company. There was a lot of good practices shared in this document, like which doctype you should use or to close your tag and such. I think this is really interesting to have.
Rémi Parmentier: In the email world, Ted Goas from Stack Overflow actually made a very similar document with a lot of content as well about how they’re building the emails at Stack Overflow. This really gave me the lust to make a similar document that everyone could share within their company or everyone could pick good practices for building HTML emails. We’re going to see a few of these best practices and you’ll be able to see the document afterwards online. Let’s start ahead.
Rémi Parmentier: The first thing that I usually share is to use the HTML5 doctype. Whenever I help people online of open HTML email, it makes me sad to see that a lot of people are still using HTML4 doctype or XHTML 1. The first reason to use the HTML5 doctype is that it’s really nice. Actually, it’s very short. You can type it by hand, you can remember it, and that’s already a good reason to use it.
Rémi Parmentier: The most important reason to use the HTML5 doctype is that when an email is displayed in webmail, our doctype is usually removed and we inherit from the webmail’s doctype. Most webmails use the HTML5 doctype, so even for you wish you could use HTML1 or HTML4 doctype, this won’t work because webmails will remove it.
Rémi Parmentier: I made this little illustration of how this actually works. On the left, you can see an email address coded. It’s got a style tag and it’s got a div and an H1 inside. What happens when a webmail like Gmail, for example, wants to display this content, it will pick the style tags and pick the content within the body, and it will prefix the styles, it will remove all the styles that it won’t support, and then it will include this inside the HTML of the actual webmail, because webmails are actually just HTML and CSS. This means that even if I use an HTML4 doctype, because Gmail uses HTML5 doctype, my code will be random thanks to that doctype. This is a good thing to have in mind.
Rémi Parmentier: I made this about this, about which doctype you should use in HTML emails, about three years ago already, but what I saw back then was that most of the email clients already were using an HTML5 doctype. A few of them didn’t have a doctype at all, like on mobile apps sometimes, but a lot of them were on HTML5.
Rémi Parmentier: It’s important to know that you can end up on different doctypes because there can be differences. The first one is that HTML5 actually have spaces between images. If you slice some big image inside your email, you will see something like this if you try it with an HTML5 doctype.
Rémi Parmentier: Let me actually show you this with a little demo. Here, I have this … Oops, it’s the wrong one. Here I have this little demo of a T-Rex. It’s actually three images. Here with an HTML1 doctype, everything is working fine, but if I use an HTML5 doctype instead, boom, you have white lines appearing between each images.
Rémi Parmentier: Now, I’m not exactly sure why this happens, but I think it’s because when HTML5 upgraded, they cannot change some of the way that images are supposed to behave according to the specification, so now it looks more like a paragraph with text, so there are lines in between images.
Rémi Parmentier: Email Geeks have found very good solutions to the service. One of the solutions is to actually add a display block style to every images. Once you do this, it will remove the white lines between the images. Another solution to avoid this if you can’t use display block is to add a vertical align middle style and then you will remove these white lines as well.
Rémi Parmentier: This is a first quirk that you can encounter with HTML5 doctype, but there is another interesting case is that you can’t display block a table cell in WebKit without a doctype. This one is really interesting as well. I’ve got a table for this as well, which would be right here.
Rémi Parmentier: Here I’ve got a table with three little dinosaurs next to each others. Usually when we’ve got tables like this and we want to make our emails optimized for mobiles, what we can do is apply the display block to our TDs and then they will stack on each others like this.
Rémi Parmentier: As we can see here, we have an HTML5 doctype. This is working fine, but if I would ever end up in an image client that will remove the doctype, then this won’t work anymore in WebKit. As you can see now, it’s back to the regular pattern display.
Rémi Parmentier: I think this has to do with legacy websites and quirk modes and all of these things, but one solution that was found by the email community is to actually use TH tags instead of TD. If I remove every TD here by TH, you can see that, here, even without a doctype, it’s working again. This is some kind of the quirks that you have to deal with in HTML emails because of not only email clients behave but also rendering engines like WebKit here.
Rémi Parmentier: The second best practice I’d want to share with you today is to use the lang attributes. The lang attribute in HTML is to define the language of your document. This is very important for accessibility, and mostly this is because accessibility tools like screen readers will be able to pick the right voice for it.
Rémi Parmentier: Once again, let me show you a demo of this live, and hopefully it won’t crash. Here I have this very nice email from Mailchimp. As it was said before, I am French, so my computer is set in French. My screen reader is in French as well, so every time we’ll see some new content, it will try to read it in French. I will stop my screen reader now. You try to see when we’ll get to this paragraph and see how it will read it.
Rémi Parmentier: I know that I don’t really have a good English accent, but this is even worse than mine. If you don’t set the lang attributes, your content will be read on whatever default language is for your users. The quick phase here is to add the lang attributes, and then I can restart my screen reader.
Screenreader:: Mailchimp Presents has a new collection of original content made with entrepreneurs in mind. In recent months, we’ve rolled out documentaries, short-form series and podcasts that live only on Mailchimp. Today, we officially launch a platform.
Rémi Parmentier: As you can hear, even for my screen reader, and my system is still set in French, once the screen reader is actually on HTML contents, it will use another voice, an English voice there, to read the content which makes the experience much, much better here.
Rémi Parmentier: One small difference that we have in HTML emails with the lang attribute is that, just like for the doctype, the doctype might not be picked up by webmails, because webmails will only take just styles and the content of the body. It’s usually a good practice to add the lang attribute as well on the wrapper that you have on your content inside your body, so you’ll make sure that this will get picked by webmails as well.
Rémi Parmentier: Now a third best practice that I like is to actually use styles over HTML attributes. This is really something that people hate about HTML emails because they feel that they have to use all the HTML attributes, they have to use all code, and this makes emails look very different from the web, but there is really no reason for this at all unless you need to support very old email clients like Lotus Notes 6 or similar.
Rémi Parmentier: In this example here, in the first example, you can see I’ve used valign, align and bgcolor attributes in HTML, but all of those can be very easily and robustly replaced by the corresponding styles. Here I only have one style attribute and inside I have the vertical align CSS property, text align and background color.
Rémi Parmentier: One reason I like to do this is because it makes go cleaner and more readable. All your presentational properties are grouped in a single style attribute instead of being all over the place with valign, align and all the stuff. This makes it, in my opinion, very, very better to read and to maintain.
Rémi Parmentier: There’s another reason I like to use styles over attributes is that it helps taking over email clients’ own styles. For example, on the French webmail of Orange, the webmail’s UI actually has a CSS that has a rule that sets every TD to vertical align top. Because of this rule, if you were to use only HTML attributes like valign=middle, the CSS role from the webmail would override with the HTML attributes because this is how the cascade works in HTML and CSS.
Rémi Parmentier: Instead, if we use an inline style with a vertical align property on the TD here, well, this style will take over the webmail style because inline styles are more important than external style sheets. Using styles over attributes is also a good way to fight other email clients’ and webmails’ default styles.
Rémi Parmentier: There are a few exceptions to the attributes that I still use. The first exceptions is to center a table in Outlook 2007 to 2019 on Windows, because as Scott said in the introduction, Outlook uses Word as a rendering engine in those versions and it’s not really good at understanding CSS, at least for some properties.
Rémi Parmentier: For example, here, it would understand the margin properties for pixel values, but it wouldn’t understand the margin zero auto value to center a table. We still need the align=center attribute to center elements and data, especially in Outlook, but we no longer need to use which attributes as in the first example here. This can be replaced by the width style instead.
Rémi Parmentier: Now other exception in Outlook as well is when you want to define a fluid image width. In the first example, I use a width attribute with 100% value. The thing is that Outlook actually doesn’t deal with percentage width for images the same way as it should be in CSS.
Rémi Parmentier: The percentage in Outlook is actually matching the physical image size and not the parent size in the HTML. If you’ve got an image that’s 600-pixel wide and you use a width=50%, then your image will actually be 300 pixels no matter what the size of your parent in HTML is.
Rémi Parmentier: Usually, to avoid any quirks with this is then I always define a fixed width in pixels for Outlook using the width attribute in HTML, and then using a style, I use a width with 100%. Outlook will only pick the attribute value here and not the style value.
Rémi Parmentier: Then, another exception I have when I use styles over attributes is to reset the default styles of the table. By default, the HTML tables have borders and padding inside and cells, et cetera. The proper way to do this in CSS is to set border zero, border spacing zero, our padding is zero, our border is zero, the first ones on the table, and expanding your border actually for each cell of your table.
Rémi Parmentier: This is pretty much why I don’t really like to do it the CSS way because you need to repeat the padding and border for every TD of your table, while if you use the attributes, you only need to use them on the table, and then you’re all set for any … no matter on any cells you have inside your table. This is probably something I will change my mind in a few years maybe, I hope, but for now, I’m still used and I prefer using the attribute way for resetting default styles on tables.
Rémi Parmentier: Now another best practice I’d like to share is, do not split the visuals. This was actually a very common practice maybe a decade ago. When we had large images, it was always better, at least it was always shared that you should split it to make download faster and things like that, but this is not true today.
Rémi Parmentier: Not splitting visual actually has a lot of benefits. The first one is that it’s easier to maintain. If you have a big visual in your email and it’s Friday night and your project manager comes at you and asks you to change it at the last minute, well, you don’t have to open Photoshop and slice your images again and where you’ve got everything. You can just replace that image and you’re done.
Rémi Parmentier: It’s also better for accessibility because you have a single image, you have a single element, so a single alt attribute. This is simpler and better for accessibility. One thing it’s also better for is for web performance, because downloading 100 kilobytes image is theoretically faster than downloading five image of 20 kilobytes.
Rémi Parmentier: That’s because for each image of 20 kilobytes, the request to the server needs to be made and we need to wait the answer five times. Even for the really small micro-transactions between the client and the server, this add up the more image you have, and it can slow down the download of your email image, so this is something to avoid.
Rémi Parmentier: Next, on the WebKit, there’s also a very weird behavior. Whenever you use a CSS transform on sliced images, WebKit will have very thin lines between split images. I would just show you a demo of this as well. Back to my first T-Rex image here, if I add a small transform here that will scale the image, here you can see that at this ratio, there are very small lines that appear within each slices of my image.
Rémi Parmentier: This is really due to WebKit not handling well the way they should scaled images like this. Maybe there’s a node size somewhere and it doesn’t compute properly, so you end up with small hair lines like this. Yes, the best practice here is to avoid to split your visuals.
Rémi Parmentier: This is actually something that will happen inside email clients because in Outlook.com, for example, if your email is bigger than the actual view of emails inside the clients, then your email will be resized using a CSS transform to feed the view port of the email client. This is something that you should be wary of.
Rémi Parmentier: Finally about splitting visual, I always try not to do it because this kind of things happens. This is something that was shared on Reddit almost 10 years ago. This is an email by LinkedIn and the face of this young lady, it was cut in half, maybe because some text was longer than expected or maybe because here the user chose to set up his email client with a bigger font than expected, so all kind of things can happen inside email clients, just like on the web. If you want to avoid these kind of strange situations, just don’t split visuals.
Rémi Parmentier: Next, this is a big one. This is tables for layouts. This surely is the most common thing that people think about when they think about HTML emails. It always annoys because we mostly don’t really need tables for layouts, except for one email client, and that is the Outlooks on Windows from 2007 to the latest 2019 version.
Rémi Parmentier: The reason of that, as we said before, is because all of those versions of Outlooks use Word as a rendering engine. Word is not really good in interpreting HTML and CSS. There is this documentation online about what it should be capable of, but it’s pretty hard to read and to make sense of, so I try to make this diagram to actually make sense of it.
Rémi Parmentier: From this documentation, what it says is that CSS supports in Outlook will actually vary from which elements you use CSS on. It will be different in body and span than in div and p and then all the other supported HTML tags.
Rémi Parmentier: First, if you have a body and span, you can only use what Microsoft calls Core CSS properties. That’s the color property, the font, text align and background color property. On the body element and the span element, you can only use those four CSS properties.
Rémi Parmentier: Then, on divs and paragraphs, you can use all those four properties from the Core level, but you can also use two new properties from what Microsoft calls the Coreextended level. In this level, you have two new properties, the text indent and margin properties.
Rémi Parmentier: Then, for all the other tags, you can use properties of the two previous levels, and you have what Microsoft calls the Full CSS support with many more CSS properties, but I think the most interesting are the width, height, padding, border and this kind of properties for defining elements.
Rémi Parmentier: This means here that if you want to use width and height properties and make it work in Outlook, you won’t be able to do this on a div because div only support Coreextended and Core CSS properties. You will need to use tables for those CSS properties, and the same thing for padding and border.
Rémi Parmentier: I usually narrow it down to the few following guidelines to use tables. I try to only use a table when I want to set a fixed width on an element. If I need an element to be a certain width, then I will use a table and define the width from that table.
Rémi Parmentier: Also, if I want to set two block elements side by side, because even Outlook doesn’t really support any advanced CSS layout property, so even float is not really well-supported, so if you need to have two elements side by side, then as you make a table with two cells, and those two elements will be next to each others then. Then I use tables whenever I need to set a padding, a background color or border style. This make it very reliant, very robust to use a table for those styles only.
Rémi Parmentier: Now a problem with tables is something we’ve learned in the way a long time ago is that tables are not made for presentation. They are made for actual data tables. This can be very problematic for screen readers especially. In order to improve accessibility here, we will use the role=presentation attribute whenever we will make a layout table.
Rémi Parmentier: Let me show you a quick example of how this will change the way your email is interpreted by a screen reader. I will take a new demo here. I’ve got this email from Jacadi, which is a French children clothing brand. They have this table here with different sizes of products. This is actually a table inside the code. I’ve pre-recorded a video here to show you how this is read by a screen reader.
Screenreader: Counting pairs, web content. Blank, blank, blank. Table 1 column. Nine rows. Blank. Column 1 of 1. Row 2. Nine Level 2 tables, seven columns. One row, Column 1 of 1. Blank. Column 3 of 7. Blank. Column 4 of 7. Blank. Column 5 of 7. Blank. Column 7 of 7. End of table. Row 3 of 9, blank. Column 1 of 1. Row 4 of 9, Row 2 table, seven columns, one blank. Column 1 of 7. Blank. Blank. End of table. Row 5 of 9, blank. Row 6 of 9, blank. Column, blank, blank, column end of table. Row 7 of 9, blank. Row 8 of 9 Row 2 table, blank. Column 1, blank. Column end of table. Row 9 of 9 blank. Column end of table.
Rémi Parmentier: This is terrible. This is so annoying. Now let’s see how we can fix these cells. The way we can fix this is by adding the role=presentation attributes. This is not something that it reads from tables to tables, so we need to add this attribute whenever we’ll have a new table. We have a few nested tables here, so we’ll add a few. Here is how the results sound.
Screenreader: Blank. Blank. Voice-over off.
Rémi Parmentier: This is so much better. This is so much smoother and it makes for much nicer experience. I hope this convinced you that you should always use as less tables as you can, but if you do, use role=presentation attributes on those tables.
Rémi Parmentier: Now, one step that we can take even further is that since tables are mostly for Outlook, we can use conditional comments to make those tables only visible on Outlook. Conditional comments are actually something that was available in Internet Explorer as well until I think I9. With these, if MSOs are in text, we can tell the borders that all the following contents within that conditional comment will be available only for MSO clients, so that’s mostly Outlook.
Rémi Parmentier: Then, between those opening and closing tables comments, we can have a div with a role or stuff that will come just like for a regular web border, although webmails will pick the div and Outlook will pick the table. This is video how I got most of my emails.
Rémi Parmentier: Now another small good practice to have is to use margin or padding for spacing. This is mostly to avoid empty containers, empty cells like this where we have a role within a cell with a height of 20 and then we have TDs with width of 20 to create margin all along with this content. I still see this done a lot, and this make your code really, really heavy. It’s less readable and it’s really bad in my opinion.
Rémi Parmentier: The proper way to do something like this would be to use a table as well if you want and have the padding style on the first TD, and then inside use margin to space tags between each others. This works again really well in every popular image client and in Outlook as well.
Rémi Parmentier: Now the small quirk that can happen in the Outlook and Windows is that there is the background color. If you use the background color on any of these elements with margin, it actually bleeds through the margin. Here’s an example where I should have a margin between the red background and blue background, but in Outlook, the margin is actually the same color of the background of that element. In those cases, then the solution is to maybe use another table and nest your content like this to space elements, but if you don’t use background, then margin is really safe even in Outlook.
Rémi Parmentier: Finally, this is perhaps my favorite recommendation. It’s to make it work without style tags. It’s not necessarily about having this raw HTML rendering, but thinking about progressive enhancements and graceful degradation and about how your emails will look without this guideline. This is something pretty unusual in cooperation of the web because it doesn’t happen on the web, but not having a style tag actually happens a lot on email clients.
Rémi Parmentier: First, not all email clients support style tags. Perhaps one of the most common example I see is Gmail on its mobile applications on iOS and Android lets you configure a third-party email address. You can use your Yahoo or Outlook.com address inside the Gmail app. If you do so, then every emails that you check won’t have support for style tags. This is what Email Geeks have nicknamed GANGA for Gmail apps with non-Gmail accounts. This is a very common occurrence that you can have.
Rémi Parmentier: Then you have a lot of cases for smaller or local or international email clients like SFR in France or Yandex and Mail.ru in Russia, et cetera. Even to this day, there are a lot of email clients that don’t support style tag, so if you want to make your code more robust, make sure that it can work without style tag.
Rémi Parmentier: Sometimes it’s also temporary. For example, in the past year or so, Gmail has had two days where style tags were completely removed from every email on every one of their email clients. We don’t know why this happened. There has been zero communication on that, but there’s a good chance that maybe they detected some kind of attacks that use certain styles, and so they needed to remove it very fastly and secure their users, so they removed style tag support for a few hours or almost a day. If you were to send a campaign that day, you were out of luck if your emails required style tags to work.
Rémi Parmentier: Sometimes also it’s contextual. For example, in Gmail, when you forward an email to someone, then you won’t have any style tags anymore, or when an email is viewed in its unclean version, you know when you have a view entire messaging at the bottom of your email because it was too long, if you view your email in that window, you won’t be able to have a style tag.
Rémi Parmentier: Then finally, sometimes it’s buggy. For example, in Yahoo Android in the app, the head is removed, so every style tag inside it are removed as well, but only the first head. We don’t really usually think as HTML documents are in multiple heads, but you can actually totally do this.
Rémi Parmentier: This has been pretty much a common practice now for a few years to deal with this bug in Yahoo. If you have a second head with your style with it, then it will work fine in Yahoo Android and in most email clients as well. We have just this empty head first so that Yahoo will strip it, and this will work.
Rémi Parmentier: Now, what I mean by making an email works is that the email should adjust its layer to any width without horizontal scroll and the email should reflect the branding of the sender. This can be colors often, this can be fonts or whatever, but make sure that it works without styles.
Rémi Parmentier: In order to do this, we can use inline styles. This is why most emails still use inline style, and I really recommend to do this for most of your styles. Make sure that the brand, the colors and everything can come up with just inline style.
Rémi Parmentier: Then, to tackle mobile emails to make sure that your emails can work fine from desktop to mobile, we have different solutions. The first one is to make your email fluid. I’ve got a little demo here as well, which I will show you right now.
Rémi Parmentier: This is an email that I’ve worked on almost four years ago for a French magazine, GEO. It’s got a lot of interesting things here. The first one is this grid here. If I try to resize it to make it responsive, you can see that it’s 100% fluid and it will scale accordingly to whatever the width for the image client is.
Rémi Parmentier: This works absolutely well without even a single style tag. This is just two tables on top, one for each lines, and we’ve got image inside it and the image are set with a fluid width, and so this works well enough even without style tags. This is good to have elements like this that can scale accordingly.
Rémi Parmentier: Now, this might not be the most optimal for every email, so another technique is to make your content hybrid. “Hee-breed,” or “hi-breed,” I’m not sure how you pronounce it, sorry for that, hybrid comes from the fact that you can still use media queries, but only as progressive enhancements, and then you need to make sure that your layout can fall back gracefully even without styles.
Rémi Parmentier: I would go back to this exact same email that I just showed you. A little bit lower here, we’ve got this gallery of user portraits. We can scale it as well. We have three columns here and then it will get on to two columns, and then only to one column.
Rémi Parmentier: The way this works here is using div width display in my block. We’ve got actually three divs like this next to each others and they all have a width of 33%. They will set so three can sit next to each others. They all have a minimum width of 140 pixels, so if there is no longer enough room to fit all those three elements because they’re in display inline block, they will naturally match even CSS flow down next to each others. This is a pretty good way to make it work like this.
Rémi Parmentier: I also use CSS and media queries here to make it a little bit more graceful when you have content here. If I disable the styles here, if I remove all of this, you can see that the layout has changed a little bit. We still have two columns, but they’re more stuck together. The layout still works appropriately where we can go from three to two to one layouts even without any styles, just with both div display and line blocks.
Rémi Parmentier: Then, perhaps the final, most popular way to make your emails work on mobiles is to make them mobile-first, to code them mobile-first. I will once again go back to that exact same email. You can see here that … Oops, it’s not fitting. I’ve got these two email columns next to each others. If I resize my window a little bit smaller, they will stack on each others.
Rémi Parmentier: Now because this is coded mobile-first, it means that this is actually the default layout for this zoom. On them, I use a min-width media query to change the layouts on desktop, on larger window sizes to make this work. If I remove all the styles here, just like I did before, you can see that now, our images are stacked on each others just like on mobile. This is what you’ll get when you code mobile-first. You get mostly your mobile view, but larger on desktop. This is really a lot of considerations to have when you’re coding emails for mobiles and for every email clients.
Rémi Parmentier: That’s pretty much it for me. All those recommendations, all those guidelines, you can find them online on GitHub, where I have these documents available. I really strongly encourage you really to share it within your colleagues and also to contribute to it.
Rémi Parmentier: If you think you have good recommendations that could apply to every emails you will code, feel free to share with me, feel free to contribute to this document as well. Hopefully you will have some questions. You can find me on Twitter or on my blog or you can send me an email as well if you have any questions after this session. Thank you.
Scott: Thank you very much, Rémi. “Re-my.” That was really very good. I’ve had a lot of questions about … Oh, hey, Vitaly.
Vitaly: Hello. Hello, Rémi. I’m so sorry about being late. Hello, everybody, dear Smashing members. I had a train delay and all. Scott, you wanted to say something? Sorry I interrupted you.
Scott: No. There was just two questions I was going to get out of the way. One was from Pawan, who’s a very, very active member of the Smashing membership. He is asking us, any thoughts on applying fonts consistently through HTML email?
Rémi Parmentier: Sorry, can you repeat?
Scott: Do you have any thoughts about applying fonts consistently through HTML email?
Rémi Parmentier: Yes. Well, for fonts, I usually encourage my clients to use web fonts in emails because it’s always better when you can have your own brand fonts. Now the thing to have in mind is that it won’t work everywhere. When using web fonts, especially, it almost works nowhere. It works in Apple Mail and in Thunderbird and maybe a few local email clients, but that’s really it. It doesn’t work in Gmail, it doesn’t work in Yahoo. If you can adapt to that, if that’s good for you, then go ahead and do it.
Rémi Parmentier: Now, the problem that you can have with web fonts like this is that if you try to use really funky fonts like Lobster or Pacifico on Google fonts, if it falls back to something like Arial or Helvetica, your email will definitely look very, very different. If you can use Montserrat and it falls back to Helvetica, that’s less a problem in my opinion. It really depends on the fonts you want to use and how much you are ready to not have this font in the cases where it won’t work.
Scott: That’s a really good point. There’s Zach Leatherman, who’s a very active member with Smashing and a presenter at SmashingConf, he’s done a lot of presentations about the fallback on fonts, so that’s interesting to make that correlation between email and web-based fonts.
Scott: Before I hand it over to Vitaly, my other question is, a lot of people are talking about interactive emails. There was actually, not this past SmashingConf, I believe the SmashingConf before, there was a presentation about interactive emails where you can actually complete an action just with one click of a button in an email, and mostly it’s based on AMP email. I was just curious, what do you know, what is AMP email and what’s the support for it currently?
Rémi Parmentier: AMP for Email is still something relatively new. It was announced by Google about a year ago, but it was only made available in Gmail desktop webmail about a few months ago, I think, in maybe April or something. AMP for Email is basically bringing the AMP Javascript framework to HTML email so that now inside Gmail, you can use interactive components like carousels or accordions, and you’ve got also, more interestingly, in my opinion, have live data.
Rémi Parmentier: If you’re selling clothes, for example, you can make sure that the clothes you’re presenting in your email are available in stock and are the ones in the best interest for your customer that’s viewing this email. This brings a lot of new customizations and possibilities for emails like that.
Rémi Parmentier: The thing is that it’s very still in its infancy and it mostly only works on Gmail desktops so far. It should come in on Gmail mobiles in the coming months, but then, there is also Yahoo and Outlook.com I think who said they were interested in implementing it.
Rémi Parmentier: Maybe this is something that will actually grab attention and go in the future. Yes, this is something I’m looking into and I’m really interested in. It’s still very hard to say if it will work and be successful, but there are a lot of interesting things in it.
Scott: Definitely. That falls back on what I was asking at the beginning before you started the presentation is, is there going to be some sort of standard that comes across for email clients? That’s my dream is that that will happen. On that note, Vitaly, I’m going to hand over to you for some questions.
Vitaly: Excellent. Thank you so much, Scott. Actually, Rémi, that was a brilliant presentation. Thank you so much. I learned-
Rémi Parmentier: Oh, thank you.
Vitaly: … a lot. I was a little bit not shocked, but in a way, I felt like it’s just wrong that we’re preaching these best practices for email which are not necessarily best practices full stop in 2019. It’s really about time that web standards have evolved.
Vitaly: We do have an open question from Pawan. Just before we do that, I have a couple, but one thing I wanted to know from somebody who’s so deeply motivated by the beauty and horror of email, I do have to find out, do you sleep well at night?
Rémi Parmentier: Oh, yes.
Vitaly: Excellent.
Rémi Parmentier: It depends because I have two small children, so not every night, but it’s not because of email.
Vitaly: Okay. The thing is, if you look back, let’s say, over the last, I don’t know, how many years have you been now in this madness?
Rémi Parmentier: Almost 15 years, but I really started digging into emails maybe five years ago, or maybe a little bit more, but yeah, about five years.
Vitaly: I’m curious, then, do you see that there has been a lot of progress in terms of email client supporting new features, broadening CSS support, Gmail, support of media queries and all? Do you see that the differences have been remarkable over the last five years or is it a very slow progress? Just so we can set expectations of what we should be expecting coming up next on the platform.
Rémi Parmentier: I would say both. It’s been both slow, but there has been progress. If you look back five years ago, five years ago, Gmail didn’t support media queries, and neither did Yahoo, I think, and neither did Outlook.com. Media queries are a huge tool to make email works well on mobile. The simple fact that those emails were able to adapt and add this to their list of CSS properties and features supported is actually a very good thing.
Rémi Parmentier: Now, it’s always a bit frustrating because it definitely doesn’t move as fast as the web is moving nowadays where you can see new features added in Chrome or Firefox every week and new articles about it. Things are moving slowly for really unknown reasons. That’s perhaps the biggest problem of emails is that everything is really opaque.
Rémi Parmentier: We don’t know how things work within Gmail or within Outlook and we have a lot of advantages for the web, people from the Chrome team, from the Firefox team sharing all the new advances in their browsers, but this is not the case in email clients, and this is really perhaps the most frustrating thing is that if you see a bug, if you have a problem, you pretty much have no one to talk to.
Vitaly: It’s a little bit loud here. I’m just in a park, I promise. Pawan is wondering, do you have any thoughts on embedding HTML forms in emails? Is it a good idea or not?
Rémi Parmentier: It can work. This is actually something that’s done a lot by us in the presentation you mentioned. Mark Robbins was the godfather of interactive emails. A lot of people actually use form in emails. Just like everything, you just need to realize that this won’t work everywhere. You need to think about, what happens if my form doesn’t work? Do I show something different? Do I have a link that sets to a form on my website? This is perhaps the hardest part, when you try to think of advances in emails like that. Every time, you need to think about what happens if this doesn’t work and what will I show to the people when it won’t work.
Vitaly: That makes sense. Well, I have so many questions. If you do have a few minutes, I just wanted-
Rémi Parmentier: Yeah, sure.
Vitaly: Because just today, I had to send out a wonderful email to our wonderful Smashing subscribers. One thing that stuck with me, and I wasn’t really sure how to deal with it. Not every client who understand media queries. Gmail does. You will have the media rule and then it will be all fine, but then, for some reason, when we’re sending out with Mailchimp and we do inline styles, actually inline styles in the attributes, what happens is you have the inline styles say font size 21 pixel, let’s say, on H2. Then you have a media that overrides it with font size 28 or something else.
Vitaly: Am I correct to assume that it’s probably a good idea to avoid bang importance one way or the other, because it will override whatever you have in the inline styles? If you have a media rule, and then that media rule, you actually have font size 30 pixels importance, will it override inline styles or not in most-
Rémi Parmentier: Yeah, definitely importance will override inline style.
Vitaly: But then it’s included in the media rule, right? If a client doesn’t understand media, they wouldn’t know-
Rémi Parmentier: Yes, exactly. Yes, which is why you once again need to think what happens if media is not supported. There, your inline style will be picked up. Maybe you will need to have the mobile-first approach and have the smaller font size inline and then use a min-width media query to have the different font size on desktop.
Vitaly: Makes sense. When you start building, do you actually build mobile-first or do you build desktop-first?
Rémi Parmentier: Well, it really depends. As I just show in my last three examples between-
Vitaly: Oh, sorry, I must have missed a few things.
Rémi Parmentier: Yeah. Between the three examples or if we do mobile-first, these are different approaches that you can have and that makes sense, depending on the contents you have. Most of the time, I usually go mobile-first, but it really depends on how you want your fallback to display. Sometimes it makes sense to have more desktop layouts and sometimes it makes more sense to have more mobile layouts.
Vitaly: For testing, we’re using Mailchimp just to see how it looks in different clients, but Doug Working is asking, do you have any recommendations for tools to test email code to see how it looks in different email clients?
Rémi Parmentier: Yes. There are two very good and very popular email tools that will allow you to take screenshots of how your email render across many, many email clients. Those are Litmus and Email on Acid. They work really similarly for email testing.
Rémi Parmentier: You just import your code and you will get screenshots very fast of how your email looks. This is really how I recommend to test emails because, of course, you need to do some ports manually as well, but it’s so much faster when you have a tool like this that it’s really more professional and you will win a lot of time by working with tools like this.
Vitaly: But then, it basically takes screenshots that you have to analyze. If you discover something like a major bug, how do you debug? Any tools for remote debugging, so to say?
Rémi Parmentier: Yeah. Debugging is the hardest part. In webmails, actually, it’s pretty easy because since the webmail is just a webpage, you can fire up your browser inspector tools and inspect the webmail’s code. This is really something interesting to do. I encourage everyone to do it at least once in a while because you will see how the webmail transforms your code in ways that you maybe have never imagined, like prefixing and renaming the classes you can have in your code.
Rémi Parmentier: This is a good way to see if maybe an image client has removed some of your styles or maybe if you did a mistake somewhere. For webmail, this is the best way to debug. For other email clients like Outlook, this is really a try-and-retry approach where you just send a code, change something, resend the email-
Vitaly: It sounds like fun.
Rémi Parmentier: Yeah, this can be a bit irritating. With the experience, you do less and less of this, but yes, unfortunately, there are no developer to see in Outlook.
Vitaly: That makes sense. One more thing that actually came up as well, is it safe to use SVG in emails? Or if you’re having the same image, would you prefer to use SVG or would you recommend to stay away from SVG and use PNG or JPEG instead, or God forbid GIF?
Rémi Parmentier: GIFs are actually still very popular in email-
Vitaly: I know. I noticed.
Rémi Parmentier: … but there are actually no reason because PNG is just as well-supported as GIFs for that matter. Regarding SVGs, just as my previous answers, I will say do it if you can manage to make it fall back to something I think for other email clients.
Rémi Parmentier: I think SVG works very well in Apple Mail, in Mac OS and iOS. It might work in a few more email clients, but I don’t think it works well in webmails. If you can have a distant SVGs that you call maybe in … For example, if you use a picture tag, you can have a source with your SVG, so this will be picked up by Apple Mail. Inside this picture, you can have an image tag as a fallback with a regular PNG or JPEG. This will work in other email clients.
Rémi Parmentier: There are different ways to tackle this kind of things, but SVG is definitely not the first format for images that you were shown when you built emails, but this is definitely something you can use, even though it won’t work everywhere. If you can have the proper fallback, then go ahead and use it.
Vitaly: Willow Cheng is asking, would you have recommendation on design tools which could let you design and export email in HTML?
Rémi Parmentier: No. Unfortunately, nothing that I can think of right now. Because most of the time, tools that will offer you to generate your HTML from design tool will be really rubbish because it will be either completely outdated and not work well in most modern versions of email clients, so I would actually recommend to stay away from those tools. From design point of view, I’m not sure there are any tools that will let you export clean, proper HTML for emails.
Vitaly: That’s actually an answer I was expecting, to be honest. Maybe just one final question. I’m sure I’ll have more later, but I know you do also have family and all and it’s quite late as well, and I get to meet you in Freiburg, so this is just a couple of weeks from now, so at SmashingConf Freiburg. This is going to be exciting.
Vitaly: I do have a question, though, still. I remember for a while, maybe a year ago, maybe two years ago, I found these two resources which were great. One of them was responsiveemailpatterns.com. The other is responsiveemailresources, or something like that, .com. One of them has gone away. It’s just down I think at this point, but I will also post the link later. Can you recommend some websites, resources where you can get copy-pastes almost email codes, snippets or something that you can reuse on a daily basis? I have heard that you might be working on something. Was I wrong?
Rémi Parmentier: I’m not sure, but I won’t talk about this for now, but it’s always [inaudible 01:04:56] snippets of codes that you can share because there are a lot of factors inside an email that can make your code behave differently. Every time there’s a tool that says it makes bulletproof backgrounds or bulletproof buttons, for example, you can always very easily, very shortly find email clients in which this doesn’t work properly. This is always a problem.
Rémi Parmentier: I remember the websites we were talking about, about responsive patterns, but I actually don’t know who were maintaining those. I don’t think they are ever really updated. As for websites, I can’t think of any right now. Maybe it will come later, that’s too bad, but the two things I will recommend is, if you’re into Twitter, follow the Email Geeks hashtag. That’s #emailgeeks, G-E-E-K-S. There are always a lot of people sharing good resources and the latest good articles that are always interesting.
Rémi Parmentier: The other thing I recommend is to join the Email Geeks at Slack channel. This is a really good community that’s growing a lot. There are all sorts of channels for marketing or for design or for code. People are really, really nice there and really always trying to help and almost available at any hours of the day, so this is incredible. If you look up for Email Geeks Slack on Google, you will see a subscription page that you can join. I hope you can join and just say “Hi” if you come.
Vitaly: Just one final, just the really, really last one, and then I’ll let you go. Sorry, excuse me if you mentioned it already in the session, but I’m wondering, as of today, as of 2019, looking at the best practices and the email clients, what are the baseline where you would say, let’s support this kind of client?
Vitaly: Because at this point, when we think about a 8, sometimes you obviously want to search something accessible to a 8, but you’re not going to optimize for a 8. We’re getting to the point where some companies can actually start dropping a 9 in the same way, but again, we’re quite far away yet.
Vitaly: When it comes to email clients, is Outlook 2013 still a thing? I remember the big update that Outlook brought in 2013 changed a lot of things in email, if I remember correctly. As of today, when we look into the landscape of email clients, what is the baseline we absolutely have to support at least?
Rémi Parmentier: I think the-
Vitaly: To support.
Rémi Parmentier: The others’ basis is Outlook 2007, because this is something actually pretty annoying is that this is used in a lot of big companies, and those big companies don’t pays new license for new versions of Outlook every year and they pay for a decade or so. There are still quite a lot of people I think using those older versions. This is still something that we have to account for.
Rémi Parmentier: Now, it’s not really that much a problem because between Outlook 2007 and Outlook 2019, unfortunately there weren’t that much of progress made because it’s still Word as a rendering engine. I think this is maybe the worst case we have to support mainly because, yes, we are not getting rid of those versions of Outlook anytime soon, I think.
Vitaly: That’s very optimistic, a bright outlook in life. I like that. I respect that. Thank you so much, Rémi, for being with us today and sharing all the wonderful insights.
Rémi Parmentier: Thank you for having me.
Vitaly: Of course. Will you be kind enough to share the slides of your presentation as well?
Rémi Parmentier: Yes, absolutely.
Vitaly: If you have any other resources that come to your mind, please send them over to us and we’ll publish them, too.
Rémi Parmentier: Sure.
Vitaly: All right? That’s been very exciting. It wasn’t actually as dirty as I thought it would be. Just humble in a way, even. I didn’t see anything that would screech and make me feel uncomfortable at night when I want to sleep. Thank you so much for that, Rémi.
Rémi Parmentier: Thank you.
Vitaly: On that note, Scott, any other updates we should keep in mind or anything we need to mention?
Scott: I was going to ask you, Vitaly. Tomorrow, we have another Smashing TV.
Vitaly: Yes. Friends, we’re trying something else and something new every time. Apparently, well, finally, today we got … I hope we received, because I didn’t get the confirmation yet, but we’re supposed to receive the first copies of the Smashing Print or our new printed magazine dedicated to topics that are often not covered well enough on the web, or maybe that just got lost in the myriad of workflows.
Vitaly: The first issue is dedicated to ethics and privacy. As a dedication to that, we’re going to have a live session, a live stream on Smashing TV tomorrow with five panelists, all contributors to this first issue of Smashing Print. It’s going to be broadcasted on YouTube. If you go on Smashing.TV, you’ll find the links, but we also will be publishing an article tomorrow featuring the links and everything.
Vitaly: The printed magazine, that by the way, Smashers, the ones with $9 plan are getting it for free, and the members with $5 plan are getting the ebook and the heavy discount on the ebook as well. Rémi is getting a printed magazine as well just because he’s so awesome.
Rémi Parmentier: Thank you.
Scott: Thanks, Rémi.
Vitaly: Beyond that, we also have a few more things coming up, I think.
Scott: On the 13th, Mr. Paul Boag, who has been a very prominent mentor in the Smashing community, many Smashing Conferences, many webinars, August 13th, Paul Boag is doing the customer journey mapping where UX and marketing meet.
Vitaly: Then we have Cassie Evans on August 20th exploring the interactive web animation with SVG. This is going to be fun as well. If you actually ever wanted to do a bit more or try to figure out a better workflow for SVG animation, that’s definitely a session not to miss, so looking forward to that.
Vitaly: All right, I think we’re good here. Any more announcements, major announcements, Scott, that we need to share with the world around us?
Scott: You’re making me feel like I’m forgetting something, but … SmashingConf Freiburg?
Vitaly: Yes, we do have a SmashingConf Freiburg, where Rémi is going to speak as well, but we also have the videos of Toronto conference which will be released today, or maybe tomorrow. Maybe they already released. See how well-prepared I am. Watch out for that and you’ll get them, you’ll find them also in your dashboard, so keep that in mind. All right. I think we’re good!
Scott: Okay. Thank you everybody for attending. Thank you-
Vitaly: Thanks, everyone, for attending.
Rémi Parmentier: Bye! Thank you and bye.
Vitaly: Thank you and see you next time. Thank you, Rémi. Bye-bye.
Rémi Parmentier: Thanks. Bye.
Vitaly: See you next time.
SmashingConf Freiburg Presentation “Think Like An Email Geek”
At the end of the Webinar, Vitaly mentions that Remi will be speaking at Freiburg. You don’t have to wait for that as we also have that video to share with you, along with the slides and resources.
We hope you enjoyed this look into HTML email. If you would like to enjoy more of this kind of content, plus the chance to interact with the presenters and other members while helping to support the creation of independent content for web designers and developers join us here.
When Tim Berners-Lee gave us the WorldWideWeb in 1990, it was the first and only web browser. But it didn’t remain alone for long.
Even in those early days of the web, there was plenty of competition for web browser market share: Mosaic, MidasWWW, SlipKnot, Arena, Netscape, and Internet Explorer emerged around that time, too, and duked it out for the top spot for the better part of a decade.
So, if there’s always been a battle of the browsers, why do we care so much about how many browsers are available today? You’d think it wouldn’t matter much. After all, browsers are nothing more than a shell through which we access the web, right? Superficially, that’s true. As consumers, browsers provide us with key navigational elements that help us move around the web: the home button, address bar, back and forward buttons, bookmarks, and more.
As designers and developers, though, you understand that browsers play a bigger role in the user experience than just what users can see at the top of their screen. With various rendering engines used to interpret and display code, we see varying results in how browsers show our websites to their users. As such, it’s a worthwhile question to ask: Would we be better off if there were only one browser?
The State of Web Browsers Today
There was a time when Internet Explorer was the reigning champ of browsers. However, it failed to prioritize the user experience and to adhere to web standards put in place for that very purpose. It was this failure that ultimately opened the door for other browsers to usurp IE from the lofty position it sat upon for years.
Here is what the global browser market share looked like in 2010, according to StatCounter:
As you can see, IE was quickly losing popularity to Firefox, which provided a much better (i.e. less intrusive) browsing experience for its users.
What’s interesting to note, though, is that Firefox didn’t remain the frontrunner for long. Just a year later, Chrome surpassed Firefox in terms of market share.
Eight years later, this is what the browser market share looks like:
It’s a totally different picture. Chrome owns the majority market share and there are no major waves detected in the market. Everyone’s browser preferences seem to be holding steady.
Even when we throw mobile browsers into the mix, the same holds true.
Notice how Chrome’s percentage share shrinks slightly, from 69.08% to 63.72%. That’s thanks to Safari, which cuts a bit deeper into Google’s share on mobile:
Even so, it’s clear that Chrome is an untouchable force when it comes to browsers. So, why don’t the others give up and just let Chrome run it all? Wouldn’t it be a better experience for users and, by consequence, make it easier for designers and developers to build for the web?
Is One Browser the Solution?
This is a tricky question to answer. Because if we’re being honest with ourselves, there’s really only one browser that we realistically could default to without the entirety of the web going bonkers: Chrome.
That said, there are some (albeit legit) concerns that will probably keep that from happening.
Concern #1: Privacy Is at Stake
Google is the entity behind Chrome and Chromium, the open source project that helps others create better browsing experiences. Browsers like Opera, Brave, and Vivaldi have been built with Chromium. Even Microsoft’s own browser, Edge, is getting a makeover with Chromium.
While it’s great that Google’s doing its part to bring order and stability to the web, that doesn’t negate the fact that there are serious privacy concerns when it comes to the Chrome browsing experience.
There’s the issue with cookies, for starters. Some web browsers have gone so far as to block websites from using cookies, by default. Google, on the other hand, leaves this to its users to configure on their own. Granted, the passing of GDPR has brought more awareness to the issue of privacy and cookie tracking on the web. But in terms of getting support from the leading browser, consumers aren’t going to get much there.
Then, there’s the matter of how much tracking Google is doing on its own. After all, if someone is using Chrome, that means they’re using other Google products as well. So, how much data is Google collecting as it watches its users go from its email platform to Google Drive to its search engine and so on? Probably a lot. Which will only strengthen the monopoly it has over the web.
Concern #2: Google Doesn’t Play Fair
Google has demonstrated that it doesn’t always have others’ interests in mind when it passes down big decisions. And that’s something that consumers and companies alike should be concerned with.
For instance, there’s the recent news about what Google wants to do to the Web Request API; specifically, how it relates to ad-blocking extensions.
Its reason for this? It says it’s moving its Chrome extensions to the Declarative Net Request API in order to improve user privacy. Some suspect, however, that Google wants to introduce its own API in order to cripple ad-blockers (which obviously impact its own ability to generate revenue through ads).
There are also assertions that Google edges out products it doesn’t like (including competing browsers) using less-than-reputable means. For example, the former CTO at Mozilla, Andreas Gal, told Bloomberg:
“There were dozens and dozens of ‘oopsies,’ where Google ships something and, ‘oops,’ it doesn’t work in Firefox. They say oh we’re going to fix it right away, in two months, and in the meantime every time the user goes to these sites, they think, ‘oh, Firefox is broken.”
It’s not just the big competitors that Google has edged out either. The same article reports that developer Samuel Maddock had a similar experience. After building a browser using Chromium, Google refused to give him permission to use one of their products to complete it. When he sought out a reason for the rejection, there was none given.
Concern #3: Innovation Will Slow
When you look at the history of web browsers, you’ll see that it’s not just the leading options that have improved the browsing experience.
Take Opera, for instance, which was responsible for giving us browser tabs, thumbnail speed dial, and mouse gestures. Even if it’s never held a large share of the browser market, it’s still been a major innovative force, and one that the big players have had no problem copying.
Which leads me to wonder: Without multiple browsers competing and collaborating, is it possible that innovation will stagnate?
You could argue that we wouldn’t need to upgrade the browsing experience if we were given one really high-quality option to work with. But as we’ve already seen, Google doesn’t always look out for its users. So, who’s to say that it wouldn’t just kick back and wait to make improvements to its browser only when it served its own interests?
That’s not how technology works. As our needs change as consumers and the world around us becomes more complicated, technology always needs to be on the cutting edge. It would be rather reckless to give up on less popular browsers whose mere presence leads to greater innovation in how we move around the web.
Wrap-Up
As it stands now, we’re better off with multiple browsers. We could definitely stand to trim down the list of browsers that are available — for the sake of development and testing — but it would require the leading browsers to collaborate and work on building a more standardized web.
You can’t design for the majority of your visitors; you have to design for all of them.
As for what you can do with this information, here are my final thoughts:
You can’t design for the majority of your visitors; you have to design for all of them.
So, first things first: familiarize yourself with the differences between the leading web browsers. If you don’t have this set up already, install Chrome, Firefox, and Safari on your desktop and mobile devices. And put them into rotation as you spend time on the web, for work or personal use. You’ll quickly learn where these browsers fall short and where they shine.
Next, take a look at Google Analytics. Which browsers do your visitors use? What about in years past? If you don’t have any data to go on, then you need to assume that visitors could be coming in from any and all browsers.
And, finally, build websites that adhere to basic web standards. You’ll find information on this at the World Wide Web Consortium. Until our web browsers come together to align their rendering engines and browsing experiences, we have to do what we can to bring consistency and stability to the web.
The art world can be an overwhelming place. From tough critics to discerning buyers, there are many people to please as you try to make it as an artist or a gallerist. How do you break in? While the first step is creating work that stands out, the next step is actually promoting that work and getting it in front of buyers.
For years, this was difficult.
But with more digital options than ever at an artist’s disposal, new ways are opening up for artists to get their work into the hands of buyers. In fact, you could say online art sales are democratizing the industry, giving more artists the chance to promote and curate their work on their own terms.
Here are some of the main steps involved in selling art online:
Classify your work correctly online. Make sure you categorize your work so that it can be browsed easily and helps you put your best foot forward.
Promote your work. This is a chance to get creative, something artists tend to excel at.
Sell your work. Set up a way to collect payments digitally.
We’ll walk you through these steps in detail. While each step might look simple, there are certain subtleties you’ll need to understand before diving in. We understand that different types of artists demand different tools and options — so we’ll be sure to outline which tools fit your needs best.
Now let’s get ready to sell!
Art selling: through galleries or online platforms?
So who should sell online anyway? Although this might surprise you, it turns out selling art digitally isn’t just for individual artists hoping to get their work out into the world. Galleries can also use online tools to reach a wider audience. After all, not every art connoisseur wants to travel to a gallery to check out pieces. And as digital tools grow more advanced, they’re better able to capture the true art viewing experience.
In short, everyone is getting in on the fun — and online selling isn’t just for the “little guy” anymore. But there are some differences when it comes to selling as a gallery versus selling as an individual, which we’ll outline below.
Galleries and individuals artists have different demands. From disparities in resources to different workflows, each approaches showcasing and selling work in a different way. Here are a few of the differences to keep in mind when it comes to selling as a gallery versus selling as an individual artist:
Galleries have more resources. This difference is fairly clear to anyone following the art world. Art galleries have the space and staff needed to showcase work in person and in an attractive way. They also connect with special auctions and exhibitors to find artwork and sell it. Overall, galleries run like a business. Although money doesn’t usually change hands up front, galleries showcase artists whose work they’re confident will sell.
Individual artists can develop a personal touch. Many artists at the beginning of their career need to rely on online word of mouth. By setting up a website and engaging with social media, they can begin to develop a personal connection with their fans. While a gallery may be a bit more impersonal — selling a collection of work that doesn’t belong to one artist alone — an individual artist has the chance to forge a world around their art and their art alone.
For galleries, online is supplementary. Popular galleries tend to have a fairly steady level of foot traffic. Lots of people see a gallery’s art in person. So while online avenues can help boost gallery sales and get an even wider audience to engage with their collection of art, they don’t rely on online sales in the same way that individual artists do.
For individual artists, online means freedom. Let’s be real: The gallery circuit isn’t always fair and welcoming. It can be tough for artists who might be just starting out and don’t have many contacts in the art world to gain a foothold.
Catching the attention of gallery owners is an uphill battle that calls for tireless self-promotion and networking. But with selling art online, a lot of that difficult legwork falls away. Individual artists have the chance to put their work in front of the masses without having to seriously penetrate the gallery world. That’s why selling online is great for outsiders and those new to art.
Advantages of online art selling and payment collection
When we talk about selling art online, we typically mean taking advantage of online galleries and creating a personal website to promote your work. This also refers to the technical aspects of buying and selling — such as setting up a way to collect payments online.
Modern tools make it easier than ever to create a functional, browsable website that displays your work beautifully and reaches a wide audience. This is particularly useful for artists who may not have serious tech skills or the means to hire someone to build their site.
The world of buying and selling art online is changing every day. In this section, we’ll learn more about how art connoisseurs are moving online to view work — and explore how this development offers plenty of advantages for the modern artist.
Artwork goes digital
Visiting an art gallery can be a unique, unforgettable experience. You might come face to face with a piece that will forever change the way you engage with and relate to art. Because of these transformative experiences, visiting an art gallery will never go out of style. It will always stand out as the chance to experience great art with your own two eyes.
That said, artwork has gone digital. While we sometimes like to believe that art is different from other sectors in some grand way, it really is an industry like any other. And more and more industries are being disrupted by e-commerce, which makes it easier than ever for sellers to sell and buyers to buy on the worldwide web.
Here’s how art is making a foothold online:
E-commerce is on the rise. Now that Amazon, Alibaba, and other major online retailers have risen to the top of shopping world, it’s undeniable that online is the first place people look when considering a purchase. And although it’s important to see a piece in person, art is well suited for online buying.
Purchases that require research and extended consideration on the part of a buyer — a process that occurs if you’re debating buying a major work of art — are perfect for online shopping.
The online shopping experience continues to improve. With the rise of big data and machine learning, retailers find it easier than ever to give users just the thing they want at just the right time. Features like “Customers who bought X also bought Y” drive customers to make more purchases — and can work well in online galleries.
Galleries are struggling. The global art world is currently in a boom cycle, with interest and sales high. But significant closures are putting galleries in a precarious position.
Major galleries like Acme, Wilkinson, and Off Vendome have shut their doors in recent years, blaming sky-high rents. And the expenses don’t end there — paying professional gallerists can be expensive, and too many are underpaid.
While this is a tough blow for the art industry, it’s also a signal that online art selling is on its way to becoming the default mode of transaction.
Say goodbye to the middle man. Many artists say they appreciate getting to engage directly with their audience — without being forced to work with a middle man to reach their fans. The fact is, exhibitions will never go out of style. But with online selling as an option, artists have the chance to constantly exhibit their work to their audience. It puts more power in their hands and gives buyers a direct route to work that excites them.
What’s the future of online art selling? For a while, analysts didn’t believe clothes shopping could translate online. After all, how do you sell someone pants online if they don’t get to try them on beforehand? But advanced technologies like virtual reality and augmented reality have changed everything, giving users the ability to virtually “try on” clothes and ensure they have the right size before hitting “buy.”
Now that concept is coming to the art world, with apps like INHAABIT enabling buyers to preview how a piece looks in their home before purchasing.
It’s safe to say the art world is in a period of exciting transition. As online selling grows in popularity, more buyers and sellers realize they have new options. How will you respond to this new environment, and how are you going to get in on the fun?
Although we’ve hinted at them already, it’s worth laying out the distinct advantages that come from selling art online. Ask most artists — especially ones just starting out — and they’ll tell you that online selling is a source of excitement and increased income. Galleries are also getting in on the fun, finding a new way to connect with art lovers around the world.
Here are a few of the benefits that come with selling art online:
Democratization. The art world isn’t always an even playing field. Artists who spend time at graduate schools or in major art programs tend to have a leg up in their field. They’re able to make contacts and form relationships with gallerists — something amateur artists have a much harder time doing. For artists who might not have the time or means to go to an elite art school, selling online is a great way for them to get their work in front of potential customers. The same applies for galleries. It can sometimes feel like David vs Goliath, with “mega-galleries” hogging all of the most lucrative pieces. Working online is a chance for smaller galleries to close that gap and find an audience.
Liberation. The art world can also have quite a bit of bureaucracy. The process of finding an exhibition, reaching out to the exhibition coordinators, and actually getting your work staged at the exhibition can take time — and lots of middle men. When working online, artists and galleries have the ability to work on their own terms.
Global impact. Art is a universal language. While there are certain hubs of art — like Rome, Paris, Berlin, and New York City — there are artists everywhere and people who want to buy art all over the map. With an online gallery, smaller galleries that are in more remote locations can find a global audience. And artists who might live outside of these hubs of the art world have the chance to connect with art lovers when selling online. In short, selling art online enables us to break down barriers and bring all artists and galleries onto the global stage.
Inventory. When you do all of your selling in the physical world, it can be tough to keep track of your inventory. But galleries that sell online can always have an up-to-date rundown of what’s on hand.
Ease. Avoiding bureaucratic red tape isn’t the only reason selling online is so easy. It’s also become a quick three-step process on many websites. Simply take a picture of your art, click upload, and then add a description — and you’re well on your way to an engaging online portfolio!
Community. Online art isn’t just about selling. It’s also about connecting — with other galleries, other artists, and other art lovers. Having your work alongside other artists in an online marketplace will motivate you to turn out new work and keep up with the latest trends. It will also inspire you to experiment with new forms.
It’s a whole new world for artists and galleries. Working digitally means a bigger audience, a lower barrier for entry, and an even playing field. But enough talk: How do you get started selling online?
How to get started selling online
The advantages are obvious — so now it’s time to learn how to sell art online and make money. For independent artists who are just trying to make it in the art world, it’s important to first learn how to promote your work online, then figure out how to make it as easy as possible for people to buy your work online.
Keep in mind that you might not make a ton of money right away. There’s a bit of a learning curve in terms of figuring out how to promote your work and finding buyers for it. So it’s important to find supplementary ways of driving income as an artist. We’ll outline useful artist “side hustles” — like teaching an online course. You’d be surprised to learn how many creative ways there are to make money as an artist.
Finally, we’ll outline which sites you should use to sell your work. While making a personal website to show off your portfolio is crucial, it’s also good to research various online marketplaces where you can post your work and connect with art lovers. These websites don’t just serve a practical purpose — they also connect artists with a community of like-minded individuals who can motivate and inspire.
Learning how to sell art online and make money can open up so many exciting avenues for you. And as technology advances, you’ll be excited to learn that getting started with this process is easier than ever.
People need to know about your work before they can buy it. Art galleries connect your work with a legion of art lovers. The internet has turned this system upside down, giving independent artists plenty of new and effective avenues for promoting their work. But before you can dive in, it’s worth assessing what kind of art you’re making and who your audience is.
What are my options? When it comes to self-promotion, you have many options. Physical spaces, like galleries, work well. You can even reach out to your community and see if offices, hotels, or public buildings want to feature your work. It’s a great way to get more people aware of the work you’re creating.
You also have online options. A personal website is a good start. That can be a central repository for your work, while providing important information about your background. You can also post your work in popular online art marketplaces, like Etsy.
What kind of art am I making? Different forms of art call for different forms of self-promotion. For most visual art, a combination of galleries and a regularly updated personal website are good routes. You’ll want to give people the ability to see your work in person but learn about it online.
Custom-made items are perfect for online sellers, especially if you’re collecting orders electronically anyway. And if you’re creating digital artwork, you’ll probably want to rely on a personal website.
Where is my audience? You know the art you’re making and the audience it appeals to, but where is this audience? Luckily, there are many resources to help you answer this question.
A variety of websites point toward specific audiences — such as those looking for more advanced visual art or those looking for fun customized art. Online marketplaces even give you the ability to specify your audience as a particular subculture — like fans of a certain TV show or sports team. Use these options to meet your audience where they are.
How can social media supplement my self-promotion needs? Of course, social media is a must if you’re trying to promote your art online. Not only can you connect with a large audience of art lovers, but you can also find communities of artists who support each other. You can find useful opportunities, collaborators, and more. And most important, you can build a community around your artwork, where people can give feedback, spread the word, and buy!
How can I keep my audience engaged? It’s one thing to have an audience; it’s another thing entirely to make sure they’re satisfied by and engaged with your work. Posting frequently on social media and keeping your website up to date are great ways to make sure everyone is in the loop.
Some artists have even experimented with writing a blog to keep fans abreast of their progress and aware of their upcoming projects. This is especially useful if your work is going to be in exhibitions and you want to spread the word and drum up excitement.
Self-promotion is key when it comes to a career in the arts. And don’t worry: There are plenty of ways to promote yourself without taking away from your work. Tasteful options like a well-designed personal website are a great way to get your work in front of people.
Overall, online options are becoming more than a supplementary tool for artists — in fact, in many cases they’re becoming the primary way artists connect with art lovers.
Find creative ways to make money as an artist
We’ll be real: Artists need to hustle! While you might be able to make a large portion of your income from art sales, you’ll probably want to work on additional sources of income. It’s important to remember that as an artist, you have a skill to offer. You can use this flare for the arts to generate additional income in creative ways. This blog post outlines some of the creative ways artists can supplement their income.
Best online art selling sites
Promoting your work is just one step in the online art selling process. The other crucial step involves actually selling your work. The good news is that there are lots of great art selling sites, which makes the process easy for artists and buyers alike. In this blog post, we highlight a few of the best sites that make selling art online easy.
How to curate your work on a website or online selling platform
Presentation is key when it comes to promoting your art online. You always want your website to do your fantastic artwork justice — so that all of your work looks attractive and ready to buy. Many artists spring for professional photographers to get the best possible pictures of their art. Others tap into their own artistic skills and photograph their artwork themselves using a powerful camera.
No matter how you capture your artwork, it’s only one part of the equation. You also need to classify your artwork correctly.
Whether you’re an independent artist or represent a gallery, building your website is a form of curation. What work do you want to highlight? How are you going to highlight this work? How are you going to organize your work so that individuals can digest your work in a clear, satisfying way?
Many website builders for artists make it easy to classify your work effectively. In other words, there’s no excuse to not have a beautiful, easy-to-navigate artistic website given all of the tools at your disposal. So let’s get ready to build!
Your website should be organized with your audience in mind. What do they want to see? What don’t they want to see? Try to put yourself in their shoes. Would you want to scroll through a million pages?
Labeling your art and characterizing it by type and other characteristics is a great way to make the online browsing experience seamless. And many websites are designed to make the process of setting your website up easy. Here’s what you should know:
Classify by type. You might be selling lots of different kinds of art. You don’t want to make your customers fish through a big jumble of all your art. Clearly delineate the different types of pieces and set up filters. For instance, if you’re a visual artist you may want to separate black-and-white images from color images. Or if you used a certain medium to create the piece, you’ll want to classify so that users can find any watercolor they want with the click of a button.
Sort by relevance. Whether you’re a gallery or an independent artist, you should make sure your art is laid out in a relevant fashion. This means prioritizing newer pieces and featuring the work that you feel there’s a large audience for. If you’re making customized work or fan art, it might be good to have a “top sellers” section so that users can navigate to the most popular pieces on your site without having to click through multiple pages.
Put your work first. Make sure your art is in a position to be admired — without distractions of any type. This includes busy background color schemes or third-party advertisements. People are on your website to see your art — not an ad or a particularly creative website design. That’s why many artists favor using a minimal white background.
Be descriptive but concise. Many websites give you the ability to add descriptions under your artwork. This enables you to give a bit of background about your piece. But again, remember your site is about letting your work do the talking. So don’t get overly detailed with your descriptions. If someone has questions about a certain piece, they can use the contact section of your website to get in touch.
Artists need to do everything they can to make their work sing. Classifying your work with accuracy and taste is an essential first step, enabling art lovers to easily find and buy your work.
Best website builders for artists
There are a wealth of great website builders out there for artists. From the versatile heavyweights to the more specialized artist-focused options, there’s something for everyone. And it seems like every year a new website builder pops up — boasting new features and a new level of usability. In this blog post, we outline the best website builders on the market for artists of all types.
Embedding JotForm into your website
You’ve set up just the right website. It features your work in an attractive, easy-to-browse way. It lets you put your best foot forward, while also enabling you to give some background about yourself and your artistic experience. It even includes a contact page for inquiries.
But wait. You’re missing one thing: a way to collect payments!
Enter JotForm. No matter which website builder you end up using, JotForm is a great way to collect information from potential buyers or set up an in-person meeting. And the best part is, you can easily embed JotForm forms across platforms — whether you’re using one of the site builder heavyweights or even something more obscure.
Once you’re finished, go to the Publish tab in the Form Builder. Then select Embed from the left panel and click on the Copy Code button. Boom! You have the code you need to embed your form.
Paste this code into your website. Choose where you want to paste this code. You might have a specific page in mind, like your purchase page. In this case, use your site builder to navigate to the correct page and edit the HTML. Most sites make it easy, even for technophobes, to edit the site’s HTML. For instance, on Wix you simply click Add on the main editor, click More, and click Embeds. Then you simply drag the embed code to the correct area of your page or click HTML iFrame. Enter the code, and you’re good to go!
JotForm isn’t just useful for payment processing forms. It’s also a great way to collect potential client contact information, especially if you’re making a custom piece with several specifications (like size, medium, extra instructions, etc.). And for a gallery, JotForm is a great way to help artists submit their work for consideration or organize your latest exhibition.
Your options are numerous. And the best part? Embedding is simple!
How an art gallery can use JotForm
Believe me: We understand that running an art gallery isn’t simple. There’s a lot of curation and organization that goes into such an enterprise — and oftentimes art galleries have limited staff.
Every minute — and every dollar — counts. There’s no time to waste, and efficiency is key. You need tools that you don’t have to worry about, that are easy to learn, easy to use, and provide results. That’s where JotForm comes in. Our simple, customizable Form Builder can come in handy in a variety of situations for art galleries.
Collecting submissions as a gallery
On our blog, we’ve highlighted some of the ways art galleries can use JotForm to collect submissions in a streamlined way. Running an exhibition isn’t easy, so having an organized approach to submissions is the best way to make sure you’re featuring the best work and making life easier for artists.
But while submitting work is a central use case for JotForm that we’ll highlight below, there are a few other powerful use cases that are also worth mentioning:
Collecting art submissions. Galleries are always on the lookout for great work. Making it as easy as possible for artists to submit their work enables you to collect a great deal of high-quality work. If you’re looking for submissions for an exhibition, you can quickly collect contact information and allow artists to attach their work to the form. They can also include background information about themselves or a description of the work they’re submitting. Here are two JotForm artwork submission forms that we like:
Collecting submissions is one thing. Keeping track of these submissions is another task altogether. Luckily, doing this is easy with JotForm. You can get email alerts for form submissions and automatically organize all of the submissions in a spreadsheet with the Google Sheets integration.
Signing up exhibition attendees. Are you organizing an exhibition or gallery opening? Using JotForm to keep track of attendance is a great way to make sure you collect contact information in a clear, streamlined way. And if attendance costs money, you can integrate with payment processors like Stripe or PayPal to ensure easy payment. Collecting all of these signups in a spreadsheet makes it easy to check off attendees at the door as they enter on the day of the exhibition. You can also make an attendance form that shows slot availability.
Collecting feedback. Art galleries are always looking to improve, to create an experience that celebrates artists and art lovers alike. One way to improve is by collecting feedback from visitors and exhibitors. You can easily customize your forms to adjust for gallery attendees versus artists. For instance, did artists have an easy time submitting work? Did they get something out of exhibiting? And did attendees have an enjoyable experience? Did they buy something from the gallery?
Running a class or lecture series. Art gallery programming can be diverse. It isn’t always an exhibition that needs to be organized. Maybe a guest speaker comes to the gallery for a lecture. Or you’re running a class for artists who want to practice a certain skill. In this case, JotForm can once again help. For a class, you might find you want to collect more than just contact information and student names. You might also want a better idea of a student’s experience level and specialized skills. In this case, you can include form fields that collect this information and arm you with the information you need to run a useful class.
Holding fundraising events. People love supporting the arts. It’s a chance for them to enrich and celebrate the artists who make our communities more vibrant and beautiful. Art galleries can be a hub for fundraisers. Some of these fundraisers might also use art sales to collect donations for a charity. Once again, JotForm is a helpful tool in this situation. Here’s a generalized fundraising form — and here are some more reasons why you should use JotForm for donations.
There are a lot of moving parts when it comes to running a gallery. Why not outsource data collection to JotForm instead of manually collecting data? This way, you can spend more time improving your gallery events, showing off great artwork, and enriching the community. Meanwhile, we’ll make sure you have the information you need, when you need it.
I learned something about percentage-based (%) padding today that I had totally wrong in my head! I always thought that percentage padding was based on the element itself. So if an element is 1,000 pixels wide with padding-top: 50%, that padding is 500 pixels. It’s weird having top padding based on width, but that’s how it works — but only sorta. The 50% is based on the parent element’s width, not itself. That’s the part that confused me.
The only time I’ve ever messed with percentage padding is to do the aspect ratio boxes trick. The element is of fluid width, but you want to maintain an aspect ratio, hence the percentage padding trick. In that scenario, the width of the element is the width of the parent, so my incorrect mental model just never mattered.
The difference is moot when you have a block element that expands to fill the width of its parent completely, as in every example used in this article. But when you set any width on the element other than 100%, this misunderstanding will lead to baffling results.
They pointed to this article by Aayush Arora who claims that only 1% of developers knew this.
Woah, I didn’t see this coming! The HTTP Archive dropped this big “state of the web” report called Web Almanac with guest writers exploring data from 5.8 million websites.
Una Kravetz and Adam Argyle wrote the CSS chapter. The point is to squeeze a digestible amount of insight out of a mountain’s worth of data. So there is some irony here with me squeezing in my thoughts about this chapter for an even quicker read, but hey, here we go.
83% of sites make use of rgba() but only 22% use rgb(). That entirely makes sense to me, as rgb() isn’t a particularly useful color format, if you ask me. It’s the “a” (alpha) that gives the format the ability control transparency, which is only recently available in the most popular format, Hex, in the form of 8-Digit Hex Codes. But even then, it isn’t as nice as rgba(). hsla() is arguably the nicest color format.
Definitely not surprising that white and black are the two most popular named colors. I use them, by name, a lot. I even change CSS commits to use white instead of #FFF and black instead of #000 because I think there is less mental overhead to it.
em is twice as popular as rem. Wow. I’m a rem guy myself, just because I find it less finicky and more predictable. In theory, I still like the idea of px at the Root, rem for Components, and em for Text Elements, but I’m not sure I’ve ever pulled it off that cleanly.
Classes are by far the leader in selector types. Factoring how many are used, they have over a 10x lead over anything else. I like to see that. They have a low-but-not-too-low specificity value. They have nice APIs for manipulating them. Their entire purpose is to be a styling hook. They are element-agnostic. It’s just the right way to do styling. The flatter you keep styles, the less headaches you’ll have., A little more surprisingly to me is the fact that the average number of classes per element is one. Makes me really wanna know the decimal though. Was it 1.1? 1.4? 1.00001?
Holy buckets. Flexbox on half of sites and grid only on two percent?! The browser support isn’t that different. I’m well aware they are both very useful and can be used together and are for different things, but I find grid generally more useful and personally use it more often than flexbox.
I would have guessed the median number of loaded fonts on a site to average to 0, but it’s 3! I think of CSS-Tricks as having one (which is Rubik at time of writing and used only for titles. The body font of this site is system-ui.) But really, it’s 4, because of preloading and subsetting and bold versus regular and such. I wonder when variable fonts will start having an impact. I would think it would lower this number over time. Open Sans and Roboto are triple any other loaded font, and the whole list is Google Font stuff, other than some instances of Font Awesome.
It’s funny how some major libraries can skew stats at such a global/universal scale for their use of certain features. I remember how YouTube’s play button used to “morph” into a pause button using an SVG technology called SMIL. But because YouTube is so huge, it could look like a very high percentage of internet traffic includes SMIL, when it’s really just one button on one site. filter is in that report. While filters are cool, it’s really the fact that it happens to be within YouTube embeds and Font Awesome’s stylesheet that the percentage of sites using it (78%) looks astonishingly high.
Of pages that make super heavy use of transitions and animations, transitions are about twice as heavily used, but, transitions are used six times more at the 50th percentile. That feels about right to me. Transitions are generally more useful, but the more animation you are doing, the more you reach for advanced tools like keyframes.
Looks like most websites have approximately 45 media queries on them. It’s not totally clear if those are different media queries, or if they could be the same media queries repeated elsewhere in the stylesheet. That seems like a lot if they are all different, so I suspect it’s just a tooling thing where people use nested media queries for authoring clarity and they bubble out but don’t get combined because that’s too weird with specificity. I’d be interested to see how many unique media queries people use. The most fascinating thing to me about the media query data is that min-width and max-width are neck-and-neck in usage. I would have put max-width far ahead if I was guessing.
About six stylesheets per site. It’s probably too hard to tell because assets like this are so often hosted on CDNs, but I’d love to know how many are hand-authored for the site, and how many are from third parties. Is the distribution like three and three or like one and five?
There is a lot more in the report, and CSS is just one of twenty chapters. So go digging!
I recently had an opportunity to try the new Vue Composition API in a real project to check where it might be useful and how we could use it in the future.
Until now, when we were creating a new component we were using Options API. That API forced us to separate the component’s code by options, meaning that we needed to have all reactive data in one place (data), all computed properties in one place (computed), all methods in one place (methods), and so on.
As it is handy and readable for smaller components, it becomes painful when the component gets more complicated and deals with multiple functionalities. Usually, logic related to one specific functionality contains some reactive data, computed property, a method or a few of them; sometimes it also involves using component lifecycle hooks. That makes you constantly jump between different options in the code when working on a single logical concern.
The other issue that you may have encountered when working with Vue is how to extract a common logic that can be reused by multiple components. Vue already has few options to do that, but all of them have their own drawbacks (e.g. mixins, and scoped-slots).
The Composition API brings a new way of creating component, separating code and extracting reusable pieces of code.
Let’s start with code composition within a component.
Code composition
Imagine you have a main component that sets up few things for your whole Vue app (like layout in Nuxt). It deals with the following things:
setting locale
checking if the user is still authenticated and redirects them if not
preventing the user from reloading the app too many times
tracking user activity and reacting when the user is inactive for specific period of time
listening on an event using EventBus (or window object event)
Those are just a few things the component can do. You can probably imagine a more complex component, but this will serve the purpose of this example. For the sake of readability, I am just using names of the props without the actual implementation.
This is how the component would look like using Options API:
As you can see, each option contains parts from all functionalities. There is no clear separation between them and that makes the code hard to read, especially if you are not the person who wrote it and you are looking at it for the first time. It is very hard to find which method is used by which functionality.
Let’s look at it again but identify the logical concerns as comments. Those would be:
Now imagine you need to make a change in one functionality (e.g. activity tracking logic). Not only do you need to know which elements are related to that logic, but even when you know, you still need to jump up and down between different component options.
Let’s use the Composition API to separate the code by logical concerns. To do that we create a single function for each logic related to a specific functionality. This is what we call a composition function.
// Activity tracking logic
function useActivityTracker() {
const userActivityTimeout = ref(null)
const lastUserActivityAt = ref(null)
function activateActivityTracker() {...}
function deactivateActivityTracker() {...}
function resetActivityTimeout() {...}
function userActivityThrottler() {...}
onBeforeMount(() => {
activateActivityTracker()
resetActivityTimeout()
})
onUnmounted(() => {
deactivateActivityTracker()
clearTimeout(userActivityTimeout.value)
})
}
// Reload blocking logic
function useReloadBlocker(context) {
const reloadCount = ref(null)
function blockReload() {...}
function setReloadCount() {...}
onMounted(() => {
setReloadCount()
blockReload()
})
}
// Locale logic
function useLocale(context) {
async function loadLocaleAsync(selectedLocale) {...}
function setI18nLocale(locale) {...}
watch(() => {
const locale = ...
loadLocaleAsync(locale)
})
// No need for a 'created' hook, all logic that runs in setup function is placed between beforeCreate and created hooks
const initialLocale = localStorage.getItem('locale')
loadLocaleAsync(initialLocale)
}
// Event bus listener registration
import EventBus from '@/event-bus'
function useEventBusListener(eventName, handler) {
onMounted(() => EventBus.$on(eventName, handler))
onUnmounted(() => EventBus.$off(eventName, handler))
}
As you can see, we can declare reactive data (ref / reactive), computed props, methods (plain functions), watchers (watch) and lifecycle hooks (onMounted / onUnmounted). Basically everything you normally use in a component.
We have two options when it comes to where to keep the code. We can leave it inside the component or extract it into a separate file. Since the Composition API is not officially there yet, there are no best practices or rules on how to deal with it. The way I see it, if the logic is tightly coupled to a specific component (i.e. it won’t be reused anywhere else), and it can’t live without the component itself, I suggest leaving it within the component. On the flip side, if it is general functionality that will likely be reused, I suggest extracting it to a separate file. However, if we want to keep it in a separate file, we need to remember to export the function from the file and import it in our component.
This is how our component will look like using newly created composition functions:
<template>
<div id="app">
</div>
</template>
<script>
export default {
name: 'App',
setup(props, context) {
useEventBusListener(MY_EVENT, handleMyEvent)
useActivityTracker()
useReloadBlocker(context)
useLocale(context)
const isAuthenticated = computed(() => ...)
watch(() => {
if (!isAuthenticated) {...}
})
function handleMyEvent() {...},
function useLocale() {...}
function useActivityTracker() {...}
function useEventBusListener() {...}
function useReloadBlocker() {...}
}
}
</script>
This gives us a single function for each logical concern. If we want to use any specific concern, we need to call the related composition function in the new setup function.
Imagine again that you need to make some change in activity tracking logic. Everything related to that functionality lives in the useActivityTracker function. Now you instantly know where to look and jump to the right place to see all the related pieces of code. Beautiful!
Extracting reusable pieces of code
In our case, the Event Bus listener registration looks like a piece of code we can use in any component that listens to events on Event Bus.
As mentioned before, we can keep the logic related to a specific functionality in a separate file. Let’s move our Event Bus listener setup into a separate file.
// composables/useEventBusListener.js
import EventBus from '@/event-bus'
export function useEventBusListener(eventName, handler) {
onMounted(() => EventBus.$on(eventName, handler))
onUnmounted(() => EventBus.$off(eventName, handler))
}
To use it in a component, we need to make sure we export our function (named or default) and import it in a component.
That’s it! We can now use that in any component we need.
Wrapping up
There is an ongoing discussion about the Composition API. This post has no intention to promote any side of the discussion. It is more about showing when it might be useful and in what cases it brings additional value.
I think it is always easier to understand the concept on a real life example like above. There are more use cases and, the more you use the new API, the more patterns you will see. This post is merely a few basic patterns to get your started.
Let’s go again through the presented use cases and see where the Composition API can be useful:
General features that can live on its own without tight coupling with any specific component
All logic related to a specific feature in one file
Keep it in @/composables/*.js and import it in components
Examples: Activity Tracker, Reload Blocker, and Locale
Reusable features that are used in multiple components
All logic related to a specific feature in one file
Keep it in @/composables/*.js and import in components
Examples: Event Bus listener registration, window event registration, common animation logic, common library usage
Code organization within component
All logic related to a specific feature in one function
Keep the code in a composition function within the component
The code related to the same logical concern is in the same place (i.e. there’s no need to jump between data, computed, methods, lifecycle hooks, etc.)
Remember: This is all a work-in-progress!
The Vue Composition API is currently at work in progress stage and is subject to future changes. Nothing mentioned in the examples above is sure, and both syntax and use cases may change. It is intended to be shipped with Vue version 3.0. In the meantime, you can check out view-use-web for a collection of composition functions that are expected to be included in Vue 3 but can be used with the Composition API in Vue 2.
Interruptions, administrative tasks, and too many meetings are among the common complaints voiced by today’s professionals. When was the last time someone complained about a canceled meeting? In other words, everyone understands what hinders productivity, right?
Not so fast, says computer scientist Cal Newport. While we all realize that interruptions and fragmented time are troublesome, we fail to recognize:
The frequency of interruptions: We convince ourselves that we are focusing on one task at a time, such as a complex interaction design problem. Yet, every ten minutes or so, we check email or answer a text. Yes, we’re performing one task at a time, but the duration of that task is brief.
The cost of these interruptions: As Newport explains on a recent episode of Hidden Brain: “Even those very brief checks that switch your context even briefly can have this massive negative impact on your cognitive performance. It’s the switch itself that hurts, not how long you actually switch.” (Emphasis mine)
This task switching was the focus of a study by business professor Sophie Leroy. She gave participants a cognitively demanding activity, such as solving a puzzle, and then briefly interrupted them before they completed it. When they returned to the original task, their performance dropped. As Leroy explains, these “results indicate it is difficult for people to transition their attention away from an unfinished task and their subsequent task performance suffers.”
Leroy calls this carryover from one activity to another “attention residue,” meaning that people are still thinking about the previous task even as they turn to the new one.
The most effective way to avoid attention residue is to structure your work in a way that reduces interruptions. Such structure requires understanding the difference between deep and shallow work.
Deep Work, Shallow Work, And Why They Matter
“Deep work is the ability to focus without distraction on a cognitively demanding task,” writes Newport in his book Deep Work. This work allows us to absorb, understand, and act on complicated information. Examples including coding, complex project plans, user research, and sophisticated design work.
Shallow work refers to tasks that do not require extensive thought and focus such as filling out expense reports and answering emails, texts, and Slack messages.
Shallow tasks are necessary. The question is how much time to devote to shallow and deep work and how to structure work in a way that facilitates reflection and concentration.
Left: Design is deep work. Right: Filling out a checklist is shallow work. (Image credits: FirmBee | raw pixel) (Large preview)
The Solution: Five Practical Tips For Pursuing Deep Work
Tip 1: Jump Into Design Work
Avoid the temptation to text or check email first thing. Put your phone on do not disturb. Get out your sketch pad or open your design tool and challenge yourself to solve one gnarly design problem by 10:00 am.
While this tip sounds like common sense, it’s not quite so straightforward because we are conditioned to respond to signals around us: “External triggers are cues from our environment that tell us what to do next. These are the dings and pings that prompt us to check our email, answer a text, or look at a news alert,” explains habit expert Nir Eyal in a post about distraction.
Eyal continues: “Competition for our attention can come from a person as well, such as an interruption from a coworker when we are in the middle of doing focused work.”
Computer scientist Cal Newport expands on this point by explaining the biology behind the itch to respond. When we don’t reply promptly to a text or email, we feel like we are ignoring someone from our tribe. Emotionally, it’s the modern-day equivalent of ignoring someone who is tapping on our shoulder as we sit around the fire. In short, it’s difficult to ignore messages and requests from co-workers.
Difficult but not impossible. Extend jumping into design work by blocking out untouchable time on your calendar. What about emergencies? “The short answer is that there really never are any,” writes podcaster and New York Times bestselling author, Neil Pasricha in Why You Need an Untouchable Day Every Week. These untouchable days involve deep, creative work.
While most professionals cannot set aside an entire day each week, they can mark two-hour blocks on their calendar a few times each week. Colleagues simply see “busy” when viewing your calendar. While not foolproof, this quiet signal shows that you know how to manage your time in order to engage in the deep work that your job requires.
Tip 2: Kickstart Your Brain With Useful Questions
By definition, deep work takes time and considerable brain resources. Sometimes we need a cognitive boost before tackling the problem head-on. When this is the case, ease into deep work by composing a list of questions to stimulate reflection. For example:
What is the organization trying to accomplish?
How does this site, product, or app align with that goal?
If revising an existing design: What would I do differently if I could recreate the design from scratch?
What would I do now if there were no legacy system constraints?
Note that these questions involve design but also encourage reflection beyond the immediate design challenge. The latter is important because the longer you work on a product or project, the easier it is to develop design blinders.
Easing into deep work or jumping in with both feet are often useful as long as it’s possible to avoid those nettlesome distractions. Even so, everyone gets stuck and needs time to regroup and let the mind wander.
Tip 3: Schedule Unstructured Thinking Time
Just as designers and other professionals need time to think through complex problems, they also need time to let the mind wander. The reason is the science behind “shower moments,” when ideas seem to arrive out of the blue.
In fact, the brain needs time for incubation, the psychological term for the unconscious recombination of thought processes after they are stimulated by conscious mental effort such as working on a specific design problem. In other words, when you set aside a strenuous mental task and do something less demanding, the brain is able to process and organize your thoughts to form new ideas.
Effective leaders value unstructured thinking time as outlined in How to Regain the Art of Lost Reflection. Jeff Weiner, CEO at LinkedIn, blocks at least 90 minutes for reflection and describes these buffers as “the single most important productivity tool” he uses. Susan Hakkarainen, Chairman and co-CEO of Lutron Electronics, uses 40-minute walks to reflect explaining that “Thinking is the one thing you can’t outsource as a leader. Holding this time sacred in my schedule despite the deluge of calls, meetings, and emails is essential.”
In short, designers should take their cues from these business leaders. Give your brain a break.
Tip 4: Vote It Off The Island
This tip comes from the Harvard Business Review article Stop Doing Low-Value Work by Priscilla Claman. She cites the example of a controller who was producing monthly reports that nobody read. He sent a list to his colleagues asking them to identify the three or four most important reports. He simply stopped writing the reports that no one was reading.
Another approach is to request permission to not do something such as asking customers if they really want their receipts. The point, writes Claman, is to stop doing something that is not important but to ask first to avoid getting in trouble. It’s vital that we stop ourselves from doing unimportant work.
Designers can identify possibly unimportant work by asking if:
Every wireframe must include detailed annotations;
Every design deliverable must include a detailed design document;
It’s really necessary to produce many variations of a design when studies about choice and decision making show that too many options make it harder to reach a decision.
No one wants to feel as if their work is sitting on a virtual shelf. By asking clients and stakeholders what matters to them, you’ll cater to their needs and save time by discarding unnecessary tasks.
The next step is to assess the remaining important work to determine how much time you can, and should, devote to deep thinking.
Tip 5: Distinguish Deep And Shallow Work
Follow the steps below to make this assessment concrete, something you can point to and share with your boss.
Identify the activities that you consider deep work such as planning a usability test, drawing wireframes, or mocking up a prototype.
Identify shallow work activities like answering emails, attending administrative meetings or meetings tangentially related to your core responsibilities.
Estimate the amount of time you spend on deep and shallow work each week.
Meet with your boss for thirty minutes and ask her what she thinks the ratio of deep to shallow work should be. Ask for a specific number. If you disagree, politely ask if you may experiment with a different ratio for one month.
Then, stick to the agreed-upon number for one month. Document any changes to your productivity, anything that contributes to a better product or service. After one month, report these findings to your boss.
This approach offers two advantages:
It’s usually wise to solicit the boss’s support.
A single proposal about deep work will not change an entire organization. Involving management, however, can serve as a catalyst for broader change just as the Google Ventures Design Sprint influenced the design process at Google and beyond.
Why Deep Work Makes Everything Better
Deep work allows designers and developers to thrive by leveraging their skills to solve complex problems and create better products and designs. Better products are likely to boost the bottom line while thriving and highly satisfied employees are more likely to stay (reducing turnover) and put their best selves forward.
Perhaps the best news for employers is that deep work does not require adding staff. The solution, explains computer scientist Cal Newport, is to re-configure work and communication. In other words, it’s not more people; it’s the same people managing work differently.
For example, agencies often answer to clients and need to be available at a moment’s notice. Rather than require every employee to be tethered to a phone or laptop, Newport suggests assigning a different employee each day to a dedicated email or a special “bat phone.” This shows the client their importance to the agency while also allowing designers to concentrate on designing, building, and solving problems.
Conclusion
Deep work is the ability to focus on challenging tasks like design and coding. Frequent interruptions make deep work nearly impossible and impose a high financial cost. In this piece, we’ve described five tips for maximizing the time you devote to deep work.
Jump into design work.
Draw fresh wireframes or work on a new design problem before checking emails and Slack messages. Block two-hour chunks on your calendar to allow time for deep thinking.
Kickstart your brain with useful questions.
Take a few minutes to ask what you are trying to accomplish and how it aligns with the company’s keep performance indicators (KPIs). Alignment with KPIs is especially important for user experience designers who are frequently asked to justify their budget
Schedule unstructured thinking time.
Take a walk, stare out the window, or whatever allows your mind to wander. This “downtime” allows the brain to form new connections.
Vote it off the island.
Are you writing reports that no one reads? Are you scheduling meetings that your co-workers find less than useful? Ask your colleagues if it’s okay to stop. They might respond with a gleeful “yes!”
Distinguish deep and shallow work.
Then, meet with your boss to arrive at the right balance between these two types of work.
Google Algorithm Updates – three big words that are good for Google, but sometimes bad for your website. Unless of course, you’re ahead of Google’s game.
When do Google Algorithm Updates affect your site? Frequently. Over 500 updates have been released over the past year alone, some small and unobtrusive, and others considered major algorithm updates – with the potential to wreak havoc on your website ranking plans. So how do you stay ahead of Google’s Algorithm Updates?
Below are 10 helpful insights for staying ahead of the game.
1. First, be a good player. Truthful, quality content that adds value to your audience is not overlooked by Google’s AI. Gone are the days when Google ranked sites on the basis of just keywords, related links or dumb sites (sites that have no value except to refer or link back to the target site). Google can tell the difference between a site that truly adds value, compared to a site that repeats information or spammy keywords. Google’s algorithms can detect weak site content and can penalize your site rankings, so keep it true.
The folks at emarketeers.com said it best regarding good site content: “Google qualifies premium content as informative, engaging, relevant, authoritative and trustworthy.”
2. Avoid Blackhat SEO. This goes without saying and a bit opposite to #1 above – don’t try to beat Google’s system by using backdoor tricks that manipulate your site to greater heights artificially. Using techniques such as Hidden Text or Links, Keyword Stuffing, Sneaky Redirects or Cloaking will eventually reduce your ranking or get you penalized by the very algorithm system you are trying to beat.
3.Use site analysis tools to stay on top of your site’s performance. Tools like Google Trends and Moz can give valuable insight as to which direction your site is headed or where it’s been over time.
Enter a search word or phrase into Google Trends (https://trends.google.com) to see where in your country or region, that term or phrase is being searched. Other options show current trends based on search keywords, or past trends over time.
Moz tools provide insight for site SEO feedback, site performance, analysis for backlinks, keyword identification and site audits – all geared towards helping you stay ahead of Google’s Algorithm Updates.
4.Don’t bet the farm on just your website(s). When (not if) you get hit by Google Algorithm Updates and site performance dips, have other social media tools already in place. Use these tools to point those searching for your products or information back to your site. If your site performance dips because of any Google Algorithm Updates, traffic will still be directed to your site from other sources until you make the necessary adjustments to rank your site higher again.
5.Strengthen your site-to-conversion rate. You have a great site and you’re getting lots of organic traffic, but are you selling? And if your site is more informational, are those coming to your site staying on your site? Whether your site revenue is product or ad-driven, getting people to use your site for the intended purpose is key. Good SEO helps people find your site, but when Google Algorithm Updates cause new traffic to dip, repeat customers who know your site will continue to generate revenue.
6. Keep site information fresh. Regularly updating your site with new, relevant information or products will guarantee a better user experience. Neil Patel (neilpatel.com) who knows a thing or two about good site design and content says to “Focus on the fundamentals. A good user experience relies on good content. If you remember this, you’re less likely to be penalized in any future Google update.”
7. External and internal links. Have you ever asked yourself, what is SEO? SEO is all about driving traffic to your site, and links from other sources can also move people your direction. Promote yourself and your site by linking internally within your site from blog pages, sidebars, landing pages, and product pages. Helping users navigate through your site is not only good user interface, it also helps to rank your site higher.
External links are just as important, especially when it comes to related traffic. These links are a bit like LinkedIn relationships, where those you know or those you do business with, link to your site because of related content, product reviews, outside blogs and industry-related sharing of information. See https://www.emarketeers.com for additional specks on how to capitalize on internal and external links.
8. Stay in tune with Google. Google rarely announces algorithm updates. If they did, they would be posting announcements all the time, which isn’t their model, but with some major core updates, such as the June 2019 core update, Google tweeted it was coming and how it would add additional restrictions of two-listing from the same domain for search results. Some algorithm updates will affect your site rankings, while others may not, but it’s good to keep an eye on Google announcements (see tweets from Google SearchLiaison).
9.Go Mobile. The keyboard has changed. There are far more mobile phones in our hands than there are workstations and searches done with mobile devices return more relevant regional, local and more precise information than general searches do. Past Google Algorithm Updates have improved mobile results and helped rank mobile results specifically over desktop searches. GPS tracking on mobile devices helps return more local and more accurate results, so don’t forget to also design your site for mobile. After all, more people are searching for your site with their thumbs, not with a full-sized keyboard.
10. Learn from the best of the best. You may be good at SEO, but there is always someone you can learn from. Do a Google search for “top SEO influencers” or “best SEO experts” and the list is always similar. SEO Guru’s like Barry Schwartz, Neil Patel, Kristi Hines, and many others serve as mentors to the rest of us who can always learn from those who have paved the way to proven results. In fact, these guys probably use search phrases similar to the two phrases above on their own sites, boosting their own rankings when you search for “industry-leading SEO experts”. Why?
