Interesting. Why not HTML? Browsers have native basic WYSIWYG editing built in, and almost every screen we look at is nowadays HTML, including the code editor.
On a `<div contenteditable=true> element, calling document.execCommand('bold') will make selected text bold in WYSIWYG mode. See https://jsfiddle.net/z0umpb3x/12/ for the concept.
The main idea here is that I don't want to know any syntax like RTF, nor I want to use any tools.
> Why not HTML? Browsers have native basic WYSIWYG editing built in
Can you point me to a page in Firefox that I can use offline to WYSIWYG edit a hypertext document without needing to use the developer console to edit raw HTML?
I believe it's technically possible, but I don't know if there's a tool.
Btw, genuinely asking, what's your offline scenario? Long loong time ago, I used TiddlyWiki for a brief time period for my temp offline scenarios. Single local HTML, can edit, but not WYSIWYG.
I like this approach and I’m thinking I might agree. I’ve been starting with Markdown, but find myself going to HTML. At some point I end up wanting some specific thing that isn’t supported by Markdown so I need to leave Markdown for embedding a video or adding a tiny bit of interactivity (like show/hide), so sticking with HTML throughout is nice.
HTML isn't "horrible" at WYSIWYG, it just isn't WYSIWYG. Your comment is like saying "JSON is horrible at for loops"—it's just a misunderstanding of the tool.
Yes, my complaint is about the editors. But it's also a problem with HTML because with HTML you can implement a document that looks the same using multiple techniques, so editors will always have code generation differences.
Makes sense. I was thinking that browsers have native support for WYSIWYG editing and most browsers/apps are Chromium based; so how the browser handles HTML formatting should be stable for a single person scenario even across apps.
HTML WYSIWYG editors are not going to create worse tag soup than WYSIWYG editors for other formats. If you care about how the precise HTML cod then WYSIWYG is the wrong tool.
HTML would be a third alternative, yes. However historically it has been less stable in its definition, and also less stable in round-trip editing by a WYSIWYG editor - it has never been been an aim for HTML to be friendly to editing at that level. In contrast there are several editors which handle RTF without disrupting it for other editors. I use TextEdit (on the Mac), but of course it it is a common word processor format. RTFD is far less well supported, but I don't normally need images. I'm not familiar with any WYSIWYG editors for HTML which represent embedded images as though they were part of the same file.
> The main idea here is that I don't want to know any syntax like RTF
Nor do I. What I want is a file format which is long-term viable, and which I can edit in a WYSIWYG editor. The underlying file format being text-based useful as a recovery mechanism if RTF ever becomes unsupported, but it's not intended that one would edit it manually
> , nor I want to use any tools.
While I do not want to edit a file format manually.
On a `<div contenteditable=true> element, calling document.execCommand('bold') will make selected text bold in WYSIWYG mode. See https://jsfiddle.net/z0umpb3x/12/ for the concept.
The main idea here is that I don't want to know any syntax like RTF, nor I want to use any tools.