[00:01:56] ryasmeen, awesome, they're all assigned to me, right? [00:01:58] i'm going by the list [00:02:23] yes mooeypoo: they are [00:02:26] sure [00:03:55] speaking of which, can we close this? https://bugzilla.wikimedia.org/show_bug.cgi?id=51290 and https://bugzilla.wikimedia.org/show_bug.cgi?id=64303 ? [00:15:53] are any of those image bugs parsoid-related? [00:18:55] so far not that I saw. [00:19:21] Most of those are behavior issues in VE. I think RoanKattouw_away mentioned something about a parsoid issue, but I am not sure exactly what it was, and I didn't replicate anything yet. [00:36:19] mooeypoo: yeah, roan ran the parsoid issue by me. it related to _ and ? characters in image filenames. [00:36:40] i hope he bugzilla'ed it. [00:36:44] cscott: He did. [00:37:36] mooeypoo: When you convert an image type, it changes from
to . This means Parsoid's SelSer doesn't get a chance to fix things, so Parsoid nastily encodes the name of the file. [00:38:13] James_F: that's not quite accurate, but probably close enough. [00:38:42] Hmm. [00:38:51] basically parsoid doesn't try hard enough to prettify resource names we are getting from HTML without the benefit of serlser/data-parsoid hints. [00:39:02] cscott: The bug is less inaccurate. :-) [00:39:05] I was trying to keep all the attributes from type to type but I think that might (maybe?) produce a problem as well. [00:39:35] should after much gear grinding and gnashing of teeth become [[File:foo b?r.jpg]] [00:39:36] I have a feeling I'll want to adjust inline images a bit to make them support the new system a bit better. For now they're good, but we don't have the advanced features yet. [00:39:40] mooeypoo: Oh, yes, merge https://gerrit.wikimedia.org/r/#/c/134755/ now please. [00:39:53] things like "oh wait, you want caption? it's alternate text in inline! because why not." [00:39:54] cscott: Indeed. [00:40:00] mooeypoo: oh, and the latest word from the RfC meeting is that upright is likely to be deprecated and removed from wikitext entirely [00:40:06] mooeypoo: Yay MediaWiki. [00:40:08] so you'll never have to support it in VE. ;) [00:40:13] cscott: Tsk. [00:40:24] cscott: We already support it in VE, it's commented out because of Parsoid. [00:40:38] I didn't know you can put these characters in image names at all [00:40:40] you should have been lazier ;) [00:40:48] my brain is still in 1995 ascii [00:40:49] :D [00:41:37] James_F, oh! that looks good code-wise, but I can't test it since I didn't see the bug that it produced. [00:41:39] James_F: i've implemented upright in parsoid at least two different times, i keep getting overridden by the forces which want to clean up wikitext and not support overtly broken stuff. [00:42:12] cscott, "not support overtly broken stuff" will mean rewriting many many parts of wikitext... [00:42:23] not that i'm opposed to that goal, i just tend to not be as Bold [00:42:27] mooeypoo: I did; it fixed it IME. [00:42:42] mooeypoo: :D [00:42:43] mooeypoo: it turns out that only something like 0.4% of image references use upright at all, and most of those would render the same if it were simply omitted. [00:42:51] (03CR) 10Mooeypoo: [C: 032] "Looks good!" [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/134755 (owner: 10Catrope) [00:43:22] cscott, the bigger question now is how much of this do users *really* need to care about in terms of front end [00:43:31] a lot of the wikitext stuff came about to make the wikitext-writers' lives easier [00:43:48] not necessarily to make the users' lives easier [00:44:24] (03Merged) 10jenkins-bot: Don't add |link= when converting block images to inline [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/134755 (owner: 10Catrope) [00:44:40] one of my to-do tasks is to collect statistics to find out more details on the users of upright [00:44:47] I mean, we have to support it 'cause it's in wikitext, but a lot of the media editor is just plain confusing unless you write wikitext and want to produce a specific wikitext output. [00:45:07] mooeypoo: we just landed a patch to make default-sized thumbnails use a square bounding box by default, so most of the motivation to use upright is now gone. [00:45:22] cscott, I write the code and feel like Indiana Jones, pulling random levers to prevent the walls from caving in... [00:46:13] cscott, and yet, people request the feature. [00:46:23] I can see the benefit in having a sort of percentage resizing thing [00:46:42] but not necessarily in the same way upright was designed. It's a bit messed up. [00:47:00] mooeypoo: sort of. but not really, since user's thumbnail preferences are completely dynamic. so "50% of the user's preferred thumbnail size (whatever that is)" isn't really terribly useful. [00:47:18] yeah that's the problem, that it's percentage out of thumbnail size [00:47:24] the user wants a particular thumbnail size. so the remaining users of 'upright' are deliberately giving the user a size *other* than their preferred one. [00:47:33] yeah [00:48:12] It becomes inconsistent really fast, very tough trying to make sure that new users specifically know what to expect when choosing combinations of options. [00:48:38] anyway, we didn't reach a firm resolution in the RfC meeting. But the preference of TimStarling and gwicke leaned heavily toward making 'upright' a no-op, deprecating it, and eventually removing it. If we can get away with that -- which is what I need to collect statistics to find out. [00:48:38] cscott, although, I have to say, I was a bit surprised to see something a little similar to the percentage concept of upright in Wordpress [00:48:53] bad ideas seed each other! ;) [00:49:26] it looks a lot more intuitive there, though, you only get the option after the image is already up, if you want to make it a bit smaller. But yes, I agree. :p [00:49:30] (03PS1) 10Jforrester: New icons for cite, references [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/134774 [00:49:41] I thought the whole 'upright' shenanigans is something users insisted on [00:51:15] mooeypoo: it was added because mw only did width-based scaling. it was the wrong solution to the problem, in retrospect. [00:51:30] * cscott has to catch a train [00:53:10] yeah. [01:13:15] James_F, gwicke: my "clunky" :) 'ext.parsoid.styles' makes it explicit that it's a CSS-only module. Can I make the same assumption for 'mediawiki.skinning.content.parsoid'? Flow *has* to have reasonable no-JS rendering. [01:13:58] spagewmf: Yeah, it'll be CSS-only. [01:14:13] spagewmf: I imagine soon enough it will be handled by skins themselves, anyway. [01:17:53] James_F: Thanks. I see right now the module has only skinStyles. [01:18:06] spagewmf: Indeed. [01:24:48] spagewmf, reasonable CSS-only rendering != no JS is ever used if supported [01:25:41] gwicke: That too. [01:26:13] it should definitely degrade gracefully [02:28:37] gwicke: yes, it should degrade well, but AIUI if you AddModuleStyles( 'mediawiki.skinning.content.parsoid' ) for no-JS and AddModules( 'mediawiki.skinning.content.parsoid' ) for JavaScript goodness, the CSS is loaded twice. Maybe skinStyles works differently [07:05:59] (03PS1) 10Mattflaschen: Preserve veaction, vesection on special redirects to wiki pages [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/134788 (https://bugzilla.wikimedia.org/50877) [07:07:38] (03CR) 10jenkins-bot: [V: 04-1] Preserve veaction, vesection on special redirects to wiki pages [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/134788 (https://bugzilla.wikimedia.org/50877) (owner: 10Mattflaschen) [10:44:51] (03CR) 10Krinkle: "Nice try James, but I don't think we'll allow javascript execution in SVGs just yet." [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/134774 (owner: 10Jforrester) [10:45:30] or third-party scriptl oading for that matter [10:45:32] wait, what? [10:45:52] haha, what. [10:45:55] These aren't svg [10:45:59] this is HTML [10:46:01] Dude :P [10:50:11] (03CR) 10Krinkle: [C: 04-1] "Hm.. while