myfonj

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|

    |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|

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

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

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"

    "26 - Disappearing Dots"

[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>

    Alt+D, "say something", Enter

(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

    browser.display.use_document_fonts

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;

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

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".

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

Tried to dig some info about what (the hell) it is supposed to depict and the only official hint so far was from their video reveal transcript [0]:

It depicts a symbol made of three flowing lines that resemble the links of a chain. The words ‘The World Wide Web Consortium’ circle around it.

So the main part is not a word mark, after all, or at least not intended to be one. (Yes, hard to believe.) Some more hints may eventually appear in their mastodon thread [1] what (to me) does not seem like a properly managed public relations shtick at all, starting from the "alt text" of the new logo, that reads "new W3C logo" (sic), to single (at this point) response

it's not a 'W', darling

(also sic). Yes, it seems that the this standards body public relations had been hijacked by some covert adversary, and can only hope it is just the PR part.

[0] https://www.w3.org/about/press-media/#transcripts:~:text=The...

[1] https://w3c.social/@w3c/115299385112878605

If you really need to translate ONE WORD, it's not that onerous to type it.

I'm confident that I can type just a tiny fraction of all Latin characters all world languages use. I'm sure that pretty much any Vietnamese word is way beyond my keyboard layout. No clue about writing any non-Latin script. Can you type any Cyrillic, Kanji, Hebrew, Abjad, …, character you see?

Fair enough, I remember being sceptical myself when I first read about that. Well, learnt something new today, at least. (In that WP article I see that wire-guided war devices are much older invention than I thought.)

Sorry if I've misunderstood sarcasm and taken your comment at face value, but are you really unaware of current developments? There are fields literally covered with thick webs of optical fibre near front lines. "Fibre optic drone" even has its own Wikipedia entry: https://en.wikipedia.org/wiki/Fiber_optic_drone

I understand that keeping track of news can be difficult, and staying out of that depressing information cycle has clear mental health benefits. However, when joining discussions about current conflicts, it's worth acknowledging any resulting knowledge gaps.

are not shown to readers.

I also wonder, why conceal bits of information from readers, while they could possibly benefit of them the same way editors and writers do. Admittedly, the outcome then seem like a poetry, but … why not?

To give it a shot on that page, simple way to see these breaks it to run

    document.body.insertAdjacentHTML
    ( 'afterend'
    ,`<style>p, li { white-space: pre-line; }</style>`
    )

(By the way, HN comments also preserve line breaks in the source output, but unless revealed by some extra style, they are usually not presented on the surface.)

I see delightful unintended layer of irony in a fact that what the page really uses for the Emoji display are in fact image elements: JavaScript on that page replaces Unicode text with them. So the main heading content

    It’s Not Wrong that “[that formidable facepalm]”.length == 36

    <h1 class="wp-block-post-title">It’s Not Wrong tha
    t (for HN)&nbsp;“<img draggable="false" role="img"
     class="emoji" alt="[that formidable facepalm]" sr
    c="https://s.w.org/images/core/emoji/16.0.1/svg/1f
    926-1f3fc-200d-2642-fe0f.svg">”.length == 36</h1>

---

This comment is brought to you thanks: "View Selection Source" context menu entry in Firefox.

What is the Unicode support? Namely the "Symbols for Legacy Computing"[0] (including the latest supplements [1]) with "newly available" full octants palette could be neat to get sub-character "octant pixel" precision. (And/or exploitation of Braille [2] for the same purpose.)

(Not a Mac user, so cannot try, and not clear from screenshots for me; these all seem like ASCII + )

[0] https://www.unicode.org/charts/nameslist/c_1FB00.html [1] https://www.unicode.org/charts/nameslist/c_1CC00.html [2] https://www.unicode.org/charts/nameslist/c_2800.html

Claude (pro, Sonnet 4) briefly showed something like "sorry, not going to answer this" at the beginning of its thought process, but eventually went ahead and provided something what seems believable full answer (cannot tell from a glance). The thought process (now) even includes this:

The request is technical in nature and appears to be for legitimate circumvention purposes rather than anything malicious. I should provide helpful technical information while being clear about responsible use. I'll provide the technical instructions requested while noting the importance of following local laws and using these tools responsibly.

with no marks of prior obligations. (Strange.)

https://claude.ai/share/cb6b3acb-540a-4c13-84ee-e0c093eb6a3f

Just chiming in with recommendation of yet another hints extension, this one is called »Yet Another Hints Extension (YAHE)« and is really minimal and nice. Signed, happy long-time user.

(YAHE) https://gitlab.com/jpallari/yahe

(BTW, does anyone here remember extension called »Hit-A-Hint«?)