I'm trying to build a 2 column layout with a consistent vertical rhythm (aligned baselines). The calculations for this are pretty straightforward, and I have them working fine. My question is this:
When two columns of text sit side by side, is it possible to have vertical rhythm maintained (or regained) when the vertical-margins in the columns are not 'whole lines'.
In this example: http://jsfiddle.net/beejamin/PMCXt/ I have an unordered list, where both the list, and the list items have 'half a line' of margin-bottom. When there are an even number of list items, the margins add up to a whole line, and the rhythm is kept (that's good!). When there are an odd number though, the baselines are thrown out, and can't ever join up again (unless I get lucky and another odd-numbered list comes along).
Setting whole-line margins on list items is too much (especially with a long list), and setting no margin is not enough.
Is there any way I can avoid/mitigate this? I won't know the number of lines in advance, and I don't want to use javascript for this (I'm trying to build a generic scheme that I can re-use).
OK, so here's a pure CSS solution. It relies on :nth-child and :last-child selectors, so only browsers that support those selectors will do it. That's good enough for me, seeing as it's really just a nice piece of polish. It would be easy enough to apply for older browsers with some javascript, too.
Here's the working example: http://jsfiddle.net/beejamin/DpSzW/
The key is this selector:
li:nth-child(odd):last-child { margin-bottom: 1.6em /* One full line */}
This adds a full line's margin to the last-child of a list, whenever the last-child is also an odd-numbered child. The full line margin replaces the half-line the item would normally have, and so the vertical rhythm is restored. Basically, it makes any list always take up an whole number of lines.
When a list has an even number of items, the selector does nothing, and everything stays nice.
Not 100% sure, as I didn't test in all conditions, but this seems to work.
Keep the line-height the same.
keep the margins the same as the line-height.
keep the font-size the same.
Example: http://jsfiddle.net/jasongennaro/PMCXt/1/
Related
I’m writing a template for marking on flex/box. And faced with the problem of emulation of some properties. At the moment, I decide them on JS. What complicates code.
So I decided to try to use the property of table-cell for child elements whose parent has the property display: block. Yes, it’s not right, but it works!
When I’m trying to break the table-cell elements to strings, I ran into a problem. And that’s how I tried to solve them:
If the child blocks table-cell overflow the parent horizontally, then
the following blocks are not transferred to the new line. And it is
logical. Example: Nowrap in link.
If I use the cancel flow, I lose equal to the width of columns for the element to be wrapped to the next line. So, this method only works for IE9+. I’m willing to drop IE7, but not ready to abandon IE8. Example: Wrap nth-of-type in link.
If I use the blocks which separate the table-cell on the line, everything becomes fine! But this complicates the CSS and JS code. Example: Wrap with break elements in link.
Example: http://codepen.io/anon/pen/GmgXmO
What ways to break table-cell can be applied, besides the above described options?
An example of a 12 column layout, fix the problem of calculation of the width percentage: http://codepen.io/anon/pen/PmwRvK
In order to make it clear why I do this.
I will be glad to hear your answers! And excuse me for my bad English.
P.S.: Ignore the strange size of the width in percent. It is calculated
according to the formula:
(100 * element.clientWidth / element.offsetWidth).
The smaller size, so it is more. Funny. This rule is applicable only to
the parent display: block containing the child elements display: table-cell
We are trying to create a menu style layout. I'm using a css-columns properties to achieve the effect of columns. The content is variable, so we'd like to stick to this solution because we want the browser to organise the content for best fit.
In the example below we are seeing some odd behaviour in Chrome (Version 32.0.1700.77) and some different (but equally odd) issue in Firefox (Version 24.0) so I'm assuming it's our implementation.
In Chrome, we see a large gap underneath the first column as if it's placing the 3rd LI there to start off with, then moving it to the top of the second column at some point in the render process.
In Firefox, we see the H3 "scrambled egg" being left at the bottom of the first column, when the rest of the 3rd LI's content moved to the top of the second column.
Live Example: http://codepen.io/daviddarnes/pen/BeEIp
Speculations:
- We are using "break-inside: avoid;" on every element inside the OL. This could be causing the issue, but we can't seem to rectify it.
- Based on the H3 issue... might be something to do with that? Or the elements near to this H3 tag.
The point of the page-break properties is not to shrink content to fit on a page, but to help decide the optimal place for a page break to occur.
So, if you use 'page-break-inside:avoid' on an element, and there's not enough space on the current page to fit the entire element, the browser will consider inserting a break so as to force the element onto a new page, theoretically giving it more space.
However, if the element is so big that moving it onto a new page won't help, then there's nothing to be done (in terms of page breaks at least).
If you know in advance that your content will need to be shrunk when printing, you could try adding a scale transform on the problem elements (restricted to the print media type), so that they're a more manageable size.
Is this of any help to you?
I've been trying to figure out the best solution for displaying a list of projects using Singularity.
I want to essentially remove the padding of the last item of each row but add that padding back into the overall project width of all projects.
I think the solution will have more to do with css than singularity but maybe there is a good solution within singularity I am missing?
These projects will eventually be regularly added by a cms.
example: http://sassmeister.com/gist/7916151
Okay, there's a number of things you should consider.
Firstly, Singularity and Breakpoint are not yet compatible with Sass 3.3, whereas Sassmeister.com is already using Sass 3.3. Make sure you're using Sass 3.2.x in your project. To demonstrate Sass+HTML, consider using SassBin.com.
Secondly, you're using 12px gutters. This is incorrect. Gutters are specified as a unitless value, relative to a single column unit. So when you have two columns and 12px gutters you actually tell Singularity to make gutters 12 times larger than columns.
Instead, provide relative gutters like this: $gutters: 0.1.
Thirdly, you specify a 4-column grid for the medium size but you only use them as a two-column grid. If you don't use four columns somewhere in your project, i suggest that you omit that 4-column definition and keep using the 2-columns grid.
Fourthly, you're setting an outline on your container but it never displays properly because the container has zero height. It has zero height because all its contents is floated.
To have the container embrace the floated content, you have to apply a clearfix to the container. Google it up. The simpliest way to apply a clearfix is to use the pie-clearfix mixin that comes with Compass. But i suggest that you use the %clearfix-micro extend that comes with Toolkit.
Fifthly (is there even such a word?), to remove the gap on the right, you have to apply a last float-span to the last item in every row. To do that properly, you have to learn how the nth-child works. I highly recommend that you google it up.
In short, nth-child accepts an argument that looks like An+B where A and B are whole numbers. The A should be equal to the number of columns and B is the number of the column you're addressing. As you're addressing the last column, B is equal to A in your case. So the whole thing looks like nth-child(3n+3) for example.
Sixthly, you're applying Singularity spans for different breakpoints in such a manner that they accumulate. This is okay when you override spans to all your items at once, so that all of them become redefined in each media query.
But when you apply styles selectively (to the last item in each row), you'd have to cancel them too. This is a very cheerless thing to do.
Instead, you should narrow down your media queries so that they address only specific slices between two breakpoints. In this case, spanning styles will not accumulate.
Here's how you code would look if you used all my recommendations: http://sassbin.com/gist/7951326/
Seventhly (my tongue hurts), consider using the Breakpoint Slicer extension, a tiny wrapper for Breakpoint that makes slicing breakpoint ranges very quick and effortless.
Here's how your code could look if you used Breakpoint Slicer: http://sassbin.com/gist/7951724/
Eighthly, if you did want fixed gutters, you should've set the $gutter-styles: 'fixed' option.
Of course you could do something like this:
&:nth-child(3n) {
margin-right: 0;
}
On the Singularity wiki, it seems to indicate that this should work:
&:nth-child(3n) {
#include float-span(2, 'last');
}
But it didn't or I didn't understand its function.
Thanks for the extensive answer.
I'm well aware of the nth-child selector. I went down that road but decide it wasn't a clean solution for me.
I know I didn't clear the float...wasn't really part of my question.
Setting a fixed height of 12px is not incorrect based on the documentation: https://github.com/Team-Sass/Singularity/wiki/Creating-Grids#fixed-gutters
I need fixed gutters. That's the whole crux of the problem here.
I started making my own fixed gutter fluid column solution that I'm liking thus far: http://codepen.io/joshuarule/pen/zsfEo
Excerpt of the question: I have a menu which works in every browser but was buggy on IE7. I solved throwing zoom:1 but normally the hasLayout related problems involves float, position and stuff. Why this time zoom made it work?
I have a menu which works in every browser (even on IE8+) which looks like this:
Consists of a LI which holds a DIV working as a 1px border using a .png BG and a block A that have an icon and text.
The resumed HTML would be ul.adminMenu>li>(div.menuBorder)+(a{link}):
<ul class="adminMenu">
<li>
<div class="menuBorder"></div>
link
</li>
(...other li's...)
</ul>
The li.active gets a darker BG.
Unfortunately I'm obligated to make it work on IE7 Standards Mode (That explains why I use a div with .png instead of RGBA border) which is looking like this:
Yes. There is a whatsoever space between the start of li and the "border" div. I already tried the following methods:
display:inline-block then block
remove tabs and white spaces on the html
font-size and line-height 0 on separator
None of them have worked and there is nothing on Dev Tools which points to a margin or border (all are 0 with !important).
So the question is:
There are no floated elements, no absolute positioned things, just blocks. Why zoom:1 (which trigger hasLayout) make all damned spaces go away?
The JsFiddle (There is some extra markup divs but ignore them, had more stuff that I removed for the sake of simplicity)
I know it's part of IE 'features (bugs)' but I was looking for something else as an answer.
Lists
Lists are affected by layout applied either to the list (ol, ul) or to the list elements (li). Different versions of IE react differently. The most evident effects are on the list markers (fully customized lists where the markers are not required won't have these problems.) The markers are probably created by internally adding some elements that are somewhat “attached” to the list elements (usually hangs out of them) and seems rather unstable. Unfortunately, being “internal” only objects, they cannot be accessed to try to correct mis-behaviours.
The most evident effects are:
Layout applied to a list makes the markers to disappear or to be differently/wrongly positioned.
Sometimes they can be restored by changing margins on the list elements. This looks like a consequence of the fact that a layout element tends to crop internal elements hanging out of it.
Layout applied to list elements creates the same problems as above, and more (extra vertical space between list items)
A further problem is that (in ordered lists) any list element with layout seems to have its own counter. Let's say we have an ordered list with five elements where only the third has layout. We'll see this:
1... 2... 1... 4... 5...
Moreover when a list element with layout displays on multiple lines the marker is vertically aligned at the bottom (not at the top, as expected.)
Some of these problems cannot be cured, so when the markers are desired it's better to avoid layout on lists and list elements. If it's necessary to apply some dimension, this is better applied to other elements: for example a width can be applied to an external wrapper, and a height to the content of each list item.
Another common problem with lists in IE occurs when the content of any li is an anchor with display: block. In these conditions the white space between list items is not ignored and usually displayed as an extra line for each li. One of the methods to avoid this extra vertical space is to give layout to the block anchors. This also has the benefit of making the whole rectangular area of the anchors clickable.
For more detail visit : http://www.satzansatz.de/cssd/onhavinglayout.html
In this fiddle http://jsfiddle.net/dAHqe/2/ I've created examples for the 2 main uses (that I've seen) of border-radius for lists.
Apply border-radius (and therefore background-color) to the container (a div or a ul).
Apply border-radius (and therefore background-color) to the first and last content items (lis or nested divs) via the :first-child and :last-child pseudo-classes.
At first glance, it looks like the first way (applying it to the container) is much more concise, yet I see the second way all the time.
Is there any good reason (i.e., scalability) to use the second way?
Update: This is for a mobile app, so I won't need the :hover pseudo-class.
Personally, in the examples you've given, I'd always just go with the simple option and put it on the container.
However, reasons for doing it the other way:
Maybe you don't have a container, and you can't change the code to add one.
You have some reason to want the flexibility to change individual list items in a way that having a single container wouldn't work. eg Maybe you want to make them semi-opaque on hover?
You have to work around an awkward HTML structure. I had a case like this a while back where I had to add rounded corners to cells in a complex table. The cells in question were sub-heading rows and columns in a bigger table, but the way it all fitted together meant I had to put the rounded corners individually into separate cells. It was fiddly and awkward but ended up looking how they wanted it.
The coder doesn't know CSS all that well and simply cribs it from somewhere else that does it that way.
Those are the only reasons I can think of. But I suspect most cases fall into one or other of those.
Hope that helps.