I am creating a 3d carousel with CSS3 and jQuery. This is my code.
Currently, my problem is that if I set this line of css code to main class, the location, and the zoom of everything will be changed:
-webkit-transform: rotateY(20deg) ;
My question is, how to rotate the main class without any other changes?
The problem is your -1000px margin on .main. If you get rid of it, you can start to apply rotations to that DOM element.
http://jsfiddle.net/upEC6/53/
Try using negative degrees to rotate.
This is a really interesting issue. I'm using Google Chrome and have not tested in Safari, but it appears that at least Chrome seems to create a new painting stack when -webkit-transform is used. If you notice, <div class="main"> no longer has a height. It's as though the contents of the element have been abstracted from their parent.
In any case, I noticed that it becomes visible again if you give it a static height instead of a percentage (like 500px) and if you remove the negative margin (which doesn't appear to do anything anyway).
Related
I'm working on a user interface based largely on flexbox, that can basically be broken down into a content area and a sidebar which can be toggled (its width is changed by adding/removing a class).
When the sidebar is toggled, the content area is manually resized through javascript. It contains an svg canvas which needs to be redrawn, so this cannot be done through CSS. Chrome handles this code perfectly.
Firefox and Safari, however, behave very strangely, and interestingly not in the same way.
I was able to reproduce the behavior in a fiddle: http://jsfiddle.net/q1yp6ssw/21/
It also happens with a regular <div>, it's not just <svg> as you can see here: http://jsfiddle.net/mqok5exb/2/
toggleSidebar() calls the function resizeSvg() which resizes the "svg" element using the size of its parent.
function resizeSvg() {
var width = $svg.parent()[0].offsetWidth;
$svg.attr('width', width);
$svg.find('text')[0].textContent = 'width: ' + width;
}
If you're testing these fiddles in Firefox, you'll notice that the content area resizes too early, and becomes larger than it should be, pushing the sidebar outside the container's original dimensions. Using setTimeout to delay the resize did not work.
It seems to be a problem with timing and when each browser renders the updated size of the parent element. The behavior is the same without the transition, so that's not the problem.
My question: What is causing this and how do I fix it, or at the very least find a usable workaround? If it turns out to be a flexbox problem, then flexbox can be replaced.
Thanks!
I know this is old, but I'm trying to do something similar and in my case changing width with javascript (angular) results in 50px lower than calculated width.
If you want to set exact value for flex you should set both width and min-width with your javascript code.
here is a code which solve my problem:
el.style.width=String(newWidth)+'px';
el.style.minWidth=String(newWidth)+'px';
Recently, I was writing code for a website template that required some element animation. Naturally, I decided to get my jQuery on and use some of its standard libraries to animate my div. In this case, I wanted to use the slideUp() function. When I coded it up and ran a trial, I noticed that the animation was very choppy, so I decided to look for clues here and on the internet and came up fairly short.
The question Div slideUp and slideDown animation choppy with inline-block display provided some hints, but nothing that I would end up actually using. So I am wondering: how have you dealt with this, per scenario, in the past? I will be posting an answer with the solutions I found to be helpful.
The Terrible min-height/min-width
The first and most common bug I have run into is the use of min-height or min-width. As noted here, it will cause the animation to be jumpy regardless of your standard height setting. Why does this happen?
Let's say you have a div that has a height of 75 pixels and a min-height of 50 pixels, and you wish to use some animation function that reduces the height of that div to zero (such as slideUp()) When the animation starts, it will begin to subtract from the total known height. When it reaches the set min-height, it will attempt to set the div height lower, but will not be able to and stick there until the display:none is added to the element's style, causing that presumed "choppy animation". It's not actually choppy: it's failing. If you were to run a standard animate() such as $("div").animate({ height:'0px' )}) on a div with a min height set (greater than 0), you would find that the animation simply sticks at the set min-height.
The solution to this problem is to simply unset any min-height for the div in css or to set min-height: 0; if the min-height is declared elsewhere.
The unfortunate no height/width
Another common bug is to simply set no height (or width, depending on the direction of the animation) on the object at all. This can cause the animation function to jump because of an incorrectly calculated height that it needs to adjust for. An unset width/height can have varying results and might succeed or fail depending on the DOM around and contained in it. It is best practice to set a height and width on any element one wants to animate. Percentage heights/widths are fine.
Padding/Margin Bloody Padding/Margin
You might run into a problem with choppy animations caused by collapsing padding/margins of the element you are attempting to animate, or any elements inside it. This is a simple problem fixed by adding a border: 1px solid transparent; to the element you are animating. This creates a bounding for jQuery to use so that it essentially ignores the collapsing padding/margins.
I am trying to create a HTML site with CSS styling and run into the following issues:
Depending on monitors size, my HTML element's positioning changes. So if It's a bigger screen, then lets say everything fits correctly. But if you open it in a smaller screen, not everything is displayed!
If I zoom in the browsers view, the elements begin to overlay each other - yet I want to stay where they are (even if that means they wont be displayed on screen due to a high zoom IN).
(I cannot post images yet, so I'm adding a link to the picture to explain abit more):
I am also posting a fiddle where you can see my CSS for the MENU and the HTML part that is connected with it:
I have to write some code, but my code is too long and wouldn't look nice.
My Fiddle
It would be really nice of you, if you can help me out here. If it's a problem more complicated to explain on how to fix it, I'd kindly ask, if you can change my fiddle to a working version (if it's not too much to ask).
I have checked already similar Questions, but there were no efficient answers that helped me to solve my problem.
So, the reason that you are getting this behavior comes down to the fact that you have set your two buttons to each be fixed with the position set to %. This means the position of each is calculated as a percent relative to the 'viewport' (the browser window). If the window is only 500px wide, then your 40% left position button sits at 200px and the 50% left position button sits at 250px, thereby causing them to overlap.
Generally, I would not use fixed positioning here, but it's really not possible to provide a better alternative without seeing more of your code. (Perhaps you'd like to get feedback in general by posting all of your code on CR).
You can solve the problem by wrapping both elements in a div and give that div your fixed position values for the first element and allow the second button to be positioned relative to the first.
Here's an example of that approach and your updated fiddle:
Change your HTML:
<div class="btns">
<a href='index.html' class='button_lay'>NONE</a>
<a href='dft.html' class='button_dft'>NONE2</a>
</div>
Add a rule for the .btns class to your css and remove the fixed positioning from each of the buttons:
.btns {
position: fixed;
top: 80%;
left: 40%;
min-width: 300px;
}
I’m having an issue with a container holding the marquee and i’m not sure what’s causing it.
Essentially, the container is stretching way too far, causing the animation to flash across extremely fast (because the animation accounts for the width).
I don’t want to state a width for the marquee because I want the container to stretch to whatever its siblings width is.
I’ve created a fiddle to display what’s happening. In the fiddle, i’ve included the exact html included on my own webpage.
I assume there’s an issue with the css of one of the other elements, but what? What's causing the container to stretch to extreme lengths?
FIDDLE: http://jsfiddle.net/uz9pG/
This is the jquery plugin marquee that i'm using http://jquery.aamirafridi.com/jquerymarquee/
Tables, fluid widths and overflow hidden tricks don't really get along well. You'll either need to change your code to use a different markup structure or put a fixed width on one the containing divs within your <td>.
Also, you have conflicting settings in your JS vs data-attributes in your markup. <div data-duration="2000" data-direction="right" class="marquee">
Here's a working version. http://jsfiddle.net/uz9pG/2/ Takes a second for the marquee to start. You'll need to adjust your margin code to sort that out. This one removes the tables altogether but you can just as easily add a fixed width to something like your .module_content div if that works for your design.
.module_content {
width: 400px;
overflow: hidden;
}
This is probably the most bizarre thing I've encountered in my years of website coding, so I thought I would run it by some people who are way smarter than me to try to explain why this is happening. If there's no explanation, I'm probably going to submit it as a bug report. It took me forever to actually suss out the cause of the problem.
The following behavior I can only produce in Firefox (version 15, currently, and maybe some others). No problem exists in Internet Explorer, Chrome, or Safari. It's so difficult to explain that I just created a demonstration here: http://sandbox.uatu.net/dom-changes.php
The general idea is that under a very specific set of conditions, DOM changes are getting held up by Firefox when a scrollable box is scrolled, whether the scrolling is done by the user or is automated by a script. Here's the set-up:
<div id="superContainer">
<div id="subContainer">
<div id="mainPage">
scrollable box in here
</div>
</div>
</div>
Important attributes:
superContainer has height and width dimensions
subContainer has a height dimension
subContainer has an opacity setting less than 1
subContainer has a background color
mainPage has a position attribute of absolute
Anyway, what you'll see if you visit that demo page is that attempting to scroll the box freezes up all page animations. You can actually watch some of these elements in Firebug and see that the properties are changing in real time, but Firefox is just refusing to repaint anything on the page.
If you toggle any of these attributes into an off position, everything is fine. It's just this particular combination of settings that seems to produce the problem.
Does anybody have any thoughts as to why? I can't tell you how crazy this drove me--I was basically troubleshooting it all weekend, totally refactoring my code on the site where I discovered it.
Seems to me that the opacity + position absolute are the culprits here, read the w3 specs on transparency to understand how engines render and threat opacity.
http://www.w3.org/TR/css3-color/#transparency
Since an element with opacity less than 1 is composited from a single
offscreen image, content outside of it cannot be layered in z-order
between pieces of content inside of it. For the same reason,
implementations must create a new stacking context for any element
with opacity less than 1. If an element with opacity less than 1 is
not positioned, implementations must paint the layer it creates,
within its parent stacking context, at the same stacking order that
would be used if it were a positioned element with ‘z-index: 0’ and
‘opacity: 1’. If an element with opacity less than 1 is positioned,
the ‘z-index’ property applies as described in [CSS21], except that
‘auto’ is treated as ‘0’ since a new stacking context is always
created. See section 9.9 and Appendix E of [CSS21] for more
information on stacking contexts. The rules in this paragraph do not
apply to SVG elements, since SVG has its own rendering model ([SVG11],
Chapter 3).
If you remove position: absolute from #mainPage you will notice the bug to be gone, you might want to file the bug anyway and think of a plan B for your implementation.