Assuming I have 10 blocks in a Foundation "Block Grid" (where these blocks are equally spaced by the Block Grid) in 3 columns. That gives me 3 rows of 3 blocks and 1 row of a single block.
If I dynamically add a class with display:none to, let's say, first block what I would get is still the same 4 rows with a hole in place of block number 1.
Is there a way to force it to rearrange the blocks as if it had started with 9 originally where you would get 3 rows of 3 blocks?
EDIT:
A little later after my initial post it occurred to me to conduct a test and it looks like a bug in Block Grid: I included a display:none class to an LI within UL that is controlled by Block Grid in the HTML code from the beginning and sure enough the block that is not supposed to be displayed affects the layout!
It looks like Foundation counts the LI that are coded within the UL without considering their display properties. In the example above if I set the first block (LI) to display:none I still get 4 rows with first row having only 2 blocks showing!
After further search I found that Foundation applies clear:both to all n+1th elements in the Block Grid regardless of the element's visibility. However, if all the elements in the grid are of equal size clearing is not going to change anything.
In my case, luckily, all the elements are of the same size so by removing clear:both from the CSS (or overriding it with clear:none !important;) solves my case. However, this is not a solution if the elements are not of the same size. I also found this which is practically the same issue.
Related
When dynamically filling css grid columns I recently noticed that after column 1000 the remainder seems to be filled in the row direction. See the example below. This leads me to the question:
Is there a maximum amount of rows and/or columns when using CSS grid?
Suggestions of how to get the remainder (from 1001 on) in the next columns are welcome, but are not the core of this question.
The CSS grid seems to have a different column/row limit depending on the browser.
For chrome the limit seems to be 1,000x1,000 as explained here in the answer of Bludev
For firefox the limit seems to be 10,000x10,000, but I can't remember exactly where i read this.
I recently asked this question: Horizontally-Drawn RowColumn Class for Motif Library (C)?
In my previous question, I was having trouble getting the xmRowColumnWidgetClass to draw horizontally (row-by-row) instead of vertically (column-by-column). After playing around with it, figured out how to switch to horizontal drawing with the following snippet:
XmNorientation, XmHORIZONTAL,
So the code that creates the xmRowColumnWidgetClass instance now looks like this:
rowColumn = XtVaCreateManagedWidget("rowcolumn",
xmRowColumnWidgetClass,
parentWidget,
XmNnumColumns, 3,
XmNorientation, XmHORIZONTAL,
XmNpacking, XmPACK_COLUMN,
XmNspacing, 6,
NULL);
However, my new problem is that for some reason the XmNnumColumns field is now referring to the number of rows, rather than the actual number of columns. Before adding the XmNorientation, XmHORIZONTAL part, the xmRowColumnWidgetClass instance was drawing the objects from left-to-right but it stayed to 3 columns like it was supposed to. Now, it is staying to 3 rows, occasionally creating a horizontal scrollbar which I do not want. I only want vertical scrolling.
So I need the children of the xmRowColumnWidgetClass instance to be drawn horizontally from top to bottom, but I need it to only put a maximum of 3 per row and thus keep it confined within a certain width.
I tried playing around with the XmNnumColumns field, but things that worked with more children did not work for less children, and vice versa. Sometimes it made it 4 or 5 columns rather than 3, and sometimes it made it 2 columns with the 3rd column completely empty. I encountered many issues like this even when experimenting with things like using XmNpacking, XmPACK_TIGHT rather than XmNpacking, XmPACK_COLUMN and other stuff.
If someone is able to find the official documentation of the xmRowColumnWidgetClass and link it, that would be be greatly appreciated.
To anybody familiar with this library:
How do I create a xmRowColumnWidgetClass instance that draws horizontally (row-by-row) while keeping it to a certain number of columns?
It should be able to handle any number of children and add as many rows as it needs to in order to keep it as exactly 3 columns.
Another group of examples of this library:
https://github.com/spartrekus/Motif-C-Examples
https://github.com/spartrekus/Motif-C-Examples/blob/master/rowcol.c
XmRowColumn was designed to implement the top menubar and all the other menu classes... You are searching for a grid like widget, and so you have to use XmForm read the related question for that.
In short: try the WtTable widget
Longer explanation follows:
The behaviour of XmRowColumn regarding "columns" becoming "rows" when you choose a horizontal configuration is very unfortunate. The alternative of using XmForm instead of XmRowColumn for this purpose is feasible, but however it requires manually setting the children constraints, and even then, it's quite possible that you won't be able to achieve the automatic sizing implemented in XmRowColumn.
By searching today, I found the WtTable widget and it works fine for my purposes. It's "almost" as automatic as XmRowColumn and it doesn't require to set any constraints manually. I tried it in my Motif code, and works fine.
Note however that I said "almost" as automatic. The "almost" is because you need to specify the number of columns and rows, and you need to specify the column and row for each child widget. However, all of this can be automated: you can create a convenience function that internally manages counters for columns and rows, so that you pass a widget to such function and it puts it in the cell it belongs automatically: you can even make that function create a new row in the WtTable when it's needed.
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).
Found the solution in a separate thread! Start with the order you want in the source for mobile, then use the push/pull classes to bend it around for the LARGER sizes. In other words, approach it from the opposite end.
Change order for Foundation small-12 column
I have an XSLFO document with a couple of block elements that have page-break-inside="avoid". Also there is a title-Element before each block-element with keep-with-next.within-page="always".
So basically I have paragraphs with a title and title and paragraph should always be on the same page and there shouldn't be a page-break inside the paragraphs.
The problem is that there are some blocks that have too much content for one page. If the content only overflows the region-body but not the entire page, no page-break occurs, so the block is still on one page.
However, there are blocks where the text overflows the entire page and in that case, there is a page-break-before. One such block element with too much content should be on the first page of the document. However, there is a page-break and it is on the second page of the document.
So in essence, my problem is that there should be no page-breaks within the block-elements (the pargraphs), title and paragraph should always be on the same page AND there should be no page-break before the very first block-element, even if it overflows the entire page. The content should always start on the first page and there should be no empty pages at all.
Thanks for your help and suggestions!
The spec says:
Keep conditions are imposed by the "within-page", "within-column", and "within-line" components of the "keep-with-previous", "keep-with-next", and "keep-together" properties. The refined value of each component specifies the strength of the keep condition imposed, with higher numbers being stronger than lower numbers and the value always being stronger than all numeric values.
Have you tried different values? Maybe you could change page-break-inside="avoid" into keep-together="<your value here>" to use tuned values.
Edit: See spec http://www.w3.org/TR/2006/REC-xsl11-20061205/#keepbreak
My requirement is to produce, essentially, a page WITHIN a page. The xsl defines a page 1/3 the size of an A4 sheet, but up to 3 of them must print on the sheet. The page is a standard header/body/footer, with a 'Page X of Y' on it and of course it is simple. But if there are 4 of these "pages", only 2 pages should be printed, 3 on the first and 1 on the second. But 4 pages are printed, because the output PDF "tells" the printer that is a complete sheet. So what I want to do is either:
code the fo so it does not page break after it finished a page (something like page-break-after="avoid" but at the page sequence level)
OR
generate a page sequence within a page sequence, the outer one being defined as A4 size, the inner 1/3 of that.
I've tried the 2nd directly in a simple way, i.e.,
<fo:page-sequence master-reference="A4">
<fo:page-sequence master-reference="one-third_A4">
...
</fo:page-sequence>
</fo:page-sequence>
..and the processor definitely does NOT like it.
Are there any instructions I can apply that could do either of these? I looked in places like schemacentral and w3schools.com and cannot find anything.
Not sure if I understood you needs (a drawing would help), but can't you simply put your content into a series of fo:block-container elements with specified height? They would come out stacked vertically.
If you need more complex geometry, check out flow-maps feature of XSL 1.1. Three body regions per page connected sequentially in a <fo:flow-target-list>, and a single fo:flow providing content for them.
Having fo:page-sequence within another fo:page-sequence is not valid according to the spec (what would a page number mean then?), and every fo:page-sequence starts a new physical page by definition.
fo:page-sequence-wrapper won't help you on sub-page level either.