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
<d.j.hartman+wmf_ml(a)gmail.com> wrote:
On 16 jul. 2013, at 23:51, Juliusz Gonera
<jgonera(a)wikimedia.org> 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
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l