[14:44:35] Technical Advice IRC meeting starting in 15 minutes in channel #wikimedia-tech, hosts: @Tonina_WMDE & @Lucas_WMDE - all questions welcome, more infos: https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting [21:01:06] #startmeeting RFC meeting [21:01:06] Meeting started Wed May 2 21:01:06 2018 UTC and is due to finish in 60 minutes. The chair is kchapman. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:01:06] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:01:06] The meeting name has been set to 'rfc_meeting' [21:01:11] \o/ [21:01:17] #topic Colorable SVG https://phabricator.wikimedia.org/T106240 [21:01:42] Hi all, who is here for the RFC meeting? [21:01:49] * brion me! [21:02:18] < [21:03:16] brion was there anyone else you were expecting? [21:03:23] might just be us, that's ok though :D [21:03:31] So this is a user request that's come up a few times, which I did a test implementation for a year or two ago [21:03:31] okay well then take it away! [21:03:57] scope creeped up for a while to potentially include resourceloader icons, then we trimmed it back to just [[File:]] refs [21:04:08] however there's two main paths we could take in implementation [21:04:42] the first option is to do much as the original test patch did, and tie SVG colorization into a parameter (on the [[File:]] and on the thumb URL) [21:04:48] this would be a specific targeted feature [21:05:02] would require adding support to thumbor for WMF production usage, but that looks doable [21:05:23] the second option is to combine it with another old idea, for 'derivative' files [21:05:25] btw the info tag is your friend for the minutes when appropriate :) [21:05:30] will do :D [21:05:51] #info option 1: color-svg-specific feature as a parameter on [[File:]] invocations and thumbnail URLs [21:06:19] so derivative files would themselves act like any other [[File:]], with their own name [21:06:36] and would be created through (some sort of interface to be determined) and then reused many times [21:07:01] #info option 2: more general derivative-file system, creating virtual files to be used via [[File:]] and thumbnail URLs without visible magic parameter [21:07:21] to decide, may need to answer some questions about expected usage [21:07:58] for instance, is it ok to require manual intervention to create a derivative (such as a tinted svg) or should templates be able to create them at will based on input parameters? [21:08:26] #info need to answer questions like: do templates need to be able to auto-create the derivatives from an input param? [21:08:46] further, we should estimate what kind of caching issues are created by adding extra output files [21:09:01] which may apply to both cases [21:09:14] #info caching / purging of extra files is a concern for implementation at scale [21:10:06] #info advantage of derivative system is it can be extended with other things like rich crop/scale/rotate without adding extra parameters on URLs [21:10:21] so that's the main state of it at this time :) [21:10:33] Another advantage is that it's easier to throttle and track usage, compared to arbitrary url parameters. [21:10:34] if there's any additional concerns i'd love to add them into the mix [21:10:37] what's the use case? [21:11:10] #info Original use case for tinted SVGs was icon use in templates, where we currently have separately uploaded "this icon in red, this icon in green", etc [21:11:39] #info Another advantage is that it's easier to throttle and track usage, compared to arbitrary url parameters. [21:11:48] Indeed. They're typically downloaded, opened in an editor, potentially corrupted, accididentally changed or cropped or otherwise inflated, and then re-uploaded. [21:11:59] It's error prone and harder for casual contributors as well. [21:12:28] #info extended use cases for derivs include cropping with less recompression artifacts and manual work/errors [21:12:34] if you want an image to be rotated you can just put some kind of rotation request on it on commons and a bot will come along and rotate, right? [21:13:00] not sure whether a derivative file system needs to be more complicated than that [21:13:30] it could work much the same at the internal level, just avoiding all the round trips [21:13:45] do you know an example of a template that uses this, and how many icon variants it needs? [21:13:48] Could we just do the original use case with template styles instead? [21:13:56] #info making the derivative source link explicit is good for machine-readable metadata too [21:14:12] user:Offnfopt had a suggestion & demo for using transparencies+CSS. Is a 3rd option, or part of 1 or 2, or just unfeasible? https://phabricator.wikimedia.org/T106240#3620819 [21:14:13] CSS has the whole filter: rule that can do it I think [21:14:19] bawolff: template styles would not apply to the SVG though (well maybe you could filter actually) [21:14:37] #info bawolff raises templatestyles and CSS filters, a possibility [21:15:16] #info quiddity mentions offnfopt's similar suggestion at https://phabricator.wikimedia.org/T106240#3620819 [21:15:23] quite possible! [21:15:31] client-side transforms are interesting too [21:15:33] tinted svgs seems like a rather large feature (especially if we do the derrivitive files version) for a rather small use case (imo) [21:16:07] yeah, with derivs i'd want to actually implement crop/rotate/etc probably [21:16:43] #info may want stronger use case fleshed out for a feature this size (deriv images). do we need to pull in the crop/rotate/etc or is this just imbalanced? [21:16:47] There's a long standing request for DerivitaveFX reimplementation on commons [21:17:15] which I think was basically just cropping and layering different images. But I think the primary killer feature was keeping track of sources, and which licenses were compatible [21:17:17] https://phabricator.wikimedia.org/T110409 [21:17:19] I was just reading brion's 2015 implementation, can you help me to understand how the colour mixing works and whether it is possible to do more complicated things than monochrome? e.g. greyscale gradients? [21:17:58] I agree with Tim that performing this in user-land with bots works quite well. But, the current situation isn't per se what we want to emulate. [21:17:59] iirc the original implementation just applies a single monochrome color. a more complex system could be done that accepts multiple parameters, and fills them into the gradient options etc [21:18:09] but then we're well on the way to general templatization [21:18:13] For one, the issue with doing them a separate files with bots is that there's no longer a relation the original. [21:18:16] Not automated. [21:18:21] But that could be fixed. [21:18:30] if we have distinct fiels but keep the relation i think we're a long way there yeah [21:18:33] On the other hand, I think retriggering cascading updates is very rare for files. [21:18:42] So probably not worth a primitive in the system? [21:19:00] Could always be done manually by re-triggering the bot/tool/extension. [21:19:05] well we want that for finding where it came from and what its rights are even if we don't trigger an automatic rebuild of the image [21:19:07] i think [21:19:18] Right, but we do track that in the information. [21:19:26] I mean if the source SVG has 50% grey in it and you ask to mix with red #f00, what is the result? [21:19:29] #info relation between the files is the main thing missing from existing bot systems. make sure that's trackable somehow even if it's not a primitive [21:19:39] I meant more like a low-level primitive of distinguishing real files from derivatives, e.g. not having an original in swift for the derivative. [21:20:14] TimStarling: iirc you just get #f00 as the default color in that implementation, so an explicit 50% gray either is kept or is overridden (I'd have to re-check the code heh) [21:20:35] ah [21:20:51] Krinkle: yeah i can see that. [21:21:31] the SVG spec has a charming reference to a book published in 1984, no link [21:21:33] #info low-level primitive for derivs not needed if high-level code/bot/etc does the editing and we keep the parent file relation at the high level. [21:22:26] but there is the arithmetic filter [21:22:31] result = k1*i1*i2 + k2*i1 + k3*i2 + k4 [21:23:23] with k1=1, k2=0, k3=0, k4=0 you have multiplication, wherein #fff in the source becomes #f00 and #888 in the source becomes #800 [21:23:29] so let's add an option 3: have an explicit way in metadata to mark file derivatives, but leave the modification to either an extension tool that does a virtual reupload or a bot tool that does a literal reupload [21:23:34] like a physical red filter over the screen [21:23:46] TimStarling: nice! that'd be better for non-monochrome stuff [21:24:58] #info adding option 3: explicit way to mark derivative files, with the implementation of tinting/cropping/etc left to extensions or bot tools for now [21:25:08] brion: you mean in file metadata (e.g. inside the .svg file) or something like {{#register-derivative:color|fill=#888}} [21:26:02] Krinkle: hmmm, ideally both i guess but a parser function is probably more directable [21:26:05] ah [21:26:26] one thing to consider: things like parser props aren't exposed across file repos i think [21:26:35] *extracted* file metadata is [21:26:48] Right. We currently have CommonsMetadata add to that API. [21:26:54] +1 awesome [21:27:07] So it is extendable to include data from outside the file binary as well [21:27:17] There is a field for it (I think called metadata.mediawiki or some such) [21:27:20] #info wiki-level metadata should be extensible with derivs etc via CommonsMetadata or another way [21:27:22] the reason I'm talking about filtering details is because I'm wondering whether one kind of filter is enough [21:27:22] that we can use for this potentially [21:27:45] because if there are a bunch of different filtering modes that are needed, it may make sense to use a different way to specify them [21:27:48] TimStarling: yeah, exactly why i think about a more general derivs system rather than a single param :) [21:27:51] yep [21:28:08] Oh, hey, you're talking about this. [21:28:15] * brion waves James_F [21:28:34] Krinkle: reminds me i need a place to stash preferred thumbnail timestamp for video files [21:28:42] Regardless though, I think its important that we get concrete use cases. I suspect design/reading-web may want to avoid a file-based approach in favour of a CSS approach. Even if it means filtering rendered-PNGs after the fact (is that possible?) because doing it in wikitext means it can't usefully vary by device or skin. [21:29:12] CSS filtering is pretty flexibile but not supported in older browsers, i think that's the main limitation [21:29:19] I remain against this idea as adding even more complexity to the syntax for images whilst we've discussed several times bigger ideas that aren't full RfCs yet about changing the syntax. [21:29:42] Also, allowing the derivative to be made only from the [[File:]] syntax would reduce usage surface given lots of these icons are actually used from Common.css where its only got an upload url. [21:29:47] James_F: we seem to have migrated away from the parameter idea towards providing infrastructure for tools to create derivative files without the syntax change [21:29:57] though we'll see, still talking about filtering :D [21:30:09] brion: Oh? Well, we built that for OOUI… [21:30:16] \o/ [21:30:21] * brion steals it [21:30:24] I don't mind the parameter idea, but the phab comments seemed quite negative about it [21:30:25] So is the RfC now "coreify OOUI's system and make it better"? [21:30:46] on the basis that one more parameter is too many? [21:30:59] #info We need to get more concrete use cases on the icon tinting idea to decide best way to move forward [21:31:15] #info via see the tinting system in OOUI also [21:31:20] seems like a weird argument, let's introduce a whole new system of derivative images because the current system for derivative images is too successful and is used too much [21:31:28] heh [21:32:01] for templates, parameters are fine and usable [21:32:23] If we were going to add transformative parameters to File: syntax we'd probably want to start with cropping and rotation before tinting. [21:33:09] except that there is already code for tinting and none for cropping or rotation [21:33:52] also cropping and rotation are used by actual real users, the usability issues are more severe [21:34:25] #info cropping and rotation are also asked-for. should be consistent in terms of system used? implications of multiple features? [21:34:27] if we just want coloured train station icons in templates, file parameters are usable [21:34:45] I imagine tinting will get used a lot in novel ways if you release it. And we may regret the ways it gets abused. [21:35:31] so there's a fourth crazy option: allow templates/lua modules to generate SVG (in which case templatization is their problem) [21:35:39] Oh gods no. [21:35:43] >:D [21:35:52] obviously we'd have to sanitize them for security [21:36:08] but this isn't theoretically worse than generated HTML subset bits for markup [21:36:21] No, but "other people do it too!" is a bad excuse. [21:36:46] #info crazy option 4: SVG generation from templates/lua modules (which can tint etc if they like) [21:36:48] I think there's clearly end-user value in having dynamic versions of media files available for transclusion. [21:37:17] I just worry that we're adding value for a few dozen ultra-experts at a cost of millions of newbies whose wikitext now got that bit more complicated. [21:37:22] re: lua->SVG, people are already coming close with things like https://en.wikipedia.org/wiki/Module:Chart [21:37:27] i think there's end-user value in generating graphs, chess board layouts, etc too [21:37:52] and i suspect 99% of it will hide behind a bigger template [21:38:02] "Ah great, I hadn't realized the coloring for RL landed -- I'll pull it up and see if I can merge." [21:38:08] said brion in July 2015 [21:38:11] lol [21:38:34] :-) [21:39:06] * bawolff wants lua->canvas [21:39:21] Imagine flash applet type content written in lua [21:39:25] don't jest bawolff [21:39:26] for like physics demos and stuff [21:39:28] i might do it for ya [21:39:38] bawolff: Because you don't have enough security issues to deal with right now? [21:40:04] #info compare with HTML chart generation via module at https://en.wikipedia.org/wiki/Module:Chart [21:40:20] You know there are people who have written lua interpreters in JS [21:40:36] James_F: Honestly, risk is lower than a lot of things, if done properly [21:40:42] with CSP and iframe sandbox flag [21:41:02] let's save that for another rfc :D [21:41:13] we already know how to sanitize SVG [21:41:34] Not enough to ship UGC SVGs to users. [21:41:37] but yes, all anyone wants to talk about is ways we can extend the scope of this RFC beyond all belief [21:42:04] #info we have several tangents now. need to narrow the scope back down to something implementable [21:42:46] ok, we've got a few minutes left [21:42:58] any strong expressions of yes/no/NOOOOOOOO on the four options? [21:43:05] https://phabricator.wikimedia.org/T106240 <- here [21:43:13] I think doing this as a server-side thing first (and then later extending to calls from wikitext) would be the sanest approach. [21:43:26] So extensions/skins can use it. [21:43:50] (that'd be option 2 or 3) [21:44:19] * bawolff thinks we should see first if users are happy with just templatestyles and filter:, and only bother if we need to solve some problem that that doesn't fix [21:44:46] * brion nods, always good to try things with existing support [21:44:48] bawolff: you're saying filter the generated PNGs? [21:44:53] using CSS? [21:44:55] yeah [21:45:34] would fail in supported browsers, but should work elsewhere [21:45:37] *un [21:46:02] Well I think IE has had (non-standards compliant support) since like IE4 [21:46:12] Unsupported = Grade X? Or Grade C? [21:46:34] I think this? https://caniuse.com/#feat=css-filters [21:46:41] has the advantage of not needing an RFC [21:46:56] iirc C gets the styles (so maybe) and X gets nothing? [21:47:10] Looks like IE11 is the only one that's a no [21:47:31] brion: C gets non-JS RL experience. A gets with-JS RL experience. X gets A but by accident, without any testing or fixes. [21:47:33] edge doesn't like url filters, but we don't need that (afaik) [21:47:35] really wish Edge wasn't a Win10 upgrade carrot [21:48:11] #info some recommendations to do user testing with TemplateStyles and CSS filters before investing further [21:49:28] Ok let's fiddle with some of that and leave the bigger options to a bigger feature set, maybe [21:49:41] perhaps also test CSS background color? that's all Offnfopt was using in https://commons.wikimedia.org/w/index.php?title=User:Offnfopt/Template:Sandbox&oldid=259213978 [21:50:04] Not sure how practical that is for the various use-cases though [21:50:10] That's a bit more limited [21:50:29] there's definitely not consensus for adding a parameter as in the existing patch [21:50:36] *nod* [21:50:44] 10 more minutes left in this meeting [21:51:33] quiddity: however it breaks compat if you want the actual background to be non-white [21:51:42] ah tricky [21:51:54] its a nice trick though [21:52:27] #info brion will do some fiddling around with TemplateStyles/filters in next couple weeks, feel free to join in [21:52:48] #info no consensus yet for adding a parameter as in the original patch, or for the larger changes proposed in option 2/3/4 [21:53:22] #info CSS background-color trick works in some cases but not general enough. full filters may be limited in support [21:53:33] Ok I think that's where we stand :D [21:53:37] any last-minute additions? [21:54:10] perhaps the existing patch should be abandoned for now? [21:54:27] yeah lemme kill it [21:55:16] done [21:55:54] thanks everybody for your feedback and ideas! [21:56:02] all finished brion? [21:56:05] we'll have to narrow it down a bit more and see what ends up being implemented :D [21:56:06] yep! [21:56:09] thanks kchapman ! [21:56:15] #endmeeting [21:56:15] Meeting ended Wed May 2 21:56:15 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [21:56:15] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2018/wikimedia-office.2018-05-02-21.01.html [21:56:15] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2018/wikimedia-office.2018-05-02-21.01.txt [21:56:15] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2018/wikimedia-office.2018-05-02-21.01.wiki [21:56:16] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2018/wikimedia-office.2018-05-02-21.01.log.html [21:56:19] woot