-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTML and CSS rework #72
Conversation
Since we need to keep these templates in sync with Django's templates, it's important we can easily diff them and code-reformatting is detrimental for seeing actual meaningful changes.
For Django version pre 3.2, we define explicit fallback values equal to the default values of the vars in Django 3.2
Position it sticky so that scrolling keeps it in the page, but without absolute offsets.
* automatically gains the header bg color * inherits the z-index from the header container * removed the fixed/absolute positioning and hardcoded pixel offset * properly namespace the CSS class names (known to conflict with bootstrap before!)
* Use the CSS variables for color information * Lift styling rules to the item component and only override anchor styling where relevant * Fix the header to display the dropdown menus (overflow)
* Hover and active state use the default admin CSS vars but can be overridden easily * Moved CSS classes and styling to drop-item element rather than link itself
* The breadcrums are not position fixed/sticky anymore, however this should be easily overrideable in downstream projects.
Codecov Report
@@ Coverage Diff @@
## master #72 +/- ##
=======================================
Coverage 98.78% 98.78%
=======================================
Files 10 10
Lines 246 246
Branches 46 46
=======================================
Hits 243 243
Misses 2 2
Partials 1 1
Continue to review full report at Codecov.
|
Now they don't overflow beyond the viewport, but display a scrollbar. The bar itself is ugly, but at least usable.
These were originally copied from the admin/css/base.css file, but only a small subset are actually used by django-admin-index.
The default_auto_field should be specified. For the time being, we keep the Django 3.2 default value (AutoField rather than BigAutoField) and once only 3.2+ is supported, migrate to the new Django BigAutoFiel default.
3ac858c
to
8fe0f43
Compare
8fe0f43
to
b2bbeda
Compare
* password change form * password change done
Django apps can inherit templates from other apps, so by putting admin-index before djang.contrib.admin, you can inherit the django admin default templates. This allows us to only override the bits that need to be overridden, making it easier to support multiple django versions and fixing/ applying the correct styling.
b2bbeda
to
019d8eb
Compare
I'm marked as reviewer but still draft? Regarding your TODO's. For mobile styling we can disable the menu. |
yeah sorry, was a bit to eager with assigning a reviewer - there's a bit more tweaking to be done for easier overriding in default-project |
Had so switch from older npm/node version
Ready for review now, and the accompanying PR for default-project is also prepared: https://bitbucket.org/maykinmedia/default-project/pull-requests/100 |
@sergei-maertens If you want to support mobile only with CSS, it is possible to do that with |
On second thought, it doesn't look that bad at the moment. With minimal effort, I think this actually works. Menus work since they are not links themselves. So let's fix spacing and z index and go |
Alright, I'll give it a stab with those suggestions. Would indeed be nice if we have basic functionality working and then leave room for improvement with another approach for a different PR |
Used tabindex=0 to make the elements focusable, thanks @JostCrow for the suggestion. The rest of the styling relies on the :focus pseudo-selector and some alignment tweaks on mobile.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The combinatin of sass and css variables confuses me a lot. Can you elaborate on the choices made?
@@ -10,5 +10,8 @@ insert_final_newline = true | |||
charset = utf-8 | |||
end_of_line = lf | |||
|
|||
[*.scss] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason to change this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, it's more in line with "big" mature projects like CRA. 2 spaces feels more natural than 4 tbh after working with both
@@ -7,6 +7,10 @@ $color-secondary: var(--secondary, #417690); | |||
$color-accent: var(--accent, #f5dd5d); | |||
$color-primary-fg: var(--primary-fg, #fff); | |||
|
|||
/* admin-index specific variables */ | |||
// default of 10px is the padding-bottom default of the header | |||
$djai-dropdown-menu-spacing-top: var(--djai-dropdown-menu-spacing-top, 10px); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason why we keep introducing variables while migrating to css variables? I think the combination is a bit confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose in this case we could set the default CSS variable values, but the order of stylesheet inclusion (admin-index is loaded in the body!) makes overriding in your own custom stylesheet harder than it should be. E.g.:
<head>
<link href="/static/admin/css/base.css"> <!-- contains :root with css vars -->
<link href="/static/admin_overrides.css"> <!-- contains :root with css var overrides -->
</head>
<body>
...
<div class"djai-dropdown-menu">
<link href="/static/admin-index.css"> <!-- contains :root with css var defaults, which overrides the overrides again because of DOM order -->
</div>
</body>
This way, the CSS var is used if it is defined, otherwise the default value fallback is used. And to not have to repeat the fallback value everywhere, I've opted to wrap that in a sass variable.
functional good enough for now. |
The goal is to be less invasive and easier to theme, while cleaning up the actual CSS rules needed to make this work.
Tested against:
TODO:
Changes
position: fixed
andtop: $magicNumber
rules, replaced withposition: sticky
or evenrelative
in a number of placesdjango.contrib.admin
templates, so they are now more compatible with different Django versions and less code for us to keep in sync with upstream