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

LewisNyman created an issue. See original summary.

LewisNyman’s picture

Title: [policy] Do not support 'administrative' CSS and markup » [policy] Do not support 'administrative' CSS, markup, and javascript
Component: CSS » markup
Issue tags: +JavaScript

Here's a rough idea of the markup and CSS that could be considered administrative:

  • 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
Wim Leers’s picture

+1000

nod_’s picture

I don't think html structure is part of the "public api" in the semver sense, so maybe we're already clear?

Wim Leers’s picture

#4: I think it's more about explicitly documenting that.

Bojhan’s picture

Would 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:

  • The information architecture (organisation of content)
  • The look and feel of overview pages (e.g. /admin /config /structure)
  • User interface text

I would generalise the list a bit more, any entity UI and any config UI are unfrozen.

LewisNyman’s picture

I don't think html structure is part of the "public api" in the semver sense, so maybe we're already clear?

We 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.

LewisNyman’s picture

Issue summary: View changes
Status: Active » Needs review

I've added the proposed list of UIs to the issue summary.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

star-szr’s picture

Status: Needs review » Closed (outdated)
Issue tags: -Needs framework manager review, -Needs product manager review, -Needs release manager review

Discussed 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.

xjm’s picture

Status: Closed (outdated) » Closed (duplicate)

Thanks @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)

xjm’s picture

Status: Closed (duplicate) » Closed (won't fix)

Better status I guess, although this could also be considered a duplicate of the Stable/Classy issues and the core policy issue around the API.

star-szr’s picture

Right, I just always want to use it because it's the new status :D