This issue is about the CSS3 border-radius property (http://www.css3.info/border-radius-apple-vs-mozilla/)
An example of this problem is here:
http://jamtodaycdn.appspot.com/bin/rounded.html
In this URL, I have rounded divs that appear to be rounded in FF3, but on Safari and Chrome the rounded corners are not there.
The style is as follows:
-moz-border-radius-bottomleft:2px;
-moz-border-radius-bottomright:92px;
-moz-border-radius-topleft:92px;
-moz-border-radius-topright:2px;
-webkit-border-bottom-left-radius: 2px;
-webkit-border-bottom-right-radius: 92px;
-webkit-border-top-left-radius: 92px;
-webkit-border-top-right-radius: 2px;
I'm fairly sure that this CSS is formatted correctly, so I'm clueless as to what the problem is.
The problem appears to be in the 92px radia. It looks like the maximum radius that the 20-pixel-high div can handle is 18px. It's not necessarily obvious what a 92 pixel radius means in that case. However, you can specify both an X and Y radius using something like this:
-webkit-border-bottom-right-radius: 92px 18px;
(side note, you shouldn't use the same ID for multiple HTML elements. You should use class instead, and adjust your CSS selector so it says .round instead of #round.)
For anyone referring to this for help with rounded corners, I agree with Jacob's answer regarding Webkit, but the question also mentioned Chrome not working. Chrome uses standard CSS3 rounded corners which are exactly like Webkit's, but without the preceding '-webkit-' on the rule. These are as follows:
border-bottom-right-radius:2px;
To take into account Firefox, Webkit and Chrome, you'd need to do something like this:
-moz-border-radius-topright:3px;
-moz-border-radius-bottomright:3px;
-webkit-border-top-right-radius:3px;
-webkit-border-bottom-right-radius:3px;
border-top-right-radius:3px;
border-bottom-right-radius:3px;
The third set of rules are CSS3 rules and are supported by Chrome. This is a good way to also get rounded corners in IE using something like CSS3Pie: http://css3pie.com/
Don't you need to apply a border or border-width property as well as the various border-radius properties?
Also, I've noticed Safari dropping the radius above certain radius values - try reducing the pixel values & see what happens.
simple type just use:
border-radius:92px 92px 2px 2px;
where:
border-radius:top right bottom left;
Related
See this pen:
https://codepen.io/armandsdz/pen/xqGaoe
I have a simple Foundation grid and I set display:flex to "row" element in order to get all columns be the same height.
It all works fine in Chrome, Firefox.
But on Safari, Edge, Yandex browsers (any version) those columns are a pixel or so too wide and it results in them not fitting within one row. Therefore, it wraps to two rows.
See image
Setting flex-wrap: nowrap would be an option in case of only one line but it's often not the case.
And most importantly it doesn't solve the issue at its core.
What am I missing in this flexbox world or is it a bug?
Thanks!
Addition: It happens not only when column width is, for example, 33.33333% but also when it's 25%. So where does that extra pixel come from?
The :before and :after pseudo-elements are part of a clearfix hack to contain floats and prevent margin collapse. (See this SO question about that.) Flexbox essentially disregards floats, but older browsers that don't support flexbox would fall back to using the floats so they would need the clearfix. Based on #DannieVinther and #Armands' comments, there are two possible solutions:
If you want to maintain the clearfix functionality for older browsers that don't support flexbox, you can add a rule to set width: 100%; on the :before and :after pseudo-elements. This will give the pseudo-elements a width of 100% and a height of 0, so they won't mess with the width of the rows of actual content.
.row:before, .row:after {
width: 100%;
}
If you don't need/care to support older browsers, you can simply override the clearfix hack by adding a rule to set content: none; on the :before and :after pseudo-elements.
.row:before, .row:after {
content: none;
}
I have a composited div (it has translate3d) with an opacity transition:
#bad {
background-color: red;
-webkit-transition: opacity .5s linear;
-webkit-transform: translate3d(0, 0, 0);
}
If I change its opacity while transition is undergoing, it will flicker in Safari.
The flicker happens about once in three seconds and is akin to a white flash.
There is no such problem in Chrome.
Scroll up and down in this fiddle to see what I mean.
The problem does not seem to be limited to opacity—changing -webkit-transform while its transition is undergoing has a similar effect: once in a while the element is rendered in one of the transition's final states.
The problem goes away if I remove -webkit-transform but unfortunately that's not an option right now.
Can I fix this in Safari by some other means?
The problem is changing property values and adding animations need to happen at the same time.
A race condition not present in OSX 10.5 was introduced when Core Animation was rewritten in C++. I learned this when my experiments with additive animation developed the same flicker. I found the workaround to be Core Animation's kCAFillModeBackwards. I also found the same workaround was effective for CSS Transitions by hacking up my own fork of WebKit, with emphasis on the hacking part. But conjecture doesn't help WebKit devs and I didn't want to annoy them any further. I do think the problem is with Core Animation, not WebKit. I'm guessing that they should use the same CFTimeInterval derived from a single call to CACurrentMediaTime throughout any given CATransaction.
Unlike transitions, CSS animations do allow for fill modes. It might be difficult to reproduce transition behavior, but that is one option. In particular, the challenge would be replacing interrupted animations with new ones that begin where the previous left off. In other words, it's easy to animate from opacity of 0 to 1 or 1 to 0, but what happens if the user wants to start when current animated progress is at 0.577564? This might require manually modifying the #keyframes style rule, not an easy task.
Then there is the question of the appropriate animation-fill-mode. Normally you wouldn't want to perform layout using forward filling animations, you'd use the CSS properties themselves. But in this case it might be simple enough to not set the underlying value, instead use only a forward filling CSS animation that gets replaced but never removed when finished. The alternative is setting the underlying value via element.style and at the same time adding a backwards filling CSS animation.
Of course, the flicker also does not happen if WebKit doesn't use Core Animation. By far the easiest way to prevent the flicker in your case is to not enable hardware acceleration.
Instead of:
-webkit-transform: translate3d(100px, 100px, 0);
try:
-webkit-transform: translate(100px, 100px);
http://jsfiddle.net/z6ejt/9/
In my case I found 3 actions that solved the same problem:
I needed to fade in an image on the ready event, tried with the jQuery animation but the image was flickering on OSX Safari.
Solved with these actions:
1) Analyze the CSS and delete all transition rules applied on the image, they seem to conflict with the animation command.
I had this rule
img {
/*DON'T COPY !!!*/
-webkit-transition:all 0.2s ease-in-out;
-moz-transition:all 0.2s ease-in-out;
-ms-transition:all 0.2s ease-in-out;
-o-transition:all 0.2s ease-in-out;
transition:all 0.2s ease-in-out;
/*DON'T COPY !!!*/
}
I deleted it.
2) Add this CSS rules to the element you need to fade in:
display: none;/*initial state modified by the fadeIn function*/
-webkit-backface-visibility: hidden;
-webkit-perspective: 1000;
-webkit-font-smoothing: antialiased;
-webkit-transform-style: preserve-3d;
-webkit-transform: translateZ(0);
3) Use the jQuery function "fadeIn" and don't use the command ".animate({opacity: 1} ecc..".
These actions resolved the flickering problem on OSX Safari .
This seems like a bug in CoreAnimation.
Kevin Doughty blogged about it and provided a simple fiddle to reproduce it.
I am not certain, but I believe it is caused by a Core Animation bug rdar://problem/12081774 a.k.a. the flash of un-animated content.
[...]
I believe the Safari transition flicker is directly related to the bug I filed. The workaround is to use a Core Animation fillMode of kCAFillModeBackwards or kCAFillModeBoth. It seems like there is something wrong with animation timing, where a property value change and an animation started on that property within the same transaction don’t actually begin at the same time. A backwards fill solves this by extending the effect of the late starting animation to be applied before its actual start time.
Kevin also reported this as #115278 in WebKit and tried to tackle it but from my understanding he didn't proceed with this and the patch wasn't accepted.
Of course it's not a real answer (doesn't solve the problem) but at least it explains the problem.
The following CSS fix the transition flicker on safari
* {
-webkit-backface-visibility: hidden;
}
I want a padding of 10px on my select tag. With a text-indent I can make the padding-left work on Safari. But I want a padding everything not just left.
Is there any way to have it work normally on Safari? (I can't understand how something so elemental can be an issue nowadays!)
try -webkit-padding:....that should work. here's Apple's list of properties that safari supports...I don't see any differentiation between safari and mobile safari, but I know there is some...https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariCSSRef/Articles/StandardCSSProperties.html
Is this an Opera bug? Please compare this jsfiddle jsfiddle.net/n5hBf/1 with this one jsfiddle.net/n5hBf/2 You should see the difference in the height. Those two jsfiddles are the same except in the first one I set styles in one statement and in the second jsfiddle I set them one after the other. That works well in other browsers but not in Opera, so you'll definitely need the latest Opera to see what I am talking about.
EDIT:
Well, now I think it is not actually a bug but rather the way how word-wrapping is handled by Opera. It differs from how it works in other browsers such as FF, Chrome, and IE. If you add word-wrap: break-word; to the textarea element, you'll see what I mean: http://jsfiddle.net/n5hBf/5/
EDIT 2:
Problem:
Say, if we have a textarea element that is 100x100 in size and contains too much text to be fit inside the textarea element, the text will overflow, thus enabling the scrollbar(s) to appear.
Goal:
In the two jsfiddles, I was trying to expand the textarea element to the size that is large enough to accommodate the content without the need in scrollbars.
Wrong solution:
The first jsfiddle behaved badly in Opera because it expanded the height too much than needed. The second jsfiddle worked well in Opera (meaning that it changed its size to the actual dimensions needed for the content; not much, not less), though the result in Opera differed from what I could observe in the other browsers. In the other browsers, only the height got changed. The result was wider in Opera as it changed both width and height.
Understanding:
As I figured out, by default Opera doesn't break long words into lines but instead it adds a horizontal scrollbar. While the other browsers do break them into lines. Also, browsers render it so that the scrolling is added only for the sake of those long words while the rest of the content occupies the same width... And then I got the clue!
Right solution:
I understood that the actual dimensions of the content were defined according to the initial textarea's size, so one of the dimensions turned out to be invalid once we changed the other one. That is, if we change the width the height is no longer actual because the content spreads over the new width making itself shorter in height. That explains why the second jsfiddle worked as intended: firstly I got the new width and applied it, then the content occupied the new dimensions, and only after that I got the new height and applied it. So, if we need to change both width and height, we need to firstly change the width and only then change the height. In browsers other than Opera it was only needed to change one dimension, so there was no difference whether the styles were changed in one statement like in the first jsfiddle or they were changed in two statements like in the second jsfiddle.
The only reason it breaks in Opera is because it's the only browser that doesn't use word-wrap: break-word by default on textareas. So it's not a bug, simply a result of a different default style.
If you add word-wrap: normal to the textarea CSS in your fiddle it will break in the same way in the other browsers (except in IE, where it breaks in a different way).
Without word-wrap: break-word, the width is different from the scrollWidth, which means that changing it will affect the scrollHeight.
However, by doing this
$textarea.css({
width: $textarea[0].scrollWidth,
height: $textarea[0].scrollHeight
});
both the scrollWidth and scrollHeight are evaluated first before they are actually set. That means that that change in the scrollHeight which would be caused by changing the width is not taken into account.
Setting the width and height in separate .css() statements one after the other will mean the scrollHeight will have been updated before it is set.
Let's say i have a sprite with lots of icons. I want to place one of the icons in the specific position over the div, e.g. 15px from the right side and 20px from the top.
Previously, when i had single image file i used the following code:
background: white url(./imgs/some/icon.png) no-repeat 91% 47%;
Now then the image is in the sprite i can access it using
background-position: 0 -471px;
But as i see it there is no place to add my current 91% 47%. Is there some kind of workaround?
It's possible to use CSS3 in the project if it helps.
Thanks!
Would you be able to add another <div>, give it the correct background, and absolute position it where it needs to be? I'm thinking that your background-position percentages are probably out when you use a sprite sheet.
If I understand your set of constraints correctly, you might be able to pull it off with a single div, but only if your png has a transparent background and the icon has enough "transparent space" as to not reveal any other icons.
Try:
background: white url(./imgs/some/icon.png) 91% 47% no-repeat, transparent url(./imgs/some/icon.png) 0 -471px no-repeat;