How to get rid of unwanted space between inline-block columns? [duplicate] - css

This question already has answers here:
How to remove the space between inline/inline-block elements?
(41 answers)
Closed 7 years ago.
I'm attempting to use a css grid with widths set in % (so I can use it responsively) and without using floats (personal dislike!).
In this instance, I'm using csswizardry-grids with the appropriate variables added in. You can view the demo linked on the github page.
There is no mention of a "container" class to assign a width to the grid, so I added .container (which is also what the csswizardry-grids demo has) with a max-width (in prep for other breakpoints later). The container has left and right padding to allow for the padding:left on the .grid__item within.
.container {
margin: 0 auto;
padding: 0 $gutter;
max-width: 960px;
}
The scss:
.grid__item {
display: inline-block;
padding-left: 32px;
vertical-align: top;
width: 100%;
-webkit-box-sizing: border-box;
box-sizing: border-box;
}
.desk--one-third { width: 33.333%; }
Also note that the box-sizing:border-box is not on any other element except that which is spec'd by the csswizardry-grids.scss.
My markup:
<div class="container">
<div class="grid">
<div class="grid__item desk--one-third">
<h1>Column 1</h1>
</div>
<div class="grid__item desk--one-third">
<h1>Column 2</h1>
</div>
<div class="grid__item desk--one-third">
<h1>Column 3</h1>
</div>
</div>
</div>
The problem: in firefox, safari & chrome, the last .grid__item falls away.
What I see: a mysterious gap between '.grid__item's of at least a few pixels. See attached screenshot:
!(http://dl.getdropbox.com/u/7408773/Screen%20Shot%202013-05-10%20at%2012.51.06%20AM.png)
Can anyone shed some light on this for me please?

Whitespace between inline-block elements
It sounds like you're using display: inline-block for the columns, rather than floating them.
The problem with using inline-block for layout is that if there's any whitespace in the HTML source code between the HTML tags (in this case, the grid__item divs), there will be 3-4 pixels of horizontal spacing added between the displayed elements.
inline-block was intended for adding block content to the flow of a paragraph. The reason this spacing occurs is the same reason that 3-4 px are added between 2 words in a paragraph: It gives a series of inline elements in a paragraph the amount of spacing they're usually expected to have.
There's no CSS solution for this that's truly cross-browser and safe (though negative left margins come the closest). There are ways to edit the HTML code to prevent this (removing the whitespace between the tags in the source code), but they present maintainability issues (with a high risk of difficult-to-identify issues turning up later on when someone else works on the code), and it significantly compromises the separation of content and presentation (given that changes to the formatting of the source code can affect the formatting of the displayed pages).
Comparison of inline-block and floats
Both floats and inline-block have the disadvantage of not having been intended for general layout (e.g., creating variable-height columns in the flow of a page). It could be argued that CSS positioning and HTML tables were not intended for general layout either (or at least are not well suited for it).
The natural uses for each:
Floats: Allowing a paragraph of text to flow around an element (usually an image)
inline-block: Adding block content inside a paragraph (like an image), as part of the paragraph
CSS positioning: Overlaying one element on top of another (usually a pop-up or dropdown)
HTML tables: Data grids
Historically, each of these has been forced into use for layout, due to the lack of other options. As Eric Meyer pointed out here and here, the reason floats wound up being used for layout was because of the ability to clear a float (which allows it to be used in a wider variety of ways).
Choosing the right tool
So if neither one was intended for general layout, how do you choose the best one to use?
The strongest argument against inline-block, on the whole, is that if it were truly suitable for general layout, there wouldn't be such a fundamental issue as the 3-4 px of horizontal spacing added between elements (which is almost never desired when laying out the main regions of a page -- columns shouldn't behave the same as words in a paragraph of text).
In specific situations, a simple rule can be applied: For cases where that 3-4 px creates a problem, that indicates that the use of inline-block is inappropriate. Likewise, for cases where the 3-4 px does not create a problem, that suggests that it may be a reasonable option.
In practice, I've found floats to be far more reliable and predictable than inline-block, especially on earlier versions of IE. The main hassle with floats is having to manually clear them. Adding a reliable clearfix to the CSS file makes doing so relatively manageable though. Even on modern CSS grid systems, the preferred layout mechanism for establishing columns is typically floats (based on what I've seen so far).

This was the first link when I searched "space between inline": http://css-tricks.com/fighting-the-space-between-inline-block-elements/
tl;dr remove any spaces between your columns.

This issue is caused by inline-block elements being considered as words - so it can be simulated by giving a negative word-spacing to the wrapping element. About word-spacing: -4px; worked for me Chrome/IE9/FF :) - However - remember - this is a workaround.
HTML:
<div class="wrapper">
<div class="inliner">01</div>
<div class="inliner">01</div>
<div class="inliner">01</div>
</div>
CSS:
.inliner{ display: inline-block; }
.wrapper{ word-spacing: -4px; }

Related

Flexbox + calc() - possible bug in flexbox?

The Goal
I'm working on a flexbox + calc() based grid system with gutters in SASS.
You define your grid via mixins like so:
.box {
#include column('1/3', $gutter: 20px);
}
Compiled this will be:
.box {
width: calc(99.999999% * 1/3 - 13.33333px);
}
The Problem (please read the updates further down)
I'm trying to find a way get rid of the classic .row containers.
In my mind this should be super simple with flexbox + calc() but I have this strange bug (or an error in my caculations?) which sometimes break the layout when multiple rows should be created.
As an example: I want a grid with a 20px gutter between the columns.
The rest is best explained in code, so here's a pen:
http://codepen.io/NilsDannemann/pen/OMBVry?editors=1100
Why is the last example (1/8 - multi row) breaking?
Update #1
Okay, heres whats happening: the Problem is not rooted in the flexbox space-between property, but comes from flexbox' behavior in general.
Flexbox always sees the gutters as available space. So in the last example it combines them (7 * 20px = 140px) and concludes that there is enough space to fit another item (width after calc() = 107.5px) on the first row.
This is were the whole thing falls.
space-betweenthen does it's job as intended.
Update #2
I think the only way around that is (as #Siguza pointed out) to add margins to fill the gutters. Then use an :nth-child selector to set the last margin of a row to 0.
In SASS this would look something like this:
.box {
#include column('1/8', $gutter: 20px);
margin-right: 20px;
&:nth-child(8n) {
margin-right: 0;
}
}
Now it becomes a SASS challenge:
How do I get the :nth-child (whole number) from the passed fraction?
With some effort I have solved this. :-)
Heres the pen with the current SASS version of the grid:
http://codepen.io/NilsDannemann/pen/OMaOvX?editors=1100
Wow! This works great!
A multi-column grid with a completely clean DOM!
No .row classes or .eigth classes. Feel free to play around with the mixin (change the fraction or the gutter).
Heres the sad part though:
Try uneven grids like this:
.box1 {
#include column('2/8', $gutter: 20px);;
}
.box2 {
#include column('4/8', $gutter: 20px);;
}
.box3 {
#include column('2/8', $gutter: 20px);;
}
Now the :nth-child is wrong and the whole thing breaks. :-(
If we can solve this (without introducing another variable to the mixin) we would have one of the cleanest any intuitive grids I have seen to date. But this last problem is a tough one.
I'm not sure if it can be done at all.
Any SASS-Genius out there to help?
The problem boils down to the definition of justify-content: space-between.
8.2. Axis Alignment: the justify-content property
The justify-content property aligns flex items along the main axis
of the current line of the flex container.
space-between
Flex items are evenly distributed in the line.
source:
https://www.w3.org/TR/css-flexbox-1/#justify-content-property
So, in your code, flex items will align per the rules of space-between, even when they wrap.
Extra space will be distributed differently depending on how many flex items exist on the line.
In your example illustrating the problem, you have nine flex items on the first row, and seven flex items on the second row. The second row has more extra space to distribute. Hence, the gutters are wider.
There are a total of 16 flex items in that container. Add two more, and everything aligns perfectly.
Revised Codepen
A few more considerations:
Flexbox is not built to serve as a grid system. The W3C is developing the CSS Grid Layout Module for this purpose.
Instead of width for defining the size of your flex items, consider using the flex property, which will enable you to control the width, as well as the flex-grow and flex-shrink factors.
Although it doesn't seem to be causing a problem in the codepen, using line comment syntax (\\ comments) is invalid in CSS and has the potential to break your code. It's safer to use the standard CSS commenting method (/* comments */). More details here: https://stackoverflow.com/a/34799134/3597276
The core issue seems to be that space-between doesn't like multiline:
#a
{
display: flex;
width: 190px;
border: solid 1px #999;
flex-wrap: wrap;
justify-content: space-between;
}
#a > div
{
height: 30px;
width: 50px;
background: #EFE;
border: solid 1px #EEE;
}
<div id="a">
<div></div>
<div></div>
<div></div>
<div></div>
</div>
This would also happen with your 1/4 boxes, if a fifth box could fit on the first row, and it does indeed happen if you make your browser window extremely narrow.
But believe that this is seen as a feature rather than a bug:
Flexbox tries to fit as many items as possible in a row.
(But I have no source to confirm this.)
What I do have though, is a workaround.
It's a little ugly, but you can give .box a margin-right of 20px, and then take it off again every 4th .fourth box, every 8th .eight, and so on, using :nth-child():
.box {
background: #eee;
text-align: center;
padding: 20px;
margin-right: 20px;
}
// Widths: 1/4
.box.fourth {
width: calc(100% * 1/4 - (20px - 20px * 1/4));
}
.box.fourth:nth-child(4n) {
margin-right: 0;
}
// Widths: 1/8
.box.eigth {
width: calc(100% * 1/8 - (20px - 20px * 1/8));
}
.box.eigth:nth-child(8n) {
margin-right: 0;
}
[ Updated Pen ]
TL;DR flexbox is overhyped garbage and here's a grid that kind of solves this unsolvable problem.
Any SASS-Genius out there to help?
Hi. I wouldn't consider myself a "genius of Sass" or anything. I know it pretty well, but Hugo and a few others have that title.
I have been called a "grid master" by a few people. It's pretty much the only thing in life I'm good at.
I made Jeet and Lost and have literally spent hundreds of hours fighting with what you're fighting with now. It haunts me. I wake up in the morning thinking about this problem and go to bed at night thinking about this problem. I've done this for years.
Flexbox won't save you on this one. In fact, the whole "flexbox will save grid systems" meme is really sad to witness because it just doesn't have the power to be any more useful than non-flexbox CSS.
Your original problem, as Michael_B pointed out, is that you're trying to use space-between. This will never work unless you have a very specific number of elements on every line. It isn't practical to expect anyone to always have x number of elements on every line.
Then you moved onto the whole "tons of markup" (a la Bootstrap) vs. margin-right grids and it seems like you opted for the margin-right grids. I tend to lean towards these as well because I care about what my markup looks like. Bootstrap grids get confusing quickly and I've worked on countless teams where some dev went to add something and screwed up the grid by forgetting a row or trying to nest something other than a column in a row. No one notices it at first, but then out of the blue you'll see an entire chunk of the site is offset by 15px or so. Rewriting it can be a pain. I've even seen this a few times by self-proclaimed Bootstrap experts on ThemeForest.
<!-- Bootstrap markup -->
<div class="container">
<div class="row">
<div class="col-md-6">1</div>
<div class="col-md-6">
<div class="row">
<div class="col-md-6">1a</div>
<div class="col-md-6">
<div class="row">
<div class="col-md-6">1b</div>
<div class="col-md-6">2b</div>
</div>
</div>
</div>
</div>
</div>
</div>
<!-- Margin-right grid markup -->
<div class="row">
<div class="col-6">1</div>
<div class="col-6">
<div class="col-6">1a</div>
<div class="col-6">
<div class="col-6">1b</div>
<div class="col-6">2b</div>
</div>
</div>
</div>
https://youtu.be/ueZ6tvqhk8U?t=18
The downside to margin-right grids is you need to get rid of the last element in a row's margin-right, which can be tricky, especially for preprocessors. This can be done by forcing the user to specify what element they want as their last one, but that introduces a whole new range of problems when you're dealing with uneven grids.
For instance, if I make a mixin that removes the margin-right from every 3rd element, but I want an assortment of sizes and shapes for my elements inside my grid, then I'm totally screwed. The only way I've found to mitigate this somewhat rare problem is to use disgusting Bootstrap markup.
This is the point where you go back to the flexbox wishing well and come up empty handed.
A week or so ago I decided to see if the Bootstrap/Foundation folks were interested in a grid that wasn't built on a markup house of cards. They declined but I put a decent amount of work into what I think is the best solution to this problem.
Here's the any-size elements with no extra markup grid Bootstrap and Foundation shot down: http://codepen.io/corysimmons/pen/MKzPWW?editors=1100
Anyway, if you like grids, stay tuned for my next big grid system set to launch early next month (I'll spam it on reddit and Hacker News). It doesn't solve this particular problem, but it will be pretty revolutionary.
If anyone is as obsessed with solving this problem as I am, I would love to chat with you about it. I'm sure I haven't thought of everything and there's some clever bastard out there just sitting on the answer.

Why bootstrap uses floating elements to construct Grid System? [duplicate]

I was tinkering with custom grid and wanted to see how other people have created their grid-systems. Since twitter's bootstrap seemed to be so popular i've looked at its code. Now i wonder why are they using floats? I would use display: inline-block; html elements have either display: inline; or display: block; i would try to avoid floats. But for some reason bootstrap creators decided to use floats. first i was thinking they used them to have backward compatibility since ie6 does not support display: inline-block; and ie7 supports it only on elements with display: inline; by default. But ie6 more or less out of the game and since they use micro clearfix hack which uses *zoom: 1; to target ie6+ IMO they could replicate the same display: inline-block; with *display: inline; *zoom: 1; So the final Question Why Floats Over Display Inline Block? Are there any issues they tried to solve i didn't mentioned above?
Inline blocks are white-space aware, have an auto width of the actual content and stacks in the order they have in HTML. Floats aren't but require a clearfix method and are based on block elements. These elements have auto width on the available space horizontally. Purely semantically, inline-blocks are less semantic since the white-space aware format and importance of order. But looking at it purely in a functional way, both just aren't made for a grid. And if it wasn't for pseudo CSS, we would have un-semantic HTML tag clearfixe's as well. So in my believes they are both not winners. But there is no alternative for the time being when flexbox will become mandatory in upcoming years.
With inline blocks:
<div>
<div style="display:inline-block; width:30%;">col1
</div><div style="display:inline-block; width:70%;">col2</div>
</div>
Tags must be glued together/appended, to dismiss any gutter. The container div is necessary to force the items being part of a separate row.
With floats:
<div class="clearfix">
<div style="float:left; width:30%;">col1</div>
<div style="float:left; width:70%;">col2</div>
</div>
Clearfix is necessary to force a "row" (dismiss any normal flow items issues or floats after the floats)
Whether use one or the other is a matter of your goal (and taste). I must say I like inline-blocks more than floats, as long as you know the both of the col widths or use relative sizing (%). I thinks it's more intuitive and predictable than floats with clearfix, a fix" for issues that aren't even issues if it was used by how it should be used. Only the white-space awareness of inline blocks force you to use some funky html, that's a downside.
Ironically, tables do exactly all this (and even col-heights and vertically alignement's) without any issues. Since inline-blocks have to be placed in order, there's an motive for discussing here.
If we are talking about responsive, table 'loses' of inline-blocks. Let say you have 4 cols on a desktop and you want 2 cols on a tablet and 1 on a mobile. With inline blocks, you 'just' give the cols other width dimensions and they hopefully wrap nice (be aware of margins as they collapse). With tables, you're bound to actual rows, which can be quite stubborn. Flexbox is needed for a long time and looks beautiful. You can adjust the layout flexible on certain circumstances.
Bootstrap can be handy to learn how they did something. Just read in 3.0 they are using relative grid sizing. Which gives an issue with nested grids and aligning.
---- --a- ---- ----
---b------
.... ..c.
Col a is a normal parent col. Col c is a child nested col of b. It's hard to align c with a with relative sizing since the gutter is variable to the container, unless you're using padding and border-box model. But that way you lose a lot of flexibility. When you want the col to have some background and padding, you're messing up the grid system, so you have to use container which you style, which would clutter the code. I haven't studied if they found a solution to this. I haven't yet. I went to fixed pixels, but that means in responsive design you can only have a few fixed width's and for everything around mobile use a relative grid.
I prefer grid systems that use display: inline-block; rather than float, such as Pure (formerly Yahoo YUI Grid), because they internationalise without extra styles; change the text direction to right-to-left and the layout automatically reverses; floats don't do this. Floats also introduce the need to clear and other cross browser oddities. Any inaccuracies that inline-block may have over float can be remedied, as demonstrated by Pure. As to the criticism that display: inline-block; is not meant to be used for layout, perhaps the use of display: table; should also be banned for cross-browser centring. I would also question whether the term Semantic Web really applies to CSS since the term is primarily concerned with HTML and using its elements and attributes to impart machine readable meaning; the whole point of CSS is to style semantic HTML as radically as one wants to, hence classic sites like CSS Zen Garden.
I say that as long as the technique is not exploiting a bug, is not obstructing content to users and devices and is sufficiently supported then it is acceptable. There is no reason that one can't use CSS in unorthodox, but supported, ways, just like Stu Nicholls' CSSPlay.
Interestingly, Flexible Box is also incorporated into Pure grids, a superior layout system compatible with modern browsers (≥IE10 and equivalent browsers).
In the term of semantic web, the display: inline-block should be used when we want to place a block level element like <img> within line(s) of text. We shouldn't use inline placement for making the pages main layout. The element with display: inline-block also takes effect from properties like font-size and line-height of parent element. This will decrease the accuracy of page layout.
You would better get in the habit of using float instead of inline-block when making the page main layout.

Do inline-block divs work when printing?

I have a pretty complex single-page application for managing data. Among other things, it of course needs to be able to print that data. For the most part I have my hands around what does and doesn't actually work when printing from the browser, and the tricks you can play in CSS using the #page directive.
I hit a problem last week that I'm finding a bit mystifying, though. I'm trying to print data onto cardstock forms -- for example, printing name badges on cardstock that might be 2 columns by 4 rows per page. I'm trying to do this using fixed-side divs, where the div's CSS looks something like this:
.badge {
display: inline-block;
width: 3.5in;
height: 2.5in;
}
That displays fine on-screen, but when I go to print it, it is coming out with each badge on a separate line -- the divs don't seem to be inlining properly. Margins are minimal, so I don't think that's the issue.
I'm at a loss here. Does fixed-size inline-block not work when printing? I'm using Chrome, if that's relevant. I am hoping that's it's possible to make this work without, eg, resorting to generating the pages as PDF on the server.
This should work:
<style>
.container {
width: 7in; /* This guarantees there will be enough room for 2 badges side-by-side */
}
.badge {
box-sizing: border-box; /* You only need this if you add padding or borders */
display: inline-block;
width: 3.5in;
height: 2.5in;
}
</style>
<div class="container">
<div class="badge">
Badge 1
</div><div class="badge"> <!-- DO NOT put line breaks between the badge divs! -->
Badge 2
</div><div class="badge">
Badge 3
</div><div class="badge">
Badge 4
</div>
</div>
In short, the 7in wide container div guarantees you'll have enough width to fit two badges side-by-side. Also, there are no line breaks between the badge divs, because line breaks would turn into spaces, which would prevent the badges from fitting beside eachother. Finally, I added box-sizing: border-box to the badge CSS to ensure that the width won't exceed 3.5in if you add borders or padding.
The number of depends on your screen size.
so when the resolution of the screen change or the printed page has another size, The number of rows and columns.
so i suggest to you to use % as unit instead of in to re-size width and height or make an css style for each resolution. Or you can Use the HTML table tag.
Because the inline-block Just treats the element like other "inline elements" and allows the use of block properties. it does not precise how many column and row.

How can a URL fragment affect a CSS layout?

Compare these 3 URLs (look at the top navigation bar in each case):
http://fast.kirkdesigns.co.uk/blog
as above but with the url fragment #navigation
as above but with the url fragment #node-2655
Note, that the only difference is the URL fragment on the end.
The first two pages display absolutely fine (in Firefox at least). It's the third one where the problem lies. The fragment #node-2655 pushes the top navbar off the top of the screen. When you then scroll back up to the top of the page, the navbar has been cut in half. This happens when using any URL fragment that causes the navbar to be out of the initial viewport when the page is first loaded.
So, how can using a url fragment affect the css layout like this?!
THE SOLUTION:
as suggested below, removing the overflow: hidden on the container element that held the navbar fixed the problem. I'd love to understand why though!
Remove the overflow:hidden on #main in css_75afd7072eaf4096aaebf60674218e31.css
I'd say it's a rendering bug in FireFox as it's fine in Opera. There shouldn't be anyway an anchor would change the CSS like you say (unless you are using jQuery or something).
I am having this problem too, and think I can see what is happening.
The "column" block with the massive (5678 pixel) margin and padding makes that block very tall. In browsers other than Firefox, the positive and negative values cancel each other out, but FF really does make it that tall - kind of.
FF also knows the two cancel each other out, but seems to look at the 5678px padding and decides the column block is poking out the bottom of the #wrapper block. This is overflow - and with overflow set to auto on #wrapper, you see the true size of #wrapper with a scroll-bar down the side.
With overflow set to hidden, FF takes away the scrollbar, but still seems to scroll the contents of #wrapper so that the item the fragment points to is at the top of the page. This is normal behaviour for fragment links in scrollable blocks, but since there is no scrollbar, you cannot scroll the content back down again, hence it looks like the layout has been effected by the fragment.
So in short, I suspect that FF is operating an invisible scrollbar in this example. That could be considered a bug, but it is probably correct behaviour. Being able to scroll the content up and down inside a non-overflowed fixed-sized block using URL fragments, is a technique that can be used effectively to implement image "sliders" that work even in the absence of JavaScript.
Hope that helps. This has been puzzling me for years, and this explanation suddenly struck me out the blue. My current workaround for this is to use jQuery "scroll to" plugin to scroll the whole page down to the fragment, as this seems to prevent the contents of #wrapper from scrolling internally.
You can also take "display: hidden" off #wrapper, but your page then ends up half a mile long.
I'll just point out that there may be some weird inheritance from the 30+ stylesheets linked to in the head. There may not, either, and it's probably a rendering bug (possibly related to :target styling) that Dan suggested. I just felt it worth pointing out that if you've got more than thirty stylesheets, you likely to start seeing some weirdness, whatever else might happens.
The reason is the column with the large padding has expanded it's container, but the expansion is then hidden but overflow:hidden; but with the use of the fragment it is being scrolled into the position of the fragment, effectively chopping off anything above that. You can use javascript and set scrollTop to 0 and it scroll it back to the normal position.
Basically a wierd edge case which browsers do not seem to handle very well.
Sorry this isn't an "answer," tho it is a response to the other comments here. This problem is just flabbergasting. It is very easy to isolate (i.e., has nothing to do with number of stylesheets), and doesn't have a proper "solution," as there is no way to achieve the desired rendering.
<!DOCTYPE html>
<html>
<head>
<style>
#container {
margin: 1em auto;
width: 40em;
}
#wrapper {
overflow: hidden;
position: relative;
}
#c1 {background-color: #aaf;}
#c2 {background-color: #ccf;}
.column {
float: left;
margin-bottom: -5678px;
padding-bottom: 5678px;
width: 50%;
}
#footer {
background-color: #eee;
padding: 1px;
text-align: center;
}
p {margin: 1em;}
</style>
</head>
<body>
<div id="container">
<div id="wrapper">
<div id="c1" class="column">
<p>This is some content in a short column. We would need some Javascript to change its height if we wanted a different background color for each column to stretch the full height of the respective columns...or we can use large padding together with an equal negative margin.</p>
<ul>
<li>Jump to P1</li>
<li>Jump to P2</li>
<li>Jump to P3</li>
</ul>
</div>
<div id="c2" class="column">
<p id="p1">The desired effect is to have the height of the two columns appear the same. We use 'overflow:hidden' on the containing div (#wrapper) to wrap it around the floated columns.</p>
<p id="p2">These paragraphs have fragment identifiers. Problem comes in when clicking one of the links on the left. Instead of scrolling just the page, the browser scrolls the div with 'overflow:hidden' so the target is at the top. It does this even if the target is already visible.</p>
<p id="p3">Opera does not exhibit this behavior. This occurs in Chrome/Safari, Firefox, and IE. (Interestingly, IE also works as expected if we completely remove the DOCTYPE declaration.)</p>
</div>
</div>
<div id="footer">
<p>Footer stuff.</p>
<p>To see why 'overflow: hidden' (or any other piece of the CSS) is needed, just try disabling it.</p>
</div>
</div>
</body>
</html>
Just as a side-note, the above technique is generally used to provide flexible-width mulit-column layouts. This is probably becoming less important these days as fixed-width layouts are becoming a lot more comment - browsers are able to magnify the web page to see small text, and fixed-width makes it a lot easier to control the typography of a page, e.g. set the width (in ems) to display the ideal nine words per line regardless of what font size and magnification the user chooses.
Sorry if that does not sound like an answer, but it is basically suggesting to discard this old model and consider moving to fixed-width columns (which is a whole new subject).
I was able to solve this with some javascript to scroll the body to the position the overflow hidden element was scrolled to.
setTimeout(() => {
let intendedScroll = document.getElementById("fragmentfix").scrollTop;
document.getElementById("fragmentfix").scrollTop = 0;
window.scrollTo(0, intendedScroll);
}, 0)

Is there a 0-width way to prevent floated divs from collapsing

First, this issue is not about block elements collapsing when their children are floated. In fact the issue has nothing to do with clearing at all.
The issue is this. Suppose I have a series of floated divs like:
<div class="column">Column 1</div>
<div class="column"></div>
<div class="column">Column 3</div>
With css:
div.column { float: left; width: 200px; }
The middle column will collapse in recent versions of Firefox and Safari, although apparently not IE7. What I want is the IE7 behavior.
I realize I can add an and it will hold the div open, but that doesn't work for me in this case because I also have have a declaration like this:
div.column input { width: 100% }
I have a series of columns layed in a table-like format, with certain conditions causing the input fields to disappear. The problem is when the input disappears the field collapses. If I add an it causes the div to wrap. Just to head off the initial questions:
Why don't I use a table instead? Because I'm using Scriptaculous Sortable to drag and drop rows, which doesn't work with tables
Why don't I use a shorter pixel width to leave room for an ? Because width: 100% is more accurate across browsers.
Why don't I add a when I hide the input I may end up resorting to this, but it would be kind of ugly in the JS, so I'm hoping for a better way.
Does anyone have any clever hacks here? Since both Safari and Firefox behave this way I assume this is officially sanctioned behavior. Where is this discussed in the W3C specs?
Eh? Shouldn't you just give it a random height? Can you show a demo?

Resources