I am rewriting CSS (don't ask why) in a way that I'm changing the style attributes via HTMLElement.setAttribute method. The problem sometimes occurs when I have computed styles that make no sense. For example (which happens most frequently), div parent has height value smaller than his child div element, in the computed styles. This makes some problems with the desired layout of the page. It is not easy, actually it is very hard, for me to change the algorithm that rewrites CSS, so does anybody know what is the cause of the problem and what would be the most appropriate way to solve it.
My assumption is that somehow some of the changes are not applied, thus I should force the css parser to recompute the values. Did anybody encounter such problem?
Assuming you are still trying to display your container at the height that you specify, even if it is smaller than the content that is inside it, you should use the overflow property.
overflow: hidden will cause the extra content to disappear.
overflow: auto will add a scrollbar to the container to allow you to scroll in the container.
Related
I'm developing a slide in/out panel using HTML and CSS.
I notice in some CSS code examples on the internet that they set the visibility property of the div to hidden once the div is completely out of view (via some negative margin-left index or some other), and obscured by overflow: hidden of its parent container. (and then back to visible when the user slides it out again)
However, in other examples they ignore this property, instead relying on the fact that it is completely hidden due to being out of view already.
I'm curious of the differences of these two approaches. One example I can think of is performance: I'm ignorant of whether or not browser rendering engines apply better optimizations to elements that are set to visibility: hidden, because it is guaranteed that they will not be seen.
Or is the browser smart enough to realize it is not being shown? Or does none of this matter, and the performance is identical regardless of whether it is visible to the user, hidden by overflow, or hidden by visibility: hidden?
Does anyone have any insight into this? Or can recommend the best practice?
There was an interesting study done on this actually which can be found here
To save you reading it, I'd say this is the main bit you're probably after:
The renderers correspond to the DOM elements, but the relation is not
one to one. Non visual DOM elements will not be inserted in the render
tree. An example is the "head" element. Also elements whose display
attribute was assigned to "none" will not appear in the tree (elements
with "hidden" visibility attribute will appear in the tree).
Basically saying, setting an element to have a visibilty of none will not stop it getting rendered but using display: none will.
In regards to the coding examples you spoke of, I'd say it's personal preference. Some people will set the visibility to none to maybe double-cover for themselves in the case that the hidden element gets put into view but doesnt need to show a particular element, maybe also to prevent the horizontal scroll bar from appearing too?
It's definitely not needed or required though and I'd personally leave the visibility property alone in this case.
I am building a web app where - as part of the UI - I have an occasional, temporary need for some extra elements in the DOM, which are therefore dynamically inserted. When they have served their purpose, they are hidden and then for good measure removed using jQuery's .remove().
For some reason, removing the elements creates a jump and a relocation of the viewport contents (reside within an iFrame) as if it is re-rendered despite the fact that the elements are hidden and therefore should not have any influence on the rendering of the content.
I have tried to remove the elements from the console instead of in my script and the jump still occurs. I have also seen a similar effect in Firefox.
I might end up keeping the elements if there is no solution, but if any of you have experience with a similar scenario and know of a solution, I would be very interested to hear it. Thank you very much.
UPDATE
After much scrutiny, I have finally pinned down the cause of this "error". It originates at the beginning of the content, which starts out with a h1 headline. The headlines have been styled with a top padding, except for the first child, where it is set to zero with a h1:first-child rule.
Now, the dynamic elements are inserted at various locations including before the first headline. Apparently, the dynamic element now becomes the first-child even though it is not rendered and therefore the general padding rule for the headlines becomes active and the headline receives a top padding. This causes it to jump up when the dynamic element is removed and it again gets a top padding of zero.
So I know the cause of this but I am not sure how to best solve the problem since the content as well as the styling is dynamic - ie. I do not control it and therefore can not simply replace the first-child rule with something more suitable.
IMHO it is completely unintuitive that the first-child rule is affected by elements that should be taken out of the document flow with display:none. It should only take "visible" elements into account.
I have a sidebar navigation menu with children and sub-children which appear on hover. Here is a jsfiddle link: https://jsfiddle.net/s096zfpd/
This is obviously heavily simplified just to give an idea of what I'm trying to accomplish. My issue is that sometimes the list within <nav> exceeds the height of <nav>. In this case, I want to be able to scroll within <nav>, but doing so would compromise the overflow-x:visible property which I need to display .sub-nav, since CSS simply doesn't allow the simultaneous use of overflow-x:visible and overflow-y:scroll.
I'm thinking that maybe a js solution could work well here. Any suggestions?
Thanks.
If you are using visible for either overflow-x or overflow-y and something other than visible for the other. The visible value is interpreted as auto It means that we can not apply visible and hidden to same DOM element, so ideal solution would be
To create a wrapper and then apply overflow-x and overflow-y to two different DOM elements. Sharing the js fiddle solution to your problem
https://jsfiddle.net/e2edvupc/
I'm trying to replicate jQuery slideDown() in GSAP and I'm having trouble working out how jQuery calculates the height of an item which is currently hidden as if it was set to height:auto.
I've tried trawling the code on GitHub but can't find any code which seems to be doing this in jQuery.fn.slideDown or jQuery.fn.animate which it calls.
There are several similar questions on SO and several solutions proposed, all of which seem to have their own problems:
Clone the element, position it off screen and calculate its height. This won't work if the element or any of its child elements have a height set by CSS styles which require the element to be in its original place in the DOM (e.g. an .accordianItem might only be styled if it's inside its .accordian).
Display the item, remove height:0 and quickly calculate the height before hiding the element again and then stating the animation. This might flash the content quickly while calculating the height.
Use visibility:true to show it in place while calculating the height. This would stop the flash and still keep the element in the same position in the DOM for correct height calculation, but it would still push other items below it down because visibility:false items still have a height.
Calculate the height of an item before it's hidden and store it in a data attribute so we know it when we want to open the item later. This won't work if any dynamic content changes the height of the item whilst it's hidden.
jQuery slideDown() "just works" every time so I'd be really interested to know how it works, but I just can't work out where it's doing this. I'm also surprised that GSAP can't do this out of the box, or that nobody has shared a proper solution to this before.
Any help would really be appreciated.
It turns out that if you use $.height() to get the height of an element with display:none it doesn't return 0 as you would expect, it actually sets visibility:hidden, position:absolute etc. and sets display to block to give you the correct height back. I assume this is what's being used internally when doing a slidedown.
This answer helped me a lot.
jQuery: height()/width() and "display:none"
Just to be clear about how this seems to avoid all the problems in my original question. It's basically doing number (3) but avoiding the problem of pushing lower content down the page because it's also set to position:absolute while the height is being calculated. A very simple elegant solution
At the moment I've been using the css line-height property in the parent div to increase the line spacing, and this works fine for the text, and even <input> elements. The only problem is any custom controls like the JQuery spinner or Chosen will try to fill up this entire line height (as they're set to display:inline-block)
Currently it appears like this:
How do I get these widgets to appear the same height as the text? I mean the default <input> elements can, so surely it's possible?
Find the element class/id and on your own style.css you can customize it's property with !important But use of !important is not considered as a good practice. (But if there's issue on one-or-two places, i think that is Ok)
Another way can be, why not making changes on jquery ui css that you are linked to.