With reference to the question clip-path not working in SVG sprite, it seems we can't use style="display:none" to hide an SVG element that defines a clip path that will be used elsewhere.
However, the suggested alternative for hiding it given (using width="0" height="0") is not working for me (at least in Chrome, the SVG element still gets allocated space in the page layout, which causes a vertical scroll bar to appear, as I have a div with height="100%" above it). What other was are available for hiding an SVG that won't stop it being used for clipping?
In the end, I used position:absolute to take the item out of the usual HTML document flow. I don't understand why a zero-sized element would cause scrollbars to appear, but that certainly seemed to be what was happening.
Related
I am trying to solve a case where <textarea /> positioned absolute with some top value does not follow it's position if it's inside of overflow hidden parent.
This tiny code example explains it perfectly:
https://jsbin.com/xitayayiza/edit?html,css,output
And here is the video how this code example works:
https://monosnap.com/file/TkEHFXaAXslh3XkakCjkzfvVqLLB0q
On the video you can see when <textarea /> grows up, covering the space above (althogh it has position: absolute; top: 10px;
The question is: Is there a way set via CSS the textarea in the way that it will always keep its top value?
As you can see on the video the top space (above the textarea) is equal to the value top: 10px; but while editing textarea and adding more content into it the space decrease, while I would like to keep it permanently the same.
If you are expecting any decent browser to allow the caret of a <textarea> to be placed into an "out-of-view" or "out-of-reach" area, you are in the wrong. Simply put, it will never happen. With only one exception: when the <textarea> has scrollbars and the user scrolls it so the caret goes out of view. However, any change to the caret position will immediately scroll it back into view.
Why? Because that is considered to be a critical state, as it makes not only the page, but also the browser seem (and, in fact, be) unusable. Which might not be important to you, but is extremely important to browser manufacturers.
When, due to some unfortunate design decisions, the caret ends up in a non-renderable area, as in your example, the browser steps in and makes it visible. It has to ignore/override some of your rules so the caret becomes visible again. Rather than removing the overflow:hidden altogether (which is, in fact, done by some browsers) - most browsers prefer to just "scroll" the contents of the element with overflow:hidden into view (it's not a proper scroll, there's usually no scrollbar involved - it's more of a "shift"); so they shift the contents into a position that allows the user to continue to see the immediate outcome of their input. This change is temporary and reverted as soon as the <textarea> loses focus or caret moves to a (normally) visible area of it.
Bottom line, whenever you place a <textarea> inside a smaller element with overflow:hidden expect it to be shifted around so the caret is always visible.
In practice, you'll notice a <textarea> becomes more predictable and controllable by placing it into a position:absolute parent rather than applying this property to itself. But, again, don't expect browsers to allow you to hide the caret.
You are a meager designer/coder, far less important than any of their active users.
Apparently, losing an active user is a big deal for most browser manufacturers.
I have html of all the iframes embedded in the page. I want an accurate method to detect which iframes were invisible. The invisibility can be achieved by placing a transparent image, or making iframe size zero or making seamless="seamless", or using "invisible" attribute value. Is there a tool or method that we can use to quickly identify number of iframes invisible to human eye.
thanks
Get the iframe's bounding rectangle, compute its area and whether. If the area is greater than zero then probe each corner with document.elementFromPoint(). If none of the corners resolves to the element then it's probably invisible. This checks whether it's hidden beneath other elements or possibly outside the overflow box of its parent containers.
You also need to check whether any of its corners has positive coordinates, since browsers don't let you scroll to negative offsets.
Do note that this method is not perfect, there are some edge-cases it may not cover, e.g. a transparent <div> with pointer-events: none; laid over the iframe has practically no effect and thus the iframe might as well be considered visible.
The invisibility can be achieved [...] making seamless="seamless"
That doesn't make an iframe invisible
Long story short, I've been using sprite sheets and some of them might have quite huge dimensions. To get the image I need, I use the css attribute clip: rect(top, right, bottom, left), but something strange about clip is that whatever that is hidden is indeed not visible, but adds to horizontal (and probably vertical) scrolling to my browser when the browser window is small enough that part that would have been visible does not fit into the browser window even though they are not visible.
I found that adding a overflow: hidden attribute to any parent of the clipped image solves the problem.
The reason I'm asking here is, if it was my own pages, I'd just add that overflow: hidden to my html tag and be done with it. However, I'm making a jquery plugin and while I'm probably not skilled enough to make plugins that other people will use, I still want to make my plugins well behaved. If I add the css attribute through jquery to the html tag, would it cause unforeseen problems?
I would recommend using background position instead. As explained here: http://css-tricks.com/css-sprites/
It is more industry standard and you won't get those weird issues.
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).
I have a iframe. The markup goes something like this:
<iframe height="350" frameborder="0" width="100%" scrolling="auto" src="someurl.php" style="z-index:100;overflow:auto;">
</iframe>
As you can see iframe's height is fixed and 350.
In someurl.php I have a slider as the 1st element that moves vertically in up direction. I tried to set z-index of the slider to 1000 but no luck, my iframe just hides the slider behind it.
How can I solve this issue?
"In someurl.php I have a slider as the 1st element that moves vertically in up direction."
The contents of an iFrame can never exceed the boundaries of the iframe.
When the scripted element inside the frame "moves up vertically" (absolutely positioned), it's not visible any more.
If the frame and parent window are hosted at the same domain, you can inject the element (from inside the frame) to the parent window, so that the element "seems to go outside" the frame.
i'm not sure if i understand you correctly, can you maybe post a link so we can see the problem?
in any case, the z-index on a page shown in your iframe isn't affected by the z-index of the iframe itself (the iframe has its own DOM). also, z-index behaviour is sort of browser-dependent (especially if you're using IE versions earlier than 9; in such IE versions it will negatively inherit z-index, so all parent elements must be given an index as well).
is the iframe-content from a different site? if not, i'd concider javascript to populate a div in stead of using an iframe.