This extended category features articles on client-side and server-side programming languages, tools, frameworks and libraries, as well as back-end issues. Experts and professionals reveal their coding tips, tricks and ideas. Curated by Dudley Storey and Rey Bango. Subscribe to the RSS-Feed.
Email is one of the best ways to engage with your users, especially during the holiday season. However, if you want to stand out, no matter how beautiful your emails are, you need to make sure they render correctly in your reader's inbox, regardless of what email client they're using. Creating responsive email is not an easy task, and there are various reasons for that.
First, there is no standard in the way email clients render HTML. This is true for email clients from different companies, such as Outlook and Apple Mail, but not only. Even different versions of Outlook, such as Outlook 2003, Outlook 2013 and Outlook.com, render HTML differently.
First of all, let's define some vocabulary. "Internationalization" is a long word, and there are at least two widely used abbreviations: "intl," "i18n". "Localization" can be shortened to "l10n".
Internationalization can be generally broken down into three main challenges: Detecting the user's locale, translating UI elements, titles as well as hints, and last but not least, serving locale-specific content such as dates, currencies and numbers. In this article, I am going to focus only on front-end part. We'll develop a simple universal React application with full internationalization support.
Building user interfaces on the web is hard, because the web and, thus, CSS were inherently made for documents. Some smart developers invented methodologies and conventions such as BEM, ITCSS, SMACSS and many more, which make building user interfaces easier and more maintainable by working with components.
HTML email: Two words that, when combined, brings tears to a developer's eyes. If you're a web developer, it's inevitable that coding an email will be a task that gets dropped in your lap at some time in your career, whether you like it or not. Coding HTML email is old school. Think back to 1999, when we called ourselves "webmasters" and used Frontpage, WYSIWYG editors and tables to mark up our websites.
Not much has changed in email design. In fact, it has gotten worse. With the introduction of mobile devices and more and more email clients, we have even more caveats to deal with when building HTML email.
The blank Photoshop document glows in front of you. You've been trying to design a website for an hour but it's going nowhere. You feel defeated. You were in this same predicament last month when you couldn't design a website for a project at work. As a developer, you just feel out of your element pushing pixels around.
How do designers do it? Do they just mess around in Photoshop or Sketch for a while until a pretty design appears? Can developers who are used to working within the logical constructs of Boolean logic and number theory master the seemingly arbitrary rules of design?
Web components are an amazing new feature of the web, allowing developers to define their own custom HTML elements. When combined with a style guide, web components can create a component API, which allows developers to stop copying and pasting code snippets and instead just use a DOM element.
By using the shadow DOM, we can encapsulate the web component and not have to worry about specificity wars with any other style sheet on the page. However, web components and style guides currently seem to be at odds with each other.
Recently, I decided to rebuild my personal website, because it was six years old and looked — politely speaking — a little bit "outdated." The goal was to include some information about myself, a blog area, a list of my recent side projects, and upcoming events.
As I do client work from time to time, there was one thing I didn't want to deal with — databases! Previously, I built WordPress sites for everyone who wanted me to. The programming part was usually fun for me, but the releases, moving of databases to different environments, and actual publishing, were always annoying.
If you’ve been following the web development community these last few months, chances are you’ve read about progressive web apps (PWAs). It’s an umbrella term used to describe web experiences advanced that they compete with ever-so-rich and immersive native apps: full offline support, installability, “Retina,” full-bleed imagery, sign-in support for personalization, fast, smooth in-app browsing, push notifications and a great UI.
But even though the new Service Worker API allows you to cache away all of your website’s assets for an almost instant subsequent load, like when meeting someone new, the first impression is what counts. If the first load takes more than 3 seconds, the latest DoubleClick study shows that more than 53% of all users will drop off.
Editor’s note:Please note that this article is quite lengthy, and contains dozens of CodePen embeds for an interactive view. The page might take a little while to load, so please be patient.
Layout on the web is hard. The reason it is so hard is that the layout methods we've relied on ever since using CSS for layout became possible were not really designed for complex layout. While we were able to achieve quite a lot in a fixed-width world with hacks such as faux columns, these methods fell apart with responsive design. Thankfully, we have hope, in the form of flexbox — which many readers will already be using — CSS grid layout and the box alignment module.
In this article, I'm going to explain how these fit together, and you'll discover that by understanding flexbox you are very close to understanding much of grid layout.