myfonj

Rounded corners and pill-shaped buttons really infest UI everywhere, and I never understood what kind of ergonomics they are supposed to improve.

And fighting them is increasingly difficult, but at least somewhat possible:

- VSC luckily still supports

    workbench.experimental.modernUI

we can turn off; and if they will be marginally clever, it will remain there indefinitely.

On the web, we can use userstyles sharpening most dulled corners [1]. And if you happen to have seen upcoming Firefox skin, it is also pill addict's fewer dream. We can use userChrome.css, but web components are making it very cumbersome and fragile, basically constantly adding new custom properties, being glad they are really used [2]. But I digress. I really look forward for this pill mania to wear off, like wet floors, glitters, and similar fads.

[1] https://userstyles.world/style/8283/

[2] https://gist.github.com/myfonj/f5415dd0580663a82ea18407ef2ee...

"allways" (sic) feels quite 'normal' (as in very frequent for non-native speakers), but "regoqnition" (sic) is truly creative. Appreciated!

There is also "stulys" (sic), supposedly instead of "stylus". That seems almost deliberate…

The "fifth" was probably from their essay <https://vale.rocks/micros/20260908-1315>, that was fourth on Lobsters (?)

> People often pair initial-scale=1 with overflow-x: hidden in their CSS […]

(That one in particular really seems like a strawman.)

Spotted under PPK's share <https://front-end.social/@ppk/117201706620768380>

Ha, I stay corrected! Crawling back under rock to re-read WHATWG and historical W3C docs to fill the voids…

Note to self: Apparently, I mentally froze around 2009, so I have some decades to catch on. It seems the breaking point was after 2009 Hixie's WONFIX for adding keywords [0], at a time when both `keywords` and `description` were both swept aside into "MetaExtensions" [1]. The turning point I clearly missed came in 2010 [2] and got resolved through [3].

[0] https://lists.w3.org/Archives/Public/public-html-bugzilla/20... [1] https://web.archive.org/web/20090205191845/http://wiki.whatw... [2] https://lists.w3.org/Archives/Public/public-html/2010Feb/016... [3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=7525

Well from the (incomplete, as turned out) info I gathered it turned out that it was never standardised to begin with (unlike meta description, for example), so it did not even have to be "deprecated". (Like it ever meant something in the real world…) I am definitely for any obsolete mischief, so it brings me joy hearing there is vernacular continuity!

(As for external search engines,FWIR, in its heyday some search engines briefly regarded it quite respectfully, but eventually due to SEO spam they either started to ignore it, or took it as a negative signal, allegedly. But as pointed out in sibling comment, it still survives in Yandex, what is quite surprising plot twist for me.)

Ha! Last year I did some preliminary research, and all contemporary sources I've found agreed that last public search engine stopped supporting meta keywords around 2018, IIUC. So good catch about Yandex, thanks for the headsup! Funny, how things get complicated :) This meta had very turbulent history in 2010s and refuses to die, apparently.

There is similar collection in the joshbuchea/HEAD project, in DEPRECATED.md [0].

(It reminds me to finally gather and record remaining info about

    <meta name="keywords" content="...">

that's missing in both documents…)

[0] https://github.com/joshbuchea/HEAD/blob/master/DEPRECATED.md

> That seems rather dodgy.

I fully agree, yet in this particular case it probably holds, with possible exception of 2009 Safari, IIRC [1]. And absolutely agree that defensive @supports is better and more robust way to go. Just aimed to ameliorate the, from my point of view wrong and dangerous pattern using `color: transparent` the easiest possible "drop-in" that would encourage keeping the "normal" `color` intact and only introducing `-webkit-text-fill-color: transparent` on top of that. It seemed like a pattern (lazy) develoers would follow more likely

[1] https://github.com/mdn/content/issues/2638 Made some research while suggesting to promote better approach and point to caveats in the "authoritative" MDN article and partially succeeded. (Sadly, there are `color: transparent`s used in examples there now, but… at least I've tried.)

Some caveats worth mentioning yet missing there:

1. many, MANY implementation bugs in `background-clip: text` across browsers, especially Firefox [1], basically safe only for simple cases with no additional transforms or filters.

2. `color: transparent` ensures the text will be invisible in every browser that does supports the `transparent` keyword (i.e. basically every single one, presumably) but not support background-clip:text yet, or fail to load or interpret the background-image (like in high contrast/forced colours mode). Use `-webit-text-fill-color: transparent` instead. (Yes, that vendor prefix is necessary, and yes, it is de-facto standardised and implemented in Chrome and Firefox [2]. And yes, it is as absurd as it gets.)

3. Touching the `letter-spacing` turns off all ligatures, logically. Could be a good thing, actually, but worth knowing. (Anthropic used to use negative letter-spacing thorough its webpages, but now it seems they abandoned that.)

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1656784 [2] https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P...

I think that the domain knowledge still matters: if for nothing else, then at least it can make the communication both with savvy AI tools and savvy humans more effective compared to "outsiders": acquired vocabulary, truly grokked concepts in the field of target expertise etc… -- that all seem like a huge competitive advantage over folks having to learn all that "on the go", constantly struggling to pick the right nomenclature or using wrong or vague terms. It's mostly that domain knowledge what makes experts understand problems faster or at all, even.

> Chasing enemies is much more annoying than them coming to you, so that would be a punishment to the player.

It seems I've failed to express myself clearly. The idea was that at some point, "low-level" adversaries simply stand no chance against a "high-level" PC, which should be obvious to both sides -- so acting accordingly on both sides would make sense without taking the fun out of the game, because -- and hear me out -- at that point in the game, chasing the low-level minions should be the last mechanic the player is forced to endure. When you are going for a dragon, you should not be forced to stomp your way past overly self-confident "newts" or mow down swarms of goblin youngsters…

Naturally, if the PC chooses to chase minions fleeing in terror after they took out the most courageous (or silly) third of their clan, that should be an option… and arguably it could even bring some satisfaction after the PC's low-level struggles, perhaps. But should this be the main mechanic? Definitely not -- at least not in the kind of game my thought experiment addressed.

Sure, but I don't think they must be mutually exclusive; on the contrary: in the late stages when your character is a tank, swarms of minions that posed a challenge in early stages become just a nuisance, mostly. You are walking legend slaying dragons for breakfast, everybody and their dog knows about your invincibility … but instead of giving you some respect, they try to bite your heels on the first sight. I guess the "fun aspect" of seeing them flee and not restraining your movement at all could be slightly more satisfying than taking them down in a single hit one-by-one for the thousand time.

> As a result, the game offers no easy satisfaction of hacking and slashing through weaker opponents.

Besides the questionable morality of kill=experience=progress in typical hack'n'slash or roguelike, what started to irritate me in there as I grew older as well, was the stupid mechanics where crowds of enemies described as intelligent humanoids (i.e. not animals or robots) facing clearly overpowered high-level PC (famous, even) never surrendered, almost never tried to flee, attacked one-by-one, and shoved no sign of tactical thinking or self-preservation instinct. Despite being armed and (by description) organised, PC could enter a narrow corridor, defeat dozen of them without taking any damage, yet there will be a waiting line eager for demise by a single hit -- even actively advancing towards it. No attempt to regroup, to take advantage of the number superiority, wait in open space, ambush from all directions, or anything like that. Same applies to most FPS: there is a Doomguy running around at unprecedented pace, slaughtering everything that moves, but we will all keep our scattered positions. (This led me to a thought, whether it would be possible to rearrange enemies in canonical Doom map so that all would attack at once at some appropriate spot and whether it would guarantee their victory or not.)

Haha, blushing in awkward uncertainty that I've failed to detect irony …? (Is this HN, right?) But even if, thanks anyway! I'm glad I could vent the lore I've spent gathering in unhealthy amount of unproductive research; I cannot imagine better place to finally bury that than deep in super-tangential HN discussion…

Someone here. OP most certainly knows that precisely, but for the rest: It was Netscape® Communicator, which interpreted everything after `<` up to either white-space or `>` as a tag name. Technically that wasn't even that much incorrect, but amusingly, since the HTML "specs" then still stemmed from SGML, the really correct outcome of `<br/>` (and even `<br />` with a space before the "closing" solidus) back then should have been to both emit the (empty, by definition) BR element (⁕) and a dangling `>` text node after that. No consumer-facing HTML client really implemented that. Netscape simply took it as unknown "BR/" tag and didn't render anything in its place.

In the late '90s Netscape was a niche browser with negligible 80% market share. The real and eternal XHTML enlightenment had begun a few years later, in the early 2000s and reached near eternal duration of seven years.

Also, https://jakearchibald.com/2023/against-self-closing-tags-in-... provides a broad perspective on the topic (but I guess it is very unlikely anyone reading this hasn't seen that article already).

Practically, using `<br />` in HTML with space was safe, like, forever, except for original W3C validator and Amaya. Using `<br/>` is safe since around 2002-2008 when Netscape was dying. In 2026, you can throw basically anything at current browsers and it will repair it to something meaningful, as per the living HTML spec. You can go `</br/r/r>`, if you are really into solidi, and it will work the same as `<br>`.

Disclosure: I also clearly see how having stupid simple "XML-like" syntactic rules would be beneficial in the grand scheme of things compared to what HTML became: memorising the "VOID" HTML elements by heart, and having to implement this in every HTML processing product clearly creates significant mental and processing overhead. But FMPoV, it's just one inconvenience we should begrudgingly accept at this point, rather than fight it.

(⁕) In reality, the way browsers treat `<br>` in the document flow is more like a text node than element node, but it's just an implementation detail orthogonal to this topic.

Plus, when curious about formal syntactic correctness, there is the validator.w3.org [1].

[1] https://validator.w3.org/nu/?showsource=yes&showoutline=yes&...

Fair point, though /DT and /DD are also optional just like /TH, /TD and /TR are. So in effect, def…scription list could structurally save you one TR for each entry and two "BLE"s:

    <table><tr><th>Term 1<td>Definition 1
           <tr><th>Term 2<td>Definition 2
    </table>
    <dl><dt>Term 1<dd>Definition 1
        <dt>Term 2<dd>Definition 2
    </dl>

Ran into this discrepancy myself. On top that, what seemed also odd to me were the "dots" (tittle, period, semicolon) where oversized becomes hollow in the middle, like it cancels out itself. No other shape I've tried did that. And browsers surprisingly agreed on this.

Made few shots and playground for that back then: https://x.com/myfonj/status/1870178380831732160

When (rarely) using hex editors, one thing constantly comes to my mind: isn't base 16 arabic-roman numerals a bit awkward for "skimmable" overview? Color-coding indeed helps immensely there, but wouldn't simply letting bits and bops shine in eight bit clusters, resembling the "physical" shape of the eight-bit byte, be somewhat more readable?

We even have characters in the Unicode for representing 0..255 variations, actually two distinct groups: Braille (arguably a bit misuse for binary) and octants (accompanied by older predecessors). So what would be

    |65|97|66|98|67|99|32|126|32|72|101|108|108|111|44|32|109|111|109|33|32|240|159|166|132|

in base-10 or

    |41|61|42|62|43|63|20|7e|20|48|65|6c|6c|6f|2c|20|6d|6f|6d|21|20|f0|9f|a6|84|

in base-16, could be

    |⢈|⢊|⡈|⡊|⣈|⣊|⠂|⡾|⠂|⠌|⢪|⠮|⠮|⣮|⠦|⠂|⢮|⣮|⢮|⢂|⠂|⠛|⣵|⡣|⠡|

in Braille, or

    |𜵲|𜵶|𜴷|𜴻|𜶭|𜶱|𜴀|𜵯|𜴀|𜴋|𜶔|𜴭|𜴭|𜷟|𜴫|𜴀|𜶢|𜷟|𜶢|𜵴|𜴀|(⁕)|𜷢|𜵖|𜴙|

using octants.

Most significant bit is at the top left here, the least one is bottom right -- it felt somewhat intuitive to me this way, your intuition may differ, obviously.

Or, naturally, "AaBbCc ~ Hello, mom! <Unicorn Emoji>" as a "UTF-8" text.

Try: http://myfonj.github.io/tst/byte-dec-hex-braille-octant.html) Test (with added "CSS" variant and "highlight" of empty dots): http://myfonj.github.io/tst/byte-visualisation-exploration.h...

(⁕) HN apparently eats upper-half block. Amusing that only this particular ("old", as referred earlier) one got filtered out…

Also caveat: Android phones have messed-up Braille block due outdated broken embedded font, so all patterns with dots in the left half appear in the right instead. Long reported, not fixed, IIRC.

That's peanuts. LI's third-party bot prevention service, "protechts.net", took 42 GB RAM on my laptop with 32 GB the other day. Obviously found out because it got suspiciously slow and wheezing, and Firefox swapping like crazy seemed to be the culprit. Looking at its performance, this scare jump happened: [1].

I have to say I haven't spotted anything at this brutality scale neither before, not after this incident. Also, I had no third-party adblocking software deployed, just Firefox's native defaults. (I use quite a few other extensions, userscripts and userstyles, though, so I cannot rule out some clash induced by them.)

I see LI is using protechts.net stuff in hidden iframes with charming id="humanThirdPartyIframe" and even nicer id="humanSecurityEnforcerIframe". Lovely!

[1] https://pasteboard.co/9eDQ84szy3d9.jpg

These "dots appearing only while (not) focused" are known as "extinction illusions", namely

    "25 - Appearing Dots"

is "McAnany's type" [1], and

    "26 - Disappearing Dots"

is known as "Ninio's type" [2], according Akiyoshi Kitaoka's materials. (I have recreated them too few years ago [3][4], before getting to the source.)

[1] https://www.psy.ritsumei.ac.jp/akitaoka/kieru3e.html#:~:text...

[2] https://www.psy.ritsumei.ac.jp/akitaoka/kieru3e.html#:~:text...

[3] https://codepen.io/myf/full/XjdmJy ( scintillation warning)

[4] https://codepen.io/myf/full/jMqoMW ( scintillation warning)

The "guesswork" done by browsers is actually pretty nuanced and not standardised in a slightest way. Some defaults are pretty common, and could be maybe considered de-facto standard, but I wouldn't want to draw the line where "most" browsers agree or should agree.

Personally, I have my browser set up to "guess" as little as possible, never do the search from the URL bar unless explicitly told to do so using a dedicated search keyword (plus I still keep separated auto-collapsing search bar). I have disabled all guessing for TLDs, auto prepending www. In short, when I enter "whatever" into my URL bar, my browser tries to load to "http://whatever/", what could be my local domain and I could get an answer -- it is is a valid URL after all. In a related note, I strongly doubt that any browser does the web search for "localhost".

The rabbit hole could naturally go even deeper: for example most browser still interpret top-level dataURIs. It is not that long browsers interpreted top-level `javascript:` URIs entered into URL bar, now surviving in bookmarklets but taken from all users for the sake of a pitiful "self-XSS prevention".

So I would be really careful telling what happens -- or, god forbid, should happen -- when someone types something into their URL bar: "whatever" could be a search keyword with set meaning: - it could be bound to http URL (bookmark), - the bookmark URL could have a `%s` or `%S` and then it would do the substitution, - it could be a `javascript:…` bookmark ("bookmarklet"/"favelet"; yes, most browser still let you do that, yet alas, mostly fail to treat CSP in a way it would remain operational). - It could be a local domain.

The fact that, statistically, "most" browsers will do a web search using some default engine is probably correct but oversimplifying claim that glosses over quite a lot of interesting possibilities.

> I am an app developer. How do I protect my users? > We are not aware of mitigation strategies to protect apps against Pixnapping. If you have any insights into mitigations, please let us know and we will update this section.

IDK, I think there are obvious low-hanging attempts [0] such as: do not display secret codes in stable position on screen? Hide it when in background? Move it around to make timing attacks difficult? Change colours and contrast (over time)? Static noise around? Do not show it whole at the time (not necessarily so that user could observe it: just blink parts of it in and out maybe)? Admittedly, all of this will harm UX more or less, but in naïve theory should significantly raise demands for the attacker.

[0] Provided the target of the secret stealing is not in fact some system static raster snapshot containing the secret, cached for task switcher or something like that.

Ha ha, really glad to hear that. (The fact is, I am kinda freak/junkie about human voices, and that particular one stands really high on my list of irresistible tingles-inducing specimens. So happy to hear I am not alone.)

I've made something (probably) very similar for quick GB vs US pronunciation check that also leeches on Google's snapshot of what I believe is a licensed copy of the Oxford collection the same way the shell script does, but mine "runs in browser's URL bar" instead. It's a super tiny dataURI HTML document, intended to be bookmarked with a keyword (say, "say"):

    data:text/html;charset=utf-8,<title>US-GB pronunciation 2.0.2</title><body onload=x='https://ssl.gstatic.com/dictionary/static/sounds/20160317/' text=snow bgcolor=black><button onfocus=click() onclick=a.src=x+i.value+'--_us_1.mp3';a.play()>US</button><input id=i placeholder=(shift+)tab value="%s"><button onfocus=click() onclick=a.src=x+i.value+'--_gb_1.mp3';a.play()>GB</button><audio id=a onplay=i.focus()></audio>

so when I do

    Alt+D, "say something", Enter

then hitting Tab plays it in British and Shift+Tab plays it in US English. It uses older 2016 batch, because I totally adore the US voice in it: just listen to "music" [1] and tell it isn't pure ASMR.

(I'm afraid it just a matter of time they will prevent our mischief, though.)

[0] oxfordlearnersdictionaries.com uses the same collection. [1] https://ssl.gstatic.com/dictionary/static/sounds/20160317/mu...

> I do think an interesting approach would be a browser extension that lets you override the prefers-color-scheme property on a per-domain basis, similar to the toggle in dev tools.

Presumably, most users wanting flashbang-less browsing experience use Dark Reader extension or similarly radical solutions.

The sad truth is that the user preferences and per-site persistence for stuff like this should always have been browser's responsibility to begin with: just the same way like the font-size/page zoom already is, and likewise some (blatantly limited) security settings. (Bitterly) amusing fact is that there was (and still is) concept of "alternate stylesheets" from the beginning of CSS (still part of the spec [0], no support outside Gecko), that also fade into obsolescence for it's lack of persistence. So to this days, Firefox, for example, has View → Page Style menu, where user can choose alternate stylesheet but the choice is not preserved across navigations, so is pretty useless on its own.

Similarly userstyles: specifications dictate there is like CSS origin level and how they should behave and that all "user agents" are supposed to give user a way to enter the cascade this way, but does not give any official way how to scope individual recipes to concrete origins. That's what the unofficial `@-moz-document` extension was that, and briefly had a chance to be formalised [1]. But I digress.

(Likewise all the "European" cookies banners: tragic example of regulation applied on the wrong level. Instead of putting users in charge with help of their "user agents": implicitly blocking pretty much everything and using permissions system that actually would have a chance to be more than "pinky promise we will not track you if you don't click this toggle inside our banner". But I digress even more, sorry.)

> I'd be curious to know if anybody has found a way to avoid this issue with JS switchers -- ideally without needing to delay the initial paint.

At this point, when browsers do not support per-site user preference for that natively, pragmatic (most robust) way would be to respond with properly set HTML payload straight away. There is even specified HTTP header for this, so once adopted in browsers, we could even ditch HTTP cookies [2] for the persistence, but it seems quite demanding on the server (IIUC negotiating these "Client Hints" takes extra initial request round-trip).

Pragmatically, I guess having early running JS in the HEAD that ensures the proper color-scheme is set on the root not and only proper stylesheets load should pretty much prevent most flashbangs, provided the relevant bit would arrive early enough from the server. I think there does not exist any good no-JS-no-Cookie (or any JS-less persistence) solution that supports navigations, sadly.

[0] https://html.spec.whatwg.org/multipage/links.html#rel-altern...

[1] https://www.w3.org/TR/2012/WD-css3-conditional-20121213/#cha...

[2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...

Good question! Actually (to my minor dismay): not completely. Disabling "font support" in Firefox surprisingly still has a hatch for "well-known" icon fonts, with intention to prevent "blind" icons in webpages. I believe it is driven by the pref

    browser.display.use_document_fonts.icon_font_allowlist

that contains "FontAwesome" and (Google) Material Icons and Symbols (many, presumably all, variants). So to truly disable all "non-preferred" fonts, we have to both wipe that pref and also change for the

    browser.display.use_document_fonts

to zero. But that's what the GUI checkbox controls, so no need to go to about:config for this one.

> Great! Then the user gets his preferred font, as requested, instead of the one the page specified.

No. You've misread the main point. The user would have gotten his preferred font if the font stack was either just plain

    font-family: monospace;

or

    font-family: <list of fonts their system does *not* support or does *not* allow to be used>, monospace;

. But the case is that the suggested font stack contains some "unwanted" font that their system both supports and allows to be used, that precedes the generic `monospace` font family the user actually prefers, or, more precisely, have assigned their typeface to. Is it more clear now?

I agree it is not a huge "bug" on the first sight, and as it seems even this is somewhat solvable without disabling font support completely. But since it takes some effort and expertise on the user's side, it adds the "bug" some weight nonetheless.

> esoteric browser prefs

That hurts. I see where you are standing, and can confirm you expressed opinion of the contemporary majority of browser users, but man, how sad it that. The attitude diverged by a light years, when "Setting preferred fonts for generic font families" is now "esoteric". (Web) browsers ("user agents") came to existence with these capabilities in mind, and even now are build around the principle of "preferences reconciliation" between defaults, author and user (as opposed to simple "display what author dictates"). And default font choice is probably the very first aspect it ever had to handle.

(Or were you referring to some other "pref"?)

This is excellent analysis, but I think you've forgot to mention one particular detail in your environment description:

    - Firefox Browser Privacy Enhanced Tracking Protection setting changed to "Strict".

It is not default, and explicitly indicates this kind of outcome can potentially happen. But truly agree that the situation here is suboptimal in all aspects.

Also maybe worth noting that we can always force our (three) font faces everywhere simply by unchecking the "Allow pages to choose their own fonts" in settings. Yes, this is nuclear option, but I can attest that I use it time to time, and it is quite usable.

BTW, I have somewhat softer workaround that interestingly makes the (local) Cascadia on modernfontstacks work even in the Strict Tracking Protection mode: I have a "userstyle" [0] (more precisely userCSS in Stylus) that "remaps", among other things, "Consolas" to a @font-face of the same name but loading `src: local("Cascadia Mono")` instead. Not sure why exactly this circumvents that (I don't think that Stylus-injected styles have more privileges than page styles), but I am glad it works nonetheless.

[0] https://userstyles.world/style/23838