Quite a bit of this, mainly later on, feels unjust. Many are problems about mobile devices, not the web. Sizes don’t mean what you might expect? They don’t on any platform. A pixel hasn’t been a physical pixel reliably for at least fifteen years, and far longer in some ecosystems. Physical units never matched reality reliably, which is part of the reason they have steadily been phased out or discouraged across all platforms (Firefox’s mozmm unit is a fun piece of history: it tried to be one physical millimetre).
> One way we could have ensured that designs are accessible is to make it impossible to build anything else.
The only way of achieving this is by hobbling the web in a way that I guarantee would have killed it.
> The <input> tag is like 30 years old, but that has apparently not been enough time for us to figure out how to make it usable!
It was enough time. <input> was fine. But then devices without physical keyboards came along, and ruined it.
You’ll have the same problems if you try adding text input to your landscape mobile game using the platform’s native toolkit. In these areas, the web is not the problem: phones are, due to their limited screen size and different input methods; and mixed-input devices/platforms are—Windows two-in-ones are full of touch/pen niggles Android doesn’t have, whether you’re web or native (and Android with a pointer has issues in the other direction).
Web as a platform is universally deployed on mobile devices. Whether it is theoretically impeccable or not (heh), the way it works in practice is such that it does not isolate the author from the shortcomings of the target native platform. Though it tries to, and it sort of promises that in the standards, it fails to consistently deliver, especially on iOS where Apple virtually does not allow competition. Such is the sad reality of the web platform.
> LocalStorage is not available in private browsing mode. Other browsers just treat it as ephemeral/SessionStorage basically.
Correction: it’s not available in Firefox either, throws on get/set. It’s the Chromium family that’s the odd one out, but it’s so popular and testing in other browsers’ private windows so uncommon that developers often don’t realise that localStorage is fallible.
I’ve been noticing DuckDuckGo search results increasingly frequently doing this. They used to either use the <meta name=description> (which is subject to abuse by the site) or show an excerpt from the page text highlighting the keyword matches (which is often most helpful), but from time to time now I see useful meta descriptions or keyword matches sidelined in favour of what I presume is Microsoft-generated clickbaity slop of a “learn more about such-and-such” kind, occasionally irrelevant to the actual article’s text or even inconsistent with it.
I feel like indentation is a really useful structural signal that has been hijacked, in C-family languages, by unnecessarily strict conventions and most recently by autoformatters, to correspond exclusively to language structure, when it could be used for semantic structure as well (or occasionally instead).
Much of the value of this block pattern is that it makes the scope of the intermediate variables clear, so that you have no doubt that you don’t need to keep them in mind outside that scope.
But it’s also about logical grouping of concepts. And that you can achieve with simple ad hoc indentation:
fn foo(cfg_file: &str) -> anyhow::Result<()> {
// Load the configuration from the file.
// Cached regular expression for stripping comments.
static STRIP_COMMENTS: LazyLock<Regex> = LazyLock::new(|| {
RegexBuilder::new(r"//.*").multi_line(true).build().expect("regex build failed")
});
// Load the raw bytes of the file.
let raw_data = fs::read(cfg_file)?;
// Convert to a string to the regex can work on it.
let data_string = String::from_utf8(&raw_data)?;
// Strip out all comments.
let stripped_data = STRIP_COMMENTS.replace(&config_string, "");
// Parse as JSON.
let config = serde_json::from_str(&stripped_data)?;
// Do some work based on this data.
send_http_request(&config.url1)?;
send_http_request(&config.url2)?;
send_http_request(&config.url3)?;
Ok(())
}
(Aside: that code is dreadful. None of the inner-level comments are useful, and should be deleted (one of them is even misleading). .multi_line(true) does nothing here (it only changes the meanings of ^ and $; see also .dot_matches_new_line(true)). There is no binding config_string (it was named data_string). String::from_utf8 doesn’t take a reference. fs::read_to_string should have been used instead of fs::read + String::from_utf8. Regex::replace_all was presumably intended.)
It might seem odd if you’re not used to it, but I’ve been finding it useful for grouping, especially in languages that aren’t expression-oriented. Tooling may be able to make it foldable, too.
I’ve been making a lightweight markup language for the last few years, and its structure (meaning things like heading levels, lists, &c.) has over time become almost entirely indentation-based. I find it really nice. (AsciiDoc is violently flat. reStructuredText is mostly indented but not with headings. Markdown is mostly flat with painfully bad and footgunny rules around indentation.)
—⁂—
A related issue. You frequently end up with multiple levels of indentation where you really only want one. A simple case I wrote yesterday in Svelte and was bothered by:
$effect(() => {
if (loaded) {
… lots of code …
}
});
In some ancient code styles it might have been written like this instead:
$effect(() => { if (loaded) {
… lots of code …
} });
Not the prettiest due to the extra mandatory curlies, but it’s fine, and the structure reasonable. In Rust it’s nicer:
effect(|| if loaded {
… lots of code …
});
But rustfmt would insist on returning it to this disappointment:
effect(|| {
if loaded {
// … lots of code …
}
});
Perhaps the biggest reason around normalising indentation and brace practice was bugs like the “goto fail” one. I think there’s a different path: make the curly braces mandatory (like Rust does), and have tooling check that matching braces are at the same level of indentation. Then the problem can’t occur. Once that’s taken care of, I really see no reason not to write things more compactly, when you decide it is nicer, which I find quite frequently compared with things like rustfmt.
I would like to see people experiment with indentation a bit more.
—⁂—
One related concept from Microsoft: regions. Cleanest in C♯, `#region …` / `#endregion` pragmas which can introduce code folding or outlining or whatever in IDEs.
This has the effect that you’re shifting the list rather than the item. And yet your actual controls are anchored to the item.
On a touch device, to shift an item from the middle of a list to the top:
• With traditional drag-and-drop: press in the middle (long press or regular press on a movement grabby), drag upwards, release.
• With this: tap in the middle, on the item, then press anywhere, drag down, release.
It’s uncomfortable. The logical entity you’re manipulating is the item, but you’re having to do it by interacting with the list, and if your drag starts on the item it’ll achieve the opposite of what you want.
It may also interact a little poorly with retracting browser chrome, which is very common on mobile. I’d definitely say it does on Firefox for Android with top address bar.
As for other platforms… ouch. With a precise touchpad it’s bizarre and uncomfortable but functional (though the scroll direction thing will probably hit even harder and be even more frustrating); with a mouse with indexed scrolling it’s fairly fundamentally unusable.
All up, although it’s an interesting direction to explore, I don’t like it at all at present, and doubt the scrolling aspect can be salvaged. Direct manipulation is good.
I agree, this doesn't make sense. Also how can you place the item when there is no space to put it?
If you want to mimic reality you should:
1) drag and drop outside of the list the item you want to move putsode the list
2) drag and drop the item in the place you want to put your selection
3) place your pick in the empty space
4) quietly discard the item you dislodged
5) wait for people to point out you are now missing one item
6) drag and drop the person under the carpet
7) repeat until no criticism
It should be at least theoretically possible: each IP address is assigned to an organisation running the IP routing prefix, and you can look that up easily, and they should have some sort of abuse channel, or at the very least a legal system should be able to compel them to cooperate and give up the information they’re required to have.
> We couldn't have guessed it at the time, but as of 2025, Google is pushing developer verification and stepping closer and closer to ecosystem lockdown.
We did guess it. Google were already past their “don’t be evil” days in 2013. They were possibly better than other companies of similar scale, but the decline was already clearly beginning. People had long warned that Google could not be trusted to keep Android open in the long term, that eventually their benevolence would fade. A good chunk of the enthusiasm around Firefox OS was in breaking the duopoly and the idea of a platform that would be much harder to lock down.
Fair point, I think I have to concede that you're right that it was perhaps perceivable at that time. In my defense, I will say that we are seeing some pretty concrete actions out in the wild in 2025 that we were only speculating on in 2013 heightening the urgency of the issue.
> One way we could have ensured that designs are accessible is to make it impossible to build anything else.
The only way of achieving this is by hobbling the web in a way that I guarantee would have killed it.
> The <input> tag is like 30 years old, but that has apparently not been enough time for us to figure out how to make it usable!
It was enough time. <input> was fine. But then devices without physical keyboards came along, and ruined it.
You’ll have the same problems if you try adding text input to your landscape mobile game using the platform’s native toolkit. In these areas, the web is not the problem: phones are, due to their limited screen size and different input methods; and mixed-input devices/platforms are—Windows two-in-ones are full of touch/pen niggles Android doesn’t have, whether you’re web or native (and Android with a pointer has issues in the other direction).
reply