[01:46:32] Getting on the BART. Headed for downtown. Hello San Francisco. [22:53:02] Meeting in here in 10 min about the grid system RfC https://www.mediawiki.org/wiki/Requests_for_comment/Grid_system [22:59:05] hey jorm - looking forward to hearing your thoughts on the grid sys as well [22:59:15] here are my thoughts: [22:59:23] 1) We need a grid system [22:59:39] hi lilatretikov - happy to talk with you here or in private message if you want to understand more about this meeting/process :) [22:59:43] 2) Not having one makes us look like stone-age "sophisticates" [22:59:55] 3) The grid system should work with div#content [22:59:55] pginer: hi, will be asking you for "what you want today" if that's ok (in a few min) :) [22:59:55] that's it. [23:00:05] Thanks jorm - I'll probably c&p that in a few min :-) [23:00:12] All right! [23:00:12] #startmeeting Discussion of grid system RfC | Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE). https://meta.wikimedia.org/wiki/IRC_office_hours [23:00:13] Meeting started Mon Jun 2 23:00:12 2014 UTC and is due to finish in 60 minutes. The chair is sumanah. Information about MeetBot at http://wiki.debian.org/MeetBot. [23:00:13] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [23:00:13] The meeting name has been set to 'discussion_of_grid_system_rfc___channel_is_logged_and_publicly_posted__do_not_remove_this_note___https___meta_wikimedia_org_wiki_irc_office_hours' [23:00:24] #chair sumanah TimStarling [23:00:25] Current chairs: TimStarling sumanah [23:00:30] #link https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-06-02 [23:00:37] #topic Grid system RfC [23:00:47] #info We're discussing Pau Giner's proposal for "a Grid system in MediaWiki to simplify the creation of user interfaces and make them ready for multiple screen sizes." [23:01:15] #link https://www.mediawiki.org/wiki/Requests_for_comment/Grid_system [23:01:30] wave hello, pginer :-) [23:01:38] #link https://gerrit.wikimedia.org/r/#/c/133683/ is the new test/example patchset. "It makes the log-in form responsive (adjusting layout, typography and visibility to the current screen size). It does not leverage all the potential of responsive design, but may be useful as a demo to help the reviewers." [23:01:47] hi! [23:01:57] cscott - I'll also be asking you for your thoughts :) [23:01:59] #link https://gerrit.wikimedia.org/r/#/c/125387/ is the actual patch to be merged - "Grid system for mediawiki.ui". [23:02:08] #link https://pauginer.github.io/agora-grid/ has more information. [23:02:13] hello ;) [23:02:21] pginer: what would you like from today's chat? [23:02:30] #info cscott has said "A grid system for content authors would be useful as well." http://lists.wikimedia.org/pipermail/wikitech-l/2014-June/076810.html and the following message have more. cscott what are your thoughts? [23:03:10] i agree with peter coomb's followup in that thread: [23:03:26] "IANA "grid expert", but I think it would be a huge missed opportunity not to let this be used for content. It could be a great help with pages like Portals, which are currently reliant on loads of inline styles for layout, or worse, tables." [23:03:31] I think we discussed this at the architecture summit? [23:03:31] Last time I was asked to provide some example of use, and I tried to provide so with the example patchset. I would like to know if there is anything else I could do to facilitate the review process. [23:03:39] maybe very briefly anyway [23:03:54] We did TimStarling [23:04:00] #link https://www.mediawiki.org/wiki/Talk:Architecture_Summit_2014/UI_styling#Grids our discussion at arch summit [23:04:10] I think the "implementation" section wasn't there at the time? [23:04:19] You are right [23:04:57] gwicke expressed some reservations about adding Yet Another non-semantic markup for content -- grids give size hints, but not the semantic reasons behind that. i agree with that concern about exposing grid systems as well. so i'm on both sides of the fence. [23:05:31] cscott, this is based on LESSCSS, so it is a bunch of mixins [23:05:37] the HTML does not get affected [23:06:09] #info when asked for his thoughts on the matter, jorm said: "1) We need a grid system 2) Not having one makes us look like stone-age "sophisticates" 3) The grid system should work with div#content " [23:06:10] it's not any less semantic than the ways content is being laid out at the moment though [23:06:25] pginer: I'm presuming your proposed system does work with div#content ? Sorry I haven't looked yet [23:06:49] (a control-f does not find that string in the pg) [23:07:01] so the question for gwicke was whether or not to apply the grid classes to style attributes? [23:07:25] the most obvious way of tying them together would be something like [[File:Foo.jpg|class=foo]] where the skin gave foo a style which referenced the grid system. [23:07:47] the alternative would be directly exposing the grid, something like [[File:Foo.jpg|grid=mxn]] [23:08:06] perhaps there are other, even better, options? [23:09:09] cscott: I don't see anything about files on the RFC [23:09:58] TimStarling: yes, my quick read of the RfC didn't turn up any indication that it applied to content. which i view as somewhat unfortunate. [23:10:03] but i could be wrong [23:10:21] The grid system just provides some basic constructs you can use when creating style classes. Those classes can have different purposes (content or UI). [23:10:25] jorm is also saying (in jargon) that it should apply to content [23:10:43] i agree with jorm's jargon (and style) [23:10:54] I think the first place to apply it is for UI, but there is nothing that prevents its use on content [23:11:15] or to create new classes or new mixins that are used on both [23:11:32] pginer: to use in content, the mixins would have to be applied to specific classes and made available on all pages, right? [23:11:35] under "Implementation" on https://www.mediawiki.org/wiki/Requests_for_comment/Grid_system it says that LESS mixins will "avoid grid classes to be used out of their intended target (UI as opposed to user-generated content)." [23:11:49] is that something which can be changed? [23:12:02] TimStarling: yes [23:12:45] that wouldn't be much extra code, would it? [23:13:16] i'd like to think that the skin would be an intermediary. so the enwiki community (for example) could agree on some semantic classes (like "one column figure", "full width figure", etc, but with better names!) and these classes could be implemented by the skin, in the content section, using the grid system. [23:13:53] cscott: that is how I see it [23:13:58] that is, the grid classes wouldn't be directly exposed to #content, but would be available for the skin to expose indirectly to content? [23:14:21] yes [23:14:25] * jorm likes it when people agree with his style. [23:14:54] i should say, "the skin and Common.css" or something like that. [23:15:26] cscott: that makes a lot of sense [23:15:31] In the same way that “width:50%” can be used anywhere, the grid system just provides constructs to say “width:50% if small-screen” [23:16:38] I’ve got a few questions. #1 Why does .mw-ui-grid have overflow: hidden, instead of something like the micro-clearfix? #2 Why don’t we just calculate widths, instead of having a couple dozen LESS proportion mixins? #3 How does this work with older browsers like, IE6? Particularly with regards to subpixel rounding differences in browsers. [23:19:42] sorry, connection dropped out for 5 minutes before I realised [23:19:54] I don't think the community would be happy with the idea of delegating layout to MW, making it difficult for them to change it [23:20:00] nod [23:20:27] and maybe today is not the best day to try to sell the idea of "WMF knows article layout better than you" [23:20:32] Regarding #1, there are several techniques for sorrounding floating elements. I don’t remember the pros/cons, but I’m open to apply a different technique. [23:21:21] Regarding #2, I don’t understand what do you refer by “why don’t we just calculate widths?" [23:22:05] Php-less was a bit limited in terms of applying dynamicly generated mixins. [23:22:10] TimStarling: the proposal was just to expose the grid system to common.css, so the community could use it to create their own layouts. [23:22:47] ah right [23:22:54] i should say, "the skin and Common.css" or something like that. [23:23:02] http://pastebin.com/vg7ueSXY <- a little backlog [23:23:04] this was just after my connection dropped out [23:23:14] yeah, my bouncer was still connected [23:24:24] from my recent experiences with wikiquotes :) one of the things they like to do is put a column of illustrative figures in a column down the right-hand side of the article [23:24:53] pginer: #2 I mean we could have a generic mixin to which you give a number (eg. 1/5), and that returns the calculated CSS given its arguments. [23:25:06] not exactly sure how the specific grid system in the RfC handles it, but some systems would make it easy to drop these out on narrow screens. [23:25:11] cscott: common.css does not currently support LESS though [23:26:19] #3 I don't think we need to support accurate layout in IE6 anymore [23:26:25] shahyar: we could go with the parameter route, but the human readable mixins may make easy to understand when used. [23:26:32] if they can read the text without their browser crashing, that's a plus [23:27:01] but I don't think there is a guarantee that it should look nice [23:28:05] http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140602.txt for people who had trouble connecting/staying connected [23:28:35] fwiw, from https://en.wikipedia.org/wiki/Moon there are two "full width" or "wide" figures: https://en.wikipedia.org/wiki/File:Speed_of_light_from_Earth_to_Moon.gif and https://en.wikipedia.org/wiki/File:Speed_of_light_from_Earth_to_Moon.gif [23:28:45] I have not made an intensive cross-browser analysis, but using float-based grids are widerly supported that other alternatives (inline-block or flexbox) [23:28:56] i'm participating because i'd eventually like to see better/more consistent markup for things like that. [23:29:09] TimStarling: while I would personally like to agree with you, in our scenario, IE6 and 7 together represent something like 2% of requests. it’s significant enough that it needs to work better than just “not crash” :) [23:29:34] IE 7 yes, IE 6 no [23:29:59] and https://en.wikipedia.org/wiki/File:Moon_phases_en.jpg * is the second "wide" image ;) [23:30:30] I think there’s a possible balance to be had, but the current state of the code does not account for either of them. and neither IE6 nor 7 support box-sizing, so supporting one is essentially both. [23:30:46] My reasoning for including div#content is specifically because i don't think we're in a position to dictate to autonomous wikis how to do layout. [23:30:49] TimStarling: IE6 is in more use than 7. [23:30:55] robla: do you have thoughts on what IE versions we need to support? [23:31:15] IE 6 is 0.22%, IE 7 is 0.74% [23:31:20] http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm [23:31:40] TimStarling: of all requests. of HTML requests it’s over 1%. [23:32:09] fair enough [23:32:16] I still don't think we should support layout in it though [23:32:32] sumanah: I think that's probably a question for Product [23:32:47] shahyar: is your concern about some images being positioned 1px off on IE6 (and maybe 7) or something different? Because that does not sound like a big deal, even for 2% of the users [23:32:49] robla: cool - you see Dan Garry around? [23:33:01] not immediately [23:33:13] quiddity: thanks, chrome hates cut-and-paste on linux these days. [23:33:18] tgr: the problem isn’t that they would be incorrectly positioned, but rather that the value would be completely miscalculated and one of the colums would end up on a new line. [23:33:30] James_F|Away: ping re your IE versions research... [23:33:31] #action sumanah to ask Product to check on IE versions we need to support, document it? [23:33:32] IIRC, layout in IE6 was a much more complicated and idiosyncratic business than IE7 [23:33:44] I am in fact in support of _forcing_ IE6-7 to render off by a few pixels so that they don’t have this problem. [23:34:02] and I think we have stopped doing IE6 support in a few other projects [23:34:30] unfortunately, we support IE6-7 (to an extent; it’s not pixel-perfect, that’s for sure) in Flow, and should we implement grid, we’d need it to do so as well. [23:34:53] should we put off the IE discussion/chat until I've had a chance to grab a Product person to weigh in on the talk page? [23:35:16] we are slowly removing support for old things like that. like, not designing for them at all. [23:35:49] the problem is that those things (the non-ie 6 designs) are for editor features, not reader features. [23:36:18] Should also check browser-stats regarding geographic distribution. Eg. if IE6 makes up a significant percentage of Global South readers/editors. [23:36:49] shahyar: couldn't that be avoided by targeting old IE separately with a CSS hack/conditional comments/whatever and making the columns a little smaller? [23:36:53] quiddity: you willing to help follow that up after this meeting, with analytics? [23:37:00] i gotta go, but my bouncer is recording everything. [23:37:03] http://www.modern.ie/en-us/ie6countdown [23:37:38] there are also polyfills for supporting box-sizing on IE6/7 [23:37:38] I think there are polyfills around for box-sizing on IE6/7. not sure if that's the only problem though. [23:37:49] pginer: jinx! [23:37:54] sumanah, sure [23:38:07] #action quiddity to Should also check browser-stats regarding geographic distribution. Eg. if IE6 makes up a significant percentage of Global South readers/editors. [23:38:09] mostly PRC then, followed by Taiwan [23:38:19] yeah, that's what I am doing [23:38:19] eg. if you set 3-column to 30% on IE, that will not overflow as long as the container is larger than 30px [23:38:33] it is mostly used in China [23:38:50] IE's big in South Korea, right? [23:38:58] tgr: yes, and it might be doable with mixins. we have to come up with a weird calculation to do it. [23:39:00] the-wub: we shouldn’t use polyfills for something like this, because we already have a LOT of elements on the page, and the page will come to a crawl with a polyfill for something like this. [23:39:08] IE6 is 1.3% in Korea [23:39:15] oh! nm [23:39:15] according to that page [23:39:18] quiddity: Oliver has browser talk page stats, iirc. [23:39:28] yupyup [23:40:00] ok pginer what additional topics would you like to address today? or mark for further discussion onlist etc.? [23:40:04] that page has IE6 at 4.2% globally, so the fact that we measure 1% tells you something about how popular we are in China [23:40:41] it is 22.2%, for the log [23:40:56] IE6 usage in PRC [23:41:08] rly? wow. [23:42:12] Just encourage to provide comments on the talk page or the patchsets [23:42:38] ok, maybe it is worthwhile to support IE6 then [23:42:47] pginer: but on what specific open questions? [23:43:32] Aspects that can be changed [23:44:16] hey Deskana - which IE versions are we committed to supporting, in MediaWiki? [23:44:16] With this proposal I’m more interested in the big picture (having a responsive grid available) than the underlying implementation [23:44:23] anyway, should we merge the existing change? [23:44:48] #link https://gerrit.wikimedia.org/r/#/c/125387/ [23:44:52] sumanah: I don't think we really have an answer to that question. We should think about this as a group. [23:45:37] it has no positive CR from anyone [23:45:38] Deskana: is it possible for me to assign this question to you to follow up on and advise pginer in this context? [23:45:46] it seems to be a blocker for this discussion [23:46:26] it’s not really a blocker. IE6-7 can be solved with hacks in the mixin. [23:46:28] I think we should support IE 6 if it is not too difficult [23:46:57] 1% thinly spread is not a concern, but 22% of China is a concern [23:47:01] I don’t see it as a blocker. It just means that at the moment the mixins cannot be used if you are creating a UI for those browsers. [23:47:21] TimStarling: #agreed that IE version question is not a blocker? [23:47:39] yes, fine [23:47:46] You can assign it to me in the sense that I can get a discussion going about it, sure. [23:47:50] what we need to merge it is for some people to give +1 on it [23:48:00] #agreed we don't need to block this discussion on the question of which IE versions we specifically support [23:48:19] #action Deskana (Dan Garry) to follow up with Product to form policy on what IE versions we support, for future RfCs! [23:48:26] i.e. actual code review [23:48:59] Someone reviewing the patchset would be awesome [23:49:06] what was the answer to the question about #content? [23:49:30] is that still a "yes, it would be nice if the patch would do this" or a "yes, the existing patch could be used to style #content"? [23:49:37] It's not just going to be product; it's also an engineering question (e.g. "What is the engineering cost of supporting IE6?") and a design cost (e.g. "How does supporting older browsers affect what designs we can create for our site?") [23:49:44] I think a separate patch can do it [23:49:44] *design question [23:50:06] TimStarling: meaning, once this is committed, a future patch can investigate the #content issues? [23:50:11] AFAICT, the existing patch does not block development of a feature which exposes these mixins to the content [23:50:16] Deskana: yes, it's interdisciplinary for sure, it's just that it seems to be a decision Product could own after consulting with others to make it :-) IMO [23:50:24] so yes [23:50:26] YEAH [23:50:29] TimStarling: ok, thanks [23:50:31] YEAHHHHHH [23:50:34] (ACCIDENTAL CAPS) [23:50:42] * sumanah laughs aloud [23:50:57] Deskana: I guess you...*takes off shades*...popped a cap in this channel. YEAHHHHHH [23:50:57] * cscott LAUGHS ALSO [23:51:07] exposing it to content should probably be deployed separately [23:51:43] from a deployment perspective, it is much more scary to expose a feature for users to incorporate into content than it is to expose a feature for developers to use in UIs [23:51:51] much easier to revert the latter [23:52:08] Deskana: (I was like, "yes, I am glad you agree, I think I did articulate that well if I do say so myself......oh. you just meant yes.") [23:53:23] TimStarling: indeed [23:53:42] cscott: are you reviewing pginer's patchset? [23:53:43] TimStarling: yes, my concern is just deploying a developer feature that can't be eventually used for content editors without tearing everything out and starting over. as long as we can build on this, +1 from me. [23:53:47] marktraceur: you wanna do that? [23:53:54] sumanah: not at the moment, i'm eating dinner ;) [23:53:58] * marktraceur looks around [23:54:00] Do what? [23:54:08] i'm trusting TimStarling's assessment :) [23:54:23] marktraceur: review the patchset [23:54:37] Maybe. [23:54:37] well, it's based on my fairly murky understanding of what a LESS mixin is [23:55:04] is this something Roan, Krinkle, or TrevorParscal would be interested in reviewing? [23:55:08] but I think pginer agrees that it is a reasonable foundation for a content feature? [23:55:14] (Pau's grid patchset) [23:55:36] or MatmaRex [23:55:38] I have some simple, addressable concerns for the patch. I’ll put those up. after that, I’m happy to +1. [23:55:57] #action shahyar to mention a few small concerns on Pau's change [23:56:00] TimStarling yes [23:56:15] shahyar thanks! [23:56:20] #pingthewholechannel [23:56:24] sumanah: Could you link to it? [23:56:43] https://gerrit.wikimedia.org/r/#/c/125387/ is the actual patch to be merged - "Grid system for mediawiki.ui". [23:57:04] This is actually surprisingly small [23:57:09] I would recommend removing any automatic text-size changes, in demo-models. Some people with desktops just like small windows, and won't appreciate their text size changing. (I realize that's just an example of how variables-can-work in the mockup, but I think it worth noting explicitly.) [23:57:11] #agreed merge 125387 first, please everyone review it; content feature will be based on top of it [23:58:39] * quiddity apologizes for being a curmudgeon. [23:59:09] ok, sounds like we're done [23:59:23] gonna end the meeting in a few seconds :) [23:59:31] I'm not convinced that directly exposing grid layouts to content authors is the best way to leverage grids; it might be better to encode semantics in content, and then style semantic content using something like a grid system [23:59:32] https://www.mediawiki.org/wiki/VisualEditor/Target_browser_matrix [23:59:48] #link https://www.mediawiki.org/wiki/VisualEditor/Target_browser_matrix browser support guide [23:59:51] gwicke: we've been there, postcard is in the mail