h5 响应式解决方案
Responsive Web Design and tables are not necessarily the best of friends. Many people have researched the situation and a lot of approaches have been devised (some of them were even rounded up in a recent article here on SitePoint). However we are still far away from the perfect solution and the search continues.
响应式Web设计和表格不一定是最好的朋友。 许多人已经研究了这种情况，并且设计了许多方法(其中一些方法甚至在SitePoint上的最新文章中进行了汇总 )。 但是，我们离完美的解决方案还很远，搜索仍在继续。
While things are still complicated in the generic case, certain specific cases can be treated with a lot more attention. I am talking here about the feature comparison table. We encounter it in many places – when choosing a car and trying to decide what extra options to choose; on web hosting websites when comparing plans and features; on any membership-based portal that lets you decide what features you need to receive in exchange for your money.
尽管在一般情况下情况仍然很复杂，但是可以更加关注某些特定情况。 我在这里谈论功能比较表。 我们在很多地方都遇到过这种情况–在选择汽车并试图决定选择哪些其他选项时； 在比较计划和功能的虚拟主机网站上； 在任何基于成员资格的门户网站上，您都可以通过该门户网站来确定需要使用哪些功能来换取您的钱。
Because this kind of table has a relatively stable and consistent structure, it is possible to coax a better behavior when displayed on small screens.
因为这种表具有相对稳定和一致的结构，所以在小屏幕上显示时可以哄骗更好的行为。
The classic comparison table brings together at least three products (displayed in columns) while the features are displayed on rows below. In the traditional structure, the first cell of each row has the name of the feature, while the cells under each product have a checkmark or some other symbol, showing whether that feature belongs to the product or not. We can find great examples of this classic structure: here, here, and here
经典比较表将至少三个产品(以列显示)组合在一起，而功能显示在下面的行中。 在传统结构中，每行的第一个单元格都具有要素名称，而每个产品下方的单元格都带有对号或其他符号，以显示该要素是否属于该产品。 我们可以找到这种经典结构的出色示例： here ， here和here
Based on these examples, we can summarize the structure of a comparison table with the following code:
根据这些示例，我们可以使用以下代码总结比较表的结构：
<table> <thead> <tr> <th> </th> <th>Product 1</th> <th>Product 2</th> <th>Product 3</th> </tr> </thead> <tbody> <tr> <td>Feature 1</td> <td>✔</td> <td>✔</td> <td>✔</td> </tr> <tr> <td>Feature 2</td> <td>—</td> <td>✔</td> <td>✔</td> </tr> <tr> <td>Feature 3</td> <td>—</td> <td>—</td> <td>✔</td> </tr> <tr> <td>Feature 4</td> <td>—</td> <td>—</td> <td>✔</td> </tr> </tbody> </table>It is easy to identify the elements mentioned earlier: the product names, the feature names, and the marks that show whether the feature is present or not. Note that the ✔ code represents a checkmark (✔) character.
很容易识别前面提到的元素：产品名称，功能名称以及显示该功能是否存在的标记。 请注意， ✔ 代码代表复选标记(✔)字符。
We now arrive at the root of the problem. In order for the table to maintain optimum effectiveness at low screen widths, a few conditions must be fulfilled:
现在，我们找到问题的根源。 为了使表格在较小的屏幕宽度下保持最佳效果，必须满足一些条件：
The user must be able to easily differentiate the products; 用户必须能够轻松区分产品； The features must be easily identifiable; and 这些功能必须易于识别； 和 It must be clear if a feature for a product is present or not. 必须明确是否存在产品功能。The best way to achieve this result is to shift the cell containing the feature name on top of the other three cells that mark the presence or absence of the feature.
实现此结果的最佳方法是将包含功能名称的单元移到其他三个标记该功能存在或不存在的单元上方。
How can we get this to happen? One answer is flexbox. If you don’t know what flexbox is or if you need a refresher, you can check out Nick Salloum’s recent article on the topic. The rest of us can dive into the solution.
我们怎样才能做到这一点？ 一个答案是flexbox。 如果您不知道什么是flexbox或需要复习，可以查看Nick Salloum关于该主题的最新文章 。 我们其余的人可以深入研究解决方案。
First we need to make sure our changes happen only on small screens. For this to happen, we target our code using a media query, using the classic width of 768px as a breakpoint:
首先，我们需要确保仅在小屏幕上进行更改。 为此，我们使用媒体查询将代码定位为目标，使用768px的经典宽度作为断点：
@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; } }There are a few important things in this set of rules that make the magic happen:
这组规则中有一些重要的事情可以使魔术发生：
We change the display value for the table row to flex and we tell its children to flow in a row, evenly spaced.
我们将表格行的显示值更改为可flex并告诉其子行以均匀的间隔连续流动。
Next we direct the cells to adopt display:block to normalize them as ordinary containers (leaving the default value will bring interference from the table rules, especially regarding the size).
接下来，我们指导单元格采用display:block将其标准化为普通容器(保留默认值将对表规则产生干扰，尤其是在大小方面)。
The next step targets the first cell in each row, making it full width and changing the background color, for added contrast. The flow rules make it stay on top of the other three cells – exactly what we needed. 下一步将目标对准每一行的第一个单元格，使其全宽并更改背景颜色，以增加对比度。 流程规则使它位于其他三个单元的顶部，这正是我们需要的。We finish the change by hiding the first th so that there is nothing displayed above the product names.
我们完成通过隐藏第一变化th ，以便有上面显示的产品名称罢了。
The demo can be viewed here.
该演示可以在这里查看 。
Obviously a solution is valid only as long as it has enough support. According to caniuse.com, support for flexbox is over 80% for the most modern variants and over 93% if we include browser versions that require prefixes or use the previous versions of the rules. Support for IE starts with IE10 (only the 2012 syntax), while IE11 has full support. Because we are mainly interested in support on small screens, we can disregard the lack of support for previous versions of IE. On the mobile front, support starts from Android 4.4 and iOS 7.1. Previous versions require vendor prefixes and don’t support the wrap feature.
显然，解决方案仅在具有足够支持的情况下才有效。 根据caniuse.com的资料 ，对于大多数现代版本， flexbox的支持率超过80％，如果我们包含需要前缀或使用规则先前版本的浏览器版本，则对flexbox的支持率超过93％。 对IE的支持始于IE10(仅适用于2012语法)，而IE11则提供了全面支持。 因为我们主要对小屏幕支持感兴趣，所以我们可以忽略对IE早期版本缺乏支持。 在移动设备方面，支持始于Android 4.4和iOS 7.1。 以前的版本需要供应商前缀，并且不支持包装功能。
You should also provide fallbacks, such as the scrolling div used in Bootstrap. This way the visitors that fall outside the support bracket will still have another alternative for their display.
您还应该提供备用，例如Bootstrap中使用的滚动div 。 这样，落在支撑架之外的访客仍将有另一种显示方式。
If a large portion of the browsers you’re going to support lack support for flexbox, there is an alternative. In fact this is the solution I used in a real project in 2013. We will need a bit of extra markup: we will have to add one extra row, duplicating the feature name. While this can appear tedious to do by hand, it can be automated if the information is read from a data source. In the end, the code from our initial example should look like this:
如果您要支持的大部分浏览器都缺乏对Flexbox的支持，则可以选择另一种方法。 实际上，这是我在2013年的一个真实项目中使用的解决方案。我们将需要一些额外的标记：我们将不得不添加多一行，复制要素名称。 尽管手工操作看起来很繁琐，但是如果从数据源读取信息，则可以将其自动化。 最后，我们最初的示例中的代码应如下所示：
<table> <thead> <tr> <th> </th> <th>Product 1</th> <th>Product 2</th> <th>Product 3</th> </tr> </thead> <tbody> <tr class="visible-xs" aria-hidden="true"> <td> </td> <td colspan="3">Feature 1</td> </tr> <tr> <td>Feature 1</td> <td>✔</td> <td>✔</td> <td>✔</td> </tr> <tr class="visible-xs" aria-hidden="true"> <td> </td> <td colspan="3">Feature 2</td> </tr> <tr> <td>Feature 2</td> <td>—</td> <td>✔</td> <td>✔</td> </tr> <tr class="visible-xs" aria-hidden="true"> <td> </td> <td colspan="3">Feature 3</td> </tr> <tr> <td>Feature 3</td> <td>—</td> <td>—</td> <td>✔</td> </tr> <tr class="visible-xs" aria-hidden="true"> <td> </td> <td colspan="3">Feature 4</td> </tr> <tr> <td>Feature 4</td> <td>—</td> <td>—</td> <td>✔</td> </tr> </tbody> </table>The CSS is also pretty simple:
CSS也非常简单：
.visible-xs { display: none; } @media screen and (max-width: 768px) { .visible-xs { display: table-row; } td:first-child, th:first-child { display: none; } }We can go one extra step for the sake of accessibility and hide the extra markup from screen readers with aria-hidden="true". This way, those screen reader applications that respect the aria-hidden specification will not read the duplicated content twice.
为了可访问性，我们可以再走一步，并使用aria-hidden="true"屏幕阅读器隐藏额外的标记。 这样，那些遵守aria隐藏规范的屏幕阅读器应用程序将不会读取重复的内容两次。
Here is demo of this second solution.
这是第二个解决方案的演示 。
We found here two ways to make a comparison table truly responsive. Both have their pros and cons. In the end, the selected choice should depend on the specifics of your audience. For most cases, the first option (with the fall-back) should be enough. If you really need to cater to the older versions of Android and iOS, you can deploy the second option. Either way, from now on, your feature comparison tables will look a lot better, no matter the screen size.
我们在这里找到了两种使比较表真正响应的方法。 两者都有其优点和缺点。 最后，选择的选项应取决于受众的具体情况。 对于大多数情况，第一个选项(具有后备选项)应该足够了。 如果您确实需要迎合旧版本的Android和iOS ，则可以部署第二个选项。 无论哪种方式，从现在开始，无论屏幕大小如何，功能比较表都将看起来更好。
翻译自: https://www.sitepoint.com/responsive-solutions-for-feature-comparison-tables/
h5 响应式解决方案
