HTML Notepad – HTML WYSIWYG editor
html-notepad.com
html-notepad.com
html-notepad is Sciter based application so its distribution is only 5 MB.
It's sources are here https://github.com/c-smile/sciter-sdk/tree/master/notepad . This still uses old Sciter.TIS and I am porting it to new Sciter - the one that uses JavaScript.
I am an author of the editor (and Sciter).
- MacOS has handy text navigation shortcuts: alt-arrow to go back a word, alt+shift+arrow to select a word, etc. These don't work, and I'm too used to them to stop using.
- I'm using Colemak keyboard layout (L key inserts letter "i"), but keyboard shortcuts don't respect it. So in my mind I have to press Cmd + U ("u" is mapped to I key) to make text Italic. Again, this broke my usual habbits.
- Common MacOS shortcuts (even Cmd + Q to quit) don't work.
I like the ideas behind this editor, but now I hope someone ports it to HTML + JavaScript, so it works keeping all the OS-provided affordances.
In fact I've created the notepad as a demo project for Sciter SDK (https://sciter.com). The same as Sciter Notes: https://notes.sciter.com
It is just that at some point someone asked me to make distribution so I've created that web site.
Another question was to understand: donation-ware, is it a sustainable solution. Apparently it is not - donation does not even cover sums asked by Apple for allowance to develop software for their platform.
Will sadly make it unusable for me. Thanks for saving me the time.
I don't mind if it will be commercial product or not - I'll help anyway.
As I said - it can be ported to new Sciter (it uses JS now) as it is - relatively easy.
Just drop me a message at https://sciter.com/contact_us/
Sciter was born from my old WYSIWYG editor that I did for EverNote. Here is the story: https://sciter.com/10-years-road-to-sciter/ and here with photo: https://notes.sciter.com/2017/09/11/motivation-and-a-bit-of-...
Sciter was born at times when term Smart Client was the thing.
So it is "Smart Client, next ITERation". So it is pronounced that way: skiter.
Last time I played with Sciter it was based on a proprietary JS engine that wasn't fully exchangeable with common JS. Is that not the case any more, and Sciter will now understand ECMA standard JS?
Mainstream Sciter now uses QuickJS of Fabrice the Magnificent (https://bellard.org/quickjs/).
QuickJS complies to ES2020 specification. And Sciter exposes most popular and modern DOM API so MithrilJS, PReactJS and other libraries work as they are.
Sciter implements far not whole set of DOM API - just essential ones. In fact DOM API and so browsers are full of garbage - old historical layers of stuff from initial Netscape JS API, IE6, etc. For example there is no XMLHttpRequest but there is Fetch API : https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
Sciter goal is not to support browser API as it is - with all its bells and whistles, after all desktop use cases require features that are not available in browsers anyway.
But all non-UI libraries from NPM collection should work as they are in Sciter. Most of pure Vanilla JS UI components should also work as they are, for example LeafletJS (maps) https://sciter.com/sciter-js-runs-leafletjs-as-it-is/
Also Sciter provides rich set of built-in components like JSX, Reactor, Virtual List (https://sciter.com/behaviorvirtual-list-for-sciter-and-scite...) and others.
But anyway Sciter provides an option for host application to link SQLite statically and expose it to JS: https://github.com/c-smile/sciter-js-sdk/blob/main/demos/usc... as set of native objects.
usciter from SDK is an example of application that has SQLite on board.
For example Sciter exposes Graphics API https://github.com/c-smile/sciter-js-sdk/blob/main/include/s..., is this close to what you mean? It allows to render stuff a la ImGUI - immediate mode painting.
And what's in principle wrong with DOM?
DOM is tree of lightweight nodes and elements. In Sciter each DOM element may have native controllers, known as behaviors. Examples of those: https://github.com/c-smile/sciter-js-sdk/tree/main/include/b... . So you can create single DOM node - document and attach your native behavior to it. It will receive all events and will do drawing if you want.
Some applications are using mixed model: DOM where it makes sense, and custom native behavior where high performant handling is required.
In fact DOM and ImGraphics have their strong points but in different situations. Sciter allows to have best of two worlds by combining them.
In any case when you say "I don't need DOM", it means that you will implement it on your side. Been there, seen that many times.
It's not that I don't want any DOM, it's that I specifically don't want "the" DOM as seen in web browsers. What I want is a scene graph without layout or CSS, but with events and transform nodes and the like. You can get close to this in web DOM just by making everything absolute and just not using CSS, but without a way to measure text before drawing it, you can't do your own layout properly.
It looks like Sciter might be what I need to build on top of though, I will look into it further.
Here I'm showing something I did some time ago https://meimporta.eu/htmleditor/ it's a crude WYSIWYG html editor for people that already knows HTML/CSS and uses basically the browser contenteditable capabilities. It was inpired by Webflow (https://webflow.com/) but very simple and basic, it has 4 main sections: editor shortcuts, wysiwyg editor, html editor, tree view. Some things are easy done in the wysiwyg editor but sometimes the raw html editor is better, we can edit in both of then and get instant result.
Don't bother comment on the UI/UX it's an personal naive tool straight to the point I needed. Anyway any feedback to improve is welcome.
Is it open source? I'd like to get it working with my own stylesheets and such.
However right now it's very buggy. I used it for 5min and encountered bug after bug. Even ⌘Q types in "q" and beeps instead of quitting the app.
Also, I suggest you use markdown shortcuts (e.g. typing # will create a header, *text* will make your text italic, etc.) I'm used to them in most text editors and they make editing super easy and fast. Of course keep the content WYSIWYG, just markdown shortcuts, and you can add an option to turn them off in case someone doesn't like them.
Overall though I hope you keep working on this and iron out the bugs, because otherwise it's a great app.
CTRL + NUMPAD 1...6 will convert paragraph to a header. CTRL + I - will apply <em> to the selection.
These are common shortcuts for all specialized markdown editors. And I believe shortcuts are better - more reliable and explicit.
1. the markdown source button does nothing. I have no idea what it's supposed to do, but I didn't see any effect whatsoever.
2. If you type * or h1 etc. then space, it will automatically convert to list/heading etc. However, this doesn't work in the first line.
3. In the `pre` block, when you press enter the cursor doesn't move to the next line. But if you type something then, you will find it will start on the next line. Probably some CRLF shenanigans going on but it's definitely not what the user would expect for a WYSIWYG editor.
You just need notepad.exe + sciter.dll in the same folder.
Static site generators, maybe? Assuming it can be taught to handle their non-HTML metadata…?
That editor is essentially for "Internet Content Writers" - people who create textual content. It is definitely not for creating websites - "HTML-NOTEPAD is not a “web page editor”. Don’t even expect to create “cool web pages” with it" from the front page.
I by myself use it with WordPress and GitHub - write content and then by using either html source or markdown source publish it on those platforms.
I'm not too familiar with Github pages, but in Wordpress's case it sounds incredibly wasteful as you lose all the benefits of Wordpress's modular editor. Why even bother with Wordpress at that point and not use a more lightweight CMS?
N
E
W
If I change title or create another note then it's written horizontally.
Treat it as pure markdown editor that edits content in WYSIWYG form.
The fact that you can edit the elements and they persist is really cool. I wrote a markdown editor for my website that renders HTML and Vue components at request time, but you have no control over component properties. Impressive stuff.
> With modern CSS, WYSIWYG Web design is simply impossible. Web pages are crafted manually by editing CSS, that is by nature of CSS.
mmm.page[1] would like a word with you!
From the "Better html-notepad" section:
> Application Development is tought. Especially design of simple and usable applications.
> I've created this HTML-NOTEPAD application for myself as I am writing a lot on Internet these days. And I am giving it for free with the hope it will be useful for others.
Second: I may follow up directly with the author, but are there any convenient workarounds for num-pad shortcuts? I'm on Windows but really don't prefer using my (detached) numpad for common shortcuts.
Not going to complain about lack of shortcut customization considering the first part of this comment. Great work - cheers.
It feels a lot like the built-in WordPad that comes with Windows, or TextEdit that comes with Macs, in that they both support similar basic formatting but are also both historically built on RTF rather than HTML.
I'll admit I don't really understand the intended audience for this, however. Since it's not for webpages, it seems to be aiming at more basic text editing.
But hasn't Markdown pretty much become the de facto standard for that? For text documents, why would you ever want to write and edit in HTML directly, rather than easier-to-use Markdown that can be converted to HTML on the fly? (Especially with WYSIWYG Markdown editors existing.)
Just curious what I'm missing here.
Latest version: https://github.com/c-smile/sciter-sdk/tree/master/bin.win/x3... , two files from there: notepad.exe and sciter.dll
It does support editing as in WYSIWIG as in Markdown form.
Actually markdown is also form of WYSIWYG. But WYSIWYG on steroids I would say. Markdown format was explicitly designed to emulate WYSIWYG but in plaintext.
For most article writing, the markdown workflow is inferior to using even a basic word processor.
Often, when I write, I want to see the structure of the document visually.
Markdown doesn't allow that.
Also, I'm always writing for the web.
I don't need the extra markdown to HTML step. What does that buy me?
I think this aspect of HTML Wysiwyg is somewhat overlooked.
Is this the next Hemingway app? Probably not.
But for many of us, who write a lot of content intended for the web, this is a great tool to add to the toolbox.
I wanted to write documentation in Markdown, it should be perfectly suitable for that, right?
But this construct for example:
<section>
<header>method ABC</header>
<p>Arguments</p>
<dl><dt>...</dt><dd></dd>
...</dl>
</section>
in html5 you would ommit the unnecessary closing tags for p, dt and dd.
One could call documentation a very specific domain for writing and perhaps Markdown is not ideal for that?
Personally I use it to write letters, notes, blog articles, and such. When I need to write something more complex I might or might not use markdown while embedding some other language. Eg. my thesis is written in Markdown but uses Latex.
Depending on the context you can indeed use the concrete code you wrote as Markdown. You could insist on embedding the the <section> pieces into a Markdown document and use a markdown to HTML preprocessor.
But you are the judge on whether this is a good idea.
HTML supports wide range of applications. Even basic HTML provided more semantic value. You can use it as for articles as for structured documentation. As it supports hierarchical structure + classes.
And pure markdown is not structural and not extendable by design - essentially just a flat list of paragraphs. Yes, you may have some containers there like <blockquote> and <ol> but that's pretty much it. Why there are no sections or any other form of grouping content?
Markdown has exactly the same problem as MS Word / Richtext - they are very good in WYSIWYG but are terrible in semantic.
Markdown.Next shall be in the golden middle between HTML and current MD - with modularity built-in by design.
Sounds like restructuredtext ("That weird markup language used by Sphinx") from around 2000.
Well, Markdown accepts body HTML verbatim. Sure, this makes it non-homogeneous, but nevertheless possible, when needed.
https://docs.oracle.com/javafx/2/ui_controls/img/editor-get-...
it shows <font class="Apple-span-style">, this means the text was pasted from a WebKit browser (or that editor is WebKit itself).
Ideally such (as MS Office one) garbage shall be removed while pasting.
I did it by myself. It is not that I am good designer even that I have artistic education (oil painting) but my primary is MS in Applied Physics/Maths (the combination specific for GUI/UX developers I think).
Every graphic on the intro screen says "ctrl+whatever" instead of "cmd+whatever".
The standard text editing shortcuts don't work. You can't hold option to jump word by word, you can't use ctrl+e or ctrl+a to jump to the end or start of a line, etc.
This alone makes me not want to use it. Every other program I've run supports these things.
Sciter definitely puts text in GTK clipboard. And it works as far as I can tell, proof: https://sciter.com/linuxnotepad/ on my Linux Mint. So your problem needs some details.
And try recent version from GitGub: https://github.com/c-smile/sciter-sdk/tree/master/bin.lnx/x6...
You will need 2 files from there: html-notepad and libsciter-gtk.so
Also HTML that is pasted from external sources (browsers, MS Office, etc.) gets "cannibalized" on pasting:
https://github.com/c-smile/sciter-sdk/blob/master/notepad/re...
with white listed tags and attributes.
The point being that there is no lack of options for building out such features. I'm not sure you'll ever get an editor to do it out-of-the-box, though, because everyone's needs are going to be different.
For example in Sciter I've added transactional DOM mutations feature
element.richtext.update(function(ctx) {
ctx.setAttribute(...)
ctx.removeNode(...)
ctx.wrapNode(...)
});
Also Sciter supports immediate mode painting a la ImGUI that helps a lot to make lightweight editing solutions.
The lack of needed API forced Google Docs to switch to Canvas based rendering and editing : https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...
HTML/CSS renderer: takes HTML+CSS as input and produces rendering. WYSIWYG editor: takes rendering (what you see) and tries to produce HTML+CSS (what you get).
With pure HTML (v 3.2, before styles) WYSIWYG was possible as, for example, to change color of the text you had only one option: <FONT color="red">. With CSS you can apply color the span in many ways: you can use any element for span and apply CSS in various ways.
Rendering, the direct task, is N(rules) -> 1(rendering). And editing, the opposite task, is 1 -> N. Mathematically speaking this task is unsolvable - has no determined solution.