acabal

But can't they just use an xpath expression to test the computed text content of a node, like `/path/to/ad/div[contains(., 'sponsored')]`? In that expression, there could be any number of nested elements inside the terminal `<div>` and it wouldn't matter. (And you'd probably have to use a regex test to account for tricky white space.)

I see this is part of the Triptych project, an attempt to, among other things, bring more verbs into HTML forms. As I've said before one of my long-time dreams is to have HTML forms support methods other than GET and POST.

Clicking on forms is how humans interact with HTTP, and for some strange reason the web has evolved to omit many very important words us humans must use to communicate. While a machine is allowed to say `DELETE /widgets/123`, a human is forced to say `POST /widgets/123/delete` or `POST /widgets/123?_method=DELETE`.

This is not only semantically incorrect, but also results in idempotency and caching issues, and, perhaps worst of all, forces developers to maintain two separate APIs: nice, well-formed REST endpoints for machines, and separate kludgy endpoints for humans, who were granted a stunted language.

Butler's Odyssey and Iliad are prose translations, which we felt didn't fit the commonly understood image of those works as works of verse.

SE Editor-in-Chief here. We selected the William Cullen Bryant translation because we felt that, of the public domain translations, it was the one most accessible to modern readers. We also host his translation of the Iliad.

Pope's is certainly very beautiful, but also very literary and written in a style of English that can be difficult for the average modern reader. I think that determination is well reflected in this survey. Maybe we'll do it too one day (our current collections policy declines alternate translations) - it's certainly deserving.

At Standard Ebooks we use the three-em-dash to indicate a fully obscured word, for example this line from Tristram Shandy:

> He lies buried in the corner of his churchyard, in the parish of ⸻, under a plain marble slab

If we were to use three em dashes in a row, the renderer typically puts a 1-2px gap between them. Using U+2E3B leaves no gaps.

Likewise, we use a 2-em dash, U+2E3A, for partially obscured words, for example this line from Gogol's short fiction:

> The town of B⸺ had become very lively since a cavalry regiment had taken up its quarters in it.

Because if HTTP is the language of the web, then HTML forms are how humans speak that language to computers. Right now we humans can only speak GET and POST.

In other words, right now if a human wants to DELETE a widget, the human has click on an HTML form to `POST /widgets/123/delete` - i.e. use an incorrect verb on an incorrect URL/object - or use some other workaround like smuggling a special `_method=DELETE` variable. This is unnatural and semantically incorrect, resulting in ugly hacks that break HTTP-level expectations like idempotency; and it also requires additional app-level logic to process.

Meanwhile a machine is allowed to simply `DELETE /widgets/123` because their interface to HTTP is not clicking on HTML forms.

We humans could converse with websites in semantically correct HTTP, have clean URLs in which both REST APIs and human-facing URLs are identical without hacks, and require no extra app/framework logic, if HTML forms simply allowed all (human-relevant) HTTP verbs.

Supporting more than GET/POST in HTML forms has been my dream for decades. There's a WHATWG proposal to do just that if you want to add your voice: https://github.com/whatwg/html/pull/11347

Home folder litter is one of my top pet peeves in computing. In fact it's the only reason why I refuse to use snaps on Ubuntu. I don't even care about whatever technical stuff everyone argues about - but snaps create a permanent `~/snap/` directory and Ubuntu devs don't care. There's been a bug report on Launchpad for over a decade[1] and it's the second highest voted bug in Ubuntu history, but no, Ubuntu devs think littering the home folder with highly visible system-level machinery is totally unavoidable.

It's like putting your car's engine in the passenger seat - rude, intolerable, and plain stupid. What if Grandma was browsing her home folder and deleted `~/snap/` because she has no idea what it is?

[1] https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053

The gem in this post is Pure, which I haven't heard of until now. I also have my prompt show the git status, and for large repos `git status` can take 10+ seconds to load and cache.

I had no idea that you could do that asynchronously, and then have ZSH update the already printed prompt with the status later! That blows my mind!

SE editor in chief here. What you describe is incorrect. The only thing we do is very light sound-alike spelling modernization, like "to-night" -> "tonight". We do not do things like change from en-GB to en-US, replace old words with different modern words, or change text for "American readers", whatever that means. I have no idea where you got that impression.

I personally worked on the Forsyte saga. If you think something was done in error, please let us know and we'll be happy to fix it.

This article is rediscovering the same phenomenon that happened when the steam-powered machinery was invented, leading to the Luddite movement.

Machinery at the dawn of the industrial revolution was supposed to be a time-saving miracle that freed capitalists from having to deal with workers, and also freed workers from backbreaking labor, letting them spend their hours in the pursuit of leisure.

Of course, the opposite happened. Machinery meant workers could produce more output in the same amount of time, so they didn't work less, they worked at least the same and eventually even more to keep up with competition and the demands of consumers. It took decades of unrest and bloody conflict to give us the 8-hour workday.

This article is rediscovering that same history, but for a different class. AI is to white-collar knowledge workers what steam-powered machinery was to the rough-handed working class of the 1800s. It promises capitalists freedom from having to deal with highly-paid knowledge workers, and it promises highly-paid knowledge workers freedom from their labor so they can spend their time in the pursuit of leisure.

Look to history to see how that worked out.

I've always told people, Kindles are ereaders seeming designed by people who hate books.

The renderer is atrocious and is holding back the entire industry, much like IE6's crappy renderer and monopoly on users held the entire web back a decade. Browsers (and thus ebooks, which are just HTML/CSS) can now do pretty decent typography, but Amazon inexplicably refuses to get on board with epub.

Their file formats are equally garbage. Mobi, a format that has hardly changed since circa the year 2005, was still in active use until just recently. Their other proprietary formats are confusing in feature set and are opaque to create. The official tool to create Amazon ebooks only runs on Windows![1]

Kindles still can't natively read epubs, but since they accept epubs via email, their customers get confused and email me about it. (Epubs sent via email are quietly convert to Amazon's propriety format, meaning all bets are off on the result. Good luck, publisher!)

I always tell people, buy literally any other ereader.

[1] Calibre can also create them but it's reverse-engineering and not the official implementation.

The reading ease algorithm we use is the Flesh-Kincaid algorithm, which works pretty well for regular prose books but clearly fails very badly on avant-garde prose like Ulysses or As I Lay Dying.

XML lost because 1) the existence of attributes means a document cannot be automatically mapped to a basic language data structure like an array of strings, and 2) namespaces are an unmitigated hell to work with. Even just declaring a default namespace and doing nothing else immediately makes your day 10x harder.

These items make XML deeply tedious and annoying to ingest and manipulate. Plus, some major XML libraries, like lxml in Python, are extremely unintuitive in their implementation of DOM structures and manipulation. If ingesting and manipulating your markup language feels like an endless trudge through a fiery wasteland then don't be surprised when a simpler, more ergonomic alternative wins, even if its feature set is strictly inferior. And that's exactly what happened.

I say this having spent the last 10 years struggling with lxml specifically, and my entire 25 year career dealing with XML in some shape or form. I still routinely throw up my hands in frustration when having to use Python tooling to do what feels like what should be even the most basic XML task.

Though xpath is nice.

Sure, but to maintain a CSS framework? Seems like they way overhired.

Taking their sponsors page at face value and doing the math, they're bringing in close to $100k/month with corporate sponsorships alone... how much money could maintaining a framework possibly cost?

No, none have reached out yet. I've had some brief, high-level discussion along those lines with some people in the library industry, and the conclusion I drew is that public libraries in the US are highly fragmented in terms of technological capability. Instead of partnering with individual local library systems, it would make the most sense to - as you mentioned - partner with Overdrive. But there's been no movement in that direction. If anyone from Overdrive is reading, get in touch :)

I know you griped about this in a different thread, but we won't be doing that, sorry. You can uniquely identify an ebook and its version by using dc:identifier in combination with dcterms:modified in the metadata file. If you desperately need a filesystem-safe string then concatenate those two and sha it.

As Robin mentioned the typical style is "fine art oil painting", with some wiggle room allowed for exceptionally difficult cases (like Asian-themed books, as there just wasn't much fine art on that subject pre-1930).

We also require that the art have some kind of connection to the book itself, so it's not just some random fine art. Sometimes the connection is a little fuzzy, but we do the best we can given that art must be pre-1930 and also must have been previously published.

(My personal favorite artwork selection of the books I worked on is The Communist Manifesto[1]. That painting was actually made specifically for a different book by Willa Cather[2], but I thought the peasant laborer, holding a sickle in one hand, with a faraway look in her eyes as the red sun rises behind her was just too good to pass up for Marx!)

1920ish was when it started becoming much more common for books to have illustrated dust jackets, so now that more books from that era and onwards are entering the public domain, we opt to use the first edition dust jacket if it's in the appropriate style. Fortunately for us, that era also happens to be the so-called Golden Age of Illustration so it's not hard finding beautiful art to use!

[1] https://standardebooks.org/ebooks/karl-marx_friedrich-engels...

[2] https://standardebooks.org/ebooks/willa-cather/the-song-of-t...

We have a list of wanted ebooks here: https://standardebooks.org/contribute/wanted-ebooks

First-time contributors should select something from the appropriate section, because that gives you the greatest chance of succeeding and the least burden on our reviewers as you get started.

Our toolset has a help wanted section and some outstanding issues: https://github.com/standardebooks/tools#help-wanted

The ebooks we produce are entirely in the US public domain, including metadata and any other files. Unfortunately there are basically no good fonts released under the CC0 license. (Most open fonts are released under the OFL license, which is not the same.) Therefore we don't embed any font files, except for Standard Blackletter[1] when necessary, which is a font we developed especially for our use based on public domain specimens, and released via the CC0 license.

[1] https://github.com/standardebooks/standard-blackletter

SE Editor-in-Chief here! As always, happy to answer any questions.

For a literature-focused list of items entering the US public domain on 2026, Standard Ebooks has 20 ebooks prepared for release on January 1: https://standardebooks.org/blog/public-domain-day-2026

Headings can't help Slavoj, his writing is characterized by a few grains of interesting ideas totally overwhelmed within SAT-prep word salad.

We do the same with our feeds at Standard Ebooks: https://standardebooks.org/feeds/rss/new-releases

The page is XML but styled with XSLT.

I'm shocked and saddened to hear this. Greg was a deep source of knowledge and support as I started and shepherded Standard Ebooks. He was generous with his time and experience, and unbelievably patient with me, some guy he had never heard of or met before who was just another cold-email in what must have been an endless stream in his inbox. We should all aspire to his high spirit of camaraderie, charity, and kindness. The world has lost a champion of both literature and the free web.

Firefox does support XSLT. At Standard Ebooks, our ebook OPDS/RSS feeds are styled with XSLT when viewed with a browser. See for example https://standardebooks.org/feeds/opds/new-releases (use view source to see that it's an XML document).

No, there are too many things to track, but all of it is in the git history. Editorial changes have a commit message prefaced with [Editorial].

> "Don't like it? Here is a full refund and you are free to read some other version."

That is not at all what I said.

> You can't claim to care about preserving the works while changing them, and that is changing them.

We do not and have never made that claim. We are creating our own editions of these public domain books, not engaging in historical preservation.

If you want to read classic books in their original spelling, then you must locate first editions. Editors and publishers have updated both spelling and punctuation as a matter of course for centuries. Just look at any three editions of any Jane Austen novel - and you could never read an edition of Shakespeare more recent than 1800.

This is not entirely correct - Kobo also expects a bunch of special <span>s inserted for things like highlighting and page numbers to work.

It kills me that Kobo is so close to having plain epubs rendered with Webkit but for some reason they just won't take the leap!