Responsive Solutions for Feature Comparison Tables-CSS Tutorial-php.cn

Responsive Solutions for Feature Comparison Tables

Key Points

Responsive web design and tables are not perfectly matched, but due to their stable structure, there is still room for improvement in functional comparison tables.
A successful responsive function comparison table should easily distinguish the product, clearly identify the function, and show whether the product function exists.
Two options for creating responsive feature comparison tables include: using Flexbox (modern browser support rate exceeds 80%, 93% support rate including browser versions that require prefix) and using additional tags and ARIA roles (More suitable for older versions of Android and iOS).
Whether the option is chosen, readability, accessibility and availability must be considered when designing responsive feature comparison tables to ensure that they are friendly and accessible to all users, including users with disabilities.

Responsive web design and tables are not the best partners. Many people have studied this and designed many methods (some of which were recently summarized in an article on SitePoint). However, we are still a long way from a perfect solution and the search continues.

While the general situation is still complex, some specific situations can get more attention. What I'm talking about here is the function comparison table. We can encounter it in many places—when choosing a car and trying to decide which extra options to choose; on website hosting sites that compare packages and features; on any member-based membership-based one that allows you to decide which features you need in exchange for money on the portal.

Because this type of table has a relatively stable and consistent structure, it can better control its behavior when displayed on a small screen.

Structure of function comparison table

The classic comparison table puts at least three products (shown in columns) together, while the functions are displayed in the row below. In a traditional structure, the first cell of each row contains the name of the function, while the cell under each product contains a check mark or some other symbol that shows whether the function belongs to the product. We can find great examples of this classic structure: here, here and here.

Based on these examples, we can use the following code to summarize the structure of the comparison table:

<table>
  <thead>
    <tr>
      <th></th>
      <th>产品 1</th>
      <th>产品 2</th>
      <th>产品 3</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>功能 1</td>
      <td>✔</td>
      <td>✔</td>
      <td>✔</td>
    </tr>
    <tr>
      <td>功能 2</td>
      <td>—</td>
      <td>✔</td>
      <td>✔</td>
    </tr>
    <tr>
      <td>功能 3</td>
      <td>—</td>
      <td>—</td>
      <td>✔</td>
    </tr>
    <tr>
      <td>功能 4</td>
      <td>—</td>
      <td>—</td>
      <td>✔</td>
    </tr>
  </tbody>
</table>

Copy after login

It is easy to identify the above-mentioned elements: product name, feature name, and marks that show whether or not the function exists or does not exist. Note that the ✔ code represents the check mark (✔) character.

Now we are at the root of the problem. In order for the table to maintain optimal efficiency at low screen widths, the following conditions must be met:

Users must be able to easily distinguish products;
Functions must be easily recognized; and
It is necessary to be clear whether the product's functions exist.

The best way to achieve this result is to move the cell containing the feature name to the top of the other three cells that mark the function's presence or absence.

Plan 1: Flexbox

How do we do this? One answer is Flexbox. If you don’t know what Flexbox is, or need a review, you can check out Nick Salloum’s recent article on this topic. The rest of us can delve into the solution.

First of all, we need to make sure our changes only happen on small screens. To do this, we use media queries to locate our code, using the classic width of 768 pixels as a breakpoint:

<table>
  <thead>
    <tr>
      <th></th>
      <th>产品 1</th>
      <th>产品 2</th>
      <th>产品 3</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>功能 1</td>
      <td>✔</td>
      <td>✔</td>
      <td>✔</td>
    </tr>
    <tr>
      <td>功能 2</td>
      <td>—</td>
      <td>✔</td>
      <td>✔</td>
    </tr>
    <tr>
      <td>功能 3</td>
      <td>—</td>
      <td>—</td>
      <td>✔</td>
    </tr>
    <tr>
      <td>功能 4</td>
      <td>—</td>
      <td>—</td>
      <td>✔</td>
    </tr>
  </tbody>
</table>

Copy after login

There are some important things in this set of rules that can achieve magical effects:

We change the display value of the table row to flex and tell its child elements to be evenly distributed in rows.
Next, we instruct cells to normalize them into normal containers (preserving the default values will cause interference with table rules, especially in terms of size).
The next step is to locate the first cell in each row to be 100% wide and change the background color to enhance contrast. The process rules keep it at the top of the other three cells – that's exactly what we need.
We make the changes by hiding the first th so that nothing is displayed above the product name.

You can view the demo here.

Obviously, the effectiveness of the solution depends only on the degree of support it. According to caniuse.com, Flexbox has over 80% support for most modern variants, and over 93% if we include previous versions of browsers that require prefixes or use rules. IE support starts with IE10 (only the 2012 syntax), while IE11 fully supports it. Because we focus mainly on support on the small screen, we can ignore the lack of support for previous IE versions. On the mobile side, support starts with Android 4.4 and iOS 7.1. Previous versions required vendor prefixes and did not support wrap functionality.

You should also provide fallback options such as the scrolling div used in Bootstrap. This way, visitors outside of support still have another display alternative.

Scheme 2: Additional markings ARIA role

If most browsers you want to support do not support Flexbox, there are alternatives. In fact, this is the solution I used in a real project in 2013. We need some extra tags: we have to add an extra line, copy the function name. While manual operations can appear tedious, they can be done automatically if you read information from a data source. Finally, the code in our initial example should look like this:

@media screen and (max-width: 768px) {
  tr {
    display: flex;
    flex-flow: row wrap;
    justify-content: space-around;
  }

  td, th {
    display: block;
    width: 33%;
  }

  th:first-child,
  td:first-child {
    text-align: center;
    background: #efefef;
    width: 100%;
  }

  th:first-child {
    display: none;
  }
}

Copy after login

CSS is also very simple:

<table>
  <thead>
    <tr>
      <th></th>
      <th>产品 1</th>
      <th>产品 2</th>
      <th>产品 3</th>
    </tr>
  </thead>
  <tbody>
    <tr class="visible-xs" aria-hidden="true">
      <td></td>
      <td colspan="3">功能 1</td>
    </tr>
    <tr>
      <td>功能 1</td>
      <td>✔</td>
      <td>✔</td>
      <td>✔</td>
    </tr>
    <tr class="visible-xs" aria-hidden="true">
      <td></td>
      <td colspan="3">功能 2</td>
    </tr>
    <tr>
      <td>功能 2</td>
      <td>—</td>
      <td>✔</td>
      <td>✔</td>
    </tr>
    <tr class="visible-xs" aria-hidden="true">
      <td></td>
      <td colspan="3">功能 3</td>
    </tr>
    <tr>
      <td>功能 3</td>
      <td>—</td>
      <td>—</td>
      <td>✔</td>
    </tr>
    <tr class="visible-xs" aria-hidden="true">
      <td></td>
      <td colspan="3">功能 4</td>
    </tr>
    <tr>
      <td>功能 4</td>
      <td>—</td>
      <td>—</td>
      <td>✔</td>
    </tr>
  </tbody>
</table>

Copy after login

To improve accessibility, we can go a step further and use aria-hidden="true" to hide additional markers from the screen reader. This way, screen reader applications that respect aria-hidden specifications do not read duplicate content twice.

This is a demonstration of the second solution.

Conclusion

We found two ways to make the comparison table truly responsive. Both have their advantages and disadvantages. Ultimately, the choice should depend on your audience. For most cases, the first option (with a fallback plan) should be sufficient. If you really need to cater to older versions of Android and iOS, you can deploy a second option. Either way, your feature comparison table will look much better from now on, regardless of the screen size.

(The FAQ part in the original document is omitted here because the content of this part does not match the pseudo-original goal and is too long. If necessary, the pseudo-originality of the FAQ part can be handled separately.)

The above is the detailed content of Responsive Solutions for Feature Comparison Tables. For more information, please follow other related articles on the PHP Chinese website!