This is why you need regulation to add transparency obligations to providers, and to remove algorithmic assessment from harmful situations. The EU Artificial Intelligence Act is a good first step: https://en.wikipedia.org/wiki/Artificial_Intelligence_Act
After I’d been in the firing line for a couple of Reg articles I started realising that yes, they don’t let much stand in the way of a good story. They still write a good story though, it’s just slightly more tenuously tethered to reality than I’d originally imagined.
At least you know what you're getting with El Reg, unlike Very Serious Publications written for Very Serious People. The average article in CIO is also densely-packed bullshit, just polished up more.
It’s Postel’s law at the end of the day: “be conservative in what you do, be liberal in what you accept from others”. As a site owner I want my site to fail loudly and quickly before a user sees a problem; as a user I never want to see a problem.
ePub is in a nice place: the number of documents to check for errors is reasonable, and the resulting artefect is designed to be shipped and never (or rarely) amended. That means that we can shift the balance towards strict parsing. But for a web site of thousands (or millions) of documents that are being amended regularly, the balance shifts back to loose parsing as the best way of meeting user needs.
Postel's Law sounds nice but it can result in major problems. It results in a de facto spec that differs from the written spec, and disagreements about what a piece of data actually means can lead to bugs and even security vulnerabilities.
Having strictly parsed HTML from the start would be fine. You'd check it before you ship it and you'd make sure it's valid.
Requiring it now would be a disaster, of course. There's so much malformed HTML out there. But making HTML parsers accept garbage at the beginning was the wrong choice.
The widespread acceptance of Postel’s Law also encourages poor authorship, because if you know clients have to be liberal in what they accept, there is no incentive to be conservative in what you send.
Isn't the developer always the first user? With strict parsing, testing a site before launch would show you the problem right there and allow you to fix it to launch a bug free site.
That is what the HTML 4 !doctype Tag - https://www.quackit.com/html/html_4/tags/doctype_html_public... - was meant for. Ideally, an old client that cannot parse a newer HTML spec should inform the user to update the client. Developers could then either support old versions of their site (more easily, in such a case) or can simply decide not to deal with outdated browsers. (In fact, isn't that what most BiGTech sites actually do now, through convoluted browser feature detections - "Your browser is no longer supported ...").
No, not really, and given the length of time ereaders stick around, you’re really probably best off assuming the worst. If there’s something complex layout-wise that I want to do then I often use @supports blocks. For example, in a recent book I worked on I had a layout that would be be accomplished with flexbox, but I started with floats instead and overrode that for better ereaders: https://github.com/standardebooks/harry-harrison_planet-of-t...
Thanks for all the explanations. I always thought it was regular HTML, but now I know to watch out for the differences.
Can you say a few more words about the library https://github.com/standardebooks/tools ?
Can it generate ePub3 from markdown files or do I have to feed it HTML already. Any repo with usage examples of the `--white-label` option would be nice.
The tooling does two main things: create a valid epub3 skeleton for your content, and build your book into “compatible”, Kobo and Kindle versions. You need to supply the valid XHTML.
I was somewhat buying the article until I got to the monstrosity that is the “Special mention”, at which point I flipped to completely agreeing. That really is atrocious.
reply