Code formating is something I've needed since the start.

Turns out, theres an intent for that.

document.execCommand("formatBlock", false, "pre");

and done.

I intentionally lowered the steps of editing on bleedwrite to one, two if it's a new post, though now that I've got it up and running, I notice that I'm using it in a way I didn't really anticipate.

After I'm done writing anything, I always log out. Every time.

I'm doing it to:

1. see the site from the public face, which is practically the exact same, and kind of a dumb thing to be doing. Good to check I guess.
   
2. lock myself out from doing something on accident.

I think that it might be to my benefit to add a lockout checkbox or something, just to add a single step to the editing flow. It'd just be a safety, essentially, if its on, none of the editing functionality would be live.

Its a super simple change, but its against the original design philosophy laid out in the opening post. Does that make it a bad idea? No, but I'm worried about feature creep if I were to lose focus on the design goals I'd setup. I can always add it and see if affects my usage at all.

There's three things left I'd like to add:

1. One is a silly easy one I just keep forgetting when I have Coda open, code formatting, kind of essential. I think I'm just gonna add a BB style tag for it, ie [tag]codez[/tag], though I could see if theres a browser intent like I'm using for the links and stuff.
   
2. Stripping out the Webkit ghost formatting, it wasn't in Chrome but at some point was folded back in, useless spans with Apple class names, its weird, I don't know why they're there, but they're annoying to have in my database.
   
3. This is more of a conceptual feature than actually useful. I've done some stuff with websocket, and the thought I had at the outset with bleedwrite is that it'd be cool to build it to stream out what I'm writing in real time, if you were on the page while I was typing you see my revisions Google Wave style, it wouldn't be cached, just streamed as it happened.
   

So, now that most of the functionality I need is here, moving on to the look.

So, tagging's done, the url + tag=tagname = tag search.

For instance: http://bleedwrite.willruby.com/tag=AAAAHHHHHYEAH

AAAAHHHHH YEAH.

I think I'm pretty set for features for a minute, but here are things I'm thinking about implementing sooner rather than later.

The posts have creation timestamps associated with them in the database, it'd be un-American not too, but I'm not printing them out right now. I'm of two minds on that, knowing the vintage of information is useful, but who really reads the metadata anyway? And if the post is six months old, does it dramatically affect the content if its about PHP or Javascript? 

Thats probably not a good enough reason to exclude them though. Regardless I'm toying with adding a posts by unit of time function not unlike the tagging function, maybe date=may2011 printing all posts from this May. It also occurs to me that if theres a lot of posts with one tag, the tag summary display is going to need pagination.

If you can't have many posts sharing tags, the system is pretty fundamentally broken, so that will need fixing, and maybe a rethink on how the url parsing works.

EDIT: so, I wanted to tag this post AAAAHHHHHYEAH, but apparently the string ", A" breaks the tag output? For some reason? BAAAHHHHHYEAH works, stuff starting with lowercase a also works. Beats me.

EDIT 2 The ReEditing: Fixed it, pasting text into the tag box makes the comma not the right character to be exploded. Easiest fix: don't paste into the tag box. Done.

So, I've ironed out a lot of bugs, there are still quite a few things off the list below that remain outstanding as of this writing.

Todo

1. Cleanup, usability, autosaving. could always be better, but improved.
2. Comments, definitely no, no one would use them, not worth the time.
3. Single page view DONE. and pagination. DONE.
4. Tagging. DONE.
   
5. HTML5 roll your own editor DONE. Lets talk about it.

I'm actually really pumped with how easy it was to get an editor together, well, I shouldn't say editor probably.

90% of the functionality I'm using to edit and style text inside of the CMS is provided by contentEditable, and in this case, Safari, as it provides context menu text formatting which saved me some time. (Edit: No longer true, Safari formatting was madding. Chrome all the way.) I just added the JS to handle pushing to the database and all that jazz. The text editing functionality I did have to add UI for relates to the addition of markup, which you can't do just typing into a element with contentEditable set, so hotkeys to add lists or images, that sort of thing.

Now, I say add UI for because I didn't, like I thought I would, have to write code to grab the selection offset inside of the text block, split the content into strings based on that and then add the appropriate html in. I didn't have to because of a nonstandard feature of most of the major browsers: 

execCommand() 

Which is wacky. Mozilla has a writeup on it, and so does Microsoft and other than that I couldn't really find much in way of documentation, but heres how it works for Bleedwrite.

Essentially, this is the fun part: 

document.execCommand("insertUnorderedList", false)

this line of code takes the element that is in focus, finds where the cursor is inside of it, and adds a list there, or, takes selected text and styles it a certain way, or creates a link. The point is that it finds where it should be and puts in the markup, lickity split. All you have to do is change the string from "insertUnorderedList" to any of the supported actions, of which there are dozens, and you're in business.

Or maybe not. 

It should probably go without saying but, caveats abound here. execCommand isn't in the W3c spec, and as one might expect, theres no shortage of inconsistency between browsers. I've been able to use my hotkeys in Firefox, Chrome, and Safari without any major problems, but building a system where compatibility is a bigger concern around execCommand is probably unwise without doing your homework.

Safari, for one thing, adds a lot of junk code every time you make a change that only serves to say, 'hey', Apple was here, and uses <div> instead of <p> depending on some context I'm not sure I understand. It's good to remember that any time you're using a wysiwyg, your going to get messy code, and when you're using a wysiwyg you rolled yourself, you're as likely to get broken code, so be careful. 

That said this post, with only a minor amount of browser induced frustration, was all written in site and in browser, so thats something.

I call this Bleedwrite, and its a CMS for people who don't want a CMS. I've developed websites for Wordpress, Drupal, Indexhibit, and who knows what other content management systems in a professional capacity, and while their powerful tools for managing large amounts of content, I've never really enjoyed my time with them. Frankly with any personal site I've tried to get going, I always end up getting lost in the amount of interface and never end up producing anything. By the time I have everything setup the urge to make anything is gone. Bleedwrite is different, it's all about being able to write, post, and edit your content quick 'n easy, and all without digging though any menu's.

Todo

1. Cleanup, and general usability concerns, autosaving.
2. Comments, maybe? Probably not.
3. Single page view, and pagination.
4. I refuse to code search, that's Googles job.
5. Tagging.
6. New: I'm adding a editor mode not dependent on anything other than html5 editable elements, though I need to add support to add markup if I do that.