IRC 2007/05/18

16:09 < jfhv> so I suggest to talk about
16:09 < jfhv> 1) XHTML parser
16:09 < jfhv> 2) Selection API
16:09 < bermi> ok
16:09 < jfhv> 3) Safari implementation
16:10 < vmx> 4) coding guidelines (i made a small draft)
16:10 < jfhv> cool
16:10 < jfhv> maybe we can wait Scott for 3)
16:11 < jfhv> I guess he'll be back next week
16:11 < jfhv> OK?
16:11 < bermi> 3) depends heavily on 2)
16:11 < jfhv> yep
16:12 < jfhv> OK.
16:13 < jfhv> So Bermi, could you please talk about 1) - new improvements, ans so on?
16:14 < bermi> right now it seems to work fairy well, I've added some rules for cleaning up MS word documents and it works pretty well in FF
16:14 < dreszka> :) :) :)
16:14 < vmx> i've a question about the xhtml parser:
16:14 < jfhv> yes, I saw that - cool :)
16:14 < bermi> there is only one thing left and is to avoid <p> inside <td>
16:15 < bermi> tell me that question
16:15 < vmx> have i understood right, that it is used to validate pasted/manual added input?
16:15 < bermi> yes
16:16 < vmx> bermi: are you the twiki guy? (sorry i can't remember who belongs to which project)
16:16 < bermi> it removes invalid tag attributes, corrects tag nesting issues and fixes entities
16:16 < bermi> nop
16:16 < bermi> its Sven I think
16:17 < dreszka> yes it's sven
16:17 < vmx> ok, i think there isn't much to say about it, i think we can go to 2)
16:17 < jfhv> bermi has created 'bermi' and 'new_parser' branches
16:18 < vmx> (i'd like to tighten the meetings a bit and make them faster and shorter)
16:18 < bermi> there is only one thing left on the Parser and its checking nesting correctness
16:18 < jfhv> yes, I noticed a problem with nested lists
16:19 < jfhv> <ul><li>...</li><ul>...
16:19 < jfhv> the second ul must go in the li
16:19 < bermi> I'll test that
16:20 < jfhv> ok
16:20 < jfhv> I also noticed another problem in MSIE:
16:20 < jfhv> sometimes the classes are 'lost'
16:21 < bermi> I think I've fixed that
16:21 < bermi> it happened when I added the MS Words cleanup, but now its been fixed
16:21 < jfhv> well, sorry, I tested last revision
16:22 < jfhv> OK - needs fix
16:22 < jfhv> I think Volker wants to talk about 2)
16:22 < bermi> so I'll have a look into that. If you could open an issue with the code so I can test it
16:22 < bermi> ok
16:22 < jfhv> Volker?
16:23 < vmx> yes
16:23 < vmx> i haven't had time to work on it
16:23 < vmx> are there any questions about it
16:23 < vmx> there's a gecko implementation that should work, just the implementation for the other browseres is missing
16:23 < bermi> is there any roadmap for that?
16:24 < jfhv> it's planned for 0.4
16:24 < vmx> of course any help is appreciated
16:25 < vmx> but it shouldn't be that hard as the algorithms can be used from other projects
16:25 < bermi> I need that to get Safari working, I proposed an interface at  https://trac.wymeditor.org/trac/ticket/38
16:25 < vmx> to implement it in ie
16:26 < jfhv> any example, Volker?
16:26 < vmx> i can't implement it for safari
16:26 < bermi> I have one, but it is for Textareas and Inputs  http://laboratorium.0xab.cd/jquery/fieldselection/0.2.3-test/test.html
16:26 < vmx> (arg, firefox crashed)
16:28 < jfhv> nice jQuery plugin :)
16:28 < vmx> bermi: hasContentSelected is already there
16:29 < vmx> it's isCollapsed
16:30 < vmx> getselectedContent should only be needed for safari, but might be useful in the core though
16:31 < vmx> replaceSelectedContent can be used in conjunction with deleteIfExpanded
16:31 < bermi> isCollapsed doesn't work in Safari :(
16:32 < vmx> insertAtCaret same as for getSelectedContent
16:32 < vmx> bermi: it isn't implemented yet, it can't work
16:32 < vmx> the whole selection api isn't implemented for safari
16:33 < vmx> deleteSelection is deleteIfExpanded
16:34 < vmx> i'm not sure if moveCaretTo is needed, i think cursorToStart/cursorToEnd should be enough
16:35 < vmx> what should be returned by getCaretPosition?
16:35 < bermi> nothing, forget about that one
16:35 < bermi> I didn't know about  http://dev.wymeditor.org/wiki/index.php/Docs/SelectionAPI
16:36 < vmx> ic
16:38 < vmx> i think the selection api is almost what you wanted to have
16:39 < bermi> I really need it in safari
16:39 < vmx> feel free to add things to that page (it should be move to trac)
16:40 < vmx> i would be nice if you/scott could implement it. i can't as i don't have safari
16:41 < vmx> i think the comments and the implemenetation for gecko in my branch should almost be enough to get it done
16:41 < bermi> I'll have a look into that
16:43 < vmx> ok, any further questions about the sapi?
16:43 < jfhv> do you think fieldselection could help?
16:44 < vmx> i know that one. it could haelp a bit, but the implementations from other brwosers is more helpful
16:44 < bermi> it didn't help me. I'm studying Dojo's selection API
16:45 < jfhv> OK. I'll take a look at it.
16:45 < bermi>  http://www.sauter-online.de/dojo/tests/test_html_selection.html
16:46 < bermi> it even works in Safari
16:47 < vmx> i try to find the one i found useful
16:49 < jfhv> anyone motivated enough to work on the MSIE SAPI implementation?
16:49 < vmx> jfhv: do you remember the link i gave you about the internet explorer implementation of the dom seelction api?
16:49 < vmx> yesi can do it
16:50 < jfhv> cool! hmm, I'm not sure
16:50 < vmx> found it
16:52 < jfhv> is it  http://jorgenhorstink.nl/2006/03/11/w3c-range-in-internet-explorer/
16:53 < vmx> yes, but someone implemented in an wysiwyg editor
16:54 < vmx> with really nice documentation
16:54 < vmx> i'll try to find it, but we should go on with the meeting
16:54 < jfhv> Excellent.
16:54 < jfhv> OK. Go to 3) guidelines
16:55 < vmx> ok i'll upload them
16:55 < bermi> sorry for breaking the guidelines on the xhtml parser, I was porting the code from PHP
16:56 < jfhv> NP. We really need them :)
16:56 < vmx> there aren't any guidelines yet, that's the problem
16:56 < vmx>  http://vmx.cx/tmp/wymeditor/codingstyle.htm
16:56 < vmx> it's just a draft (and not prrof read etc)
16:57 < vmx> just read thorugh an tell if you're done. then we can start discussion (and there will be discussion ;)
16:58 < bermi> I would add. Name your methods thoroughly so no documentation is needed for it ;)
17:00 < jfhv> argh... object literals :)
17:00 < bermi> I've added a few :/
17:01 < jfhv> what do you prefer, Bermi?
17:02 < vmx> (btw: i found what i was looking for:  http://mozile.mozdev.org/0.8/src/dom/InternetExplorerRange.js that#s jsut for ie, buit perhaps there's docuementaion for other problems somewhere else in the source)
17:02 < bermi> is init called automatically when instantiating?
17:02 < jfhv> I guess no
17:03 < bermi> so I prefer non literals
17:03 < jfhv> Actually Scott and I prefer to use the prototype.* syntax
17:04 < vmx> ok i think we should go trough my propositions: i think we should try to make the code compressable by dean edwards packer
17:05 < bermi> So do I, but I one way or other doesn't matter that much, if you don't need a constructor go with literals
17:05 < bermi> vmx: the IE Range code license doesn't fit with WYM licensing policy
17:05 < bermi> MPL 1.1/GPL 2.0/LGPL 2.1
17:06 < vmx> i won't use the code
17:06 < vmx> just the algorithm
17:06 < jfhv> be aware of patents
17:06 < bermi> yes, I would better see what the Dojo BSD, have done
17:07 < vmx> afaik algorithms can be patented (at least not in europe) (but i'll be aware and ask those people)
17:07 < jfhv> well, I was kidding
17:07 < vmx> ic :)
17:07 < vmx> there is no difference bettween literals and prototye.* it's the same syntax, but the former can be compressed better
17:08 < jfhv> ah, I didn't know that
17:08 < bermi> vmx: Is the init method in literals called automatically when instantiating?
17:08 < vmx> prototype is a reserved word. to it can't be compressed
17:08 < vmx> bermi no. it just does the same, but is written different
17:09 < jfhv> I prefer non-literal simply because it's easier to read
17:10 < vmx> i don't know why it should be easier to read. normally you know where you are in the source, aren't you?
17:11 * vmx should polish his english a bit this spring
17:11 < bermi> If you want to instantiate your Objects you'll need to do something like this to have a valid constructor
17:11 < bermi> function b(){
17:11 < bermi> }
17:11 < bermi> b.extend({
17:11 < bermi> init: function(){console.log('hi')}
17:11 < bermi> });
17:11 < bermi> new b();
17:11 < bermi> uuupsss, sorry, I'm kind-a-newbie on IRC
17:13 < vmx> you'll need to cann "init"
17:13 < vmx> cann = call
17:15 < jfhv> OK. I'm not going to rewrite all the stuff in literals for 0.3.
17:15 < bermi> actually you don't need the init method at all, you can just used the function body as constructor, I included init to check if it was called the way you proposed
17:15 < vmx>  http://www.htmlgoodies.com/primers/jsp/article.php/3600451 is a nice tutorial about prototypes
17:17 < vmx> jfhv: you are "the master", you have the last word. i prefer literals, and would use them for now on
17:17 < vmx> the rest of the code can be changed from time to time
17:17 < jfhv> I suggest to keep non-literals for 0.3, as we won't add new features
17:18 < vmx> the point is actually: we need to decide now and use that forever
17:18 < jfhv> ... and to use literals after the 0.3 stable release
17:18 < jfhv> so we'll have to rewrite the whole stuff in literals
17:18 < vmx> but if the majority of core developers dont like it, we shouldn't use them.
17:18 < vmx> ok
17:19 < vmx> that's fine
17:19 < bermi> I want to suggest a new topic for the next chat. Unit tests
17:19 < vmx> so there'll be a big 0.4 selection api+literls release
17:19 < vmx> bermi: have you read the old chat logs?
17:19 < bermi> no
17:19 < vmx> we talked about it once
17:19 < jfhv> I'd like to know Scott's thoughts about literals, BTW
17:20 < jfhv> I don't want to be imperative
17:20 < bermi> jfhv, I we are going to use literals they should be real OO, not just for encapsulation IMO
17:21 < vmx> jfhv: perhaps you could also search the net about it. i haven't found anything negative about oject literals yet (at least i don't remember)
17:21 < bermi> jQuery is not really well suited for object inheritance. I had to write my own inheritance code for the Lexer/Parser code
17:22 < vmx> bermi: do you mean the "extend" method on jquery?
17:22 < vmx> on=in
17:23 < bermi> I had to write my own extend methods as the one in jQuery didn't work for me
17:23 < vmx> cause it wasn't called recusrively?
17:24 < bermi> what do you mean?
17:25 < bermi> I wanted to keep the Lexer/Parser independent from jQuery
17:25 < bermi> so I wrote
17:25 < bermi> Object.prototype.extendObject = function (oSuper) { for (sProperty in oSuper) { if(sProperty != 'type'){ this[sProperty] = oSuper[sProperty]; } } };
17:25 < vmx>  http://dev.jquery.com/ticket/1028
17:27 < vmx> back to coding style
17:27 < vmx> another big (arguable) point is the hungarian notation
17:28 < bermi> I hate it
17:28 < vmx> me to (as you can see on my proposition)
17:29 < bermi> what happens when you want a far that can be undefined, bool or object?
17:29 < jfhv> mixed?
17:29 < jfhv> mVar
17:30 < vmx> i think a var should have one type (or undefined)
17:30 < bermi> I preffer his proposition on naming conventions for the variables
17:31 < vmx>  http://dojotoolkit.org/developer/StyleGuide is btw a nice guide (although not everything)
17:31 < bermi> booleans should always start with is/has/does
17:31 < jfhv> well, non-hungarian is not a problem for me
17:31 < bermi> Objects with first uppercase, arrays in plural.....
17:32 < jfhv> yes
17:32 < jfhv> it's just a matter of search/replace in the current code
17:33 < jfhv> and I also think non-hungarian is better for the end-user
17:33 < jfhv> who will configure the editor
17:33 < bermi> I'm really used to these guidelines  http://akelos.org/Akelos%20Framework%20Developer%20Coding%20Style%20Guide.pdf
17:34 < vmx> bermi: i'll take a look at see what can be useful
17:34 < bermi> all yours
17:35 < vmx> could i also copy & paste? (as it seems that you have written it)
17:36 < bermi> I've adapted it from other free sources
17:36 < bermi> you can copy and paste
17:36 < vmx> ok
17:37 < bermi> From the Akelos guidelines: This document has evolved from  http://www.possibility.com/Cpp/CppCodingStandard.html and  http://pear.php.net/manual/en/standards.php
17:37 < vmx> so i can remove the hungarion notation part?
17:38 < jfhv> do it!
17:38 < bermi> :D
17:38 < vmx> strike!
17:38 < jfhv> I will search and replace
17:39 < bermi> jfhv: I think we should merge the new parser before changing the notation
17:39 < bermi> What about the new dynamic loading technique, do you like it?
17:40 < jfhv> well, I'd prefer to release 0.3 stable before merging the XHTML parser in the trunk
17:40 < vmx> how does it work? with "document.write"?
17:40 < bermi> no
17:40 < vmx> link to source?
17:40 < bermi> with $j.ajax and eval
17:41 < jfhv> I really like it :)
17:41 < bermi> non-async ajax
17:41 < jfhv> seems to work very well
17:41 < vmx> isn't eval evil? (that's what you can read ybout it ;)
17:41 < vmx> i tihnk dojo uses document.write
17:42 < bermi> I don't think eval is evil in JS
17:43 < bermi> prototype.js, jQuery and all other frameworks allow to eval returned content
17:43 < vmx> the part about commentin the source needs to be written, take a look at  http://dev.mootools.net/browser/trunk/Element/Element.Event.js i think this is really much better than jsdoc
17:43 < vmx> bermi: i was just kidding, i've no idea about adding file dynamicly
17:45 < vmx> i think all other parts of the style guide should be ok, as these are only "normal" conventions
17:45 < vmx> the code tag part also needs to be written
17:47 < jfhv> OK. I suggest that you copy it to the dev wiki.
17:47 < jfhv> We can discuss further if needed on the mailing-list
17:48 < vmx> jfhv: if it's ok for you i'll rework it untill the next meeting
17:48 < vmx> and add it myself than
17:49 < jfhv> ok, thanks
17:49 < jfhv> about 0.3
17:49 < jfhv> I'd like to release 0.3 stable asap
17:50 < vmx> it it ok to add it to the trac-wiki as draft? than everything can follow the cahnges in the trac timeline?
17:50 < jfhv> No problem
17:51 < jfhv> it needs a base rubric
17:51 < dreszka> I'll have to go now
17:51 < dreszka> bye bye
17:51 < jfhv> like Developers/Coding style
17:51 < jfhv> we have 0.2/.... 0.3/....
17:52 < jfhv> I'll create the pages this evening
17:53 < jfhv> OK?
17:53 < jfhv> (I mean the basic structure)
17:53 < bermi> jfhv: you can move some tickets to 0.4 as those bugs (#1 and #26) are fixed with the new parser
17:54 < vmx> jfhv: just dot it! ;)
17:56 < jfhv> isn't the parser planned for 0.3.1 ?
17:58 < bermi> for me it's OK on 0.3.1, but please don't change the naming conventions at 0.3 as it will be nightmare to merge
17:59 < jfhv> I'd like to change the conf names
17:59 < vmx> i think it's ok if 0.3.1 has mixed naming (as we hven't a cenvention yet)
18:00 < jfhv> I mean aClassesItems and so on
18:00 < bermi> I just use conf names for the CSS parser
18:00 < bermi> thats ok for me
18:00 < jfhv> nice
18:01 < jfhv> OK. I'll try to find good names.
18:01 < bermi> you might want to include the new loading mechanism, so it's simpler for users
18:01 < jfhv> I guess you haven't tried the Makefile?
18:01 < bermi> no
18:01 < jfhv> It merges and packs
18:02 < jfhv> so everything is merged in one file
18:02 < jfhv> jquery.wymeditor.js
18:02 < bermi> I knew it merges, but had no idea about packing
18:03 < bermi> the loader only fetches the external file is the required function is not available yet
18:03 < jfhv> OK. Sorry to repeat myself, I'd prefer to keep the current code, so I can release 0.3 asap.
18:04 < bermi> ok
18:04 < jfhv> OK
18:05 < jfhv> anything to add?
18:05 * vmx has nothing to add
18:06 < bermi> nothing
18:06 < jfhv> OK. Thank you for the meeting. I'll post the log as usual. Bye bye :)
18:06 < vmx> i think this was one of the most productive meetings we had
18:06 < vmx> perhaps we should talk about next meeting time
18:07 < jfhv> why not
18:07 < vmx> thursday or friday 14 gmt?
18:07 < jfhv> I'd prefer Friday, finally
18:07 < bermi> see you friday then
18:08 < vmx> it's ok for ne
18:08 < vmx> me
18:08 < jfhv> cool
18:08 < jfhv> we can start at 13 GMT
18:08 < jfhv> or is it too early for Scott?
18:09 < jfhv> I mean: 14 GMT (16 for me) is a little bit late
18:10 < bermi> 13 GMT is OK for me, but you should ask Scott
18:10 < jfhv> OK, I will
18:10 < jfhv> I'll announce it on the ml
18:10 < jfhv> so, bye bye :)
18:11 < bermi> bye