[22:00:52] #startmeeting RFC meeting [22:00:52] Meeting started Wed Dec 2 22:00:52 2015 UTC and is due to finish in 60 minutes. The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot. [22:00:52] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [22:00:52] The meeting name has been set to 'rfc_meeting' [22:01:14] #topic RFC: Use

for media | Wikimedia meetings channel | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [22:01:33] hello, all. [22:02:33] #info https://phabricator.wikimedia.org/T118517 [22:02:44] hi [22:03:14] \o [22:04:27] Hey all [22:05:12] so is this a proposal to get rid of the magnify icon? [22:05:20] perhaps inadvertently [22:05:40] i don't think that's an inherent part of the proposal, but i *am* wondering if people would see that as a nice side-effect [22:05:41] AFAIK no, though that could happen as an implementation side effect [22:05:50] Is the magnifier button done via JavaScript or is it baked into the HTML [22:05:52] ? [22:06:02] right now the magnifier is baked into the HTML AFAIK [22:06:02] just responded on the task, IIRC design at the time was in favor of removing the magnify icon anyway [22:06:03] It's not a nice effect if you lose the ability to link to info of an image :) [22:06:18] it is HTML/CSS [22:06:28] cscott: that seems broken - could we repurpose that as JavaScript? [22:06:42] brion: the magnify link goes to exactly the same link as the main image. [22:06:42] jdlrobson: Only for JS users, but yes. [22:06:59] Well there's two purposes to the magnify icon. One is visibility of the concept of magnifying [22:07:12] The other is providing info if the image is nolinked or linked to a page [22:07:20] brion: that could be done with a CSS :before or :after overlay. [22:07:44] Not if its a different link I assume? [22:07:46] brion: the link or nolink status is done by the hover icon; it can also be done with css [22:07:48] with linking being 'attribution' [22:07:52] brion: i'm checking that right now [22:07:55] so rather important [22:08:01] But that may be a rare case for thumbs using thumb styles [22:08:17] for images the magnify icon has the same effect as clicking the image, but for video it is totally different [22:08:26] Usually nolink or link= is on inlines used as icons [22:08:33] You mean [[File:Foo.jpg|link=Bar|thumb=Baz.png]]? [22:08:49] for video, the image has no link except for a play button overlay [22:08:57] James_F: yep [22:08:57] and the magnify icon goes to the description page [22:09:00] brion: you're right, the magnify link always goes to the image (or manualthumb image, i suppose, can't easily verify that from parsertests), even if link= points somewhere else. [22:09:07] * jdlrobson doesn't see a problem with this being JS only (fyi mobile has no magnify button) [22:09:20] TimStarling: good point -- you can get to the image info from the player but its awkward [22:09:27] mobile has totally broken video support, right? [22:09:42] well mostly broken... [22:09:43] maybe some people want to view the description page without playing the video? [22:09:45] TimStarling: yes :) [22:09:48] TimStarling: not completely true but mostly yeh [22:09:54] Normally we require (in content land) via policy users to only use link= or nolink for PD images, so attribution isn't really needed. [22:10:05] ^^^ [22:10:12] ok, if people think the magnify link is still useful, we can certainly preserve it. it's just an extra tag inside the

, with some css to match. [22:10:20] In which case, simplify if possible. [22:10:22] * jdlrobson wonders if the use of the magnify function could be assessed separately to this proposal using some simple click tracking [22:10:22] dbrant: JoshM bgerstle_afk ^ you probably want to follow / comment on this rfc discussion in case the apps would go boom if they have xpath rules baked in. i don't know the full impact or severity offhand. related ticket = https://phabricator.wikimedia.org/T118517 [22:10:36] jdlrobson: sound like a good idea... [22:10:42] cscott: the issue is about editing, but yeah, the functionality can be preserved in any case [22:10:43] even if people think it's not useful, we should probably address it in a separate patch, not conflate the issues. [22:10:56] cscott: +1 [22:10:59] jdlrobson: yeah IMHO it could be done easily as JS or a post process step on top of the pure markup [22:11:12] could even be brought to the 2010s by animating it a little [22:11:17] cscott: Agreed. [22:11:30] gwicke: Kill before animate, I'd suggest. [22:11:33] gwicke: agreed, but there is already other markup inside the figure, like data-file-width and data-file-height, which we ignore when we serialize after editing. [22:11:37] cscott: i'm interested in losing it to JS purely to minimise initial HTML payload - although i expect this is only a minimal amount of bytes after gzipping every little helps [22:11:43] gwicke: i'd prefer it not be there, but i'm not dying. [22:11:53] I would consider a baked-in magnifying bring kept on main parser as equivalent to postprocessing on the parsoid [22:11:59] * gwicke proposes a user preference, puts on evil grin [22:12:00] jdlrobson: we can still significantly slim it down [22:12:16] cscott: So, this proposal appears to be for block images -- what about inline images? [22:12:16] jdlrobson: all we need is , the rest can all be CSS. [22:12:33] we need the actual a tag before, as has been pointed out, the href might not match anything else in the figure. [22:12:45] brion: baking it into the caption makes editing a bit ugly [22:12:48] gwicke: animations separately please - let's not add more variables ;-) [22:12:53] RoanKattouw: the *patch* is currently for block images. the *proposal* is for both. [22:12:58] OK [22:13:01] RoanKattouw: for inlines Wed either use custom figure inline tag or span as in current parsoid... [22:13:02] but, in any case, we can figure that out [22:13:02] RoanKattouw: basically the patch is lagging the proposal somewhat. [22:13:05] But

is a block node, so what are your plans for inlines? [22:13:08] Are we resolved to retain the magnifying glass in the

world, and have a distinct RfC about animating or scrapping it. [22:13:18] RoanKattouw: but it may be worth deploying them as two separate patches anyway. [22:13:21] Oh, I just found https://phabricator.wikimedia.org/T118520 [22:13:25] RoanKattouw: yep! [22:13:35] James_F: +1 sounds like a good idea [22:13:41] what about the other proposed changes, namely typeof and relative links? [22:13:53] currently we replace

with for inlines. but T118520 says we just make

into for inline images. [22:14:33] I think an element would be cleaner and more efficient to match [22:14:34] Mw:typeof is questionable as that's parsoid custom [22:14:41] since we need to add a bit of a javascript thunk for

in IE8 anyway, it's no more troublesome to do the same for [22:14:48] But it's useful for marking inlines, potentially [22:14:48] also what about non-images... [22:14:57] cscott: That's problematic. [22:14:58] cscott: and other old browsers [22:15:08] like safari mobile on ios 4.2.1 [22:15:09] Especially if we add more non image types we can't rely on [22:15:11] ok, i'm a bit overwhelmed by the different threads of conversation here [22:15:20] can we order the questions somehow, and deal with them one by one? [22:15:22] Need a consistently identifiably surrounding tag [22:15:37] dr0ptp4kt_: do they strip tags, or do they just lack the default styles? [22:15:38] Do we want

for regular block images without a caption box? [22:15:47] 1. What are we hoping to get out of this meeting? [22:15:48] cscott: sure, take your time [22:15:51] If no, then not for inlines either. [22:16:05] Wait, that's the same thing. [22:16:11] gwicke: in the case of ios 4.2.1 the image didn't load. it seems the tag is there, just not rendered gracefully [22:16:21] i currently see: (1) typeof, (2) relative links, (3) vs , and (4)

for regular block images without a caption box, and (5) what do i want to get out of this meeting. [22:16:25] gwicke: in the case of opera mini it rendered it okay [22:16:29] dr0ptp4kt_: it'll save bandwidth ;) [22:16:32] cscott: JS for non-JS users. [22:16:33] Krinkle: A captionless block image is not the same as an inline image. Image types are way more complex than anyone gives them credit for [22:16:37] can we take them in order, and folks can push new q's on the end of the stac? [22:16:42] gwicke: ha [22:16:51] cscott: Go for it. [22:17:22] (1) typeof is really useful to gadget authors and folks consuming/scraping article HTML [22:17:49] is it like the content-type of the content of the figure ? [22:17:49] cscott: +1 i would find the mw:typeof useful myself :D [22:18:04] gwicke: opera mini actually has some javascript support. if there's a