Architecture meetings/RFC review 2014-02-27

This meeting will concentrate on UI and UX styling RFCs. We're following up on the discussion we started at the Architecture Summit.

It takes place in at 0:00 UTC-1:00UTC on 28 February, that is, afternoon on Thursday Feb 27 (San Francisco time)/morning of Friday 28 Feb (Sydney time).

Requests for Comment to review

 * 1) Requests for comment/Grid system - Pau Giner and Trevor Parscal
 * 2) Requests for comment/Scoping site CSS - Juliusz

Did not have time to consider:

 * 1) Requests for comment/Allow styling in templates - Jon Robson

Quick checkins if we have time:
 * 1) Inline diffs - Max Semenik
 * 2) Architecture guidelines (quick checkin)
 * 3) Performance guidelines (quick checkin)

Summary and TODOs
Meeting started by sumanah at 23:58:32 UTC. The full logs are available at https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-02-27-23.58.log.html .


 * LINK:   (sumanah, 23:59:50)
 * Grid system (sumanah, 00:00:15)
 * https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-27 (sumanah, 00:00:17)
 * https://www.mediawiki.org/wiki/Requests_for_comment/Grid_system (sumanah, 00:00:39)
 * Per the discussion from the January 2014 architecture summit, https://www.mediawiki.org/wiki/Talk:Architecture_Summit_2014/UI_styling#Grids Pau & Trevor now own this, and we hope to get some working on-wiki demos by about April 2014. (sumanah, 00:01:13)
 * http://pauginer.github.io/agora-grid/examples/simple-demo.html - one example by Juliusz, he plans to make more (sumanah, 00:08:48)
 * CSSJanus should work in the RTL context as well  (sumanah, 00:19:23)
 * some say: the point of a grid system is mainly for UI, not for content styling (sumanah, 00:20:11)
 * some indirection is recommended for use of grids in content. prefer to use semantic classes (brion, 00:21:35)
 * ACTION: pginer to finish writing the RFC so we can mark it accepted (TimStarling, 00:27:15)
 * ACTION: pginer to add detail on intended use cases / prefixing to RFC & perhaps narrow "implementations" section  if possible, name the actual classes and mixins which you intend to create  (sumanah, 00:30:30)


 * Scoping site CSS (TimStarling, 00:32:10)
 * LINK: https://www.mediawiki.org/wiki/Talk:Architecture_Summit_2014/UI_styling#Grids had the question but neither the name of the questioner nor the answer "irrelevant" (sumanah, 00:32:15)
 * LINK: https://www.mediawiki.org/wiki/Requests_for_comment/Scoping_site_CSS (TimStarling, 00:32:23)
 * LINK: https://www.mediawiki.org/wiki/Talk:Architecture_Summit_2014/UI_styling#Scoping_site_CSS discussion from the architecture summit (sumanah, 00:33:32)
 * HELP: "let's figure out good ways to help editing & preview -> (who's interested?)" (from the arch summit notes)  (sumanah, 00:34:06)
 * ACTION: more research required on advanced possibilities for scoping site CSS (brion, 00:56:37)
 * consider splitting that out from the core RFC so we can get simple things done faster (brion, 00:56:56)

Meeting ended at 01:12:04 UTC.

Action items

 * pginer to finish writing the RFC so we can mark it accepted
 * pginer to add detail on intended use cases / prefixing to RFC & perhaps narrow "implementations" section  if possible, name the actual classes and mixins which you intend to create
 * more research required on advanced possibilities for scoping site CSS

Full log
23:58:32 #startmeeting RFC review UI styling 23:58:32  Meeting started Thu Feb 27 23:58:32 2014 UTC and is due to finish in 60 minutes. The chair is sumanah. Information about MeetBot at http://wiki.debian.org/MeetBot. 23:58:32  Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 23:58:32  The meeting name has been set to 'rfc_review_ui_styling' 23:58:48 #chair brion TimStarling 23:58:48  Current chairs: TimStarling brion sumanah 23:59:28 pginer: jdlrobson hey there, you have a preference for who goes first? 23:59:30  ooh, working bots today, high tech 23:59:50 #link 23:59:55 I would like to finish early if possible, 00:00:01 it is 1am here 00:00:06 ok, pginer first :) 00:00:15 #topic Grid system 00:00:17 #info https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-27 00:00:39 #info https://www.mediawiki.org/wiki/Requests_for_comment/Grid_system 00:01:13 #info Per the discussion from the January 2014 architecture summit, https://www.mediawiki.org/wiki/Talk:Architecture_Summit_2014/UI_styling#Grids Pau & Trevor now own this, and we hope to get some working on-wiki demos by about April 2014. 00:01:39 * sumanah lets other people ask questions or bring up issues 00:02:06 The language team is using an initial implementation of the concepts 00:02:11 proposed 00:02:35 for Content translation project 00:02:45 * Krenair waves 00:03:36 the idea is to check that there are no major issues and be able to merge the basics into core. 00:03:43 nice 00:04:07 I think there should be no major concerns considering that the basics are just a set of classes with predefined widths. 00:04:26 and breakpoints 00:04:46 LESS CSS makes it easy to tweak the specific implementation and improve later if needed. 00:05:21 ;q 00:05:22 q 00:05:42 (sorry, wrong window) 00:05:45 UNKNOWN COMMAND: 'q' 00:05:58 I plan to make more examples such as this: http://pauginer.github.io/agora-grid/examples/simple-demo.html 00:06:11 jorm haha 00:06:14 To illustrate the use and make it easier to get feedback 00:06:49 That's all I had to update. Let me know if there is any question 00:06:58 well, sounds good :) 00:07:09 what can we see it in action in? (or soon) 00:07:14 my first question is: Does anyone think that having a grid is a *bad* idea? 00:07:34  jorm: not that I know of 00:07:43 pginer: would that look good in RTL too? 00:07:48 jorm: i had some initial concerns on first proposal, but they have been relieved by prior discussion 00:08:10 Yeah, I didn't think there was any major objection - other than possible technical hurdles. 00:08:22 matanya: that should flip to RTL pretty straightforwardly yes 00:08:26 jorm, the answer probably depends on what this is used for 00:08:29 matanya: CSSJanus  should work in this context too. 00:08:48 #info http://pauginer.github.io/agora-grid/examples/simple-demo.html - one example by Juliusz, he plans to make more 00:08:52  should we mark this RFC as accepted? 00:08:53 I'd think we would need to grind it into Vector (somehow) 00:09:17 pginer what units are used to define width? 00:09:37 It is based on percentages 00:09:46  i think it was made clear at the summit that the grid system is useful for content, not skins, due to lack of absolute sizing 00:09:51 .one-half { width: 50%; } 00:10:02  I support grid systems with relative sizing, but they of course have their limitations 00:10:20 You can create an element with the classes: one-third, mobile-one-whole 00:10:56 that will make the size of the column to change from 33% to 100% on a small screen/window 00:11:00  so the idea is to provide these classes and promote them for editors to include in article styling? 00:11:15 TimStarling: https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Grid_system does not really say that anything is really incomplete, but I think there are a few open questions in https://www.mediawiki.org/wiki/Talk:Architecture_Summit_2014/UI_styling#Grids, e.g., "How does this impact bandwidth? & server storage / cacheing of thumbnails?" 00:11:23  I'm very interested in grids, but does it support vertical? 00:11:33 They are mainly thought for extension UIs 00:11:51 The classes can be used directly but they can also used "silently" thanks to LESS 00:11:57 That is, as mixins 00:12:31 do you plan to prefix them with mw? 00:12:33  so by content TrevorParscal just means the content area of a skin when a special page is displayed? 00:12:43 I can create a a sidebar whose style is .sidebar{ .one-sixth; .lap-one-third;} 00:13:16 The HTML would only have the semantic .siebar class 00:13:19 This only applies inside of div.#content, then 00:13:23  TimStarling: not the chrome of the skin - unless the skin is designed for proportional layout, then of course that's great, use the grid 00:13:49 gwicke, the current implementation already prefixes everything as mw-ui- 00:14:15  my point is that our skins currently have proportional and fixed elements, and to be clear, the grid system being proposed doesn't support both, so it's not a drop-in replacement for existing positioning code in Monobook and Vector 00:14:32 pginer: ah, ok; that also clarifies Tim's question about use in normal articles 00:14:38 <TimStarling> pginer: maybe that should be mentioned on the RFC doc 00:14:39 <TrevorParscal> I don't really think there's anything wrong with using a grid system for a skin 00:15:01 The rid is intended to play well with current styles, only elements inside a .grid element will be affected. 00:15:19 It is mentioned when it is indicated that is optional 00:15:27 * jdlrobson awaits that wonderful day when there is no need for the mw- prefix 00:15:36 you can decide which parts of a skiin use the grid 00:15:39 <TrevorParscal> I would say that ideally we should be moving away from article authors being involved in page layout as much as possible, and giving them a grid system would suggest we are moving in the wrong direction 00:16:01 <TrevorParscal> But I'm sure some people who like things the way they are will dissagree 00:16:03 (anything here to be summarized in the minutes with an #info ?) 00:16:08 You can even use the grid and add extra styles to make some element of a fixed width (or a max/min width) 00:16:10 that is fine 00:16:13 TrevorParscal: +1 00:16:42 <TrevorParscal> when article authors are given more layout power, it seriously damages out ability to make the content portable 00:16:54 TrevorParscal: especially on mobile we are seeing this already 00:17:02 <TrevorParscal> as in between platforms, skins or decades in time 00:17:15 <TimStarling> I thought the idea of a grid system is to make layout more portable 00:17:34 <Edokter> re width: wercentage of what? desktop average or mobile average 00:17:36 I agree, but authors adding .one-half is better than they forcing a width:50% directly 00:18:17 In any case, I agree that the main purpose is for UI not content 00:18:37 <TrevorParscal> the way to make it more portable is to step back from directly controlling layout and have them annotate with semantic information 00:18:41 <TrevorParscal> look at the direction HTML is going 00:18:46 <TrevorParscal> we should be following suit 00:18:55 �*nod* try to keep things like 'one-half' directly in the HTML css, especially for content 00:19:02 <TrevorParscal> instead, I'm hearing a suggestion we give them more styling directly in the model 00:19:04 but we can make use of a grid in the styles that are built around semantic things 00:19:10 like "floatable-image" or something 00:19:20 *directly out of 00:19:20 <TimStarling> I'm not suggesting anything 00:19:22 not *directly in 00:19:23 #info CSSJanus should work in the RTL context as well 00:19:23 bah 00:19:32 <TrevorParscal> yes, we can apply a grid system to semantically marked up content - that's exactly how it should be done 00:19:36 <TimStarling> I was just asking what you meant by content 00:19:52 <TrevorParscal> TimStarling: I'm not really referring to you, not sure why you thought I was 00:19:57 <TrevorParscal> I'm referring to the RFC 00:20:01 <TrevorParscal> which is a suggestion 00:20:05 <TrevorParscal> in it's purest form, no? 00:20:11 #info RFC authors say: the point of a grid system is mainly for UI, not for content styling 00:20:35 <Gloria> The styling in content area question is outside the scope of the grid RFC, in my opinion. 00:20:41 wait, hmm, I thought Trevor was a coauthor on this RFC, was wrong 00:20:42 <Gloria> There's a separate RFC about deprecating inline styling. 00:20:45 <TrevorParscal> sumanah: no, it's great for content styling, just not if used directly by content authors 00:21:22 <TrevorParscal> Gloria: deprecating inline styling indeed is out of scope, I'm not talking about that 00:21:30 <TimStarling> TrevorParscal: you mean in MediaWiki:Common.css or whatever replaces it? 00:21:35 #info some indirection is recommended for use of grids in content. prefer to use semantic classes 00:21:38 Gloria, css class prefixing makes that clear 00:21:52 <TrevorParscal> I'm talking about content authors using the grid system classes in actual article content 00:22:07 <TrevorParscal> brion has it right 00:22:13 <Edokter> like plcement of infoboxes and thumbs 00:22:15 <Gloria> gwicke: How do you mean? 00:22:22 <TrevorParscal> TimStarling: You've lost me 00:22:43 mw-ui-* is explicitly marked as something you should *not* use in page content 00:22:52 <TimStarling> well, you say a grid system is great for content styling if not used directly by content authors 00:22:52 <Gloria> That will literally stop no one. 00:22:52 <TrevorParscal> gwicke: +1 00:23:01 <Gloria> gwicke: We're already seeing buttons in the content area, aren't we? 00:23:05 <Gloria> mw-ii-button or whatever? 00:23:09 <Gloria> mw-ui-button * 00:23:10 <TimStarling> I am asking if you imagine that a grid system will be used directly in Common.css etc. 00:23:20 <Gloria> If editors can use the fancy classes, they will... 00:23:23 Gloria, we can easily enforce it 00:23:24 <TimStarling> defining classes which are in turn used by authors 00:23:32 <TimStarling> such as infobox classes etc. 00:23:46 <TrevorParscal> TimStarling: it should be applied to content, using the less mixins, targeting content by it's semantics (such as what it is, not how the author feels it should appear today) 00:23:48 <Gloria> Infoboxes have been abstracted to a meta-template. 00:23:54 <Gloria> Most authors have no interaction with the HTML. 00:24:17 <TimStarling> ok 00:24:18 <TrevorParscal> TimStarling: I think you understand me now 00:24:33 <TrevorParscal> Gloria: that is just one example 00:24:41 <TrevorParscal> there are many many others out there 00:26:00 <TimStarling> any action items? 00:26:35 sounds like 'wait for more cool stuff to happen in language team's usage, then model stuff on it' 00:27:05 <TimStarling> how about 00:27:15 <TimStarling> #action pginer to finish writing the RFC so we can mark it accepted 00:27:15 perhaps pginer could respond to "<TimStarling> pginer: maybe that should be mentioned on the RFC doc" :) (action item)? 00:27:35 :) 00:28:08 Any part you recommend adding more detail to? 00:28:11 does pginer need to address the bandwidth/storage/caching stuff at all? 00:28:29 pginer, some detail on intended use cases / prefixing would be good 00:28:37 ok 00:29:04 <TimStarling> pginer: maybe narrow the "implementations" section 00:29:18 Makes sense 00:29:54 <TimStarling> if possible, name the actual classes and mixins which you intend to create 00:30:30 #action pginer to add detail on intended use cases / prefixing to RFC & perhaps narrow "implementations" section <TimStarling> if possible, name the actual classes and mixins which you intend to create 00:31:08 ok. added to my todo-list 00:31:09 <TrevorParscal> Maybe I'm missing something, but asking about "bandwidth/storage/caching" for a CSS change seems sort of - did the person who asked that understand the RFC at all? 00:31:11 thanks 00:31:27 agreed to re-visit this in April when the Foundation team's usage has had more of a chance to grow? 00:31:39 <TimStarling> TrevorParscal: probably not 00:31:51 <TimStarling> next RFC? 00:31:56 <TrevorParscal> please 00:32:10 <TimStarling> #topic Scoping site CSS 00:32:15 https://www.mediawiki.org/wiki/Talk:Architecture_Summit_2014/UI_styling#Grids had the question but neither the name of the questioner nor the answer "irrelevant" 00:32:23 <TimStarling> #link https://www.mediawiki.org/wiki/Requests_for_comment/Scoping_site_CSS 00:33:18 jgonera: :) 00:33:30 <TrevorParscal> Has the RFC been updated completely since the summit, because there are still some issues that were brought up that aren't reflected in this version? 00:33:32 #link https://www.mediawiki.org/wiki/Talk:Architecture_Summit_2014/UI_styling#Scoping_site_CSS discussion from the architecture summit 00:33:41 so scoping content CSS inside the content area is ..... theoretically doable 00:33:47 keeping UI styles *out* of content is harder 00:33:54 except by blacklisting i guess :D 00:33:54 I updated the proposal section, the first paragraph 00:34:06 #help "let's figure out good ways to help editing & preview -> (who's interested?)" (from the arch summit notes) 00:34:10 brion, yeah, this is a separate issue 00:34:42 <TrevorParscal> so first off, the proposal uses an ID as an example 00:34:45 <TrevorParscal> but we really must not do that 00:34:51 editing & preview is an interesting idea too, but I don't think it's within the scope of this RFC 00:34:55 <TrevorParscal> it needs to be a class - for a lot of reasons 00:35:14 TrevorParscal, you're right 00:35:15 <TrevorParscal> including to resolve issues in editing and preview 00:35:16 it should be a class 00:35:34 <TimStarling> I could note here that the tie-in with LESS is not absolutely necessary 00:35:38 brion, re keeping ui styles out of the content: we can disallow prefixed styles 00:35:45 <TimStarling> it's not like LESS has a monopoly on descendant selectors 00:35:59 <Gloria> gwicke: Disallow how? 00:36:00 <TimStarling> but if we are doing LESS anyway in the short term, then I guess it is ok 00:36:06 <TrevorParscal> TimStarling: I think that was intended to show how easy it is to do 00:36:06 Gloria, strip in the sanitizer 00:36:32 <TrevorParscal> TimStarling: but you are right, we could probably write something quite simple that prefixes things 00:36:35 <Gloria> That sounds like a pretty awful abuse of the sanitizer. 00:36:40 sumanah, as far as I remember editing & preview during the summit was about previewing the CSS that's being edited 00:36:42 <TrevorParscal> CSSJanus is all regexes and works OK 00:36:43 <Gloria> Unless these classes are exploitable? 00:37:01 Gloria, we strip all kinds of things in the sanitizer that are not security related 00:37:08 <TimStarling> you probably have to parse it anyway 00:37:25 <TimStarling> to make sure the user-supplied CSS doesn't escape from the LESS block 00:37:34 <TimStarling> with an unmatched closing brace or whatever 00:37:46 <TrevorParscal> LESS makes it easier, probably, just because it's already able to parse CSS 00:38:04 <TrevorParscal> TimStarling: well, that would break LESS compilation 00:38:23 It seems to facilitate the round-trip by keeping the user provided rules unmodified. 00:38:23 TrevorParscal, what should be the correct class for this? .mw-body? .mw-content-ltr/rtl? 00:38:29 <TimStarling> } /* hello!!! */ #content { 00:38:54 <TrevorParscal> .mw-content seems good to me 00:39:03 TimStarling, sure, it's just easier this way 00:39:04 and since we have LESS in core, why not? 00:39:07 <TimStarling> you could make it so that it still compiles 00:39:24 <TrevorParscal> I would say at the same level we would need to have the .ltr and .rtl classes 00:39:32 <TimStarling> well, before we go too far down this path, is this the proposal or isn't it? 00:39:49 <TrevorParscal> so you can say .mw-content.rtl - since we won't let you write .rtl .mw-content anymore 00:40:05 <TimStarling> is the idea to just do $less = ".mw-content { $unvalidatedUserSuppliedCSS }" 00:40:14 TimStarling: you could avoid that case by parsing twice - once without the scoping and once with (sure there would be a more performant way) 00:40:20 This RFC may need re ..... scoping :) 00:40:28 <TimStarling> because that seems a bit hacky to me 00:40:42 <TrevorParscal> I agree this is a hack 00:40:48 <TimStarling> jdlrobson: right 00:40:59 <TimStarling> if it is LESS then you need to parse LESS to validate 00:41:04 <Edokter> I'm not entirely sure what problem scoping is trying to solve. 00:41:12 <TimStarling> if it is CSS then you need to parse CSS to validate (and also add descendant selectors) 00:41:23 <TrevorParscal> a more robust solution would be to write a LESS plugin which can modify the selectors of all rules while they are in the DOM 00:41:28 <Gloria> Edokter: There's a "Problem" section in the RFC. :-) 00:41:32 Edokter: remember hlists on mobile…. :) 00:41:33 <TrevorParscal> the CSS dom inside LESS that is 00:41:46 <Edokter> ah yes 00:41:51 <TimStarling> TrevorParscal: yeah, that sounds nicer 00:42:24 ba-dump-tish 00:42:51 <Edokter> but... does it require such an elaborate software solutoin where naming-discipline does the same? 00:43:08 <Gloria> Edokter: I think that's a pretty reasonable question. 00:43:19 Edokter: as Gloria has pointed out in previous discussion, naming-discipline "doesn't stop anyone" 00:43:20 TrevorParscal, currently, there's no such thing as .mw-content 00:43:28 <TrevorParscal> that's good news 00:43:46 <TimStarling> Edokter: it's not so elaborate 00:43:55 <Edokter> apart fom hlist, have ther been other scoping problems? 00:44:16 <TrevorParscal> Edokter: usually doing things the right way isn't as easy 00:44:28 <TrevorParscal> that's not to say the hard way is always right 00:44:57 having the ability to scope selectors would be handy for template styles too 00:45:04 <Gloria> brion: The caveat is that local admins can't be stripped of their ability to stylize their own sites. :-) 00:45:06 <TimStarling> it sounds like a couple of days of work to me, at most 00:45:13 <Gloria> brion: Even if we think their styling is ugly. 00:45:25 <TrevorParscal> but, Tim's instincts here are good - when possible, modify things in a DOM rather than pre-process strings before parsing 00:45:34 <jdlrobson_> seems jgonera is having connection problems 00:45:38 as am I. 00:45:38 Gloria: as long as they separate the content and theme styles i'm fine with that :) 00:45:55 at least I can't find it on a mediawiki.org page 00:45:55 should this be added? 00:46:11 <Gloria> brion: I'm not sure MediaWiki encourages that... renaming Common.css to Content.css seemed like it had some merit. 00:46:11 <TrevorParscal> gwicke will tell you, text pre-processing is pretty evil and has caused us many a problem down the road 00:46:24 <TimStarling> the time required depends mostly on the quality of the code in the LESS parser and whether it really does have a plugin system 00:46:46 <TimStarling> TrevorParscal: you suggested a plugin because you know it has plugins, right? 00:46:56 even if we had to roll our own shallow grammar it would not be too hard 00:46:57 TrevorParscal: actually with LESS .rtl .mw-content would still be possible with a ".rtl &" rule 00:47:30 OTOH with LESS, enterprising sould could find many ways to break out 00:47:50 &+.real-selector {} and so on 00:48:23 freenode is laggy as hell for me... I'm just reading from logs now 00:48:25 sounds like this one needs more time in the oven 00:48:59 <TrevorParscal> tgr, I mistyped, I meant to say rules like .rtl .wikitable will become .mw-content .rtl .wikitable - but .rtl is set on body, not a child of .mw-content 00:49:10 are we ready for action items to do some more research and experimentation on it? 00:49:18 <TrevorParscal> we could make .mw-content have a child with .rtl, but that's a larger change 00:49:19 I'd rather not overengineer this at first and try the simplest solution to see how it works 00:49:32 (I'm referring to creating a plugin for LESS) 00:49:48 <Gloria> TrevorParscal: I don't think ".mw-content" exists currently. 00:50:04 <TimStarling> well, whether a LESS plugin is the simplest solution depends on whether you consider string interpolation into a LESS block to actually be a solution 00:50:04 <TrevorParscal> I don't see anything on the web about extending LESS, so for now I'm pretty sure that's not going to be easy or feasible 00:50:05 Gloria, that's what I said, but my messages came like 3 minutes late ;) 00:50:07 TrevorParscal: .mw-content { .rtl & .wikitable {} } will translate to .rtl .mw-content .wikitable {} 00:50:30 <Gloria> We currently have #mw-content-text and .mw-content-ltr, it looks like, at least in Vector. 00:50:33 <TrevorParscal> tgr: oh, I see what you mean 00:50:41 <TrevorParscal> sorry, I misunderstood you 00:51:51 <Gloria> TrevorParscal: If we change to ".mw-content .ltr" or whatever, we'll need to figure out what to do with the current class. 00:52:15 <TrevorParscal> Gloria: current class? 00:52:17 <Gloria> The body tag has a class of .ltr. 00:52:24 <TrevorParscal> tgr solved that 00:52:29 <Gloria> TrevorParscal: The current class is ".mw-content-ltr" 00:52:38 for client-side performance keeping selectors on content short would be better 00:52:41 <jdlrobson_> will we have time to go over my RFC - apparently we only have 8 mins left :) 00:52:45 <TrevorParscal> you just write .ltr & .myclass which becomes .ltr .mw-content .myclass 00:52:54 since there is normally much more content than chrome 00:53:11 <Gloria> TrevorParscal: Okay, but first you'd have to add .mw-content. I'm not sure that point has transmitted successfully. 00:53:54 <TrevorParscal> gwicke: ideally we could do some actual performance analysis, because it's unlikely that there is going to be enough of a penalty to justify tossing this idea alltogether 00:53:57 Gloria, TrevorParscal I'm assuming that would not be very difficult? 00:54:23 <Edokter> man this feels like 20 years ago... netsplit 00:54:28 <Gloria> jgonera: Probably not very difficult, no. It'll just make the HTML a bit messier. 00:54:42 <TimStarling> I'll tell you something interesting about the LESS compiler... 00:54:49 TrevorParscal, just saying that .mwc-hlist is more efficient than .mw-content .hlist 00:54:52 <Gloria> Because you'll have class="mw-content-ltr mw-content" I guess. 00:55:00 <TimStarling> it has many many methods in the compiler class 00:55:06 <TimStarling> and most of them are protected, not private 00:55:06 Gloria, why messier? I'd say less messy, we already have LTR/RTL indication in HTML, we don't need mw-content-ltr/rtl 00:55:09 especially when applying the same pattern to all content styles 00:55:18 <Gloria> jgonera: I don't think you can remove them. :-) 00:55:28 <TrevorParscal> TimStarling: are you suggesting we code against a moving target? lol 00:55:35 Gloria, because people use them in their custom CSS? 00:55:37 <Gloria> jgonera: If you remove the current classes (.mw-content-ltr/rtl), you'll break a lot of shit, I imagine. 00:55:41 <Gloria> Yep. 00:55:43 ok, I think connectivity is bad enough that we should start wrapping up. jdlrobson and MaxSem I'm sorry. now that we've done a few of these it's clear that even when 3 RFCs are pretty related there's not enough time to talk about more than 2 00:55:55 <Gloria> And in screen-scraping scripts and in JavaScript and in site-wide CSS and... 00:55:58 <TimStarling> sure, I'm saying maybe we could subclass it 00:56:19 <TrevorParscal> TimStarling: I'm not suggesting you are crazy, just bold 00:56:36 <TimStarling> plugins are coding against a moving target too, you know 00:56:37 #action more research required on advanced possibilities for scoping site CSS 00:56:44 <TrevorParscal> Gloria: I think it's safe to say that this will break a lot of stuff as it's currently proposed 00:56:56 #info consider splitting that out from the core RFC so we can get simple things done faster 00:57:09 would this be limited to site-wide CSS? for user CSS it would have some interesting security implications like DOSing the less interpreter 00:57:10 <Gloria> TrevorParscal: That increases the implementation difficulty dramatically, then. 00:57:26 <TrevorParscal> we should introduce a new way that works together, and let users migrate their styles over, then deprecate the old way and eventually kill it 00:57:34 * Gloria nods. 00:57:35 yeah, if people use .mw-content-ltr to style things, than having .mw-content as a class of the same element won't help 00:57:38 <Gloria> Slow deprecation. 00:57:43 I'm not convinced that actually using LESS for this is a good idea 00:57:44 and if it is limited to site-wide CSS, that makes it hard for administrators to test changes 00:57:49 <TrevorParscal> Gloria: of course, but this RFC is very unrealistic in a lot of ways 00:57:58 <Gloria> The best kind of RFC, heh. 00:58:25 <TrevorParscal> gwicke: we could just use an iframe for content, solves CSS leaks both ways :) lol 00:58:35 I'm frankly, becoming a bit less excited about it too, I didn't see that many obstacles coming 00:58:54 TrevorParscal, yay! 00:59:06 <Edokter> Yuuuuck! 00:59:59 more seriously, a shallow grammar that identifies CSS selectors and bodies is very simple 01:00:14 <TimStarling> I think you could do it as a formatter 01:00:39 so if the only task is prefixing all selectors with something, then that could probably be done very efficiently and securely without LESS 01:00:39 <TimStarling> the LESS code is split into a parser and a hierarchy of small formatter classes 01:00:41 formatter? 01:00:55 <TimStarling> the formatter classes take what is called a CSS tree, and generate a string 01:01:06 lessphp? 01:01:17 <TimStarling> includes/libs/lessc.inc.php 01:01:20 yes 01:01:26 <TrevorParscal> TimStarling is 20% done with writing the LESS plugin 01:02:17 I'll have a look at it 01:02:37 jdlrobson: btw, did you discuss the class-triggered CSS include idea at the architecture summit? 01:03:42 ok guys, i gotta run 01:03:47 <TrevorParscal> me too 01:03:55 <TrevorParscal> wrap up? 01:03:58 if there's any more ideas feed them to meetbot 01:04:01 gwicke: nope - https://www.mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_templates#Proposal is basically what we wrapped up with at the summit 01:04:11 <TimStarling> it'd just be like http://paste.tstarling.com/p/ieuyvN.html 01:04:25 jdlrobson, k 01:04:29 it sounds�ed like people were very anti having multiple wiki pages to put stuff sadly 01:04:34 <TimStarling> except with code duplication instead of as a patch 01:04:38 ok, any #agreed or #action stuff left to say? 01:04:46 <TrevorParscal> TimStarling: nice 01:05:19 jdlrobson, what was the argument against having a page per logical collection of classes? 01:05:21 <TrevorParscal> looks like it's going to be pretty simple actually 01:06:15 CSS:hlist for example 01:06:21 gwicke: most editors in the room were very against the idea of having to go to a different page to edit CSS for simple templates. 01:06:35 TimStarling, I'll just have to see how dependent it is on changes to lessphp 01:06:50 we don't want to have a burden of updating this every time we updates lessphp 01:07:38 <TimStarling> the formatter interface is probably relatively stable, since you only need to update it when the CSS grammar changes, not when the LESS grammar changes 01:07:42 jdlrobson, otoh many styles can be shared between templates 01:08:16 and encouraging editors to do so is a good thing IMO 01:08:40 <Edokter> are we at templates yet? 01:08:51 jdlrobson is AFK 01:08:52 Edokter, officially the meeting is over already 01:09:21 <Edokter> bah... I waited for this one 01:09:41 my idea on that was https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Allow_styling_in_templates#Class-triggered_CSS_includes 01:09:54 Well, it's not quite over until one of the chairs does #endmeeting 01:09:57 <TrevorParscal> TimStarling: I think since we have full control over updating LESS.php, as long as we have a test that fails when our subclass stops working we should be in good shape 01:09:57 also scoped by rewriting selectors 01:10:54 Edokter: I'm sorry, I won't schedule more than 2 RFCs into a 1-hr RFC review in the future 01:11:09 <TimStarling> sorry Edokter 01:11:46 <TimStarling> we can fit in 3 if we're very disciplined, but usually it ends up being 2 or 2½ 01:11:56 <Edokter> I'll post my thoughts on the RFC talk page 01:12:04 <TimStarling> #endmeeting