Patch to commit: #3

Problem/Motivation

Proposed resolution

User interface changes

None.

API changes

None.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

RainbowArray’s picture

Status: Active » Needs review
FileSize
2.86 KB

Here's a few tests to check if responsive table classes are being applied correctly.

Status: Needs review » Needs work

The last submitted patch, 1: 2282683-1-responsive-table-test.patch, failed testing.

RainbowArray’s picture

FileSize
3.08 KB
3.46 KB

Here's a revised patch with the interdiff.

RainbowArray’s picture

Status: Needs work » Needs review
markhalliwell’s picture

Status: Needs review » Needs work

We should test that the priority classes aren't applied when #responsive isn't set or not TRUE.

RainbowArray’s picture

Status: Needs work » Needs review
FileSize
4.25 KB
1.57 KB

Added the additional test.

Status: Needs review » Needs work

The last submitted patch, 6: 2282683-6-responsive-table-tests.patch, failed testing.

RainbowArray’s picture

Status: Needs work » Needs review
FileSize
4.15 KB
1.37 KB

Tried a different approach to check how output is handled when responsive tables are not enabled.

Status: Needs review » Needs work

The last submitted patch, 8: 2282683-8-responsive-table-tests.patch, failed testing.

gnuget’s picture

Hi mdrummond.

You have done an awesome job with these tests, thank you.

Right now, the: #responsive => TRUE only add the class 'responsive-enabled' in the table tag and the core/drupal.tableresponsive library.

// If the table has headers and it should react responsively to columns hidden
// with the classes represented by the constants RESPONSIVE_PRIORITY_MEDIUM
// and RESPONSIVE_PRIORITY_LOW, add the tableresponsive behaviors.
if (count($element['#header']) && $element['#responsive']) {
    $element['#attached']['library'][] = 'core/drupal.tableresponsive';
    // Add 'responsive-enabled' class to the table to identify it for JS.
    // This is needed to target tables constructed by this function.
    $element['#attributes']['class'][] = 'responsive-enabled';
}

Which i think it is totally ok, so in the tests the #responsive => FALSE only should check if theresponsive-enabled class and the library are added, it is not necessary to make sure the priority-low and priority-medium classes are there because these are a common CSS classes, and the user must be able to add those classes even if not want a responsible table.

The problem here is in the themes we have something like this:

/**
 * Responsive tables.
 */
@media screen and (max-width: 37.5em) { /* 600px */
  th.priority-low,
  td.priority-low,
  th.priority-medium,
  td.priority-medium {
    display: none;
  }
}
@media screen and (max-width: 60em) { /* 920px */
  th.priority-low,
  td.priority-low {
    display: none;
  }
}

it doesn't matter if we have #responsive => FALSE the priority-low and priority-medium classes will still be hiding in narrow devices.

I think we should change that for something like this:

/**
 * Responsive tables.
 */
@media screen and (max-width: 37.5em) { /* 600px */
  .responsive-enabled th.priority-low,
  .responsive-enabled td.priority-low,
  .responsive-enabled th.priority-medium,
  .responsive-enabled td.priority-medium {
    display: none;
  }
}
@media screen and (max-width: 60em) { /* 920px */
  .responsive-enabled th.priority-low,
  .responsive-enabled td.priority-low {
    display: none;
  }
}

But that is out of the scope of the issue.

For now, In my opinion is only necessary change how #responsive => FALSE is tested.

joelpittet’s picture

Assigned: Unassigned » LewisNyman
Issue tags: +frontend

@gnuget I agree it should be a bit more specific so we aren't name collision. Maybe @LewisNyman can chime in on #10?

LewisNyman’s picture

Assigned: LewisNyman » Unassigned
Issue tags: +CSS

I think it just testing the .responsive-enabled and the library is enough for this issue.

I think the problem with the CSS classes is that it is not clear what the .priority-x classes do, so there is potential for unintentional overlap and false positives.

Our CSS standards have a way of dealing with this :) I would suggest:

.responsive-priority-low
.responsive-priority-medium

Removing the elements from the selectors would also be nice.

RainbowArray’s picture

If we have a property that turns responsiveness on tables on and off, then it doesn't make sense to enable responsiveness unless that responsive-enabled class is present. The suggestion in #10, minus the elements, would maybe be good:

/**
 * Responsive tables.
 */
@media screen and (max-width: 37.5em) { /* 600px */
  .responsive-enabled .priority-low,
  .responsive-enabled .priority-low,
  .responsive-enabled .priority-medium,
  .responsive-enabled .priority-medium {
    display: none;
  }
}
@media screen and (max-width: 60em) { /* 920px */
  .responsive-enabled .priority-low,
  .responsive-enabled .priority-low {
    display: none;
  }
}

I'm fine if we change that to:

/**
 * Responsive tables.
 */
@media screen and (max-width: 37.5em) { /* 600px */
  .responsive-enabled .responsive-priority-low,
  .responsive-enabled .responsive-priority-low,
  .responsive-enabled .responsive-priority-medium,
  .responsive-enabled .responsive-priority-medium {
    display: none;
  }
}
@media screen and (max-width: 60em) { /* 920px */
  .responsive-enabled .responsive-priority-low,
  .responsive-enabled .responsive-priority-low {
    display: none;
  }
}

That's outside the scope of this issue, but could be done in a follow-up side issue.

I'm still not clear why the latest tests I wrote failed. Any insights?

gnuget’s picture

Your tests fails because the classes are added even if the '#responsive' => FALSE, is set... this is because those are normal classes and aren't stripped when the #responsive is false.

So, here you only need to tests if the table has the responsive-enabled class, and that's it.

+++ b/core/modules/system/src/Tests/Theme/TableTest.php
@@ -138,6 +138,102 @@ function testThemeTableHeaderCellOption() {
+  public function testThemeTableResponsivePriorityNotEnabled() {
+    $header = array(
+      array('data' => 1, 'class' => array(RESPONSIVE_PRIORITY_MEDIUM)),
+      array('data' => 2, 'class' => array(RESPONSIVE_PRIORITY_LOW)),
+      array('data' => 3),
+    );
+    $rows = array(array(4, 5, 6));
+    $table = array(
+      '#type' => 'table',
+      '#header' => $header,
+      '#rows' => $rows,
+      '#responsive' => FALSE,
+    );
+    $this->render($table);
+    $this->assertRaw('<th>1</th>', 'Header 1: the priority-medium class was not applied.');
+    $this->assertRaw('<th>2</th>', 'Header 2: the priority-low class was not applied.');
+    $this->assertRaw('<th>3</th>', 'Header 3: no priority classes were applied.');
+    $this->assertRaw('<td>4</td>', 'Cell 1: the priority-medium class was not applied.');
+    $this->assertRaw('<td>5</td>', 'Cell 2: the priority-low class was not applied');
+    $this->assertRaw('<td>6</td>', 'Cell 3: no priority classes were applied.');
+  }
markhalliwell’s picture

Issue summary: View changes
Status: Needs work » Reviewed & tested by the community
Issue tags: -Needs tests, -frontend, -CSS

My comment in #5 was based loosely on very tired IRC conversation between @mdrummond and myself. It was my understanding that this is how it should work, but ultimately if it failed a follow-up should be created to address it. As far as the class name changes, that is indeed out of scope and should be a separate follow-up issue.

The tests in #3 is sufficient for #806982: Tables should take an optional footer variable and produce <tfoot>.

LewisNyman’s picture

Status: Reviewed & tested by the community » Needs work

Tests are still failing :( See #14

markhalliwell’s picture

Status: Needs work » Reviewed & tested by the community

It already has that test, review #3.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Awesome work! I'll sleep better at night with this patch. :)

Committed and pushed to 8.x. Thanks!

  • webchick committed 7862be8 on 8.x
    Issue #2282683 by mdrummond | Mark Carver: Responsive tables do not have...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.