I have web page working properly on Ie 7 and mozilla but when opened in IE 8 height getting mizimized.Is there any additional height property i need to set up for this in css??
You may have a float issue. Are you floating elements? If so, you might want to put clear: both as a css property in your footer.
The height depends on a couple of things, such as how you have initially set it (%, px), and how it is positioned. If the height is set with pixels then you should be ok.
A fallback option is to use min-height: 800px; replacing 800 with your chosen value. That way if something happens to the content (or there is none), you will still see the element.
Also, if the element in question is not meant to have any content, then give it display: block;.
Related
My biggest problem here is to express what I want, so please free to alter the formulation / suggestion correct wording for things.
On mobile I wish my page to be only vertically scrollable (page width and view port width are the same. A bug is causing an element adding more width than it should. I have identified the culprit element, when I set this element style to "display:none;" the display is correct (no horizontal scroll), when I don't I get an horizontal scroll.
To make it clear, with ".culpritElement {display: none}":
With culpritElement visible:
culpritElement is generated with some inline style by a third party library that I don't want to tweak. Is there a CSS directive to set to make the element visible but out of the positioning flow of the others (and page size computing).
You could set .culpritElement { max-width: 100vw; overflow-x: hidden; }
Or you could apply the above css style to its parent element
I have done some testing and from what I can see there is a bug in mobile Safari on ios6.
When adding overflow:hidden on the body tag and moving an element out of the body using transform:translateX(100%); It creates an extra scrollable space for that element.
On all desktop browsers it is "hidden".
Here is a demo: http://jsfiddle.net/mUB5d/1 . Open that in Mobile safari and you will see what is wrong.
Could anyone take a look at safari 6 on Mac OS to see if the bug is present there too?
Does anybody know of any workaround besides creating another parent around my element?
Thanks for your feedback!
Nope. Safari 6 on Mac does not present with the bug. Scrollbars are not present.
I ran it on OSX Mountain Lion (10.8.2)
To further answer your question, the reason this is happening probably has more to do with Mobile Safari's zoom rendering than an overflow hidden bug. The element is in fact being hidden off screen (notice below where I have scrolled over to the right all the way, it still doesn't show me the full 100% width element - 90% of it is in fact being hidden.
It likely has something to do with iframes, and page zoom. Still looks like a bug though.
I'm assuming you're demonstrating in JSFiddle from a real life example. If you go back to your real life example (apart from iframe territory), try adding this meta tag to the head if you don't already have it, and see it this helps:
<meta name="viewport" content="width=device-width, initial-scale=1">
This is normal behaviour on iOS (and iOS only). You can work around it by declaring overflow: hidden on both html and body element. In addition, you should set the body to position: relative.
Overflow behaviour
There are several things at play here. To understand why the fix works, we first need to have a look at how the overflow of the viewport is set.
The overflow of the viewport is determined by the overflow setting of the html element.
But as long as you leave the overflow of the html element at its default (visible), the overflow setting of the body gets applied to the viewport, too. Ie, you can set either html or body to overflow: hidden when you target the viewport. The overflow behaviour of the body element itself is unaffected - so far.
Now, if you set the overflow of the htmlelement to anything other than visible, the transfer from body to viewport does no longer happen. In your particular case, if you set both overflows to hidden, the setting of the html element gets applied to the viewport, and the body element hides its overflow as well.
That's actually the case in every reasonably modern browser out there, and not specific to iOS.
iOS quirks
Now, iOS ignores overflow: hidden on the viewport. The browser reserves the right to show the content as a whole, no matter what you declare in the CSS. This is intentional and not a bug, and continues to be the case in iOS 7 and 8. There is nothing anyone can do about it, either - it can't be turned off.
But you can work around it by making the body element itself, not the viewport, hide its overflow. To make it happen, you must first set the overflow of the html element to anything other than visible, e.g. to auto or hidden (in iOS, there is no difference between the two). That way, the body overflow setting doesn't get transferred to the viewport and actually sticks to the body element when you set it to overflow: hidden.
With that in place, most content is hidden. But there still is an exception: elements which are positioned absolutely. Their ultimate offset parent is the viewport, not the body. If they are positioned somewhere off screen, to the right or to the bottom, you can still scroll to them. To guard against that, you can simply set the body element to position: relative, which makes it the offset parent of positioned content and prevents those elements from breaking out of the body box.
Answering in code
There is one final gotcha to watch out for: the body itself must not be larger than the viewport.
So the body needs to be set to 100% of the viewport width and height. (The credit for a CSS-only way to achieve it goes to this SO answer.) Margins on the html and body elements have to be 0, and the html must not have padding or a border, either.
Finally, in order to deal with body padding, and in case you ever want to set a border on the body, make the math work with box-sizing: border-box for the body.
So here goes.
html {
overflow: hidden;
height: 100%;
margin: 0;
padding: 0;
border: none;
}
body {
overflow: hidden;
position: relative;
box-sizing: border-box;
margin: 0;
height: 100%;
}
NB You can set body padding and border as you please.
After struggling with this for a while I've found that both html and body tags need overflow hidden to actually hide the overflowing contents. On elements inside body overflow hidden works fine, so our choice is an extra css rule or a wrapper element.
for me it works
I have implemented in the left side menu
if($('.left-menu-panel').is(':visible')) {$("body").addClass('left-menu-open');$("html").css('overflow-y','hidden'); $('body').click(function() {$("body").removeClass("left-menu-open") ;$("html").css('overflow-y','visible'); });$('#off-canvas-left').click(function(event){event.stopPropagation();}); }
After experimenting with the css3 flex-box proporty, I quickly noticed some differences in Chrome and Firefox.
In particular: if you set a width on an element that should be flex,
firefox will flex the element according to what it needs, it takes the width style into account but its only a variable.
Chrome will respect the with style fully,
An example:
<div id="box">
<div class="flex-box">Test</div>
<div class="flex-box">Test Text</div>
</div>
If the 2 divs inside the box have the same width assigned, chrome will make them the same size. Firefox will reconize that the second div needs more space, and thus it gets more allocated.
who is right?
Remember the flex doesn't apply to the width, it applies to the free space after the minimum intrinsic width has been determined. This produces counter-intuitive results in several common cases, as has been pointed out on the www-style mailing list. I've found that, unless you want the CSS re-ordering or the multi-line (which isn't yet implemented in Firefox and Chrome), what you think you want to use display: box and box-flex for you really want to use display: table and display: table-cell.
But back to your actual question: I found Firefox and Chrome display identically if you set a width in pixels, but not if you set a width as a percentage. As far as which browser is doing it correctly at the moment, it's a fair bet Firefox is implementing what the spec originally intended as the original spec is describing what the XUL property does, and the XUL property is what this is all based on. As others have mentioned, whether or not the final spec ends up matching this original intention is unknown.
I don't think any browser is right or wrong as flexbox is still a working draft. At any time the spec could change and render another browser right or wrong.
http://www.w3.org/TR/css3-flexbox/
I disagree with robertc's statement "But back to your actual question: I found Firefox and Chrome display identically if you set a width in pixels, but not if you set a width as a percentage."
I am currently using the flexbox in an attempt to show how simple it is to convert a rather heavy in JS and CSS site to a very simple HTML/CSS3 site. Once conclusion I have come to with regards to setting width in pixels:
#main {
display: box;
}
#main > section {
width: 120px;
padding: 10px;
border: 5px solid #000;
}
In chrome, the total width = 120 + 20 + 10 = 150px
In ff, total width = 120px (the 20px padding are inside the 120 and the 10px border is as well)
Another inconsistency I found, in chrome, #main IS greedy and takes up 100%, as you would likely expect. In Firefox, you need to set with to 100% on #main in order for it to act as you would expect.
I'm still working on ironing out all differences in all supported browsers, I will try to post when I have more to add to this. Sadly, as cool as he flexbox model is, and as easy as it makes a lot of shit, its far from consistent.
One more thing, using CSS transitions to change dimensions works well with explicitely defined dimensions (ie. pixels)... but if the dimension is defined by the box's flex, the animation simply jumps between the flex values... no where near as smooth (though, instead of heaving flex of 5 and 1, you could have flex of 500 and 100). In fact, chrome will not animate between flex values, just jumps. FF on the other hand does this nicely.
I'm just really hoping things progress to the way FF handles flexbox, while chrome is close, I just don't agree with how some things are handled, and the lack of animation between flex values just plain sucks.
I am trying to make a table-like calendar page, using fixed width and height block level elements. There is an outer container, which sets the width, and the cells get aligned by float: left. It works well in every browser, except in IE6, where the list gets split after the 29th element.
If I make the outside container a bit more wide (by at least 3 pixels) the problem gets fixed in IE6. Because the elements are more than 3 pixels wide, it doesn't change how the page looks. But I really don't understand why it happens, and what should I do not to make it happen.
I tried IE7.js, but it didn't help.
I know IE6 is such a buggy old browser, but while my sites are simple I prefer making them IE6 compatible.
link to the page in question
You can fix it by adding this to the bottom of style.css:
/* IE6 hack */
* html #naptar-list a, * html #naptar-list div {
width: 77px
}
This works by using the Star HTML hack to feed to only IE6 the declaration width: 77px (1px less than the actual width), which in my testing, fixed the problem: I'm not entirely sure why.
I have a <textarea> that needs to fit into a space whose size is not pre-determined (is a percentage of the screen size). I can get good results if FireFox by setting the regular CSS properties:
#container { width: 70%; height:70% }
#text_area { width: 100%; height: 100%; margin: 0; padding:0; }
However in IE 6 and 7 I get different, odd results. In IE6 the textbox appears to have padding to both the left and the right, pushing the size of my container to grow. In IE7 the textbox has padding to the left, but does not make the size of the container grow - instead its right edge pushes outside of the container.
The height setting seems to have no effect in either IE6 or IE7; the <textarea> is 2 rows long in both cases, ignoring the height:100% directive.
Is there a consistent way to size a <textarea> across browsers?
Is there a way to get rid of the padding to the left of the <textarea>?
Update
Using position:absolute removes the padding, but the width:100% is still screwed up. IE7 seems to calculate the 100% width to be too large, resulting in a <textarea>that spills out of the <div> that contains it.
I'll create a stand-alone example if I get a chance...
I've seen this problem with ASP.Net textbox controls also in IE7. I couldn't remember where I found a solution (but props to the person that found it), but I was having the same problem where the textbox with width="100%" would actually break the DOM and my entire content section would "spill" onto a neighboring section (such as a table based navigation).
The solution I eventually adopted was to wrap the asp:Textbox inside its own table and set the "table-layout:fixed; width: 100%" property and on the textbox/textarea "position:relative; width: 100%;" so the block would look like this:
<table style="width: 100%; table-layout: fixed;">
<tbody>
<tr>
<td>
<asp:Textbox id="txtMyTextbox" runat="server" Width="100%" style="position: relative;"/>
</td>
</tr>
</tbody>
</table>
This is not the prettiest solution, but I have verified that it does work cross all browsers. I have a write-up on this issue HERE.
Hope this helped.
There may be a sneaky CSS way to achieve this that I don't know about, but in my experience this is one of the things where using a bit of Javascript is justified.
You could get the height you need (of the current window I presume) using JQuery or Prototype, or in pure Javascript: Get the height of the current document and then
document.getElementById("text_area").style.height = calculated_height+"px";
The left hand padding I find odd, though. Can you post an example?
In order to solve this kind of problems, one has to think about how percentage is handled in the browser. First of all.... percentages don't exist, they are converted to pixels at some point. The steps are 1) browser renders all tags, 2) browser measures outer, parent, percent-sized boxes to get its size in pixels, and sets the size of the child boxes according to their percentage size.
I think the first thing to verify is the size of textarea's parent box, and it's parent box, and so on. This can be done by checking the "Layout" information in Firebug and IE Developer Toolbar, and find out what's measured differently in both browsers. Once you find that element (or elemets) css can be adjusted to consider them.
Have in mind that percentage sizing considers the width and height of parent box content to size the child element and not padding. So, if a parent box width is 500px and has 100px padding, a child element with 100% width will be 500px and the 100px padding will be around it, and both elements will take 700px of your screen.
Try
adding a min-height:100% on the text area css. On the div containing the absolute positioned , set the position to relative on your css.
also use transistional Doctypes instead of strict, while your at it. Make sure there are no unclosed tags. I would be better if you can make the page XHTML or HTML standard compliant so that you will have less problems with cross browser compatibility.
Try adding display:blockand border:0 to your #text_area.
The former should take care of the height-issue and the latter prevents the width:100% to spill over.