The DJ these are some great points and super useful (and to me what an RFC should be all about - entertaining the proposal and playing devils advocate) - could you add these to the RFC so they don't get lost? In terms of the RTL problem - I could imagine a RTL stylesheet would be useful here - I don't think RTL rules should be surfaced on a LTR site. I also don't think that CSS that is only active in a certain namespace should be loaded everywhere (although another viewpoint is that this leads to more css fragmentation so there are 2 sides to this argument)
(I'll copy this response to RFC when it's there :)) On Wed, Jul 17, 2013 at 4:39 PM, Derk-Jan Hartman <[email protected]> wrote: > On 16 jul. 2013, at 23:51, Juliusz Gonera <[email protected]> wrote: > >> I wrote an RFC about scoping Common.css and Mobile.css: >> https://www.mediawiki.org/wiki/Requests_for_comment/Scoping_site_CSS >> >> In short: this could help us separate CSS rules added by administrators from >> the core UI rules of MediaWiki. >> >> What we would get: >> * UI (chrome) CSS more predictable and broken less often >> * no crazy UI styling as seen at https://nv.wikipedia.org >> >> Please share your thoughts. > > Some things to remember: > * Content isn't always inside the #content node (think navpopups, > reftooltips, image annotation extension, stuff (TMH) inside jquery dialogs > etc). > * Anything no longer allowed by Common.css could easily be injected using > javascript. > * You can still get out of #content by using relative or absolute positioning > * Some CSS in Common.css is already prefixed with #content (or body) > sometimes, for specificity reasons. What will LESS do with that... > * Some CSS in Common.css is namespace specific and thus relies on the ns-# > classes of the body. > * Some CSS in Common.css is rtl specific and thus relies on the rtl class of > the body. There is no rtl class on #content and #mw-content-text has a > different meaning. > * Some CSS in Common.css targets UI, not content. > > That's a lot of potential breaking points for a lot of existing > installations, that will need to be 'guided' trough the process. I count > about 40 selectors in the English Wikipedia that would require fixing. Some > of the existing content selectors would not be possible after your scenario > unless using Javascript. > > In principle it is a nice idea, and I think we should slowly move into that > direction. But in terms of styling, it's somewhat security trough obscurity > if you ask me. > > Also: https://nv.wikipedia.org wtf? Something as unreadable as that goes > against core principles. I can't believe it's been there for years already.... > > DJ > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson http://jonrobson.me.uk @rakugojon _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
