views.view.html.twig - usage of row class

I am having the same problem when using a view

Please see attached screenshots

From what I can see row should not be added twice.

See https://www.w3schools.com/bootstrap/bootstrap_grid_system.asp

It seems to me quite a lot of these classes are being added unnecessarily. Please see attached

The important thing is it sits in container.

Container adds max width and also centres the container, add adds padding both left and right.

WIth regards to row, to get the desired result I think col needs to be a direct descendent of row. To achieve this it is also possible to move row from the view to the container. Notice this benefits from .row > * {} css

Again please see attached

the simplest solution is to replace the views.view template on your subtheme.

I disagree,

I think the simple solution for most people is to fix it in the parent theme that we are inheriting from.

But i understand it's too risky to change now.

Why?

Behaviour out of the box is wrong? Using a grid layout for a view is an extremely common requirement. If necessary this change could go in either a minor or major release.

Just to confirm, to get around this issue I removed row from

1. Copied the following files to my subtheme from barrio parent

templates/views/views-view.html.twig
templates/form/container.html.twig

2. in views-view.html.twig removed hardcoded row class e.g.

  {% if rows %}
    <div class="view-content">
      {{ rows }}
    </div>
  {% elseif empty %}
    <div class="view-empty">
      {{ empty }}
    </div>
  {% endif %}

3. In container.html.twig added the "row" class to the classes array e.g.

{%
  set classes = [
    has_parent ? 'js-form-wrapper',
    has_parent ? 'form-wrapper',
    has_parent ? 'mb-3',
    'row',
  ]
%}

I have tested on a few list views with that use Bootstrap col classes as well and it seems to work well.

The benefit of this approach is you can also remove the wrapper defined in page.tpl.twig (again this needs to be copied across to your theme in order to do this).

e.g.

 <div class="row row-offcanvas row-offcanvas-left clearfix"> 
...
</div>

That said I am not sure what the consequences of doing this are. In other words I am not sure what the purpose of row-offcanvas row-offcanvas-left clearfix are here? (https://www.w3schools.com/bootstrap5/bootstrap_offcanvas.php)

What this shows is the significance of max-width and or width on the column class with .row > *

The width is defined on col class but for some reason this seems to behave a little differently if both of those attributes are disabled. I do not really understand why this is?

Another thing, the col class is added in HOOK_preprocess_page

e.g.

$content_width = 'col';

And

  $variables['content_attributes'] = [
    'class' => ['main-content', $content_width],
    'id' => ['content'],
    'role' => ['main'],
  ];

Removing reference to $content_width in my sub theme.

I faced dame problem with slick, but ir comes from flex usage un general, not specifically from row cosas un views.

That might explain why you have the following css in style.scss

.slick {
    width: 100%;
}

.slick>div {
    margin: 0 15px;
}

Maybe there should be a click component for this sort of thing.

Looking at this again I believe that the only reason to use row class is in a list view.

For this reason i think it is beneficial to as row class to a direct parent on col class variants where possible.

My solution is to remove other variants of row in the front end theme and to add to parent where we have a list view e.g.

in templates/views/views-view-unformatted.html.twig
in templates/views/views-view-masonry.html.twig

I have modified templates that output row data as follows

e.g.

{#
/**
 * @file
 * Theme override to display a view of unformatted rows.
 *
 * Available variables:
 * - title: The title of this group of rows. May be empty.
 * - rows: A list of the view's row items.
 *   - attributes: The row's HTML attributes.
 *   - content: The row's content.
 * - view: The view object.
 * - default_row_class: A flag indicating whether default classes should be
 *   used on rows.
 *
 * @see template_preprocess_views_view_unformatted()
 */
#}
{% if title %}
  <h3>{{ title }}</h3>
{% endif %}
{% if rows %}
<div class="row">
{% for row in rows %}
  {%
    set row_classes = [
      default_row_class ? 'views-row',
    ]
  %}
  <div{{ row.attributes.addClass(row_classes) }}>
    {{ row.content }}
  </div>
{% endfor %}
</div>
{% endif %}

rows container with row class is output if there are rows to be output

Actually it's better not to add

in templates/views/views-view-unformatted.html.twig
and templates/views/views-view-masonry.html.twig

because infinite scroll will insert multiple rows.

A better approach is to provide a template suggestion for the container template based on available theme suggestions if available

e.g.

function MY_SASS_THEMENAME_theme_suggestions_container_alter(array &$suggestions, array $variables)
{
  $container = $variables['element'];
 
  if (isset($container[0]["#theme"])) {
    $suggestions[] = 'container__' . end($container[0]["#theme"]);
  }


}

Then I can make sure 'row' class is added there

e.g.

{#
/**
 * @file
 * Theme override of a container used to wrap child elements.
 *
 * Used for grouped form items. Can also be used as a theme wrapper for any
 * renderable element, to surround it with a <div> and HTML attributes.
 * See the @link forms_api_reference.html Form API reference @endlink for more
 * information on the #theme_wrappers render array property.
 *
 * Available variables:
 * - attributes: HTML attributes for the containing element.
 * - children: The rendered child elements of the container.
 * - has_parent: A flag to indicate that the container has one or more parent
     containers.
 *
 * @see template_preprocess_container()
 */
#}
{%
  set classes = [
    has_parent ? 'js-form-wrapper',
    has_parent ? 'form-wrapper',
    has_parent ? 'mb-3',
    'row',
  ]
%}
<div{{ attributes.addClass(classes) }}>
  {{ children }}
</div>

Just to follow up on this I believe that a class should be able to be added on a view by view basis. I have created a core issue for this:

https://www.drupal.org/project/drupal/issues/3450377 📌 Remove dependency on hardcoded classes in views template Needs work