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.
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
In addition to the question stated in the title, I also conversely would like to know how is display:inline different from clear:none?
EDIT: I had a hunch this question would be unpopular... let me elaborate.
Both seem to involve putting elements onto their own line. "display:inline" flows elements inline, which strikes me as very similar to the behavior of "clear:none", which allows elements to float next to you.
Conversely if you want your div, perhaps a footer as in this example https://css-tricks.com/all-about-floats/, to stand on its own then you can say "clear:both" indicating that nothing may float next to you.
But this behavior seems very similar to "display:block".
Hence my question, how are these different in behavior or expected usage?
I'm sure it's obvious by now that I'm a total amateur in CSS, but after 15 years in backend programming I'm trying to face my fears and learn it. I hope someone might answer the question rather than downvoting me for trying to learn something new...
display:block -> Displays an element as a block element (like <p>)
clear:both -> No floating elements allowed on either the left or the right side
A block-level element always starts on a new line and takes up the full width available (stretches out to the left and right as far as it can).
An inline element does not start on a new line and only takes up as much width as necessary.
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
The div is the quintessential block level element, and the span is the inline counterpart. They are the simplest possible form of that display type, with no other properties. In a great many cases I will give either of them the style:
display: inline-block;
This makes them behave in a very handy way. For div it means boxes that will easily sit next to each-other, while maintaining their width and height as defined. For the span I can use this to make colorful rectangles. The inline-block display is great for so many things, but I have never seen an element that starts as an inline-block without anything else going on.
Images (img) are, but they are obviously not suited for the same things as a div, they have that style, but they fulfill a different purpose.
So is there an element that I don't know of that is the quintessential inline-block, or is this left out?
And if not, why? The uses of inline-block are numerous, so it seems like there should be some element that takes that basic form.
There's no such element, and there are some good reasons why not.
inline-block has several uses in contemporary web design. However it is not part of the original design, which only includes block and inline elements. Instead it derives from <img> as added by NSCA Mosaic. (Which uses the wrong markup and helped defeat the original "responsive design". I think we've only just started to fix the problems with img).
Further down the timeline, inline-block still wasn't part of IE4 or 5, or any version of Netscape. It wasn't part of the early HTML4 era. So we wouldn't expect to find your hypothetical element in that version of the standard. inline-block only appears in CSS2, which came after HTML4. (Look at the reference section in each standard).
Unlike block, inline-block is affected by whitespace in the markup. It's implied by the name, and it's what you'd expect from looking at <img> in the middle of some text (aka wordprocessor object anchored "as character"). But beyond its origins there, the whitespace-dependent markup soon becomes very troublesome. I wouldn't expect W3C HTML5 to enshrine this in a new element.
Specifying it would certainly involve argument about "semantics", separation of content and presentation etc. (As well as what to call it :). And if the default rendering makes whitespace significant - is that not part of the semantics of that element? Consider using images to represent words - or individual letters of a word (with appropriate alt text). This illustrates that the presence of whitespace (or not) around this element would be semantically significant, just like the presenceofwhitespaceseparatingwordsissemanticallysignificant. That seems like a big problem to me.
inline-block is often promoted as a modern alternative to using float everywhere. But neither is genuinely suitable. This is why CSS3 will standardize new layout modes: "flexbox" and "grid", to support modern responsive designs with genuine, clean markup. No dummy markup (or dummy generated content). No hacking around whitespace-dependence.
The only elements I can think of that have an in-line appearance, but allow for a width and height to be set, are:
img,
input,
textarea
select, and
button
The only element here, though, that can take HTML content is the button element; which is not an ideal use of the button since it's intended to be an element with which the user might/should interact; rather than simply a container element.
While you may have multiple uses for such an element, there's no convincing reason, given the ease with which the display property might be changed, that the W3C, or any other authority, should explicitly define one; especially given that the only difference between inline and inline-block is the ability to assign dimensions and margin.
The img tag is inline-block by default:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Img
Edit: You can check this SO question: Is <img> element block level or inline level?
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/