IRC 2007/06/22
15:21 < jfhv> Bermi, what have you planned for the parser?
15:21 < jfhv> (in the near future)
15:21 < bermi_> scope awareness
15:22 < jfhv> explain?
15:22 < bermi_> right now the parser does generic tag parsing (it treats all tags the same way)
15:23 < bermi_> when parsing the code it sets the parser in different modes (tag mode, attribute mode....)
15:24 < bermi_> my intention is that at a parsing level this changes to "list mode", "list item mode", "body mode"
15:24 < bermi_> that way we could have more control on what is allowed and where
15:25 < jfhv> OK
15:26 < jfhv> do you think that the current code is stable enough to make a release?
15:26 < bermi_> the parser code is stable
15:27 < bermi_> it needs more real world testing
15:28 < jfhv> right
15:28 < jfhv> we can release it as e.g. 0.4 beta
15:28 < bermi_> that could be ok
15:29 < jfhv> call for feedback as usual
15:29 < jfhv> how much time do you think the scope awareness will take?
15:30 < bermi_> right now II don't have time to implement it
15:30 < bermi_> thats just the only improvement I can think for the parser
15:31 < jfhv> OK
15:32 < bermi_> I think that right now the parser can do a real good job, and with the before/after rules I committed yesterday it can handle most design mode inconsistencies
15:33 < jfhv> yep - I think it would be a good idea to release it asap and get feedbacks
15:33 < bermi_> if 100% correct code is needed people can use the tidy plugin
15:33 < jfhv> (though the tidy ext is not available everywhere)
15:34 < jfhv> OK, so I make a release asap
15:34 < bermi_> what other features are planing?
15:35 < bermi_> IMO support for unsupported browsers should be handled ASAP
15:36 < jfhv> right that has to be done before next release
15:36 < jfhv> we need WYMeditor to gracefully degrade
15:37 < jfhv> e.g. in Safari
15:37 < jfhv> currently it breaks JS because of WymClassSafari
15:37 < bermi_> we also need to enable/disable supported methods in an efficient way
15:38 < vmx> bermi: for example?
15:38 < bermi_> the WymCLassSafari in the new_parser class can handle strong, emphasis and lists.... nothing else
15:39 < bermi_> if we could have a convention to tell wym what a browser can do, we can render a layout with the features that work correctly
15:40 < vmx> ic
15:40 < dreszka> ok
15:40 < jfhv> OK, I see - don't you think it's just a question of hiding some buttons?
15:40 < jfhv> ... something I did for Opera BTW
15:41 < bermi_> how did you implement it?
15:41 < jfhv> $j(this._box).find(this._options.toolSelector + '[@name=' + WYM_INDENT +']').hide();
15:42 < bermi_> so the convention could be having an attribute like
15:42 < bermi_> this.unsupported_methods = [WYM_INDENT,....];
15:43 < bermi_> and then hide those buttons
15:43 < jfhv> why not
15:44 < bermi_> that will make it easier. Safari supports different methods depending on the version
15:45 < bermi_> have you had a look into the safari implementation at branches/new_parser?
15:45 < jfhv> yep, but not recently :)
15:46 < bermi_> what do you think about the way I implemented unsupported designMode commands?
15:47 < bermi_> that might also be useful to override buggy commands on other browsers, instead of adding if/else conditions
15:48 < jfhv> do you mean:
15:48 < jfhv> WymClassSafari.prototype._exec = function(cmd,param) {
| null; |
| typeof this[cmd] == 'undefined'){ |
15:48 < jfhv> this._doc.execCommand(cmd,false,param);
15:48 < jfhv> }else{
15:48 < jfhv> this[cmd](param);
15:48 < jfhv> }
15:48 < jfhv> };
15:50 < bermi_> thats right, in this case if the command is implemented in WymClassSafari it will use it instead of execCommand
15:50 < bermi_> that allows you to do stuff before and after running specific commands
15:51 < jfhv> OK - do you think it will be 'compatible' with the SAPI? Is it complementary?
15:51 < bermi_> it is complementary
15:51 < vmx> it fits perfectly to the sapi
15:51 < vmx> *g*
15:52 < jfhv> great!
15:52 < vmx> the "manual" exec would need the sapi
15:53 < bermi_> vmx, thats right
15:53 < jfhv> I see
15:54 < jfhv> well I'm sorry I don't have much time for the meeting
15:54 < vmx> jfhv: just one thing
15:54 < vmx> i've chattet with john resig about the unique/html issue
15:55 < jfhv> what I suggest is to handle unsupported browsers, see if bugs remain and then release 0.4 if possible
15:55 < jfhv> OK
15:55 < jfhv> and?
15:55 < vmx> changing html() is the only way to go. i know you don't like it but i think it's ok
15:56 < vmx> i'll try to make a version which is the best of speed and jquery filesize
15:56 < jfhv> could you tell me why?
15:56 < jfhv> your patch seemed good
15:56 < vmx> the solution john proposed would be really slow
15:56 < vmx> it still slows the selectors down
15:56 < jfhv> and your third patch?
15:57 < vmx> i also think that is is better to have speedier selector and less speed in html
15:57 < vmx> event that one again about 5-10%
15:57 < vmx> you won't need html() that even
15:57 < vmx> even wymeditor won't need it that often
15:58 < jfhv> the only problem occurs when you use jquery.find()
15:58 < vmx> yes
15:58 < jfhv> I circumvent it by not using find()
15:58 < vmx> as find needs to check for uniqueness
15:58 < jfhv> yep
15:58 < vmx> but i don't think that's the way to go
15:58 < vmx> of course it will speedier, but that bug needs to be fixed in the core
15:59 < vmx> and john said that a fix will go into the 1.1.3 release
15:59 < vmx> and even if it's the html() fix, the main point is that it gets fixed
16:00 < jfhv> what will be fixed?
16:00 < jfhv> the mergeNum attr?
16:00 < vmx> .html()
16:00 < jfhv> OK, but what about the extra DIVs?
16:00 < vmx> so mergeNum will be stripped if you cann html()
16:00 < vmx> there won't be any extra divs
16:01 < vmx> at least not in my tests
16:01 < vmx> have you tried my hrml() fix?
16:01 < jfhv> the second patch (IIRC) ?
16:02 < vmx> a comment
16:02 < vmx> http://dev.jquery.com/ticket/1143#comment:8
16:02 < jfhv> yep I tested it
16:03 < jfhv> extra DIVs remain IIRC
16:03 < vmx> which one was your test case?
16:03 < jfhv> there was no extra DIVs with your last patch
16:03 < vmx> then i can test it again
16:03 < jfhv> let me see
16:04 < vmx> i couls also use current svn to test
16:04 < jfhv> my test/020
16:04 < jfhv> but I did this test after trying your html) patch
16:05 < jfhv> anyway, you can use the test pages
16:05 < jfhv> which are minimalistic
16:06 < jfhv> I found out that the issue comes from MSIE + expandos + designMode
16:06 < vmx> yes, but only with innerHtml
16:07 < jfhv> explain?
16:08 < vmx> if you call innerHtml the mergeNum expando gets added
16:08 < vmx> and also the additional divs
16:09 < jfhv> OK - where can I check out the proposed fix?
16:10 < vmx> http://dev.jquery.com/ticket/1143#comment:8
16:10 < vmx> of yourse you need to change all calls from .innerHTML to .html()
16:10 < vmx> haveN#t we had that discussion before?
16:11 < jfhv> maybe
16:11 < jfhv> I'll re-test, thanks
16:12 < jfhv> OK, sorry I have to go
16:12 < vmx> np, cu
16:12 < bermi_> see you
16:13 < jfhv> if I have other ideas/questions I'll post them on the m-l
16:13 < jfhv> bye!
16:13 < bermi_> a marketing roadmap would be nice
16:13 < bermi_> bye
16:14 < jfhv> I let my IRC client open
16:14 < dreszka> i have to go also
16:14 < dreszka> have a nice weekend
16:15 < bermi_> I'm also leaving, nice weekend to all
16:15 < vmx> cu all
