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.
Related
Atm I'm doing my first attempt at a website, recently got a new job which requires me to learn some basic HTML&CSS so for a starters I set myself up to duplicate an exsisting site.
The question/problem is:
I wanna make 3 columns at 100% height, the left and right being scaleable to 0 upon downsizing the browserwindow, while the middle column is containing the actual content of the site, min-width at 60%. At lower resolutions im planning on implementing media-things in my css to remove the left n right columns when the resolution goes below a certaint limit.
I've set html&body&all to hight & width 100%.
I'm trying to do something a bit like here: The site im trying to duplicate
My current attempt can be found here: My attempt
Some code for the lazy ones that don't wanna inspect the site:
<div id=all>
<div id=leftmargin></div>
<div id=wrapper>
<div id=header></div>
<div id=nav></div>
<div id=content></div>
<div id=rightmargin></div>
</div>
</div>
Since im very new to web development, please excuse me if you need more info.
My problem is in essence that "leftmargin' and 'rightmargin' overlaps the 'wrapper'-div. I'd very much like that to be in the center of the page and then make the margin-divs 'expendable' at lower resolution by css.
I hope I made myself relatively clear, thanks in advance.
Kind regards
Mike
I'd avoid using a div for the sole purpose of creating a margin space. Instead, let your side bar content create the margin you're looking for. The content is overlapping the margin because it's not contained within the margin div. You'll need to tweak how the main content is centered by using "margin-left: " the same size as the sidebars or some other way, but it'll improve your overall structure.
As for text overlapping the container at small sizes, remove the "width: 18.8%;" and "white-space: nowrap;" from #lefttop and "max-width: 18.8%;" from #leftnav. This will let the text be the full width of the gray container on the left, and the words will wrap if the line doesn't fit.
Finally, to get rid of the side bars at small widths, as jerrylow recommended, use
/* screen sizes smaller than 750px apply these styles */
#media screen and (max-width: 750px) {
#leftnavwrap {
display: none;
}
#shortcut {
display: none;
}
#content {
width: 100%;
}
}
I am currently developing a site and have encountered a strange problem with getting two of my divs to stay on the same line. The page in question is here: http://bit.ly/13QE7Zi and the divs I'm trying to fix are the text div in the middle and the small image beside it. In the CSS, I have these divs set to take up 1000px (20+640+20+300+20) which is the width of the container element, but if I do this, the second div gets pushed onto the next line. It only works if I decrease the width of the text div by 3 px, which is undesirable because then the edge of the image is not aligned with the right side of the page properly. This occurs in Chrome and Firefox. I'd prefer not to use floats because that breaks other aspects of the page. How do I get these two divs to stay on the same line and still fill the full 1000px of width?
The reason this is happening is because you have a 'space' character between your two inline blocks.
HTML doesn't really ignore all white space. You can have 1000 spaces and new lines between two elements and HTML would condense all those down into 1 single space when displaying.
Your inline blocks are setup in such a way that they there widths add up to be exactly 1000px, however you have a new line in between your two containing elements which condenses down to 1 space. Your precise measurement doesn't account for this extra space and so your inline blocks wrap to the next line.
Instead of decreasing your text's width by 3 px, decrease the padding-right on .looktrai-text it won't change the way it looks but will give enough room for both to fit.
You can use border-box box-sizing. That way the width of the elements will include the padding and the borders.
You can simplify your code, and even implement text wrapping around the image by doing the following.
Disclaimer: This is a suggestion based on the results you are trying to achieve.
Remove the .looktrai-text and .looktrai-sidediv divs
Format the HTML inside of #looktrai-content like this:
<div id="looktrai-content" class="clear">
<img src="content/looktrai_side.jpg" alt="" class="align-right" />
<p>My paragraph text</p>
<p>My second paragraph</p>
</div>
Add the following CSS:
img.align-right {
float: right;
margin: 0 20px 20px;
}
The result will look something like this: http://codepen.io/anon/pen/yjdxh
This is a cleaner, simpler approach that allows you to reduce code, and maximize flexibility.
I would use float: left for the text div, and float: right for the image div and remove the display: inline-block property. This creates a clearing issue for the footer, but this is easily fixed using one of the many 'clearfix' hacks. My preferred method is using a .group class on the parent container div, as per this article on CSS Tricks. In your case this would be <div id="looktrai-content" class="group">
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; }
I'm building a site which makes use of the popular 960.gs 16 column grid system. Here's a screenshot of the relevant part of the design, with the grid columns overlaid on top:
The issue is the white "popular right now" box. Since this has a white background, I want some padding inside the box. Simple enough: I added a <div> inside the parent one and styled it appropriately with padding: 10px and a white background.
The problem comes when I try to re-use the grid inside an 'inner' <div> like this. for example, inside that white box, I want the link list to be inside a 5 column container, and the image in a 3 column container (sorry, the screenshot doesn't show it at this size).
I tried redefining my grid column sizes inside the .inner class, which partly works - I removed 10 pixels from each column size, since the total width needs to be 20px less than before to account for the margins. This works in the case where there are exactly two child <div>s inside the .inner container, but obviously if there are more or less than 2 then things start to look wrong.
Does anybody have a good strategy for dealing with this kind of thing? I'd be willing to just put the padding on all columns, regardless of background colour, but couldn't get this working like I wanted when hacking the grid.
thanks
Matt
the 960gs has an .alpha and .omega class for allowing nesting. Usually this removes the leading 10px and trailing 10px margin from the elements you apply it to. You might be able to reverse these and misuse them to give you the padding you need - the overall column widths would add up, but the padding would be on the "wrong" side
<div class="container_12">
<div class="grid_12">
<div class="grid_5 omega">...</div>
<div class="grid_3 alpha">...</div>
</div>
</div>
I haven't tested this though so not sure that it would work
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)