Select Page

Category: Link

Firefox Multi-Account Containers

It’s an extension: Each Container stores cookies separately, so you can log into the same site with different accounts and online trackers can’t easily connect the browsing. A great idea for a feature if you ask me. For example, I have two Buffer accounts and my solution is to use different browsers entirely to stay logged into both of them. I know plenty of folks that prefer the browser version of apps like Notion, Front, and Twitter, and it’s cool to have a way to log into the same site with multiple accounts if you need to — and without weird trickery. This is browsers competing on UI/UX features rather than web platform features, which is a good thing. Relevant: Opera Neon and Refresh. Direct Link to Article — Permalink The post Firefox Multi-Account Containers appeared first on CSS-Tricks....

Read More

Seriously, though. What is a progressive web app?

Amberley Romo read a ton about PWAs in order to form her own solid understanding. “Progressive web app” (PWA) is both a general term for a new philosophy toward building websites and a specific term with an established set of three explicit, testable, baseline requirements. As a general term, the PWA approach is characterized by striving to satisfy the following set of attributes: Responsive Connectivity independent App-like-interactions Fresh Safe Discoverable Re-engageable Installable Linkable Direct Link to Article — Permalink The post Seriously, though. What is a progressive web app? appeared first on CSS-Tricks....

Read More

Creating the “Perfect” CSS System

My pal Lindsay Grizzard wrote about creating a CSS system that works across an organization and all of the things to keep in mind when starting a new project: Getting other developers and designers to use the standardized rules is essential. When starting a project, get developers onboard with your CSS, JS and even HTML conventions from the start. Meet early and often to discuss every library, framework, mental model, and gem you are interested in using and take feedback seriously. Simply put, if they absolutely hate BEM and refuse to write it, don’t use BEM. You can explore working around this with linters, but forcing people to use a naming convention they hate isn’t going to make your job any easier. Hopefully, you will be able to convince them why the extra underscores are useful, but finding a middle ground where everyone will participate in some type of system is the priority. I totally agree and the important point I noted here is that all of this work is a collaborative process and compromise is vital when making a system of styles that are scalable and cohesive. In my experience, at least, it’s real easy to walk into a room with all the rules written down and new guidelines ready to be enforced, but that never works out in the end. Ethan Marcotte riffed on Lindsay’s post in...

Read More

The Cost of JavaScript in 2018

Even though we mentioned it earlier, I thought this outstanding post by Addy Osmani all about the performance concerns of JavaScript was still worth digging into a little more. In that post, Addy touches on all aspects of perf work and how we can fix some of the most egregious issues, from setting up a budget to “Time-to-Interactive” measurements and auditing your JavaScript bundles. Embrace performance budgets and learn to live within them. For mobile, aim for a JS budget of < 170KB minified/compressed. Uncompressed this is still ~0.7MB of code. Budgets are critical to success, however, they can’t magically fix perf in isolation. Team culture, structure and enforcement matter. Building without a budget invites performance regressions and failure. Super specific and super practical! Surprisingly, Addy mentions that “the median webpage today currently ships about 350KB of minified and compressed JavaScript,” which seems like an awful lot lower than I’d expected, if I’m being honest. The stat that scares me most is that the median webpage takes around fifteen whole seconds until it’s interactive. And pulling all that JS into a Web Worker or caching with Service Workers won’t even make up that time to interaction. Yikes. Another key point: not all bytes are equal. For example, 200KB of JavaScript is not equal to a 200KB JPG image file: A JPEG image needs to be decoded, rasterized, and painted...

Read More

Your Body Text is Too Small

Several years ago, there was a big push by designers to increase the font-size of websites and I feel like we’re living in another era of accessibility improvements where a fresh batch of designers are pushing for even larger text sizing today. Take this post by Christian Miller, for example, where he writes: The majority of websites are still anywhere in the range of 15–18px. We’re starting to see some sites adopt larger body text at around 20px or even greater on smaller desktop displays, but not enough in my opinion. Christian attributes this to all sorts of different things, but I particularly like this bit: Unfortunately, it’s a common mistake to purposefully design a website in a way to avoid scrolling. To the detriment of design, body text size is reduced to either reduce scrolling, or condense the layout in order to fit other elements in and around the copy. Scrolling is a natural, established pattern on the web—people expect to have to scroll. Even when it isn’t possible, people will attempt scrolling to see if a page offers more beyond what’s initially in the viewport. Readability is more important than the amount of scrolling required—good content won’t prevent users from scrolling. I would only push back a little bit on the advice — that legibility isn’t always tied to the font-size of a block of text. A lot...

Read More
000webhost logo