IRC 2007/02/07

16:04 < lewiscot> Salut.
16:04 < jfh> Hello!
16:04 < lewiscot> Ca va?
16:04 < bens> Hello.
16:04 < jfh> Hello Ben!
16:05 < jfh> How are you?
16:05 < bens> Enjoying a cold English afternoon.
16:05 < lewiscot> Hey Ben.
16:05 < lewiscot> So a typical day in England, eh?
16:05 < bens> Colder than most.
16:05 < jfh> It's cold too in Belgium.
16:06 < jfh> Daniel is busy for the moment, with a customer.
16:06 < jfh> I think he'll back in 5-10 minutes.
16:06 < bens> Has everyone got a copy of the notes I wrote this morning?
16:06 < lewiscot> -2C here today.
16:07 < jfh> Daniel and myself received them.
16:07 < lewiscot> I have them.
16:07 < lewiscot> JF sent them to me.
16:07 < lewiscot> I have been working on some very similar ideas.
16:08 < bens> I tried playing with designMode and contentEditable, but it seemed to me that I would have to write one editor per browser, and still not support everything after all that hard work.
16:09 < jfh> Yes, it's really hard.
16:09 < bens> So I wondered whether it would be more work to make an editor out of the bits which are supported by all browsers.
16:09 < bens> I suspect it might be less work, have a higher quality result, and be a more interesting bit of work.
16:10 < bens> Writing proper code, rather than bodging around browser bugs and all.
16:10 < bens> And more maintainable, less likely to break in the next version.
16:11 < jfh> I agree. You use some fun hacks though.
16:11 < bens> Fun hacks?
16:11 < jfh> IE the spans
16:11 < bens> It was the first bit of serious js I've ever written. I've done much more since.
16:11 < bens> Oh, those. Yes, couldn't think of any other way to do it.
16:12 < lewiscot> Ben, take a look at
16:12 < bens> Not really a hack though; it's just using supported stuff in a way it wasn't intended to be used.
16:12 < lewiscot> This is a solution I came up with for keeping the code for different browsers separate and reducing the number of if (ie) else if (moz)...
16:13 < bens> You still have to write all the code paths though.
16:14 < jfh> OK. I like Scott's idea - using factory design.
16:15 < lewiscot> As I see it, there are 3 big benefits to using a factory pattern:
16:16 < lewiscot> 1. The code is more maintainable. As browser issues change, only the code for that browser must be changed.
16:16 < lewiscot> 2. Less code is executed when a page loads (fewer if/else statements)
16:17 < lewiscot> 3. The task of writing code for each browser can be delegated to a different developer
16:17 < lewiscot> For instance, I can concentrate on writing the code *only* for safari rather than trying to simultaneously debug each function for FF, IE, Safari and Opera.
16:18 < jfh> Ben, do you know that technique?
16:18 < bens> Sounds like a standard OO design pattern.
16:19 < lewiscot> Yes
16:19 < bens> In C++ you would define a base class with pure virtual functions, implement them in derived classes.
16:19 < bens> This is quite similar.
16:19 < jfh> Yes.
16:19 < lewiscot> Yes, that is where I got the idea
16:19 < bens> It might be easier just to redefine functions in the JS, rather than using factories.
16:20 < lewiscot> Another benefit will come in testing. It will not be necessary for JF to finish his code, for instance, in order for me to test mine.
16:20 < lewiscot> Can you explain.
16:20 < bens> var browserhacks = {};
16:20 < bens> if(mozilla)
16:20 < bens> {
16:20 < bens> browserhacks.do_nasty_stuff = function() { ... }
16:20 < bens> }
16:20 < bens> else if(safari)
16:20 < bens> {
16:21 < bens> browserhacks.do_nasty_stuff = function() { ... }
16:21 < bens> }
16:21 < bens> ...
16:21 < bens> Then call browserhacks.do_nasty_stuff()...
16:21 < lewiscot> Oh, I see. Same effect, but different technique.
16:21 < bens> Yes. Depends on which has the nicer syntax.
16:22 < lewiscot> Absolutely. Whatever is simpler is usually better.
16:23 < lewiscot> Ben, can you explain a little bit about the reason for using a lot of spans? I'm not questioning the technique, I just don't quite understand.
16:24 < bens> Hit detection. When a click event is captured, you need to know exactly which character has been clicked on so you can position the caret.
16:24 < bens> Unless I am missing something blindingly obvious, there is no other way of doing this.
16:25 < lewiscot> So it is a way to not have to deal with window.getSelection(), document.selection, etc?
16:25 < bens> In the case where the user has not selected any text, there is no selection.
16:25 < bens> Remember, the browser is not aware the text is being edited, and does not help in any way.
16:25 < daniel> hi ben, hi scott :)
16:25 < lewiscot> Hi Daniel. Ca va?
16:26 < daniel> ça va très bien merci - sorry for the interruption,please continue
16:28 < jfh> But you use a textarea, don't you (or maybe I missed something)?
16:28 < lewiscot> Ben, Doesn't the window record the offset position even if the selection length is 0? I know Mozilla does. I don't know about IE though.
16:29 < lewiscot> While I am thinking about it, I have written a good debug tool for jQuery. You can download it at
16:29 < bens> Are you talking about in a designMode or contentEditable?
16:29 < jfh> In IE, I use a little hack to get the caret (in the editor though)
16:29 < lewiscot> No. It works in normal mode.
16:29 < lewiscot> It works in Safari also.
16:29 < lewiscot> The debugger I just sent you a link to is used like this:
16:30 < lewiscot> If you want to view the properties and methods of (for instance) the Window object, just call $.ShowObj("name", window);
16:30 < lewiscot> It will open a new window and print out the complete object.
16:31 < bens> Mayve that's the blindingly obvious thing I've missed.
16:31 < lewiscot> Also, $.log() allows you to automagically add a textarea to the document.body and log the results of each event.
16:31 < lewiscot> It is a very useful tool.
16:32 < lewiscot> Ben, I will post my selection tests later today so you can download them and take a look.
16:33 < lewiscot> Here is an example result from $.ShowObj():
16:33 < lewiscot> It also shows the selection offsets:
16:33 < lewiscot> window.getSelection():
16:33 < lewiscot> [QueryInterface]=>function QueryInterface() {
16:33 < lewiscot> [native code]
16:33 < lewiscot> }
16:33 < lewiscot> [anchorNode]=>[object Text]
16:33 < lewiscot> [anchorOffset]=>10
16:33 < lewiscot> [focusNode]=>[object Text]
16:33 < lewiscot> [focusOffset]=>14
16:33 < lewiscot> [isCollapsed]=>false
16:33 < lewiscot> [rangeCount]=>1
16:33 < lewiscot> [getRangeAt]=>function getRangeAt() {
16:33 < lewiscot> [native code]
16:33 < lewiscot> }
16:33 < lewiscot> [collapse]=>function collapse() {
16:33 < lewiscot> [native code]
16:33 < lewiscot> }
16:33 < lewiscot> [extend]=>function extend() {
16:33 < lewiscot> [native code]
16:33 < lewiscot> }
16:33 < lewiscot> [collapseToStart]=>function collapseToStart() {
16:33 < lewiscot> [native code]
16:33 < lewiscot> }
16:33 < lewiscot> [collapseToEnd]=>function collapseToEnd() {
16:33 < lewiscot> [native code]
16:33 < lewiscot> }
16:33 < lewiscot> [containsNode]=>function containsNode() {
16:33 < lewiscot> [native code]
16:33 < lewiscot> }
16:33 < lewiscot> [selectAllChildren]=>function selectAllChildren() {
16:33 < lewiscot> [native code]
16:33 < lewiscot> }
16:33 < lewiscot> [addRange]=>function addRange() {
16:34 < lewiscot> [native code]
16:34 < lewiscot> }
16:34 < lewiscot> [removeRange]=>function removeRange() {
16:34 < lewiscot> [native code]
16:34 < lewiscot> }
16:34 < lewiscot> [removeAllRanges]=>function removeAllRanges() {
16:34 < lewiscot> [native code]
16:34 < lewiscot> }
16:34 < lewiscot> [deleteFromDocument]=>function deleteFromDocument() {
16:34 < lewiscot> [native code]
16:34 < lewiscot> }
16:34 < lewiscot> [selectionLanguageChange]=>function selectionLanguageChange() {
16:34 < lewiscot> [native code]
16:34 < lewiscot> }
16:34 < lewiscot> anchorOffset is the selection start, focusOffset is the selection end. If the numbers are the same, no text was selected but you know the caret pos.
16:35 < bens> (Sorry, phone call)
16:35 < jfh> OK. I think it's Gecko specific, though.
16:35 < bens> Seen Firebug?
16:35 < lewiscot> Yes, that example is but it works similarly in Safari.
16:35 < lewiscot> No, I haven't. Is it a JS debugger?
16:36 < bens> Yes, and it is absolutely wonderful.
16:36 < bens> Breakpoints and everything.
16:36 < jfh> I agree.
16:36 < lewiscot> I will check it out. Thanks.
16:36 < bens> From my playing with selection in other contexts, I suspect they're going to be unreliable if the aim is to work in "any" browser.
16:36 < daniel> I use it all time, ... but for CSS development wonderful also.
16:37 < lewiscot> Download the debugger and pass it "window.selection" or createRange to see the results.
16:37 < lewiscot> I don't know what it will show but it seems there has to be a way - at least there should be a way (but it is MS after all).
16:39 < lewiscot> Ben, have you seen this:
16:40 < bens> Yes. I like that site. :-)
16:40 < lewiscot> That guy is a rock star. The best JS developer I've ever seen.
16:40 < lewiscot> So what happens in IE when you call document.selection.createRange()
16:41 < lewiscot> Does it return "undefined" if no text is selected?
16:41 < daniel> it works in IE
16:41 < bens> See the thing is that you're enumerating results in browsers, but as soon as something new comes along, it's broken.
16:41 < daniel> it seems to return nothing when no text is selected
16:42 < lewiscot> If no text is selected, does it return a null value or a selection object with a zero length?
16:42 < lewiscot> Ah, you just answered that question. Sorry.
16:43 < bens> The advantage of the "do it all yourself" approach is that it's very difficult for a browser to break your code.
16:44 < bens> In my structured editing code, there are no browser conditionals. There are a couple of extra lines of code to work around Safari bugs. But no use of different implementations of similar concepts.
16:44 < bens> And that's why I feel the approach has merit.
16:44 < lewiscot> I understand.
16:45 < jfh> And what about using a *visible* textarea?
16:45 < jfh> Thus editing in it?
16:46 < jfh> please take a look at branches/jf.hovinne/test/014/
16:46 < bens> Not very elegant. Difficult to do bold and other character based styles.
16:47 < bens> Also doesn't smoothly fill the page; nasty hacks or user has to scroll.
16:48 < lewiscot> Ben, how much code is required for you method? Does it require a lot of code, in other words?
16:48 < bens> 014/ -- interesting concept; could be done with replacing the text you clicked on.
16:48 < bens> You've looked at my example, have you?
16:48 < lewiscot> I didn't look at the code.
16:49 < bens> I suspect that, done carefully with a good design, it's going to be about the same as supporting the big three.
16:49 < lewiscot> I have been very busy and just did not have time. I'm trying to roll out a CMS implementation for a client.
16:49 < lewiscot> Ok.
16:49 < bens> Yet has far better browser compatibility, cleaner code, and better user experience.
16:49 < bens> (CMS sounds fun!)
16:50 < bens> There's not all that much code really. If I had done one char per span there would be much less.
16:50 < lewiscot> Yes. It is. I implemented version 0.2 of WYMeditor with it yesterday.
16:50 < bens> The fun will be doing selections and undo/redo.
16:50 < jfh> Ben, please take a look at 007, too.
16:50 < jfh> I agree, the problem is markup...
16:50 < lewiscot> Ben, do you insert the spans on pageload
16:51 < bens> 007 -- again, the problem is that it's not like the user expects in MS Word.
16:51 < lewiscot> what is the link to your example?
16:51 < lewiscot> I will look at the code now while we chat
16:51 < bens> spans -- I do them when the user clicks, using a binary chop algorithm
\ 16:51 < bens>
16:51 < lewiscot> thanks
16:51 < bens> But I think the variable length spans just make things difficult.
16:53 < bens> (making a selection breaks the current code)
16:55 < jfh> FYI: in designMode, Gecko always add a <br> in empty elements.
16:55 < lewiscot> Yeah, I noticed that. Nasty.
16:56 < jfh> Maybe this could solve the cursor positioning problem...
16:57 < jfh> "a dummy element at the end of every paragraph"
16:57 < lewiscot> Hm. Interesting.
16:58 < lewiscot> JF, I really like the way you dynamically add IDs to all the images. Very useful.
16:58 < bens> See notes about right or left in cursor position in notes I sent.
16:58 < lewiscot> BTW, I expanded the dialog that handles the image double-click event so the user can add a className and can resize the image based on dimensions or scale.
17:00 < jfh> Yes, I saw that. Good work!
17:00 < lewiscot> Thanks.
17:00 < lewiscot> Do you like the PopUps?
17:00 < lewiscot> Has the benefit of avoiding popup-blockers.
17:01 < jfh> The 'overlays'?
17:01 < lewiscot> Yes.
17:01 < lewiscot> I took the technique from jquery.thickbox.js
17:01 < bens> Which version are you looking at? Sounds like some fun going on there!
17:01 < jfh> Yes, that's a good idea.
17:02 < lewiscot> We are talking about my implementation of WYM.
17:02 < bens> ta
17:02 < lewiscot> You may need to refresh your browser after loading it the first time.
17:03 < lewiscot> JS tries to init the editor before the content is loaded. I've implemented a hack - setTimout("init()", 1000) - to get around it. Not elegant but it works.
17:04 < bens> Looks very different in Safari to FF!
17:05 < bens> Very nice!
17:05 < lewiscot> Yes. I have not debugged in Safari yet. WYM does not support Safari so it doesn't really matter except that some fallback behavior needs to be added.
17:05 < lewiscot> Thanks.
17:07 < lewiscot> JF - in safari, clicking a button causes the selection to be lost. I just realized that Ben's solution will fix this.
17:08 < lewiscot> A click event could be added to each span and a reference to it stored for the event handler.
17:08 < lewiscot> That may be the best place to start on Safari compatibility - if Ben does not mind our using his code :-)
17:09 < bens> I'm quite keen on getting a working editor; of course you may use my code!
17:10 < lewiscot> For the time being, we could also only add the spans in Safari. This is not the ideal solution but I think it is probably better to not change the existing version any more than possible (more testing, debugging, etc) until the next major version release.
17:11 < lewiscot> Here is what I propose as next steps (just a suggestion):
17:11 < lewiscot> - Start writing use scenarios
17:11 < lewiscot> - Decide on a core set of features/behaviour
17:11 < lewiscot> - Collaborate on the high-level design
17:12 < lewiscot> - Decide on list of functions, naming, coding style, etc.
17:12 < lewiscot> - Each of us do the necessary proof-of-concept work for the unknown aspects
17:13 < lewiscot> - Decide on the approach (JF's 14, 07 - Ben's technique)
17:13 < lewiscot> - With that work done, the actual coding should be a lot easier
17:14 < lewiscot> - Then the fun part - testing
17:15 < lewiscot> Thoughts?
17:16 < bens> If you go with my approach, then this will really affect the design. So you might want to choose the technique earlier.
17:17 < lewiscot> Good point.
17:17 < jfh> Yes, I think we need to test different techniques.
17:18 < bens> Sounds like it would be a good plan for all of you to give my code a good going over, and see what you think of the technique.
17:18 < bens> It's going to be annoying writing a full text editor, with all that implies.
17:18 < lewiscot> I guess item 5 should really be item 3.
17:18 < bens> But it will give the project something unique; totally cross-browser, future proof, and total control over how it looks and behaves.
17:20 < daniel> ben: i think it depends on the fact if it will be possible to nest elements or not
17:21 < lewiscot> Ben, I really like the tool menu that pops up when an item is clicked. Very nice. I like the fact that less browser space is used for toolbar. What do you think of positioning the tool menu based on the cursor position so the user does not need to move the cursor very far?
17:21 < bens> Can you be more specific?
17:21 < lewiscot> Just a thought - maybe a bad one.
17:21 < bens> tool menu -- what I meant by unobtrusive UI.
17:21 < lewiscot> Yes. It is very nice.
17:22 < daniel> you said that nesting elements (strong, ems, ...) is difficult with this technique
17:22 < bens> nesting elements: I think that 'anything' is possible if it can be done in the DOM.
17:22 < bens> Oh, I see.
17:22 < bens> It is possible, but it increases the complexity of the algorithms to manipulate the elements.
17:22 < bens> But if that's a required feature, then it's not _that_ bad.
17:23 < lewiscot> Ben, what happens if the DOM already has spans in it?
17:23 < bens> Think when you have <b>some <i>textCURSOR more</> text</b> and the cursor is at CURSOR and the user inserts a line break... you have to fiddle about quite a bit to get proper markup.
17:23 < bens> spans -- yes, currently that is a limitation.
17:24 < lewiscot> Can this be worked around by assigning a className to the spans used for editing?
17:24 < bens> Another techinque is to use lots of text nodes without the span around them. I'm not 100% sure it'll be as good in all browsers, using spans does make it difficult for the browser to screw things up by being clever with concatentaiton.
17:24 < bens> Yes, you could use a classname at the expense of efficienty.
17:25 < lewiscot> That way, when they are manipulated or cleared only spans of "editorSpan" class are operated on.
17:25 < bens> Or, you could CSS-away the boldness of 'b', and use that instead.
17:25 < bens> Obviously we're doing semantic markup, so b isn't used.
17:25 < daniel> from a "web designer" perspective, i have to say I am satisfied of current version of WYMeditor, except the fact it doesn't support custom span elements, nor nesting of block elements (divs), and some other details like integration and popups, both resolved by JF and scott.
17:26 < lewiscot> How much efficiency is lost?
17:26 < bens> extra clause in your if statements when scanning nodes.
17:26 < bens> Probably not noticable.
17:26 < lewiscot> It might be worth considering if the benefit is great enough. That is unknown at this time.
17:27 < lewiscot> Daniel, I think the DIV issue can be gotten around.
17:27 < bens> Daniel -- my concern with WYMeditor is the browser support and what happens in the future.
17:27 < bens> It is not a universal solution; none of the rich text editors are.
17:27 < lewiscot> True
17:27 < bens> It would be nice to create somethign which is that universal solution, and is future proof.
17:27 < daniel> of course Ii agree
17:27 < lewiscot> I used TinyMCE for a while but it is so damn big it just isn't very useful.
17:28 < bens> I was amused by the 'tiny' in the name too.
17:28 < daniel> :p
17:28 < lewiscot> Yes - very ironic
17:28 < lewiscot> 5-6MB. If that is what they consider tiny, I would hate to see "large"
17:29 < lewiscot> My CMS - SkyBlue Canvas - is only 2.5MB so the text editor was 2X the size of the CMS.
17:31 < jfh> OK. I propose to continue the discussion on the dev wiki. Ben: I'll send you the URL.
17:31 < lewiscot> JF - after I got WYM hooked up to SkyBlue last night, it worked like a champ. All I needed to do was copy/paste my existing HTML in place and - voila, ca marche!
17:32 < jfh> C'est chouette :)
17:32 < lewiscot> By adding the className feature to the image details, I did not need to change anything about my existing content or styles.
17:32 < lewiscot> chouette = cool?
17:32 < jfh> Yep
17:33 < lewiscot> For a second I thought you wrote "chiotte" - completely different meaning :-)
17:33 < daniel> lol
17:33 < jfh> Yes, I agree.
17:33 < lewiscot> LOL.
17:33 < jfh> We should say: "c'est de la chiotte".
17:34 < lewiscot> That's the shit?
17:34 < jfh> That's shit.
17:34 < lewiscot> Ah, quite the opposite, n'est ce pas?
17:34 < lewiscot> Ben, do you speak any French?
17:35 < bens> I can read and get the meaning, most of the time, but speaking or listening or writing... I'm such a typical englishman in that regard.
17:35 < lewiscot> I have a hard time understanding when I hear spoken French but I can read, write and speak pretty well.
17:35 < lewiscot> NOT a typical American in that respect. :-)
17:36 < jfh> Yes, you write pretty well...
17:36 < daniel> ... JF told me you come regularly in Paris to seduce French women :)
17:36 < lewiscot> LOL!
17:36 < daniel> ok that's not exactly what he said
17:37 < lewiscot> Seulement un fois.
17:37 < jfh> (une)
17:37 < lewiscot> Elle s'apelles Delphine Ballard - tres belle.
17:37 < lewiscot> Thanks
17:37 < lewiscot> Elle s'appele
17:37 < lewiscot> ?
17:38 < jfh> Elle s'appelle. Is she "Ma biche?"
17:38 < lewiscot> Oui.
17:38 < daniel> :-P
17:38 < lewiscot> Il y a une autre qui s'appelle Cecile Didry. Aussi tres belle.
17:38 < jfh> So they both live in Paris?
17:39 < lewiscot> Yes
17:39 < daniel> please don't come to belgium, you'll seduce all the girls
17:39 < lewiscot> I think Delphine may live in Boston US now. I'm not sure.
17:39 < jfh> Ah ok. Daniel is frightened.
17:39 < lewiscot> Ont-elles belles?
17:40 < jfh> Belles, belles, belles comme le jour.
17:40 < lewiscot> J'arriverai demain.
17:40 < jfh> Mais pas toutes.
17:41 < lewiscot> comment on dit - "German women"
17:41 < daniel> JF: stop ! Why did you tell him that ?
17:41 < daniel> Scott: no they are awful... don't come ;)
17:41 < lewiscot> Mentuer!
17:41 < lewiscot> Menteur!
17:42 < jfh> Pas du tout. German women: Allemandes
17:42 < lewiscot> J'aime beacoup les Allemandes aussi - lesquelles de Berlin.
17:42 < daniel> ok, when you will come to paris next time, please consider coming to belgium, we will introduce you to our best "blondes" and "brunes"
17:43 < daniel> beers of course
17:43 < lewiscot> of course!
17:43 < jfh> Bières d'abbayes.
17:43 < jfh> delicious
17:43 < lewiscot> Ben, you still there?
17:44 < lewiscot> Want to join us in Paris for beers and blondes?
17:46 < jfh> Ben?
17:46 < lewiscot> I guess he got tired of the French and left.
17:46 < lewiscot> Ok, let's wrap up the business portion: what should we do next and when should we meet again?
17:47 < lewiscot> I am going to spend some time this weekend looking over and working with Ben's code.
17:47 < daniel> I'll have to go now, thank you for this very interesting irc session, I'll let you finish without me
17:47 < jfh> I propose to use the dev wiki
17:47 < lewiscot> Ok, a bientot Daniel.
17:47 < bens> Is there anything I should be doing to help? Apart from answering questions?
17:48 < jfh> Ben: I need more time to understand your code
17:48 < lewiscot> I will send post a copy of my implementation of WYMeditor for everyone to look at. We should be familiar enough with one another's code to talk specifics and evaluate what works and what does not.
17:50 -!- daniel has left #wymeditor [daniel]
17:51 < jfh> OK. Ben: I want to fully understand how Structured Editing works - technically.
17:52 < lewiscot> JF: I think the first order of business - the most important next step - is to turn WYMeditor into a completely portable, dynamically loading and easy-to-implement plugin using the current version.
17:52 < lewiscot> I will post my code to the svn server sometime today so we can work off of that.
17:53 < lewiscot> I will need your help cleaning up the code. I duplicated a few of your functions so that will need to be cleaned up.
17:53 < lewiscot> We will also need documentation for how to implement the editor in third-party apps.
17:53 < jfh> OK. 013 was my first attempt to implement "a completely portable, dynamically loading and easy-to-implement plugin
17:54 < jfh> But I like Ben's approach, too
17:54 < lewiscot> Let's compare 013 and my code and go from there.
17:54 < lewiscot> Oh - by portable I mean that it can be integrated with any third-party application.
17:55 < jfh> 013 is based on jQuery, is already a plugin, and is compatible with MSIE/FF/OP
17:55 < jfh> I've looked at Safari's code and they have implement (un)ordered lists
17:55 < jfh> But not links, I think
17:56 < jfh> Ben: I speak about designMode
17:56 < jfh> The execCommand stuff
17:56 < lewiscot> May suggest that we agree on a naming convention for our individual versions? You are on 013 but I am only on 04. We should use something like "jf.013"
17:56 < jfh> OK, NP
17:57 < lewiscot> We should also have some notation to indicate when our version is derived from someone else's version
17:57 < jfh> So I guess we should have a working editor, based on jQuery, and so on, in 2 months
17:57 < jfh> I really don't know about Ben's approach
17:57 < lewiscot> I think we can have an updated version of v0.2 before then.
17:58 < lewiscot> Not with full support but I think we should make the current version easier to implement before we work on an upgrede.
17:58 < lewiscot> upgrade.
17:58 < lewiscot> Also, I think hacking jQuery support into the editor would be nice.
17:58 < lewiscot> We could have it ready in 2-3 weeks.
18:00 < lewiscot> My thoughts on the proposed techniques:
18:01 < lewiscot> Ben's approach promises to be very good. It solves a lot of the compatibility issues quite nicely. It is a very strong candidate for v0.3 or v0.4. It poses some challenges that must be overcome and thoroughly tested first.
18:02 < lewiscot> The current version of WYMeditor v0.2 works very well in FF and IE. It is not a perfect solution but it is a vast improvement over other alternatives. The fact that it does not support Safari is not good long term but I think in the short term, the market will forgive us for this.
18:04 < lewiscot> We will be better served by getting a working stable version out to market sooner rather than later, even if it does not support all browsers.
18:04 < jfh> OK. We should release a 0.2.3, with the new features (dynamically creation, thickbox, ...)
18:05 < jfh> What about SkyBlue specific code?
18:05 < lewiscot> _HOW_ WYMeditor achieves its tasks is not important to the end user. They only care that they can do what they want to do. If the methods of editing are changed in a future version, it should be un-noticable by users and is not really important so long as we do not change how it is used by the end user.
18:05 < lewiscot> Yes, I think v0.2.3 is a good next step.
18:06 < lewiscot> The version you downloaded was set up that way so I could make the necessary mods to WYM. I have taken all the SkyBLue-specific code out. I will post an updated version later today. I'll post it to my site first so you can download. I will try to get it up on the svn later today also.
18:07 < lewiscot> Just so it is clear and our goals are clearly defined:
18:07 < lewiscot> The purpose of v0.2.3 is only to do 3 things:
18:07 < lewiscot> 1. Simplify the implementation of WYMeditor into third-party apps
18:08 < lewiscot> 2. Implement jQuery support (very limited and hacked but it's a start)
18:08 < lewiscot> 3. Replace the Dialog Windows with thickbox overlays
18:09 < lewiscot> We will also need really good documentation on how to integrate WYMeditor. This will be key to convincing developers to use it.
18:09 < lewiscot> Oh, I understand what you mean about the SkyBlue-specific code (get.urls.php, $Core, etc.). I will take all of that stuff out.
18:10 < lewiscot> Give me until next Monday to get that done.
18:10 < jfh> OK.
18:11 < lewiscot> One feature I _really_ like in the SkyBlue implementation is the ability to create a link to another page within the site. If you could be thinking about how to do this generically in any application that would be helpful.
18:11 < lewiscot> A serialized array from PHP maybe?
18:12 < lewiscot> No, forget that. Dumb idea.
18:12 < jfh> We can discuss about that later.
18:12 < lewiscot> The developer will need to create their own PHP to get the pages. We will just make the "Internal Page" feature conditional.
18:13 < lewiscot> Should we just take that feature out for v0.2.3?
18:13 < lewiscot> That is probably the best solution for now.
18:14 < lewiscot> I know exactly how to do it but perhaps we should go for the easier target to start with.
18:15 < lewiscot> Ok, I need to get to work. Next wednesday 15:00GMT?
18:15 < jfh> Why not?
18:15 < lewiscot> Ok. A bientot.
18:15 < lewiscot> Bye Ben.
18:15 -!- lewiscot has left #wymeditor [lewiscot]
18:15 < bens> I'll be around then.
18:16 < jfh> Cool, thanks.
18:16 < jfh> Bye!
18:16 < bens> And will answer any questions by email!
18:16 < bens> Bye!