Problem/Motivation
Between Drupal minor/patch releases, markup and CSS is frozen to prevent regressions for themers.
In Drupal 8.1 and beyond, we want to be able to evolve the UX of Drupal to stay competitive and to fix any usability problems we find. We can't do this if the mark up and CSS for admin interfaces is frozen.
Proposed resolution
Do not support backwards compatibility for the administrative module HTML and CSS between Drupal 8 minor releases. If a themer decides to add custom overrides to Drupal's UX, then they would have to check for regressions with every improvement released.
Proposal list of UIs we don't support:
- Block layout UI
- Field UI
- Simpletest UI
- Views UI
- Quickedit
- Toolbar
- Contextual links
- Content listing
- People listing
- Node preview bar
- Menu UI
- Taxonomy UI
- Tour
- Shortcut
- WYSIWYG
- The installer
- The information architecture
- Admin overview pages (e.g. /admin /config /structure)
- User interface text
We would need to make this clear on release so people understand the implications of modifying Drupal's administrative UX.
Remaining tasks
Come up with a concrete list of module UI's that are no frozen.
Discuss
Communicate
User interface changes
None
API changes
None
Data model changes
None
Comments
Comment #2
LewisNymanHere's a rough idea of the markup and CSS that could be considered administrative:
Comment #3
Wim Leers+1000
Comment #4
nod_I don't think html structure is part of the "public api" in the semver sense, so maybe we're already clear?
Comment #5
Wim Leers#4: I think it's more about explicitly documenting that.
Comment #6
Bojhan CreditAttribution: Bojhan as a volunteer commentedWould like to add that this proposal has been discussed with Alex/webchick/cotser/joel/morten/lewis and emma. This should also serve as motivator for those that do try to enhance the UX to contribute directly towards a release.
The debatable pieces are less linked to the Seven theme per se, such as:
I would generalise the list a bit more, any entity UI and any config UI are unfrozen.
Comment #7
LewisNymanWe consider all default markup and CSS part of the public API of themers. Everything we decide to set as internal is an exception as far as I understand.
We've already agreed to mark Seven as internal, which effectively breaks UI freeze between minor versions, but if the module markup is frozen then it means we'd have to do a lot of messy overrides in Seven and then port them back into the modules for 9.x.
Comment #8
LewisNymanI've added the proposed list of UIs to the issue summary.
Comment #10
star-szrDiscussed with @xjm @alexpott @effulgentsia @catch.
This issue was created before the Stable base theme was a thing. The way I see it there are two main facets to this proposal:
1. Improving user interfaces and user experience.
2. Cleanup.
For point 2 the cleanup can still happen in the core module markup/CSS now that we have Stable. We should prioritize BC in favour of stability and themer experience in my opinion.
For point 1 I think #2574767: Views listing page displays too few items on a page gives part of the picture of how we can evolve UI/UX while still maintaining BC. In that case I pushed for maintaining the 'views_ui_view_info' theme hook as is with its markup for BC but we are also adding new theme hooks to evolve the interface. We could also do such things in an experimental module.
IMO we have the tools now to handle this and still evolve so we don't necessarily need a formal policy. Any UI/UX changes can be treated as new. If we're missing something please comment.
Comment #11
xjmThanks @Cottser!
(Closed (outdated) is supposed to be for versions of Drupal that are no longer supported, like 6.x. https://www.drupal.org/issue-queue/status#outdated)
Comment #12
xjmBetter status I guess, although this could also be considered a duplicate of the Stable/Classy issues and the core policy issue around the API.
Comment #13
star-szrRight, I just always want to use it because it's the new status :D