-
Notifications
You must be signed in to change notification settings - Fork 19
Feature/2.x/785 padding horizontal causes unwanted indenting #847
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: 2.x
Are you sure you want to change the base?
Feature/2.x/785 padding horizontal causes unwanted indenting #847
Conversation
markconroy
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @ctorgalson, this looks like a great piece of work.
I've left a few small changes that we should look at and then do some more testing.
Would be great to get this and a few more things into a new major release (e.g. remove the components directory that is now using SDC instead)
| } | ||
|
|
||
| .lgd-section__inner { | ||
| margin: 0 auto; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
margin auto here is causing all the section__inner items to be center aligned, this is affecting the main content block on service pages
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one should be fixed on the current branch.
|
|
||
| .lgd-section__inner { | ||
| margin: 0 auto; | ||
| max-width: var(--width-container, 73.75rem); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure exactly why, but this max-width is making our section__inn 1180px by default (e.g. breadcrumbs) but in the current theme (e.g. demo.localgovdrupal.org) they are equating to 1148px.
It's probably because the padding-inline is now on the outer container instead of the inner container.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
components/section/section.css
Outdated
|
|
||
| /* WRAPPED: inner element has block and inner padding */ | ||
| .lgd-section--wrapped > .lgd-section__inner { | ||
| padding-block: var(--vertical-rhythm-spacing, 1.5rem); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder should we create a custom variable for this, something like --section-block-spacing and set that to equate to --vertical-rhythm-spacing in case some designs wants extra/less padding here, but still want the vertical rhythm amount for paragraphs and things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need an extra variable? This is already achievable with a single line of css in the theme's variables.css or elsewhere:
/**
* Using my new favourite unit for this, `lh`.
*
* @see https://caniuse.com/mdn-css_types_length_lh
*/
.lgd-section {
--vertical-rhythm-spacing: 1lh;
}| section_inner_classes: [ 'tabs' ], | ||
| section_outer_attributes: create_attribute({ | ||
| 'aria-label': 'Tabs'|t, | ||
| role: 'navigation', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can leave out role="navigation" since it's implied by the nav element.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in current branch.
| </article> | ||
|
|
||
| {% endblock %} | ||
| {% endembed %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll need a blank line here at the end of file so the tests don't fail
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in current branch.
|
@markconroy, @tonypaulbarker what do we think of the overall approach? My thoughts: Pros
Cons
/**
* Solving the basic issue with (almost) no utility classes
*
* Given a pre-established set of layouts, we can create the utility classes (like e.g. `region--full-width`), but then
* add selectors to that class's css rule.
*
* By doing this, we can essentially eliminate most uses of utility classes. And since localgov_base acts more like
* a starterkit theme than a base theme, we can always have a local copy of this stylesheet.
*/
/**
* Full width regions
*
* Use .region--full-width utility class, OR add selectors to this list.
*/
.region--full-width,
.region--header,
.region--footer,
.region--content {
padding-inline: var(--spacing);
}
/**
* Constrained content regions
*
* Use .region--constrained utility class, OR add selectors to this list.
*/
.region--constrained,
.region--content {
margin-inline: auto;
max-width: var(--width-container);
/* Variations by node bundle */
.node--type--localgov-services-page & {
margin-inline: 0 calc((100vw - var(--width-container)) / 2 + (var(--width-container) - var(--width-restricted-width-section))));
max-width: var(--width-restricted-width-section);
}
} |
|
@markconroy, @tonypaulbarker any thoughts? |
|
@ctorgalson are you coming to tech group drop in today? We could chat about it there. |
|
@markconroy I had another call. I'll come on the 9th for sure. |
|
Sorry @markconroy, last-minute call here. |

DRAFT
Closes #785
What does this change?
This is a proof-of-concept PR demonstrating a way we can eliminate the hard-to-predict and hard-to-manage layout inconsistencies brought about by the use of
.padding-horizontal.It's finished enough for demonstration, but not ready for use.
The main addition to the theme is a new SDC,
localgov_base:section. The new SDC always renders the same markup, and can be configured to output one or more of ten layout classes that address most common layout issues.For demonstration purposes, the branch makes significant changes to several blocks, the main
page.html.twigtemplate, theregion.html.twigtemplate, theheader.html.twigtemplate, and thefull-contentSDC, altering all of them to use the new SDC.Even in the early stage the branch is in, most layout issues are gone. One notable exception to this is the
localgov_subsite_*content types. The Page Builder paragraphs haven't been touched, though it wouldn't be a lot of further effort to get them to behave the same way.I assume, but haven't checked in any detail, that the Scarfolk Council theme would need some/all of these changes as well.
How to test
localgov_basein an LGD sitelocalgov_baseas the default themeHow can we measure success?
Reduction or elimination of width inconsistencies in content.
Have we considered potential risks?
The main risk is the reason why this change should only accompany a major version change to the theme: existing child themes will have corrected some the issues this change corrects, but in different, incompatible ways.