Our .padding-horizontal class causes unwanted indenting

[markconroy]

We have a very handy .padding-horizontal class so text/content does not bump up against the side of the screen on small screens.

However, since it's added at the page.html.twig level, and node.html.twig level, and paragraph.html.twig level, it can lead to ugly indenting which you need to override with CSS or custom templates.

Let's figure out a way to fix this, if possible.

[ctorgalson]

Quick and dirty helper

If we want a very limited short-term fix now that the display-full SDC is in use, could add a variable to the SDC allowing .padding-horizontal to be handled similarly to how .node__restricted-width-section is now handled. We'd still have to override localgov_base templates, but doing so would become simpler.

Suggested approach

On a different subject, when I've tried to address this kind of problem in non-SDC themes by doing two things:

1. give .padding-horizontal etc. more friends (i.e. more utility classes),*
2. in general, set almost no default margins or padding at the layout level**

To do that, I've basically used these rules:

• layout grids, whether page or component-level, should:
  • use `display: grid;'
  • have zero margin, padding, and border by default
  • use column-gap and row gap for gutters
• all Drupal regions*** should:
  • have 100vw width
  • consist of an inner and outer element
  • have no default margins except when between sibling region elements
  • have only padding-inline so that the content doesn't reach the viewport edges at small sizes, but the region's background always can
  • use BEM classes on the outer element to define their specific behaviours, like e.g.:
    • .region--contained, like .lgd-container but never used except in regions
    • .region--condensed to unset the default margins
    • .region--bleed to unset even the default padding

I made a quick codepen to illustrate. It's not a complete design-system or anything, but in 41 61 lines of css It probably addresses about 80% of the layout issues we get by using .padding-horizontal alone. Also, naming things is hard 🙄.

https://codepen.io/bedlamhotel/pen/EajyyQv

Note that:

• content edges always align
• content never collides with the viewport edge at smaller sizes
• region backgrounds can reach the viewport edges
• sibling regions are separated by default, but can be made to touch
• the regions' padding/margins etc are easily unset (by using the right classes) to accommodate content

---

* IMO, it's easier not to use utlitiy classes for this purpose, but I'm trying to keep within the existing paradigm.
** Even at the component level, I'd suggest no default margins: margins come into effect contextually.
*** For LGD purposes, I'd include Subsite Landing sections under the category of 'region'.

[ctorgalson]

It occurs to me that this would make a pretty good SDC.

If it's helpful, we could even make an SDC compatible with the current system and what I'm proposing above by setting a flag on the theme like:

/**
 * Implements hook_preprocess().
 * /
function localgov_base_preprocess(&$variables, $hook) {
  $variables['localgov_base_feature_branch'] = '1.x'; // Only changes with major version.
}

[ctorgalson]

@tonypaulbarker this relates to other things you're looking at, I think.

[markconroy]

I'd really like to explore this futher. This looks like a really clever way of working, and I love the idea of it being an SDC.

[ctorgalson]

@markconroy I'll create a proof of concept and push the branch up so anyone who's interested can test it out.

[ctorgalson]

@markconroy @tonypaulbarker I've implemented a stub SDC on a branch to demo the concept. I've named the SDC section to avoid class collisions and indicate that its potential uses go beyond Drupal regions (i.e. this should also be useful for subsite Page Builder stuff).

https://github.com/localgovdrupal/localgov_base/tree/feature/2.x/785-padding-horizontal-causes-unwanted-indenting/components/section

It would be possible to make the SDC also replace the default region template, but it would also be more complex.

What's done

• internal classes for all ordinary region/subsite section layouts
• README/inline comments re: those classes
• demo classes to make visualisation simpler
• a single partially-built template implementation (region--content-top.html.twig)

What's not done

• between-section classes
• full README
• more elaborate demo

[tonypaulbarker]

On the original issue, let's keep in mind that this could get complicated and having some bumpers to stop the content bleeding to the edge for any team that doesn't have front end developers makes sense. Bleeding to the edge is probably worse than some unwanted indenting.

It is possible to use breakout classes although it's nasty to have to do so.

My notes on experiences with the restricted-width-section and padding side of things.

Applying this at the node level leads to width inconsistencies from one content type to another when a component is nested in a node template.

I think that controlling things at a section level is better, but having control at a granular level is better still.

Most granular example: All p tags inside WYSIWYG content are controlled for readability (along with heading elements) but not the whole long text field, because you may have an image floated next to the text.

Having a section SDC seems to make sense on the face of it, but can we wrap all the components we want to with it and what happens when those things become nested? Say, we have a paragraph nested inside a page section or building blocks field inside a node template. If we use it for a region template, how does it look when we have a footer with regions in columns?

It feels as though what we are trying to achieve is a 'container' component that we can consistently centre and add some horizontal and vertical spacing to.

The tricky thing here is, sometimes a thing will be at the right level and sometimes it'll be nested so to accompany the SDC it might also be handy to have a global set of classes and variables that can be applied by context.

There is also a practicality - to apply a class I need to go edit a template. If I have many templates, it's faster to add a style to a class already present. Sometimes I don't have a template to add a class to and I need to style an element.

.my-block {
margin: var(--my-wide-container-margin-variable);
padding: var(--my-small-padding-variable);
}

.my-other-block {
margin: var(--my-regular-container-margin-variable);
padding: var(--my-regular padding-variable);
}

.my-thing-to-restrict {
max-width: var(--we-have-the-perfect-variable-for-this-already);
}

So, I reckon we want an SDC called 'container' that we can send a handful of props to and part of the header template, or a region or a paragraph or a body field can include the container SDC if it wants (or not if it doesn't).

[ctorgalson]

@tonypaulbarker this isn't really meant to directly address some of the issues in your comment--I don't see the approach in the SDC being useful in any context except those where the expectation is of an element that occupies the full layout width, e.g. .region and .lgd-page-section. Content I see as a separate part of this problem (more on that below).

Yes, part of the issue is that .padding-horizontal compounds in increasingly unhelpful ways when it's nested. But that happens because we've been relying on .padding-horizontal (and .lgd-container and friends) for page-level layout like Drupal regions and LGD Page Builder sections and the content inside them. Currently, we're mixing layout and content styles in a way that guarantees problems.

In most cases, these problems can be solved by providing a capable set of layout styles, and removing default inline padding from content, or at least providing separate styles specific to content (like e.g. the lgd or page-builder grids which will work perfectly well inside a system like this).

The SDC addresses the first part of that problem by providing a way to address almost all of the page-level layout possibilities, keeping these main principles in mind (using "section" to refer to .section and "section content" to refer to .section__inner):*

1. sections should reach the viewport edges by default (in case, e.g., they have a background color or image)
2. sections should have padding-inline by default (for separation of section content from the viewport edges at small sizes)
3. section content should be contained to the layout-width by default
4. section content should have no block or inline padding by default
5. all of 1-4 should be trivially overrideable

The codepen (which I've updated to use layout classes only from this branch) demonstrates both pretty well: we're able to vary the space allowed for content to exist in within the overall layout. Note that the content in any given section aligns with the content in every other section regardless of page width.

When it comes to child themes, it will make things rather simple. E.g. if we were overriding .region--* templates to implement the sections of the Codpen with the SDC, they'd look like this (Page Builder templates' styles map well onto this approach as well):

{# Banner #}
{% embed 'localgov_base:section' with {
  section: region,
  section_outer_classes: [ 'lgd-section--bleed', 'lgd-section--uncontained' ],
} %}
  {% block section_content %}{{ content }}{% endblock %}
{% endembed %}

{# Section Demo #}
{% embed 'localgov_base:section' with {
  section: region,
  section_outer_classes: [ 'lgd-section--expanded' ],
} %}
  {% block section_content %}{{ content }}{% endblock %}
{% endembed %}

{# 1. Defaults #}
{% embed 'localgov_base:section' with { section: region } %}
  {% block section_content %}{{ content }}{% endblock %}
{% endembed %}

{# 2. "wrapped" and "bleed"#}
{% embed 'localgov_base:section' with {
  section: region,
  section_outer_classes: [ 'lgd-section--bleed', 'lgd-section--wrapped' ],
} %}
  {% block section_content %}{{ content }}{% endblock %}
{% endembed %}

{# 3. "expanded" and "wrapped" #}
{% embed 'localgov_base:section' with {
  section: region,
  section_outer_classes: [ 'lgd-section--expanded', 'lgd-section--wrapped' ],
} %}
  {% block section_content %}{{ content }}{% endblock %}
{% endembed %}

{# 4. "wrapped" with content #}
{% embed 'localgov_base:section' with {
  section: region,
  section_outer_classes: [ 'lgd-section--wrapped' ],
} %}
  {% block section_content %}{{ content }}{% endblock %}
{% endembed %}

{# 5. defaults with content #}
{% embed 'localgov_base:section' with { section: region } %}
  {% block section_content %}{{ content }}{% endblock %}
{% endembed %}

---

* There are more tweaks to add involving the vertical relationships of regions to one another (chiefly contextual and overrideable margin-block settings, but those will be fairly simple to add.

[ctorgalson]

By the way: my next step on this proof-of-concept will be to replace the theme's regions without touching any content templates or styles. That should give us a good idea whether or not I'm talking through my hat 😀 .

[tonypaulbarker]

When writing SDCs, rather than

section_outer_classes: [ 'lgd-section--wrapped' ],

I'd prefer something like this

wrapped: TRUE

then in the SDC:

{% set section_outer_classes = [ wrapped ? 'lgd-section--wrapped', bleed ? 'lgd-section--bleed' ] %}

so the SDC is self-contained, scoped and defined, we can easily know its possible states for testing in something like storybook and we can be consistent without scanning other templates in the theme.

I think my main reason for preferring the naming of 'container' to 'section' is that section is an HTML element and probably not everything that we'd want to contain is a semantic section (not every semantic section will be contained).

[ctorgalson]

Making a note for later. A good way to handle that would be something like this Twig example:

{# Assumes a prop, section_options #}

{% set default_options = [
  'bleed',
  'expanded', 
  'uncontained',
  'wrapped',
] %}

{% set options = section_options|default([])|filter(option => option in default_options)|map(option => 'section--' ~ option) %}

{% for option in options %}
  {{ option  }}<br>
{% endfor %}

[ctorgalson]

Updating this so people don't think it's forgotten.

I've been testing this approach on a (non-LGD) project, and I'm quite satisfied that it demonstrates the utility of the approach outlined here. My next steps are:

1. complete the SDC on a feature branch,
2. create a proof-of-concept branch that uses the SDC to render a selection of regions and content templates,