and converting them later [01:16:51] I hate all browsers [01:16:53] they all suck [01:16:59] :) [01:17:01] brb [01:17:05] There I ran into the issue that if the text starts with

Foo

replacing that

with \n is wrong [01:17:12] So I used .find('* + p') [01:17:21] Which gave me hope for a Webkit div fix [01:21:22] TrevorParscal: Also when you get back please respond to my PMs :) [02:11:38] lol WTF [02:12:04] It looks like the ownline breakage could be fixed by just reversing what it does at the beginning of a line and what it does at the end of one [02:13:58] Oh wait, I'm an idiot [02:14:12] Or up too late, have your pick [02:32:31] OK I'm calling it a day [02:32:49] I have figured out what's going on with the ownline stuff and I have a fix on paper, I'll implement it in the morning [18:29:00] RoanKattouw_away: how's it going... [19:33:10] hey adam_miller_away [19:33:37] can you irc/chat/otherwise grab me when you're back. [19:40:27] highlighting is pretty screwed up in IE if you start editing allot, more specifically if you start pasting [19:41:18] as soon as it starts nesting things in P tags, highlight stops working [19:42:09] that whole traversal algorithm is based on the assumption that all text nodes share the body as a parent, when actually in browsers like IE, Safari and Chrome, text nodes end up nesting inside p tags and divs respectively [19:52:38] Hm [19:52:47] Theoretically it does account for stuff being wrapped [19:53:01] Although it's possible it assumes everything is a child of the body unless it wrapped it itself [19:53:21] I also discovered that my fix to make

conversion work is grossly inefficient [19:53:45] $pre.find('br').each(function() { $(this).blah(); } ); ends up calling the jQuery constructor tens of thousands of times [19:53:49] (for large articles) [19:53:57] And good morning :) [19:56:51] good morning [19:57:02] yeah, so I was just getting nimish up to speed [19:57:50] browsers do evil to the DOM, we need to find text in some better way...abt right? [19:58:19] so, as you begin adding lines, typing text, pasting things, etc. IE, Safari, Chrome (and maybe Opera) and even old versions of FireFox (unless you use execCommand('styleWithCSS', false, false) ) start wrapping things in paragraph (in IE) or div tags (everyone else) [19:58:37] Yeah we need to convert those gracefully [19:58:42] so for us to survive this kind of crazy dom corruption [19:58:47] context.fn.htmlToText() is where that happens [19:59:02] well, I'm talking about the highlight thing breaking [19:59:09] We still need div conversion in htmlToText(), and apparently Traverser is making some bad assumptions [19:59:11] Yeah [19:59:11] yes, it's trye that htmlToText is a problem as well [19:59:14] Lemme poke at that [19:59:28] But htmlToText should only cause problems with

wrapping [19:59:31] Not with

[19:59:43] but the refreshOffsets function, may be another place we have to look to deal with this [20:00:17] RoanKattouw: yeah - and that's the WebKit issue, but if you look at the dom of the iframe in IE after you've added a few lines of text, you will see [20:00:20] Yeah it's probably in there rather than traverser [20:00:45] the TOC stops working, because the highlight process is not compatible with the way the browser has resturctured the iframe's DOM [20:01:17] i'm thinking we can come up with a way to support nesting and move on with our lives :) [20:01:20] that's my hope [20:01:25] Yes [20:01:32] I'm gonna poke at refreshOffsets now [20:01:42] After I commit something first [20:02:42] k [20:03:03] i gotta get some food and come back to eat at my desk [20:03:16] I think we can get this done [20:03:33] btw - we want to push to Test soon, but we aren't going to the live site until monday at lunch [20:03:38] we will have a release lunch [20:03:44] Cool [20:03:47] brb [20:05:05] Hm the TOC doesn't scroll to the highlighted header [20:05:15] adam_miller_away: Can you poke at that? ---^^ [20:31:56] TrevorParscal: Ah I discovered the problem [20:32:02] My leavingP logic is flawed [20:52:37] Ryan_Lane: you abouts? [20:56:37] Roan-phone: I'm back from lunch [20:58:22] I'm back too [20:58:29] I showed howie how evil templates are - his blissful ignorance has come to an end [20:58:34] I figured out what's going wrong [20:58:36] hahaha [20:58:42] Did you see the substall discussion? [20:58:51] There's some evil stuff there [20:59:57] Or the ifsubst template that basically does {{#if:{{subst:ns:0}}|not substed|substed}} [21:00:14] Anyway I figured out the p issue, or at least I know why it's failing [21:00:26] I have code to detect when we're entering and leaving a

[21:00:38] awesome [21:00:45] But in

foo

Bar

it doesn't notice that it's left then entered a

because it's just a boolean inP [21:00:59] So I'm thinking I'll track the actual

element I'm in [21:00:59] I don't expect this is a show-stopper, just something we need to pay attention to [21:01:06] Yeah well let's just get it fixed [21:01:21] After that I'll turn my attention to htmlToText() which I made ridiculously slow yesterday [21:01:33] awesome [21:02:04] Because

\n\n\nFoo\n\n\n

gets some newlines stripped (even in Firefox) I got lazy and decided to just convert \n -> br then do .find('br').each(function(){$(this).remove();}); but that's slow as hell [21:02:24] So I'm gonna speed it up by only
ing newlines that are actually in danger of being eaten (i.e. are at the beginning or end) [21:03:40] we need to make a jquery plugin which can do this -> $( 'div:not([rel=wikiEditor])' ).convert( 'p' ); [21:04:02] Not necessarily [21:04:03] essentially, converting all matching elements to another element type [21:04:04] I'll poke at it [21:04:06] k [21:04:14] i'm saying for the safari/chrome issues [21:04:17] Gotta think about performance too [21:04:18] brbh [21:04:20] Oh for the divs [21:04:35] s/brbh/brb [21:04:36] yes [21:05:04] I think I might be able to pull that off too [21:05:39] So 1. wrapping in

s, 2. Speeding up
conversion, 3. Doing

conversion [21:06:07] ok usabilty folks [21:06:12] your tesla host is online. [21:06:17] rejoice [21:06:21] ;] [21:07:22] Cool [21:07:29] *guillom takes a magnet [21:07:31] I guess Ryan_Lane is the one to poke at it? [21:07:33] yea [21:07:37] i forwarded him the info already [21:07:40] and CC'd naoko [21:07:41] Good [21:07:42] Thanks dude [21:07:48] quite welcome [21:07:49] back [21:08:05] RobH: Also, could you look through the wiki closure requests in Bugzilla? I tried to do them a month and a half ago and failed, and people are getting impatient [21:08:23] Specifically wiki closures because those wikis are being vandalized and all the admins are gone [21:12:34] other than swapping out db28s mainboard tomorrow (i have no cpu paste on hand to do it this second) tomrrow is an office day for me to play catchup [21:12:45] i will try to get to them RoanKattouw as they are indeed important, you are correct [21:12:51] OK [21:13:02] I appreciate the reminder ^_^ [21:13:27] Yeah I kinda decided to remind you of your tasks instead of doing them :) same for Ariel BTW [21:13:40] Multichill has another batch of image uploads and poked me about it [21:13:42] RobH: thanks for setting up tesla! [21:14:03] And I really shouldn't become the go-to person for these things just because I did them in my free time in December [21:14:08] anytime =] [21:17:03] TrevorParscal: Aha part of this breakage is your fault :) you added a check for ca2.nextSibling not realizing the code does check for it and takes a different path if it's null [21:17:25] I still wonder what these browsers are gonna think about me trying to shove

Foo

in their face though [21:17:35] I'm pretty sure that's not legal [21:18:29] RoanKattouw: interesting [21:18:31] looking now [21:18:33] ooops [21:19:40] In fact, in our use case (anchor == 'before'), ca2.nextSibling is never even accessed :) [21:20:40] Hm it seems Firefox is happy with

Text

that div being the heading marker I assume [21:21:56] Yes [21:22:21] My code was also having trouble with

Foo

Bar

[21:22:25] Not picking up the empty

[21:22:30] Which, BTW, is also displayed wrong [21:22:45] Because you added CSS suppressing

's display properties [21:24:32] well, the strategy there was that IE wants to use a combination of
and

depending on if enter or shift+enter is used - which makes no sense in a code editor [21:24:49] I know [21:24:49] so yes, I made paragraph tags have no margins or padding [21:24:58] But as a consequence, empty p tags are misrendered [21:25:09] as if they aren't there? [21:25:35] Yes [21:26:00] So basically if you insert empty lines in IE, they're just not there (presumably) [21:26:58] right, so we could play with the CSS to make that not happen [21:27:18] like padding-top: -1px margin-top: 1px or some crazyness like that [21:27:57] Good luck with that [21:28:12] i thought an empty P with no margin or padding would still be 1em tall or so and break the line [21:28:15] My fix for the anchoring thing works in Firefox now, gonna test in IE [21:28:19] Apparently not [21:28:27] At least in Firefox [21:28:32] Maybe IE disagrees [21:28:50] Although if IE does what you expect and Firefox doesn't, I'd be shocked [21:29:14] also, would this help? http://code.google.com/p/ierange/ [21:29:39] rather than always doing 2 versions [21:29:49] I saw that [21:29:57] Not sure it's beneficial [21:30:06] Because we've got it figured out pretty well at this point [21:30:26] And in some cases IE has methods that perform better than Firefox's, that'd be doubly bad with this [21:30:37] Like, IE has some fast method but Firefox needs a loop [21:30:57] So you do that loop, but then the underlying IE wrapper probably does a loop as well because it tries to provide non-native functionality [21:31:18] So we'd be making our code slower on a browser that already has a slow JS engine :) [21:31:40] RoanKattouw: excelent points [21:31:52] just came accross that when investigating an IE error [21:31:56] thought it was interesting [21:32:08] Yeah I think you may have shown it to me before [21:32:14] Like yesterday or the day before [21:32:39] Google has been working on allot of "make IE act like a normal browser" projects, including svgweb and excanvas - which sacrifice performance for compatibility [21:33:00] Yeah I think in certain cases in our code the performance hit is inexcusable [21:33:15] yeah, it's bad enough [21:33:18] Whereas in other cases there wouldn't be much of a difference because we're essentially doing our own emulation already [21:33:44] For instance something that's fast and easy in IE is getting the character offset of the selection [21:34:06] Grab the selection range, create a second range from the start of the document to the start of the first range, then gets its text.length, done [21:34:17] Firefox needs a DOM traversal there [21:36:38] *TrevorParscal writes IE compatability layer for W3C compliant browsers [21:36:50] not [21:40:23] *RoanKattouw yells at IE [21:40:33] Seriously, a textnode with .parentNode == undefined ? [21:41:03] html perhaps? [21:41:24] What do you mean? [21:41:46] *TrevorParscal scratches head [21:42:07] Not to mention that it's empty ^^ [21:42:19] Could it be because it got split off just before? [21:42:43] i was seeing ie splitting text nodes arbitrarily allot this morning [21:43:04] well, might not have been arbitrary, could have been a bug in the offsets thing [21:43:34] Aha [21:43:35] if you go into IE's firebug wannabe thing, and refresh the document in the HTML tab [21:43:39] Yeah I split it so that it because empty [21:43:46] look at the dom in the iframe [21:43:47] yeah [21:43:50] Weird bug in my splitting probably [21:52:28] I think I found it [21:52:45] I was doing some weird hacks faking newlines in cases of

wrapping [21:53:03] Which caused my wrapping logic that normally avoids splitting off empty textnodes to fail because of the fake newline [21:54:35] ok [21:56:02] Ugh there's another edge case in my

handling that's failing [21:56:06]

Foo

Bar [21:56:25] Becomes FooBar [21:56:37] Or \nFooBar if not at the beginning [21:57:36] we need text nodes at the body level which are preceded by a block like

get a new line prepended to them? [21:59:16] Or append a newline to the p [21:59:19] That's what I'm trying to do now [21:59:44] But it gets awkward for

Foo

Whee

vs.

Foo

Whee

[21:59:48] (where

is a wrapper of ours) [21:59:55] Of course that doesn't currently happen because we only use anchors [21:59:58] But still [22:00:06] I'd need to break out the traverser for this [22:04:19] fun [22:13:36] nkomura: foundation-l has public archives on the web [22:13:51] http://lists.wikimedia.org/pipermail/foundation-l/2009-November [22:20:51] *RoanKattouw jumps in glee [22:20:54] Yay my code works [22:22:56] Or well, not quite :( [22:32:40] RoanKattouw: proceed with cautious optimism, thar be dragons in your browsers [22:33:10] I know [22:37:34] http://img46.imageshack.us/img46/6725/picture1vgz.png [22:37:36] *RoanKattouw raises an eyebrow at IE and it's empty textnodes fetish [22:38:01] that is after just a little bit of new line removal/adding/typing [22:38:07] Oh no [22:38:09] Really? [22:38:12] yes [22:38:14]
in

? [22:38:33] *RoanKattouw considers just dumping
s in favor of

s altogether for IE [22:38:47] More generally, give browsers what they expect [22:38:50] Evil browser sniffing, sure [22:39:02] but a more dependable product [22:40:33] Yeah P [22:48:27] Oh great [22:48:33] I expected this would happen [22:48:40]

Foo

is illegal [22:48:49] And gets normalized to

Foo in Firefox [22:48:55] And God only knows what IE does with it [23:16:36] TrevorParscal: OK I've mostly fixed the

handling issues, except for when the text starts with "

== Foo ==

" [23:16:46] In that case it'll keep adding and removing the anchor [23:16:55] I'm gonna commit my code now and fix that last case tomorrow [23:17:04] Cause I need a reverse traverser for that and it's past midnight [23:30:00] TrevorParscal: Committed a crapload of fixes, off to bed. List of tomorrow: finish aforementioned weird edge case with

s, write

conversion, speed up
conversion [23:30:27] If you want to take any of those (except the first one), feel free, but e-mail me [23:56:04] hey usability, any JS hackers here? [23:56:17] that is, those working on the usability project