myfonj

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

in devtools console. (Using `pre-wrap` instead of `pre-line` is also interesting: indents "wrapped" lines by the source code indent, what gives it even more clarity.

(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

(sic syntactically wrong quotes) is in reality (for JS-capable and enabled clients) presented as

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

(arbitrary line breaks added for convenience). Here the "true" `.length` of the (scare)quoted content is: 144.

---

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«?)

That's strange; the `head` and `footer` nodes were present in the XSL template this morning [1], last GH change was Feb 13 [2], what matches

    curl --head --silent --url https://xsl-website.widloski.com/template.xsl | grep modified
    last-modified: Thu, 13 Feb 2025 07:11:02 GMT

from here.

[1] at 09:11:48, according https://web.archive.org/web/*/http://xsl-website.widloski.co... [2] https://github.com/Evidlo/xsl-website/commits/master/templat...

I wish external entities were enabled in browsers (*), and not entirely disabled, like they are now.

In the OP scenario, it would provide possibility to have header/footer/stylesheet content in separate files and get system working that does not rely on absolute path of the CSS.

(*) Naturally, just with few minimal directory traversal precautions; basically anything like "no ../" and even restriction like "referenced resource filename must begin with referencing XSL filename" would be fine for me.

Haven't read the book yet, but isn't that more like a matter of the font/rendering engine? I have a murky notion that for Cyrillic, for example, there are some nuances in rendering certain glyphs in cursive between languages [1], but these nuances are usually resolved by cooperation of the font and client interpreting the language hints, so not in the "physical" text.

(Not telling I see this as a good thing or anything: it is way beyond my expertise; I definitely can see the motivation for introducing as many variants in the Unicode register as there are in the real world)

Isn't the umlaut vs trema/diaeresis in a similar situation?

[1] made me test it and cobble a demo. (Sadly, not speaking any of these languages, so cannot verify it is correct; just wanted to see the difference in practice):

    data:text/html;charset=utf-8;verbatim,<style>
    @import url("https://fonts.googleapis.com/css2?family=Noto+Sans:ital@0;1");
    body { font-family: 'Noto Sans'; }
    dl:hover i { font-style: normal; }
    </style>
    <dl>
    <dt>lang="ru"
    <dd lang="ru"><i>грипп, практика, график, типа</i>
    <dt>lang="sr"
    <dd lang="sr"><i>грипп, практика, график, типа</i>
    </dl>

Arguably, depending on wide (physical text ↔ specific font ↔ rendering agent) ecosystem feels quite fragile, but cannot tell if there is any better alternative for this particular case.

https://myfonj.github.io/sandbox.html#%3C!doctype%20html%3E%...

True. And interestingly, the term "emoticon" was used both for the basic "ASCII" and fancy graphical representation. And while some "ASCII" sequences were present on multiple platforms, the meaning quite unsurprisingly often diverged, just like you implied. See some:

        [MSN emoticons]  vs [Yahoo emoticons]
    :-* "Secret telling" vs "kiss"
    8-| "Nerd"           vs "rolling eyes"
    :|  "Disappointed"   vs "straight face"

[MSN emoticons] https://web.archive.org/web/20031206095746/http://messenger....

[Yahoo emoticons] https://web.archive.org/web/20080408053458/http://messenger....

N.B. some of them are animated. Animated fonts coming when?

Other anecdotal experiences with Google and their specific attitude towards user/developer needs:

- Stable Array.sort (2008 – 2018): Of course it doesn't have to be stable, spec does not dictate it right now, it is good for performance, and some other browser even started to do this like we do: http://crbug.com/v8/90 . - Users don't userstyle (2015– ) Of course we absolutely can an will remove this feature from the core, despite it is mandated by several specifications: https://bugs.chromium.org/p/chromium/issues/detail?id=347016 . - SMIL murder attempt was addressed in the OP article (I think they keep similar sentiment towards MathML either) but luckily was eventually retracted. I guess/hope this XSLT will have similar "storm in the teacup" trajectory.

Coincidentally spotted this source code in some Microsoft Windows Server® 2022 Remote Desktop Web Access thingy yesterday:

    <?xml version="1.0" encoding="UTF-8"?>
    <?xml-stylesheet type="text/xsl" href="../Site.xsl"?>
    <?xml-stylesheet type="text/css" href="../RenderFail.css"?>

    <RDWAPage 
        helpurl="http://go.microsoft.com/fwlink/?LinkId=141038" 
        (…)

So I doubt XSLT is going away any time soon.

In my perspective, for truly "self-contained", "portable" and "self-updating" and even "un-hosted" web apps, the only option nowadays are prehistoric data-URIs, that are slowly losing abilities anyway (basically can live only as bookmarks or direct URL pastes, and their only persistence option is location #hash that needs re-bookmarking):

    data:text/html;charset=utf-8,<body id=b onload=b.innerHTML=decodeURIComponent((l=location).hash.slice(1)) onkeyup=document.title=b.innerText.split('\n')[0]||'.' onblur=try{history.pushState({},document.title,'\u0023'+b.innerHTML)}catch(e){l.hash=b.innerHTML} contenteditable bgcolor=darkslategray text=snow link=aqua vlink=lime style=text-align:center>#Hello, HN!<br><br>Do you like this %E2%9D%9Dun-hosted%E2%9D%9E&nbsp;app?<br>With persistence<a href="https://news.ycombinator.com/reply?id=44944112">%E2%80%A6?</a>

Well we should first establish some sort of contract how to convey the "I feel that I actually understand this particular piece of information, so when confronted with it in the future, you can mark is as such". My lines of thought were more about a tutorial page that would present the same techniques as course you have finished a week prior, or news page reporting on an event you just read about on a different news site a minute before … stuff like this … so you wold potentially save the time skimming/reading/understanding only to realise there was no added value for you in that particular moment. Or while scrolling through a comment section, hide comment parts repeating the same remark, or joke.

Or (and this is actually doable absolutely without any "AI" at all):

    What the bloody hell actually newly appeared on this particular URL since my last visit?

(There is one page nearby that would be quite unusable for me, had I not a crude userscript aid for this particular purpose. But I can imagine having a digest about "What's new here?" / "Noteworthy responses?" would be way better.)

For the "I need to cite this source", naturally, you would want the "verbatim" view without any amendments anyway. Also probably before sharing / directing someone to the resource, looking at the "true form" would be still pretty necessary.

Not any more "sentient" than existing LLMs even in the limited chat context span are already.

Naturally, »nothing new of interest for you« here is indeed just a proxy for »does not involve any significant concept that you haven't previously expressed knowledge about« (or how to put it), what seems pretty doable, provided that contract of "expressing knowledge about something" had been made beforehand.

Let's say that all pages you have ever bookmarked you have really grokked (yes, a stretch, no "read it later" here) - then your personal model would be able to (again, figuratively) "make qualified guess" about your knowledge. Or some kind of tag that you could add to any browsing history entry, or fragment, indicating "I understand this". Or set the agent up to quiz you when leaving a page (that would be brutal). Or … I think you got the gist now.

Each user have distinct needs, and has a distinct prior knowledge about the topic, so even the "raw" super clean source form will probably be eventually adjusted differently for most users.

But yes, having some global shared redundant P2P cache (of the "raw" data), like IPFS (?) could possibly help and save some processing power and help with availability and data preservation.

Interestingly, the original idea of what we call a "browser" nowadays – the "user agent" – was built on the premise that each user has specific needs and preferences. The user agent was designed to act on their behalf, negotiating data transfers and resolving conflicts between content author and user (content consumer) preferences according to "strengths" and various reconciliation mechanisms.

(The fact that browsers nowadays are usually expected to represent something "pixel-perfect" to everyone with similar devices is utterly against the original intention.)

Yet the original idea was (due to the state of technical possibilities) primarily about design and interactivity. The fact that we now have tools to extend this concept to core language and content processing is… huge.

It seems we're approaching the moment when our individual personal agent, when asked about a new page, will tell us:

    Well, there's nothing new of interest for you, frankly:
    All information presented there was present on pages visited recently.
    -- or --
    You've already learned everything mentioned there. (*)
    Here's a brief summary: …
    (Do you want to dig deeper, see the content verbatim, or anything else?)

Because its "browsing history" will also contain a notion of what we "know" from chats or what we had previously marked as "known".

> what is back and forwards?

Sorry, I didn't realise that was unclear. By "back" and "forwards", I mean movement through the flow of text relative to the cursor position. Given any reference point in linear text, all surrounding content either precedes or follows that point. Moving through preceding content is "going back", and moving through following content is "going forwards". When we move to the preceding line (↑) or preceding character (←), we're going "back". When we move to the following line (↓) or following character (→), we're moving "forwards". My point was that ← ↓ ↑ → effectively represents "back one character — forward one line — back one line — forward one character", which feels counter-intuitive to me.

> strongest finger, the index finger.

Interesting. As far as I now, middle finger is usually considered stronger than the index finger. Index finger might be more dextrous, though (?). Personally, I also slightly prefer the middle finger for rapid pressing over the index finger, but cannot see strong definitive advantage of either one. (I guess most of us use the middle finger for regular ↑↓ keys, as well as W/S in WASD bindings in games/project just fine, and using index finger in that context instead would feel odd.)

> what is your neutral finger position?

Mostly index finger on "K". (So I guess I'd prefer having "down" (being the most frequently used when VIM binding is involved) on "L", where my middle finger usually dwells, and "K" for moving up, if I had to invent it from scratch.)

For me personally is the J/K direction still feels swapped and I always have to remind myself they are in fact the other way round. Even (especially) for touch typists, I would really expect [k] to point down and [j] up. In our writing system from the top left to bottom right my intuition would really be to stick ↑ with ← together and vice versa ↓ with →.

    ← ↓ ↑ →

makes a little sense to me.

    ← ↑ ↓ →

would be way better, IMO.

Not only because the most used used direction (↓) would be closer to my "neutral" finger position, but mainly because the the keys for progressing "back" and keys for progressing "forwards would be grouped together.

Honestly, I wouldn't even mind having them spread across two rows, like U I J K

    ↑  ↓
    ←  →

or something. (Personally, I have global WASD-like arrow mapping bound to IJKL through capslock combo in AutoHotkey, since sometimes cursor keys are really inconveniently far away when typing.)

Good idea. I remember I have done some research about this in the past when I tried to trace historical arguments for the infamous "should there be a space before slash in void tags for the best compatibility"

    <br/> vs <br /> (vs <br>)

discussion, but didn't get much far then (https://stackoverflow.com/a/30880386/540955).

Thanks! That's actually really valuable insight and seems to be a promising start for a interesting investigation

I'd even say that from a glance, EMACS ("W3" browser in it) seems like possibly hugely relevant application, actually. Will look into it.

> Historically, […] no relevant browser has ever implemented SGML […] NET

I can probably confirm that "relevant" part of this claim for the times spanning from the first decade of 2000s, but I still desperately (in a way) seek information whether ANY even niche and obscure application that consumed "HTML" treated the NET as specified back then. I am quite certain W3C Validator did (that Mathias' article proves that, after all) and that Amaya might have do that, since it was a reference implementation from the same spec body, IIRC, but cannot swear on that.

Have anybody here have a clearer recollection of that times, or even some evidence?

I still find it strange such feature had such prominent space in the specs back then, but practically nowhere else.

For the recent resources it might matter: unless the training data are curated meticulously, they may be "spoiled" by the output of other LLM, or even the previous version of the one that is being trained. That's something what is generally considered dangerous, because it could potentially produce unintentional echo-chamber or even somewhat "incestuously degenerated" new model.

Good point! Yet interestingly, that page seem to adopt to colour scheme preference just fine at this point. (Even dynamically.) It is fact that the gooey thingamajig keeps same weird colours in both schemes, but besides that, at least the main background and text try to reflect User's preference with regard to luminosity.

Let me share with you my brief but very intensive user story of the "M3 web":

1. User visits https://m3.material.io/develop/web. 2. User suffers unsolicited and redundant gooey animation of an "orange-violet blob-like thingamajig" unrelated to the topic. This happens despite user's clearly communicated "prefers-reduced-motion" setting that other sites usually respect. 3. User struggles to find how to stop said thingamajig. After scrolling, they eventually discover some kind of "pause button" tucked away in the bottom left corner of a sidebar. (User has a laptop, so that icon—with no textual hint of its function—sits below their initial viewport.) 4. User clicks the pause emblem and the visual distraction freezes in place. 5. User attempts to identify the first interactive element in the main area (also known as a "link"). 6. Moving the cursor over a tile under "Announcements" makes the tile change colour. User deduces it might be clickable. There is no other visual indication that this content is functionally different from the "static" texts surrounding it. 7. The tile reads:

    Meet Material Web 1.0Start using lightweight and accessible Material Components in any web framework

This appears to be a heading and subtitle, but in reality consists of two styled <spans> with no space between them (hence the peculiar "1.0Start" fusion). The spans are marked with `class="title"` and `class="description..."` respectively. 8. User boldly clicks that tile. 9. User gets a new browser tab opened. 10. User wonders why there was no visual indication this would happen. 11. User evaluates the content of this unsolicited tab, decorated with "cheering megaphone" emoji. They conclude there is actually no clear path toward "Starting to use lightweight and accessible Material Components" there. 12. User decides to close the tab and return to the original "M3" page. 13. The original "M3" page no longer looks as it did before. It has scrolled back to the frozen orange-violet thingamajig, causing the content with the tile to vanish from the viewport. 14. User decides that they've encountered enough WCAG violations for this month. 15. User closes the tab.

Also don't forget that not all contributions are done through PRs or are actual code changes. There are folks that do tests, make MREs, organise issue reports, participate in forums … they all are also contributing: their time and efforts.

This is quite fair point, yet I'd argue that still most so called web apps could (and should) use basic old-school HTML forms as the underlying technology, and progressively enhance from that baseline, up to the "app-y" look and feel we know and ~~ha~~__love__.

Obviously, there are some limits where application built with bog standard HTML forms becomes too cumbersome or makes no practical sense, as you say, but I think that that threshold is far higher than what current web-app landscape exhibits. I think the threshold is around video editing software, or real-time multi-user collaborative spaces perhaps. But for the rest, following three old steps

    Make it work — just HTML.
    Make it nice — add some CSS.
    Make UX slick —  add JS.

still makes sense to me. In context of the plainvanillaweb.com it would mean just moving the content from non-semantic attributes of custom components to their semantic initial content, such as adapt

    <x-avatar src="https://i.pravatar.cc/150?u=a042581f4e29026024d"></x-avatar>

to get the data from its contents:

    <x-avatar><img src="https://i.pravatar.cc/150?u=a042581f4e29026024d" alt></x-avatar>