Ensure that Quick Edit relies less on the structure of the HTML

dunno if we should attach the issue that Quickedit now uses .region-content as a selector ? or seperate that into its own issue ?
we bashed around that back in #2407739: Remove classes from system templates r*.html.twig where the issue came up the first time.
i would suggest we used a data-attribute instead for this functionality & attached it to the body or main, else were opening up for so many doors where we can break this :/

I think .quickedit-field should be fine. It's added by initializeField() in quickedit.js so even if there are no classes at all on a field, it should still work because the data-attribute is there (unless attributes aren't printed either, but that's shooting yourself in the foot then).

I did some thorough manual testing. The solution in #4 makes a ton of sense. Many thanks!

This is super important for making it possible to have custom themes in Drupal 8 still support Quick Edit without subtle, non-explicit restrictions. It will ensure #2178121: Document the requirements for themes for Quick Edit to work in/with them will result in very simple instructions/guidelines for theme developers in D8.

Wouldn't we want at least a js- prefixed class name? or a data attribute?

[…] js- prefixed class name […]

Right, I forgot that that is the new rule.

Testbot--

1. +++ b/core/modules/editor/js/editor.formattedTextEditor.js
   @@ -63,7 +63,7 @@
          // Store the actual value of this field. We'll need this to restore the
          // original value when the user discards his modifications.
   

   Can we remove the gendering in this comment while we're at it. There has to be a better way to write this.

2. +++ b/core/modules/editor/js/editor.formattedTextEditor.js
   @@ -63,7 +63,7 @@
   +      var $fieldItems = this.$el.find('.quickedit-field');
   
   +++ b/core/modules/quickedit/js/editors/plainTextEditor.js
   @@ -31,7 +31,7 @@
   +      var $fieldItems = this.$el.find('.quickedit-field');
   

   Wouldn't we want to change this to js-quickedit-field or a data attribute as nod_ suggested before we RTBC this?

Oops, yes, I forgot about #7 in #10.

Wim--

Nice ! RTBC then ?

I manually tested this, and it seems to work. But don't we need to change the template output to use js-quickedit-field as well? I'm only seeing quickedit-field in the template markup.

#14: this is 100% JS-only. That's the whole point: to make Quick Edit not rely on the template markup. This patch makes Quick Edit's JS rely solely on the already-existing data-quickedit-* attributes, which cause this class to be added.

Except that this patch actually is relying on the non-existent .js-quickedit-field class; QuickEdit's JS still creates the quickedit-field class — see initializeField() in quickedit.js.

Renaming that class is actually out of scope here, because it would require changes to Quick Edit's JS, which would then have inconsistent class names.

So, re-uploading the patch in #4.

fair enough.

Renaming that class is actually out of scope here, because it would require changes to Quick Edit's JS, which would then have inconsistent class names.

Notwithstanding the CSS selectors in quickedit.theme.css, which would break if quickedit-field is renamed js-quickedit-field in initializeField().

Adding credit to @mdrummond for manually testing this.

Pushed to 8.0.x.

Actually, this caused a regression: #2671202: [regression] Text field's label is duplicated in the value when edited & saved using Quick Edit.