Make #type 'item' work outside of a form context to render a compound label + content

Like this.

Umph. Apparently, a couple of core modules are using #type 'item' in very unusual ways.

Since I don't want to rewrite half of core for this patch, I added the necessary properties and behavior to support those unusual usages. Specifically:

- Some modules do not specify a #title.
- Some specify only #markup and #description.

Re-rolled against HEAD.

Closely related: #1848874: Clean up and simplify user cancel methods and processing

1. Fixed RenderTest.
2. Fixed NodeTypeInitialLanguageTest.
3. Fixed LinkFieldUITest.
4. Fixed LinkFieldTest.

Manual/visual testing:

The classless H4 heading causes problems, since headings usually get a top+bottom margin of 1em. Options:

1) Do not use a heading, but div.label (as in #882666: Core form descriptions shouldn't use a label when not associated with a form) — in hindsight, I don't really like that idea, since it abuses an HTML element to look like another. If something should look like a heading/label, then it should be formatted as one.

2) Apply a class to the heading, so the margin can be force-removed.

3) Use a higher/smaller heading element (e.g., H6). This probably still requires 2), not only for the margin, but also for the font-size.

I guess that would leave us with h4.label and accompanying CSS styles to remove the margins and inherit the font-size.

1. Incorporated CSS from #882666: Core form descriptions shouldn't use a label when not associated with a form
2. Added .label class to item heading.

#10: theme.item_.10.patch queued for re-testing.

I consider this patch ready. :)

Merged HEAD.

#14: theme.item_.14.patch queued for re-testing.

Merged HEAD.

Alrighty. So here's my stance on the current patch:

1. I'm 100% confident that making #type 'item' work as a render element outside of forms is a good idea.

   I had a dozen of use-cases for that in the past already. That change looks complete to me.

2. I'm only 60% sure of the Link field formatter change, which merges the 'separate' formatter into the 'link_default' formatter.

   The idea is that the 'separate' formatter shares most of the formatter settings, prepare and view code with the default link formatter. The actual difference between both is merely that the 'separate' formatter outputs the link title and link URL as separate HTML elements (as the formatter name suggests).

   To clarify, this is what 'link_default' outputs:

   <a href="http://example.com">My link title</a>
   

   And this is what 'separate' outputs:

   <h4>My link title</h4>
   <a href="http://example.com">http://example.com</a>
   

   Both formatters share a couple of settings that allow to control whether to output the URL as plain-text (instead of a link) and so on. Also, the code to sanitize the values as well as applying tokens is almost identical.

   I don't know what our current guidelines are with regard to "When, exactly, does one implement a standalone formatter instead of formatter settings?"

   In other words, is a formatter defined by its technical behavior? Or is it defined by its resulting markup?

   Because, if it's the markup that makes up a formatter, then the 'separate' formatter definitely produces different markup and should probably stay its own formatter... But if the markup does not play a key role - or if the marginal difference outlined above is not deemed to be sufficient - then it would be OK to merge them.

   Perhaps I should move the Link formatter change into an own issue?

Created a separate issue for the Link formatter change: #1867822: Leverage new #type 'item' for Link field formatter (merge 'link_separate' formatter into 'link_default')

Removed Link formatter changes.

#19: theme.item_.19.patch queued for re-testing.

#19: theme.item_.19.patch queued for re-testing.

#19: theme.item_.19.patch queued for re-testing.

Yep, that's intentional, since a wrapper is not logical in all cases:

+  // Lastly, only wrap the item in a container if there are any attributes.
+  if (!empty($element['#attributes'])) {
+    $output = '<div' . new Attribute($element['#attributes']) . '>' . $output . '</div>';
+  }

Of course, we could decide that all items should always get at least an .item class on a wrapping DIV, but in evaluating this patch across core, I wasn't able to see why that should be necessary (and it resulted in some divitis). There's a counter-argument of reliability, of course. Perhaps we need to always add a wrapper in order to allow JS and CSS to reliably target elements.

Yeah. But if it's always wrapped in a DIV, then... what's the actual difference to #type 'container'...?

Would it make sense to remove #type 'item' altogether and move the #title » h4.label processing as contained here into #type 'container'?

For #ajax and #states, we'd actually need a HTML ID in #attributes, which in turn means that we need a #pre_render to call element_set_attributes() (e.g., like all form elements).

Second, when appearing inside forms, we could automatically translate #name into an HTML class on the wrapping container; e.g., '[#name]-wrapper'. That should be sufficient for theming.

But when appearing outside of forms, and if there are no #attributes, then I think we do not need a wrapping container, since that would be a DIV without any attributes, which doesn't make sense.

I think we should definitely try to get this in for D8. Perhaps first as #type 'item', to make sure it lands? But with the possible clean-up of merging 'item' into 'container'.

What do you think?

Note that #2002336: Introduce a CSS class to hide borders of fieldset elements introduced a new #type 'fieldgroup' that essentially resolves part of this use-case here, but only within a form context, because it is a <fieldset>.

The original use-case here was targeting output outside of a form context; e.g., Link field formatters just want a "label" followed by custom #markup/#children.