Architecture meetings/RFC review 2014-02-27

From MediaWiki.org
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-officeconnect 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]

  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:[edit]

  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 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 .


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
Retrieved from "https://www.mediawiki.org/w/index.php?title=Architecture_meetings/RFC_review_2014-02-27&oldid=916899"