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