For an even-poorer-man's google docs, I like to keep this bookmarked:
data:text/html, <html contenteditable>
If you navigate to that string in your browser it gives you a blank, editable page. No saving or any fancy features, but it is pretty convenient to be able to quickly spin up a scratch pad sometimes.
Clever, but why? Notepad.exe, TextEdit.app, Gedit, nano are all already there - and do save if you want to after. TextEdit will even just let you quit and come back without saving and the draft is there. Leave the browser sometimes man!
Very cool tip, although I use notepad++ for this because even if I shut everything down it saves any new tabs I opened as temp files without me giving it a second thought.
It doesn't take away from this, but because of the title: Google Docs started much like this, but eventually they gave up on plain HTML and changed to the current model which still uses the DOM but is "complicated"(tm) HTML.
I can't find the link at the moment, but I think it's interesting because despite it being the simple solution, they eventually realized it was holding back adoption amongst business users.
Edit: Found the article: "Babe Ruth and Feature Lists" [0] where former Google PDM Ken Norton writes:
>We were relying on the browser’s rich text surface, which used HTML as the underlying data format and caused browser compatibility nightmares. You’d bold a word and then be unable to un-bold it. Bulleted lists couldn’t be edited or deleted without screwing up the whole page or turning everything into a bullet. Centering a line would often center-align the entire document. Formatting bugs had been an annoyance for Googlers, but they were fatal for groups of students who needed to print a term paper to a teacher’s exacting specifications.
This project is mainly targeted at presenting (read-only) documents, which includes displaying and printing invoices etc. I admit, the project description could have made this clearer.
Basic editing is possible, which is why it's a poor man's Google Docs. Styling is possible as well, if you don't try to bold/unbold randomly, etc.
So for presenting read-only documents, this has zero of the problems that Google Docs had and the project can safely continue to use the DOM and "contenteditable".
No JavaScript? Nice. Don't see too many functional pages without it. I don't know that I would call it a poor man's Google Docs due to the lack of equivalent features but good work nonetheless.
It's quite hilarious to see how a certain class of developers think (or portray) that something is skeuomorphic, and therefore, undesirable, when in fact there is nothing (zilch!) in software that is not stemmed on skeumorphic thinking.
Starting from Object Oriented Programming to visual design, everything in software is a skeuomorphic inspiration of what we have experienced offline before.
For example: The web scroll is a direct skeuomorphic rip-off of physical scrolls from back in the day! In fact between paginated page-flips of modern physical books and scrollbooks or yesteryears, scrolling is probably the older of the two technologies. Then we have paper-like pages in MS Word or Google Docs with page-breaks in them!
The mobile dial-pad is a cute skeuomorphic rip-off of physical buttoned dial-pads on phones. iWatch/digital watches still do good with clock needles the way physical ones always did. Button, shadow, gradients, flat buttons, round buttons, corner elements, form design and pretty much everything in "good design" are all grounded on, in principle, skeuomorphism.
Hell, we even copied the scrolling momentum!
It's a fact: any ego-strut or marketing-speak from anybody in software that says some "design" is original and not skeuomorphic is simply selling bullshit.
What happens if multiple people load the same page and type simultaneously? I'm on a phone and can't test that for myself, but the simultaneous access/editing is what Google Docs truly valuable.
This contributes nothing more than <div contenteditable> and to present this a document editor is counter-productive to users searching for something reliable. The link below shows the many shortcommings of just calling the contenteditable browser API as an emulator. For example, Google Docs does not use contenteditable at all -- for the many reasons outlined below. Building a real doc editor that functions as a widget in blogs and forums sites requires a lot more support -- of the open source alternatives, Medium is one of the best.
You might not have looked at this closely enough, but "contenteditable" is really only one line that has been added to make the demo more useful.
The real thing this is about is the CSS. There are ~250 lines that produce the correct page sizes, margins and paged content and ensure that prints are as expected.
[+] [-] cwkoss|9 years ago|reply
For an even-poorer-man's google docs, I like to keep this bookmarked:
If you navigate to that string in your browser it gives you a blank, editable page. No saving or any fancy features, but it is pretty convenient to be able to quickly spin up a scratch pad sometimes.[+] [-] ianlevesque|9 years ago|reply
[+] [-] aji|9 years ago|reply
[+] [-] edroche|9 years ago|reply
[+] [-] wyldfire|9 years ago|reply
[+] [-] nedwin|9 years ago|reply
[+] [-] nattaylor|9 years ago|reply
I can't find the link at the moment, but I think it's interesting because despite it being the simple solution, they eventually realized it was holding back adoption amongst business users.
Edit: Found the article: "Babe Ruth and Feature Lists" [0] where former Google PDM Ken Norton writes:
>We were relying on the browser’s rich text surface, which used HTML as the underlying data format and caused browser compatibility nightmares. You’d bold a word and then be unable to un-bold it. Bulleted lists couldn’t be edited or deleted without screwing up the whole page or turning everything into a bullet. Centering a line would often center-align the entire document. Formatting bugs had been an annoyance for Googlers, but they were fatal for groups of students who needed to print a term paper to a teacher’s exacting specifications.
0 - https://library.gv.com/babe-ruth-and-feature-lists-1818bb8c6...
[+] [-] marco1|9 years ago|reply
This project is mainly targeted at presenting (read-only) documents, which includes displaying and printing invoices etc. I admit, the project description could have made this clearer.
Basic editing is possible, which is why it's a poor man's Google Docs. Styling is possible as well, if you don't try to bold/unbold randomly, etc.
So for presenting read-only documents, this has zero of the problems that Google Docs had and the project can safely continue to use the DOM and "contenteditable".
[+] [-] paulddraper|9 years ago|reply
[+] [-] jkaptur|9 years ago|reply
[+] [-] fuck_google|9 years ago|reply
[deleted]
[+] [-] BinaryIdiot|9 years ago|reply
[+] [-] combatentropy|9 years ago|reply
Ctrl B: bold
Ctrl I: italic
Ctrl U: underline
[+] [-] rtcoms|9 years ago|reply
[+] [-] kawera|9 years ago|reply
[+] [-] labrador|9 years ago|reply
[+] [-] kowdermeister|9 years ago|reply
[+] [-] tantalor|9 years ago|reply
[+] [-] kevinwang|9 years ago|reply
But isn't it skeumorphic to have pages based off of real paper sizes?
[+] [-] throwawayIndian|9 years ago|reply
It's quite hilarious to see how a certain class of developers think (or portray) that something is skeuomorphic, and therefore, undesirable, when in fact there is nothing (zilch!) in software that is not stemmed on skeumorphic thinking.
Starting from Object Oriented Programming to visual design, everything in software is a skeuomorphic inspiration of what we have experienced offline before.
For example: The web scroll is a direct skeuomorphic rip-off of physical scrolls from back in the day! In fact between paginated page-flips of modern physical books and scrollbooks or yesteryears, scrolling is probably the older of the two technologies. Then we have paper-like pages in MS Word or Google Docs with page-breaks in them!
The mobile dial-pad is a cute skeuomorphic rip-off of physical buttoned dial-pads on phones. iWatch/digital watches still do good with clock needles the way physical ones always did. Button, shadow, gradients, flat buttons, round buttons, corner elements, form design and pretty much everything in "good design" are all grounded on, in principle, skeuomorphism.
Hell, we even copied the scrolling momentum!
It's a fact: any ego-strut or marketing-speak from anybody in software that says some "design" is original and not skeuomorphic is simply selling bullshit.
[+] [-] nathancahill|9 years ago|reply
[+] [-] bryanrasmussen|9 years ago|reply
[+] [-] rezashirazian|9 years ago|reply
[+] [-] markwaldron|9 years ago|reply
[+] [-] elwell|9 years ago|reply
[+] [-] marco1|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] CarolineW|9 years ago|reply
Does this do that?
[+] [-] marco1|9 years ago|reply
It doesn't do this yet, because the focus here has been on perfect representation of pages via CSS.
But using socket.io or something like this, it shouldn't be thard hard.
[+] [-] vtempest|9 years ago|reply
Why ContentEditable Is Terrible, Or: How the Medium Editor Works (2014) (medium.com) https://news.ycombinator.com/item?id=11487667
[+] [-] marco1|9 years ago|reply
You might not have looked at this closely enough, but "contenteditable" is really only one line that has been added to make the demo more useful.
The real thing this is about is the CSS. There are ~250 lines that produce the correct page sizes, margins and paged content and ensure that prints are as expected.
[+] [-] stephenr|9 years ago|reply
Is that a bug, or is it not intended to work that way?
[+] [-] marco1|9 years ago|reply
This does only affect the "in-browser" view. In the print view, everything is correct.
Yet, you're right in that this just isn't acceptable. The "preview" mode in the browser should work exactly like the print mode here.
This is a known issue and had already been tracked here: https://github.com/delight-im/HTML-Sheets-of-Paper/issues/2
[+] [-] a_lifters_life|9 years ago|reply