Field output supporting code should move out of field.module

Technically yes. — But given this:

function field_page_build(&$page) {
  $path = drupal_get_path('module', 'field');
  $page['#attached']['css'][$path . '/css/field.module.css'] = array('every_page' => TRUE);
}

I'd say that those styles should be moved into system.module.css + system.theme.css instead, because there is no point in loading an additional CSS file on every page. :-)

First approach.
About the CSS, I moved the lines related to field forms to system.module.css and lines related to field presentation and labels to system.theme.css. Not sure if this is the best approach.
Regards

Thanks @plopesc!

Now that I see the actual CSS, all of those styles are theme styles, so they belong into system.theme.css, and we can copy them 1:1.

Make sure to move the existing CSS literally 1:1 — your new CSS in this patch is using an indentation of 4 spaces instead of 2 and the CSSDoc comment headers are not correct. ;)

Fixing CSS issues in #3

1. +++ b/core/includes/theme.inc
   @@ -2540,6 +2540,263 @@ function template_preprocess_region(&$variables) {
   + * Default template: field.html.twig.
   ...
   +function template_preprocess_field(&$variables, $hook) {
   ...
   +function theme_field($variables) {
   
   @@ -2709,5 +2966,12 @@ function drupal_common_theme() {
   +    // From field system.
   +    'field' => array(
   +      'render element' => 'element',
   

   not sure how this file related to theme_field(), the template still lives in field module

2. +++ b/core/modules/system/system.module
   @@ -1073,6 +1073,22 @@ function system_theme_suggestions_region(array $variables) {
   +  $suggestions[] = 'field__' . $element['#entity_type'] . '__' . $element['#bundle'];
   +  $suggestions[] = 'field__' . $element['#entity_type'] . '__' . $element['#field_name'];
   +  $suggestions[] = 'field__' . $element['#entity_type'] . '__' . $element['#field_name'] . '__' . $element['#bundle'];
   

   maybe file follow-up to make this more consistent?

Thanks, @plopesc!

move_field_theming-2201693-6.patch no longer applies.

error: patch failed: core/modules/field/field.module:460
error: core/modules/field/field.module: patch does not apply

Rerolled

It's not great having system module implementing the theme suggestions hook. There's no other place to do that?

The only other way I could see would be to move those "default" suggestions directly into the corresponding function that collects the suggestions (i.e., in /core/includes/theme.inc or ThemeHandler)

That might indeed be better than system.module.

System module currently implements hook_theme_suggestions_HOOK() for html and page to provide their theme_hook_suggestions.

In that case, should this implementations be moved also to theme.inc or ThemeHandler?

Maybe we could left this issue as it is now and then decide which is the best place for these implementations and move all at once.

Anyway, attaching patch re-rolled, it currently does not apply.

Moreover, while we are here, could we consider add changes proposed in #2160065: Automatically add theme hook suggestions based on view mode for fields??

Regards

Re-rolling

Re-rolling again with @plopesc.

Committed 13242b5 and pushed to 8.x. Thanks!

Don't think this needs a change notice since the theme names have not changed - just the code has moved.

diff --git a/core/modules/field/field.form.inc b/core/modules/field/field.form.inc
index d131094..a4ab137 100644
--- a/core/modules/field/field.form.inc
+++ b/core/modules/field/field.form.inc
@@ -6,8 +6,6 @@
  */
 
 use Drupal\Component\Utility\NestedArray;
-use Drupal\Core\Field\FieldDefinitionInterface;
-use Drupal\Core\Render\Element;
 
 /**
  * Callback for usort() within theme_field_multiple_value_form().
diff --git a/core/modules/field/field.module b/core/modules/field/field.module
index 9de6738..0c173c2 100644
--- a/core/modules/field/field.module
+++ b/core/modules/field/field.module
@@ -5,13 +5,9 @@
  */
 
 use Drupal\Component\Utility\Html;
-use Drupal\Component\Utility\String;
 use Drupal\Component\Utility\Xss;
-use Drupal\Core\Entity\ContentEntityInterface;
 use Drupal\Core\Entity\EntityTypeInterface;
 use Drupal\Core\Extension\Extension;
-use Drupal\Core\Template\Attribute;
-use Drupal\entity\Entity\EntityViewDisplay;
 use Drupal\field\Field;
 
 /*

Removed unused uses during commit.

I was getting 404s because of references to the old files

Hello,
Thank you @rodrigoaguilera for your review!

The problem was that implementations of hook_page_build() and hook_theme_suggestions_field() should have been removed in the previous patch.

Those methods were re-added in one of the patch iteration, sorry :(

ugh, right.

21: move_field_theming-2201693-21.patch queued for re-testing.

Bot error - hopefully

Marked as duplicate #2226019: The not exist field.module.css is added to the page

The clearfix class is all the time added to the wrapper DIV (I do not known where) no matter what is the label position, above, inline or hidden.
The problem is that the clearfix class is duplicated when the label position is "inline".

27: move_field_theming-2201693-27.patch queued for re-testing.

The latest patch looks suspect to me because it removes the hook_theme_suggestions_HOOK() implementation.

The patch from #16 unfortunately undid a bunch of the work from #1987398: field.module - Convert theme_ functions to Twig, here is a follow-up to clean that up: #2226233: Redo changes from field.module to Twig conversion issue that were clobbered

@Cottser Sorry for the inconveniences :(

I removed the hook_theme_suggestions_HOOK() implementation in #21 because it is duplicated. It was moved form field module to system module.

Regards.

Thanks for clarifying @plopesc, that makes sense!

I'm not sure about the additional CSS markup change made in #27, from my perspective #21 looks closer to what we need to close out this issue and I'm unable to reproduce the issue described with inline fields. @Sweetchuck can you please open a separate issue if you're able to reproduce and describe this behaviour? Thanks!

Re-RTBC'ing #21.

Committed patch in #21 c40d117 and pushed to 8.x. Thanks!