Why are my DIVs higher in Firefox than Chrome? - google-chrome

I have a DIV in a table. This code is generated by GWT, so I don't have a lot of control over the elements that are used (which is to say that I know tables are usually not the best element for layout, but this is not something that I have direct control over).
In Firefox, a DIV with 100% height spills out below the table, while in Chrome the DIV are sized as I would expect. What is going on?

So this one had my pulling out my hair for a while, but it turns out that the DIVs in Firefox were defaulting to box-sizing: content-box setting, while in Chrome they were defaulting to the box-sizing: border-box setting. Because I was using padding in the DIV, this was causing Firefox to display the DIV with a height of 100% plus the padding.
The solution was to just specify -moz-box-sizing: border-box in the CSS for the div.

Related

weird behavior with border

I've written a code to place two images side by side and show some text on hover, but I came across a weird behavior I can't explain and I was wondering if anyone can explain it to me.
Everything works fine with the code, but as soon as I add borders to the .project-tile class, to add borders around the image, both images collapse to the center.
I have tried to isolate the problem but I can't really figure it out, anyone has any idea?
codepen: https://codepen.io/pafestivo/pen/JjvNMmJ?editors=1100
This has to do with the css box-sizing property. By default, the value of box-sizing is content-box, which means the border is not constrained by the width: 400px; and instead causes the divs to overflow their width and trigger wrapping.
Setting box-sizing: border-box; on .project-tile will allow you to add borders while keeping the current positioning.

Textarea at 100% width fills container but div at 100% width expands the parent

I'm having an interesting problem that I'm hoping someone can help with. I have a textarea that when set at 100% width, fills the parent div that it's in. HOWEVER, if I replace that with a div, the div blows out the parent divs width to now fit the child's content instead of wrapping.
I've tried various approaches (display:inline-block, display:table, display:table-cell, box-sizing...) I've used span, div, p and table/tr/td.. all result in the following overflow.
I've inspected the source, and all I see is the textarea's width being set to 100% with no other styles affecting it.
Is there's an attribute I'm missing when I'm inspecting?
My guess is that you simply need to utilize border box:
*{ box-sizing: border-box; }
Basically, your div might have padding also. Now when you add the padding with width: 100%, the child will basically overflow the parent cause of the extra padding.
To include padding within the width try providing your div a box-sizing: border-box;.
You can read more about box-sizing here.
Due to the complexity of the application, I'll need to strip it down to the basics and figure it out. I was hoping that there was a structural component of the textarea that I didn't know about.
Thanks,

CSS width with percentage for child elements not working on firefox?

I'm trying to create a fluid layout, so I used a width in %. I tested the site on Chrome, Safari and IE. When it worked fine in IE I thought my work was done, however when checking it in Firefox I realized the width was incorrect. EG: two 50% elements wouldn't fit in one line neither 3 elements with 33% width. This is an example from my site:
http://pranalog.com/example.php
How can I get this to work on Firefox (or on the most browsers)?
You have box-sizing: border-box; set on the div's, to set border-box in Firefox, add:
-moz-box-sizing: border-box;
to your style rule. This is needed to get box-sizing to work in Firefox, setting this property to border-box forces the browser to render the div's with the specified width and height, and places the border and padding inside the div's.
This in turn fixes your issue: with the border rendered on the outside of your div's, the total width of your elements is essentially 3 times 33.3% = 99.9% plus 6px needed to render the the six 1px wide borders on the right and on the left of each div. Since 6px is more than the 0.1% of the page width that is left, the last div doesn't fit on the same line anymore and moves down to the next line.
With the border rendered inside the div's by setting border-box properly, you won't have this issue.
Here's a fixed up jsFiddle
It's because you have a border of 1px, try removing the border value and all three fit side by side.
If you would like to keep the border then just reduce the width to around 32%
Good luck

Do I have to remove px for padding when using 100% width?

I'm building a responsive webpage and have set all outer wrappers (inlcuding body) to 100% width. The problem is that some elements 100% width is going outside the wrappers?
Please, take a look on this page : http://test.ufeed.se/
Size your browser to under 1000 px width. scroll down a bit and then use the horizontal scroll. You will see that some of the elements are outside the wrapper, why?
Do I maybe have to remove px from 100% width like this :
width: calc(100% - 16px);
to remove paddings (that takes extra space)?
padding makes elements bigger if you are not using box-sizing: border-box
Its because of the box model. Basically the width is set to 100% and then the margin, borders and padding add on to that pushing content outside of where you want it.
Yes you can remove the padding and that should resolve the problem, but as block level elements automatically take up the full width available you should just be able to remove the width and it will work as intended.
You can also use box-sizing: border-box; which tells the browser to include padding within the width calculation.
Without actually looking at your code I think these are the best solutions to your problem. If you want more specific help replicate the problem in a jsFiddle.
Learn about width: auto and the difference between width:auto and width:100%
If a container already has a width and you're thinking about setting a width of 100% on a descendant then NOPE what you really need is auto ;) Whatever the padding, border and box model, the result will be the same and what you intended.
* { box-sizing: border-box } and its prefixes (and boxsizing.htc polyfill for IE6-7 if needed) is also neat but it has huge consequences on your layout. I mean, it's a choice you've to make for your whole project. width: auto is useful in more particular situations.
i think this width element should be a %px element
.postContainer .createdDateCon {
width: 150px;
}

Safari on iOS6 treats display:table differently

Safari on iOS6 appears to treat display:table differently (compared to Safari on iOS5 and Safari on my PC).
On iOS5, display:table forces a div into box-sizing: border-box mode, and ignores any attempt to override the box-sizing.
On iOS6, display:table forces a div into box-sizing: content-box mode, and also ignored any attempt to override.
The outcome is that DIV DISPLAY:TABLE WIDTH 250px PADDING-LEFT: 50PX will be 250px wide on iOS5 and 300px wide on iOS6.
My question: Is my understanding of this correct? Is there a simple way of getting a div with DISPLAY:TABLE and a left padding to be the same width on iOS5 and iOS6.
FYI the reason I am using DISPLAY:TABLE is because it allows simple vertical centering of my content, which has variable height.
Just in case it helps someone in future, this answer solved the issue for me. I moved the padding from the element styled with display: table; to the one styled with display: table-cell;.
I ran into this same issue and couldn't find any documentation other than this posting. Fortunately for me, it turned out that the container in question didn't need the table: display property.
However, I did test to see if display: table-cell applied the padding the same way as display: table, and it turns out it doesn't. So maybe try applying the display:table property to the parent container (free of padding, of course) and try display: table-cell on the div in question.
Did you try adding
box-sizing: border-box
This wont have any effect on the iOS5 but will probably fix the display on iOS6 if what you're saying is correct. Sorry no chance to test on iOS6