I'm making a dashboard using SVG-based charts. When I print the page, the charts move around to prevent page breaks from happening within them. This is undesirable and breaks my layout but I cannot figure out what is causing it.
Example:
Plunker
Pop out preview
Print (just look at preview, don't actually have to print)
Result: 2 full boxes per page with uneven margins
Expected: 2.5ish boxes per page with even margins
Any help would be greatly appreciated
EDIT: Here is a gallery of what I'm talking about. Apparently this issue does not affect all browsers/Operating systems?
It's not possible.
According to http://www.w3.org/TR/CSS2/page.html#allowed-page-breaks, these are the only cases in which an element can break between pages:
In the normal flow, page breaks can occur at the following places:
In the vertical margin between block-level boxes. When an unforced page break occurs here, the used values of the relevant 'margin-top'
and 'margin-bottom' properties are set to '0'. When a forced page
break occurs here, the used value of the relevant 'margin-bottom'
property is set to '0'; the relevant 'margin-top' used value may
either be set to '0' or retained.
Between line boxes inside a block container box.
Between the content edge of a block container box and the outer edges of its child content (margin edges of block-level children or
line box edges for inline-level children) if there is a (non-zero) gap
between them.
You want (2), and you are getting (1).
The problem is that <svg> elements are replaced content.
And according to http://www.w3.org/TR/CSS2/visuren.html#block-boxes, replaced elements aren't block container boxes:
Except for table boxes, which are described in a later chapter, and
replaced elements, a block-level box is also a block container box.
That means that <svg> doesn't fulfill (2), so you can't get what you want.
I worked it around by applying position: absolute to parent container.
Related
I have a set of nested HTML, elements that are made up of a parent (AssetContainer) and two main nested parts (MediaViewContainer & AssetDetailsContainer) that are side by side. The right side component (AssetDetailsContainer) has a couple of sub-divs, but they have no styling of their own.
My issue is that the right side component is not rendering at the size it is styled to. The AssetDetailsContainer CSS sets a width of 600px, and this appears in the inspector, but then a different, much smaller value is used to actually render the element. If I set a larger or small value it grows and shrinks but at some non-integer scale of the value that was set. Though "Scaling" is probably a bad term as the rendered value/input value ratio is not a constant.
I'm attaching some images of the inspector panel for the main elements involved in the width, showing their HTML, CSS, and actually rendered properties. I know images aren't ideal, but these seemed to best represent the pertinent data in one place.
AssetDetailsContainer (right side child element) inspector snapshot
Looking at the resulting AssetDetailsContainer shown in the inspector we see the original 600px in the CSS, but then it's rendered as 104.5px instead.
AssetContainer (parent element) inspector snapshot
MediaViewContainer (left side child element) inspector snapshot
What am I missing here with respect to layout?
Turns out the solution was to nest the AssetDetailsContainer in an unstyled <div>. I think since the AssetDetailsContainer had a relative positioning property, that was not playing well with the flex positioning of the parent that was being used to create the side-by-side layout. The extra div layer seems to give it the proper segmenting of the different positioning properties and I now get the expected behavior.
Difficult to come up with a good title - by all means, change if you can.
Traditionally, a margin on an element can be used to move elements around a page relative to its previous elements. So, if I had a div as a column on my page I could shift elements vertically within that by setting their top-margin CSS property.
This is handy in dynamic pages where some elements might not exist according to given condition, eg, a very simple example here:
https://jsfiddle.net/jhartnoll/4s6pcLu0/1/
I have simply defined a column with a div element, positioned two other div elements and made one of them have a 2em vertical gap between it and its predecessor.
If you remove (or set Display:none) element #one then element #two is shifted up the column and positioned 2em from the top of the column, rather than 2em from element #one which is no longer there.
However, if I try to do a similar thing using a CSS grid, thus making the DOM tree simpler and more flexible, I run into a problem:
https://jsfiddle.net/jhartnoll/xvhycg0k/11/
In this case, the columns are set by the CSS grid so are sort of pseudo columns, but when I set my elements to have margin-top: 2em the margin is calculated from the top of the grid column, not relative to a predecessor element.
Therefore, if element #one is not present, #two simply remains 2em down from the top leaving a gap above...
This behaviour renders margin-top useless, because it is exactly interchangeable with top on relative positioned elements.
Is this a bug with CSS Grid, or am I using it wrong, or is there a way around this?
CSS Grid seems great, but I have run into several problems like this where dynamic content is concerned, if elements have potentially variable heights, or may not be there at all, the Grid leaves other elements floating in space, unable to shift up.
EDIT for clarity of the dynamic problem
Thanks for the comments so far. The problem is not with using the layout, I understand how to set up grids, and rows, define sizes, spaces, span etc, the problem is with dynamic content.
Supposing I have an extremely simple product page:
https://jsfiddle.net/jhartnoll/xvhycg0k/42/
Irrespective of the grid spacing, row/column size etc, the concept is simply that I have thrown in a "Price reduced by 10%" splash element above the product title.
Naturally, product pages would be using templates and therefore the HTML and CSS should be fixed and flexible enough to enable elements to be missing or present.
Not all product pages will display the 10% off deal, so on those pages, I would want the Product Title to shift up into the top element position.
This, as far as I can tell, cannot be achieved with grids.
Similarly, if there was a div which contained a product description and underneath it some product cross promotion or something, the description might be of variable length, so with the div as a column example in the my original question, the content would automatically expand the description grid and shift the cross promotion stuff down the page. Again, this can't be achieved with grids?
So, I was messing around with using a grid defining columns only and simply one row per page so that content could be stacked in columns similarly to the original div as a column example, but then I ran into this margin-top problem which, within a Grid is that margin-top is relative to the grid top, not to the elements above.
So I can't find a way of creating a dynamic website, using a template design which allows for conditional elements and variable element dimensions using Grid and without using Javascript to manipulate on page load.
In my mind, there should be an option for a row-shift property to allow elements to jump down a row if the content is too large, or jump up if there is nothing obstructing it... or something like that anyway!
Hey try the following code I guess it will help your requirement!
#column{display:grid;grid-row-gap: 10px;width:4em;height:auto;border:1px solid grey;}
#one{background:red;width:2em ; height:2em}
#two{background:blue;width:2em ; height:2em}
<div>
<div id="column">
<div id="one">
</div>
<div id="two">
</div>
</div>
</div>
What is the default behaviour of a div?
I noticed that even if a put a width for a div let's say 100px,
if i put a 2nd div with the same width will put it on the second line.so by default doesn't matter the width. it puts it on different lines?
in this case i understand the need of float.
I thought that any element i put in a html page,they will be side by side unless i add a break element or paragraph or something with that role.
Or maybe i do not use it correctly the div for this kind of alignment,but i really want to
clarify this for good.
A div element is, by default, display: block.
This value causes an element to generate a block box.
The rendering of them is described here
Block-level elements are those elements of the source document that are formatted visually as blocks (e.g., paragraphs). The following values of the 'display' property make an element block-level: 'block', 'list-item', and 'table'.
Block-level boxes are boxes that participate in a block formatting context.
and then here
In a block formatting context, boxes are laid out one after the other, vertically, beginning at the top of a containing block.
To stop this kind of rendering, you can use float to cause block level elements to bubble up beside each other. You can also modify the display property of the div.
Divs are block-level elements which mean they stack...like blocks. Although it sounds reasonable that since the width would allow them to fit side-by-side without a float, this is not how they are designed to behave.
If an element is an inline element as opposed to a block, its behavior is to fit side-by-side. You can force this behavior on a div if you would like by tying the two ideas together. You can do something like:
<div style="display:inline-block"></div>
This will allow the div to maintain its other block properties but allow it to fit inline as text and images would and, if this the your desired goal, avoid the use of float.
The DIV by default takes 100% of the screen, even if you set it width the space on the right cannot be occupied by anything.
Try this:
The way to have two div on the same line would be to make them float:
<div style = 'float:left;width:500px;background-color:red;color:white;'>Hey</div>
<div style = 'float:left;width:100px;'> There</div>
I noticed that line-height seems to affect blocks. Its strange to me, that i never noticed this disturbing effect before.
The problem is that it will affect blocks, even if they do not contain text at all.
I created a JSFiddle to demonstrate the issue. If you set line-height to 0, the grey area will no longer exceed that of the image inside the container.
Why is this happening and is there a clean way to prevent it?
The line-height value affects rendering even in the absence of text, since “'line-height' specifies the minimal height of line boxes within the element. The minimum height consists of a minimum height above the baseline and a minimum depth below it, exactly as if each line box starts with a zero-width inline box with the element's font and line height properties.” (CSS 2.1 about line-height.)
But that’s really not the cause here. Images are by default rendered inline, meaning that they act as big (or maybe small) letters, sitting on the baseline of text. The details are complicated, but by setting line-height considerably smaller than font size, you put baselines closer to each other and the space vanishes.
Another way to remove the disturbing effect is to set display: block on the img element. Then the element will be formatted in a different way.
Yet another way is to set vertical-align: bottom on the img element.
I was trying for display:inline property and I found same question for which I was looking....and here I got this answer, it makes me very clear ....but I am not clear about these lines ...
Basically margin, padding and border
can be set on inline-level elements,
but they may not behave as you expect.
The behavior will probably be OK if
there's only one line, but other lines
in the same flow will likely exhibit
behavior different from your
expectations (i.e. padding will not be
respected).
so please anybody can make me clear about these lines...I have also tried for display :inline here
You cannot set height, margin-top, margin-bottom, padding-top and padding-bottom on an inline element. You can set margin left and right an padding left an right.
You can set with on an inline element but then it will behave like a block element: See here
Inline Elements will always be displayed next to each other as long a they fit next to each other.
yes inline element behave differently other then block element. the main point of inline element is that is doesn't take vertical margin & padding.
inline elements like a, span
you can give inline-block instead of inline
this is a best example related to your question
http://www.maxdesign.com.au/articles/inline/
EDIT
yes, padding-bottom pushing the inline element down but it's not add any width to your inline element means when the content move to new line it's going to overlap each other & in block element margin, padding & border are adding width,height & space the block element
check these link for more
http://reference.sitepoint.com/css/inlineformatting
with this property set (display:inline) you can't set width and height of your element. Margin, padding & border is ok. I'd use floating instead, but that's because it gives me more flexibility sometimes. =]
It is saying that if you have an inline element that goes all the way to the right of the page and then wraps around to the left (for example, a single line of text that takes up two lines of space) then you may have unexpected consequences. In particular the padding may not display as desired.
An inline element, when it doesn't break on to multiple lines, respects left/right padding - so you see the padding-left and padding-right inside the left and right edges of the element respectively.
When the inline element does break on to multiple lines, the padding is somewhat respected, in that again both left and right inside edges of the element have padding. The part where it isn't respected is exactly the part where the element breaks, the break-point doesn't have any padding because it simply spreads itself onto the next line.
A block element on the other hand, does respect padding properly because it adds the padding and the contents of the element break inside that padding.
Here's a quick image to help explain what I've explained: