I found a bug in Chromium.
It seems that the engine renders transitions in some kind of special layer. Part of content which overflows over border-radius should be hidden, but it is not.
Look at this example: http://jsbin.com/nijavunoqe/1/edit?html,css,output
Hover mouse over color squares. You will notice that while animation corners are visible. And furthermore it affects neighbour element. Firefox and IE are ok.
So, the question is: Is it possible to find a way around this bug and get it to work as expected?
.container
border: 1px solid red
width: 200px
height: 200px
border-radius: 20px
overflow: hidden
margin-bottom: 10px
img
height: 220px
width: 220px
margin-top: -10px
margin-left: -10px
cursor: pointer
transition: width 1s, height 1s, margin-top 1s, margin-left 1s
&:hover
height: 240px
width: 240px
margin-top: -20px
margin-left: -20px
You can use this code in the mean time for chrome. Those transforms are broken as hell I've never even noticed.
Just note that I changed your .content to img. It didn't work straight off the bat with .container but I'm sure you can tweak it from here.
Related
My problem as stated in the title is about chrome's sub-pixel rendering. Sometimes you want the browser to determine an element's proper height or width so it takes up all the available space. And that's how floating point values appear. When the numbers after the decimal are high, it seems to get imprecise and make weird spacings. Changing the box-border property doesn't change the result. I made a codepen showing the problem, make sure to use a browser supporting sub-pixel rendering. As you zoom in you can see a space between the border and the pseudo-element.
* {
box-sizing: border-box;
}
div {
position: relative;
width: 100.98px;
height: 100px;
margin-left: 2px;
background-color: aqua;
border-radius: 10px;
border: solid 1px #000;
}
div:after {
position: absolute;
content:'';
width: 15px;
height: 100%;
right: 0;
background-color: black;
}
<div>
Turns out that rounding the width and height doesn't solve the problem at all; it's not about the float values (could be a factor). After some experimenting I found a trick of sorts. If you somehow manage to throw in a right: -1px or a left: -1px to the element's style it will no longer get weirdly spaced out (right: 0 or 1 doesn't work). I tested it with a resizable element. You can move it back into it's original position with transform: translateX(-1px) and there it is. No more subpixel gaps between elements. I made a codepen showcasing the solution: https://codepen.io/m4tex-the-sasster/pen/zYaMdwv
Goal: In the current demo, theres a padding between the last word in the textarea field and the bottom border (the bottom border is realized through a "background" property).
Demo:
https://jsfiddle.net/7vaf1th8/336/
Thats how it looks like (And its correct, thats exactly what I want!):
In Webinspector:
Problem: As soon as I focus into the textarea, hit Enter and type some characters in, the characters are far too low near the bottom border (because the padding-bottom gets ignored), it looks like this (Which is wrong):
In Webinspector:
I've tried to set a calc(100%+7px) background position, to keep the space / padding between the bottom border and the characters, but no attempt was successful.
How can I remain the padding / space between the text and the bottom border while typing? (without disregarding/loosing/deleting the "background" property (border on the bottom), because I need it?)
in the .form-group .form-control you can change the padding to 0px and it will remove that extra: https://jsfiddle.net/7vaf1th8/349/
.form-group .form-control {
margin-bottom: 7px;
border: 0;
background-image: linear-gradient(#66bb6a, #66bb6a), linear-gradient(rgba(165, 181, 203, .5), rgba(165, 181, 203, .5));
background-size: 0 2px, 100% 1px;
background-repeat: no-repeat;
background-position: center bottom, center calc(100%);
background-color: transparent;
transition: background 0s ease-out;
float: none;
box-shadow: none;
border-radius: 0;
resize: none;
margin-top: 7px;
padding-top: 0 !important;
height: auto;
padding: 0px 0;
width: 100%;
color: #555;
display: block;
}
I've fixed it on my own now.
Ive created a parent class for the parent element, changed the background propertys to this parent element and deleted it on the child(textarea) element.
Now the padding works as expected.
Note: It seems to be a fact, after reading similar questions, that padding is not working in webkit on textareas "as expected". It doesnt seem to be a bug, just the way webkit handles padding when the scrollbar starts to appear on the textarea.
I'm trying to create a CSS transition which gives the desired result in Chrome, but IE (10 and 11) and Firefox (41) differ (each gives a different result, but they all fail to display the border, see for yourself in the Codepen linked below):
<div class="box"></div>
.box {
width: 200px;
height: 200px;
background: green;
margin-top: 20px;
margin-left: auto;
margin-right: auto;
transition: all 1s ease-out;
box-sizing:border-box;
border: 0px dotted green;
box-shadow:1px 1px 20px black;
}
.box:hover {
border: 99px dotted green;
background-color: red;
border-radius: 500px;
cursor: pointer;
transition: all 0.5s ease-out;
transform: rotate(2turn)
}
http://codepen.io/anon/pen/EVvrYx
Would you say this a bug in both IE and Firefox? Because the definition of border seems quite straight forward and consistent with the behavior in Chrome.
Yet both FF and IE show nothing at all in the final transition state.
(btw also fun effects if you hover over the edge of the figure in Firefox, not a bug though I guess but only occurs in FF)
To have a round div you set the border to 50% of the width/height, more might cause unpredictable result, which might explain the border differences.
If you change the border from 99px to 9px and set the border-radius to 100px it seems to work in IE/Edge/FF/Chrome equally, though the dotted border differs.
And according to this, Firefox has a border/radius bug, https://bugzilla.mozilla.org/show_bug.cgi?id=382721, where when you combine border-radius and dotted style, it shows a solid border instead of a dotted.
The Version of the browser might be the issue, I was using IE8 previously and telerik controls were not updated in it. Make sure you update your browser and check if you can see similar behavior.
I have a simple page with two offcanvas menus, one in which side, they both work normally when in english, but since I also need to support arabic, I use the dir="rtl" in the html tag, and with it the right offcanvas menu have some weird behaviour on Chrome, looks like a repaint issue, when I resize the window it goes to the right position (sometimes it goes randomly after a few seconds as well).
I'm using transform: translateX(); and transform: translate3d(); in the body to achieve this, and as far as I can see there's nothing wrong.
Here's a codepen example of the bug: http://codepen.io/Ghostavio/pen/WbgXXZ
Its a simple thing I did Hope This is your answer
What I did was made the body position Fixd
in body:
position: fixed
Your New CSS will look like this:
box-sizing: border-box
body
padding: 5%
position: fixed /*Changed Here*/
overflow-x: hidden
transition: .3s ease-in-out transform
&.left-offcanvas-active
transform: translateX(270px)
//transform: translate3d(270px, 0, 0)
&.right-offcanvas-active
transform: translateX(-270px)
//transform: translate3d(-270px, 0, 0)
header
text-align: center
position: relative
img, svg
vertical-align: middle
a
text-decoration: none
.logo img
width: 240px
max-width: 100%
.gc
fill: #8E8E8E
.content
text-align: justify
.hamburger-icon
position: absolute
top: 10px
left: 0
cursor: pointer
.second-icon
left: auto
right: 0
.left-offcanvas, .right-offcanvas
witdh: 270px
min-width: 270px
height: 100%
background-color: #BABACA
position: fixed
display: block
top: 5%
.left-offcanvas
left: -270px
.right-offcanvas
right: -270px
.offcanvas-links
display: block
padding: 20px
color: #117EBF
border-bottom: 1px solid #E1E1E1
font-weight: 800
text-decoration: none
span
background-color: #C80428
color: #FFF
padding: 0 5px
border-radius: 2px
font-weight: 400
float: right
Hope this helps you.
I had a similar issue creating a sticky header on a horizontal scrolling table for RTL. What I found is that in order to get position : sticky to work for RTL without JS, I had to assign z-index to both the sticky column (sticky header) and the scrollable columns.
At first I used JS to position everything and add offset padding to get the sticky header effect. But after a walking away in frustration and returning to it days later did I come up with a CSS only solution.
JSfiddle example
Chrome is working fine in containing an image with an overflow:hidden rounded div, however safari does not do a good job at this, the overflow: hidden doesn't seem to work here.
here's an example
here is my sass code:
.profile-image-container
position: relative
top: 3px
display: inline-block
cursor: pointer
.profile-image
width: 33px
height: 33px
display: block
position: relative
border: 2px solid $default-border-color
position: relative
top: -5px
border-radius: 50%
-moz-border-radius: 50%
-webkit-border-radius: 50%
overflow: hidden
haml:
.profile-image-container
.profile-image
=image_tag "avatar.jpg"
%span.status.online
%i.icon.icon-check-small
fiddle:
http://jsfiddle.net/LB2EQ/
Problem 1. In Safari images don't inherit border-radius, so you'll have to add it.
Problem 2. Your image has a different width & height than the profile pic container which is why you'll see a very strange border-radius (only upper left) if you don't resize it.
.profile-image img{
width:33px;
height:33px;
border-radius:50%;
}
See working solution on jsfiddle: http://jsfiddle.net/LB2EQ/1/