For a while we’ve been exploring switching to WYSIWYG text editing in our products. Up until this point we’ve been using either plain text, manual HTML, or Textile formatting. Depending on who you are it’s either fine or annoying. We want to do a lot better.
We’ve looked at a lot of existing options (Yahoo’s WYSIWYG plug-in, TinyMCE, etc), but we weren’t happy with any of them. Currently available WYSIWYG editors don’t offer much flexibility when it comes to modifying their look and behavior. You are stuck with their HTML, buttons, and design. Modification was possible, but it was really ugly behind the scenes. We really needed a framework for building our own editor with beautiful code and a low cost of change.
WysiHat
So we decided to make our own. It’s called WysiHat and we’ve open sourced it. Get it? WysiHat. Hat instead of Wig? Funny, we know! Today we’re releasing a very stripped down early developer release.
WysiHat is a WYSIWYG JavaScript framework that provides an extensible foundation to design your own rich text editor. WysiHat stays out of your way and leaves the UI design to you. Although WysiHat lets you get up and running with a few lines of code, the focus is on letting you customize it.
We are giving developers early access to the project while we continue to work out the remaining issues. Note: It’s extremely early. Contributors are welcome so please check out the project on GitHub and send us your feedback.
Jay Owen
on 21 Oct 08Sounds good. I am looking forward to trying this out.
Phil McThomas
on 21 Oct 08I don’t get it. Seriously. Feel free to stand on my toes, laugh opening, and ban my email address from future posting. But I don’t get it.
Phil McThomas
on 21 Oct 08s/b “laugh openly” – I’m also dyslexic
Paul Smith
on 21 Oct 08That is kind of funny, I didn’t get it until you explained it though. :p
macournoyer
on 21 Oct 08Is Josh Peek working for you? Cause looks like your just forked the project.
Nathan
on 21 Oct 08I’m glad someone is trying to make a generic, simplified wysiwyg editor.. I’ve used tinymce a bit and it is a big hassle. especially customizing it.
@Phil McThomas – what don’t you get? It’s a wysiwyg text editor for the web that is hopefully less sucky than the existing options.
Ricky Irvine
on 21 Oct 08What You See Is Hardly Actually That
JF
on 21 Oct 08Yes, Josh Peek has been developing this for us.
N C
on 21 Oct 08Will it support xhtml output? Please say yes.
Ryan
on 21 Oct 08Good luck going down this rabbit hole. Making a great WYSIWG editor is like trying to nail Jell-O to a wall. Many have tried, and they all have problems.
Nathan
on 21 Oct 08I was going to put up a publicly viewable example but I cant get the examples to work.. on the simple example I just see an empty textbox, the other examples show buttons as links but they don’t seem to do anything.
Josh Peek
on 21 Oct 08@NC Short answer, yes. But you could totally configure that however you want. The built in “formatter” normalizes the output as nice and neat xhtml.
Nathan Moore @ Anthology Creative
on 21 Oct 08@Nathan – I am seeing the same thing. After digging into the code, it looks like the .js file that should be at ”../dist/wysihat.js” is missing in the repo. Hopefully they will fix this so we can try it out.
Josh Peek
on 21 Oct 08@Nathan you need to run ‘rake’ to build the source. I’ll update the example files to make that more clear.
mike
on 21 Oct 08Why post this news without a demo? Or at least a screenshot or something…
Trevor Turk
on 21 Oct 08This is great news. I’ve been unhappy with the state of WYSIWYG tools for a while now. Going the framework route makes a whole lot of sense. Give developers a shared foundation, and they’ll be able to build the rest of the structure as their individual needs dictate.
TJ Stankus
on 21 Oct 08This is a need for this. Based on all your other great software, I have high hopes. Looking forward to checking it out.
Zinni
on 21 Oct 08Thank you for this!
You are completely right about current options lacking flexibility. I have been utterly frustrated with them in the past. As a designer the option to design the UI of the elements is also something that was much needed.
wesley
on 21 Oct 08Not very user friendly of 37signals not to have a demo or screenshot with this announcement.. Usability 101? :)
Tim
on 21 Oct 08Where can I see a demo of it?
David
on 21 Oct 08@Josh Peek Sounds awesome! Yes custom CSS and XHTML support would be great! All the ones out there are so blechhh…
Levi McCallum
on 21 Oct 08Anyway we can see a demo?
Quin Hoxie
on 21 Oct 08I put up an example at http://qhoxie.com/wysihat
I will update it if Josh changes them.
Gregor
on 21 Oct 08I’ve found only this demo: http://qhoxie.com/wysihat/
the examples from your git repository are not really functional, are they?
Josh Peek
on 21 Oct 08@Quin Thats totally fine if you want to post one of the examples.
I just want to note that WysiHat does not come with a full set of icons and buttons. Its a framework to build on top of. So the examples are kind of boring since they are just text :)
Janet Swisher
on 21 Oct 08Based on the name, I was hoping for a WYSIWYG Help Authoring Tool. The open source world needs one. Maybe someone can use this to build one.
Jake
on 21 Oct 08What I am wondering is why it was necessary to bind the whole project to a second language, Ruby. It seems pretty unnecessary, and annoying for anyone that does nothing with Ruby.
That said I am excited about having a wysiwyg editor that just works and generates valid xhtml.
Micah
on 21 Oct 08I’ll put this on my list to look at, right up there with markItUp!
Josh Peek
on 21 Oct 08@Jake The entire project is all javascript. I’m just using a ruby library to merge all the source code together. Once we have an actual release 1.0 (or whatever) there will be a single javascript you can just download, no building needed.
Your application does not have to be running Ruby. The only dependency is Prototype.
Quin Hoxie
on 21 Oct 08I update the example with some famfamfam icons to give an idea of the styling. Seems very promising.
http://qhoxie.com/wysihat/
Paul
on 21 Oct 08Why are you using prototype. Why not jquery? Just wondering, this is not criticism. I like the idea of this but i’ve wasted so many hours of my life with wysiwyg that I eventually gave up and used codepress.
Jake
on 21 Oct 08@Josh Peek That makes sense, I just didn’t want to have to install Ruby to check this out. But it looks like people are starting to get demo’s up and running, so that’s good.
I look forward to seeing how this develops.
Dmitry
on 21 Oct 08Prototype… That’s the problem with all this frameworks, it’s just too many of them – jquery, mootools, yui, prototype. And if you want to use something like wysihat on a site build primarily with jquery your user will have to download another pile of js scripts.
Thomas
on 21 Oct 08Best of luck trying to best what the FCKEditor guys are putting together with CKEditor 3.0.
Chriztian Steinmeier
on 21 Oct 08Ha! I read it like the editor “I wish I had” :-)
If this is good, I ‘m going to be veeery happy.
Josh Peek
on 21 Oct 08@Dmitry I see building on top of a framework as a huge advantage. Yahoo’s WYSIWYG and TinyMCE reimplement everything that Prototype or jQuery does, and they are massive. WysiHat is around 1000 lines while TinyMCE is around 11000 (yikes).
Dmitry
on 21 Oct 08@Josh Peek, you have a point there, i’ll definitively take a look at wysihat.
wesley
on 21 Oct 08I doubt that whysihat is as comprehensive and bug free (wysiwyg editors have lots of bugs/differences in diff browsers) as tinymce.
That said, I did hear that tinymce would release some sort of jquery/prototype wrapper modes…
Sam O
on 21 Oct 08Hey Josh Peek,
I would honestly suggest not bundling this project with any ruby/rails dependencies, its a JavaScript utility. I downloaded it and expected to double click on the examples and have it going but i get this “Opps, you need to build the package before running this example. Don’t worry its easy, just run rake in the project’s directory.“
John Topley
on 21 Oct 08@Paul Presumably Prototype is being used because it was invented by Sam Stephenson of 37signals’ fame.
Anders
on 21 Oct 08Playing with the included test/editor.html you seemed to have nailed it. Excellent cleaning of input and output. I gave up on WYSIWYG editors some year ago so I might have mist it, but last time I checked no other editor did this well.
Josh Peek
on 21 Oct 08@Sam see one of my previous comments. Since this is still under development, I do not want to have to rebuild a release on every commit. Once we hit a stable release you’ll be able to download a single file, no ruby requirements.
@Anders O you found a goodie :) Thats just a debugging editor your playing with. Yeah, I’m really focused on clean output.
Sam O
on 21 Oct 08Sounds good, really not an issue for me, just thought it might hinder general adoption. This seems like a winner. Great job!
Ian Bicking
on 21 Oct 08In my experience the really hard part of a WYSIWYG editor is making it a decent editor. This is really very hard. What do you do when you get a pre element in your code? How do you distinguish between paragraphs and brs? How do you handle entering and exiting lists, or lists with items that include paragraphs? How do you extend link text, or choose not to extend link text? How do you edit links usefully?
Incidentally, you don’t actually get to choose what HTML you get in your editor—the browser will happily insert any HTML regardless of your controls when you use cut and paste. Not to mention cut and paste from Word.
Admittedly lots of WYSIWYG editors make it harder than it should be to customize them. I think this is because once you start working with a WYSIWYG editor this seems like the least of your concerns. That’s not a smart choice, just the unfortunate direction many authors take. But recreating all the hard work in existing projects just to make them easier to customize is not a good idea, IMHO. Recreating all that hard work to have better encapsulized code that uses a library? That’s helpful. Recreating it to make different basic choices about the UI? OK. Recreating it because you are highly committed to creating a new and better experience and you are willing to put in the huge amount of time necessary? Great! If you do that, you should make it easy to customize so you can attract other developers. But customization as a driving goal seems unwise.
Greg
on 21 Oct 08We were just talking today about how we need a wysiwyg editor where you can control the markup, because we have hidden timestamp data behind our text. Sounds like wysihat might be what we need. Checking it out!
Jason Little
on 21 Oct 08When is this going to be implemented across your product lines?
Josh Peek
on 21 Oct 08@Ian I agree, nailing the editor proportion is the hardest part to get right. And thats the focus of WysiHat. Other editors seem to focus on giving you a ton of “widgets” to add to you toolbar. I think this should really be a design choice and not a decision enforced by the framework.
My issue with “customizing” tinymce was every was passed in as an option. So you had a big set of flags turn this off, this on, set this to that color, etc. WysiHat is about code. If you want to change the way a button looks, or how a piece of code behaviors, you can override that section and inject your own code.
Tom
on 21 Oct 08When are you guys going to let go of Prototype and move to jQuery? Seems kind of pointless to be hanging on like this.
Ben Hamill
on 21 Oct 08@Ian Bicking: “How do you distinguish between paragraphs and brs?” Easy. Nothing is a br. If they have multiple newlines, maybe insert an inline style that adds 1em of bottom padding to the previous p tag. Not all of the questions you pose are that easy, perhaps, but I really am not a fan of br.
Josh A.
on 21 Oct 08@Ryan Just because everyone else has failed, doesn’t mean you have to.
Sometimes people just don’t get it. Occasionally, it’s everybody that doesn’t get it. Maybe that’s the point where you give up. But giving up never solved anything.
What I don’t get is that all the WYSIWYG editors I’ve seen (I’m yet to look at WysiHat), are pathetic. They have file sizes, even when compressed with the GZip and the like, that make you presume they contain a collection of poorly compressed MP3s. Also, the code I’ve seen has often been poor, and extensive.
I’ve tried, and almost succeeded, in making a better WYSIWYG. It was for a web app which is currently on hold, but I seek to restart the project sometime.
I’m not saying that can do it better than everyone (anyone) else, just that all the other ones I’ve seen have been pretty shit.
And, on that note, other than its obtuse file size, NicEdit is pretty awesome.
Now, I’m sure from a usability perspective WysiHat will be great. Accessibility/markup-quality, I’m not so sure.
It probably is completely amazing.
It’s just that, as much as I respect you guys [37s], your track record on web standards isn’t exactly applaudable.
Anyway, thanks for WysiHat—I’ll have a look (yes, I realize how pathetic it is that I’m commenting before I’ve seen it), and I’m sure it’s better than I could ever do.
Andrew Dupont
on 21 Oct 08@Tom: I eagerly await your award-winning tome: The Frameworks Other People Should Be Using. While I’ve got you here… what should I have for dinner tonight? HIT ME BACK
Alex Rudloff
on 21 Oct 08Sweet. We’ve been using textile on emurse.com and I’m not that big of a fan. Would love to find a simple, streamlined wysiwyg framework to use instead.
Mike Harper
on 21 Oct 08A light editor built on jquery or prototype sounds like a great idea, but this seems to be the first steps in that direction, not a finished editor like others are hoping.
The main complaint I’d have is that someone can’t spell “oops” and the errors say “opps” everywhere.
Ian Bicking
on 21 Oct 08@Josh Peek: We (http://topp.openplans.org) settled on Xinha primarily because we felt it was the most pleasant to work with, as a user, on a day-to-day basis. Which to be honest means “least infuriating”. Unfortunately as an editor it gets very little attention compared to TinyMCE and others. Hopefully we’ll be able to change that, and making it clearer how you can customize it is part of that—customizability is by no means the hardest task or the most important to user experience, but it’s a barrier that drives off too many potential developers.
Xinha is also notable in that it’s one of the few mature WYSIWYG editors that has an open development process, and that was no small part of our decision process.
@Ben Hamill: I’m pretty sure it doesn’t work like that, you can’t just get rid of br’s. Most of a WYSIWYG editor is implemented in the browser. Sometimes the browser simply implements things incorrectly or in a nonsensical way. A lot of effort has to go into correcting this behavior. Also you really don’t get a choice of markup like people think you do. The WYSIWYG editor primarily operates on the DOM, though it can play around with text (most easily on save/load—modifying the text while someone is editing is likely to cause user-visible disruptions).
Inline styles are even worse, as the browser respects them in display but doesn’t offer a reasonable way to modify them. Hidden aspects to the markup are one of the most frustrating things to handle as a user—things display in weird ways for reasons you really can’t understand, based on structure that’s invisible to you.
Jens Alfke
on 21 Oct 08I may be pessimistic, but this strikes me as another case of gratuitous rewriting. Haven’t you guys written essays warning about this, or at least sagely linked to Joel Spolsky’s essay? The one that uses the Netscape/Mozilla disaster as an object lesson?
WYSIWYG HTML editing is really hard, especially considering the bugs and incompatibilities of the various browsers. I have yet to see an implementation that really works well at all, compared to a basic native editor like TextEdit. They’re all quite buggy.
Given that, a flexible UI isn’t tops on my list. It would be nice, since most of the editors look like Word knockoffs, but that’s secondary; by Maslow’s hierarchy of needs, we’re still at the food-and-shelter level with this stuff.
You guys are undeniably brilliant, but I wish you had made more effective use of your skills by working with one of the existing editors to make it more configurable, not to mention more stable. That way the world would have a good solid editor sooner. Instead, by this time next year we’re likely to have a couple of solid-but-ugly ones and one beautiful-but-buggy one. That would be a shame.
Jordan
on 21 Oct 08I’m kind of disappointed, 37s … while part of me wishes for a stable, useful, compliant WYSIWYG text editor to embed in applications (and I can’t think of anyone I’d rather see try and build one), another, far larger, part of me doubts one can exist.
The single biggest issue I’ve encountered with text editors is people copying and pasting from Word - this issue aside, I could count the number of mild-to-serious WYSIWYG problems on one hand - and I can’t imagine a point when the amount of effort required to overcome the Word factor is worth it, compared with saying to users: ‘don’t copy and paste from word’.
As Jens said: I’m sure that skills could have been made better use of elsewhere.
David
on 21 Oct 08Wow! So many negative comments! Half of them are from people who have never used ‘rake’, or suggest that we all migrate from prototype, so I guess we should take them with a grain of salt. But it’s disheartening to see so many reactions that are so… dismissive and negative. “I’m kind of disappointed”?! “I wish you had made more effective use of your skills”?? I would hope the first reaction would not be, “man, you guys are dumb and wrong,” but, “hmm, that’s not what I would have done, maybe they know something I don’t.”
Anyone who doesn’t know why this is a great idea has never:
A) grudgingly and very sadly added one of the existing editors to your project, B) tried to add a button to one of the existing editors, or C) looked at the code of one of the existing editors (hoping to make some changes), and shuddered. ...not at the complexity, but at the code itself.
As an aside, this is one of those issues where the browsers themselves (ff & webkit, not much hope for IE) need to take some initiative—it is a question of interaction with the OS, after all. Some onpaste event would be a start, or even a onpastewordjunk event?
Steve R.
on 21 Oct 08At the risk of getting lynched by all the designers out there, am I the only one wondering why WYSIWYG in an online tool, to be run in a browser (I assume) is a desirable thing? ‘Pretty printing’ is fine as far as it goes, but really – why in a browser-based app? I’m picturing all kinds of practical applications that look terrible because users will try to be ‘creative’ and then go nuts trying to undo bad layout and design decisions. Give them defaults, let ‘em export to OpenOffice if they’re making something too fancy for a nice, clean, well-conceived preset.
Maybe I’m an idiot who is not understanding what this is all about… if you haze me, please enlighten too.
Andrew Brown
on 21 Oct 08Thats cool your trying to cut a new clean path for WYSIWYG editors, I’ve been thinking of building one after frustration with the current selection out their.
I downloaded it from GitHub but it doesn’t work straight out of the box. I guess its still underway?
Tim
on 22 Oct 08Ignore the naysayers Josh! Building a framework based WYSIWYG editor makes tremendous sense. Look forward to seeing it.
Wes Winham
on 22 Oct 08I’ve personally found WYMeditor to be absolutely wonderful. The big issue I had with tinyMCE was editing a file that had already been edited a couple of times (it got very very messy). WYMeditor keeps it stripped down so that I can use the stylesheet to do all of the real styling and let the author focus on the content.
popupchinese
on 22 Oct 08We teach Chinese at Popup Chinese and will give this a shot in our lesson creation system. The existing javascript editors we’ve tried all have problems with simple things like setting sizes across browsers. But our teachers want WYSIWYG.
There’s room for a small, lean and – frankly – easier solution. Best of luck with the project. If it works for us we’ll be contributing code.
wuputah
on 22 Oct 08I really look forward to the future work. A WYSIWYG done by 37s can only mean good things, and I look forward to using it in future projects. A lot of clients like to use a WYSIWYG editor and although they are usually happy with TinyMCE, we often run into problems when using it. TinyMCE definitely has that “de facto standard” feel – just like Internet Explorer (or Windows in general), there is definitely room for improvement.
I wish you best of luck dealing with browser compatibility, though. Although, the fact you’ve dropped support for IE6 might help a lot.
Kennon Ballou
on 22 Oct 08@David: That was exactly my initial reaction too! I had to use TinyMCE on a site in the past and trying to customize it was about like driving nails into my skull. It works great if you want it to look exactly like they have it, but if you want to customize it, look forward to spending hours and hours editing javascript and css files
WysiHat is pretty much exactly what I’ve needed for years now, a minimal, easy to customize WYSIWYG javascript editor. Looking forward to seeing what gets done with it!
Mathias Biilmann Christensen
on 22 Oct 08At Domestika (Domestika.com/Domestika.org) we just open sourced a script we use to handle the typical word copy/paste problems.
It’s a very strict XHTML Purifier based on the algorithm specified in the HTML 5 draft for parsing HTML.
It will take messy word HTML and turn it in to nice, pretty printed, well nested XHTML.
It only knows the tags that we’ve found it interesting to let our clients use in their website content, so it’s not a solution if you want to give a lot of freedom in the HTML editing, but for the typical case where you want a simple WYSIWYG editor for doing bold text, links, images and the like, it’s very handy indeed.
The source is up on GirHub: http://github.com/biilmann/javascript-xhtml-purifier
Jason
on 22 Oct 08This is about the dumbest idea you guys have come up with to date. There are a plenty of editors already. None of which are perfect but some are pretty close and come on, seriously, it isn’t like they are that hard to implement. Whatever. Go nuts.
Matthew
on 22 Oct 08Glad you’re attempting this!
What i would REALLY, REALLY like is a core library which just does the absolute bare minimum to support a plain contentEditable area cross-browser in a non-buggy fashion.
Nevermind the toolbars, buttons, widgetry, plugins, etc – those can be added ontop of the core library if desired.
Just something which contains all the nasty workarounds required to get a basic bare-bones contentEditable area working (and behaving consistently) cross-browser and outputting clear, consistent XHTML, in one place.
Then people can build whatever sort of UI they want ontop of it, without having to battle through the horrific bloated codebases of TinyMCE, FCKEditor etc. (which, incedentally, still don’t quite manage to work around things like cursor positioning bugs, consistent behaviour when it comes to return keypresses and paragraph vs line breaks)
Terry Sutton
on 22 Oct 08Got so sick of having to edit TinyMCE and FCK output that I switched to Markdown. Its awesome. Definitely not what you see ….but definitely dependable and way less hassle.
diarmuid ryan
on 22 Oct 08i’ve been using TinyMCE for long time but looking to change. This looks promising to move to
RichardA
on 22 Oct 08@Jason
I disagree completely. Nothing out there is even close to being close! TinyMCE and FCK are terrible. The only usable RTE I can think of is in GWT, versions of which you can see in Gmail and Google Sites.
I’m very interested to see what comes from this as well as seeing the CKEditor rewrite (FCKeditor version 3).
sun
on 22 Oct 08Like previous commenters, I would highly recommend to wrap all functions native to Prototype in stub functions. That way, you leave the way open to add compatibility with jQuery and other libraries. For example, if Prototype is a hard dependency, almost the complete Drupal world will not be able to use this editor.
If you cannot work on stub functions yet, consider to store Prototype in a non-conflicting namespace (i.e. similar to jQuery’s noConflict(), or, simply avoid usage of the $() shorthand).
Also, previous commenters “heard” right – TinyMCE 3.x started to ship with alternative wrappers (including jQuery and Prototype) to reduce the overall code-size and avoid re-implementing library functions that are already available. Not yet stable though, but definitely a wise step.
Good luck! Let’s hope I’ll be able to add WysiHat to Drupal’s Wysiwyg API some day.
Morley
on 22 Oct 08I haven’t looked at the code yet, but I’m wondering if there’s plans for automatically cleaning up Word HTML? It’s by far the worst AND most persistent issue I’ve run into with any WYSIWYG editor.
TinyMCE has a “paste from Word” feature, but users (at least the ones who paste from Word) rarely use it.
Tim Molendijk
on 22 Oct 08It would be awesome if WysiHat would end up being the first online WYSIWYG editor that doesn’t give you major headaches.
But I must say I’m skeptic. The problems with current WYSIWYG editors are actually not so much a result of flawed or outdated coding or architecture, but rather of browser differences… the same issue after all these years.
Just take a look at TinyMCE 3. It actually has a very elegant and clean architecture. The source is very readable and customizability is decent. Yet the editor has many major and minor glitches. Nevertheless I consider it the best editor out there at this moment. And it certainly has the right firmaments to get better in the future.
Nevertheless I’m looking forward to see what WysiHat will bring to this game.
Derek Scruggs
on 22 Oct 08Nice to see competition in this space. In my world, the biggest killer is pasting in text from Word. Whoever figures out how to make that work transparently without requiring you click a special paste-from-Word icon should be nominated for the Nobel prize.
Yeah, Word sucks, but it’s also pervasive, so we have to man up and deal with it.
Josh Peek
on 22 Oct 08For all those who did not want to install ruby to play with WysiHat, I decided to release a packaged 0.1 release. These releases will be less frequent, and if you want use the “edge” version or submit patches you going have download ruby.
Any tagged release will be packaged and posted on this page. http://github.com/josh/wysihat/wikis/download
David
on 22 Oct 08I’m torn on the idea, myself. On one hand, I have used almost every WYSIWYG editor out there, and all of them are cumbersome to implement and nearly impossible to configure to perfection. It would be great to have one that provides the bare minimum, and allows you to plug in only the needed functionality, with solid output at every point.
On the other hand, I have since taken a stand on minimality. Put simply, people don’t NEED to do much in text formatting. When they do, Textile is not difficult to learn for the basics (headers, bold/italic, images). To me, this is something that 37s should agree with. It’s weird that they would consider adding “fluff functionality” to otherwise great products. In the end, 37s products are about simplifying communication. However when someone replies to a comment in all pink italic 44pt text, the communication becomes much less simplified.
What I think would be the best idea is to allow each project manager to define custom styles that could then be used within Textile. Then, styles could be defined that support each project’s needs, without resorting to these irrelevant complicated editors.
Yan Pritzker
on 23 Oct 08My hat is off to you guys (no pun intended). The existing solutions range from ugly to pure evil. I hope this one has the 37s flavor of simplicity and cleanliness that we’ve come to expect ;-)
Matt
on 23 Oct 08To my mind, WYSIWYG is a step backwards. For several reasons. 1. Because it encourages users to post really ugly stuff. 2. Because it only deepens addictions to bad software like MS Word. 3. Because it brings back bad memories of church bulletins from the 1990s. 4. Because it reminds me of colorful emails with italics and big old wacky fonts and birthday cakes and droopy eyed dogs that my boss used to send to our department. 5. Because it prevents wikis and LaTeX and vi from taking over the world. :-)
Arik Jones
on 23 Oct 08Like many have said, it’s great that 37s is breathing some life into the space. The problem with Wysiwigs is they do to much. Word docs don’t translate well on the web for a reason, word docs and web pages serve very different purposes.
Look at it like this; Would you expect that Saab allow engines from H3 Hummers be seamlessly popped in with no headaches? Certainly not. So I think Wysiwyg editors in the context of form controls on the web should be as bare as possible, leaving only the most basic options (which Wysihat sets out to do). The rest is really up to you and Wysihat doesn’t impose that you should follow only ONE way to get there.
Anonymous Coward
on 23 Oct 089ok
Tom Vretberg
on 23 Oct 08As someone noted above, TinyMCE has been testing using adapters for JQuery and other libs, but the overall gain in size is not as much as you might think, it’s in the order of 5-10kb for a 160kb of TinyMCE script. There just isn’t much css querying going on, if it gets implemented eventually, it will probably only be to silence the hype.
The things that take space is the browser normalization, as well as functionality and output formatting/control, seems like this wysiwyg “editor” has either of that.
If you want to check out customization, check out Squarespace.com and their implementation of TinyMCE, they got rid of the UI and are using the engine only, thanks to the nice API docs.
The TinyMCE devs also release PunyMCE (google it) that is a bit more similar to this editor, stripped down, no output formatting (handle it with backend code), easy to customize etc.
damndom
on 23 Oct 08I like mooeditable better…
http://cheeaun.com/projects/mooeditable/examples/default.html
andjules
on 23 Oct 08@matt your frustration with WYSIWYG editors, while shared by many, is misplaced. That frustration is with lazy developers (not customizing/limiting the editor’s functions) and tasteless users (not all users are tasteless, but those who are…)
I predict 37signals implementations will probably be limited to bold, italics and perhaps a few others – maybe lists, maybe pics (unlikely). The point is, your use case determines the appropriate level of formatting.
Textile (which 37signals currently uses) was developed by Dean Allen, an expert on tasteful text formatting; and he baked appropriate formatting into Textile. The only problem is the syntax… I’m never going to teach my mom to use it, and 37signals is never going to teach thousands of customers to use it.
Sunny
on 23 Oct 08Thanks ! An itch was there to scratch and you’re scratching it the right way. Please do reinvent the wheel when others are too square.
Kaanon
on 23 Oct 08I for one, like it. I’ve long been of the opinion that users need only a few options. Bold, Underline, Italic and a few others are really the most necessary.
Lunés
on 24 Oct 08Unfortunately WYSIHAT does not respond to a linux style middle click to insert the clipboard into the “textbox”. Is this even possible?
omtv
on 25 Oct 08Obviously 37signal is a great company! Thanks for sharing.
Ian Taylor
on 28 Oct 08Josh,
Thanks for taking up the “simpler text editor” fight. Most WYSIWYGs are way too complicated, bloated, and buggy. Somebody’s needed to start a project like this for a long time. On one of the last projects I worked a solid 50% of the bugs filed against the project had to do with formatting bugs in the WYSIWYG, and the code was so complex that fixing them was often out of the question. Having a stripped down editor that does less but does it better is just what the doctor ordered.
My only request is that you keep it developer accessible and hackable (it looks like you’re on that path already). Thanks again.
This discussion is closed.