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!
The nicest thing with using a shortcut like the one above is that all formatting is preserved, tables especially, but also other html elements with styling (mostly). This is very handy in a lot of contexts.
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.
Those are built into the operating system, not the browser.
My point is that not everyone has those features out of the box. Sure, you can install more software, but it's not a reason to not have a feature like that in this word processor.
Yes, I really wish Firefox added this feature! As far as I know, they even have this in the Android version of Firefox.
Anyway, if your operating system comes with a PDF printer or if you installed one manually, you can use the normal printing feature that every browser has.
What are you on that Firefox doesn't have a built-in print-to PDF? On GNU/Linux, I've got a "Print to File" printer that lets me select between PDF and Postscript, even though I don't have cups-pdf installed.
Thanks! That "Print to File" is provided by the operating system, not Firefox. I'm on Windows 7, where the operating system doesn't provide this. Yet Chrome provides it itself.
I used to use it as a CUPS feature, but as I said: I don't have cups-pdf installed, and indeed, I don't have CUPS installed at all. Perhaps it is being provided by some system library (perhaps libcups), but not by CUPS itself.
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.
Thanks for this short excursus, but "not skeuomorphic" has never been marketing speak here.
Instead, it has been added only to disassociate from a HTML/CSS imitation of paper (the material) by itself, which quite a few people have been expecting, given the (improvable) title of this project.
> Instead, it has been added only to disassociate from a HTML/CSS imitation of paper (the material) by itself
Assuming that digital screens cannot truly be produced using cellulose and starch (the material) the dissociation and difference in the nature of medium is understood. And then the "software part" has absolutely no role to play in that dissociation.
You can't evade the fact that it is just marketing-speak at every level. I am pretty sure that the dev community likes to believe otherwise, and hence the downvotes, but that's just lame groupthink anyway.
FWIW, I understood it as "we didn't use a background 'texture' that visually resembles a piece of looseleaf paper", and I rather welcomed that particular visual design choice.
Good design is one where a user doesn't lose focus from the task they had on their mind -- be it in physical realm or software. In fact for this reason alone there is no well-designed software in the world, anywhere, that doesn't rely on skeuomorphism at its core.
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.
I suspect it is harder than you think. Have a go, and let us know how you get on. I'd love to see a simple, light-weight, elegant alternative to Google Docs.
Thanks, I didn't mean it's trivial, but it's not a hard technical problem (anymore) to do that on the web.
Not sure if I'll be working on this, though, because there are so many (commercial) services providing this already. Sure, you might think that Google Docs could be more lightweight and elegant, but for many people it's working fine and that 10% improvement on Google Docs is definitely too much work for a tiny open-source project.
I was talking about basic functionality, just as you were in your first comment. The title of this contribution didn't talk about a poor man's Google Docs by chance.
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.
When i viewed the print preview it seemed broken too - the content in the first on-screen page (which was too long) became two pages, and then in the print preview it forced a new page before the next block of content.
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.