I believe that the time has finally come to fulfill TBL's "Phase 2" so I created a prototype a few weeks ago. It's just an HTML editor made to create HTML Documents. Not web sites, not landing pages, not designs, not mockups, not apps, not games, just HTML based rich text documents with links and media you can edit and save locally.
The essential pieces you may be interested in:
- put all UI in shadow dom under the root, so inspector is exactly the html being edited
- use the file system access api to allow local writeback to file system while editing
- when on the web, connect to GitHub or via WebDAV to write back to origin while editing
- collaborate via crdts over webrtc. I wrote a cheap/free serverless signaling system for this: https://github.com/gfodor/p2pcf - you can use y.js to sync the document DOM
DM me on Twitter if you want to Collab - this particular thread is something I’m going to be pushing hard on but not for 2D HTML, but 3D HTML. Spatial 3D documents in HTML is likely going to be a major thing with the arrival of WebXR and spatial computing.
What is stopping you explicitly defining such a standard? Gruber did it with Markdown and that seems to have gone pretty well.
I use HTML for all my notes and writing, and I guess I have my own loosely defined "Standard" in the sense that I use a subset of tags, very light use of CSS, a predefined document structure, and I use the abbreviated model of HTML that doesn't require certain tags to be closed.
What I'm working on now is the specific Sanitizer API options which explicitly list out the semantic HTML elements which are allowed, as well as the valid attributes. That will make implementing the standard pretty straight forward. However, the API doesn't cover style properties, so I'm wondering how deep I should delve into CSS, or just leave it alone. Not as clear cut as it seems because of @imports and fonts.
There's a bunch of this-or-that questions I'm trying to figure out like how restrictive should the Content Security Policy be? Will it allow external URLs for images/media, only secure sites, or be totally locked down to just data:// urls? What about file:// urls? Should I even use the Sanitizer API? If you open a document and there are extraneous elements, should they be ignored or deleted? An editor which potentially destroys a page isn't ideal. What about iframes? If you want to add a YouTube video, it's done via an iframe, so killing it all together doesn't seem like a great idea. Then again, that's a potential security/privacy issue. Etc. etc.
I'm leaning towards a restrictive, self-contained format which is as risk-free to implement as possible from a security and privacy standpoint. Basically re-creating how secure the .mhtml files are now. However, that's a lot less flexible than allowing external content to be loaded. But from everything I've seen online, any "standard" which isn't by default stupidly safe will be a non-starter from the browser makers perspective, and my ultimate goal is to have the doc format be something that can be natively opened. Even if I forgo that dream, it may just make sense from a practical standpoint - forcing the files to be useful only as documents. But then again... you get the idea.
I'm hoping to come up with a rationale for all the decisions, write as complete a spec as possible before opening it all up to input to avoid bikeshedding as much as possible. We'll see how it ends up!
> Why don’t we have an HTML-based rich text standard yet?
> I have zero idea. In fact, we seem to be getting farther away from one as Markdown popularity surges.
> The other day I read a blog post by the folks at Mozilla - who are supposed to be the standard bearers of, um, web standards, and was truly shocked that they decided to convert all their documentation to Markdown last year. What?? In fact, they stopped using HTML in order to do it.
Yep, I am baffled by this too. Glad to see that I am not the only one !
I am aware of at least one document editor project that at least tries to have a working round trip conversion to HTML :
https://texmacs.org/tmweb/help/faq.en.html
(But I am afraid that it will never work as well as an editor that treats HTML as the first class document type...)
https://www.russellbeattie.com/notes/posts/the-decades-long-...
> But most importantly, since my goal was to replace Markdown as a simple, easily manageable rich text document format, trying to also tackle the bundling issue was besides the point. Markdown doesn't include files, doesn't care about them and will never have them. There's no reason for an HTML Document standard to deal with encapsulated files either, as essential as it might first seem.
> All that said, I'm sure someone, somewhere might wonder why my Hypertext editor doesn't have some sort of option to save as a zipped file format of some sort, I thought I'd share what I discovered reading up on the topic. Then maybe someone can get the W3C, Mozilla, Google and Apple to finally make up their minds and decide on a standard that we can use in the future. (I won't hold my breath.
Yeah, sigh...
Still, bundling is kind of essential - most documents will want to have at least some multimedia, and you generally do NOT want to have them get split into multiple files !
As you say I still don't understand why Firefox, instead of a separate folder for the non-HTML content, does not "throw a bunch of files into a zip and call it a day?", especially when ePub does that already !
Heh. I agree, actually. And even though I wrote all that, it was partly to convince myself to stop thinking about it. It didn't work.
Here's a prototype I finished last night for a secure, self-contained HTML doc format. It has a script at the top that monitors all the media tag additions like images, video and CSS, and then swaps them for base64 encoded data URLs contained at the bottom of the document. I say "secure" because the doc has a super-restrictive CSP at the top of the page which basically disables asset loading.
It's sort of a cross between MIME-HTML and SingleFile, but the end result is a page that's identical the original HTML, except for a bit of JS which I envision the browsers would take care of for .htmd files, and a chunk of JSON at the bottom for storage.
https://www.hypertext.plus/demo/htmldoc-test1.html
(BTW, Thanks for reading all my rantings! I appreciate knowing it's not going into the void!)
;)