RFC: Scoping site CSS

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: Scoping site CSS

Juliusz Gonera
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.

--
Juliusz

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Scoping site CSS

C. Scott Ananian
On Tue, Jul 16, 2013 at 5:51 PM, Juliusz Gonera <[hidden email]>
 wrote:

> I wrote an RFC about scoping Common.css and Mobile.css:
> https://www.mediawiki.org/**wiki/Requests_for_comment/**Scoping_site_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.
>

This could also be useful for VE/Parsoid; see
https://bugzilla.wikimedia.org/show_bug.cgi?id=51245
  --scott

--
(http://cscott.net)
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Scoping site CSS

Yuvi Panda
In reply to this post by Juliusz Gonera
Yay! I see several good things that could come out of this, but to
prevent pitchforks and misunderstandings, I think this RFC should be
split some more.

So ideally, this should be split into multiple RFCs. The ones I can
think of, so far:

1. LESS support for RL.
2. Separate CSS(LESS?) that applies just to content, and is scoped as such.
3. An easier way to custom-style your wiki that does not require you
to edit CSS, and also can be as flexible as the current one.
4. Remove customizability via Site / User CSS.

1 and 2 should mostly get general support, and *should* get what we
want (content styles that we can load by themselves without
conflicting the UI). 3 is awesome, but also very hard - and does not
have a clear use case. 4 is akin to taking away internet from a
hackerspace and is a lot, lot harder - and of limited benefit.

So... split this? :)

--
Yuvi Panda T
http://yuvi.in/blog

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Scoping site CSS

Alex Monk
4 is basically pointless. I hope that will never get approved (I very much
doubt it will anyway).

Alex Monk

On Wed, Jul 17, 2013 at 10:59 PM, Yuvi Panda <[hidden email]> wrote:

> Yay! I see several good things that could come out of this, but to
> prevent pitchforks and misunderstandings, I think this RFC should be
> split some more.
>
> So ideally, this should be split into multiple RFCs. The ones I can
> think of, so far:
>
> 1. LESS support for RL.
> 2. Separate CSS(LESS?) that applies just to content, and is scoped as such.
> 3. An easier way to custom-style your wiki that does not require you
> to edit CSS, and also can be as flexible as the current one.
> 4. Remove customizability via Site / User CSS.
>
> 1 and 2 should mostly get general support, and *should* get what we
> want (content styles that we can load by themselves without
> conflicting the UI). 3 is awesome, but also very hard - and does not
> have a clear use case. 4 is akin to taking away internet from a
> hackerspace and is a lot, lot harder - and of limited benefit.
>
> So... split this? :)
>
> --
> Yuvi Panda T
> http://yuvi.in/blog
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Scoping site CSS

Yuvi Panda
On Thu, Jul 18, 2013 at 3:35 AM, Alex Monk <[hidden email]> wrote:
> 4 is basically pointless. I hope that will never get approved (I very much
> doubt it will anyway).

I agree, and separating that out from the other 3 should help in
making sure that everyone doesn't get distracted by 4 while 1-3 are
indeed nice things by themselves :)

--
Yuvi Panda T
http://yuvi.in/blog

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Scoping site CSS

Derk-Jan Hartman
In reply to this post by Juliusz Gonera
On 16 jul. 2013, at 23:51, Juliusz Gonera <[hidden email]> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Scoping site CSS

Jon Robson
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
<[hidden email]> wrote:

> On 16 jul. 2013, at 23:51, Juliusz Gonera <[hidden email]> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



--
Jon Robson
http://jonrobson.me.uk
@rakugojon

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Scoping site CSS

Brad Jorsch (Anomie)
In reply to this post by Yuvi Panda
On Wed, Jul 17, 2013 at 5:59 PM, Yuvi Panda <[hidden email]> wrote:
> 1. LESS support for RL.

Don't we want more support for RL, not less? ;)

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Scoping site CSS

Matthew Flaschen-2
In reply to this post by Yuvi Panda
On 07/17/2013 05:59 PM, Yuvi Panda wrote:
> Yay! I see several good things that could come out of this, but to
> prevent pitchforks and misunderstandings, I think this RFC should be
> split some more.
>
> So ideally, this should be split into multiple RFCs. The ones I can
> think of, so far:
>
> 1. LESS support for RL.

Note, there are bugs for both LESS
(https://bugzilla.wikimedia.org/show_bug.cgi?id=40964) and Sass
(https://bugzilla.wikimedia.org/show_bug.cgi?id=46545) integration for
ResourceLoader.

Matt Flaschen


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l