-
Notifications
You must be signed in to change notification settings - Fork 83
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
DEP 84: Rejuvenate form media #84
Draft
thibaudcolas
wants to merge
2
commits into
django:main
Choose a base branch
from
thibaudcolas:rejuvenating-form-media
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,95 @@ | ||
| ====================== | ||
| DEP XXXX: Rejuvenate form media | ||
| ====================== | ||
|
|
||
| :DEP: XXXX | ||
| :Author: Thibaud Colas | ||
| :Implementation Team: You? People in the `forum thread: Rejuvenating vs deprecating Form.Media <https://forum.djangoproject.com/t/rejuvenating-vs-deprecating-form-media/21285>`_ | ||
| :Shepherd: You? | ||
| :Status: Draft | ||
| :Type: Feature | ||
| :Created: 2023-12-12 | ||
| :Last-Modified: 2023-12-19 | ||
|
|
||
| .. contents:: Table of Contents | ||
| :depth: 3 | ||
| :local: | ||
|
|
||
| Abstract | ||
| ======== | ||
|
|
||
| See `forum thread: Rejuvenating vs deprecating Form.Media <https://forum.djangoproject.com/t/rejuvenating-vs-deprecating-form-media/21285>`_. | ||
| We want `form.Media <https://docs.djangoproject.com/en/5.0/topics/forms/media/>`_ to catch up with modern web standards, so Django projects can more easily leverage those standards. | ||
|
|
||
| Specification | ||
| ============= | ||
|
|
||
| See the `MDN script element documentation <https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script>`_ and `link element documentation <https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link>`_. | ||
|
|
||
| Here are requirements which Django could/should better support: | ||
|
|
||
| - ES modules | ||
| - Import maps | ||
| - Dynamic module imports | ||
| - async, defer scripts | ||
| - CSPs via nonce attributes | ||
| - integrity attribute | ||
| - fetchpriority attribute | ||
| - nomodule attribute | ||
| - Arbitrary script attributes | ||
| - Preloading / speculative loading | ||
| - Resource ordering (see `capo.js <https://rviscomi.github.io/capo.js/>`_) | ||
| - Web Components | ||
|
|
||
|
|
||
| Motivation | ||
| ========== | ||
|
|
||
| `form.Media <https://docs.djangoproject.com/en/5.0/topics/forms/media/>`_ is a good API to manage a form widget’s dependencies. | ||
| Though not all projects need to keep a strict record of each widget’s dependencies | ||
|
|
||
| Rationale | ||
| ========= | ||
|
|
||
| This section should flesh out out the specification by describing what motivated | ||
| the specific design and why particular design decisions were made. It | ||
| should describe alternate designs that were considered and related work. | ||
|
|
||
| The rationale should provide evidence of consensus within the community and | ||
| discuss important objections or concerns raised during discussion. | ||
|
|
||
| Backwards Compatibility | ||
| ======================= | ||
|
|
||
| At this stage I wouldn’t expect this to introduce any backwards-incompatible changes. If we did so, it would be with a very gradual deprecation path, likely only in the interest of: | ||
|
|
||
| - Better performance (for example default to more modern script loading techniques) | ||
| - Better security (for example default to… more modern script loading techniques) | ||
|
|
||
| Reference Implementation | ||
| ======================== | ||
|
|
||
| Here are the most fully-fledged implementations so far: | ||
|
|
||
| - https://github.com/matthiask/django-js-asset/ | ||
| - https://github.com/rails/importmap-rails | ||
|
|
||
| Other references: | ||
|
|
||
| - https://github.com/dropseed/django-importmap | ||
| - https://github.com/tonysm/importmap-laravel | ||
|
|
||
| TODOs | ||
| ===== | ||
|
|
||
| - Add more possible requirements | ||
| - Review https://github.com/wsvincent/awesome-django for packages with form media-related functionality. | ||
| - Review https://djangopackages.org/ for packages with form media-related functionality. | ||
| - Update https://github.com/st3v3nmw/awesome-django-performance with existing performance-related Django packages relating to form assets. | ||
| - Also update https://github.com/wsvincent/awesome-django with good packages in this category | ||
|
|
||
| Copyright | ||
| ========= | ||
|
|
||
| This document has been placed in the public domain per the Creative Commons | ||
| CC0 1.0 Universal license (http://creativecommons.org/publicdomain/zero/1.0/deed). | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 think that's a very complete list. As I already said on the forum thread, I think that the frontend tooling space is still moving so quickly that it's hard to know which tools may or may not be useful in a few years time. When I think about Django and it's stability I have a horizon of several years always, with frontend tooling that's just not the case. If we had more fellows and/or more people which are paid to work on Django it could be a good idea. Even though I'm actually a (p)react and web/rspack fan I think it's a good idea for Django to stay in the backend world.
So, I think there's a lot of value in trying to support CSP (that was one of the motivations for django-js-asset, see https://406.ch/writing/django-admin-apps-and-content-security-policy-compliance/ ), supporting additional arbitrary attributes on
<script>tags etc. but that's it.I'm not sure I understand the resource ordering thing. Django already supports relatively complex dependencies (at least since https://code.djangoproject.com/ticket/30153). Of course that doesn't do anything about the initial page loading performance, but then you're already in the area of bundlers again.
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.
From my perspective everything on that list has already proven its usefulness quite clearly! Additional attributes on
<script>would be really useful but that feels to me like a rejuvenation of the Media API to bring it to 2014 standards rather than 2024.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.
Should we also be adding anything about Django providing polyfills?
As in
This is something the Rails approach did I believe, to allow for a 'simple' cross browser support approach where developers didn't have to think about what to include.