[17:40:18] hi all [17:42:16] hi [17:42:21] hey [17:43:04] did u notice the first new textformatting icon made by the community? [17:43:35] http://commons.wikimedia.org/wiki/Vector_edit_toolbar [17:43:41] chinese [17:44:08] though it looks like that icon isn t implemented yet [17:58:36] nice [17:58:44] the font size seems a little small [17:58:59] *nkomura goes to a meeting room [17:58:59] hard to tell for me [17:59:05] hello [17:59:10] hi trevor [17:59:21] :) [18:16:44] parutron: hey, there? [18:17:12] Oh crap, the meeting [18:17:17] Have you guys started yet? [18:17:18] we're done [18:17:20] *RoanKattouw just finished dinner [18:17:21] don't worry [18:17:24] lol [18:17:30] I will give you the gist of it [18:17:31] That's fast [18:18:02] "fix bugs, make good use of adam's time in SF, wounds like we will be using bolt peters for our final study, but nothing is concrete" [18:18:21] OK [18:18:33] I'll be starting work soon, will be poking at bugs for about two hours [18:18:39] Then off to watching the Olympics [18:24:22] TrevorParscal, nimish_g and RoanKattouw, i cleaned up and reorganized the outstanding issues in the "Bugs" sheet of the test matrix [18:24:23] http://spreadsheets.google.com/ccc?key=0AsH79AXxmoh-dEhRZ0JFVmtaOTFEeVFvano2cTk5ZHc&hl=en [18:24:36] thanks! [18:24:40] closed bugs are hidden [18:24:51] cool thanks [18:25:26] nimish_g: I fixed the highlight code so your template stuff now sort of works again [18:25:51] There's an issue with added newlines there, but aside from that any remaining issues are like 95% likely to be in templateEditor rather than highlight [18:26:53] (basically what happens is

foo{{bar|baz}}whee

becomes

foo

....{{bar|baz}}...

whee

which translates to "foo\n{{bar|baz}}\nwhee" [18:27:23] hm, ok [18:27:33] I'll check it out in a bit, looking at some bugs now [18:27:55] RoanKattouw: even after I changed highlght divs to spans? [18:28:12] TrevorParscal: templateEditor inserts divs for more complex markup [18:28:49] nimish_g: In response to that: if you can manage to do your magic without using block elements (i.e. just spans, stuff that's legal to put inside a

), please tell me, that'd be nice [18:32:20] can anyone tell me what this button does? http://commons.wikimedia.org/wiki/File:Button_nbsp.png [18:32:36] inserts a non-breaking space [18:32:38] RoanKattouw: span with display:block? [18:32:46] that's a HORRIBLE icon though [18:32:46] wow [18:32:56] so thats a formatting thing? [18:33:08] well, normally lines can break between words [18:33:10] aka, spaces [18:33:38] a character is a space, visually, but text wrapping will NOT break on it [18:33:58] ok thx [18:34:54] nimish_g: Yeah but I'm talking about the

stuff in there, that's illegal inside of s or
s [18:35:09] aah gotcha [18:36:46] what's he using lists for? [18:36:53] the buttons? [18:37:09] No idea [18:37:21] svn up, insert a template call with parameters and inspect the resulting DOM [18:40:23] *TrevorParscal dusts off the templateEditor preference checkbox and clicks it [18:42:59] indeed [18:43:04] it's the W icon [18:43:19] yeah, so that will need to be changed from using UL [18:43:41] And it needs to be span-safe, [18:43:51] So presumably you need like a span with a background-image or something [18:44:05] normally I encourage the use of UL/LI for things like that, but that's mostly because I want it to have a sane HTML strcutre with no CSS/JavaScript [18:44:27] I get that [18:44:40] But if we can pull this off without using block elements, that'd be awesome [18:44:53] yes, we need to make it span safe [18:45:10] in this case, if they have CSS/JavaScript disabled, they aren't seeing the entire editor anyways [18:47:01] Yeah [18:47:36] OK so who's poking at what right now? [18:49:14] not me [18:49:32] I'm playing with copy paste bugs [18:50:06] *RoanKattouw claims bug 22479 (specialchars inserting at beginning) [18:54:05] RoanKattouw: does 8pm CET monday Feb 22 work for you for the team meeting? [18:54:36] RoanKattouw: r62534 seems to have broken undo/redo. what were you aiming to accomplish with the change to delayed change? [18:55:10] nkomura: Wait, Monday? It was gonna move to Wednesday initially, right? [18:55:19] right [18:55:29] adam_miller: TOC+templateEditor updating on delayedChange [18:55:38] since wed next week may not work for you, i'm thinking of moving it to monday [18:55:50] nkomura: Works fine for me, but so does Wed @ 11 AM PT [18:56:15] adam_miller: How does it break undo/redo? [18:56:38] Was it moving down the context.oldHTML assignment? [18:56:58] hannes-t: does 8pm CET next wed (2/24) work for you for the team meeting? [18:57:37] RoanKattouw: still looking into it, i just noticedit command z wasn't doing anything anymore [18:58:12] OK [18:59:01] Hm I don't see how that particular rev would cause that [18:59:21] adam_miller: Do you know the SVN command to revert a revision locally? [18:59:35] yeah, but i can also see what I think it causing the problem [18:59:39] so i'd rather just fix it [18:59:56] it's doing the oldDelayedHTML change comparrison twice now [19:00:33] so if it IS different, by the time it gets to the updateHistory function, it doesn't think it's diffrent any longer [19:03:01] nkomura_mtng: yes. 8pm next wed is fine! [19:04:58] adam_miller: Aah [19:05:13] adam_miller: Then the oldDelayedHTML assignment in my added code should probably die [19:05:54] is it ok to move that event.data.scope = 'realchange' into the update history function? [19:06:16] *No* [19:06:30] That's exactly why I put that code there in the first place [19:06:40] OTOH, well... [19:06:45] ok then i'll make the updateHistory funciton assume that things have changed [19:06:47] I guess it could *maybe* go there [19:06:57] Yeah that'd be much cleaner [19:07:03] *RoanKattouw facepalms for not thinking of that himself [19:07:09] It's only ever called in change handlers anyway [19:08:34] RoanKattouw: does a change of cursor position count as a 'realchange'? [19:08:43] Nope [19:08:55] alrighty then [19:09:00] A 'realchange' is a change where the HTML actually changed [19:09:55] That definition is not even narrow enough for me (expanding/collapsing templates changes classes hence changes HTML, but should be a 'realchange'), but making it narrower would be too slow [19:10:04] *shouldn't [19:12:23] hey hannes-t [19:30:28] http://usability.wikimedia.org/wiki/Text_format_icons [19:46:37] Bleh, the algorithm I wrote to move the cursor/selection to the right place after inserting text was fundamentally broken in a quite embarrassing way [19:47:06] It assumed it went through the lines in order while the surrounding code was really traversing lines in reverse order [19:47:24] Of course I only tested it with numLines = 1, the one case in which that doesn't matter [19:51:12] nimish_g: r62589 [19:51:21] nimish_g == investigatory ninja [19:51:36] this one though... https://bugzilla.wikimedia.org/show_bug.cgi?id=22398 [19:51:37] hmmm [19:52:39] awesome, take *that* webkit-on-apple! [19:52:52] lol that cause is ridiculous [19:52:56] Way to go guys [19:54:24] TrevorParscal: $( this.childNodes ) is dangerous if you're not sure this.childNodes doesn't contain top-level textnodes [19:54:41] Because jQuery drops textnodes a lot [19:54:57] RoanKattouw: hmm [19:55:06] I recommend using .html() in some way [19:55:07] well, I'm selecting children of a span [19:55:15] so, how could they end up being top-level? [19:55:18] Hmm, $($(this).html()).insertBefore(this); ? [19:55:26] TrevorParscal: top-level inside the :P [19:55:33] hmm [19:55:38] I mean stuff like
foo
bar [19:55:49]
Where bar will be in a textnode that's a direct child of the span [19:56:00]
RoanKattouw: basically apple-on-webkit pastes different inside iframes than anything else in that it wraps all pasted content inside these apple spans [19:56:24]
nimish_g: I get that, but if there's raw unwrapped text /inside/ these Apple spans, Trevor's code will break [19:56:46]
but it's not breaking even where there is raw text in there [19:57:04] like, selecting a couple of words, copy it [19:57:06] then paste it [19:57:28] my clipboard inspector says its some words [19:57:33] and it worked fine [19:57:53] Interesting [19:58:41] allthough selecting text with a link in the middle seems to freak out a bit [19:58:53] it will give the link it's own line [19:59:17] ha, jQuery doesn't drop TextNodes in this particular case [19:59:39] we could check to see if the paste is
text
or just text and wrap it in a
to fix it [20:00:43] Why does it give the link its own line? [20:00:53] And why do we need
wrapping? [20:01:32] because the algorithm steps over each top level non .wikiEditor element [20:02:14] Ah [20:02:15] once you expand the span out, if there was just raw text in there instead of several
elements you get strange behavior [20:02:31] Ah right so these s don't get inserted into
s but outside them? [20:02:44] However, when such a does get inserted in the middle of a
, it shouldn't be double-wrapped [20:02:45] so we need to ensure that it's being wrapped in a
if it's just some text and other inline stuff [20:02:53] Yeah but only if it's top-level [20:03:12] RoanKattouw: these spans only get put on the outside [20:03:25] Interesting [20:03:33] So they don't get inserted at all when you paste into the middle of a
? [20:07:52] no, they get inserted no matter what from what I can produce [20:07:59] OK [20:08:16] So my question is, is it possible to get
Previously existing textpasted textmore text
? [20:08:27] Because in that case we should not
-wrap the stuff inside the span [20:09:06] *RoanKattouw wonders how pasting multiline text in the middle of a line is handled [20:11:00] hannes-t, Roan said you may know about UI toolbar icons. Are template for them available anywhere? [20:15:03] TrevorParscal, nimish_g: Enjoy you're lunch, I'm off [20:15:04] *your [20:15:08] *RoanKattouw_away fails [20:15:41] brb [20:15:44] lunch [20:29:23] i'm back [20:52:48] MS word issues fixed! [20:53:04] (actually MS rich text paste issues fixed) [20:58:31] cool [20:58:37] nimish_g: Recombine and bump style versions? [21:00:45] he didn't have make installed on his computer... [21:00:50] he's getting the IT guy [21:00:57] RoanKattouw: https://bugzilla.wikimedia.org/show_bug.cgi?id=22398 [21:01:20] OMG, a computer without make? [21:01:31] s/computer/non-Windows computer/ [21:02:20] nimish_g: OK I'll recombine and bump this one for you then [21:02:29] this bug started out as something we actually did fix, but somewhere in the middle they start redefining what the bug is, which make it a duplicate of #22428 [21:02:52] i'm inclined to close it, but wanted your take on the situation [21:03:11] *RoanKattouw reads the full bug [21:04:41] Are both issues resolved? [21:05:16] It looks like bug 22398 started out as a dupe of bug 22428, then became something else (copy from wikiEditor to extenal editor), then was changed back [21:05:53] If I got that right, my recommendation would be to repurpose bug 22398 to be about the wikiEditor-->external editor bug and note that the other part is covered by bug 22428 [21:06:13] (and possibly close 22398 as well if the wikiEditor->external editor paste issue is fixed already) [21:06:46] can you recreate this wikieditor->external editor issue? [21:06:48] I cannot [21:06:56] but maybe it's the texteditor I'm using [21:07:27] *RoanKattouw tries [21:10:12] Yes, I can [21:10:22] Paste into a text editor rather than a rich text edito [21:12:20] yeah, I did that [21:12:26] what's it doing for you? [21:12:59] Inserting blank lines [21:13:14] Presumably it interprets
Foo
Bar
as "Foo\n\nBar" [21:15:42] ah [21:15:59] well, out of firefox it does seem to have extra new lines [21:17:09] so, to fix it we would need to not use
content
and use content
instead [21:17:10] nkomura: so the issues outstanding with bug 22398 were: 1) MS word paste and 2) copy-paste from wikis? [21:17:18] which cannot work for a billion or so other reasons [21:17:23] if that's all then we got it [21:17:49] on copy, changed the content to a copy-friendly version, then 100ms later change it back... [21:17:52] *TrevorParscal cries [21:27:37] nimish_g: i haven't been following what have been resolved today [21:28:02] so copy/paste from a word document works cleanly now? [21:28:51] yes [21:28:59] nice! [21:29:07] no code insertion? [21:29:14] no code insertion =) [21:29:23] double nice [21:29:45] let's compile all fixes at the end of day today [21:29:54] and rerun the test for the night [21:30:07] our stuff is not ( going to be / meant to be ) compatible with wikEd - any thoughts on that? [21:30:26] we have https://bugzilla.wikimedia.org/show_bug.cgi?id=20498 which is assuming that we are supposed to be compatible with them [21:30:47] i support not to be compatible out of the box [21:31:12] i don't mind them working around our tools [21:31:19] I don't want to so things just to break their stuff [21:31:33] but we can't really go chasing after them for compatibility issues [21:31:53] i agree [21:31:56] that's a long thread [21:32:02] i need time to read [21:33:16] but our position does not change - we cannot provide support for gadgets, but will offer expandability where we can [21:34:04] it doesn't help that "cacycle" looks like "calcey" [21:40:31] TrevorParscal: wikEd and wikiEditor provide much of the same functionality. People should use either, you can't really overlay them. If wikEd has some button with an awesome feature behind it, add it to our toolbar using the API [21:41:17] RoanKattouw: right, I mean, they could do things to tie into our tools, but supporting gadgets is a slippery slope [21:41:29] Yes [21:41:48] *TrevorParscal strums guitar chords while reading bug reports [21:42:24] My position is that we don't make an effort for that. If there's some easy way we can accommodate for easy things, Gadget maintainers should report that and we can fix it [21:53:24] parutron ... are you interested in supporting other languages for bold and italic ? [21:53:40] happy to ask for them .. on translatewiki for instance [21:54:16] hello GerardM- [21:54:25] Hoi [21:54:32] we definitely are.......and sharing with translatewiki would be excellent. [21:54:45] i just pushed a blog post on the basic ins and outs. [21:54:56] http://blog.wikimedia.org/ [21:55:40] there is for instance no cyrillic among them ... no devanagari [21:55:56] that is exactly what we are looking for people to help us with. [21:56:02] Ok [21:56:03] it looks like someone has already added a chinese character! [21:56:09] yes [21:56:12] http://commons.wikimedia.org/wiki/Vector_edit_toolbar [21:56:16] I noticed [21:56:25] yippee - crowdsourcing design will be a new frontier for us. [21:57:43] are you ok when I use your picture on my blog ? [21:58:03] the message being that you are looking for this [21:58:35] sure, though the usability logo might be more appropriate? totally up to you! [21:59:07] I use a lot of images ... it makes it more readable and better read [21:59:16] agreed ;) [21:59:22] thanks so much for your help. [21:59:59] let me know what size you want the image and i can send it over. [22:01:20] Do you have a profile at translatewiki.net ? [22:15:13] parutron: Incidentally, that makes me wonder which languages you speak [22:21:09] i do not have a profile there [22:21:25] i speak english, a bit of french, sign language [22:21:26] tee hee [22:22:13] I take it that you mean American Sign Language ? [22:24:06] si senor. [22:24:09] oh yeah and some spanish [22:24:12] ;) [22:24:41] for your info ... we want to have a Wikipedia for American Sign Language [22:24:55] it will be written in sign language [22:25:05] eh SignWriting [22:25:47] GerardM-: Has this gotten through langcom yet? [22:26:45] the problem is not langcom but it being a top down script written in lanes with a script that is currently not part of Unicode [22:27:09] it is eligible when we can technically host it [22:27:29] it should be a laboratory project [22:28:14] it will make a hell of a difference when it is supported by the WMF [22:29:18] adam_miller: I don't like the hacks throwing delayedChange() in two unrelated places (ready and change), but I can't think of a decent alternative offhand [22:29:24] If you can find one, I'd appreciate it :) [22:29:45] wow - that's a major undertaking. [22:29:50] RoanKattouw: why's it a hack? [22:30:14] Because you're calling an event handler when that event didn't actually occur, the relevant code should be broken out into a function if possible [22:30:50] it is ... but once they have cracked it ... and it seems they have it will potentially support over 200 sign languages [22:31:18] just consider the user interface implications [22:35:14] TrevorParscal: Do we really need
wrapping in Firefox? [22:38:58] RoanKattouw: time check :-) [22:39:13] don't you have a driving exam tomorrow? [22:39:17] Yeah at 2 pm [22:39:29] And there's more skating later, they're re-prepping the ice now [22:39:44] RoanKattouw: yes [22:39:48] RoanKattouw: agaik [22:39:54] *afaik [22:39:58] RoanKattouw: ok I'll try and get templates working again and pass you any notes along the way [22:41:03] nimish_g: Nice. There's issues with not updating properly (added a TODO next to the empty onSkip() function) and with the template name suddenly becoming empty after messing with the surrounding text a bit [22:41:17] so folks, please make sure that prototypes and deployments are updated with the candidate build for QA before the end of the day [22:41:34] nimish_g: Like we said, if you could cram all of this in s and stuff that'd be awesome and you can unconditionally set splitPs: false [22:43:13] (in that case) [22:59:14] hm, RoanKattouw_away, there seems to be newlines all over the place [23:19:15] nimish_g: You mean before and after template wrappers? [23:19:35] RoanKattouw: no, in the middle of the template text [23:20:20] {{template | blah blah }} becomes [23:20:21] {{template | blah [23:20:21] blah [23:20:21] }} [23:20:45] something like that, you get what I was trying to type, the line breaks are within the template text [23:20:46] nimish_g: I know, this'll be fixed automatically once you manage to get everything inside a [23:21:04] Oh wait [23:21:12] The ones in the *middle* of template text I don't know about [23:21:16] yeah [23:21:38] RoanKattouw: I can't reproduce https://bugzilla.wikimedia.org/show_bug.cgi?id=22485 post r62580 either [23:21:39] I'm still investigating [23:21:42] Do these newlines appear in the editbox while editing, or only in the changes tab or in the edit box on save&reload [23:21:43] shall i just mark it fixed? [23:22:09] You mean you can't reproduce the entire bug? I just commented on the specific JS error [23:22:19] I didn't even fire up IE, just fixed the JS error [23:22:42] they appear in the edit box while editing [23:22:56] rather, in the iframe [23:23:06] the edit box isn't showing up anymore [23:23:23] RoanKattouw: I can't reproduce the bug - I thought the error was perhaps causing it.. but wasn't sure [23:23:43] TrevorParscal: you mean the 'randomly can't select things' bug? [23:23:51] nevermind [23:23:53] i got it now [23:23:57] dang - IE sucks [23:24:03] nimish_g: That's interesting. What's the HTML content? [23:24:24] nimish_g: ... and is your stylize function trying to do fancy stuff with these parameters in any way? [23:25:11] RoanKattouw: it's tons of
's wrapping random bits of text [23:25:28] Ugh [23:25:32] which params? [23:25:34] Which browser? [23:25:37] FF [23:25:40] 3.6 [23:25:42] Hm [23:25:53] Well I think it should be fixed once you get this to all fit in inline elements [23:26:07] That means the text will no longer be outside a
and Firefox shouldn't try to put it in one [23:27:17] I'll try turning the 'div' into 'span' and getting rid of the
stuff to see if it works for now [23:27:45] Right [23:28:03] And set splitPs: false unconditionally rather than splitPs: model.isCollapsible() which I have now [23:29:55] where's splitPs? [23:30:39] nvm found it [23:34:40] RoanKattouw: k, so doing that doesn't bork the display of wikitext too much, but if you expand the template and type anything inside the template text at all, it goes nuts [23:34:56] as in it creates several random duplicate wrappers for templates everywhere [23:35:41] RoanKattouw: it would be allot simpler if we could just add/remove classes to/from existing
elements for headings [23:35:54] rather than be adding/removing elements [23:36:07] have we given this much thought? [23:36:21] nimish_g: Update getAnchor: [23:36:33] *RoanKattouw should really document the highlight API some time [23:36:45] TrevorParscal: We have not, and it would be a lot simpler indeed [23:36:52] foreach
if the contents match a heading, mark it as such [23:37:00] I can make that an option in the highlighter [23:37:17] it may not work for all things, but that would be so much faster and less wonky for the toc [23:37:31] Aye [23:37:42] I'll do both of those tomorrow (
class marking and docs) [23:38:13] mk, actually, RoanKattouw I'm just gonna start beating this code into submission and give you a damage report tomorrow... [23:38:33] If you can avoid it please don't touch the highlighter [23:38:54] It has the support you need, the code you need to beat up is very likely in the marker object [23:39:03] (getAnchor, onSkip, afterWrap, etc.) [23:39:07] ok [23:39:23] As there's zero docs it's not obvious how they work :( yet [23:39:38] But I can give you a very basic definition of each property in there if you like [23:39:50] the CSS voodoo I did for IE8's lots of extra lines in the editor doesn't work anymore now that we wrap
tags in
tags [23:40:27] Bleh [23:40:44] ok ya what do the params do? [23:41:44] OK so start and end are byte offsets into the wikitext, simple enough [23:42:20] type is a string identifying what it is you're highlighting, doesn't matter what it is as long as it doesn't conflict with any other code that highlights stuff [23:42:59] anchor is 'wrap' or 'before', indicates whether you want templateEditor-style wrapping or TOC-style anchoring [23:44:46] splitPs is a boolean telling the highlighter whether it has to split up
s in order to insert the marker. Should be true for block-level markers, but currently has the newline problems you mentioned. This option may disappear in the future [23:45:20] afterWrap is a function that gets executed after your text has been wrapped, and is passed a DOM object referring to the wrapping as a parameter [23:45:28] ...why would you create a boolean that, when set to true, randomly breaks up lines? [23:45:39] "randomNoise: false" [23:45:58] nimish_g: Because
foo
bar
baz
is illegal and tempts browsers into slowly corrupting your HTML [23:46:33] aah,
s can't have any block elements in them? [23:46:36] Exactly [23:46:50] I think Firefox ended up moving my
before the
, changing the order of the text [23:46:51] well that's silly of them [23:46:57] You really don't want that to happen [23:47:01] yeah [23:47:18] ok [23:47:36] comitting less scary CSS [23:47:40] OK so moving on: beforeUnwrap is similar to afterWrap, gets run just before a wrapper is removed (unwrapped) [23:47:41] that works :) [23:48:15] I'm not sure beforeUnwrap is currently complete, you can test it by editing a template's source and remove brace so it's no longer a template, that should trigger unwrapping [23:49:15] onSkip is a function that's called when the highlighter visits your wrapper but decides to leave it alone. It basically means that some wikitext has changed and you may or may not want to update your marker [23:50:36] getAnchor is a function that's very easy to get wrong (I've struggled with it quite a bit). What it does is it gives you two textnodes that contain the start (ca1) and the end (ca2) of the to-be-marked text, and asks you to find out whether that text happens to be wrapped already. You're supposed to return the wrapping if so, and null if not [23:51:50] And finally model is just a custom attribute that templateEditor uses to pass the model around. It's only needed because I needed model.isCollapsible() so early, you can move the model creation and storing back to stylize once you don't need the conditional splitPs any more [23:52:47] The TOC module also generates marker objects like these from line 110 down, you may want to read that as well to get a better feel of how they work