This video explains the problem best: http://www.screencast-o-matic.com/watch/cQ1Oc9f1L
Basically the directory is located here: http://www.ipalaces.org/uploaderprogress/grrrrrr.html
Is the problem piece using YUI.js as the uploading script. The YUI updates the table's row with new information on every event. So I have it update it with some CSS/HTML so that it does a progress loading bar. It works fine for all browsers but IE. I am not sure if this is a known rendering bug or what, and if there is even a fix for it?
the working-demo.html basically shows that if you just resize the div using javascript, IE renders it fine. Its just updated the table's row with new div information seems to cause rendering issues.
I couldn't reproduce the bug because you applied that fix. But I did take a look at the source. The way you are animating that progress bar just begs for bugs. Try compatibility mode in IE8 and you will see that it's shrinking instead of growing (because the element is centred) and that progressbar-completed element is 2x bigger then container. Same in Chrome and probably Safari.
This is how I would do it:
(source: maikumori.com)
Make A constant for example 250px. Then you have to make a background image with same size as A containing progress bar as if it was at 100%.
Then:
background-position = B = -1 * Math.Round(A * UploadedSize / FileSize)
Pros:
Takes less markup
If you make background image 2*A and B = B + A then you can have custom image for "blank" space therefore you can make fancier progress bars easily
Should work in most modern and not so modern browsers
Doesn't make a mess if user has css/javascript disabled
Cons:
A must be constant
Haven't tested =(
P.S.
Sorry for blinding colours, couldn't change them afterwards ... mspaint
I found a solution.
If I include this in the HTML then it will work fine:
<div class='progressbar-completed' style='visibility: hidden;'></div>
It seems like IE is having trouble maintaining the "memory" of the background file when its dynamically created in javascript.
Putting the DIV in the html itself seems to make the memory of the background file persistent in IE.
Related
I want to start by mentioning that I have seen and read this question, so I know that Safari (and iOS) handle the height property differently than Chrome. This problem does however feel a bit different. Anyways:
I have a list of items that is styled with flexbox. Each entry is a grid containing various types of information. However, each entry also consists of an image that is positioned absolutely in relation the grid so that it sticks out a bit to the left. An example of how this works can be found here. This works fine in Chrome and looks as expected, but things look weird in Safari. Even though Safari does not use the grid container as a relative height for the image (which has a property of height: 80%), the image seems to align well with the grid. However, all other entries are aligned with the entire body of the page. When inspecting the grid, it doesn't look like it takes up the entire page, yet the other components seem to think that it does.
Why is it that the image looks OK whereas the other components do not? Furthermore, does anybody know a way of solving this problem? I would prefer if the image height could remain as a percentage because i want to re-use the component in other parts of my code.
Thank you.
EDIT: Here are images that show the difference between Chrome and Safari, from the example JSFiddle.
Chrome:
Safari:
EDIT 2: I still don't know why this happens (and I'm intrigued to find out why), but I did figure out a solution to the problem. By setting a specific height for the list entry (i.e. by using grid-template-rows: 50px; for instance), the image size is correctly scaled to the grid row, and the other components are placed correctly.
I am trying to create a website in which the navigation is based on zoomable contents.
For instance, here is a screenshot of what you can see just after opening the webpage:
Then, I am using zoom.js for "zooming" the page and be able to read the text. However, after the magnification I got this:
The font-size is set to 9.4%, and as you can see it causes characters to be overlapped and not correctly positioned.
I tried to use some jQuery plugin like FitText.js or jQuery TextFill, just to see if they changed the font-size in some "magic" way that solve this issue; unfortunately they had effect in solving this visualization issue.
So my question is: how can I make the font looking "normal"? Is there any jQuery plugin or other JS library to manage this problem?
I am using Firefox, and I prefer to focus on using just this browser for the moment.
As suggested by Nico O and Ed Plunkett in the comments, the solution to my problem was to start with a very big page, in which everything is 20 times bigger than the desired page size. Then I added the following CSS to scale everything 20 times smaller:
body {
transform: scale(0.05);
transform-origin: 0 0;
}
When I need to zoom on a point, I simply add new transformation parameters in the CSS, by changing the transform property (I used jQuery, but it can be done in many other ways):
$("body").css("transform", "scale("+scale_factor+") translate("+translate_data+")");
Note also that I didn't need any additional library (with the exception of jQuery) to do this.
My users and I are running into a rendering glitch in Chrome only (on both Windows and Mac) where an overlaid div that I'm using for on-hover tooltip-style "popouts"(see first image below) does not get rendered properly in certain cases (see second image below). In all other browsers I've tested, it works as expected.
Here's how the hover popouts are supposed to look (and what happens in Firefox, Safari, IE):
Here's what happens in Chrome:
You can see it in action on this site if you look at May 24 using a browser window width of ~ 1200px (significnatly wider or narrower windows do not seem to work). The glitch only affects the popouts in the bottom right of the menu that are popping left, e.g. those on May 24. Hovers using the same exact mechanism higher up in the page work just fine. Glitched popouts are invisible (except for part of the carat), but if you click on the link to lock the popout in place and then hold left click while moving your mouse around as if to "select text" in the area where the popout should be, it will then render partially. Also if I open dev tools and try to select the popout, it will render just fine at that point.
I've been looking at this all day and trying different work arounds with opacity, z-index, etc. and getting nowhere. Does this glitch ring any bells for anyone? Is there a way to force Chrome to render the div, once its been positioned and unhidden? I'm fine with any work-around or hack.
I use a custom (and fairly complicated) jquery plugin for popouts. If it would be helpful to see the non-minified javascript for the plugin, I can post or provide a link to that, but general guidance that leads me to a work around will be sufficient to be accepted as an answer.
Edit: My Browser Build: 26.0.1410.65
(Per my comments)
This does indeed seem to be a bug in Chrome, though without a smaller test case to reproduce it, it could be very hard to track down. You may want to report it to the Chrome team with as much information as possible.
In support of my "it's a bug" assertion:
The hidden/clipped elements become visible when they are selected.
The elements underneath the hidden/clipped elements are not clickable.
This indicates that z-index and height is correct.
It only happens under very specific circumstances; the rest of the items with the same style work fine. The same item may work fine at a slightly bigger/smaller screen width.
Applying a 3D transform fixes it.
The problem goes away when I apply a CSS transform such as scale3d or translate3d. I imagine this is because certain CSS properties cause the browser to switch to GPU acceleration.
In this case, switching to the fast path for rendering seems to alter the drawing sequence enough to fix the problem.
Super hacky but this fixes it for me:
$('.drop-link.food').on('hover',function() {
$('.tool-tip').css('overflow', 'hidden').height();
$('.tool-tip').css('overflow', 'auto');
});
Obviously this isn't a "good" solution, and even remaining hacky you could probably optimize it to only force the redraw on the tooltip it needs to, but hopefully it helps...
Another clue:
$('.drop-link').on('hover',function() {
$(this).siblings('.tool-tip').css('display','block');
});
This won't fix it right away, but it seems like if this is there, once you've hovered on something, it will work the next time you hover on it.
Not sure if this helps with your situation, but over the last couple of days I've started to notice that certain site elements on Facebook and Weight Watchers no longer show up. Specifically it seems to be affecting items that (I believe) to be controlled by or dependent on Javascript. When I call up these sites in Firefox and Safari they work as expected.
I have a simple table with css. When I add a bottom border to the middle row, the next row has a really weird border. it happens only in chrome, and I have no idea why.
I should say the I apply the bottom border to the middle row using javascript (because I don't know the size of the table beforehand). I tried to apply without javascript, and it works without the weird problem.
here is an example of the table, notice the borders in the middle:
http://ri-cloud.appspot.com/super_tacticko?create
here is the javascipt I'm using to create the middle line:
// add the middle line
var half = height / 2; // it has to be zugi anyway
var $middle = $('tr').slice(half-1, half);
$middle.find('td').addClass('middle-td');
If resizing the window fixes the issue (as it does in my case also) it is most likely a rendering bug... Chrome has a number of these that spring up from time to time, mainly because it tries to be faster than everything else by cutting corners (imo).
The only way to work around a bug is to keep trying different approaches until you find one that doesn't trigger the issue, either that or try programatically resizing your table/body after it's been created and then put it back to the right size again — this may force Chrome to redraw correctly... and should occur quickly enough that the users wont notice. A third approach could be to build the table entirely in JavaScript and once properly formed, embed it into the page.
The reason why the CSS method probably works is because it will be using Chrome's rendering methods at a different point in the rendering process to that of the JavaScript style modifications.
Basically, I have seen Chrome do some pretty strange things. The hacks I've used in the past to get around odd Chrome problems have been:
Use decimals in dimension calculations — i.e. 30.1px instead of 30px
Not setting opacity to full — i.e. 0.99 instead of 1.0
Not to use an ip address prefixed with a . when setting a cookie
Use overflow: hidden to repair strange renderings in certain situations.
Oh just for the record I'm viewing on Windows 7 via Chrome v25.0.1364.97
I have run into similar problems in Chrome on Windows 10. The cause of this problem is that Chrome is not working correctly with Windows text-size settings feature (IMHO changing DPI in Win OS). When I have switched from 125% text size to 100% text size, Chrome was rendering my HTML table correctly. As far as I have been testing, other browsers are working with this feature OK.
Finally I made a quick fix to this issue as follows:
table {
tr td {
border-color: transparent !important;
outline: 1px solid #666;
}
}
It is not bullet-proof, the sizes of borders are 2px, but better something than nothing.
I've been working on a slideshow script that uses CSS3 transitions, or jQuery's animate when they are unavailable. I've created a custom function to do the slide animations, which does so appropriately. Everything seemed to be working fine, but I've hit a major snag during testing.
For one reason or another, there is an large delay applying the jQuery CSS before and after the transition on large slideshows. For example, the slideshow in the link below is around 9900 pixels wide (container width, most of which is hidden). The container is maneuvered to display the appropriate slide, using CSS3 transition and transform properties. The delay occurs applying the CSS between lines 75 - 82 in the paste below. In particular, applying the 'transition' CSS causes the problem. Add the 'transition' CSS to the stylesheet (rather than applying it with JS), and delay disappears. This isn't really a solution however, because we only want to use CSS3 transitions on specific properties, that can vary (using 'all' in the stylesheet would transition some CSS that we don't want to animate, but change regularly).
Animation function:
http://pastebin.com/9wumQvrP
Slideshow Demo:
http://www.matthewruddy.com/demo/?p=2431
The real problem is with iOS, in which the slideshow (and even the browser sometimes) becomes completely un-usable. I can't pinpoint any errors, and have really exhausted my knowledge of debugging JS. I'm sure it is related to this section of the function after playing around a bit, and disabling CSS3 support within the plugin altogether removes the problem completely.
I'm completely stuck, and really appreciate any help anyone can give.
--- Edit ---
I've tried applying the CSS with native Javascript rather than jQuery's .css function. Same results, no better performance. Also worth noting that this isn't happening at all in Firefox, and seems to only be a problem with Webkit browsers.
Anyone with a solution, would happy to make a donation towards a few beers! I really cannot figure this out!
--- Second Edit ---
Ok, so been debugging and I can see that the slowdown is caused by the browser repaint cycle that is taking a very long time. Is there a better way to handle this that the way it is already doing? Positioning the element absolutely is a known way to reduce repaints, but that isn't really working because the slideshow is responsive. Absolutely positioning the slide images or the slides themselves causes it to collapse.
--- Third Edit ---
A day later, and I've made some progress. Adding 'transition: all 0s ease' to the elements stylesheet CSS has gotten rid of the repaint caused by adding the inline CSS transition property via the custom animation function mentioned in the original post. This causes a significant performance gain, especially when removing the inline CSS transition property when the transition itself has finished.
Good stuff! However, now there is still a slowdown when the inline CSS translate is being removed (that was used to create the hardware accelerated transition effect itself) after the transition, and the left positioning is being applied. When the two happen together, there is a slowdown.
Breaking them up into two separate tasks (the translate removed, then the left position added in a setTimeout with no time specified), again gets rid of the repaints = performance gain, and looks likes problem solved. But sometimes, the CSS transition property isn't get negated fast enough, and the translate removal gets animated. No good, and don't know where to look next to work around it.
I think the problem is you're loading HUGE images :)
They are too big for the container you have them in, so you scale them down, which is even more resource intensive.
Try resizing them.
First of all congrats for your debugging!
I have been working on the exact same stuff lately and found out that ios devices don't support a large number of images positionned in the same page. It causes crashes and the only solution I found was removing elements instead of just hiding them. The downside is that removing and appending elements causes lags so you have to do it cleverly, when your transitions are done. I thought the best way to go was keep 3 or 5 images in the DOM and replacing the rest with thumbnails of the images, resized to fit the original. When transitions are done, I'd just put the large images back into place...
Hope this helps you a bit on the ios problem at least...
After spending some time analysing your code TimeLine with Chrome Dev Tools, I believe there's some optimization you could do.
As far as I can tell, every single one of your 16 images gets fully repainted every time an animation is requested. This seems quite obvious to me, as there are 16 images in your example, and the Chrome Dev Tools reports 16 long "Paint" executions every time in hit "Next".
In my humble opinion, you should figure out a solution that considers only translating two images: the one you want to hide and the one you want to show. So, consider please, not moving the rest of the images and, instead, leaving them all side-by-side to the shown image.
One more thing, using scaled down images is probably making the paint cycles quite longer. Avoid them whenever you can.
Well, think I've managed to figure it out! Just so you know, original post links don't reflect the changes as I've done them on my localhost environment.
Absolutely positioning the slides container has fixed the problem that was occurring with repaint speeds after the transition had taken place (whilst applying CSS properties). Obviously taking them out of the DOM has done the trick, allowing painting to take place much more efficiently.
I originally didn't try this too much because I knew this would add a lot of work to the resizing functionality. I had originally intended to not resize at all in JS, and rely on percentages to do the dirty work. Absolutely positioning the container would cause the slideshow viewport to collapse, rendering the native resizing useless.
However, I was already having problems with sub-pixel rendering in other browsers anyway, so I guess it was time to bite the bullet and rely on fixed pixel values. I then used JS to handle the resizing, using the window resize event. All seems good, however the slideshow was still collapsed due to the positioning. Assigning height values wasn't working correctly, so was at a bit of a loss.
Thankfully, I came across a neat little trick of setting the 'padding-top' of the slideshow viewport to a percentage value, dynamically calculated (desired slideshow height, set in the settings panel for this script, divided by desired width). As padding-top percentages are relative to the width of the element, this did a great job of providing responsive height and correcting the viewport again (no longer looking collapsed).
Here is some info on using padding-top for responsive elements that maintain aspect ratio. Great little trick: http://f6design.com/projects/responsive-aspect-ratio/
All is good now, and things are working well in iOS and webkit browsers. Everything is extremely quick and working as it should. Four days later, and it is finally figured out. Not happy about having to resort to JS for resizing, but I guess it was always going to happen due to percentage inconsistencies between browsers. Lots of decimals = no good!
Thanks to all who tried to point me in the right direction. Definitely got me thinking, and learned a lot of debugging skills that I can use again to make sure transitions are performing well. Thanks again!
not sure if this helps or not but I noticed you use 3d translation - I would think a simple 2d translation would be enough especially since your third parameter is 0 and might accelerate the issue, also go with fewer images as Armel L. suggested, don't have an iphone to test though... alternatively, this is a solution I used before css3 but should still work move the element containing the images using javascript by modifying left (?and top - the demo only moves left and right though? without the transition effects) and this way you can fine-tune the refresh rate which I think might account for the slowdown... you can go as low as 18 fps without anyone noticing, might even be good enough with just 16fps
I had this when I was first designing a magazine carousel-style page device.
If you have a series of images within a long "tray", even if they are not within the viewport, they will still take up ram, and you can effectively have five or so before leaks and nastiness begin to happen.
What I found works is "hiding" them ... But make sure they take up the physical space necessary.
What I also found worked was that one could make the 'previous' current and 'next' image are visible and move the tray, 'unhiding' them as they reach those three positions.
In my own system, I skipped the 'tray' holding e images and only had them at -100% width, 100% width and the current one a 0.
I never had much luck with the typical long-tray carousel with large scale background images... Especially with css3 acceleration.