Suggestions for additional SDDS components for testing XB

I don't know the components from CivicTheme but in Omitsis we use Mercury editor with this components:

Layout type:

• Layout: General layout to insert into other componets
• Accordion Layout: Layout to insert accordions content.
• Accordion Content: Layout, that behaves like an accordion, to insert other components
• Tab Layout and Tab Content: Same as Accordion.

Content type:

• Header
• Text
• Content teaser: To insert a content with a view mode, teaser by default.
• Dynamic list: To insert configurable views from the page builder.
• Form: To insert webforms
• Image
• Download
• Link
• Video
• Number: Typical number that when scrolling you see an animation from 0 to the indicated number, plus an icon, prefix, suffix and description.
• Card: With predefined fields to be filled in manually. Configurable view mode
• Blockquote
• Iframe
• Review: An opinion, with a photo and a rating

I think we did a small experiment with sliders before, we can continue on that. Also we should try tabs and accordions, Additionally trying out a unique field and widget like rating would be interesting to see how it behaves with XB.

How fine-grained are the SDCs planned? Are you planning to add SDCs like "link", "button", "pill", "image", "video", etc. or other "smallish" components? Or do you think of SDCs rather as a combination of smaller partials as in a typical cards which incorporates "text", "button", "image" components?

@kristen pol, We can include the below components to the organisms:

1. Gallery: An image or media gallery with thumbnails and a lightbox feature for viewing full-sized images.
2. Pricing Table: A table that compares different pricing plans with features and call-to-action buttons.
3. Modal Dialog: A dialog that overlays the main content and contains text, forms, buttons, and sometimes images.

Been discussing padding adjustments with Jacob. Let's decide if we'd want a "Spacer" type component to put in between components or if we want this type of padding to be handled per component.

I think it's a lot better to have margins and paddings in the components instead of having a spacer component, a spacer has no semantic meaning.

+1 for #10

I agree with

a spacer has no semantic meaning

but these paddings or margins need to be configurable based on different breakpoints.

but these paddings or margins need to be configurable based on different breakpoints.

I think it is better to have this directly in all style properties.

For example, if you have margin-left you should be able to set, in addition to the default, a value for each breakpoint.

It would make sense to me to integrate the existing breakpoints from the theme’s THEME.breakpoints.yml file. Additionally, it would be beneficial to centrally manage margin and padding styles in the XB configuration per breakpoint with classes. For example, if we use TailwindCSS breakpoints like sm, md, lg, xl, and 2xl in our breakpoints.yml file, we can set standard padding and margin values based on these breakpoints (eg. sm:p-1 md:p-1.5 lg:p-2 and so on - either directly or if there would be classes for that already we could map this in our CSS - this would be better because we wouldn't need to add those classes to our safelist because of purgeCSS). Component-specific overrides can then be handled within the XB settings of the respective component when needed.