= IRC 2007/02/28 =
16:46 <@jfhv> OK. Volker and Scott: did you checked out the svn today? [[BR]]
16:46 < lewiscot> No, I haven't. Which version in the branch? [[BR]]
16:46 <@jfhv> The trunk. [[BR]]
16:46 <@vmx> no, i'll take a look (i really like tracs timeline) [[BR]]
16:47 <@jfhv> Many things to say... [[BR]]
16:48 <@jfhv> I've added a basic l10n system. [[BR]]
16:48 <@jfhv> + constants [[BR]]
16:48 <@jfhv> + many options [[BR]]
16:49 <@jfhv> + buttons work in general [[BR]]
16:49 <@jfhv> + switching containers works [[BR]]
16:50 <@jfhv> + a 'hack' with setTimeout for a callback fn [[BR]]
16:50 <@jfhv> OK in IE/OP/FF [[BR]]
16:51 <@jfhv> Volker: we use a specific file for each browser [[BR]]
16:51 <@jfhv> This is done by init() [[BR]]
16:52 <@vmx> jfhv, yes i've seen that [[BR]]
16:52 <@vmx> and there's alsa a "master" file for all of them, right? [[BR]]
16:52 < lewiscot> JF: the more I think about it the more I think this is the correct way to go. We only have to do one browser detect. This should lower the cpu overhead. [[BR]]
16:52 <@jfhv> Yes, jquery.wymeditor.js [[BR]]
16:52 <@jfhv> Yes, I like this method. [[BR]]
16:53 < lewiscot> I like how little code is required. Very nice. [[BR]]
16:53 <@jfhv> Yes. I try to keep the specific files the lighter possible, too. [[BR]]
16:53 <@jfhv> To avoid duplicates. [[BR]]
16:53 <@vmx> can you overwrite functions? [[BR]]
16:54 <@vmx> i mean, can the ff specific file overwrite a function from the general one? [[BR]]
16:54 < lewiscot> JF, so the setTimeout worked? [[BR]]
16:54 <@jfhv> Volker: I didn't test overwriting. [[BR]]
16:55 <@jfhv> Scott: yes! [[BR]]
16:55 < lewiscot> The overwriting should work [[BR]]
16:55 < lewiscot> Excellent. I'm glad that worked out. I think there are some ways to make the technique more reliable. You might try looking at how jQuery handles the document.ready function. [[BR]]
16:56 <@vmx> if overwriting works it sounds nice. i thought about cases where all browsers need the same code, except of one [[BR]]
16:56 < lewiscot> Another option is to hard-code the function you want to be called (setting the html) in the body.onload of the iframe document. [[BR]]
16:56 < dreszka> if you could take a look at my problem... it's visible here: [[BR]]
16:56 < dreszka> http://trac.wymeditor.org/trac/browser/branches/d.reszka/002/wymeditor/jquery.wymeditor.js?rev=127 [[BR]]
16:56 < dreszka> at line 49 where I try to use the value of sToolsHtml in sSectionTopHtml [[BR]]
16:56 < dreszka> if you can give me an advice to make it finally work I would be very very happy ! :) [[BR]]
16:57 < dreszka> ... sorry to interrupt [[BR]]
16:58 <@jfhv> Scott: I tried many solutions. IIRC, one worked well in any browser, except MSIE... [[BR]]
16:58 <@jfhv> You can see an example using setTimeout in index.html [[BR]]
16:58 <@jfhv> http://trac.wymeditor.org/trac/browser/trunk/src/index.html [[BR]]
16:59 <@jfhv> I find it pretty simple [[BR]]
17:00 <@jfhv> You just have to pass the WYMeditor index (i) [[BR]]
17:00 <@jfhv> $j.wymeditors(i) returns the WYMeditor instance i [[BR]]
17:00 < lewiscot> Yes, it is simple. I ran into a problem with it however in my implementation of Wymeditor for my CMS. If the internet connection is slow you have to set the timeout interval to a higher number. [[BR]]
17:01 < lewiscot> It works but it is not pretty. [[BR]]
17:01 <@jfhv> I agree. [[BR]]
17:01 < lewiscot> Daniel, I will experiment with jquery to see how to work it out. It should not be difficult. [[BR]]
17:01 < dreszka> thank you [[BR]]
17:02 <@jfhv> sorry, phone call [[BR]]
17:02 < lewiscot> It really depends on how JavaScript parses and resolves the object's properties. [[BR]]
17:02 < lewiscot> np [[BR]]
17:02 < lewiscot> I think i have figured out (in theory) how to handle the Safari implementation. [[BR]]
17:02 <@vmx> scott: can you tell me what you are talking about, i can really follow your discussion. i don't know the inital problem [[BR]]
17:03 < dreszka> I know it can be done becouse I foud a way several months ago, but can't remember how I did it :( [[BR]]
17:03 < lewiscot> vmx, do you mean about Safari? [[BR]]
17:03 <@vmx> no the prevoius onw with settimeout [[BR]]
17:03 < lewiscot> LOL. I do that all the time, Daniel. [[BR]]
17:04 <@jfhv> Volker: I'd like to add a callback function to $j(".wymeditor").wymeditor() [[BR]]
17:04 <@jfhv> So you can manipulate the WYMeditor instance [[BR]]
17:04 <@jfhv> When it's ready [[BR]]
17:04 < lewiscot> Oh. JF was having a problem with setting the content of the iframe. The issue was that the setHTML function was being called before the iframe was completely loaded so when he tried to set iframe.content to the HTML, there was not 'body' element present. We used setTimeout to cause the setHTML function to delay by 1 second. [[BR]]
17:05 <@vmx> ok ic [[BR]]
17:05 <@jfhv> (Setting the html value is an example) [[BR]]
17:05 < lewiscot> It is a hack and I think there should be a cleaner, more reliable way to do it but we have not found it yet. [[BR]]
17:05 <@vmx> k [[BR]]
17:05 < lewiscot> JF, I think I figured out how to handle the safari implementation. [[BR]]
17:06 < lewiscot> Safari does not fully implement execCommand but some of the commands are supported. [[BR]]
17:06 < lewiscot> Whenever possible, we will use execCommand [[BR]]
17:06 < lewiscot> where necessary, I will write custom code to handle the commands not supported. [[BR]]
17:07 < lewiscot> As support in safari improves we can change the individual functions. [[BR]]
17:07 <@jfhv> OK, that's what I was thinking. [[BR]]
17:07 < lewiscot> We will need a wrapper for execCommand calls however. [[BR]]
17:07 < lewiscot> This will be necessary in all browser files though. [[BR]]
17:07 < lewiscot> So we would need: [[BR]]
17:07 < lewiscot> wym.execCommand(cmd); [[BR]]
17:08 < lewiscot> wym.prototype.execCommand = function(){ [[BR]]
17:08 < lewiscot> ... etc. [[BR]]
17:08 < lewiscot> Then in the safari code, we will need a separate function for each command. [[BR]]
17:09 < lewiscot> For the commands supported natively, we will simply call the native function. [[BR]]
17:09 < lewiscot> For those not supported, we will have custom code to execute the command. [[BR]]
17:09 <@jfhv> OK. See for example jquery.wymeditor.mozilla.js : _exec [[BR]]
17:09 < lewiscot> This will make it easier to strip the custom code out as support improves. [[BR]]
17:09 < lewiscot> Ah, excellent. So you already did this? [[BR]]
17:09 <@jfhv> I guess :) [[BR]]
17:09 < lewiscot> Great. [[BR]]
17:09 < lewiscot> :-) [[BR]]
17:10 <@jfhv> Wymeditor.prototype.exec [[BR]]
17:10 <@jfhv> in jquery.wymeditor.js [[BR]]
17:10 < lewiscot> I'm going to spend a lot of time this weekend researching safari's JS engine. [[BR]]
17:10 <@jfhv> It's a little bit different, but the approach is the same. [[BR]]
17:10 < lewiscot> Cool. I will work with what you have already done. [[BR]]
17:11 < lewiscot> The way I will handle it is this: [[BR]]
17:11 < lewiscot> If the command is supported natively, I will do nothing except call the native code. [[BR]]
17:11 <@jfhv> Yes. [[BR]]
17:11 < lewiscot> If not supported natively, I will create a duplicate of the selection and set a variable to the parentNode. [[BR]]
17:12 < lewiscot> I will manipulate the duplicate then replace the original once the duplicate is changed. [[BR]]
17:12 < lewiscot> it will require some key capturing but luckily most commands are supported. [[BR]]
17:13 < lewiscot> The tough part will be keeping track of the caret pos and the selection range. [[BR]]
17:13 < lewiscot> None of it is too difficult, though. [[BR]]
17:13 < lewiscot> I looked at the Writely.js file and saw some good ideas there. [[BR]]
17:14 < lewiscot> Whatever works for Google should work for us, right? [[BR]]
17:14 <@jfhv> LOL [[BR]]
17:14 < lewiscot> Do we have a target date for release of v0.3? [[BR]]
17:15 <@jfhv> Volker: this is Google Docs [[BR]]
17:15 <@jfhv> I'd like to make a release in March [[BR]]
17:15 < lewiscot> Ok. I will get to work this weekend. [[BR]]
17:15 <@vmx> was that all you had to talk about, is it now my part to talk about my ideas? [[BR]]
17:16 < lewiscot> Yes, I'm done. [[BR]]
17:16 <@jfhv> OK! [[BR]]
17:16 < lewiscot> Which part are you working on volker? [[BR]]
17:17 <@vmx> no specific yet, and i don't know how my time i'll have. but i'm on the gecko side, as i'm a linux user [[BR]]
17:17 < lewiscot> Excellent. I love linux. It's the best. [[BR]]
17:18 <@vmx> and (hopefully) the software design (as i've some ideas) and the "m" in "wym" [[BR]]
17:18 <@vmx> have you all seen my hacked eymeditor? [[BR]]
17:18 < dreszka> scott: let him talk ! [[BR]]
17:18 <@vmx> *wymeditor [[BR]]
17:18 < lewiscot> sorry :( [[BR]]
17:18 <@jfhv> Scott: http://vmx.cx/tmp/wymeditor/ [[BR]]
17:18 < dreszka> sorry but I have to go [[BR]]
17:18 < dreszka> bye [[BR]]
17:18 <@vmx> by dreszka [[BR]]
17:19 <@vmx> (i can't type today) [[BR]]
17:19 < dreszka> I'll ask JFH to send me a copy of this session [[BR]]
17:19 < dreszka> bye [[BR]]
17:19 <@jfhv> (the session is logged) [[BR]]
17:20 <@jfhv> (it will be available on the wiki) [[BR]]
17:20 <@vmx> ok, so the basic i have is based on the ideas lyx have. do you know lyx? [[BR]]
17:20 -!- dreszka [n=admin@126.134-240-81.adsl-dyn.isp.belgacom.be] has left #wymeditor [] [[BR]]
17:20 <@jfhv> A little... [[BR]]
17:21 <@vmx> you can't to things, that you dn't mean. e.g. an empty paragraph isn't allowed, it won't make any sense [[BR]]
17:21 <@vmx> if you'd like more space you should change your stylesheet, not the markup [[BR]]
17:22 <@vmx> it's the smae with indenting with spaces [[BR]]
17:22 <@vmx> do you like the way it currently works? [[BR]]
17:23 < lewiscot> I like what I have read so far. [[BR]]
17:23 <@jfhv> Actually, this is WYSIWYM. [[BR]]
17:23 <@vmx> ok i'll come to the software design [[BR]]
17:24 <@vmx> we should have some documentation on what should happen when [[BR]]
17:24 <@vmx> like: what happens if you press enter at the end of a headline [[BR]]
17:25 <@vmx> or: if you have selected bold formatting and press enter, should the next line also be bold [[BR]]
17:25 <@vmx> so that everyone who implements for a specific browser know what should be done [[BR]]
17:26 < lewiscot> vmx: I agree. We need to think out the scenarios and make decisions before writing any code. [[BR]]
17:27 <@jfhv> Not so easy in a web-based editor, but I agree. [[BR]]
17:27 <@vmx> why not? [[BR]]
17:27 <@vmx> do you think of written scenarios or a diagram. i think a diagram would fit best. it could like a state machine [[BR]]
17:27 <@jfhv> Because we use designMode, and we don't control it. [[BR]]
17:28 <@vmx> we can control it. that is anpther point [[BR]]
17:28 <@vmx> one i'm not sure about [[BR]]
17:28 <@jfhv> MSIE is really crazy... [[BR]]
17:28 <@vmx> how much should we stop the designmode what he does by default [[BR]]
17:28 <@jfhv> I've had many, many problems in MSIE [[BR]]
17:29 <@jfhv> FF is better [[BR]]
17:29 <@vmx> if you take a look at my code, you'll see that i often stop the events completly and do what i want then [[BR]]
17:29 <@jfhv> Yes, I saw that. I'm impressed! [[BR]]
17:30 < lewiscot> vmx: I agree with what you are saying. I think the most maintainable and forward-compatible solution is to not break designMode unless it is absolutely necessary. [[BR]]
17:30 <@vmx> that isn't that nice but sometmes the only solution, e.g. if you press enter at the end of a headline, it inserts two "
" (msie also does that) [[BR]]
17:30 <@vmx> but we like to have a "" [[BR]]
17:31 < lewiscot> agreed [[BR]]
17:31 <@jfhv> FF uses lots of
in designMode [[BR]]
17:32 <@vmx> tightly connected to that problem: how should the code wymeditor creates while editing look like [[BR]]
17:32 < lewiscot> question: [[BR]]
17:32 < lewiscot> should we remove the
tags as the user types or during idle time? [[BR]]
17:33 <@vmx> that would have been my next point [[BR]]
17:33 < lewiscot> :-) [[BR]]
17:33 <@vmx> there a two ways: cleanup at the end of the session, or while editing [[BR]]
17:33 < lewiscot> yes, that is what I was thinking too [[BR]]
17:33 <@vmx> i think cleanup while editing would be nicer [[BR]]
17:33 <@jfhv> At some time, I used to remove the
while editing, but that causes problems [[BR]]
17:33 < lewiscot> I can see a benefit in both approaches [[BR]]
17:34 <@vmx> in my prototpye you can see that it would work while typing [[BR]]
17:34 < lewiscot> cleaning while typing is visually nicer [[BR]]
17:34 < lewiscot> on the other hand, the code will probably be simpler to clean up during idle time [[BR]]
17:35 <@jfhv> This was a bu I had to fix in 0.2 [[BR]]
17:35 < lewiscot> Do either of you know much about regular expressions? [[BR]]
17:35 <@jfhv> bug [[BR]]
17:36 <@jfhv> Medium knowledge [[BR]]
17:36 <@vmx> the disgnmode in ff acts strange, but almost everytime the same way, so you could "repair" it immediately [[BR]]
17:36 <@vmx> medium [[BR]]
17:36 < lewiscot> I was just wondering which is less cpu intensive: dom manipulation or string manipulation with regex. [[BR]]
17:37 < lewiscot> My guess would be dom manipulation but I don't know for sure. [[BR]]
17:37 <@vmx> the approach in my prototype was, zthat i sometimes double check if there aren't any unwanted tags [[BR]]
17:38 <@vmx> if you try keep the markup always clean i think you'll have smaller problems [[BR]]
17:38 < lewiscot> good thinking [[BR]]
17:38 < lewiscot> perhaps I have an idea: [[BR]]
17:38 <@vmx> think of very long editing session, how would the markup look afterward. how many "" will there be? [[BR]]
17:39 <@jfhv> BTW: MSIE always rewrites what you've cleaned up [[BR]]
17:39 < lewiscot> we could have a "cleaner" function that each time a keyboard event occurs, the current node is run through the cleaner. [[BR]]
17:39 <@vmx> scott i think this is to much unneeded overhead [[BR]]
17:39 < lewiscot> ok [[BR]]
17:40 <@vmx> but the diea is good [[BR]]
17:40 <@vmx> a general cleanu function [[BR]]
17:40 < lewiscot> so should the cleaner be conditional on certain events? [[BR]]
17:40 <@vmx> yes [[BR]]
17:40 < lewiscot> Oh, I just realized that is what your code is already doing. [[BR]]
17:40 <@vmx> e.g. if you press backspace at the beginning of a paragraph, when two paragraph get joined [[BR]]
17:40 <@vmx> yes [[BR]]
17:41 <@vmx> as you know what can and should happen if you perform an action [[BR]]
17:41 < lewiscot> someone mentioned a state machine a bit earlier. I think that is the correct thinking. Who mentioned that? [[BR]]
17:42 <@vmx> it was me [[BR]]
17:42 <@jfhv> Volker: I guess you've modified something in http://vmx.cx/tmp/wymeditor/ - it doesn't work anymore in my FF. [[BR]]
17:42 <@vmx> no i haven't, i'll take a look [[BR]]
17:42 < lewiscot> JF, I have a suggestion: [[BR]]
17:43 < lewiscot> While you and I are working on the core functionality in each browser, perhaps volker could be in charge of code cleaning. [[BR]]
17:43 <@vmx> jfhv: there#s a bug sometimes if you press backspace just after it was loaded [[BR]]
17:43 <@vmx> jfhv: type soemthing first and then you can do what you want [[BR]]
17:44 <@jfhv> Well, I get an error when I click to get the cursor [[BR]]
17:44 <@vmx> i don't get an error, which version of ff are you using? [[BR]]
17:44 <@jfhv> 2.0.0.2 [[BR]]
17:45 <@jfhv> I get an exception: nsISelection.getRangeAt [[BR]]
17:45 <@jfhv> line 505 [[BR]]
17:45 <@vmx> hm i use 2.0.0.1 but that should make a difference (as 2.0.0.2 was a secutiry update) [[BR]]
17:45 <@jfhv> NS_ERROR_ILLEGAL_VALUE [[BR]]
17:45 <@vmx> scott, does it work for you? [[BR]]
17:46 < lewiscot> Yes. I'm using FF1.5 on Mac. [[BR]]
17:46 <@jfhv> I can delete, but I can't write. [[BR]]
17:46 <@vmx> jfhv: what are you doing? can you reproduce the bug? [[BR]]
17:46 < lewiscot> volker, can you add a button show the textarea content? [[BR]]
17:46 <@jfhv> Yes. I do CTRL+F5, and the I click in the editor. [[BR]]
17:47 <@jfhv> I get: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsISelection.getRangeAt]" nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)" location: "JS frame :: http://vmx.cx/tmp/wymeditor/wymeditor/wymeditor.js :: selection :: line 505" data: no] [[BR]]
17:47 < lewiscot> JF, it sounds like an empty selection exception. [[BR]]
17:47 <@vmx> scott: i use firebug for debugging, so i haven't needed it. in addition i had no time to look how you add such a button [[BR]]
17:48 < lewiscot> np [[BR]]
17:48 <@vmx> i'll have a look at it, just booting another pc [[BR]]
17:48 <@vmx> ok another thing i'd like to talk about [[BR]]
17:49 <@jfhv> I've restarted FF. It works now. [[BR]]
17:49 <@vmx> ok :) [[BR]]
17:49 <@vmx> what do you think about wiritng code that could be easily used as jquery plugin for others [[BR]]
17:50 <@vmx> e.g. my allChildren() function. it returns also textnode, what jquery doesn't do [[BR]]
17:51 <@vmx> this could easily go to a "general purpose utility file" [[BR]]
17:51 <@jfhv> Yes, so you mean using extend? [[BR]]
17:52 <@jfhv> $.fn... [[BR]]
17:52 <@vmx> yes [[BR]]
17:52 <@vmx> as you can see at the end of my file [[BR]]
17:52 <@jfhv> yes, I saw that [[BR]]
17:52 <@jfhv> It's OK, of course [[BR]]
17:52 <@vmx> anotr problem are "phantom nodes" [[BR]]
17:53 <@vmx> these only occur in gecko afaik [[BR]]
17:53 <@vmx> should the code to handle them go to thegecko specific file, oder to the genera one [[BR]]
17:54 <@jfhv> In the Gecko one, I guess [[BR]]
17:54 <@vmx> i'm not really sure [[BR]]
17:54 <@jfhv> In MSIE, you've also 'phantom nodes' [[BR]]
17:55 < lewiscot> I think a wrapper should go in the general code with a browser-specific function in each browser. [[BR]]
17:55 <@vmx> oh, i din't know that [[BR]]
17:55 <@jfhv> [[BR]]
17:55 < lewiscot> How and when do the phantom nodes appear? [[BR]]
17:56 <@vmx> jfhv, i think you mean empty nodes, not phantom nodes [[BR]]
17:56 <@vmx> phantom nodes are between tags (elements) [[BR]]
17:56 <@vmx> if you have "
\| ..." [[BR]]
17:57 <@vmx> gecko will return on |
.firstChild the "\n" [[BR]]
17:57 <@vmx> sorry, it should read "
\n| " [[BR]]
17:58 <@jfhv> Well, IIRC, MSIE uses lots of (but in the numeric format) [[BR]]
17:58 <@vmx> jfhv, ic [[BR]]
17:58 < lewiscot> It seems to me that in both cases we are talking about unwanted white space. [[BR]]
17:58 <@vmx> again the allChildren() example. the removal of phantom nodes could be easily implemented there. if you put it into the gecko file, you would need t implement it again, just for one if statement [[BR]]
17:59 < lewiscot> Isn't what you both are talking about part of the code cleaning? [[BR]]
17:59 <@vmx> it's just an example, i think we should use more such wrappers [[BR]]
18:00 <@vmx> celaning phantom nodes it too much work imho [[BR]]
18:00 <@vmx> not to much work to implement but for the cpu [[BR]]
18:01 < lewiscot> Perhaps we should use both an "as you type" cleaner, and a "tyding" cleaner that is run at end of session. [[BR]]
18:01 <@jfhv> That's what is done in 0.2 [[BR]]
18:01 < lewiscot> the "as you type" cleaner would be event-triggered and the tyding function would only look for specific things like phantoms. [[BR]]
18:01 <@vmx> yes, of course. phantom nodes occur to often to celan them on typing, and an idented source can also be nice [[BR]]
18:01 < lewiscot> ack, JF. [[BR]]
18:02 <@vmx> without phantom nodes there code will be in one long line [[BR]]
18:02 <@jfhv> I try to handle bad events while editing, and I clean up the code at the submit [[BR]]
18:02 <@vmx> i've one last big thing [[BR]]
18:02 < lewiscot> I think you are both on the same page and essentially saying the same thing. [[BR]]
18:03 <@vmx> we need a selection api [[BR]]
18:03 < lewiscot> I agree. [[BR]]
18:03 <@vmx> the idea is from kupu editor [[BR]]
18:03 <@vmx> it wrapps the selection, and therefore supports some highlevel functions [[BR]]
18:03 < lewiscot> vmx, do you have a link to kupu editor so I can check it out? [[BR]]
18:04 <@vmx> the main code os for all browsers, and some of the code needs to be browser specific [[BR]]
18:04 <@vmx> scott: this is the dev page http://kupu.oscom.org/ [[BR]]
18:05 <@jfhv> jquery.wymeditor.js: Wymeditor.prototype.container [[BR]]
18:05 <@vmx> and this the current one http://plone.org/products/kupu [[BR]]
18:05 < lewiscot> I just found it. Thanks. [[BR]]
18:05 < lewiscot> I have a suggestion that I think will make future development eaiser. [[BR]]
18:05 <@vmx> the essitial code is in "common" (hard to find imho) [[BR]]
18:05 < lewiscot> ok, thnxs [[BR]]
18:06 <@jfhv> And WymClassX.prototype.selected [[BR]]
18:06 <@vmx> http://codespeak.net/svn/kupu/branch/plone-2.1/common/kupuhelpers.js (search for BaseSelection) [[BR]]
18:07 <@jfhv> WymClassX.prototype.selected returns the selected container [[BR]]
18:08 <@vmx> jfhv: we need far more fucntionality, in addition the selection api of the browser is very different [[BR]]
18:09 <@vmx> take a look at my code again. i've tried to do it as general as posible. functions like "isAtStart" can nice in many situations [[BR]]
18:10 < lewiscot> vmx, I understand what you are doing. I think you are on the right path. [[BR]]
18:10 <@vmx> we should wrap the whole selection into our slection object. at the moment i sometimes use the original selection [[BR]]
18:10 <@vmx> so that we have one selection object that is crossplatform [[BR]]
18:11 <@vmx> this is also a part where i think tests would make sense [[BR]]
18:11 < lewiscot> Similar to the way jQuery returns a selected object? [[BR]]
18:11 <@vmx> so that "isAtAtart" really retuns true on the same cases on all browsers [[BR]]
18:11 <@vmx> how does jquery return a selected object? [[BR]]
18:12 < lewiscot> if you do $("#foo"), a DOM object is not returned but a JS object with the DOM object embedded. [[BR]]
18:12 <@vmx> yes [[BR]]
18:12 < lewiscot> JF, what do you think? [[BR]]
18:12 <@vmx> but almost all dom functionality should be wrapped [[BR]]
18:12 < lewiscot> so essentially, we are always performing operations on a clone? [[BR]]
18:13 <@vmx> yes, but sme operations will be cheap as the only clone the value of the dom object [[BR]]
18:13 <@vmx> but most of the time we don't need those dom functions/attributes [[BR]]
18:14 <@vmx> as they aren't that sane. we'll create our own sane ones [[BR]]
18:14 <@vmx> have you had a look at the dom selection api? [[BR]]
18:14 < lewiscot> JF, I think this is the way Writely does it using documentFragment [[BR]]
18:14 < lewiscot> Not sure, though. [[BR]]
18:15 <@vmx> e.g. the "anchorNode" returns the node you started the selection, if you select from back to front, it returns the node at the back [[BR]]
18:16 <@vmx> but most of the time you aren't interested in the way the user selected [[BR]]
18:17 <@vmx> so a documentation about what (sane) funvtions are needed (and what they'll do) should be written [[BR]]
18:18 <@jfhv> OK. I didn't have the need for such API in 0.2, so I'll think it over. I'm sorry, I have to go now. I keep my IRC client open, so the session keeps logged. [[BR]]
18:18 <@vmx> ok, cu jfhv [[BR]]
18:18 <@jfhv> ... and you can continue the discussion [[BR]]
18:18 <@jfhv> ciao! [[BR]]
18:18 < lewiscot> a bientot, JF. [[BR]]
18:19 <@jfhv> oui, à bientôt! Very interesting discussion, BTW! [[BR]]
18:19 < lewiscot> j'suis d'accord. [[BR]]
18:19 <@vmx> if course with selection don't only mean selected text, but also the current cursor position [[BR]]
18:20 < lewiscot> JF, I want to talk to you about some non-wymeditor stuff when you have time. [[BR]]
18:20 <@vmx> e.g. the cursor can be in a text node, but also between element nodes, which makes a big difference [[BR]]
18:20 < lewiscot> vmx, I agree. I think you are on the right track with your thinking. I have been thinking very similarly about wymeditor: [[BR]]
18:21 < lewiscot> a state engine, working on a clone, etc. [[BR]]
18:21 <@vmx> that's nice. so were are probably on the right track [[BR]]
18:21 < lewiscot> I think so. [[BR]]
18:21 < lewiscot> I think before we start coding we should do 3 things: [[BR]]
18:22 < lewiscot> - create a list of the functionality to be supported e.g., bold, italic, insert image, etc. [[BR]]
18:22 <@vmx> and i think we should right test for the selection api, as this one of the most important things with a great spot of problems [[BR]]
18:22 < lewiscot> - create a diagram for each browser of the support for each function and compare each browser [[BR]]
18:23 < lewiscot> - write out detailed scenarios of how to handle each situation [[BR]]
18:23 < lewiscot> I agree with your idea on testing the selection api [[BR]]
18:23 <@vmx> your points are good, i agree [[BR]]
18:24 < lewiscot> Before we write code to perform operations we should know that we can monitor the current state of the document, selection and events [[BR]]
18:24 < lewiscot> and correctly in each browser [[BR]]
18:25 < lewiscot> If we can create a representation of the selection in a wymeditor-native object, then we do not have to worry so much about browser-specific code. [[BR]]
18:25 < lewiscot> very good idea, btw [[BR]]
18:25 <@vmx> yes [[BR]]
18:25 <@vmx> a thing that comes to my mind. if jquery is used, we should code upwards compatible [[BR]]
18:26 <@vmx> e.g. use ".attr('name')" instead of "name()" [[BR]]
18:26 < lewiscot> I agree. [[BR]]
18:26 < lewiscot> ok, I have to go now. Welcome aboard and it was a good discussion. [[BR]]
18:26 <@vmx> ok [[BR]]
18:26 < lewiscot> ciao. [[BR]]
18:26 <@vmx> cu [[BR]]
18:27 <@vmx> that's it, thanks for the great discussion |