[12:17:45] brion: I've been giving some thought to the scoping thing, and I'm increasingly less convinced that trying to do it automatically is worthwhile. It's trivial to do manually by template authors, but trying to force it seems to be fraught with issues. [12:18:45] Coren: on the css side or the html side? [12:19:05] brion: The issues? On the html side. [12:19:59] brion: The CSS side is trivial; every declaration has a proper array of selectors, prepending a clause to them is about two lines of code. [12:20:51] But also it limits some (IMO) reasonable use cases. [12:21:34] Not insane: have a template {{foo-styles}} that defines a pile of styles that are then used by a family of other templates that are used together. [12:23:11] Template authors that /want/ to scope (and we should encourage that) can wrap the template in a or
as suitable, and give it a class they can then use as selector - leaving it to the author means that we don't need to worry about balancing ourselves, but the resulting templates nevertheless end up balanced. [12:23:32] But, more importantly, it means they can wrap in some /common/ class. [12:24:01] And at a {{foo-styles}} template to the individual templates and not have to do copypasta [12:24:09] s/at/add/ [12:24:48] A.k.a.: Have the style cake and eat it too. :-P [12:25:27] at the cost of increased collisions, leakage, etc, sure [12:25:31] it's a decision one way or the other [12:26:37] Well, my *opinion* is that giving the more flexible tool that can be used both way is a win - but that might be the old hand geek talking. [12:27:04] that's what folks said when they made sscanf into fixed-length buffers work ;) [12:27:40] Heh. That *might* be overstating matters a bit. [12:27:45] heheh [12:28:13] Hm. How about a @scope faux at rule that decides /what/ the prefixed selector is? Still alllows grouping then. [12:28:48] we should at least force scoping to inside the content area [12:29:17] it's bad enough folks can use absolution positioning to overlay UI elements with fake ones, ebing able to change the existing ones feels scarier for security [12:29:54] Hmmm. Good point. Not hard to do: add mw-context-text to the selectors. [12:29:59] Coren: could be interesting for style-library usage yeah [12:30:28] though i suppose you could just opt in to a scope by pasting .foobar manually on a few rules [12:30:33] Or at least mw-body if we want to allow styling of title, etc. [12:30:38] or we could use the sass processor hehehehhe [12:30:52] no, title is part of user interface [12:30:57] can't rely on styling it [12:31:20] brion: Yeah, you can always *do* scoping. [12:31:22] for instance on ios the title's a native label i believe [12:31:25] *ios app [12:31:44] brion: Good point. mw-context-text makes more sense then. [12:31:52] cross-content-display-system portability is hard ;) [12:32:38] I got a patch for minor tweaks and linting, and for adding functional value filtering in. Ima do one for adding selectors now. [12:33:09] Also still need to do unit tests. I've almost managed to wrap my head around our harness and conventions now. [12:33:53] That'll teach me to leave mw coding to "everyone but me" for years. :-P [12:35:29] brion: How do you feel about this then: add "@scope ;" default to 'mw-content-text' but allow specifying more and prefix the rules with those? [12:35:44] sure let's try that [12:35:54] should get us through a good test :D [12:36:07] and we'll get a better feel after porting a few templates maybe [12:36:15] brion: "Good" template authors will then want to wrap their expansion in some tag with the class in question, but styles still shouldn't leak out. [12:36:27] yep :) [12:36:47] so that lets you pull in a style lib via {{aslkdjlfasj}} instead of having to do {{aslkdjlfd| .... and a bunch of content ... }} [12:36:50] brion: No doubt. Getting this in a form suitable for deploying on beta is my first priority - then we can import a bunch of ugly templates and test. [12:37:01] :D [12:37:03] beta ftw [12:38:15] brion: The extra win with doing the {{style-lib-foo}} way is that this deduplicates automagically. getTemplates() will return the template exactly once even if it's transcluded dozens of times. [12:38:23] yep [12:38:40] hmm one thought [12:38:48] if people build a style lib out of multiple subtemplates... [12:38:55] ...those might not load in a predictable order [12:39:03] currently i think they'll come back in order of page_id of the template [12:39:29] which could be surprising, and could change over time in case of renames [12:39:37] I don't think that's an issue? document as "order is stable but undefined - rely on order at your own risk"? [12:40:05] well, we can say that but that's like handing people a book with small print "chapters may be out of order" [12:40:06] Good CSS rely on selectors, not order. [12:40:13] yes well [12:40:23] we don't always get the css we want [12:40:25] we get the css we deserve [12:40:32] ;) [12:40:39] I can always sort the rules according to some other, specified order. [12:41:27] hmm, authoring tool helper could also help identify conflcits [12:41:28] But to be honest, I'd wait until someone comes up with a reasonable use case that relies on order and can't be done properly beforehand. It's easyenough to backfit if neeed. [12:41:30] template style linter :D [12:41:36] yeps [12:42:21] brion: (btw, thanks for letting me pick your brain this much) [12:43:11] :D [12:43:13] sure thing! [12:45:42] Oh, is there a canonical list of properties we don't want to allow? [12:46:01] we should probably make one :) [12:46:40] I know of 'behavior', '-moz-binding' and '-o-link' but there are probably others. Doing a whitelist for properties is probably impractical. [12:47:03] whitelist is doable but will take work to collect one ;) [12:47:09] start with blacklist definitely [12:47:26] besides technically anything you can stuff into a rule you can already do inline, so let's just replicate that blacklist for start [12:47:37] True dat. [12:47:54] ideally we'd eventually use the same rule validator on both sides [12:48:21] Isn't the point of this to forbid inline styles? :-P [12:48:46] not to forbid them, but to discourage them by providing a far superior alternative [12:48:58] that also happens to be much, MUCH easier to make responsive to different screen sizes ;) [12:49:10] * Coren afks for a few. [12:49:10] author chocie yo [13:32:47] * Coren returns. [15:03:15] James_F: probably https://phabricator.wikimedia.org/T131189 [15:03:45] greg-g: Ta. [22:14:06] Dereckson: should i get the fix for https://phabricator.wikimedia.org/T132285 deployed this SWAT? any reason not to? [22:14:13] (or, are you around to deploy it?) [22:15:19] hi [22:15:36] Yes, I'm on the page Deployment to add it. [22:24:28] By the way, I filled, without any conviction, the upload wizard large video upload bug. [22:24:48] without any conviction because we have 0 info to add to this bug [22:25:13] https://phabricator.wikimedia.org/T132300 [22:28:32] yeah. i'll be looking at it. [22:31:02] Would you have any idea of strategy to get information? [22:31:35] like where some data could be logged or how to use X-Wikimedia-Debug? [22:34:42] Dereckson: nothing obvious comes to mind [22:35:40] We have new capabilities of debug: https://wikitech.wikimedia.org/wiki/X-Wikimedia-Debug