基础来源排序混乱 [英] Foundation source ordering confusion

问题描述

我有一个这样的行设置:

<div class="small-12 small-push-12 large-6 columns"><!-- 内容-->
<div class="small-12 small-pull-12 large-6 列"><!-- 内容-->

基本上，当屏幕较小时，我希望在第一列之前拉取第二列，但在大屏幕时保持适当的顺序.

我在这里做错了什么?文档像往常一样回流.

另外，我确实意识到我可以颠倒 HTML 本身的顺序，它会起作用，但只是好奇是否有可能让它以这种方式工作.

解决方案

您的问题促使我查看 Foundation 的 SCSS 源代码以了解网格是如何实现的，因为和您一样，我在让我的列按我想要的方式移动时遇到了麻烦.在寻找答案所花费的时间里，我现在已经忘记了我最初需要找出什么，但是在深入了解网格的工作原理后，我知道它现在将更容易使用，我会更有信心我的工作是正确的.我将尝试在此处提供一些见解.

对您的问题的简单回答是，不，您不能按照您的方式让 Foundation 交换一个列块.[我将它们称为列，而不是网格列，后者指的是 Foundation 的(通常是 12 个)基本列.] 假设它可能有效，我会说代码你写的是正确的.它无法正常工作的实际原因是*在 Foundation 中没有为小型、中型、大型或任何媒体尺寸范围定义 12 列推或拉类."因此，当媒体屏幕尺寸为小"时(在您的情况下)) 推和拉类会被 CSS 默默地忽略，您最终会以原始顺序在两行上得到两列.

一般规则是不能将列从一行推或拉到另一行；你只能沿着同一行移动它们.在看到我重读你的问题之后，我有一个这样的行设置......"但这不是真的，因为目的是产生两个 行.可以用一列定义创建多行，我认为这只是 CSS 浮动工作方式的副作用.

这是会发生的事情(请原谅我将 CSS 属性拟人化……将它们称为对某事做某事"更容易，而且通常似乎是清楚了解正在发生的事情的最佳方式):

对于您指定的每一列，它的宽度是使用当前网格列宽度(加上一些用于间距的装订线")乘以所用类名中指定的网格列数(大 6、小 2、等等.).由于它们已被赋予 float 属性，因此它们会从行的开头与下一个对齐.如果一行中没有足够的空间来显示所有列，则该行将被拆分并在下面的行"上继续，依此类推；那些不适合的将移至下一行(依此类推).如果没有指定其他类，每一列都将显示在这个初始位置.这就是如何从一列定义形成多行.

当您添加 push 和 pull 类时，CSS right 和 left 属性将添加到上述属性中.由指定的 push 或 pull 类确定的偏移量用于计算相对位移，必要时用于重新排序列.但是 left 和 right CSS 属性不知道这些列块来自哪里，或者除了它们处理的行之外还有任何行.所以每一列都沿着它最初放置的线移动，如果移动量将列移动到行边界之外，它将被放置(或部分放置)到行的左侧或右侧(并且可能看不见).这就是您提出的流程通常不起作用的原因，尽管在您的情况下，如上所述，您使用了一个未定义的类 (small-push-12) 并获得了不同的效果.如果您稍微使用编号较低的 push 和 pull 类(1 到 11)，您可以更清楚地看到列是如何被推离一行的.(至少目前由 Foundation 完成的方式)以及为什么我现在认为(因为起初我认为我自己可能有可能)能够在基本情况下创建多行是一种有益的副作用"CSS 恰好可以工作.

对于任何想要提高对 CSS 的理解或使用 Foundation 的人，我强烈建议您花一些时间来研究 Zurb 在框架中实现的一项或多项功能.我发现 SCSS 定义设计良好且编码简洁(尽管可能不是每个人都喜欢，恕我直言，CSS 编码意见似乎与 Mac/Windows 意见一样具有煽动性，并且在表达时经常唤起同样的热情).

I have a row setup like so:

<div class="row">
    <div class="small-12 small-push-12 large-6 columns">
        <!-- Content -->
    </div>
    <div class="small-12 small-pull-12 large-6 columns">
        <!-- Content -->
    </div>
</div>

Basically, I want the second column to be pulled before the first column when the screen is small, but keep it at proper order for large screens.

What am I doing wrong here? The document reflows like it always does.

Also, I do realize I can just reverse the order in the HTML itself and it'll work, but just curious if it's possible to make it work this way.

解决方案

Your question prompted me to look at Foundation’s SCSS source code to see how the grid was implemented since like you I was having trouble getting my columns to shift as I wanted. In the time spent finding an answer I’ve now forgotten what I’d needed to find out originally but having gained insight as to how the grid works I know it will now be much easier to use and I’ll feel more confident that my work is correct. I’ll try to provide some of that insight here.

The simple answer to your question is, No, you can’t make Foundation swap a block of columns in the way you’ve done it. [I’ll call them columns as opposed to grid columns that refer to Foundation’s (usually 12) base columns.] Assuming it might have worked I’d say that the code you wrote would be correct. The actual reason it fails to work is because *there are no 12 column push or pull classes defined in Foundation for small, medium, large or any media size range." Thus, when the media screen size is "small" (in your case) the push and pull classes are silently ignored by CSS and you end up with two columns on two rows in the original order.

The general rule is that you can’t push or pull columns from one row to another; you can only move them along the same row. After seeing that I reread your question which began, "I have a row setup like so…" But that’s not true since the intention is to produce two rows. That one can create multiple rows with one column(s) definition is, I think, just a side effect of how CSS floats work.

Here’s what happens (excuse me for anthropomorphizing the CSS attributes…it's just easier to talk about them as "doing something to something" and often seems to be the best way to clearly understand what's happening):

For every column you specify, it’s width is determined using the current grid column width (plus some "gutter" for spacing) multiplied by the specified number of grid columns from the class name used (large-6, small-2, etc.). Since they have been given the float attribute they are then lined up one against the next starting at the beginning of the row. If there is not enough room on one row to display all the columns the line of columns is split and continues on the "line" below, and so on; those that don't fit are moved to the next row (and so on). Without other classes specified each column will be displayed in this initial position. This is how multiple rows can be formed from one column(s) definition.

When you add push and pull classes the CSS right and left attributes are added to those described above. The offset determined by the specified push or pull class is used to calculate the relative shift which is used to reorder columns if necessary. But the left and right CSS attributes know nothing about where these column-blocks have come from or that there is any row but the one they work on. So each column is moved along the line where it was initially placed and if the amount of shift moves the column outside of the row boundary it will be placed (or partially placed) to the left or right of the row (and possibly out of sight). That’s the reason that your proposed process won't work in general though in your case, as mentioned above, you used a class that wasn't defined (small-push-12) and got a different effect. If you play around a bit with the lower numbered push and pull classes (1 through 11) you can see more clearly how the columns are pushed part way off a row. (the way it is currently done by Foundation, at least) and why I now think (since at first I thought it might be possible myself) that being able to create multiple rows in the base case is a beneficial "side effect" of how CSS happens to work.

For anyone wanting to improve their CSS understanding or who uses Foundation, I highly recommend taking some time to work through one or more of the features that Zurb has implemented in the framework. I find that the SCSS definitions are well designed and cleanly coded (though perhaps not to everyone’s liking since, IMHO, CSS coding opinions seem to be as inflammatory as Mac/Windows opinions and often evoke the same fervor when expressed).

这篇关于基础来源排序混乱的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！