Architecture meetings/RFC review 2014-02-27
Jump to navigation
Jump to search
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 #wikimedia-office connect 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[edit]
- Requests for comment/Grid system - Pau Giner and Trevor Parscal
- Requests for comment/Scoping site CSS - Juliusz
Did not have time to consider:[edit]
- Requests for comment/Allow styling in templates - Jon Robson
Quick checkins if we have time:
- Inline diffs - Max Semenik
- Architecture guidelines (quick checkin)
- Performance guidelines (quick checkin)
Summary and logs[edit]
Summary and TODOs[edit]
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 <TimStarling> 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[edit]
- 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 <TimStarling> 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[edit]
Meeting logs |
---|
23:58:32 <sumanah> #startmeeting RFC review UI styling 23:58:32 <wm-labs-meetbot> 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 <wm-labs-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 23:58:32 <wm-labs-meetbot> The meeting name has been set to 'rfc_review_ui_styling' 23:58:48 <sumanah> #chair brion TimStarling 23:58:48 <wm-labs-meetbot> Current chairs: TimStarling brion sumanah 23:59:28 <sumanah> pginer: jdlrobson hey there, you have a preference for who goes first? 23:59:30 <TimStarling> ooh, working bots today, high tech 23:59:50 <sumanah> #link 23:59:55 <pginer> I would like to finish early if possible, 00:00:01 <pginer> it is 1am here 00:00:06 <sumanah> ok, pginer first :) 00:00:15 <sumanah> #topic Grid system 00:00:17 <sumanah> #info https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-27 00:00:39 <sumanah> #info https://www.mediawiki.org/wiki/Requests_for_comment/Grid_system 00:01:13 <sumanah> #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 <pginer> The language team is using an initial implementation of the concepts 00:02:11 <pginer> proposed 00:02:35 <pginer> for Content translation project 00:02:45 * Krenair waves 00:03:36 <pginer> the idea is to check that there are no major issues and be able to merge the basics into core. 00:03:43 <brion> nice 00:04:07 <pginer> I think there should be no major concerns considering that the basics are just a set of classes with predefined widths. 00:04:26 <pginer> and breakpoints 00:04:46 <pginer> LESS CSS makes it easy to tweak the specific implementation and improve later if needed. 00:05:21 <ebernhardson> ;q 00:05:22 <ebernhardson> q 00:05:42 <ebernhardson> (sorry, wrong window) 00:05:45 <jorm> UNKNOWN COMMAND: 'q' 00:05:58 <pginer> I plan to make more examples such as this: http://pauginer.github.io/agora-grid/examples/simple-demo.html 00:06:11 <jdlrobson> jorm haha 00:06:14 <pginer> To illustrate the use and make it easier to get feedback 00:06:49 <pginer> That's all I had to update. Let me know if there is any question 00:06:58 <brion> well, sounds good :) 00:07:09 <brion> what can we see it in action in? (or soon) 00:07:14 <jorm> my first question is: Does anyone think that having a grid is a *bad* idea? 00:07:34 <TimStarling> jorm: not that I know of 00:07:43 <matanya> pginer: would that look good in RTL too? 00:07:48 <brion> jorm: i had some initial concerns on first proposal, but they have been relieved by prior discussion 00:08:10 <jorm> Yeah, I didn't think there was any major objection - other than possible technical hurdles. 00:08:22 <brion> matanya: that should flip to RTL pretty straightforwardly yes 00:08:26 <gwicke> jorm, the answer probably depends on what this is used for 00:08:29 <pginer> matanya: CSSJanus should work in this context too. 00:08:48 <sumanah> #info http://pauginer.github.io/agora-grid/examples/simple-demo.html - one example by Juliusz, he plans to make more 00:08:52 <TimStarling> should we mark this RFC as accepted? 00:08:53 <jorm> I'd think we would need to grind it into Vector (somehow) 00:09:17 <jgonera> pginer what units are used to define width? 00:09:37 <pginer> It is based on percentages 00:09:46 <TrevorParscal> 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 <pginer> .one-half { width: 50%; } 00:10:02 <TrevorParscal> I support grid systems with relative sizing, but they of course have their limitations 00:10:20 <pginer> You can create an element with the classes: one-third, mobile-one-whole 00:10:56 <pginer> that will make the size of the column to change from 33% to 100% on a small screen/window 00:11:00 <TimStarling> so the idea is to provide these classes and promote them for editors to include in article styling? 00:11:15 <sumanah> 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 <Edokter> I'm very interested in grids, but does it support vertical? 00:11:33 <pginer> They are mainly thought for extension UIs 00:11:51 <pginer> The classes can be used directly but they can also used "silently" thanks to LESS 00:11:57 <pginer> That is, as mixins 00:12:31 <gwicke> do you plan to prefix them with mw? 00:12:33 <TimStarling> so by content TrevorParscal just means the content area of a skin when a special page is displayed? 00:12:43 <pginer> I can create a a sidebar whose style is .sidebar{ .one-sixth; .lap-one-third;} 00:13:16 <pginer> The HTML would only have the semantic .siebar class 00:13:19 <jorm> This only applies inside of div.#content, then 00:13:23 <TrevorParscal> 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 <pginer> gwicke, the current implementation already prefixes everything as mw-ui- 00:14:15 <TrevorParscal> 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 <gwicke> 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 <pginer> The rid is intended to play well with current styles, only elements inside a .grid element will be affected. 00:15:19 <pginer> 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 <pginer> 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 <sumanah> (anything here to be summarized in the minutes with an #info ?) 00:16:08 <pginer> 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 <pginer> that is fine 00:16:13 <jdlrobson> 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 <jdlrobson> 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 <pginer> I agree, but authors adding .one-half is better than they forcing a width:50% directly 00:18:17 <pginer> 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 <brion> �*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 <brion> but we can make use of a grid in the styles that are built around semantic things 00:19:10 <brion> like "floatable-image" or something 00:19:20 <brion> *directly out of 00:19:20 <TimStarling> I'm not suggesting anything 00:19:22 <brion> not *directly in 00:19:23 <sumanah> #info CSSJanus should work in the RTL context as well 00:19:23 <brion> 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 <sumanah> #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 <sumanah> 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 <brion> #info some indirection is recommended for use of grids in content. prefer to use semantic classes 00:21:38 <gwicke> 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 <gwicke> 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 <gwicke> 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 <brion> 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 <sumanah> perhaps pginer could respond to "<TimStarling> pginer: maybe that should be mentioned on the RFC doc" :) (action item)? 00:27:35 <brion> :) 00:28:08 <pginer> Any part you recommend adding more detail to? 00:28:11 <sumanah> does pginer need to address the bandwidth/storage/caching stuff at all? 00:28:29 <gwicke> pginer, some detail on intended use cases / prefixing would be good 00:28:37 <pginer> ok 00:29:04 <TimStarling> pginer: maybe narrow the "implementations" section 00:29:18 <pginer> Makes sense 00:29:54 <TimStarling> if possible, name the actual classes and mixins which you intend to create 00:30:30 <sumanah> #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 <pginer> 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 <pginer> thanks 00:31:27 <sumanah> 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 <sumanah> 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 <sumanah> 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 <sumanah> #link https://www.mediawiki.org/wiki/Talk:Architecture_Summit_2014/UI_styling#Scoping_site_CSS discussion from the architecture summit 00:33:41 <brion> so scoping content CSS inside the content area is ..... theoretically doable 00:33:47 <brion> keeping UI styles *out* of content is harder 00:33:54 <brion> except by blacklisting i guess :D 00:33:54 <jgonera> I updated the proposal section, the first paragraph 00:34:06 <sumanah> #help "let's figure out good ways to help editing & preview -> (who's interested?)" (from the arch summit notes) 00:34:10 <jgonera> 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 <jgonera> 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 <jgonera> TrevorParscal, you're right 00:35:15 <TrevorParscal> including to resolve issues in editing and preview 00:35:16 <jgonera> 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 <gwicke> 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 <gwicke> 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 <jgonera> 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 <gwicke> 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 <pginer> It seems to facilitate the round-trip by keeping the user provided rules unmodified. 00:38:23 <jgonera> 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 <jgonera> TimStarling, sure, it's just easier this way 00:39:04 <jgonera> 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 <jdlrobson> 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 <brion> 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 <jdlrobson> 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 <jorm> 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 <brion> Edokter: as Gloria has pointed out in previous discussion, naming-discipline "doesn't stop anyone" 00:43:20 <jgonera> 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 <gwicke> 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 <sumanah> as am I. 00:45:38 <brion> Gloria: as long as they separate the content and theme styles i'm fine with that :) 00:45:55 <jgonera> at least I can't find it on a mediawiki.org page 00:45:55 <jgonera> 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 <gwicke> even if we had to roll our own shallow grammar it would not be too hard 00:46:57 <tgr> TrevorParscal: actually with LESS .rtl .mw-content would still be possible with a ".rtl &" rule 00:47:30 <tgr> OTOH with LESS, enterprising sould could find many ways to break out 00:47:50 <tgr> &+.real-selector {} and so on 00:48:23 <jgonera> freenode is laggy as hell for me... I'm just reading from logs now 00:48:25 <brion> 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 <brion> 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 <jgonera> I'd rather not overengineer this at first and try the simplest solution to see how it works 00:49:32 <jgonera> (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 <jgonera> Gloria, that's what I said, but my messages came like 3 minutes late ;) 00:50:07 <tgr> 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 <gwicke> 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 <gwicke> 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 <jgonera> 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 <gwicke> 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 <jgonera> 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 <gwicke> 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 <jgonera> 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 <sumanah> 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 <brion> #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 <brion> #info consider splitting that out from the core RFC so we can get simple things done faster 00:57:09 <tgr> 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 <jgonera> 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 <gwicke> I'm not convinced that actually using LESS for this is a good idea 00:57:44 <tgr> 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 <jgonera> I'm frankly, becoming a bit less excited about it too, I didn't see that many obstacles coming 00:58:54 <gwicke> TrevorParscal, yay! 00:59:06 <Edokter> Yuuuuck! 00:59:59 <gwicke> 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 <gwicke> 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 <jgonera> formatter? 01:00:55 <TimStarling> the formatter classes take what is called a CSS tree, and generate a string 01:01:06 <jgonera> lessphp? 01:01:17 <TimStarling> includes/libs/lessc.inc.php 01:01:20 <jgonera> yes 01:01:26 <TrevorParscal> TimStarling is 20% done with writing the LESS plugin 01:02:17 <jgonera> I'll have a look at it 01:02:37 <gwicke> jdlrobson: btw, did you discuss the class-triggered CSS include idea at the architecture summit? 01:03:42 <brion> ok guys, i gotta run 01:03:47 <TrevorParscal> me too 01:03:55 <TrevorParscal> wrap up? 01:03:58 <brion> if there's any more ideas feed them to meetbot 01:04:01 <jdlrobson> 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 <gwicke> jdlrobson, k 01:04:29 <jdlrobson> 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 <sumanah> ok, any #agreed or #action stuff left to say? 01:04:46 <TrevorParscal> TimStarling: nice 01:05:19 <gwicke> 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 <gwicke> CSS:hlist for example 01:06:21 <jdlrobson> 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 <jgonera> TimStarling, I'll just have to see how dependent it is on changes to lessphp 01:06:50 <jgonera> 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 <gwicke> jdlrobson, otoh many styles can be shared between templates 01:08:16 <gwicke> and encouraging editors to do so is a good thing IMO 01:08:40 <Edokter> are we at templates yet? 01:08:51 <jgonera> jdlrobson is AFK 01:08:52 <gwicke> Edokter, officially the meeting is over already 01:09:21 <Edokter> bah... I waited for this one 01:09:41 <gwicke> 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 <sumanah> 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 <gwicke> also scoped by rewriting selectors 01:10:54 <sumanah> 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 |