Range input thumb gets offset over time - css

I've looked all over Stackoverflow and it seems that all range sliders with thumb labels have this problem. For example, this answer almost doesn't have it, but still does.
Basically, you can calculate value / max to get the left style for the range value label, so that it's always aligned to the thumb.
The problem is that the further right you slide, the more offset it gets. For example, in the linked answer the label starts off on the left side of the thumb at the 0 value, and it slowly slides to the right side of the thumb by the time it gets to 100.
Why is this happening? I'm implementing my own solution and it suffers from this problem. Also, every answer I've seen on Stackoverflow has this problem. What's causing it, and is there a good solution?
Here's a shitty GIF of the problem:

This is happening because the dot's center does not represent the value. Lets say the dot's size is 10px and the slider is 100px wide. When slider value is 0, the center of the dot is actually at 0px + 5px, i.e. 0 * slider_width + 0.5 * dot_width. When the slider is at 100% then the center of the dot is at 100px - 5px, i.e. 1 * slider_width - 0.5 * dot_width.
To fix this issue you need to subtract an offset value of (percent_as_decimal - 0.5) * dot_width. This will be negative when less than 50% so when subtracted it will add.
Now that above offset will only affect where the leftside of the element is placed. You will also need to place a translate of 50%, via transform: translateX(-50%); to the number's container to address the width of the number element.
To summarize:
1) align left side of number to center of dot
2) translate number to place the center of the number with where the left side was before.

Related

Moving overlapping sliding vertical images when scrolling

Basically, I'd like to understand how the effect with the vertically scrolling, but overlapping images on the amazing Beolit 15 works.
What I found out so far is that they use a container div which again contains four divs that are positioned absolutely to the upper left corner of the container. So far, so good. Apart from that, the four divs all have the same size, feature a background-image that is sized as cover, and have different z-index values to make sure that they are in the correct order on top of each other.
Then, what they added is a clip style that always starts in the upper left corner of each of the four divs, always has the same width, but they differ in their vertical length. The top-most is the shortest one, the second-top-most is the second-shortest one, and so on…
So far, I already have two questions:
How do they get the 673px width? Isn't this depending on screen resolution? Why is it exactly this value?
How did they get the height of teach of the clipping rectangles? Why exactly those values? (Of course, because otherwise it wouldn't work, but how did they get those values? I'm sure not by trial and error…)
Now, apart from that, you can see that when you scroll, basically all they do is update the lower border of the clipping rectangle. This way it looks as if they were sliding up, and move above the images, while they stay fixed.
What I do not get here is how they do this. Obviously they have somehow attached to the window.scroll event, but how exactly?
They add a .fixed class to div.images via e.startEngine() once it reaches the top edge of the viewport and remove it via e.stopEngine() when you scrolled through all images. This triggers the following styles:
.focus .images.fixed {
position: fixed;
width: calc(50% - 30px);
}
calc(50% - 30px) is probably the 673px you are searching for.
The style every image gets looks like:
height: 928px;
clip: rect(0px 597px 1856px 0px);
which can be expanded to:
height: [window.innerHeight];
clip: rect(
0px
[window.innerWidth / 2 - 30]
[
this.parentNode.parentNode.offsetTop +
document.querySelector('.inpagenav').offsetHeight +
(window.innerHeight * IMAGENUMBER) -
window.scrollY
]
0px
);
The scroll event is attached via e.Tools.bindEvent(window, "scroll", w) and the function w calls e.Tools.clipY() which sets the clip styles for each image.

how to move images from left to right with css3 animation?

here am trying to load 3 images from left to right and then wait for 3 seconds and then again load from left to right. This process is continues for every 5 seconds. here am not getting how to load it from left to right and loaded images should be on one line only.
I mean in this example, images are moving from left to right but they are going to next line. i dont want to go for next line. they just load one by one with some gap from left to right only.
in this [example]1, values are fade in fade out. but i wanted to go for like left to right like movemet/ load images(appear) from bottom to top/ load(appear) images from top to bottom
If you don't want items to go to the next line, then you need their aggregate widths to be less than 100% of the container.
10px + 80% + 10px + 80% + 10px + 80% > 100%
Edit
To expound: The problem is that your right margin is 80%
50% {margin-right: 80%;}
That means 80% of the page, which is too much. What you need to do is animate the left margin of the last two objects rather than the right margin of all three objects. The greatest left margin that you can have should be about 40%
50% {margin-left: 40%;}
Note that you shouldn't have multiple elements with the same ID in HTML, but you can have multiple classes, so your divs should look like
<div class="ui-block-b subdiv">
Note also that you need to close your img tags with /
<img src="img/images.jpg"/>

CSS - dynamically calculate width

I come across width: calc(25% - 20px + 5px);
I couldn't find any answer via google. I wanted to know how to get the width to be 410px for three boxes in each row, because right now it returns me 4 boxes in smaller width than 410px.
Any help or insight will be appreciated.
This method resolves the entire expression into a single value and then applies that to the element.
The thing you're trying to do would first calculate the 25% of the parent element as an integer value and then it would move on to the next operand. Then would calculate the result and will apply.
I think, you need to lessen down the parent element's width property. Then you'll see three checkboxes with a width of 410px.
Secondly, you can also try to make sure the expression is accurate while calculating the result for the width.
Try this fiddle: http://jsfiddle.net/afzaal_ahmad_zeeshan/D6sQ5/ To see, how calc() method works.

Logical explanation for CSS background-position?

For an application with a good lot of icons, I want to make an image sprite.
Since I started my 'adventure' in the land of webdesign/ front-end webdev, I've always wondered: what is the logic behind background-position: (left)<number>px (top)<number>px;
When you compare this to the shorthand property for either padding or margin(when only specifying top and left), these are both property: (top)<number>px (left)<number>px;
So top and left values are reversed.
Also, suppose I have a sprite that is 64px (length) x 16px (height) and contains a total of 4 16x16 icons. To get the second icon in the sprite (|____|_this_|___|____|), you have to type background-image: -16px 0px; instead of 16px 0px (which would be logical, because the second icon starts 16px later than the first one).
If you want an example (I know w3schools is not always correct but it will do for the example): http://www.w3schools.com/css/tryit.asp?filename=trycss_sprites_nav
So my question is: Why are all the values for the background-position property like,... reversed? Is there any logic behind it? Does CSS read the property from right to left?
When using shorthand for margin (or padding) with only two values you are not setting a X/Y position - you are setting four margins, using the same value for top & bottom (vertical margins), as well as right & left (horizontal margins). You can also pass four values and they will start with margin-top and continue clockwise around the box (top -> right -> bottom -> left).
I usually remember this using the word "trouble" without any vowels (TRBL).
Anyway: for positioning there is only two values, and it is common practice to use the vertical axis (x-axis, 0 is top) and then then horizontal (y-axis, 0 is left), so using a negative value for the y-axis on background-position would move a background the same direction you would move the box if you were to give it a negative left margin.
.class1 {
background-position: -20px 0; // move background 20px left
margin-left: -20px; // move box 20px left (margin, following items will also move)
}
.class2 {
position: relative;
left: -20px; // move box 20px left (position, following items will stay put)
}
So I guess what I'm trying to say is that the values are basically coherent, depending on how you look at it ;)
Docs for margin (check the syntax list)

Calculate translateZ for CSS Transform

I've run into an issue when using the transform property.
I have 1 simple DIV the fills the screen, and another DIV that sits on top of it.
I'm applying the following transform to the DIV on top:
'transform':'rotateX(Xdeg) rotateY(Ydeg)';
I'm also using preserve-3d
This works perfectly in all browsers except Safari. From what I've read, Safari is the only one that actually gets this correct, and clips the top DIV which the transform is being applied to. The other browsers don't clip the DIV. Basically, when the DIV is rotated, it's going inside/behind the bottom layer DIV.
So, I'm assuming that I need to use translateZ to pull the top DIV forward?
My question is, how would I go about calculating how much I need to translate the div forward along the Z axis, or getting this to work in Safari? The rotate X and Y will be variables, so users might be able to rotate the element along either the X, Y, both or none at all.
Any help on this would be amazing. Thanks!
Are your X and Y values always positive ?
In this case,
transform-origin 0% 0%
should do the trick (making the rotation center be the point that will be the lower in the result)
if not, you only need a little logic:
if your X angle is positive, x origin is 0%, else x origin is 100%
if your Y angle is positive, y origin is 0%, else y origin is 100%
and then, apply
transform-origin x-origin y-origin
I am unable to reproduce your problem without a jsFiddle. You could use a function like element.getBoundingClientRect(). This will give you the current coordinates of the second transformed div. If you compare these with the coordinates of the first div you should find the needed translateZ. You need to compare all 4 corners of the transformed div. A negative DELTA means that that corner is intersecting the first div.

Resources