The full scope of my specific issue is likely too deep to include in a question here. Instead I am looking for clues.
The nature of the problem has to do with overflow: hidden. In Internet Explorer 11 it is working sometimes and at other times not. I have an element that is larger than the body and I have set the body element to overflow: hidden. Sometimes the page loads and works exactly as expected, but in about 60% of my tests the browser just ignores this property. If I look in the inspector the property and value are present, yet are not having any affect on the rendering of the page.
I have tried using a container element instead of the body, but the same thing happens. opening the inspector panel while scrolled to the top of the page will sometimes fix the issue. Any ideas?
There is a lot going on with this layout which is why there is no fiddle. Everything else works fine in IE. There are no errors in any browser and the layout works perfectly in all other browsers I have tested (Chrome, Safari, Firefox, Opera and IE 11).
Are you using a display properly on that div or element? If you have display: inline then try to change to display:block.
I am not sure why this worked but I just positioned the body fixed. That seems to work.
Related
the sticky positioning support in CSS is very nice, but with glitches!
I am using position: sticky on a two-column layout. I have a select dropdown in the section that is set to be sticky, when page is scrolled, the select in the sticky-positioned div renders way off its place, outside the div, where it would've appeared originally without any scrolling. Here is the screenshot:
when I click anywhere to close the dropdown, and then open it again, it renders fine in the correct place. This is happening on Chrome and Firefox but not in Safari.
Here's a jsfiddle with the issue replicated. Before opening the dropdown, scroll down a bit, and then click on the select.
Does anyone know a solution to this?
After looking at your example, this appears to be an artifact of the OS rendering <select> elements and not the browser. I'd suggest filing a bug report for Chrome and Firefox, as those are the browsers you reported it in (I've confirmed it in Chrome 59 on Debian-based Linux).
I am facing a strange problem where the a navbar I have created is displaying differently in Chrome than Firefox. Here is a screenshot of each. Firefox is displaying it correctly:
While the background colors are getting lost in Chrome:
I have created a fiddle here, but the problem is not apparent when viewed on the jsfiddle site using Chrome. In the live Chrome browser, the body declaration over-rides the definition for the navbar, even though z-index is used.. Any ideas on how to solve this strange issue? Im using an old version of Chrome right now (21.0.1180.90), trying to insure backwards compatibility. Thanks for your ideas!
Your code works fine tested in "live Chrome browser" 21.0.1180.89 (couldn't find the 21.0.1180.90) on OS X 10.8.2.
And I think you are missing the point of z-index:
For a positioned box, the 'z-index' property specifies:
The stack level of the box in the current stacking context.
Whether the box establishes a stacking context.
http://www.w3.org/TR/CSS2/visuren.html#z-index
z-index is not used to override any other css declaration.
You're code is working in Chrome version 24 , Firefox and Internet Explorer 10 . Maybe the problem is only in that version of Chrome or you override it somewhere else.
I am using overflow:scroll; in my css to have scrollbars always "on" for an iFrame window, but it works only for Firefox! Any idea about Chrome, Safari and Opera? Thank you in advance!
I have a similar issue with webkit (safari and chrome) based browsers; seems that they value higher the css styles on the html over the actual iframe style itself. Can´t find much documentation on this, but I am sure it is the origin of the problem.
http://trafficonweb.com/iframe-moves.png the iframe moves to left when pulled right on its main content (under the navigation menu). Only on webkit.
This happens when scaling down the iframe with the scale (transform) css property.
This is not the perfect answer but at least a hint; will continue research and post afterwards.
And looking for others to contribute to this issue. Thanks.
This is a CSS related question, I got one good answer from my previous question, which suggested the use of some CSS code like overflow:auto together with a fixed height container.
And here is my actual implementation : on uni server
If by any chance you cannot access that server, try this
Please follow the instructions on screen and buy more than 4 kinds of tickets.
If you are using IE8, Opera, Safari, Chrome, you would notice that the lower right corner of the page now has a vertical scroll bar, which scrolls the content inside it and prevent it from overflowing. That's what I want to have in this section.
Now the problem is, this would not do in FireFox 3.6.2. Am I doing something not compliant to the CSS standard or FireFox has its own way of overflow control?
You can inspect the elements on screen, and all controlling functions are done in one javascript using jQuery. All CSS code is kept in a separated file as well.
According to the professor, FireFox would be the target browser, although the version was set to 2.0...
It seems you have to set a height / overflow to the <tbody> tag, not just the table (or maybe not the table at all, didn't test that).
So...
tbody { height: 130px; overflow: auto; }
And I specifically tested with "height", it seemed "max-height" didn't work as intended. Very odd behavior, indeed.
Have you tried overflow: scroll?
http://betawww.helpcurenow.org/media/press/
You'll see I have used spans within an anchor, with the span.hover-description set to display:none; by default, and on a:hover that span is set to display block and absolutely positioned to create a tool-tip effect when hovering over the name and email of the "For Immediate Release" contact names.
Everything looks as desired in Firefox, but Chrome reveals my unknown blunder somewhere.
Any help on what's the problem that is causing Chrome to not display like Firefox?
Incidentally, Explorer shows the tool tip as expected, although I'm getting a funky bottom margin issue below the names, and Safari has the same issue as Chrome (must be a webkit rendering setting that I need to accommodate for).
OK, I figured it out. Since I'm using a pretty complex nesting structure to accomplish the CSS tool-tips, I overlooked the fact that I had actually nested a p tag within a p, and of course that is a no-no.
Firefox is really friendly to a lot of validation errors, but Chrome and Safari seem to be much more strict.
In the end I changed the p's to span elements and all is well across browsers.