> The one thing it does get right is live editing, but you don't have to do WYSIWYG to get live editing -- you can just have a splitscreen with a sane, editable, logical representation on one side and an instant preview on the other.

Years ago I did exactly this for an internal CMS. The preview window used the same renderer as the front end, and there were various dynamic controls the authors/editors could use to control content, reference other content, etc. The preview window would update as they typed and always look like the current styles. If someone went overboard with direct styling, it would be painfully obvious during review, since reviewers first saw the raw content.

The system also had a "cheat sheet" which would show technical writers all of the supported styles and snippets in both literal and rendered forms.

Nice story, but the important part is missing: Did it work? Did people accept that? Is it already replaced by something else now?

This is why I'm so fucking angry at the state of contenteditable. It could have been awesome, but its a complete disaster. If you want anything good (say, autoembedding youtube videos) you essentially have to use text area and fake the whole thing. Like managing cursor state and switching elements.

Contenteditable fails in many ways, but it's still something quite awesome and provides a good basis to build on. I built myself a wiki system because I find the current ones to be a huge pain to edit and I'm using contenteditable as the main tool. No need for separate editing pages, markup languages, or other nonsense - just click edit and make the changes immediately. I agree that contenteditable could have been way better, or in the very least more consistent between browsers.

At first I thought like you, until I started to deal with embed issues. For italics, bolding, and images, it works OK. Shitty to deal with handling some keyboard inputs, but not terrible. Beyond that, it is unmanageable though.

Yeah it's a nightmare, but you can wrangle it with enough work... try the demo here and see what you think: http://www.decalcms.com/tour/

It's good, but it lacks some features I want, like embeding youtube videos and allowing an arbitrary number of line breaks. But it is good and you should be very proud of it. I know how hard it is to make something this complex with contenteditable.

Hey, thanks for the kind words! You can actually embed snippets, just not in the short demo. If you put your email in at the end you get access to a more comprehensive demo that shows how image and object embedding work ... but disallowing arbitrary numbers if line breaks is actually a deliberate choice. One of the primary motivators is in making predictably formattted content so it's easier to repurpose into different contexts (eg. mobile devices or integrated into an application). Since hitting enter a bunch of times is usually a hacky way to fix a presentation issue that should be controlled with CSS we actually write code specifically to disable it.

I think the point is that "preview" is broken concept too.

The text you are writing will be read on smartphones, tables, PCs, and TV. It will have different layouts, e.g. depending on screen size. Which one do you want to preview?

All of them? I don't think there's a way around that, including expecting the people writing your copy to operate in the abstract realm of responsive CSS or whatever.

There's no way around thinking about your use-cases and you're not going to convince designers to not want to see what the end product actually looks like.

I'm not sure I agree on your last point; some of the younger, less print-bound designers I've worked with have a good understanding of the difference between presentation and semantics, and have been often enough annoyed by sites which look just dandy at 1920x1080, but are unusable on a phone, to have a burning desire not to produce more of the same.

Stipulating that point, though, perhaps the solution is to keep designers at a higher level of granularity -- to have them produce designs for "large screen", "small screen", "mobile", "print", &c., including general ideas of how body text shall appear, but leave the more granular detail to someone who's not so much wedded to pixel-perfection, but instead understands that the same content will necessarily look different when differently rendered, and who can understand and accommodate those differences to produce a result that works well across all of them.

Then there is also retina vs non-retina displays, the next site redesign, glossy vs matte screens, and non-color calibrated displays. Then there are different browsers, operating systems, and fonts installed.

It is almost as funny as the request that a logo must use the "Pantone 1337" color. It probably is not representable in RGB and nobody has a color-calibrated screen.

Use the responsive design view built into firefox and try the different screen sizes. You still are going to care 'how it looks' on all of the devices you expect to see it. I understand that it's nearly impossible to control for every screen size, and maybe that's the point, but you should still know and understand what most users will see.

As long as the tool you're using doesn't allow people to inject arbitrary presentation instructions (eg. font size and style) along with the content you can safely allow people to enter their content on one device and know that your responsive style will handle the rest. We are solving this problem and looking for feedback at http://www.decalcms.com/tour/

Wow! This almost exactly what I feel about html editor and why I'm working my live html/css editor (http://liveditor.com) !

Can I quote your response somewhere on my website to explain the idea of LIVEditor?!