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

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

Comments URL: https://news.ycombinator.com/item?id=48427005

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48426598

Points: 6

# Comments: 0

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.

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

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 `
` in HTML with space was safe, like, forever, except for original W3C validator and Amaya. Using `
` 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 `
`, if you are really into solidi, and it will work the same as `
`.

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 `
` in the document flow is more like a text node than element node, but it's just an implementation detail orthogonal to this topic.

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

    
Term 1
Definition 1
           
Term 2
Definition 2
    
    
Term 1
Definition 1
        
Term 2
Definition 2
    

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

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

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

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

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.

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.

    data:text/html;charset=utf-8,USGB

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