very cool. this is why i hate the modern web.

@ariadne anti-fingerprinting feels like a pyrrhic victory to the extent it can be achieved

sure, random webpages probably don't need to know how many cores you have (and thoughtful design could keep this available to those few which maybe do). but the thing that made me conclude this is Accept-Language:, a feature that is intentionally made worse for bilingual users in service of reducing fingerprintability. i think i'd rather have that than a (in practice) false promise about privacy

@whitequark @ariadne At some point we need to start legislating these things instead of trying to patch over them with technology.

Like, there is zero legitimate reason for fingerprinting to uniquely identify individual users at scale. It should simply be illegal. This does not preclude stuff like identifying bots. Ad stuff should just use cookies where allowed.

@lina @whitequark agreed, but also why do websites need to know i have a fucking threadripper
@lina @whitequark like that is my point here, i cannot think of any reason why a website needs to know i have 128 threads

@ariadne @lina i ship an FPGA toolchain in the browser. it can* use multithreading. it needs to know how many threads to run to not contend on resources uselessly

* currently not built in that configuration for a variety of reasons that is not specifically tied to the web

Glasgow Interface Explorer

Use Glasgow Interface Explorer from your browser!

@ariadne @lina it's not a reason to expose information useful to, like, 1 site you might maybe use, to every of them, and frankly i am not aware of any material benefit from running more than 4 of p&r threads in parallel so it could probably be capped to that. but i think this is a legitimate reason
@whitequark @ariadne @lina a problem is we use the web browser for two totally separate purposes: as a way of looking at transient text/image/video content; and as the only surviving application platform. we want two totally opposite things out of these two different platforms ("control the computer" vs "touch nothing"), but insist on not delineating the two website metacategories. and microsoft/apple/android are only gonna keep making it harder to offload applications back onto "computers"
@mcc @whitequark @ariadne @lina I want to know if anybody is working on separating the web into those two things. It can only make things better for everyone. We can get hypertext documents that load fast and look better than ever, and network-sourced applications with runtimes that are performant on a potato.
@sabrina @mcc @whitequark @ariadne @lina I mean for all intents and purposes #geminiprotocol is a great attempt at having a "markdown only web". We can debate how much regular folks actually want two webs, one for documents and one for runtimes
@iyashikei_kris @mcc @whitequark @ariadne @lina I think the problem with Gemini isn’t that nobody wants two webs, but that most people don’t want a second web that is only a minimalist plain text web. I think a hyperdoc web should still have all the styling features anybody could want. It can shed (most of) the scripting and the features in CSS that only exist for apps.

@sabrina @iyashikei_kris @mcc @whitequark @ariadne I think CSS is getting there but although it can do most things people would want these days, some things would have to be upgraded from "horrible hack" to first class support. Like this stuff:

https://www.codegenes.net/blog/show-hide-div-on-click-with-css/

Basic toggleable UI elements should not require hacks like fake check boxes.

How to Show/Hide Div on Click with CSS Only (No JavaScript Needed for Accessibility)

In web development, showing or hiding content dynamically is a common requirement—think collapsible menus, accordions, tabs, or toggleable sections. While JavaScript is often the go-to solution for interactivity, there are scenarios where a CSS-only approach is preferable: it’s lightweight, avoids JS dependencies, and works even in environments where JavaScript is disabled. But here’s the catch: many CSS-only "toggle" solutions sacrifice accessibility, leaving keyboard users or screen reader users unable to interact with the content. The goal of this guide is to teach you **how to create accessible, CSS-only div toggles** that work for everyone, without a single line of JavaScript.

codegenes
@lina @sabrina @iyashikei_kris @mcc @whitequark @ariadne apologies for piling into a thread, but: I don't know how the author wrote this post and didn't include a reference to the summary element, which is standardized and accessible and has been around for years at this point: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/summary
<summary>: The Disclosure Summary element - HTML | MDN

The <summary> HTML element specifies a summary, caption, or legend for a <details> element's disclosure box. Clicking the <summary> element toggles the state of the parent <details> element open and closed.

MDN Web Docs

@saikou @sabrina @iyashikei_kris @mcc @whitequark @ariadne

I think the problem with that one is the mandatory parent/child/sibling relationship... and it also doesn't work for the mutually exclusive case.

There's also a use case for "deselect on focus loss" which that doesn't do...