4 ms·

(Self promotion, sorry, but relevant.) 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

(Self promotion, sorry, but relevant.) 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. https://www.hypertext.plus https://www.hypertext.plus

BlueTemplar 4y ago
https://www.russellbeattie.com/notes/posts/why-is-markdown-popular.html https://www.russellbeattie.com/notes/posts/why-is-markdown-p... > 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 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-html-bundle-quagmire.html 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 !
- russellbeattie 4y ago
  > Still, bundling is kind of essential 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 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!)
  - BlueTemplar 4y ago
    Markdown implementations : "almost, but not quite, entirely unlike a document format" ;)
gfodor 4y ago
I’m working on this, but for 3D. 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 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.
- gala8y 4y ago
  What do you mean by 3D HTML? That is very interesting. Your page goes to 503 atm.
  - gfodor 4y ago
    Check this out: https://m.youtube.com/watch?v=CnUVCFdpVE4 https://m.youtube.com/watch?v=CnUVCFdpVE4
    - gala8y 4y ago
      Thx.
MrVandemar 4y ago
A HTML Document standard would be great. 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.
- russellbeattie 4y ago
  I'm working on exactly that right now! My next blog post will be a "proposal" for a standard, which I'm going to also post to the W3C working group forums to see if I can get traction from standards committees/browser engines. 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!
laerus 4y ago
How is this different from a WYSIWYG HTML editor?
- russellbeattie 4y ago
  It's basically an HTML word processor. It can create, save and edit .html files as documents. (Plus it has a bunch of other little features listed on the site, but that's the gist of it.) There are lots of WYSIWYG HTML editor libraries available but few, if any, rich-text editing apps that can read and write HTML/CSS files perfectly.

BlueTemplar 4y ago

https://www.russellbeattie.com/notes/posts/why-is-markdown-popular.html https://www.russellbeattie.com/notes/posts/why-is-markdown-p... > 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 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-html-bundle-quagmire.html 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 !

russellbeattie 4y ago
> Still, bundling is kind of essential 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 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!)
- BlueTemplar 4y ago
  Markdown implementations : "almost, but not quite, entirely unlike a document format" ;)

gfodor 4y ago

I’m working on this, but for 3D. 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 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.

gala8y 4y ago
What do you mean by 3D HTML? That is very interesting. Your page goes to 503 atm.
- gfodor 4y ago
  Check this out: https://m.youtube.com/watch?v=CnUVCFdpVE4 https://m.youtube.com/watch?v=CnUVCFdpVE4
  - gala8y 4y ago
    Thx.

MrVandemar 4y ago

A HTML Document standard would be great. 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.

russellbeattie 4y ago
I'm working on exactly that right now! My next blog post will be a "proposal" for a standard, which I'm going to also post to the W3C working group forums to see if I can get traction from standards committees/browser engines. 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!

laerus 4y ago

How is this different from a WYSIWYG HTML editor?

russellbeattie 4y ago
It's basically an HTML word processor. It can create, save and edit .html files as documents. (Plus it has a bunch of other little features listed on the site, but that's the gist of it.) There are lots of WYSIWYG HTML editor libraries available but few, if any, rich-text editing apps that can read and write HTML/CSS files perfectly.