I have some code that, until recently, worked on all browsers supporting CSS transforms. It broke in the newest Chrome (37). I found the issue. The transform from the computed style of an element is not accepted by other elements.
HTML
<div class="one">One</div>
<div class="two">Two</div>
<span></span>
CSS
div {
width: 100px;
height: 100px
}
.one {
background-color: red;
transform: rotate(90deg);
}
.two {
background-color: blue
}
Javascript
var oneStyle = window.getComputedStyle(document.querySelector('.one'));
var oneTransform = oneStyle.transform;
document.querySelector('span').innerHTML = 'Tranform value is: ' + oneTransform;
var twoStyle = document.querySelector('.two').style;
twoStyle.transform = oneTransform;
Here is a Fiddle: http://jsfiddle.net/acbabis/0v8v2xd7/
The issue is that the second (blue) element does not rotate the same as the first (red) element is even though I told it to in the javascript.
This looks like a bug to me. Is it?
EDIT: My actual code was working in every browser but the newest Chrome, but it appears my sample code breaks in all browsers. I'd still like to understand why the above problem occurs.
EDIT 2: Got it to break in only Chrome 37 again. My guess is that it doesn't like the scientific notation; but then why would the computed style have it?
This is a fairly common problem, similar errors happen with older versions of Chrome and other vendors as well.
The usual fix is, as Hashem mentioned partly, to either change the rotation to something like 89.9deg or force GPU rendering by doing something like translateZ(1px) in addition to the rotation. Demo. In the future we can likely force this as well by using the will-change property
This is because browsers have trouble rendering certain things and rendering elements rotated exactly 90 degrees is one of those things. Sometimes they need a little help :)
Related
I have a circular image (a profile picture). This image may or may not be translucent so I've given it a background color to ensure that it's always visible. The problem I'm having is that the background color is visible even on images that are completely opaque (see figures).
After messing around with borders and padding I found a workaround. I found that adding an invisible border, and then removing it will fix the problem. To deal with images being dynamically added and removed, I do this on a timer (this was easier than injecting some code in all places where images are added to the page). This is what I've done and it seems to work but I don't like it.
setInterval(() => {
for (const img of document.getElementsByTagName("img")) {
if (img.style.border.length) {
img.style.border = "";
} else {
img.style.border = "0 solid transparent";
}
}
}, 500);
The <img> has the width and height attributes set to 32. It also has a border-radius of 16px and of course, a background-color.
Surely there must be a better way to deal with this than the setInterval above. Changing the border seems to be causing the element to be rendered again (and correctly). Perhaps there's a way to do this more directly?
Since this is a weird rendering issue, I should mention that I'm using Chrome 87.
I found another workaround that's a little bit more efficient. Whenever an image is added to the page, I attached an onload listener that updates the border.
img.onload = () => {
setTimeout(() => img.style.border = "0 solid transparent", 100);
};
This still feels like an ugly hack. Also, the edge around the image appears briefly before disappearing when the page loads. I'm looking for a better way.
I tried this out in Safari and updating the border doesn't help. It seems like I'll need to think outside the box.
Figure 1 - disgusting
Figure 2 - desired
Oh neat, what an interesting issue! Unfortunately I've looked and looked and looked and can't seem to see why this is happening. Triggering a reflow of any kind seems to fix it though, so whether you use the border or not should work.
However I think I've found another solution that would work without requiring a reflow, and that's using a radial-gradient background-image instead of a solid background color.
I set up an example pen here: https://codepen.io/xhynk/pen/ZEprxqq (it was easy to increment the ?4 to uncache the image and get it to "act weird" again.
Using this CSS for the background on the image, it seems to prevent the image from being close enough to "bleed" through the edge:
img {
background-image: radial-gradient(#000 70%, transparent calc(70% + 1px));
}
You could potentially drop the 70% down to 69% if you're still seeing it. I just tried to get it as close to the edge of the container as possible, and the +1px calc smooths it out instead of being jagged.
You can see in the following image, the first avatar has the radial-gradient applied and there's no bleed, and the second has the solid background: black instead which does.
I tried to replicate what you just told. And it seems to work just fine.
From what I understood, I am thinking of one possible error that is to replace fixed width of the image and set it to 100% and not care about the height of the image in the img tag.
Set the height and width of the image in your surrounding div and give that a background color.
<!DOCTYPE html>
<html>
<head>
<style>
img {
background-color: blue;
border-radius: 50%;
width: 100%;
}
#image-container {
width: 128px;
height: 128px;
background: lightseagreen;
}
</style>
</head>
<body>
<div id="image-container">
<img src="img_avatar.png"/>
</div>
</body>
</html>
Just copy paste it into https://www.w3schools.com/html/tryit.asp?filename=tryhtml_basic to see
You see, for some reasons some times I can't scroll to the bottom of the page (some times it happens in the middle too). Here is a screenshot:
Why does this happen? I can't create a jsfiddle, because I can't reproduce it since sometimes when I reload I have this problem, sometimes it works fine... It happens in a random way. I have no idea what might be causing this. It just stops scrolling before reaching the bottom. I know this might be classified as an open question but I just want to see, if anyone have had this problem. Any suggestions are appreciated..
UPDATED
Ok, here is the code I used to style the scrollbar and the scrolling, in CSS:
body
{
scrollbar-face-color: rgb(0,131,168);
scrollbar-track-color: rgba(0,131,168,0.8);
scrollbar-arrow-color: rgba(0,131,168,0.5);
scrollbar-shadow-color: rgb(0,131,168);
}
::-webkit-scrollbar-track
{
background-color: rgba(0,131,168,0.5);
}
::-webkit-scrollbar
{
width: 5px;
}
::-webkit-scrollbar-thumb
{
background-color: rgb(0,131,168);
}
in the javascript, "vista" is the main container, I wrote:
var vistaProfesional = document.getElementById('vista');
vistaProfesional.style.overflow = "auto";
vistaProfesional.style.overflowX = "hidden";
vistaProfesional.style.height = 100 + '%';
I have been thinking, and I found out that, when I was doing the whole thing, I wanted it to have a smooth scroll, therefore I used the smoothWheel plugin because it is easy to use and since I am new to programming this seems a charm. However, right after the code abode I wrote:
$("#vista").smoothWheel();
to initialize it and though it works, it is when this plugin is active that I have this issue. If I comment that line of code and stay with the normal scroll, the problem described doesn't occur. As for one of the comments, yes, the zoom is already in 100%
I have seen this problem in several websites before. Set your zoom level to 100% to allow you to scroll to the bottom of the page.
Often when the zoom is not equal to 100% there is a partial row that is not shown, so the website thinks that you have not displayed the bottom of the page, so won't fetch the rest, or update the scroll bar properly.
I think you should specify height to body and html because as for as i know Scrolling plugins need that, so
body, html {
height: 100%;
}
If this does'nt solve your issue you may use Nice Scrolling Plugin which has a lot of properties, also it has been documented very well.
Hope this helps you.
I'm using the library FlipClock.js to build an analog-style clock that uses a version of the CSS "card flip effect." Unfortunately, only after building out my project did I notice a long-standing bug affecting Internet Explorer 9 and below:
https://github.com/objectivehtml/FlipClock/issues/7
In IE9 and below, the clock time lags by one second (i.e., in the first second of animation, nothing visible changes), and the digits in the clock are also offset by a value of 1. My expectation is not for the CSS flip animation to work, but for the digits to change instantly as they currently do, only be correct.
I've been troubleshooting for a while but have yet to find a solution or even pinpoint the problem. I have a hunch that this isn't a script-related bug; I suspect that the digits are changing correctly in the HTML (hard to verify with IE's developer tools), but that they're just not showing as intended due to one or more CSS rules that were written not considering IE9's poor CSS3 support. I'm kind of expecting (or at least hoping) to stumble upon a CSS property or two that just fixes it.
The library is based on a proof-of-concept, which exhibits the same problem:
http://codepen.io/ademilter/pen/czIGo
I'm troubleshooting there to keep it simple, and if I find a fix, will submit a pull request to the FlipClock.js library.
I would greatly appreciate any help!
After removing the CSS animations and shadows, changing the z-index of li.before might do the trick (see http://codepen.io/cbuckley/pen/rysja):
body.play ul li.before {
z-index: 1; /* was previously 3 */
}
So you could use z-index: 1 by default, then feature-detect for CSS animations in the JavaScript and add a body class (say body.supports-animation). Then the relevant CSS might look like:
body.play ul li.before {
z-index: 1;
}
body.play.supports-animation ul li.before {
z-index: 3;
}
/* Prefix animation/background declarations with body.supports-animation too */
Caveat: I haven't tried this with FlipClock, nor have I actually tested on a browser without animation support, but I hope it gives one possible option :-)
Just changing the z-index will fix the problem for IE8 and IE9 but will break the transition for all modern browsers.
To Target specifically I8 or IE9 you can use this:
On your JS file add:
var doc = document.documentElement;
doc.setAttribute('data-useragent', navigator.userAgent);
then on your css you can detect IE8 and IE9 with this code (flipclock.css line 160):
/* PLAY */
.flip-clock-wrapper ul.play li.flip-clock-before {
z-index: 3;/*Original */
}
/*ie8 and ie9 fixes*/
html[data-useragent*='MSIE 8.0'] .flip-clock-wrapper ul.play li.flip-clock-before {
z-index: 1;
}
html[data-useragent*='MSIE 9.0'] .flip-clock-wrapper ul.play li.flip-clock-before {
z-index: 1;
}
That fixed the problem for me!
I have a background image for an input box..It works fine in IE/FF, but for some reasons it is not visible in iPad Safari..Below is the CSS for the same;
#rightContent .inputBox{
background:transparent url(images/keyback.gif) no-repeat scroll center 6px;
border:0pt none;
float:left;
height:40px;
#height:37px;
margin-left:10px;
width:450px;
overflow: hidden;
}
Please help. Thank you.
I would suggest splitting out the background style into seperate parts. Not all browsers support transparent (and possibly other parts of that style).
When a browser sees a style they don't know what to do with, they usually ignore the whole style. Putting the background-image onto it's own line (eg. it's own style) will let that property get picked up by browsers that can deal with it, rather than getting missed because it is lumped in with things the browser doesn't know about.
I believe the default value of background-color is transparent. Have you tried not setting a color? Also, since you have a set image with no-repeat, why not make the image a jpg/png and set a color to match the background-color you want.
I've had the same problem and have managed to get a working solution using jQuery
$(document).ready(function () {
var buttonsFilename = '<%=ResolveUrl("~/Content/Images/Buttons.png") %>';
$('.commands .command').css({
background: 'url(' + buttonsFilename + ')',
width: '55px',
height: '55px',
display: 'inline-block'
});
});
I'm using this within an ASP.NET MVC website, hence the <% %> tag.
I could only get it to work using the background shortcut css property. I couldn't get any of the following to work ...
background-image
backgroundImage
'background-image'
... when using the object notation. Unfortunately that wipes out any other background settings you may have. But I got around that by using another piece of jQuery to set my background-position property.
I am having the same problem, but I found that the image slice I was using was too thin to display on iPad. It is a texture, so I was using a 15px slice and an x-repeat, which is fine in all browsers but not iPad. After some experimenting I found that the threshold for iPad seems to be 130px.
I'm having issues getting Firefox to update a webpage when its class is changed dynamically.
I'm using an HTML table element. When the user clicks a cell in the table header, my script toggles the class back and forth between sorted_asc and sorted_des. I have pseudo element which adds an arrow glyph (pointing up or down) depending on which class the cell currently is.
.thead .tr .sorted_asc .cell:after {
content: ' \25B2';
}
The problem is, that when you click the cell header a second time, the page doesn't update the arrow... until the user mouses away from the element. I think it's a bug as it works fine in Safari, and as I don't see any :hover tags in my CSS or other entries that might interfere.
Anyone seen this before, or know how to work around the issue?
It's kind of cheesy, but since you're using javascript anyway, try this after you changed the className:
document.body.style.display = 'none';
document.body.style.display = 'block';
This will re-render the layout and often solves these kind of bugs. Not always, though.
This is 2014 and none of the proposed solutions on this page seem to work. I found another way : detach the element from the DOM and append it back where it was.
Would you be able to use different CSS to accomplish the same thing without relying on the :after pseudo-selector? You might be able to simple define a background-image which you align as needed (I assume you would want the arrow on the right hand side).
For example:
.thead .tr .sorted_asc .sorted_asc {
background: url(images/down_arrow.png) no-repeat right;
}
.thead .tr .sorted_asc .sorted_des {
background: url(images/up_arrow.png) no-repeat right;
}
I only suggest this since I assume there isn't a specific reason why you need to use the :after pseudo-class. If you do need to use it, please update.
The bug can still be triggered in Firefox 58. Thankfully the opacity trick also still works. Just make sure to time it correctly. You might need to set a timeout between opacity changes.