Admin and CSS Custom Properties

115 views
Skip to first unread message

Patrick Guido

unread,
Apr 27, 2017, 7:07:50 AM4/27/17
to django-d...@googlegroups.com
Hi everyone! 

I think this is probably my first post here! Anyway... I was recently working on a
django project where I was asked to change the admin theme (just the colors).

I did so using CSS custom properties (see [1]) so that I would have all the colors[2] set
in one file.

I'd like to start adopting CSS custom properties in the django admin.
It shouldn't take too much time, ideally what I'd like to do is this:

1. find all the colors used in the admin
2. create a `variables/colors.css` file where we put all the colors used in the admin
3. add another color/background-color (or any CSS rule) where we use the variable defined
  in the previous file, so that old browsers still use the default color, but new ones use the 
  color set from the variable.

That should mostly be it, a user can override the variables by adding another CSS file, or
by creating a new static file in `admin/css/variables/colors.css`

The only issues I can see are:

1. there won't be an easy way to override colors for old browsers (same as now)
2. one additional http request
3. if we ever change (or add/delete) one color we need to remember to update the variable file
    and the CSS

Do you any feedback on this? I might start a PR during this weekend or the next one :)


[2] but this is not limited to colors, can be used for fonts, margins, etc

--
Patrick Guido Arminio

Adam Johnson

unread,
Apr 27, 2017, 6:19:17 PM4/27/17
to django-d...@googlegroups.com
Thanks for introducing me to a new CSS feature! I clearly don't keep up with front end stuff enough.

Re: your issues:

1. From the support grid at the bottom of the Smashing Magazine article you linked, it looks like it's only IE 11 and Edge 14 that are major browsers that don't support it. However I feel like if Django is going to announce a feature like "you can override the Admin colours", it should work in all browsers. I'm not sure if we have a written policy for this though.

2. I'm not a huge fan of an additional HTTP request for every admin page load, for every admin site in existence whether or not the colours have been overridden. HTTP/2 isn't very widely deployed still so requests still ain't cheap.

3. This can be overcome with a test to ensure the two files are in sync, I guess?

And one more question: how much less painful is this to override the colours compared to the variable-less way, where you just clone the colour definitions of every rule in the original file in a second override file?

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAOUxZcv836UE3LL26JiZnrd7Mfes8_Yf2Cvxbr%2BOe9f2sTyTdg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.



--
Adam

Patrick Guido

unread,
Apr 28, 2017, 5:15:16 AM4/28/17
to django-d...@googlegroups.com
On 27 April 2017 at 23:18, Adam Johnson <m...@adamj.eu> wrote:
Thanks for introducing me to a new CSS feature! I clearly don't keep up with front end stuff enough.

Re: your issues:

1. From the support grid at the bottom of the Smashing Magazine article you linked, it looks like it's only IE 11 and Edge 14 that are major browsers that don't support it. However I feel like if Django is going to announce a feature like "you can override the Admin colours", it should work in all browsers. I'm not sure if we have a written policy for this though.
I guess it also depends on use cases, usually (where I work) we tend to support only latest browsers when it comes to admin, since
it will be used by only a few people :) But I see your point.

A friend of mine was suggesting configuring colours in python, but this means that the css would be rendered via python, which is
not ideal.
Another solution would be to add a JS polyfill to make it work on older browsers, but I'm against it :)
Let's also keep in mind that this (if approved) will be included in django 2.0 or later, so the browser support will be even better :)

 

2. I'm not a huge fan of an additional HTTP request for every admin page load, for every admin site in existence whether or not the colours have been overridden. HTTP/2 isn't very widely deployed still so requests still ain't cheap.
Uhm, I think we can easily skip one request if the colours have not been overridden. We can put the vars in base.css.
Then we can add the variables by changing the template (but that's more cumbersome) either by adding an external css link
or by adding a style tag with the variables.
 
3. This can be overcome with a test to ensure the two files are in sync, I guess?
Uhm, true!
 
And one more question: how much less painful is this to override the colours compared to the variable-less way, where you just clone the colour definitions of every rule in the original file in a second override file?
I haven't checked all the rules, but I think it will require quite a bit of work. Maybe we can create a "template" file
that can be used to override quite easily the colours, but that doesn't scale too well I think. 


--
Patrick Guido Arminio

Curtis Maloney

unread,
Apr 28, 2017, 6:38:57 AM4/28/17
to django-d...@googlegroups.com
I recently discovered that the stated "policy" on browser support in
Admin is... well... not clear at all.

https://docs.djangoproject.com/en/1.11/faq/admin/#what-browsers-are-supported-for-using-the-admin

It claims to support full function for "YUI's A-Grade" browsers, but the
link it provides does nothing to explain the supported versions, and a
further "target environments matrix" link still lists IE6.

So perhaps it's time to update the FAQ, and have a discussion on what
Admin's browser support policy needs to be updated to.

--
Curtis

On 28/04/17 19:14, Patrick Guido wrote:
> On 27 April 2017 at 23:18, Adam Johnson <m...@adamj.eu
> --
> You received this message because you are subscribed to the Google
> Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-develop...@googlegroups.com
> <mailto:django-develop...@googlegroups.com>.
> To post to this group, send email to django-d...@googlegroups.com
> <mailto:django-d...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAOUxZcugkWEnyx3wt7uXNYJE_Rgix-5N_iPwxMbZS73RA63%3DFw%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAOUxZcugkWEnyx3wt7uXNYJE_Rgix-5N_iPwxMbZS73RA63%3DFw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

Collin Anderson

unread,
Apr 28, 2017, 8:00:36 AM4/28/17
to django-d...@googlegroups.com
I suggest supporting IE11+, as that's the latest on Windows 7 and there's not much 9-10 usage. Now's probably a good time to bump them if needed because we're just past an LTS.

Though, yes, it doesn't allow CSS variables.

<mailto:django-developers+unsubsc...@googlegroups.com>.
To post to this group, send email to django-developers@googlegroups.com
 <mailto:django-developers@googlegroups.com>.

Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAOUxZcugkWEnyx3wt7uXNYJE_Rgix-5N_iPwxMbZS73RA63%3DFw%40mail.gmail.com
 <https://groups.google.com/d/msgid/django-developers/CAOUxZcugkWEnyx3wt7uXNYJE_Rgix-5N_iPwxMbZS73RA63%3DFw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.

Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/db7742bc-769b-85fe-af87-c398fa99215d%40tinbrain.net.

Patrick Guido

unread,
Apr 28, 2017, 8:05:24 AM4/28/17
to django-d...@googlegroups.com
On 28 April 2017 at 12:59, Collin Anderson <cmawe...@gmail.com> wrote:
I suggest supporting IE11+, as that's the latest on Windows 7 and there's not much 9-10 usage. Now's probably a good time to bump them if needed because we're just past an LTS.

Though, yes, it doesn't allow CSS variables.
Is it really an issue to use a feature that doesn't work on older browser but doesn't degrade the experience?
If you use CSS variables with a fallback you will have the best of both worlds. 

The admin will continue working on old browsers, but on the new ones you can use a custom color scheme.

--
Patrick Guido Arminio

Dmitriy Sintsov

unread,
Apr 29, 2017, 4:12:57 AM4/29/17
to Django developers (Contributions to Django itself)
CSS variables are long time available at server-side via LESS / SASS compilers. For example MediaWiki has built-in ResourceLoader that includes LESS compiler and JS minifier. It uses caching to re-compile only when source .less or .js are changed. Everything works even with IE8. But MediaWiki is an "out-of-box use" software not a framework like Django.

When changing colors, most easy way is to use Bootstrap for admin templates. In such way, changing colors is as easy as dropping bootstrap skin into 'static/css/bootstrap_skin.css' and specifying it with Admin.Media subclass css attribute. There are lots of ready bootstrap 3 skins as well as bootstrap editors. Also it works with old IE and no CSS variables are needed (they are compiled separately from Bootstrap source code).
--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages