An interestingly regressive technique for expanding the size of a rectangle with rounded corners in CSS that protects the corners themselves from deforming, all by using transform.
Let’s apply this to our square. It will mean we need one container and three child elements to represent the square left (1), center (2), and right (3) parts.
...when the web was young, the free market in ideas was open to anyone with access to a library’s internet connection.
But the web rewards network effects and network effects have led to monopolies. Google doesn’t really want a free market in ideas (they hate blogs), instead, they want a market in which they’re the landlord. Facebook enabled a huge outpouring of voices from people who didn’t previously have a microphone, but their algorithms and focus on clicks led toward incentives for outrage as the voices corroded so many elements of our culture.
A service worker can request just the bare minimum of data it needs from the server... and then it can programmatically transform that data into a full HTML document.
{...}
By only requesting the contents of a page, the networks payloads become substantially smaller, and the pages can load quite a bit faster.
A great overview of why a custom select component can be problematic:
<select multiple>, which is standardised across OSes but has very poor success rates in UX tests;combobox.Enter should not trigger a form submission but most users may expect it to, making it hard to utilise in an accessible way (see second article as well for how confusing this can be).In the followup article, user testing (albeit with a small sample size) showed that - to the surprise of none - the native select element is consistently the easiest to use across platforms for basic form requirements. However, <select multiple> was comfortably the worst user experience for multiselect. 🤔
But, when male brand mascots outnumber female mascots two-to-one, is there still a place for this approach in today’s society?
I'm a particular fan of the Green Giant:
Originally discovered via The Logo Smith.
Information wants to be free or it wants to be expensive.
Both are true. It either benefits from everyone knowing it, or it becomes worthwhile because it is scarce.
I don't think I've come across a clearer explanation of the full cascade before, nor one so beautifully crafted. An excellent resource and inspiration.
A great explanation of why two-pass rendering is a useful mental model to consider when working with server-side rendering/SSGs like Gatsby and JavaScript frameworks. The main point? Rehydration ≠ rendering, so don't load dynamic content until rehydration is finished if you want to avoid weird layout bugs and jankiness; use hooks or "Client-only" component abstractions instead.
Critically, rehydration is not the same thing as a render. In a typical render, when props or state change, React is prepared to reconcile any differences and update the DOM. In a rehydration, React assumes that the DOM won't change. It's just trying to adopt the existing DOM.
An excellent overview of (most of) the unit options you can use in CSS Grid columns and rows, with examples. (No RSS)
A neat little project that highlights potentially insensitive language used within the provided copy (for English, at least).
Oh boy, there's a lot worth pulling out of this overview of upcoming web technologies:
[Mid-range Android phones are the] median device that web users have, Apple’s market share in terms of 2019 Q1 sales in the US is 39%, with Samsung at 28%, while the rest is a range of Android devices which sell for between $500 and $50 dollars.
In other words, as Simon says, the single biggest UX impact is the size of JS shipped. Mid-range phones don't just struggle to download large JS packages, they also struggle to process them quickly.
The web is an open and democratic place, when people are forced to use only native apps they have a limited window on the web experience and the knowledge available therein.
Truth. And, as noted, a part of that lock-in to native is the huge amount of framework code we're shipping, shuttering out those mid- or low-end phones. Jamstack static-site generators are marked here as one potential solution, though they still ship a lot more JavaScript then they might. I really hope Simon's prediction of more competition in the SSG hosting space comes true though; I love Netlify but shaking things up is always a positive.
Another potential solution is Web Assembly, which (apparently) compiles 20x faster than JS 😲 That could significantly decrease the JS load needed for, say, React by converting process-heavy parts to WASM. That could be a massive gain to the entire web community by one team's efforts:
In this example a single React release could raise the tide of web performance for all React-based websites.
In terms of Google's proposed "slow website" badge, Simon raises some interesting counter points:
Who knows what the workaround techniques will be: loading screens like 1999, screenshots rendered while the page loads in the background, UA sniffing to deliver a faster experience to googlebot.
He also takes aim at Google Analytics trailing behind on key UX features like Real User Measurements (things like largest contentful paint and blocking time). I'm not sure I buy this quite as much, but any (non-invasive) improvements to the metrics that GA provides would be welcome.
Slow sites cost money, and observability helps us to allocate funds to improve performance.
I guess I'm reading up on React Context a lot today. Kent provides a useful step-by-step guide in his normal steady manner, which I found pretty easy to grasp. He also makes a very valid point:
Context does NOT have to be global to the whole app, but can be applied to one part of your tree
I've yet to need context very heavily, but this feels like a solid rule of thumb: if it can be localised, do it. It's also interesting hearing his thoughts on default states:
None of us likes runtime errors, so your knee-jerk reaction may be to add a default value to avoid the runtime error. However, what use would the context be if it didn't have an actual value? If it's just using the default value that's been provided, then it can't really do much good.
Finally, I'm a big fan of how he imports hooks as a priority via his context API. It just feels a lot cleaner that way 👍