2026-09-05 01:19:08 <oak         > hey. are any of y'all working on a catjam entry? https://itch.io/jam/catjam-2026
2026-09-05 07:10:31 <iv4nshm4k0v > Somewhat off-topic, but I've recently revised my retrogaming notes, http://users.am-1.org/~ivan/qinp-2026/247.games.en.xhtml .  Used http://microformats.org/ markup, too, but http://pin13.net/mf2/?url=http://users.am-1.org/~ivan/qinp-2026/247.games.en.xhtml seems to, for whatever reason, put my h-cite bits in all the inappropriate places, like the "name" properties.
2026-09-05 07:12:44 <moku        > xhtml! there's a throwback
2026-09-05 07:13:06 <moku        > anyway, i gotta go
2026-09-05 07:15:55 <iv4nshm4k0v > The Living Standard supports both "traditional" (HTML) and "XML-based" (XHTML) serializations of HTML DOM.  The latter is used with Content-Type: application/html+xml, which is conventionally associated with ".xhtml" file suffix.  The latter isn't reserved to "XHTML" W3C TRs.
2026-09-05 09:37:35 <iv4nshm4k0v > By the by.  Suppose an embedded Forth system has no storage whatsoever for source code.  One example is cmForth, which would request blocks over serial link.
2026-09-05 09:37:35 <iv4nshm4k0v > What examples are there for doing it the other way around: for the system to accept - or reject - bits of source sent over serial link?  I'd imagine that if the code is "bad," the system is ought to signal and reject the code until some kind of a "EOF" marker, right?