Show HN: ~200 byte in-browser, no JS, private notepad(jjjjjjjjjjjjjjjjjjjj.github.io) |
Show HN: ~200 byte in-browser, no JS, private notepad(jjjjjjjjjjjjjjjjjjjj.github.io) |
To save a note just store it on disk (cmd/ctrl+s). To add images, drag and drop them onto the text area. Remove the contenteditable attribute from <body>, save, and voila, you now have a static lightweight blog post ready to be published! Formatting can be a bit wonky but should work in some browsers (cmd/ctrl+b/i/u). Copy+pasting formatted text can potentially break things a bit.
The two colors are from Solarized. Feel free to download the file and update style/markup to your preference.
Some ideas/variations:
Dark theme: https://jjjjjjjjjjjjjjjjjjjj.github.io/new-note/dark.html
Serif: https://jjjjjjjjjjjjjjjjjjjj.github.io/new-note/serif.html
HN theme: https://jjjjjjjjjjjjjjjjjjjj.github.io/new-note/hn.html
With heading: https://jjjjjjjjjjjjjjjjjjjj.github.io/new-note/with-heading...
What's this supposed to do? On Firefox/Win it just saves the initial blank page as you'd expect, which is not very useful. Removing the `contenteditable` attribute before saving makes no difference.
I'm not aware that there is a simple portable way to save dynamically-modified webpages; projects like TiddlyWiki have been banging their collective heads against this problem since forever.
You might be interested in a new way to create websites I'm creating. Websites are stored as JSON, and a small Javascript engine file writes these directly to the DOM.
This makes the site very easy to dynamically modify and save, which is the basis for this as a hosting service - the site itself contains a site editor that outputs the site as JSON, and uploads itself to S3.
(It's in late alpha, and will hopefully move to beta before the end of the month.)
are you talking about the windows notepad? it's as simple as a plain text editor can get, how is the contenteditable notepad better?
Either that, or I'm in the Twilight Zone.
Just because it is simple does not mean OP has to like it.
Pale Moon 27.9: Image conversion to base64 worked perfectly
Dooble 1.50: creates clickable link (file:///home/user/.../filename.jpg)
Midori 0.5.11: creates NON-clickable link
Otter 0.9.09 beta 9: creates clickable link
Chromium 65.0.3325.181: opens new tab
Opera 45.0: opens new tab
Anyway, I know you said you don't like lots of different things, but you might actually find that you like BoostNote. I'd say give it a try, I think it's great.
It seems like it would be pretty easy to add a save/load feature with localStorage.
I know it wouldn't be 200 bytes, but this is a pretty great idea.
I created this self referencing URL:
`data:text/html, <html><head><title>SO META</title></head><body><h1>This link's url is</h1><script>p = document.createElement("p");p.innerText = window.location.href;document.body.appendChild(p)</script></body></html>`
The sad part is that <a href>'s are actually blocked from using data:text/html URLs. So we can still create tiny games and apps that can be copy/pasted in the address bar, but we can't link to them.
If we can put the data in an image file a user could drag a cart into their address bar to load up a game. So we can pass around carts like images.
You can also <a> to a URL that issues a redirect to a location given by a GET parameter, eliminating the need to stand up a site for every different idea you come up with.
<a onclick="document.write('<html>...</html>'">other game<\a>
Anyone know what I am talking about?
the win32 one, or did they replace it with a metro/modern version?
document.body.innerText += 'hello world/n';
echo hello world >> file_in_notepad.txt
If you’re still writing native apps in 2018, you’re throwing money right out of the window and you deserve bankruptcy.
I prefer native apps in most cases over some web counterpart with rare exceptions.
[1] http://indirection.modusponens.org/data:text/html,Hello,%20w...!
Http Redirection to data: urls has been blocked in chrome for at least half a decade. There's really no reason to allow that, a server can just as easily return the data as the response body.
Making Node or similar a prerequisite kills that value proposition stone dead, never mind piling on things like S3 as backends.
This is true for this new system as well. The browser engine is only needed to write JSON to the DOM, since browsers don't natively read JSON. You could host both on your SSD and point a webpage at them. (XHR caching is a to-do item.)
S3 is used because it's relatively common and trusted. Node (or any server) is just used to facilitate writing to S3. Node specifically is used because it's simpler to develop everything in one language, and that's the only language that runs in browsers.
Safari cut-and-paste works for images.
Of course, as the iPad runs out of memory as I use multiple apps, stops Safari then reloads it when I come back. Which loses any edits to the content.
Expected. The unexpected is that this simple thing is as functional as it is...