[06:43:50] thank you for your time werdna [16:44:28] werdna: how's it? [17:01:45] TrevorParscal: good [17:01:57] :) [17:01:59] didn't really like fully disappearing, I like sitting at 50% transparency better [17:22:45] TrevorParscal: latest version is live on the test wiki if you wanna take a look [17:24:11] right on [17:24:36] looking good man! [17:25:02] I like the menu effect [17:25:02] obviously we still need a little bit of adjustment, but the scalable box is a very good thing [17:25:04] it looks good [17:25:19] I'd really like to get Parul to take a peek, but I haven't heard much from her [17:25:27] she's probably busy and therefore avoiding me :P [17:25:37] oh [17:25:38] um [17:25:40] also, why are the images being cut off? [17:25:42] or getting married :) [17:25:43] he he he [17:25:53] she's been online and so on [17:25:55] werdna: looking into that [17:26:06] but I guess she's distracted by "real life" [17:26:08] whatever that is [17:26:09] yeah, but she doesn't normally work on fridays [17:26:20] plus she's getting mairried in a couple days or something [17:26:23] yeah [17:29:20] brion: I went with your fadey idea, check it out http://wiki.werdn.us/test/view/Talk:Main_Page [17:29:27] werdna: the way you are doing the div in the a [17:29:36] it's not how I laid it out [17:30:00] working on the icons being cut off [17:30:00] hey duuuude [17:30:23] TrevorParscal: yeah I know, I was adapting my existing stuff :) [17:30:25] oooh that fade in/out is slick :D [17:30:31] werdna: the icons are supposed to be background images of the a tags [17:30:44] if you don't do it that way, you will run in to all sorts of trouble [17:30:50] like icons being cut off? [17:30:51] sec [17:31:00] yes [17:31:05] let's try it with the non-mouseover state invisible like TrevorParscal suggests [17:31:14] and vertical alignment issues as well [17:31:38] werdna: background image vertical alignment works everywhere very well [17:31:51] div inside an a vertical alignment is a nightmare everywhere [17:38:33] brion: I did that already, can just revert the change where I changed it to your suggestion [17:38:40] :) [17:39:56] brion: force reload [17:40:20] TrevorParscal: it just seems freaky to use a background-image and padding to put an icon before some text [17:40:30] when there's a perfectly good normal way to do it, an img tag :/ [17:40:35] I'm wondering why we do that [17:40:37] really? we do that with our links all the time [17:40:40] (I'm sure there's a good reason) [17:40:41] like the external link [17:40:53] that's because the external link thing has to be done in CSS [17:40:56] img tags are not better [17:41:09] they have different strengths [17:41:18] It seems to be the more "normal" solution anyway :P [17:41:53] and also, in the code I gave you, in text only mode the links have text and everything [17:41:58] (no style mode I mean) [17:42:09] which is how it looks on devices that don't render CSS [17:42:28] werdna: neat! [17:42:30] and also how search engines see things - you should get really comfortable with looking at the page that way [17:43:05] it'd be great if we can put focus into the edit box when we start a reply, too [17:43:33] that's easy enough [17:43:39] do you like the way it scrolls? [17:43:47] TrevorParscal: isn't that what alt is for? [17:44:07] werdna: you should look and see how it looks in styleless mode [17:44:28] blank list items [17:44:29] i get a kind of weird jumping around sometimes when moving from icon to icon [17:44:30] ewww [17:44:33] at least if i let the tooltips pop up [17:44:57] yeah, the jumping effect is because it's being floated [17:45:09] couple notes on the drop-down menu: [17:45:12] it's supposed to be absolutely positioned in the top right in the post [17:45:22] a) requiring a click to open it is non-obvious especially with no hand icon on the button [17:45:33] b) if i move the mouse a couple pixels outside the menu, everything fades out [17:45:38] I vote for hover open [17:45:51] and i have to put the mouse back somewhere that's inside that individual message's area to get it to re-show [17:45:59] confusing for short messages, easy to lose the menu [17:46:08] and use fadeIn( 'fast' )/fadeOut( 'fast' ) not show() / hide() [17:47:21] I do use those, but I use hide() and show() for the suetup [17:47:40] the A tags in the drop down menu should be display:block as wel [17:47:50] (all in the HTML i gave you :) of course) [17:48:34] brion: you prefer the auto-appear to the fade in/out thing? [17:48:56] i think i might :) [17:49:03] overall look is cleaner [17:49:14] i do too - but it needs to be done right (a little more tweaking) [17:49:14] i'm undediced on the tools being on the right vs left or top vs bottom [17:49:19] *werdna prefers the fade in/out, but doesn't have strong feelings either way [17:49:38] if there's a very long message, and i look for a reply button at the end, i won't see it [17:49:42] TrevorParscal: also, I removed top: 0.5em from the style for the toolbar because it made them all hang at the very top of the page [17:49:44] since it's way up at the top, off my screen [17:56:30] You guys seen this? http://hackaday.com/2009/08/21/cbs-introduces-video-in-print-technology/ [17:57:22] werdna: it should be absolutely position top right of the post, or within the post but at the top of the browser if the top of the post is not visible [17:57:48] aka, follow the browser's scrolling to keep it in view but still contain it within the post area [17:57:58] is that doable in CSS or will that need some jQuery-fu? [17:58:24] heh [17:58:28] that can't be cheap :D [17:58:51] werdna: pretty sure thta would need some j-fu ;) not hard though, there may already be a convenient module [17:59:14] It's probably not too hard [17:59:21] in theory you could try swapping between regular positioning and position: fixed i guess, don't know if there's any benefit to that vs just bumping around the top position to follow scrolling [17:59:44] yeah, that's interesting - [17:59:53] add an event for when the window is scrolled, compare the scrollTop with the element's top, if it's higher then bump it down\ [18:00:17] first, let's get that thing absolutely positioned - it will get rid of the wiggling text effect too [18:00:43] wiggly text? [18:01:26] yeah, if the post is really short, because you have it floating it makes the post area grow on mouseover [18:01:42] I thought I just reverted that [18:01:48] I seem to have [18:01:51] clear your cache [18:03:46] ah [18:03:48] yes [18:03:50] good stuff! [18:05:12] can we get some more space between the left line on the post and the text [18:05:31] should be about equiv amount as we indent for the next inner line [18:05:59] that's 2em, I think [18:06:20] right on [18:07:36] I *really* want one of these [18:07:36] http://dvice.com/archives/2009/08/windowphone-con.php [18:08:35] wow [18:11:21] I want a future magical device too =) [18:12:37] we just decided that we already can use the palm of our hand as desktop wallpaper [18:13:06] why the heck would i want a transparent phone? [18:13:17] solid backgrounds are GOOD [18:13:18] my point exactly! [18:13:41] "The killer feature of this concept phone is its ability to change the look of the display glass to match the current weather conditions of your location (i.e. sunny day equals clear screen, rainy day equals virtual droplets on your screen)." [18:13:44] you don't want to know what your hand looks like? [18:13:46] why the HELL would i want that? [18:14:02] seriously! [18:14:08] ah, futurists :) [18:14:20] hey, I can't read anything cause it's raining.. even though I'm indoors... [18:14:24] hey, this sucks [18:15:01] brion: well, I don't think that's a killer feature [18:15:13] but I like the transparent, flexible bit [18:15:41] transparent means it'll be harder to read; there's no up-side [18:15:47] flexible sure [18:16:14] werdna: also, there's a trick to the mousover and using fades without leaving a trail of fading out toolboxes [18:16:47] what, add $j('.lqt-thread-toolbar').fadeTo(0,0);? [18:16:48] you just wait until the mouse has been over the box for like 100ms - really short time, but it works great [18:17:38] I'm happy with the no fade for now though [18:17:52] no, I mean before showing one toolbar, hide all the others [18:17:52] so, what's the issue with using a tags for the icons? [18:18:01] werdna: oh - yeah that's a good idea too [18:18:04] well, I can do it if necessary [18:18:11] i think it's a good idea [18:18:21] it just feels weird to be hacking it together with CSS [18:18:34] when HTML has a perfectly good system for making things not collide [18:19:00] http://wiki.werdn.us/test/view/Talk:Main_Page <- repeating for myself :) [18:19:17] it's all about 1. cross browser 2. what happens without CSS and JS 3. clean looking dom [18:20:51] dom dom dom [18:21:55] *werdna shrugs, it's mostly a hunch rather than any concrete objection :D [18:22:53] what I'm really looking forward to is the iPhone augmented reality stuff [18:22:55] werdna: i tested the code I gave you.... [18:22:57] that's gonna be seriously awesome [18:23:01] at least a bit [18:23:04] heh [18:23:11] I'm gonna change it in a sec [18:23:29] werdna will you be at Wikimania ? [18:23:32] yes [18:23:35] Cool [18:23:47] TrevorParscal: then again, clean DOM is out the window with the nested tl, tr, bl, br divs ;) [18:24:54] that's why it's 3rd priority [18:26:49] *werdna grumbles at refactoring [18:47:37] *werdna has a song by Flight of the Conchords in his head [18:47:55] "The humans are dead, we used poisonous gases to poison their asses (actually their lungs)" [18:48:42] BINARY SOLO [18:49:07] zero zero zero zero zero one! [18:49:10] 0 0 0 0 0 0 1 - 0 0 0 0 0 0 1 1 - 0 0 0 0 0 0 1 1 1 [18:49:17] 0 0 0 0 1 1 1 1 [18:49:28] ok that's just sad dude [18:49:35] :P [18:49:40] cause I'm spot on! [18:50:38] "i poked one it was dead" [18:50:50] sorry - you should be careful when quoting the conchords [18:50:55] i get all excited [18:58:34] TrevorParscal: committing fixes [19:01:46] and deployed :) [19:01:50] getting there :) [19:50:27] werdna: looking good man! [19:50:39] *werdna is looking at a vacation in September [19:58:24] yay [19:59:08] Brussels, Berlin, Copenhagen, Stockholm, and Helsinki [19:59:26] or the other way round, but the flights are more convenient that way [20:00:50] awesome [20:01:52] flight, actually [20:02:13] the plan (to me) is actually to take the train / ferry all the way to Helsinki, and get back by plane [20:19:07] you traveling with lauren? [20:37:38] indeed [20:37:49] *werdna returns from the kitchen with beef + black bean sauce [20:38:05] the only food I can cook is stir fry [21:06:51] TrevorParscal: got another rtl issue for ya :D https://bugzilla.wikimedia.org/show_bug.cgi?id=20344 [21:08:54] right on [21:09:32] interesting issue [21:09:36] will look into it [21:09:57] probably easy to fix by moving a couple of clears into the common styles or something, but want to check it out. thanks! [21:10:02] since you're already in the midst of rtl hell ;) [21:10:14] yeah [21:10:46] indeed, rtl is sometimes hell to deal with [21:13:10] Brion happy to notice all the rtl movement ... [21:13:38] :D [21:15:04] Brion what does it take to make LocalisationUpdate work for release 1.15 ?? [21:15:18] I would love to have the Wikieducator people localise and benefit [21:15:54] not sure if the current state works on 1.15 or not :) prolly not hard (as long as they're not using all the freak caching modes we are ;) [21:16:34] ... WikiEducator is used in some 50 countries I have been told [21:17:05] consider what happens if they get involved in translatewiki,net .... [21:17:15] awesome :D [21:24:45] brion: ugh, I haven't tested LQT in RTL [21:25:02] will probably get harassed about that at wikimania ;) [21:26:41] mwahahahaha [21:27:59] how about changing the order of operations in the abusefilter to right to left in RTL... I wonder how that is handled [21:29:39] that wouldn't be done [21:30:34] how do RTL languages handle mathamatical order of operations? [21:30:41] do they just do left to right? [21:30:47] or do they follow right to left? [21:33:50] *TrevorParscal doesn't know [21:35:15] they follow PEMDAS? [21:35:50] http://en.wikipedia.org/wiki/Order_of_operations [21:35:57] direction has no meaning [21:37:04] PEMDAS? [21:37:25] Parentheses, exponentiation, multiplication, division, addition, subtraction i guess [21:37:28] I always learned BODMAS [21:37:34] I have no idea what PEMDAS is, but direction matters for logical operators [21:37:45] Brackets (of) Division, Multiplication, Addition and Subtraction [21:38:01] true && false || true for example [21:43:15] actually that particular one is the same both ways, but meh [22:01:07] Simetrical: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/55269#c3653 [22:01:22] i'd love to discuss this further if you like [22:02:00] Sure. Sorry for the harsh language, I was feeling cranky that night. :D [22:02:28] no worries he he he [22:02:30] TrevorParscal, for one thing, I'm going to bet that you currently don't serve the tools to Chromium, Iron, or Iceweasel, to name three off the top of my head. [22:02:38] Even though those are identical to Chrome/Firefox. [22:02:44] (unless your UA sniffing is robust enough) [22:02:59] we should test them and add those to the list [22:03:07] You can't test all browsers that will ever be made. [22:03:13] agreed [22:03:17] Remember, this code will probably make its way into core and be used by third parties for ages. [22:03:34] we are focusing on http://usability.wikimedia.org/wiki/Releases/Acai/Compatibility_Matrix [22:03:39] Even if we can keep up with new browser releases -- and I really doubt we can even do that -- we can't keep third-party sites up-to-date. [22:03:46] and those toolbar marks are wrong [22:03:49] That's fine, just don't ban browsers unless you definitely know they don't work. [22:04:41] It's better for someone with a bad browser to get somewhat broken functionality because they're using a bad browser, than for someone using an odd but good browser to not get good functionality because you haven't heard of them. [22:05:26] What you have now is exactly what causes the "must use NN4/IE4 or higher" phenomenon today. [22:05:29] *Simetrical pokes brion for comment [22:05:50] we prioritize quality in the user experience above most everything [22:06:08] so, we fundamentally are against giving people broken software [22:06:08] Yes, and quality is degraded if you deprive them of functionality just because you haven't heard of their browser. [22:06:38] It's better to give broken software to broken browsers, than to not give good software to good browsers. The former discourages use of broken browsers, the latter discourages use of good browsers. [22:06:46] Of course, it's best to not give broken software to anyone. [22:06:50] if we havn't heard of their browser, we have no way of knowing if we are going to give them a quality experience or not, so we error on the side of safety [22:06:56] But if you don't know, then assume it's good, not broken. [22:07:17] Erring on the side of safety is giving them the full features. [22:07:23] There's no really safe side here, though. [22:07:31] Either you risk giving them broken features, or fewer features. [22:07:57] i see it differently because the less common browsers are the ones I tend to spend the most time getting to work (aside from IE of course in which case it's common and time consuming) [22:08:10] Which less common browsers? [22:08:20] opera [22:08:20] Simetrical: wot [22:08:24] for instance [22:08:32] brion, http://www.mediawiki.org/wiki/Special:Code/MediaWiki/55269#c3653 [22:09:02] TrevorParscal, if a browser didn't make the safe list, it's more likely that it will work perfectly than fail horribly, IMO. [22:09:10] 2% of the internet uses opera 9 - 9.5 and there always seems to be some tweak needed to get things to work in that browser - maybe not as bad as IE but still [22:09:12] Weird browsers that people actually use tend to be new and shiny. [22:09:24] yes, this is definitely wrong. we should have the toolbar ALWAYS on unless we KNOW it won't work on a PARTICULAR system (or better yet if our capability tests determine that necessary caps are missing) [22:09:29] Weird browsers that are old and broken usually aren't used. [22:09:51] The primary reason people use old and broken browsers is because it's what they've always used because it was the standard at some point. [22:09:57] E.g., IE or Netscape or whatever. [22:10:30] Anyway, the point is, it's better to hurt users of bad weird browsers than to hurt users of good weird browsers. [22:10:49] quality experience means not fucking people over and saying "sorry you must have version X of software Y even though your browser actually works fine" [22:11:16] Remember also that two major browsers (Firefox and Chrome) are 1) open-source, but 2) third parties can't use the official trademark for custom compiles. So user-agent sniffing might not detect them as Firefox/Chrome even though they're functionally identical. [22:11:17] your approach doesn't ensure quality user experience, it ensures new browsers can be created without effect on user experience [22:11:33] Nothing *ensures* quality user experience except explicit testing. [22:11:41] The question is what to do if we're not sure which way is better. [22:11:50] Because we haven't tested their browser. [22:12:15] The best approach is to assume that unknown browsers are standards-compliant and featureful. That's the most futureproof solution. [22:12:33] After all, new browsers tend to support whatever old browsers support, but not conversely. [22:12:43] I totally understand your points, I've stated my points, if brion wants to overrule me, I can live with that - no worries [22:12:50] k. [22:13:19] thanks [22:16:54] TrevorParscal: can i confirm also that we're not using css error hacks to try to target things to ie 6? we should be using conditional comments for that [22:17:04] and is there anything else based on user-agent sniffing that doesn't need to be? [22:17:39] What's wrong with CSS error hacks? They're rather convenient. You can't include conditional comments in CSS, you have to make a whole new file and add extra HTML junk. [22:17:43] (AFAIK) [22:18:16] Simetrical: they're a) unclear b) unreliable as you might trip up something else with the same error or not trip up the browser you were targeting if they fix that error but not the thing you were working around [22:19:29] They're mainly useful for targeting IE6 and IE7 at this point. All new browsers are pretty consistent with CSS parsing. [22:19:32] i make clear code comments that explian what the deal is every time [22:19:39] So it's really a very small, fixed set of old browsers. [22:19:44] No matter what, we want to avoid the situation where the user doesn't get a toolbar at all. There might be some standard library checks we could run... [22:19:57] Not likely that any new browser is going to not implement child selectors, or mess up * html. [22:19:59] for the 'unknown broser' case [22:20:14] nimish_g: if you fail to produce the new toolbar, fall back to the old one [22:20:18] should be pretty straightforward! [22:20:26] brion: [22:20:34] it's not straigtforward at all [22:21:08] if we had a toolbar.showUpForUserProperly() function I'd be all over that =) [22:21:13] can you give an example of how it's not straightforward? [22:21:35] a failure mode which involves a completely missing toolbar and *no* errors or exceptions or detectable case of 'oh the entire element is not there'? [22:21:51] what makes the toolbar "functioning properly" has to do with a combination of support for jquery, jquery-ui, specific CSS layout capabilities, and lots of browser specific bits to fix things that browsers do strangely [22:22:28] brion: we had an opera and IE issue while testing, where layout issues made elements appear as far as the browser was concerned, but not appear in any visible place as far as the user was concerned [22:22:44] nimish_g: can you detect their location? [22:22:47] eg item off of screen? [22:23:08] stuff like this... http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/UsabilityInitiative/js/plugins/jquery.wikiEditor.toolbar.js?r1=54465&r2=54476 [22:23:48] ok, so you've solved that issue already. [22:23:57] if/when you get another report, find that one. [22:24:01] my point being, this type of thing is not testable [22:24:12] in an automated way [22:24:34] stick to standards, give the best experience possible everywhere we can, and when the 0.00000001% weirdo discovers a bug, we resolve it then if possible [22:24:59] the point is, don't fuck everything up for 5% of visitors because 0.000000001% of visitors may have another problem [22:25:27] I think that falling back to the older edit tools is far from ... that [22:25:43] but it's easy to change the logic [22:25:54] use the good ones unless we detect a failure or know that there's an undetectable failure. [22:25:59] we can go with allowing unknowns [22:26:06] yes, please do [22:26:30] hey all, one of the reason for the browser detection was to support the new toolbar in RTL langauges [22:26:42] how about something simple like a "can't see the toolbar?" link for browsers we don't recognize? [22:26:45] I guess I felt like we talked about this already and now you've changed your mind - which is fine, but ... yeah I'm just confused [22:26:53] the blank toolbar for RTL in IE7 was pretty bad user experience [22:26:57] i've never changed my mind -- this is how we've done everything we do for the last 8 years [22:27:06] i don't know how you got the impression otherwise? [22:27:27] nkomura: then given a known detectable problem, we fix it. that's how things are done [22:28:04] *TrevorParscal is fine with that [22:28:43] brion: trevor spent two weeks trying to fix the problem for RTL, and the problem crops up either IE6 or IE7 [22:29:03] so we've got to the point of disabling either the beta or toolbar from RTL languages [22:29:04] nkomura: if it can't be fixed for that combination for now, then disable it for that combination until it can be fixed. [22:29:12] that doesn't mean "go turn off everything you haven't happened to test yet" [22:33:11] i'm fine turning off the new toolbar until the browser detection [22:33:46] detection's logic is changed to support unknown future browsers [22:34:03] brion: here's my idea: we have 2 lists: one "works" list, one "not works" list.... that .0000000001% we don't know about will always get a link going "can't see the toolbar?" [22:34:15] and if they go "nope, can't see it" then we give them the old one. if not, they get the new one [22:35:14] nimish_g: that ain't half bad [22:35:19] that way we 'support' new browsers but avoid the condition that someone just can't edit =) [22:37:19] basicly, you should rarely if ever care what the user-agent string is [22:37:29] nearly all detection should be based on actual capabilities exposed in the browser [22:37:49] user-agent checks should pretty much be limited to the case where you've got no other way to detect a known problem in a particular known browser [22:38:15] otherwise you're basically taking everybody you didn't test and saying "you're worthless and i'm not going to support your browser even though it probably works fine" [22:41:26] right, which is why I think the "we know works" "we know fails" and "assume it works, if not they click on something to get the reduced version" would be perfect. I don't know if we have (or if there even exists) a library we could go through to be like "ok, does JS function x behave the way our code expects? check. how bout this one? check" [22:43:04] much of the time you're checking to see if functions/attributes exist, or if you get an exception in response [22:43:14] sometimes the browser just does wacky stuff and it doesn't look right :) [22:51:04] It takes a ton of time to do proper capability testing. [22:57:13] brion: so, remember when we were talking about having a user daily contributions count table, and based on that, we could find out how many contributions they made in the last 6 months or so? [22:57:47] nom nom yes [22:58:45] we were thinking about making it more granular, so we would have 3 months, 6 months and 1 month in the click tracking table. This would also mean that every time the click-tracked users made a click, we would be summing up on that table 3 times instead of once...does this sound like a terrible load on the DB? [22:59:25] 30 rows, 90 rows, and 180 rows of integers... prolly not too bad :) [22:59:55] those could be rolled up into totals you only have to touch once a day too, but thta may be unnecessaary