Industries often experience evolution less as slow and steady progress than as revolutionary shifts in modality that change best practices and methodologies seemingly overnight. This is most definitely true for front-end web development.
Our industry thrives on constant, aggressive development, and new technologies emerge on a regular basis that change the way we do things in fundamental ways.
Fluid layouts have been a normal part of front-end development for years. The idea of fluid typography, however, is relatively new and has yet to be fully explored. Up until now, most developers’ idea of fluid typography is simply using Viewport units maybe with some minimum and maximum sizes.
In this article, we are going to take it to another level. We are going to examine how to create scalable, fluid typography across multiple breakpoints and predefined font sizes using well-supported browser features and some basic algebra. The best part is that you can automate it all by using Sass.
Jekyll is gaining popularity as a lightweight alternative to WordPress. It often gets pigeonholed as a tool developers use to build their personal blog. That’s just the tip of the iceberg — it’s capable of so much more!
In this article, we’ll take on the role of a web developer building a website for a fictional law firm. WordPress is an obvious choice for a website like this, but is it the only tool we should consider? Let’s look at a completely different way of building a website, using Jekyll.
Today, CSS preprocessors are a standard for web development. One of the main advantages of preprocessors is that they enable you to use variables. This helps you to avoid copying and pasting code, and it simplifies development and refactoring.
We use preprocessors to store colors, font preferences, layout details — mostly everything we use in CSS. But preprocessor variables have some limitations.
Safari 10.1 was announced a while ago already, and this week it finally came to Macs and iOS devices around the world. The new Safari version ships CSS Grid Layouts, fetch(), IndexedDB2.0, Custom Elements, Form Validation, Media Capture, and much more.
If you have been following Google’s changes recently, you may have noticed that they became obsessed with mobile web. And there are a couple of strong reasons to support that. According to Search Engine Land, Google has officially confirmed that mobile search surpassed desktop back in 2015. Moreover, in October 2016, Google announced mobile-first indexing which focuses on prioritizing the mobile version of a website’s content over the desktop version when assigning search rankings. This obsession led to the introduction of Accelerated Mobile Pages (also known as AMP) which are primarily designed to provide the mobile user with an immersive,…
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.
Most people now know that modern web browsers use the GPU to render parts of web pages, especially ones with animation. For example, a CSS animation using the transform property looks much smoother than one using the left and top properties. But if you ask, “How do I get smooth animation from the GPU?” in most cases, you’ll hear something like, “Use transform: translateZ(0) or will-change: transform.”
These properties have become something like how we used zoom: 1 for Internet Explorer 6 (if you catch my drift) in terms of preparing animation for the GPU — or compositing, as browser vendors like to call it. But sometimes animation that is nice and smooth in a simple demo runs very slowly on a real website, introduces visual artifacts or even crashes the browser. Why does this happen? How do we fix it? Let’s try to understand.
We have great new technology available to enhance our websites. But while theoretical articles explain well what the technologies do, we often struggle to find real use cases or details on how things worked out in actual projects.
This week I stumbled across a couple of great posts that share exactly these precious real-life insights: stories about HTTP/2 implementation, experiences from using the Cascade of CSS in large-scale projects, and insights into employing Service Worker and BackgroundSync to build solid forms.
But then again, we have to remind ourselves that we shouldn’t immediately jump to a new tool just because it’s available, to not rewrite the whole code of a project just because conventions have changed. No project will stop working because you’re using OOCSS instead of ITCSS or Backbone.js instead of React.js. If the project is an ongoing process and will be developed and maintained for another few years, you should evaluate to change tools from time to time, of course. But take your time. Better evaluate first, then reconsider, before you immediately jump on a train from which you don’t know where it’s heading.