Provide some generic components

It was included in another (alpha3) issue MR, wasn't it?

oh yes, the issue description was updated. My bad.

Hello,

I don't think it is up to the display builder tool to provide the components. The components will be provided by the design system used on a website.

Otherwise we will end up like with the 4 Core layouts (1, 2, 3, 4 columns) that we (I only?) use in BO dashboards and that we have to remove with stuff like Layout Builder Restrictions in front.

Special case for "HTML Element": I have something similar on projects, and having something like that would definitively become handy to not have to duplicate it on every projects. But let's put it in UI Patterns 2, why only reserved for Display Builder users?

Discussed with @mogtofu33 during weekly meeting.

HTML wrapper and HTML void element components to go into UIP2

Grid/Flex/Space, to precise, either:
- submodule labelled as demo (problem of Composer namespace)
- test module
- separated drupal.org project (but risk that other people propose their own stuff)
- document as best practice, like the grid_row component was identified as a best practice in its time.

To avoid confusion with components provided by Design Sytems, maybe we can:

• mark them as noUi to not show them in the ComponentLibrary
• display them in the BlockLibrary under the "Element" group

Those ones were already merged before beta1:

props:
  type: object
  properties:
    size:
      type: string
      enum: [... some values in PX]
    direction:
      type: string
      enum: [...]

{% set attributes = attributes.addClass('db-generics').addClass('db-spacer').addClass('db-spacer-' ~ direction|default('vertical')) %}
<div{{ attributes }} style="--size: {{ size|default('16px') }}; position: relative;"></div>

slots:
  content:
    title: Content
props:
  type: object
  properties:
    tag:
      title: Tag
      type: string
      pattern: '^[a-zA-Z0-9-]+$'

<{{ tag|default('div') }}{{ attributes }}>{{ content }}</{{ tag|default('div') }}>

props:
  type: object
  properties:
    tag:
      type: string
      pattern: '^[a-zA-Z0-9-]+$'

{% if tag is defined %}
<{{ tag }}{{ attributes }}/>
{% endif %}

Let's discuss about them:

• spacer: problematic because the enum values in pixels don't necessary fits with the design system currently used. It would be better to rely on Styles plugins in a more generic component. Also db-spacer-* is Display Builder specific markup which must be avoided.
• html_wrapper: confusing naming it is a "normal" HTML element
• html_tag: confusing naming because it is only for empty HTML elements

So, we will first #3556382: (Temporarily) Remove the generic components in beta1 and we will reintroduce them with this ticket, after beta1 and after a discussion.

Proposal 1: Components following technical constraints

We follow the constraints of HTML meaning and SDC definition/template structure:

• A component for empty HTML elements, with an enum with br, hr...
• A component for sectioning HTML elements, with a slot and an enum prop with article, aside, nav, section... it is useful to split them from other block elements if we create a "Layouts" library panel one day.
• A component for other block HTML elements, with a slot and an enum prop with blockquote...
• A component for phrasing HTML elements with a string prop and an enum with abbr, strong, em, q...

Proposal 2: Components following functional needs

What are they ? How the users (site builders, content editors..) understand the element building blocks of a display? Let's study what the pother display building tools are proposing

Let's try something :)