Django Admin New Look

4,606 views
Skip to first unread message

Alexey

unread,
Mar 4, 2015, 2:15:33 PM3/4/15
to django-d...@googlegroups.com
Hi guys,

I think django admin needs new look. I played with styles recently and that's the result: https://github.com/django/django/pull/4232

Inspired by a new djangoproject.com site. 

New theme looks modern, fresh and clean. There are CSS changes only. No any HTML changes.

Let's discuss it. I will appreciate any feedback.

Thanks

P.S. I can create demo app if it needs.

elky

unread,
Mar 4, 2015, 3:56:17 PM3/4/15
to django-d...@googlegroups.com
Quick summary of the PR discussion:
  • Everyone (ok, probably not) understands that current admin interface looks old
  • Green theme I used from djangoproject site isn't good idea - admin shouldn't be associated with brand 
  • It's better to keep default color scheme (most of apps uses this scheme in their components/widgets)
  • CSS-only approach is good idea for the beginning

Riccardo Magliocchetti

unread,
Mar 4, 2015, 5:27:57 PM3/4/15
to django-d...@googlegroups.com
Il 04/03/2015 21:56, elky ha scritto:
> Quick summary of the PR discussion <https://github.com/django/django/pull/4232>:
>
> * Everyone (ok, probably not) understands that current admin interface looks old
> * Green theme I used from djangoproject site isn't good idea - admin shouldn't
> be associated with brand
> * It's better to keep default color scheme (most of apps uses this scheme in
> their components/widgets)
> * CSS-only approach is good idea for the beginning

Looks good, thanks for your work! Looking forward for a blueish theme :)


--
Riccardo Magliocchetti

elky

unread,
Mar 11, 2015, 4:20:31 PM3/11/15
to django-d...@googlegroups.com
Hi everyone,

I reworked my previous attempt of stylizing django admin and now it looks more like original in terms of color scheme. See attachments.

For those who want to play with new theme I created an app which is very simple to install, see here: https://github.com/elky/django-flat-theme. Feel free to criticize - I'll appreciate any feedback. 

Thank you

8cd90460-c71e-11e4-87da-70dc340c7a50.png
69f33268-c71e-11e4-9ac6-48866199f5f5.png
76b7d878-c71e-11e4-8f25-513a0170fbba.png
8074bc1e-c71e-11e4-97e4-146f9d824f81.png

Bruno Ribeiro da Silva

unread,
Mar 11, 2015, 4:49:16 PM3/11/15
to django-d...@googlegroups.com
Looks good! Congrats!

--
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.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/da28de40-82b4-44e3-875d-1b18f930704e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
Bruno Ribeiro da Silva
Python Dev and Homebrewer!

Collin Anderson

unread,
Mar 11, 2015, 5:31:42 PM3/11/15
to django-d...@googlegroups.com
That looks beautiful! I can see all of the improvement from last time too!

I'd personally prefer slightly less vertical padding, but otherwise I think it's awesome!

Thanks!
Collin

Thomas Rega

unread,
Mar 11, 2015, 5:45:03 PM3/11/15
to django-d...@googlegroups.com

+1

Aymeric Augustin

unread,
Mar 11, 2015, 6:02:42 PM3/11/15
to django-d...@googlegroups.com
2015-03-11 21:20 GMT+01:00 elky <manse...@gmail.com>:
I reworked my previous attempt of stylizing django admin and now it looks more like original in terms of color scheme. See attachments.

This looks good!

Now let's try and see if we can merge it :-)

Here are some questions that come to mind:

1) Roboto is licensed under the Apache License. I don't think we can simply distribute it under Django's BSD license. This can be solved in various ways but mustn't be forgotten.

2) I'm not sure how people will feel about shipping 320kB of fonts with Django. That's a few percent of Django's total size. That's better than using Google Fonts by default, though.

3) Did you test RTL? Just set your language to Hebrew (he), browse the admin and see if the layout breaks.

4) Did you test non-trivial cases — say, horizontal filter in a tabular inline? The easiest would be to have a few models and admins configured to use all admin options. People who develop custom admin skins need this; I would be surprised if this didn't exist already.

5) Did you test your design with some accessibility checking tool? If we're modernizing the admin, let's try to do this right. Jessica McKellar made some good points during her keynote at DjangoCon Europe 2012. Watch it at least skim Reinout van Rees' notes!

I hope this helps,

--
Aymeric.

Aaron C. de Bruyn

unread,
Mar 12, 2015, 12:03:36 AM3/12/15
to django-d...@googlegroups.com
Beautiful. It's clean and simple.

Great work!

-A

Alexey

unread,
Mar 12, 2015, 6:31:32 AM3/12/15
to django-d...@googlegroups.com
Thanks you Aymeric

On 12 March 2015 at 03:02, Aymeric Augustin <aymeric....@polytechnique.org> wrote:

Now let's try and see if we can merge it :-)

Nice to hear :) But I think there's no rush and we need more testing and more feedback. 


I'm not sure how people will feel about shipping 320kB of fonts with Django.
 
We can reduce fonts size by 160kB I believe. I used 4 font weights - light, regular, medium and bold - so I think we can remove 'light' and 'medium' from there (they are used in just few places). I'll play with it and come back to this issue.

 
Did you test RTL?

I did - I tested Arabic and Hebrew - no issues detected for me. BUT. As far as I understand Django admin has poor RTL support by itself. Changing locale to Arabic is not enough to test it - to see what really happens with RTL you need to set dir="rtl" attribute for html tag (try to do it via dev tools in browser). And that's where issues really are - see screenshots:
- https://db.tt/WaIiB3D1 (button overlaps header)
- https://db.tt/ApDqDOzw (form labels are not properly aligned)
I can fix it as part of new theme or as part of current admin. Let's decide.

 
Did you test non-trivial cases — say, horizontal filter in a tabular inline? 

Yes, I tested this theme on real project which is big and complex. But I'm not 100% sure that I saw all cases. I think we need more user's feedback on it.

 
Did you test your design with some accessibility checking tool?

No I didn't. Thanks for suggestion. I'll check.



Thanks,
Alex

elky

unread,
Mar 12, 2015, 6:35:12 AM3/12/15
to django-d...@googlegroups.com
Thanks you Aymeric

Now let's try and see if we can merge it :-)
Nice to hear :) But I think there's no rush and we need more testing and more feedback.

I'm not sure how people will feel about shipping 320kB of fonts with Django
We can reduce fonts size by 160kB I believe. I used 4 font weights - light, regular, medium and bold - so I think we can remove 'light' and 'medium' from there (they are used in just few places). I'll play with it and come back to this issue.

Did you test RTL?
I did. I tested Arabic and Hebrew - no issues detected for me. BUT. As far as I understand Django admin has poor RTL support by itself. Changing locale to Arabic is not enough to test it - to see what really happens with RTL you need to set dir="rtl" attribute for html tag (try to do it via dev tools in browser). And that's where issues really are - see screenshots:

Jonhnatha J. R. Trigueiro

unread,
Mar 12, 2015, 7:23:34 AM3/12/15
to django-d...@googlegroups.com
Hi Alexey,

I started using it on my project. Awesome.
Clean and beautiful interface.

Thank You!

--
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.
Visit this group at http://groups.google.com/group/django-developers.

For more options, visit https://groups.google.com/d/optout.



--
Atenciosamente,

Jonhnatha J.R. Trigueiro
joepre...@gmail.com
+55 84 8888 4224
 

Tom Christie

unread,
Mar 12, 2015, 7:58:27 AM3/12/15
to django-d...@googlegroups.com
Amazing work so far. :)

Florian Apolloner

unread,
Mar 12, 2015, 10:39:49 AM3/12/15
to django-d...@googlegroups.com
First off, great work Alex!


On Thursday, March 12, 2015 at 11:31:32 AM UTC+1, elky wrote:
Yes, I tested this theme on real project which is big and complex. But I'm not 100% sure that I saw all cases. I think we need more user's feedback on it.

You could create a project with a few models and (crazy) AdminConfigs and throw it onto Heroku so everyone can play around with it. This way we'd also have an easy way to "show" issues.

Did you test your design with some accessibility checking tool?

No I didn't. Thanks for suggestion. I'll check.

In line with that, how does it perform for mobile devices?

Cheers,
Florian

elky

unread,
Mar 13, 2015, 6:33:58 AM3/13/15
to django-d...@googlegroups.com
In line with that, how does it perform for mobile devices?

Same as default django admin. I don't plan to make admin responsive yet (to make it perfectly accessible on mobile) - just because we can't control third-party apps. Ideally django should have its own css framework for that but not in near future I think.

elky

unread,
Mar 13, 2015, 7:42:35 AM3/13/15
to django-d...@googlegroups.com
Did you test RTL?
I did. I tested Arabic and Hebrew - no issues detected for me. BUT. As far as I understand Django admin has poor RTL support by itself.

Sorry guys, I was wrong about it. Django has very good RTL support! Just didn't notice right setting to test it. But anyway I did few tweaks in my theme. 

Tim Graham

unread,
Mar 16, 2015, 9:44:23 AM3/16/15
to django-d...@googlegroups.com
In some previous discussion, it was suggested to have a toggle between the new and old designs to ease the transition. I guess this could be something like a "theme" attribute on AdminSite. Do you think this is required? It seems this could be a non-trivial maintenance burden if we have to test and maintain two designs for some time.

elky

unread,
Mar 16, 2015, 10:41:54 AM3/16/15
to django-d...@googlegroups.com
As far as I remember the main argument of that suggestion was third-party apps will be broken in terms of color scheme (this was in green-theme discussion). But now we have new look with same colors as default admin. So I don't think we need additional setting to switch themes - primarily because community will have to support this setting (deprecate and then remove) in future Django versions.

I'm going to make pull request this week, so in case of success I hope people will have enough time to test new theme in alpha and beta releases.

Aymeric Augustin

unread,
Mar 16, 2015, 1:24:39 PM3/16/15
to django-d...@googlegroups.com
2015-03-16 15:41 GMT+01:00 elky <manse...@gmail.com>:
I'm going to make pull request this week, so in case of success I hope people will have enough time to test new theme in alpha and beta releases.

For what it's worth, I've deployed your theme on an internal application and received positive feedback from users. I don't receive feedback often, let alone positive feedback.

--
Aymeric.

elky

unread,
Mar 18, 2015, 2:34:16 PM3/18/15
to django-d...@googlegroups.com
Awesome!! Sounds fantastic. Thanks, Aymeric

On Monday, 16 March 2015 22:24:39 UTC+5, Aymeric Augustin wrote:
For what it's worth, I've deployed your theme on an internal application and received positive feedback from users. I don't receive feedback often, let alone positive feedback.

Which branch is better to open pull request? Theme works perfectly in 1.8b2 but seems it's too late to catch the last train.

Thanks

Ryan Hiebert

unread,
Mar 18, 2015, 2:41:33 PM3/18/15
to django-d...@googlegroups.com
In the likely event that it won’t be back ported to 1.8, can you release it on PyPI? Actually, you may wish to do that anyway for older versions.

I use setup.py to install my django app, so it’s difficult to add direct github url dependencies. (It takes a flag when installing with pip, which isn’t enabled in my environment).

Ryan

--
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.
Visit this group at http://groups.google.com/group/django-developers.

elky

unread,
Mar 18, 2015, 2:53:04 PM3/18/15
to django-d...@googlegroups.com
Yeah, I'm planning to publish this app on pypi this week

elky

unread,
Mar 19, 2015, 7:02:51 PM3/19/15
to django-d...@googlegroups.com
django-flat-theme is available on pypi now: https://pypi.python.org/pypi/django-flat-theme

elky

unread,
Apr 7, 2015, 11:16:42 AM4/7/15
to django-d...@googlegroups.com
Hi everyone. As you can see there is less activity now in this thread. With the latest 0.9.3 release I just think CSS work is over until anyone report a bug or suggestion to improvement.

There is big interest from the community:
- 1736 downloads in the last month from PyPi
- 334 unique visitors of the repo and 117 stars

People actively use this theme so it's time to think what do to next.

I would like to make Pull Request in Django 1.9 branch when it starts - but I need feedback and suggestions before. Please share your thoughts, guys.

I manually found interesting discussion here. Few words on flat icons - I think it requires markup change but if people really want to see flat icons I suggest to use one of the popular icon font library (like I suggested in October). Any thoughts?

Thanks,
Alex

Collin Anderson

unread,
Apr 7, 2015, 11:23:28 AM4/7/15
to django-d...@googlegroups.com
There's a ticket about icons here: https://code.djangoproject.com/ticket/20597

Marc Tamlyn

unread,
Apr 7, 2015, 11:25:57 AM4/7/15
to django-d...@googlegroups.com
Django's master is the correct branch for 1.9 development now.

Flat icons would be good, and I agree personally with your earlier suggestion to use font awesome icons. I do think this is a separate issue we could add later.

The primary questions to establish answers to before a possible merge in my opinion are:
- Do we ship both, or just the new one and release the old one as a third party package?
- How could we identify the difference for third party app developers who integrate with both versions, at least across the 1.8/1.9 release cycle? The easy answer here would be to add a new body class, potentially to both versions.

My suggestion would be that we should publicise via this mailing list (and django-users etc) that we are planning to integrate this, and you can use it now via your app. This should hopefully get you more bug reports early and we can merge it in a more finished state for the 1.9 alpha.

--
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.
Visit this group at http://groups.google.com/group/django-developers.

elky

unread,
Apr 7, 2015, 11:52:14 AM4/7/15
to django-d...@googlegroups.com
On Tuesday, 7 April 2015 20:23:28 UTC+5, Collin Anderson wrote:
There's a ticket about icons here: https://code.djangoproject.com/ticket/20597
 
Thanks Collin.


On Tuesday, 7 April 2015 20:25:57 UTC+5, Marc Tamlyn wrote:
The primary questions to establish answers to before a possible merge in my opinion are:
- Do we ship both, or just the new one and release the old one as a third party package?

If we release old one as a third-party app we need to support it as well. And it is additional headache for the third-party apps developers.  
 
- How could we identify the difference for third party app developers who integrate with both versions, at least across the 1.8/1.9 release cycle? The easy answer here would be to add a new body class, potentially to both versions.

How we can add this class? Someone suggested a setting to enable new theme. Ideally Django needs something like CSS framework because as far as I can see most of apps just uses their own styles and markup.
 
My suggestion would be that we should publicise via this mailing list (and django-users etc) that we are planning to integrate this, and you can use it now via your app. This should hopefully get you more bug reports early and we can merge it in a more finished state for the 1.9 alpha.
 
That would be great.

Marc Tamlyn

unread,
Apr 7, 2015, 12:12:47 PM4/7/15
to django-d...@googlegroups.com
We would modify our base admin template when we merge it. There are a number of third party applications which provide modified versions of their admin pages (FeinCMS is a good example of a moderately complex one). They would normally support two versions of Django (maybe also an LTS now), and so would need to provide one code base which works with both. So the shipping of and old one doesn't make third party app developers headache any worse.

We will need to release the old one as a third party app, or ship both for a deprecation period because of users own admin style changes and overrides they may have made.

I'm not sure the best approach for swapping between the two, even if they are shipped separately. Perhaps the easiest option is to ship both versions, add an AdminSite.theme parameter set to the new one. The main issue I can see with this would be two lots of static files collected every time (annoying for S3 users), but this is liveable with.

--
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.
Visit this group at http://groups.google.com/group/django-developers.

Aymeric Augustin

unread,
Apr 7, 2015, 12:15:39 PM4/7/15
to django-d...@googlegroups.com
2015-04-07 17:25 GMT+02:00 Marc Tamlyn <marc....@gmail.com>:
The primary questions to establish answers to before a possible merge in my opinion are:
- Do we ship both, or just the new one and release the old one as a third party package?

I'd like to make the new theme the default unless the developer opts out.

Since the admin CSS and JS receives very little maintenance, keeping the current theme under django/contrib/admin/classic_theme/static or in a third-party package doesn't make a significant difference for us.

The former is more convenient for users who choose to opt-out: all they need is to add 'django.contrib.admin.classic_theme' before 'django.contrib.admin' in INSTALLED_APPS. That will save us some angry emails ;-)

This leaves the question of how long we keep supporting the classic theme. I suggest to go for the usual two-releases deprecation cycle and leave it up to the community to maintain it separately from Django 2.1 on.

My suggestion would be that we should publicise via this mailing list (and django-users etc) that we are planning to integrate this, and you can use it now via your app. This should hopefully get you more bug reports early and we can merge it in a more finished state for the 1.9 alpha.

Yes, that's a good idea in any case.
 
--
Aymeric.

Jannis Leidel

unread,
Apr 14, 2015, 7:52:46 AM4/14/15
to django-d...@googlegroups.com

> On 07 Apr 2015, at 18:15, Aymeric Augustin <aymeric....@polytechnique.org> wrote:
>
> 2015-04-07 17:25 GMT+02:00 Marc Tamlyn <marc....@gmail.com>:
> The primary questions to establish answers to before a possible merge in my opinion are:
> - Do we ship both, or just the new one and release the old one as a third party package?
>
> I'd like to make the new theme the default unless the developer opts out.
>
> Since the admin CSS and JS receives very little maintenance, keeping the current theme under django/contrib/admin/classic_theme/static or in a third-party package doesn't make a significant difference for us.
>
> The former is more convenient for users who choose to opt-out: all they need is to add 'django.contrib.admin.classic_theme' before 'django.contrib.admin' in INSTALLED_APPS. That will save us some angry emails ;-)

I don’t think we should keep it in django.contrib.admin.class_theme and just make a hard break (we don’t guarantee backward compatibility for styles or frontend API IIRC), but also offer a separate Python package at the time of the Django release with the new skin.

> This leaves the question of how long we keep supporting the classic theme. I suggest to go for the usual two-releases deprecation cycle and leave it up to the community to maintain it separately from Django 2.1 on.

When you say community, who are you referring to?

I’d rather see the original skin moved into a repo under the django namespace on GitHub. Moving it into an own app inside of django.contrib.admin and then remove it just two releases (~1 year) later is a pretty good way to receive angry mails.

> My suggestion would be that we should publicise via this mailing list (and django-users etc) that we are planning to integrate this, and you can use it now via your app. This should hopefully get you more bug reports early and we can merge it in a more finished state for the 1.9 alpha.

Agreed, especially the apps that we know are doing heavy customization like django-cms should provide some good leads to what we can do better.

Jannis

Andy Baker

unread,
May 23, 2015, 6:35:51 AM5/23/15
to django-d...@googlegroups.com
Hi,

Is this thread still the most up to date place for discussing this? I'm trying to work out what the current status is and whether it is likely to land in 1.9.

For the benefit of anyone else coming to this late here's what I can track down:

Last comment here prior to mine was jezdez on April 14th

The standalone repo is here: https://github.com/elky/django-flat-theme (last commit May 8th)

The Trac ticket is here: https://code.djangoproject.com/ticket/24444#ticket (Status: 'accepted' but 'patch needs improvement' - last change May 11th)

The original pull request is here: https://github.com/django/django/pull/4232 (Status closed. last update: March 11th)

So it looks like it's still on track - I just can't find any recent discussion on it. If that's normal then apologies for the noise.

On Wednesday, 4 March 2015 19:15:33 UTC, elky wrote:
Hi guys,

I think django admin needs new look. I played with styles recently and that's the result: https://github.com/django/django/pull/4232

Inspired by a new djangoproject.com site. 

New theme looks modern, fresh and clean. There are CSS changes only. No any HTML changes.

Let's discuss it. I will appreciate any feedback.

Thanks

P.S. I can create demo app if it needs.

elky

unread,
May 23, 2015, 8:00:18 AM5/23/15
to django-d...@googlegroups.com
HI Andy,

Yes, this thread is actual for discussing this theme.


I hope I'll have enough time to work on it this weekend.

Emil Stenström

unread,
May 30, 2015, 1:19:15 PM5/30/15
to django-d...@googlegroups.com
I just wanted to add that this looks GREAT. Maintaining the old colors was a smart move, as this makes things familiar but still new. This work was long overdue!

/E

elky

unread,
Jul 29, 2015, 7:13:15 AM7/29/15
to Django developers (Contributions to Django itself), manse...@gmail.com
Hi guys,

I'm glad to say I finished work on replacing image icons with font. I used Font Awesome (GPL licence) kit to do it.

I'll appreciate if you test new icons in your project and report any issues here. You can do it by running:

There are couple of questions I wanna discuss in this thread:

1. Font Awesome kit contains about 600 icons - obviously we don't need all of them in Django. I can create small kit which will contain only icons that used in the project - it will allow us to save about 70KB. But the question is - how to support this kit in future if someone decide to add new icons?

2. Do we support IE8 and less? If yes - I'll need to add additional font files.

Thank you,
Alex D.

Marc Tamlyn

unread,
Jul 29, 2015, 8:27:56 AM7/29/15
to django-d...@googlegroups.com, manse...@gmail.com
Font Awesome is not GPL - the code is MIT and the font itself is SIL OFL both of which are fine to include with Django.

--
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.
Visit this group at http://groups.google.com/group/django-developers.

Tim Graham

unread,
Jul 29, 2015, 8:37:09 AM7/29/15
to Django developers (Contributions to Django itself), manse...@gmail.com, marc....@gmail.com
In https://code.djangoproject.com/ticket/20597 we discussed switching to SVG (instead of an icon font) in Django 1.10 when we can drop support for IE8. Now that Django 1.9 is slated for December and IE8 support ends the next month, I think it might be acceptable to drop IE8 support in 1.9 and go with the SVG solution now. What do you think?

Is this a blocker for merging the existing PR (which currently needs a rebase and release notes)? I'd think the two issues could be separate commits.

Andy Baker

unread,
Jul 29, 2015, 8:39:51 AM7/29/15
to Django developers (Contributions to Django itself), manse...@gmail.com
I do a lot of projects with highly customized admins and having the full font awesome would be splendid.

One option is to use optional requirements: pip install django[all-icons]
but I don't think Django does this anywhere else so it's probably a big leap for a small part of contrib.admin

Maybe all that's is needed is a simple wrapper app that packages the full font-awesome on the correct static path and it's as simple as documenting it thus:

"If you want all the font awesome icons to be available put this app in INSTALLED_APPS after contrib.admin and it will overwrite the minimal icon pack with the full one"

Aymeric Augustin

unread,
Jul 30, 2015, 4:56:39 AM7/30/15
to django-d...@googlegroups.com, manse...@gmail.com
Le 29 juil. 2015 à 13:13, elky <manse...@gmail.com> a écrit :
>
> I can create small kit which will contain only icons that used in the project - it will allow us to save about 70KB. But the question is - how to support this kit in future if someone decide to add new icons ?

Indeed, it could be difficult to maintain in the medium term.

If I remember correctly, the new theme already adds ~300kB of fonts. Saving 70kB of icons doesn't change that much.

Shipping the entire set sounds easier at this point.

--
Aymeric.

Marc Tamlyn

unread,
Jul 30, 2015, 5:05:52 AM7/30/15
to django-d...@googlegroups.com
One thing that might be nice to do with the admin, especially in the context of the fonts but also with jQuery, is to give an easy override to use CDN versions of the files. Django still needs to bundle them for offline work, and the default should be to include Django's own ones, but it would be good on production sites to use CDNs (probably google, or make it configurable). It may be that this is more work than it's worth, but as some of these files, especially jQuery, font awesome and Roboto are widely used around the internet now many users would already have them cached - even if it's just from another Django admin.

--
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.
Visit this group at http://groups.google.com/group/django-developers.

Aymeric Augustin

unread,
Jul 30, 2015, 5:21:33 AM7/30/15
to django-d...@googlegroups.com
I am wary of privacy implications (leaking referers) of making it too easy to use a CDN, all the more since the admin is lightweight and not performance-critical.

-- 
Aymeric.

elky

unread,
Aug 7, 2015, 4:51:54 AM8/7/15
to Django developers (Contributions to Django itself)
Just posted a comment regarding inline SVG here: https://code.djangoproject.com/ticket/20597#comment:12

If everyone is fine with Font Awesome - I'm going to create pull request in master.

elky

unread,
Aug 16, 2015, 3:00:45 PM8/16/15
to Django developers (Contributions to Django itself)
Hi guys,

I made double work for vector icons - now we have Font and SVG icons. Let's choose what to use.    

Quoting my comment from SVG discussion here:

Well, only week ago I was 100% happy with font icons. But after Collin's comment I vote for SVG (<img> with svg as a source).
Below I listed advantages/disadvantages for both options. 
 
Font

SVG
And the final and main argument to choose SVG is that some apps use a bit overridden Django CSS classes so font approach may cause visual issues (I checked it with few CMS apps). So font approach is an extra headache for app developers.

Marc Tamlyn

unread,
Aug 17, 2015, 4:09:18 AM8/17/15
to django-d...@googlegroups.com
+1 to the svg option.

--
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.
Visit this group at http://groups.google.com/group/django-developers.

Tim Graham

unread,
Aug 17, 2015, 7:28:18 PM8/17/15
to Django developers (Contributions to Django itself)
The SVG option looks good to me as well. While you are there, could you update the "no" icon as done in https://github.com/elky/django-flat-theme/pull/14?

Unless someone can present an argument for keeping IE8 support, I wouldn't worry about it considering it will be end of life about 1 month after the release of Django 1.9.

Please send a pull request when you have a chance and don't forget a mention in the 1.9 release notes too.

Aymeric Augustin

unread,
Aug 18, 2015, 3:32:18 AM8/18/15
to django-d...@googlegroups.com
On 18 août 2015, at 01:28, Tim Graham <timog...@gmail.com> wrote:

> Unless someone can present an argument for keeping IE8 support, I wouldn't worry about it considering it will be end of life about 1 month after the release of Django 1.9.

Let’s just make sure the admin stays usable, even if it looks bad. Since we’re taking the SVG route, providing an alt text on icons should do.

We could be explicit about the lack of support for IE8 and lower by adding a conditional message in the template:

<!--[if lt IE 9]><p class="error”>You are using an old web browser which cannot display this page correctly. Please update to a more modern browser or contact your system administrator for help.</p><![endif]-->

--
Aymeric.




Tim Graham

unread,
Aug 18, 2015, 7:13:11 AM8/18/15
to Django developers (Contributions to Django itself)
I also had the idea of upgrading jQuery to jQuery 2 which drops support for IE6/7/8, but I guess this will break all the JavaScript in the admin under those browsers. Do you think that's unacceptable at this time? If so, could you propose an alternate timetable for the upgrade?

Marc Tamlyn

unread,
Aug 18, 2015, 7:29:56 AM8/18/15
to django-d...@googlegroups.com
I don't know about schedule, but caniuse reports IE8 browser usage at 1.5%, more than IE9 or IE10.

There's an argument we shouldn't be "enabling" people still using XP who are stuck on IE8, and this is a decreasing problem, but I don't think we can tie ourselves to Microsoft's support dates.

--
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.
Visit this group at http://groups.google.com/group/django-developers.

Markus Holtermann

unread,
Aug 18, 2015, 7:34:11 AM8/18/15
to django-d...@googlegroups.com
Hey,

Looking at some browser market share stats
(http://www.sitepoint.com/browser-trends-august-2015-chrome-exceeds-50/
, disclaimer:
http://www.sitepoint.com/how-browser-market-share-is-calculated/) IE8
seems hardly be used anyway. Furthermore, with the dropped support for
IE8 (and 9+) on Jan 12th, 2016
(https://support.microsoft.com/en-us/lifecycle/search?sort=PN&alpha=internet%20explorer),
I don't really see any problem in removing IE8 support and notifying the
users that they have to update to a modern browser.

Therefore I find Aymeric's proposed solution "You are using an old web
browser ..." a reasonable choice over being stuck with ages old
technology that is long outdated.

/Markus

PS: I'd go with SVG solution

On Tue, Aug 18, 2015 at 04:13:11AM -0700, Tim Graham wrote:
>I also had the idea of upgrading jQuery to jQuery 2 which drops support for
>IE6/7/8, but I guess this will break all the JavaScript in the admin under
>those browsers. Do you think that's unacceptable at this time? If so, could
>you propose an alternate timetable for the upgrade?
>
>On Tuesday, August 18, 2015 at 3:32:18 AM UTC-4, Aymeric Augustin wrote:
>>
>> On 18 août 2015, at 01:28, Tim Graham <timog...@gmail.com <javascript:>>
>> wrote:
>>
>> > Unless someone can present an argument for keeping IE8 support, I
>> wouldn't worry about it considering it will be end of life about 1 month
>> after the release of Django 1.9.
>>
>> Let’s just make sure the admin stays usable, even if it looks bad. Since
>> we’re taking the SVG route, providing an alt text on icons should do.
>>
>> We could be explicit about the lack of support for IE8 and lower by adding
>> a conditional message in the template:
>>
>> <!--[if lt IE 9]><p class="error”>You are using an old web browser which
>> cannot display this page correctly. Please update to a more modern browser
>> or contact your system administrator for help.</p><![endif]-->
>>
>> --
>> Aymeric.
>>
>>
>>
>>
>>
>
>--
>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.
>Visit this group at http://groups.google.com/group/django-developers.
>To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/e541a69a-2ded-4af1-b049-f144878c0f83%40googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.


--

Shai Berger

unread,
Aug 18, 2015, 7:25:38 PM8/18/15
to django-d...@googlegroups.com
On Tuesday 18 August 2015 14:29:15 Marc Tamlyn wrote:
> I don't know about schedule, but caniuse reports IE8 browser usage at 1.5%,
> more than IE9 or IE10.
>
> There's an argument we shouldn't be "enabling" people still using XP who
> are stuck on IE8, and this is a decreasing problem, but I don't think we
> can tie ourselves to Microsoft's support dates.
>

Sure we can, in the same sense that we "tie ourselves" to the support dates of
PostgreSQL, MySQL and Oracle.

1.9 is the release following an LTS -- the perfect time for changes such as
JQuery 2 and dropping support for old browsers. If developers need to support
the legacy IE8, they can use Django 1.8.

The suggestion to add a notice for IE8 users seems reasonable to me, but I
don't think we should hold back progress just to keep the admin usable on it.

Shai.

Josh Smeaton

unread,
Aug 19, 2015, 3:23:21 AM8/19/15
to Django developers (Contributions to Django itself)
I agree with Shai. There are certain companies that have bought extended support for WinXP/IE8 for extravagant amounts of money. That means Microsoft is taking on the burden of support (security) for those systems. They are EOL as far as we're concerned. We shouldn't intentionally cripple support unless there is a reason to do so though. For example, unless we need jQuery2 for some purpose, maybe it's best we just leave it at it's current version for the moment. As for font/svg icons - alt text is fine for an old browser out of support.

Sam Cooke

unread,
Aug 19, 2015, 5:27:53 AM8/19/15
to django-d...@googlegroups.com
For jQuery support in older browsers it's pretty simple to include jQuery
1.11 in old IE using conditional comments - that way we retain support with
just an extra line of code, don't leave IE8 behind, and get the performance
boost of jQuery 2 in modern browsers. As far as I'm aware they are still
API compatible.

--
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.
Visit this group at http://groups.google.com/group/django-developers.

elky

unread,
Aug 19, 2015, 5:39:08 AM8/19/15
to Django developers (Contributions to Django itself)

On Wednesday, 19 August 2015 14:27:53 UTC+5, sdcooke wrote:
and get the performance boost of jQuery 2 in modern browsers. As far as I'm aware they are still API compatible.

We should carefully check jQuery change log. I remember they removed toggle method in one of the latest versions, so some apps may broke because of that.   

Sam Cooke

unread,
Aug 19, 2015, 5:59:21 AM8/19/15
to django-d...@googlegroups.com
I meant jQuery 2 and 1.11 are API compatible - you're right though, the latest versions of jQuery might have deprecated things that are currently used in Django.

--
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.
Visit this group at http://groups.google.com/group/django-developers.

Tim Graham

unread,
Aug 19, 2015, 10:34:01 AM8/19/15
to Django developers (Contributions to Django itself)
To see what's required, I made a pull request for jQuery 2 here: https://github.com/django/django/pull/5155
The selenium and JavaScript tests pass without any modifications to the admin's JavaScript.

My own opinion is that if you really need IE8 support, it's not difficult to write a custom template and conditionally include the old jQuery version. If we view the admin as an internal management tool for "staff users", I think it's reasonable for organizations to know what browsers their staff uses and be able to make these determinations.

For me, moving to jQuery 2 is a bit like the Python 2/3 debate. As long as we have to support Python 2/jQuery 1.x we are somewhat restricted in reaping the benefits of Python 3/jQuery 2. I'm not sure there are any new features in jQuery 2 at this time - the main benefit seems to be smaller size. Of course, if we start using new features of jQuery 2 at some point, we might break the solution proposed in the previous paragraph, but that seems okay to me since the point is that we shouldn't spend much time caring for unsupported browsers.

If we don't want to use end-of-life dates for deciding a browser support policy, then what alternative metric should we use?

Marc Tamlyn

unread,
Aug 19, 2015, 11:35:20 AM8/19/15
to django-d...@googlegroups.com
FWIW, I can see the arguments here and I would definitely like to move to jquery 2 and drop old browsers (aggressively). Actually having a solid browser support policy, a redesign etc would be a great time to do this as well.

I can see we are likely to get some backlash, but maybe less than I think.

So consider me a +0 with reservations, and I would like to suggest that the final decision here is made by the technical board.

Josh Smeaton

unread,
Aug 19, 2015, 7:49:14 PM8/19/15
to Django developers (Contributions to Django itself)
>My own opinion is that if you really need IE8 support, it's not difficult to write a custom template and conditionally include the old jQuery version.

Good point. It's easy enough for users to support IE8 themselves if they need to. Consider me a +1 then.

Marc Tamlyn

unread,
Aug 20, 2015, 6:12:45 AM8/20/15
to django-d...@googlegroups.com
I think this is a bit of a misnomer - if we include a jQuery without IE8 support we will start dropping IE8 from the CSS, our own custom javascript, new jquery features, community plugins will drop it etc etc. For 1.9 itself it may simply be a case of swapping in a different jQuery version, but it won't stay that way for long.

Josh Smeaton

unread,
Aug 20, 2015, 9:59:12 AM8/20/15
to Django developers (Contributions to Django itself)
The only reason that I'm on the fence about not actively ending IE8 support right now is that it will still be in support for the release of Django 1.9. It'll only be a month, but it's something. I'd feel more comfortable about a soft deprecation now and a harder end for Django 1.10. It'll at least give some warning to the community if someone were to look for it.

Tom Christie

unread,
Aug 20, 2015, 10:14:24 AM8/20/15
to Django developers (Contributions to Django itself)
Could we give users guidance on overriding the admin's application specific static files with global static files if we do this?

Not immediately clear to me what order static files are copied in, but presumably it's possible to ensure that the jquery static files included in the admin app directory are overridden with user specified ones in a project-level static files directory, right?

Also, tho I'm broadly in favor with us staying with up to date with the currently active version of jQuery, to clarify: is there anything *specific* that we'd be gaining from the switch at this point?

Aymeric Augustin

unread,
Aug 20, 2015, 10:23:48 AM8/20/15
to django-d...@googlegroups.com
2015-08-20 16:14 GMT+02:00 Tom Christie <christ...@gmail.com>:
Could we give users guidance on overriding the admin's application specific static files with global static files if we do this?

The general rule is: if several applications provide the same resource, the earliest application in INSTALLED_APPS wins.

(NB: before 1.7, management commands had the opposite behavior.)

-- 
Aymeric Augustin.
 

Collin Anderson

unread,
Aug 20, 2015, 12:00:36 PM8/20/15
to Django developers (Contributions to Django itself)
To be clear: jQuery 1.x and 2.x are the exact same except for IE < 9 compatibility. jQuery v1.11.3 and v2.1.4, released simultaneously, _are_ the latest version of jQuery. It's not like "1.11.x" is an "old" release series. 1.x and 2.x have the exact same features and API and are 100% compatible with each other. The _only_ difference is that v2.1.4 is slightly smaller because it doesn't have shims to support IE6-8 (and a few other old browsers).

The only advantage to switching to 2.x is a slightly smaller file size, meaning a slightly quicker load time.

In a few months, they'll switch to 3.x, breaking some backwards compatibility, and instead of 2.x and 1.x, they'll have "jQuery" and "jQuery Compat" with the same version numbers. That should make this more clear.

I personally suggest staying with jQuery Compat (1.x) through this next LTS cycle. The file size is really not that much, and it shouldn't be any extra work to maintain.

Tim Graham

unread,
Aug 20, 2015, 12:19:07 PM8/20/15
to Django developers (Contributions to Django itself)
Thanks everyone for feedback. I think it's a good idea to send this to the technical board to reach a consensus. Here is the summary as I see it:

Benefits of jQuery 2:
* Smaller file size (36KB or 11KB for minified version)
* "Faster" -- not sure this has any practical benefit currently, but might be helpful if rewriting the filter widgets which are notoriously slow [1])

Cons:
* No built-in IE6-8 support for admin JavaScript features

Pros of doing it now:
* Discourages use of old, unsupported browsers.
* It's bunched with other admin changes like the redesign and dropping fallback images for IE6/7 support (for no transparent png support by these browsers).
* "1.9 is the release following an LTS -- the perfect time for changes such as  JQuery 2 and dropping support for old browsers. If developers need to support  the legacy IE8, they can use Django 1.8." -Shai
* Possible to restore compatibility by overriding the admin's jQuery with an older version of jQuery with an app that looks like this:

admin-jquery-1/static/admin/js/vendor/
    jquery.js
    jquery.min.js

jQuery 1.X and 2.X have API compatibility so this technique should work for the foreseeable future.

Cons:
* IE8 won't be EOL until ~1 month after the release of 1.9.
* Workaround technique could be annoying for affected users.

[1] https://code.djangoproject.com/ticket/15220

Hugo Osvaldo Barrera

unread,
Aug 21, 2015, 5:44:02 AM8/21/15
to django-d...@googlegroups.com
I see not mention of this later on this thread so I have to ask:
Do we have an equivalent of an `alt` if using fonts? If not, how would this be usable by, for example, blind users?
 
Currently, django-flat-theme.git@flat-icons does not seem to deal with this.
 
--
Hugo Osvaldo Barrera
 

elky

unread,
Aug 21, 2015, 7:06:55 AM8/21/15
to Django developers (Contributions to Django itself), hu...@barrera.io
Does 'title' attribute help in terms of accessibility? 

Hugo Osvaldo Barrera

unread,
Aug 21, 2015, 7:26:16 AM8/21/15
to elky, Django developers
 
On Fri, Aug 21, 2015, at 08:06, elky wrote:
Does 'title' attribute help in terms of accessibility? 
 
`title` adds a tooltip, so no, not really.
 
--
Hugo Osvaldo Barrera
 

Tim Graham

unread,
Aug 27, 2015, 2:53:28 PM8/27/15
to Django developers (Contributions to Django itself)
Carl pinged me in #django-dev to say that the technical board says it's ok to go ahead with dropping IE8 support in admin for 1.9.

Three +1s and two +0s. The +0s were due to feeling that:
a) IE isn't as dead as in some places as it is in the Valley
b) the advantages gained by dropping support are weak.

But both the +0s nonetheless felt that this was consistent with our general support practices, and thus was fine to do now.

Nick Sarbicki

unread,
Aug 28, 2015, 9:11:27 AM8/28/15
to Django developers (Contributions to Django itself)
This takes the conversation back a ways...

But I like the idea of being able to customise the admin scheme. Enforce a default of course, but maybe have some options (in admin.py? or as a separate script?) which can change the core colors of the scheme, either a set of predefined colours, or something completely customisable by the user. 

I don't think it's a huge amount of work (it's finding and replacing hex values in the css files). But I reckon it could add a lot of value for people who want the admin page to match the scheme of their website.

Obviously not a good idea to shove it in before the 1.9 release, but if the idea is liked I might (or any one else who is interested) be able to look into it.

/Nick.

On Monday, March 16, 2015 at 1:44:23 PM UTC, Tim Graham wrote:
In some previous discussion, it was suggested to have a toggle between the new and old designs to ease the transition. I guess this could be something like a "theme" attribute on AdminSite. Do you think this is required? It seems this could be a non-trivial maintenance burden if we have to test and maintain two designs for some time.

On Friday, March 13, 2015 at 7:42:35 AM UTC-4, elky wrote:
Did you test RTL?
I did. I tested Arabic and Hebrew - no issues detected for me. BUT. As far as I understand Django admin has poor RTL support by itself.

Sorry guys, I was wrong about it. Django has very good RTL support! Just didn't notice right setting to test it. But anyway I did few tweaks in my theme. 

Tim Graham

unread,
Aug 29, 2015, 1:10:35 PM8/29/15
to Django developers (Contributions to Django itself)
It seems like a nice idea if the implementation is simple.

elky

unread,
Sep 4, 2015, 5:35:50 AM9/4/15
to Django developers (Contributions to Django itself)
Does anybody know where this CSS code (https://github.com/elky/django/commit/36c1decd2f18c3af947546ea3b8eaeaecd2762ba) uses? I didn't find any mention of these CSS classes in the project.

The first mention of these styles came from this 9 years old commit - https://github.com/django/django/commit/f69cf70ed813a8cd7e1f963a14ae39103e8d5265
I did checkout to this state and didn't find any mention of these classes in backend or JS. So I think this code is really unused. Correct me if I'm wrong. 

Collin Anderson

unread,
Sep 4, 2015, 8:38:05 AM9/4/15
to django-d...@googlegroups.com
That looks right to me. More specifically (from the attic/magic-removal branch):
Removed html classes, but not css:

--
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.
Visit this group at http://groups.google.com/group/django-developers.

elky

unread,
Sep 4, 2015, 8:44:24 AM9/4/15
to Django developers (Contributions to Django itself)
Thanks for clarification, Collin.

Fabio Caccamo

unread,
Nov 17, 2015, 10:04:48 AM11/17/15
to Django developers (Contributions to Django itself)
Hi guys, 
I just released https://github.com/fabiocaccamo/django-admin-interface

It is based on the great Elky's theme, but by default it uses the same colors of https://www.djangoproject.com/ 
and as a plus it allows some interface customizations (title, logo and colors) directly through the admin interface itself.

It's possible to manage multiple themes and switching between them with a click.
Here how the theme customization admin looks like:


Roberth Solis Martínez

unread,
Dec 10, 2017, 7:23:32 PM12/10/17
to Django developers (Contributions to Django itself)
Huuum it sounds cool
Reply all
Reply to author
Forward
0 new messages