I am not sure what is the problem, but my CSS is not working and I am not able to figure out what is the exact problem as I am new to CSS. I have tried the code on Chrome and Firefox and need someone to explain what is the real issue.
This is a Chrome screenshot and when I am inspecting the element then it highlights the <div> on the browser, but it is not visible.
This screenshot is from Firefox and I am using Firebug, but the interesting thing is all the content, which is not visible on the browser, has a different color (grey) than the content visible on the browser.
Can anyone explain me how to fix this?
The pale display within Firebug indicates that the element is not visible.
According to the Firebug wiki this can have different reasons:
Faintly displayed elements mean they are not visible inside the page. That is e.g. when the CSS style display: none is applied to the element or the element doesn't have any dimensions.
So it looks like the ancestor <div> with id ebBannerDiv_... is hidden (meaning it's offsetWidth and/or offsetHeight DOM property is 0) and therefore all its children are hidden, too.
It may be related to font-size and line-height being set to 0px for that <div>.
For further investigation you can check the dimensions and visibility of that element via the Layout side panel. If you see there that display is set to none or it's width or height are 0, you can then investigate further by checking the style trace for the width, height, display, font-size and line-height properties within the Computed side panel.
Related
This is completely different from the regular overflow issues people struggle with. First of all, I've only been able to produce this issue in Chrome (Version 41.0.2272.101 64-bit). IE 9+ and Firefox seem to behave as expected.
The body element grow with the content. No height: 100% or position: absolute styling used here.
The problem is that there seems to be something unknown forcing the browser to scroll further than it should by roughly 400px or more on both x and y axis. The inspector cannot select anything in this empty space and ends up selecting the html tag.
I've been through every element on the page and nothing seems to extend beyond the html tag!
Unfortunately I cannot link anything as the site is on a work server and requires authentication to access the page :(
I'm stumped, so any suggestions would be much appreciated!
I found that the issue involved jQuery UI, css provided with the plugin and my company's css. We use jQuery UI for input suggestion in our app.
What seems to be happening was that a recent change in our html structure set particular elements height and width to 100%. This css happened to include jQuery UI's ui-helper-hidden-accessible class. The css provided with the plugin sets ui-helper-hidden-accessible to, amongst other things, position: absolute; and clip:rect(1px,1px,1px,1px);. As the parent element was not explicitly set to position: relative;, the ui-helper-hidden-accessible element was overflowing, though due to the clip property it was not visible in the developer tools! Neither selecting the hidden element or clicking it in the dev tools elements tab would reveal how large it was.
There are two solutions to this problem:
Altering the css selector that sets width and height to 100%
Setting the parent element to position: relative;
Have hit a problem I've never encounted before.
I have a element, its a panel that is fixed to the right side of the screen, and the css for the positioning is:
.myPanel{
position:absolute;
left:0;
}
This works fine, the mark up for the panel is generated by vaadin.
Now everything works fine, however every now and then when I refresh the page the css position:absolute
is being ignored.
Naturally I open my devtools and see that according to the styles tab position:absolute IS being applied, it just doesnt look like it.
Now the odd bit
When I uncheck the tick box to remove the position:absolute styling nothing changes (as I'd expect) but when I re-check it, and the position:absolute is reapplied, the panel then shows correctly.
So even though there is no new css, removing then re-adding position:absolute fixes it.
I've always been under the impression that dynamically added elements will still take css styles that have been loaded pior. Is that incorrect?
I have ONLY had this in chrome, currently version 39
Any ideas?
UPDATE:
if at some point the css was being overridden I'd expect dev tools to flag that (style with a strikethrough etc) but its not. I have tried adding !important to it but get the exact same result (see is applied in devtool, disable and reenable fixes it).
I've noticed in the dom that vaadin is loading my custom javascript in the head, then the css, then its own inbuilt javascript.
This seems to be working according to the spec. If width and height
for a replaced element (which input is one) is auto, it's supposed to
use the elements intrinsic width and height, which might cause
absolute positioning to be overconstrained.
One fix is to wrap your inputs in a div, absolutely position that, and
use width/height 100% on the inputs. Note that Firefox also has this
behavior, and it is indeed in the spec, so it's better to fix the
website than to change Chromium.
~#9 chromo...#gmail.com
As per you saying:
I've noticed in the dom that vaadin is loading my custom javascript in
the head, then the css, then its own inbuilt javascript.
I would say this would be the case for all browsers. For more info, see a previous answer of mine in relation to this
Its a known bug which looks te be solved and the appears again, see also https://code.google.com/p/chromium/issues/detail?id=313221
I have encountered a strange bug using my OpenCart website in Chrome. The product images are not showing up but I see the white area where they should come.
If a product doesn't have an image it's aligned to the left but in this case I can see the white area where the picture normally is.
And here's the crazy part, if I click on inspect element, suddenly the image appears.
Some css code
.product-list .image {
float: left;
margin-right: 10px;
overflow: auto;
}
In the CSS you need to set the width and height attributes.
That is weird. Regardless, things to check:
Z-index: The outer box that surrounds the image might be "above" the image itself. Add z-index to the image with a value of 9999 to check
Position: if it's parent container or god knows what else has a weird position it could be affecting where the child element, in this case an image is appearing.
Disable JS - Javascript might be causing an issue here, try disabling it to check.
Also, when you use chrome dev tools, you are technically "hovering" on the image. And you say it suddenly appears. So I'd take a look at your :hover rules as they apply to images. A lot of sites will use a sprite technique that shows one image in normal state, and then shift the background to a different part of the same image on hover. Your normal state could be empty and the hover then moves the bkgd position to the image you want.
Let me know how this turns out.
More scenarios to replicate this issue
1. Close inspect if not already opened.
2. Resize inspect if already opened.
3. Resize browser window.
Just to follow up on this issue, Mary's answer is the correct one, but for our circumstances it was important not to set a width and height in order to maintain responsiveness. But apparently setting width and height to auto works just as well, even though it makes no difference in appearance.
So, since opening the Web Inspector resizes the page in some cases, you should look into:
resize handlers on JavaScript side that might be causing your images to show up
media queries that satisfy certain width and only show images then on CSS side
Picture element having media queries that
aren‘t covering the width you are viewing this with.
For me this was the Picture element having a gap in its media attribute definitions (<source media=(min-width: 1824px)">).
I'm guessing this is because of an update because I feel I would have noticed this before, but when I use Chrome's element inspector it only highlights the dimensions of an element if that element has a specified class. If the element has an id and no class, no dimensions are given.
Highlighting element with class...
Highlighting element without class...
The second image shows the lack of yellow dimensions box. Obviously this isn't the biggest deal but I'd like to know if this is a bug or if Chrome is doing this for a specific reason and if there is a way to change it.
What does the style visibility:hidden do when applied to the html element? Does it have anything to do with the scrollbars, esp. in regards to IE7?
Background: Oracle Apex generates this code, and I'm trying to work out if it's causing an issue with an intermittently hidden horizontal scrollbar in IE7:
<style> html {visibility:hidden;} </style>
Specifications
According to the spec, the visibility property should still affect layout. This implies to me that it should not affect scrolling if an element ends up causing scroll behavior. Also, any children set to visible should be visible within a hidden element.
Observed Behavior
Using this fiddle...
Firefox, IE 8-10, Opera
Makes visibility: hidden on the html element not render the body (as it should) but still shows some rendering of the html itself as it shows the background-color. As BoltClock noted in his comment, this actually may be expected, since the background of the html is (according to spec) to become...
"the background of the canvas and its background painting area extends
to cover the entire canvas."
These browsers also allow elements set back to visible inside to show as the spec for visibility indicated, so the div is showing and can scroll.
Chrome and Safari
It does not render the background-color on the html, but it does allow the div to show and it shows the scroll bars. So Chrome is not propagating the background property to the canvas, presumably because its visibility was set to hidden.
IE7
The background-color for the html element does not render (like Chrome) but there are also no scroll bars showing up for the div element inside. This seems to indicate that it is not properly staying in the layout per the spec.
So it may be that the visibility: hidden property is part of your issue. Obviously, the background point relates not at all to your scroll issue, but does address the point of your overall question on how the property affects the html element.
In my opinion, the Chrome and Safari rendering would seem to be the most intuitive (what I might expect as a designer), as I would not expect the background-color to render (since the element is hidden), but at the same time, if I set a child as visible, then I would expect the browser to let me scroll on behalf of that child even if the html wrapper is set to visibility: hidden. However, whether the webkit browsers or the other browsers are closest to the spec is debatable, for as BoltClock noteed in his comment, the spec does not seem to indicate whether visibility on the html element should or should not affect the propagation of the background property).