http://forums.animefushigi.com/showthread.php?161-Poll-Test
I want to switch the position of "Vote Now" and "View Poll" Results buttons
I'm having trouble figuring how what css to change to do this
edit oh sorry, you can Login with Test / test
you can use css
float:left; / float:right;
I think it's a mild misconception than CSS can switch positions of elements arbitrarily. It all depends on the design of the layout and its accompanying HTML.
Seeing your HTML will help!
If you knew the widths of side-by-side elements, you can position them but that's not very robust if the layout is fluid or different browser vendors or settings influence the elements widths. Positioning can lead to nasty overlapping elements.
Floating your buttons within their container may be an option, e.g. if the buttons are float:left, they will be in their original order. If they are float:right, their order will be reversed. Their container will need to be floated too probably. I'd need to see the HTML to explain it with confidence.
Related
The HTML below specifies a button and a div that have identical class and contents.
<div class="root"><!--
--><button class="outer"><div class="middle"><div class="inner">label</div></div></button><!--
--><div class="outer"><div class="middle"><div class="inner">label</div></div></div ><!--
--></div>
In this example, I have explicitly set every CSS property1 for the classes outer, middle, and inner2.
This means that both the button.outer and div.outer sub-trees of the DOM should have completely identical CSS settings. Presumably, as well, no CSS properties for these elements are getting their values from anywhere else besides the provided stylesheet.
As the example shows, the side-by-side button and div look quite different. Specifically, in the button, the label appears at the bottom of the element, whereas in the div it is vertically centered. (The label is centered horizontally in both cases. Also, note that all the classes have the setting vertical-align: middle.)
I have observed this difference with all the browsers I've tested so far (Chrome and Firefox).
Since there is no difference in the stylesheet settings for the button.outer and div.outer elements, and their descendants, I figure that the difference in their appearance is due to some CSS property with a value (such as auto or normal) that gets interpreted differently by the browser depending on the whether the context is a button or a div element.
My immediate goal here is to understand sufficiently well why the button and the div are being rendered differently so that I can adjust the CSS intelligently.
My longer term goal is to make CSS coding more predictable. Currently I find that my CSS is completely unstable due to gross inconsistencies like the one shown in the example.
My question is:
how can the difference in appearance between the button and the div be explained?
1 As reported by Chrome's devtool.
2 I took the vast majority of the values for these settings from Chrome's devtool's listings. The point was to ensure that both the button and the div elements had the same setting (whatever it may be) for each CSS property.
This is likely due to different meanings for the value of auto for the position of elements inside of a button. If you expand the size of a div, the content by default will be in the top-left corner. If you do the same for a button, the content will be centered horizontally and vertically.
Since the button's top and left values for auto is to be centered and not in the top left corner, you can reset top and left to always act like a typical div would. These are the properties to change on .middle:
.middle {
top: 0;
left: 0;
}
Here's the forked JSFiddle with those changes to .middle.
Different elements have different default settings. There is an enormous amount of CSS in your demos, and it's largely overkill and very hard to determine where exactly the differences in rendering are coming from.
Have you tried a CSS reset instead? These will resolve most of the discrepancies between elements and browsers, giving you a blank slate to add your own styles.
how can I determine the property (or properties) that account for the difference in appearance between the button and the div?
By clicking through them one by one and toggling them on and off in Dev Tools. If you turn off position:absolute on the middle class, you'll see what you're probably expecting in layout. I found this by clicking through all the properties in the Elements > Styles panel. See:
https://jsfiddle.net/vfdd9p8L/
This is probably a bug that you're encountering. Browsers have lots of them! By layering on so many styles at once, you're probably backing into a weird corner case with respect to the layout algorithms. To isolate the bug for help and/or reporting, try to create a reduced test case, which creates an unexpected discrepancy, but using the minimal number of elements and declarations.
(Also note that your fiddle is including jQuery CSS, which includes Normalize, which is a whole other layer of styling.)
Normally, when we want to have multiple DIVs in a row we would use float: left, but now I discovered the trick of display:inline-block
Example link here.
It seems to me that display:inline-block is a better way to align DIVs in a row, but are there any drawbacks? Why is this approach less popular then the float trick?
In 3 words: inline-block is better.
Inline Block
The only drawback to the display: inline-block approach is that in IE7 and below an element can only be displayed inline-block if it was already inline by default. What this means is that instead of using a <div> element you have to use a <span> element. It's not really a huge drawback at all because semantically a <div> is for dividing the page while a <span> is just for covering a span of a page, so there's not a huge semantic difference. A huge benefit of display:inline-block is that when other developers are maintaining your code at a later point, it is much more obvious what display:inline-block and text-align:right is trying to accomplish than a float:left or float:right statement. My favorite benefit of the inline-block approach is that it's easy to use vertical-align: middle, line-height and text-align: center to perfectly center the elements, in a way that is intuitive. I found a great blog post on how to implement cross-browser inline-block, on the Mozilla blog. Here is the browser compatibility.
Float
The reason that using the float method is not suited for layout of your page is because the float CSS property was originally intended only to have text wrap around an image (magazine style) and is, by design, not best suited for general page layout purposes. When changing floated elements later, sometimes you will have positioning issues because they are not in the page flow. Another disadvantage is that it generally requires a clearfix otherwise it may break aspects of the page. The clearfix requires adding an element after the floated elements to stop their parent from collapsing around them which crosses the semantic line between separating style from content and is thus an anti-pattern in web development.
Any white space problems mentioned in the link above could easily be fixed with the white-space CSS property.
Edit:
SitePoint is a very credible source for web design advice and they seem to have the same opinion that I do:
If you’re new to CSS layouts, you’d be forgiven for thinking that
using CSS floats in imaginative ways is the height of skill. If you
have consumed as many CSS layout tutorials as you can find, you might
suppose that mastering floats is a rite of passage. You’ll be dazzled
by the ingenuity, astounded by the complexity, and you’ll gain a sense
of achievement when you finally understand how floats work.
Don’t be fooled. You’re being brainwashed.
http://www.sitepoint.com/give-floats-the-flick-in-css-layouts/
2015 Update - Flexbox is a good alternative for modern browsers:
.container {
display: flex; /* or inline-flex */
}
.item {
flex: none | [ <'flex-grow'> <'flex-shrink'>? || <'flex-basis'> ]
}
More info
Dec 21, 2016 Update
Bootstrap 4 is removing support for IE9, and thus is getting rid of floats from rows and going full Flexbox.
Pull request #21389
While I agree that in general inline-block is better, there's one extra thing to take into account if you're using percentage widths to create a responsive grid (or if you want pixel-perfect widths):
If you're using inline-block for grids that total 100% or near to 100% width, you need to make sure your HTML markup contains no white space between columns.
With floats, this is not something you need to worry about - the columns float over any whitespace or other content between columns. This question's answers have some good tips on ways to remove HTML whitespace without making your code ugly.
If for any reason you can't control the HTML markup (e.g. a restrictive CMS), you can try the tricks described here, or you might need to compromise and use floats instead of inline-block. There are also ugly CSS tricks that should only be used in extreme circumstances, like font-size:0; on the column container then reapply font size within each column.
For example:
Here's a 3-column grid of 33.3% width with float: left. It "just works" (but for the wrapper needing to be cleared).
Here's the exact same grid, with inline-block. The whitespace between blocks creates a fixed-width space which pushes the total width beyond 100%, breaking the layout and causing the last column to drop down a line.
Here' s the same grid, with inline-block and no whitespace between columns in the HTML. It "just works" again - but the HTML is uglier and your CMS might force some kind of prettification or indenting to its HTML output making this difficult to achieve in reality.
If you want to align the div with pixel accurate, then use float. inline-block seems to always requires you to chop off a few pixels (at least in IE)
You can find answer in depth here.
But in general with float you need to be aware and take care of the surrounding elements and inline-block simple way to line elements.
Thanks
There is one characteristic about inline-block which may not be straight-forward though. That is that the default value for vertical-align in CSS is baseline. This may cause some unexpected alignment behavior. Look at this article.
http://www.brunildo.org/test/inline-block.html
Instead, when you do a float:left, the divs are independent of each other and you can align them using margin easily.
First up, for extreme clarity, here a JS fiddle demonstrating what I'm trying to achieve:
http://jsfiddle.net/bb_matt/VsH7X/
Here's the explanation - my rationale:
I'm creating a responsive site using the 1140 grid framework.
It's a fairly complex layout.
I've created a re-usable simple gallery class which can drop into any defined column size & using media queries, I apply relevant percentage widths to the li elements.
Each of the li elements has a right margin of 5%.
I'm using nth-child(xn+x) in the media queries to remove the right margin at the end of each row.
Everything works well - images resize as the layout resizes, the number of gallery items in a row work as I've defined based on percentages.
The only remaining issue to fix is to clear between rows.
I can't add additional html markup and I want to steer clear of overly complex jquery fixes.
I know of two ways to fix this, but I'm not keen on either of them.
First fix, simply using display: inline-block on the li elements, with a vertical align of top, would flow everything correctly... however, all the percentages get shot and the gallery items no longer neatly fit in the allocated space.
Second fix, give the list items a height. This is the route I will go down if necessary - it will require a different height depending on the resolution - no big deal, but not as neat.
I updated your fiddle here: http://jsfiddle.net/VsH7X/5/
I added a clear: left to the first item in each new row.
ul.gallery li:nth-child(5n+6) {
clear: left;
}
Keep in mind that the :nth-child pseudo class does not work in IE6-8, or FF3 and under.
But I am not really sure whether the idea is that I put one <div class="container"> around my whole page, or whether I should nest them. I think I see both in various examples.
Anywhere you want a div that is centered with a width of 940px. It is also used in the navbar to position elements. There are no hard and fast rules.
If it was only meant to be used once they would have given it an id instead of a class
I've been trying to figure out the same thing -- I think the idea is that .container is intended to be a fixed width div -- 940px in the default css -- whereas .container-fluid is, well, fluid. At least that's what I've sussed from looking at the css and the (sparse) documentation.
So I'm inspecting this site: http://www.grittirollo.it/ and it appears that the content that slides out has a fixed height. Is there no way to set this dynamically?
It appears as though the developer measured out how tall each portion of the sliders' box model would be when rendered, and then multiplied it by how many rows there were. From there, he/she set it manually in the CSS.
Elements on a webpage can typically be measured with their scrollHeight JavaScript property (element.scrollHeight) however some browsers don't have this and some browsers do it differently from others. (I believe Firefox's has to be done recursively down the tree of elements and Safari just uses the outermost element.) This should be possible without manually setting the height using JavaScript, you just may have to conditionally code it to work with all the browsers you want to support.
I don't see why it's necessary to set it dynamically. If the stuff is float:left; and they put a <div class="clear"> at the bottom of a hide-able section, you would be able to see the contents of that section when it was un-hidden with JavaScript. You could then adjust the layout with padding and margin to make it look pretty.
Or, they could have also used position:relative; and position:absolute; to layout the hide-able sections. It comes down to preference.