Jump to content

Architecture meetings/RFC review 2014-02-27

From mediawiki.org

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]
  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"