Architecture meetings/RFC review 2014-06-02

'''23:00 UTC, Monday, 2 June, at.

Request for Comment to review

 * 1) Requests for comment/Grid system

Summary and logs
= #wikimedia-office: Discussion of grid system RfC | Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE). https://meta.wikimedia.org/wiki/IRC_office_hours =

Meeting started by sumanah at 23:00:12 UTC. The full logs are available at https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-06-02-23.00.log.html .

Meeting summary

 * LINK: https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-06-02 (sumanah, 23:00:30)
 * Grid system RfC (sumanah, 23:00:38)
 * 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." (sumanah, 23:00:47)
 * LINK: https://www.mediawiki.org/wiki/Requests_for_comment/Grid_system (sumanah, 23:01:15)
 * 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." (sumanah, 23:01:38)
 * LINK: https://gerrit.wikimedia.org/r/#/c/125387/ is the actual patch to be merged - "Grid system for mediawiki.ui". (sumanah, 23:01:59)
 * LINK: https://pauginer.github.io/agora-grid/ has more information. (sumanah, 23:02:08)
 * 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?  (sumanah, 23:02:30)
 * LINK: https://www.mediawiki.org/wiki/Talk:Architecture_Summit_2014/UI_styling#Grids our discussion at arch summit (sumanah, 23:04:00)
 * 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 "  (sumanah, 23:06:09)
 * LINK: http://pastebin.com/vg7ueSXY <- a little backlog (cscott, 23:23:02)
 * LINK: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140602.txt for people who had trouble connecting/staying connected (sumanah, 23:28:05)
 * LINK: http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm (TimStarling, 23:31:20)
 * ACTION: sumanah to ask Product to check on IE versions we need to support, document it? (sumanah, 23:33:31)
 * LINK: http://www.modern.ie/en-us/ie6countdown (TimStarling, 23:37:03)
 * ACTION: quiddity to Should also check browser-stats regarding geographic distribution. Eg. if IE6 makes up a significant percentage of Global South readers/editors. (sumanah, 23:38:07)
 * LINK: https://gerrit.wikimedia.org/r/#/c/125387/ (TimStarling, 23:44:47)
 * AGREED: we don't need to block this discussion on the question of which IE versions we specifically support (sumanah, 23:48:00)
 * ACTION: Deskana (Dan Garry) to follow up with Product to form policy on what IE versions we support, for future RfCs! (sumanah, 23:48:19)
 * ACTION: shahyar to mention a few small concerns on Pau's change (sumanah, 23:55:57)
 * LINK: https://gerrit.wikimedia.org/r/#/c/125387/ is the actual patch to be merged - "Grid system for mediawiki.ui". (sumanah, 23:56:43)
 * AGREED: merge 125387 first, please everyone review it; content feature will be based on top of it (TimStarling, 23:57:11)
 * LINK: https://www.mediawiki.org/wiki/VisualEditor/Target_browser_matrix (sumanah, 23:59:32)
 * LINK: https://www.mediawiki.org/wiki/VisualEditor/Target_browser_matrix browser support guide (sumanah, 23:59:48)

Meeting ended at 00:00:08 UTC.

Action items

 * sumanah to ask Product to check on IE versions we need to support, document it?
 * quiddity to Should also check browser-stats regarding geographic distribution. Eg. if IE6 makes up a significant percentage of Global South readers/editors.
 * Deskana (Dan Garry) to follow up with Product to form policy on what IE versions we support, for future RfCs!
 * shahyar to mention a few small concerns on Pau's change

Action items, by person

 * Deskana
 * Deskana (Dan Garry) to follow up with Product to form policy on what IE versions we support, for future RfCs!
 * quiddity
 * quiddity to Should also check browser-stats regarding geographic distribution. Eg. if IE6 makes up a significant percentage of Global South readers/editors.
 * shahyar
 * shahyar to mention a few small concerns on Pau's change
 * sumanah
 * sumanah to ask Product to check on IE versions we need to support, document it?

Full log
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:12  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:12  Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 23:00:12  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:25 #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:38 #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  it's not any less semantic than the ways content is being laid out at the moment though 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: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:00  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  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 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:53 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:17 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 <TimStarling> sorry, connection dropped out for 5 minutes before I realised 23:19:54 <TimStarling> 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:01 nod 23:20:27 <TimStarling> 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 <TimStarling> ah right 23:22:54 <TimStarling> 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 <TimStarling> this was just after my connection dropped out 23:23:14 <TimStarling> 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:18 <TimStarling> #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 <TimStarling> if they can read the text without their browser crashing, that's a plus 23:27:01 <TimStarling> 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:57 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 <TimStarling> 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 <TimStarling> IE 6 is 0.22%, IE 7 is 0.74% 23:31:20 <TimStarling> 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 <TimStarling> fair enough 23:32:16 <TimStarling> 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:41 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:02 not immediately 23:33:13 quiddity: thanks, chrome hates cut-and-paste on linux these days. 23:33:17 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:31 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 <TimStarling> 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 <TimStarling> 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 <TimStarling> http://www.modern.ie/en-us/ie6countdown 23:37:38 there are also polyfills for supporting box-sizing on IE6/7 23:37:38 <the-wub> I think there are polyfills around for box-sizing on IE6/7. not sure if that's the only problem though. 23:37:49 <the-wub> 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 <TimStarling> mostly PRC then, followed by Taiwan 23:38:18 <TimStarling> 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 <TimStarling> 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:07 <TimStarling> IE6 is 1.3% in Korea 23:39:15 oh! nm 23:39:15 <TimStarling> according to that page 23:39:18 quiddity: Oliver has browser talk page stats, iirc. 23:39:28 yupyup 23:40:01 ok pginer what additional topics would you like to address today? or mark for further discussion onlist etc.? 23:40:04 <TimStarling> 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 <TimStarling> it is 22.2%, for the log 23:40:56 <TimStarling> 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 <TimStarling> 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 With this proposal I’m more interested in the big picture (having a responsive grid available) than the underlying implementation 23:44:16 hey Deskana - which IE versions are we committed to supporting, in MediaWiki? 23:44:23 <TimStarling> anyway, should we merge the existing change? 23:44:47 <TimStarling> #link https://gerrit.wikimedia.org/r/#/c/125387/ 23:44:52 <Deskana> sumanah: I don't think we really have an answer to that question. We should think about this as a group. 23:45:37 <TimStarling> 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:25 it’s not really a blocker. IE6-7 can be solved with hacks in the mixin. 23:46:28 <TimStarling> I think we should support IE 6 if it is not too difficult 23:46:56 <TimStarling> 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 <TimStarling> yes, fine 23:47:47 <Deskana> You can assign it to me in the sense that I can get a discussion going about it, sure. 23:47:49 <TimStarling> 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 <TimStarling> 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 <Deskana> 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 <TimStarling> I think a separate patch can do it 23:49:44 <Deskana> *design question 23:50:06 TimStarling: meaning, once this is committed, a future patch can investigate the #content issues? 23:50:11 <TimStarling> 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 <TimStarling> so yes 23:50:26 <Deskana> YEAH 23:50:29 TimStarling: ok, thanks 23:50:31 <Deskana> YEAHHHHHH 23:50:34 <Deskana> (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:58 * cscott LAUGHS ALSO 23:51:07 <TimStarling> exposing it to content should probably be deployed separately 23:51:43 <TimStarling> 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:50 <TimStarling> 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:43 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:59 * 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 <TimStarling> well, it's based on my fairly murky understanding of what a LESS mixin is 23:54:37 Maybe. 23:55:04 is this something Roan, Krinkle, or TrevorParscal would be interested in reviewing? 23:55:07 <TimStarling> 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 <TimStarling> #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:10 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:50 <TimStarling> gwicke: we've been there, postcard is in the mail 00:00:08 #endmeeting

let's continue this chat onwiki or onlist :) Thanks all quiddity the text-size example was to ilustrate that although there are especific mixins for size, you could make any property to be responsive (in addition type changes were exaggerated to be noticeable) Yup, that's what I figured. Thanks for confirming though. :) gwicke: yes, that's what we were proposing i think okay, great <the-wub> alright. I just want to say big thanks pginer for working on this! I've been wishing for a grid system for a while, both as an editor and a fundraiser just came back from a meeting, now reading the backlog basically exposing the grid system to the skin and/or common.css, and letting the wiki itself define appropriate semantic classes using the grid system and then those semantic classes would be the thing exposed to content (rather than the grid system directly) but that's step two or three or four, i gather <TimStarling> we would like authors to use semantic classes <TimStarling> whether we can force them to use semantic classes is another matter <TimStarling> we can probably gently encourage it using the template styling feature fwiw, wikiquotes was very diligent itself about not adding extraneous size or other styling to their images. the problem is that 'bare thumb' is only a single semantic class. it would be nice if there were more. ;) i think we can also encourage semantic markup w/ VE <TimStarling> if you provide classes for use in MediaWiki:Common.css or in some new template style feature, presumably it will be possible to use those classes in style attributes <TimStarling> well, in class attributes ideally there should be checkboxes or a drop down for 'type of image', and the direct manipulation of handles should be mildly discouraged <TimStarling> I'm not sure how you would technically discourage that <TimStarling> but maybe it's not necessary if we provide appropriate tools for semantic classes yes, works now.  it's not the tersest markup, but if VE is generating the class attributes, the extra typing shouldn't matter. <TimStarling> template styling is probably critical TimStarling: one way to discourage it would be switch between (say) one-column and two-column styles when you drag the image handles, instead of adding MxNpx attributes. there might be a checkbox to allow direct image sizing, but it would be an 'advanced' option. it's all about what you make easy