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).
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;
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.
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 am building a custom rich text editor. And in its current use, it inserts itself- a div- before a text area that is nested in a div.
This container div is supposed to start out with a top margin that lowers it down on the page, and then the text editor div then sits inline with that.
The problem I am having is, in IE 9, when the editor div gains focus it immediately shifts itself so that its margin-top is 0px. This therefore occurs on the page loading, but also if the user clicks anywhere in the content editable div.
The caret remains at the correct location, but the editor div plus its container have scrolled upward so the editor div has no margin.
This works correctly in IE 8 for some reason.
Without seeing the code, I'm not sure, but have you tried it in quirks mode? There has probably been a fix to make the code work more along standards that doesn't work with IE9. You can either use the built in tools in IE9 to try to identify the problem, or change the DTD and see what happens.
W3 DTD List
Is there a way to tell Safari / Webkit browsers and Firefox to scroll an element or a page while overflow is set to "hidden"?
I'm using overflow: hidden on the body-Element and it works for Opera only.
Any ideas?
Pretty sure this is one of those cases where Opera does it differently from everyone else. Overflow is supposed to prevent scrolling if its value is hidden, not just hide scroll bars.
If you really want to hide the scroll bars, but still want to scroll the window or its contents, you can use JavaScript / DOM script to do it.
Sorry but you have been mistaken, the overflow-x:hidden or overflow-y:hidden must be applied to the html element, not body element. But in just the case I have googled it and found these
link tell me if they did any help.
http://www.webmasterworld.com/javascript/3560359.htm
http://www.artmov.com/dev/snippets/apply-overflow-x-overflow-y-to-body-in-ie7-ie6-84/
(In this link I found the above mentioned statement.)
http://haslayout.net/css/Document-Scrollbars-Overflow-Inconsistency
In this link I found that you should apply directly overflow value in the <HTML> tag.
Hope it works!
If you're setting overflow: hidden on any element, you're explicitly telling it that the contents should be hidden, and therefore can't be scrolled to. If you want the contents to be scrollable, then you need to use overflow: auto. Why would you ever want to scroll something you're telling the browser it should not scroll? It's contradictory.