![]() ![]() I then treated it as a simple record-based file with that offset and wrote my changes. I then wrote my own code which read the header and got an offset within the. The workflow didn't permit two people to be updating the *same* file, but simply rebuilding the file on update was not permissible for concurrency reasons (nor was it permissible for speed reasons-I was state-saving each item checked off on a screen.) Solution: The files which could be updated in use were forced to no compression. As time went on it the requirements included updating some of those files *in a shared access environment*. zip files as a container to keep all files in an order together. You have to explicitly tell it to produce such a suboptimal result but it can be done. zip files specify the compressor used for each file, one of which is no compression. but once it's on someone's servers presumably it's ready to be read. The one file thing I said earlier was more about sharing the book, similar to an app package. I think if someone is going to go through the trouble to host a book, they probably don't mind unziping a file before putting it on their server. Those situations are rare though, and most JS is just to give a reader like experience. In my view, an HTML document should work like a book, and any JS is purely to augment and extend that book if necessary. The one file thing is cool, but again it requires JS to show anything, so that's not really inline with what I was talking about. Like this, the book would be compatible both offline and to be hosted online, without requiring any changes to the book. In any case, ideally, any ebook solution should have all resources loaded as files relative to the current document, and nothing inline. Finally, just distribute it in a zip file. This achieves the same goal as offline, but in a safer and more universally compliant way.ĥ. In this way, ebooks would always work offline, but it has the added benefit of working online too and would automatically adhere to the strictest possible CSP. It's safer to specify separate styling as resources relative to the HTML, and ebooks should forbid loading resources from a separate domain. ![]() I think it's a mistake to embed all the styling as that may violate some people's CSP's. (for standard ereader capabilities, I think the browser should offer that, but the book itself shouldn't be shipped with an ereader)Ĥ. However, from the perspective of being a book, if it doesn't work as a book without JS then it's a bug in my view. However, if there is some necessity to add interactivity or to augment the book, then yeah, why not, use JS. In other words JS shouldn't be required for it to perform its basic function. Bearing this in mind, I believe that if a reader has JS turned off, this book should work as intended. In my view, an ebook is a book that can change its size in a way that makes sense. I don't personally think JS should be a requirement, but a lot of conversations break down at this point so let do my best to explain and please understand I'm not simply being religious about this. HTML + CSS in 2024 is capable of reproducing virtually any kind of printed medium, but it can also reflow text.ģ. absolutely we should have a single-file, portable ebook format, and since PDF doesn't reflow text then it's not that.Ģ. This is something I deeply care about, as I'm also very interested in the intersection of ebooks, security, and a LowJS web.ġ. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |