Well you can store it in localStorage or PUT to server [1]. Functionally it is not far from Wordpad yet it is possible to embed code, create UI and it is a web page — ready for publishing.
I've published minimal setup to github for convenience [2].
UI is not included (yet) as I use bookmarklets, it is easy and fun way to extend the platform. Each published bookmarklet contains builder (check page source [3]) — change contenteditable, click Update and drag to bookmarks bar.
It is similar to Smalltalk — edit image with image tools. In fact it is not hard to write `do it (d)`, `print it (p)`.
I have not published HTML PUT yet, fixed [1]. It is example of real life complexity — I have to work around Firefox bug, smartphones choose awfully small font without <meta viewport>, avoid quirks mode with <!DOCTYPE>, <textarea> does not reflect value in outerHTML, search engines asks for <h1>.
And demo now has Save, Load, Reset buttons to store changes in localStorage. There is also body.onload handler so it loads changes on page load [2].
This was/ is very cool. Thanks for mapping all of that out. I've been using Nullboard for the last few months and it's been really nice to be able to save. I'm going to add your note pad idea to it to be able to keep longer notes about things.
data:URI origin has no access to localStorage, so you have to run your own HTTP(S) server to either have origin for browser instances localStorage or roll something like your PUT persistence.
Yup. javascript: URL (either pasted or typed into URL bar) are long gone as self-xss precaution. The only way you can run javascript: URL is bookmarking it and invoking resulting bookmarklet. And AFAIK there is no way to re-enable it again. You have to start web developers console to rund ad-hoc JavaScript code in pages' context. (I see this as an end of glorious era of "you can do pretty much anything in URL bar".)
Well I just quickly tested, and NoScript doesn't seem to block that, whereas it would if it were externally loaded or inline JS on a web page.
So that's one difference. Not that the type of person to use NoScript would likely paste obvious javascript into the address bar...
Edit: Doesn't look like you can create a valid URL with that format, but it can be launched via pasting in (obviously), a bookmark (which the contents of which could be obfuscated by telling a user to drag an image to the bookmark bar and click it), and can be launched via command line, e.g.
To take this to a fun little limit, I tried to turn it into a self-saving form. Unfortunately, I hit problems with the History API being forbidden, replacing the URL seemed to only reload the page and not change it and so on... But I did eventually get something that is quite useable, which you should obviously not copy and past blindly:
I wonder if we took a standard build of the most recent versions of Google chrome, firefox, or safari, plus this tiny code, whether or not that would cost more or less storage than a minimum install of office 97 or whatever the oldest viable version of office for Mac OS x is still out there.
With these few kilobytes of code plus the hundreds of megabytes of runtime that constitutes the browser still take up less storage space than an office suite that can retain State and persist data?
I'd love to see more use of contenteditable in general, and continuing incremental improvement to browser support & standards for it. Right now it's fairly niche, but there's huge potential here imo to build a web that's easier for users to edit and create for themselves directly.
A massive improvement would be if saving didn't open the save dialog and instead just saved the file. I understand why it doesn't work this way but it is a must for a decent editor. Autosave being almost as important, of course (hitting ctrl-s at every keystroke is deep in my psyche, though).
In theory the new file system API would allow for this: https://web.dev/file-system-access/. Ask for a path & save permissions once, and then you're allowed to continue saving to that file however you like, until the tab/browser is closed (and then next time you need to ask for permission again).
Significantly more complex though as you need a bunch of JS, and it's Chromium-only right now.
Slightly off-topic but serious question: Why we have only Microsoft formats for the office documents. Why the open document formats have really bad tooling, why are we not moving to OD ? What will it take to move ?
Because the charter of projects like LibreOffice are fundamentally broken—they're aiming to replace Microsoft Office by cloning it, but Microsoft Office itself is part of a busted paradigm. It reminds me of that old quote from Linus Torvalds about why distributed version control schemes are worthwhile whereas migrating to Subversion is not—because Subversion aimed to be "CVS done right", and that's a fundamentally flawed premise. You need to make something better that fixes what's wrong with the first thing, and make it obvious/unavoidable what the flaws of the first thing were. To displace Microsoft Office, it isn't enough to try to clone it. (Even if you could, Microsoft Office really only persists due to its own momentum, anyway.)
Microsoft Office is a digital approximation of a paper-based paradigm, but it's not really great at either one of those things. The Web and its plaintext formats are way better for sharing and interoperability than MS Office formats. Some fans of MS Office will dispute this, but they're not being honest with themselves. The fans who aren't lying to themselves will instead point out that it's better for print, but it's only better for print in comparison to the Web. If you're actually serious about print, then TeX and PDF/PostScript are better. But most stuff created in Microsoft office isn't ever really intended for print, anyway. So what gives? Microsoft Office succeeds despite being mediocre on both measures because while the alternatives each have things that make them better in their strong suit, they fail at the things they aren't strong at. Microsoft Office squeaks by because it's able to get a C in all its classes, whereas the others remain well-liked among their friends and family, but they don't get to graduate.
Because Office grabbed the vast majority of users, and that for decades. Open formats never got the same level of adoption as Office. You are free to move, it would mostly be compatible with Office when you have to send your work to some friend who only uses Windows and MS tools.
What it will take to move is growing adoption of open formats for office documents, many people have moved decades ago, but the tooling quality is in proportion to the user base size
How do you think I can help push adoption ? Is there a possibility of moving to a different format (non xml based) say html for docs and json for xls and so on ?
1. The open source office suites actually having a good user interface.
2. There being a company that you can pay for support. Corporations/governments can be absolutely paranoid about needing support (even when it is often unused for years).
3. Lots of marketing.
4. 100% compatibility with Microsoft Office.
I know, and again it's not hard to run without that.
But I'm always surprised people don't realise how much difference it makes to have a big "DEMO" link in people's face vs "oh you can click here and here and then you see it!"
Adding these links may literally be the 5 minutes in your creative process that will give you the most value
I have a feeling that, for the poster, the creative process itself has enough value. I appreciate their generosity in taking the time to share their creativity, and inspire others to think of creative ways to test limits and subvert standard ways of doing things- like using a bulky office suite, or putting a big demo button, rather than encouraging readers to interact with interfaces in ways they hadn't considered before.
Of course, if you're trying to monetize, or make sure it's easy for less savvy folks to access a useful tool, you're probably absolutely right.
That is `data:text/html,...` samples — copy, paste into URL, submit. Unfortunately Firefox does not load "data:..." links [1], github "Try it" links digress to hosted pages which breaks the point.
You've made me think though. If it is hard to copy URL, maybe it is hard to copy code into the console. I've added buttons to my contenteditable demo [2].
> Here worth mentioning that elements with an id can be accessed as window[id] or window.id. The thing that wasn’t standardized for a long time and has been a hack from IE, now has become a standard.
<html contenteditable> is too powerful I think.
You can paste HTML,
which you might find desirable for stuff like pasting link anchors,
but if you paste something that uses tables for layout
(HN titles for example).
It leaves it in this weird state where you can delete the table contents but not the table itself.
I think for my purposes I'll use something like
You forgot to include React, Angular, JQuery, Bootstrap, Tailwind, Facbook and Google trackers, and Github CI and Typescript and ES8 syntax! And underscore, moment.js, using a linter with randomized settings. You did however use a minifier and ES6 syntax, so Ill give you one Github star.
I've published minimal setup to github for convenience [2].
UI is not included (yet) as I use bookmarklets, it is easy and fun way to extend the platform. Each published bookmarklet contains builder (check page source [3]) — change contenteditable, click Update and drag to bookmarks bar.
It is similar to Smalltalk — edit image with image tools. In fact it is not hard to write `do it (d)`, `print it (p)`.
[1] http://sergeykish.com/live-pages
[2] https://github.com/sergeykish/live-pages
[3] http://sergeykish.com/bookmarklet-put-xhtml