This seems like it would be an easy thing to figure out, but I can't seem to find what I'm looking for.
I want to animate the width of a div from right to left. It seems that this works left to right by default.
TweenMax.from($("#hero-container"),0.5,{width:0});
I tried to change the origin of the div, but that didn't seem to make a difference.
You need to align #hero-container to the right edge of whatever container it's in, and then animate the width.
I prefer using flexbox, but you can use position: absolute; right: 0; too if that tickles your fancy - But that presents a whole new level of problems, as it removes your element from the document flow.
Quick example using flexbox: https://codepen.io/jeppeolesen/pen/VyKebx
Related
I want to create a click event that will have two photos on opposite corners of the screen move towards each other, once they collide, they move back in the direction they came from.
I am having trouble placing an image on the top right corner. I tried using "float: right" but when I tried that, my function does not work.
To place the images on the top right corner you should use absolute positioning:
.class {
position: absolute;
right: 0;
}
Also do you really need javascript to animate this?
It would be better and more performatic to do it with some CSS. Checkout this fiddle I made: https://jsfiddle.net/jv5et9L0/
In the fiddle I use absolute positioning to put the elements where I want, and then, through Javascript, I add apply the transform() property on my CSS. The animation occurs because I have set the transition property on the .item class.
I've been trying to create a couple of typical layout examples using Singularity, and I have a question about grid-span and floats.
I've created a sample scss stylesheet and html layout. Here's the complete example on Sassmeister.
http://sassmeister.com/gist/a7ca98b7520b12bd6241
My question is whether the containing content div <div id="content"> is necessary? I'm having to use it with a clearfix mixin in order to 'pull' the div down and keep the footer below the content section and aside.
Is there another way to achieve this layout with Singularity, without having to use the surrounding clearfix div? Is there an option for grid-span in the main section that will either not use a float, or self clear this section?
To understand your problem you have to learn how floats and clearing work.
0.
When you float an element, it is removed from the flow. It's vertical height does not count when calculating the height of the container.
1.
The intended usage of floats is to add images to a long sheet of text. The text would wrap around the floated image and increase its overall height and stretching the container vertically, just like an object submerged into water increases the height of water surface.
Before:
After:
2.
If the floated image is located very close to the bottom of the text, it will pop it's bottom out of the bottom of the container, just like an iceberg exposing it's top from the water.
3.
Now imagine that your text is comprised of paragraphs and each paragraph starts with a title. When there's an image floated at the bottom of a paragraph, the image would stretch into the next paragraph, pushing the next paragraph's title aside.
4.
If you don't want that to happen, you apply clearing to paragraph titles:
h2 { clear: both; }
This basically tells the titles: don't let floated images push you aside, let them push you down instead.
5.
But web pages have become more than formatted text, and HTML/CSS didn't provide any means of formatting layouts. So we started using floats for layouts. It's ugly, it's like using wallpaper to sew your clothes, but we have no better option (until Flexbox becomes a thing, and it seems to already).
What happens when you float all content in a container? There will be no flow left, no text to stretch the container vertically, and it's height will be zero (plus border and padding):
6.
You already know that in order to make containers regain their height (wrap around the floated content) we have to apply a clearfix to the container. But what a clearfix actually is?
When you apply a clearfix to a container, you use :after in CSS to create an additional element within the container, after all it's content. Then you apply clearing to the little mother fcuker:
.container:after {
content: '';
display: block;
clear: both;
}
7.
Now back to your question! What's the alternative of using the clearfix?
You've probably have guessed already.
If you've got got content below the floated element, simply apply clear: both to the next element below the floated one! Just like we did in #4 for paragraph titles.
In your case:
footer { clear: both; }
And here's a demo: http://sassmeister.com/gist/df8af8a3c7f8d3df2796
I'm trying to reposition the PanPanel and ZoomPanel controls on my map to the bottom left corner rather than the top left. I see that I can add options, but as much as I've tried, I can't find a way to tell it to stay to the bottom left, even when the window is resized.
I am also not sure how I will tell them to stack like they do normally when I tell them to reposition relative to the bottom left.
I changed the images that make up both panels, so now there's a bit more room between pan and zoom panels than I want, so I'm also trying to get them to come closer to each other.
On top of looking into using options on the controls, I also tried creating a style for the id of the div that surrounds both panels, but the value of the id in the div is "OpenLayers.Map_2_OpenLayers_Container", which contains a '.'. Far as I know, that's not a legal id for styling. Anyway, it didn't work. On top of which I don't think I can trust the name to always be the same, with continued work on this page causing a lot of additions over time.
Any ideas?
Try:
new OpenLayers.Control.YourControlXXXX({
moveTo: function (px) {
if ((px != null) && (this.div != null)) {
this.div.style.left = yourLeft + "px";
this.div.style.bottom = (yourBottom+controlHeigth) + "px";
}
},
... other options
})
ummm! I see that these controls are more modern than I thought, are positioned by CSS so try:
.olControlPanPanel {
bottom: 55px; /* not 0px */
top: auto;
}
NOTE: try as: div.olControlPanPanel {... to force the priority of CSS if you are not sure where position are loaded de css of OL.
So I found the problem. First I wasn't setting top to auto. Since it was set in the style.css file to 10px, and when I changed it in the style.css file it to auto the bottom worked. But then my css file wasn't working. I found an OpenLayers example for Pan and Zoom, and eventually found that the difference between what I was doing and what they were doing was that I hadn't loaded the style.css file explicitly at the beginning of the page. So it seems that the OpenLayers Map, when it is created, causes the style.css file to be read late, after my css was read, and so it overrode my override. When I did an early load (beginning of the page) it worked perfectly.
Seems that the attribution control, created when I create a map Layer, must read the current CSS, since the map hasn't yet been created on the page, and so it never needed for me to do the early load. If I remove the early load, it still takes the changes made from my css file. But removing the early load causes the Pan and Zoom controls to no longer respond to my changes, so I assume this means that the Map object is reading the styling after the late load of the style.css file, which at that point has already overridden my css.
Go figure...
Just in case this might be of use to anyone else. I'm using OpenLayers 3 and I wanted to move the zoom controls to the righthand side of the map. My map is attached to an element with a 'tm-openlayers-map' class value and to move the zoom controls I used the following css/sass
.tm-openlayer-map
//change the colour of the map buttons
button {
background: $title-bar;
}
.ol-zoom {
top: 0.5em;
right: 0.5em;
left: auto;
//move the tooltips to the left of the now right aligned buttons
.ol-has-tooltip:hover [role=tooltip] {
left: -5.5em;
border-radius: 4px 0 0 4px;
}
.ol-zoom-out.ol-has-tooltip:hover [role=tooltip]{
left: -6.2em;
}
}
//make sure the rotate controls included by default with an opacity of 0 don't
//block clicks intended for the '+' button
.ol-rotate {
visibility: hidden;
}
}
I want to accomplish a preview of an image gallery that is wider than the screen, using overflow: scroll (or auto).
To the right, a shadow that overlaps the last visible image should indicate that more images are visible to the right.
Here is a Fiddle: http://jsfiddle.net/SBdLg/
First, I thought: Easy, give that image gallery a box-shadow: inset. But that will be shown behind the images.
Now, with an overlapping div that has position: absolute, I reach the desired effect BUT the box-shadow also moves when scrolling to the right.
IMHO, this problem would also occur when using an image containing the shadow instead of the div on top.
Is the desired effect possible by CSS at all?
Removing position: relative from the outer DIV and positioning the shadow precisely where you need it (this is the ugly bit) will help you achieve this.
Check the demo: http://jsfiddle.net/SBdLg/11/
The CSS2.1 spec mandates that overflow other than visible establish a new "block formatting context". This strikes me as odd, that a property whose obvious purpose is to hide overflow without affecting layout, actually does affect layout in a major way.
It seems like overflow values other than visible combine two completely unrelated features: whether a BFC is created and whether the overflow is hidden. It’s not like "overflow:hidden" is completely meaningless without a BFC, because floats historically can overflow their parent element, hiding the overflow without changing the layout seems sensible.
What are the reasons behind this decision, assuming they are known? Have the people who worked on the spec described why this was decided to be the case?
I asked about this on the mailing list on your behalf; the thread can be found here. In summary, this has to do with scrolling content for the most part:
Fundamentally, because if the spec didn't say this, then having floats intersect with something that's scrollable would require the browser to rewrap (around intruding floats) the contents of the scrollable element every time it scrolls. This is technically what
CSS 2.0 required, but it was never implemented, and it would have been a huge problem for speed of scrolling.
-David
Most likely, it refers to scrollable content in a box that may occur outside of the float's parent but would intersect with the float. I don't think this is related to rewrapping content around a float within a scrollable container, as that already happens naturally, plus the float would clip into the container and scroll along with the rest of its content anyway.
Finally this makes sense to me. In fact, I'm going to provide an example here so hopefully it makes sense to you and anyone else who may be wondering. Consider a scenario involving two boxes with the same fixed height and overflow: visible (the default), of which the first contains a float that stretches beyond its parent's height:
<div>
<p>...</p>
</div>
<div>
<p>...</p>
<p>...</p>
</div>
/* Presentational properties omitted */
div {
height: 80px;
}
div:first-child:before {
float: left;
height: 100px;
margin: 10px;
content: 'Float';
}
Notice the similarity to one of the examples given in section 9.5. The second box here is simply shown to have overflowing content for the purposes of this answer.
This is fine since the content will never be scrolled, but when overflow is set to something other than visible, that causes the content to not only be clipped by the bounds of the box, but also to become scrollable. If the second box has overflow: auto, this is what it would look like had a browser implemented the original CSS2 spec:
Because of the float, attempting to scroll the content would cause the browser to have to rewrap it so it doesn't become obscured by the float (and what should happen to the part that scrolls out of the top edge?). It would probably look something like this when scrolled to the bottom:
The catch here is that the browser has to rewrap the content every time it repaints it during scrolling. For browsers that are capable of pixel-based smooth scrolling — which is to say, all of them — I can see why it would be a performance disaster! (And a user experience one, too.)
But that's for when the user can scroll the content, right? This would make sense for overflow: auto and overflow: scroll, but what about overflow: hidden?
Well, a common misconception is that a container with overflow: hidden simply hides content by clipping and cannot be scrolled. This is not completely true:
While scrolling UI is not provided, the content is still scrollable programmatically, and a number of pages perform just such scrolling (e.g. by setting scrollTop on the relevant element).
-Boris
Indeed, this is what it'd look like if the second box was set to overflow: hidden and then scrolled to the bottom with the following JavaScript:
var div = document.getElementsByTagName('div')[1];
div.scrollTop = div.scrollHeight;
Again, notice that the content would have to be rewrapped to avoid being obscured by the float.
Even though this wouldn't be as painful for performance as had scrolling UI been available, my best guess is that they made boxes with any overflow value other than visible generate a new BFC mainly for the sake of consistency.
And so, this change was brought about in CSS2.1, documented here. Now if you apply an overflow value other than visible only to the second box, what a browser does is push the entire box aside to make way for the float, because the box now creates a new block formatting context that encloses its contents, instead of flowing around the float. This particular behavior is specified in the following paragraph:
The border box of a table, a block-level replaced element, or an element in the normal flow that establishes a new block formatting context (such as an element with 'overflow' other than 'visible') must not overlap the margin box of any floats in the same block formatting context as the element itself. If necessary, implementations should clear the said element by placing it below any preceding floats, but may place it adjacent to such floats if there is sufficient space. They may even make the border box of said element narrower than defined by section 10.3.3. CSS2 does not define when a UA may put said element next to the float or by how much said element may become narrower.
Here's what it looks like with overflow: auto for example:
Note that there is no clearance; if the second box had clear: left or clear: both it would be pushed down, not to the side, regardless of whether it established its own BFC.
If you apply overflow: auto to the first box instead, the float is clipped into its containing box with the rest of the content due to its fixed height, which is set to 80px in the example code given above:
If you revert the first box to height: auto (the default value), either by overriding or removing the height: 80px declaration from above, it then stretches to the height of the float:
This happens to be new in CSS2.1 as well, in that an element with height: auto that generates a new block formatting context (i.e. a block formatting context root) will stretch vertically to the height of its floats, and not just enough to contain its in-flow content unlike a regular box. The changes are documented here and here. The change leading to the side-effect of shrinking the box so that it does not intersect the float is documented here.
In both of these cases, no matter what you do to the second box, it will never be affected by the float because it has been restricted by the bounds of its container.
I know this will be a speculative answer, however after reading the specifications a few times here is my view on this:
What section 9.4.1 is talking about is any block element that does not fully contain or does not fill the containment space. For example when you float an element it is no longer filling 100% of the parent, like in-flow elements do. Inline blocks, table cells, and table captions are also elements that you can affect height and width but that are not intrinsically 100% of the parent (yes table>tr>td is one that would fill 100% of it's parent but it is designed to allow for multiple td's so the td doesn't count as it will automatically shrink to accommodate additional td's) this also applies to any overflow other than visible because it breaks the containment of the block element.
So if I am reading this correctly the way it works is the 9.4.1 section is referring to block elements that break the default containment rules of the block elements as specified by section 9.2.1