Similar to my "Go 101" books website, about 1000 line of Go code (started from 500 lines at 9 years ago). The whole website can be built into a single Go binary.
The details / summary feature can also be implemented with pure css without JavaScript. Here is an example: https://docs.go101.org/std/pkg/io.html, just click all "+" signs to expand contents.
This is false, recently the details element has gotten support for grouping them: the [name] attribute.
This effectively enforces tab-like semantics where only one of the grouped details elements can be open at a time.
This is a quite recent addition and the modern web is evolving too fast so I wouldn't put it past myself for missing this :)
Yay for progress and for JavaScript free solutions!
No, it's still true. I'm aware of that hack, but unfortunately it doesn't solve the problems with pure HTML and CSS tabs.
Crucially, the `name` attribute does not semantically turn a group of <details> elements into a set of tabs. All it does is introduce the (visual) behavior where opening one <details> element closes the others.
Same caveat applies to the "checkbox hack" or any other pure CSS solution. You cannot create accessible versions of most complex controls like tabs without JavaScript.
(That first example could be created semantically and accessibly with <details> / <summary> though!)
That's actually a common strategy called "progressive enhancement". The only thing is that your order is backwards: you should first make it accessible in pure HTML and CSS, and then use JavaScript to layer your fancy interactions on top.
So, for the tabs example, your baseline pure HTML and CSS solution might involve showing the all tab panels simultaneously, stacked vertically. Once the JavaScript loads, it would rearrange the DOM to hide all but one and add the tab-like behavior.
Here is a non-exhaustive list of issues you'll run into with various pure HTML and CSS implementations:
- Tabs should have an ARIA "tab" role [1], but <summary> doesn't accept roles [2].
- Focusing a tab must activate the corresponding tab panel [3], which requires JavaScript.
- Tabs should be navigable by arrow keys [4], which also requires JavaScript.
I want to be clear that I'm not trying to tear down your work. Your project looks cool and eliminating JavaScript is a noble goal. But unfortunately, as of today, it's still required to correctly build most complex controls on the web.
I really don't know. I'm not a CSS expert. I've just picked up bits and pieces of CSS knowledge from Google and AI agents. These results often aren't perfect, so you'll need to make some adjustments.
The standard library provides a global allocator. The collections in the standard library currently use that allocator.
It also provides an unstable interface for allocators in general. That's of course useful someday, but also doesn't prevent people from using whatever allocators they want in the meantime. It just means that libraries that want to be generic over one cannot currently agree. The standard library collections also will use that once it becomes stable.
No. There is a global allocator which is used by default, but all the stdlib functions that allocate memory have a version which allows you to pass in a custom allocator. These functions are still "unstable" though, so they can currently only be used with development builds of the compiler.
The problem is, when you modified the go version in go.mod, the behaviors of some code change, but the change is not easy to detect in time. Go team never plan to develop a tool to identify/detect code affected by such breaking changes, leaving developers without guarantees for safe migration.
And consider that some people run go scripts even without the "//go:build go1.xx" directives ... (Please don't refute me. The Go toolchain allows this and never warns on this.)
They can fix the issue by just changing the semantics of "for-range" loops, almost no negative effects. But they also applied the change to 3-clause-for loops, which causes many problems, some of which have been pointed out before the change was made. So the rookie mistake is totally caused by arrogance.
Laudable, but I don't think TapirMD will gain much traction.
First, your landing page doesn't describe how TapirMD fits into the Markdown universe. I just see a list of features. Why should I read the list? Ah, the spec page[0] has some info, but it should really be on the landing page.
Second, and more importantly, TapirMD is not a superset of CommonMark[1]. GitHub had its own flavor of MD, but it's been some years now since they migrated to a CommonMark base plus extensions[2].
I recommend looking more closely at the CommonMark universe and innovating there.
Thank you very much for your feedback. I truly appreciate it.
TapirMD is not a superset of Markdown or CommonMark.
It simply inherits some of its DNA from Markdown.
While Markdown is very simple, it is also highly underspecified and syntactic inconsistent.
CommonMark improves on it slightly, but not fundamentally.
Moreover, basic Markdown lacks many essential features that web content writers need.
Yes, none of these factors prevent it from being adopted widely.
But for me, the limited feature set is the real blocker.
I don’t want to rely on a patchwork of extensions and third-party tools.
TapirMD (where MD stands for `markup doc`) aims to address these shortcomings.
It is a new language, deliberately not compatible with Markdown,
and never intended to fit within the Markdown ecosystem.
Its official toolchain is designed to empower web content writers to create rich,
feature-complete articles without relying on any third-party tools.
The spec is too long to serve as a landing page.
Maybe a concise demo showcasing sample code on the leading page would be great.
Thank you again for the constructive criticism.
TapirMD was primarily developed for my own needs as a technical writer,
to produce content for my websites (see the .tmd soruce of my articles: https://tmd.tapirgames.com/use-cases.html).
Markdown simply felt too limiting. I've been using TapirMD for over a year now and am quite satisfied with it.
I'd be delighted if it proves helpful to other writers as well.
reply