ipad css transform causes a font issue - html

I'm doing HTML/CSS/Javascript development on iPad. I'm using css transform to translate gallery elements (li elements within an ul). The li's contain text. It all animates fine on desktop, but on iPad 2 device the animation phase makes the font somehow less bright, and when animation is completed the font returns normal. The difference is really visible, almost like going from regular font to bold and back. As said, it all is well on desktop safari, only happens on iPad mobile safari.
Anyone having the same issue?
.pom.

I've seen this and other slightly odd behaviour which is down to hardware acceleration for 3d transforms but I haven't found a single standard 'fix'. In order to try better to understand the problem, take a look at tips here:
http://davidwalsh.name/translate3d
and here:-
How to force re-render after a WebKit 3D transform in Safari

Related

How to fix blurry/pixelated font-rendering on red/blue backgrounds (Windows, Firefox, Chrome, others)?

On Windows, and to a certain degree also on Mac OS, with different browsers (Firefox, Chrome, Safari), our menu bar has rather pixelated/blurry font-rendering. This is on an ASP.NET Core 2.1 site that uses Bootstrap 4.1.3 but it's easy enough to reproduce with just simple HTML: https://jsfiddle.net/2tgc9r84/
<html>
<body style="background-color:#e72c87;">
<p style="font-size:20pt;">
This is some text that looks terrible.
</p>
</body>
</html>
Interestingly, the same font renders just fine in other areas of the site. I have noticed this on a 4K monitor that has 150% scaling activated but the issue also shows up with 100%. I have also tried this with different fonts, so apparently it's not an issue with the font, either.
Originally I thought this was an issue with transparency or transformations but finally, I tried simply changing the background color - and it turns out this blurriness is very obvious with red and dark blue (and of course, combinations of those, like magenta), and pretty much invisible with most other colors. Also, by changing the main background color, I can reproduce the issue for the other areas.
You can directly have a look at the site where this occurs here: https://beat-the-rhythm-vr.com/Home/Social (the navigation with the blurry text shows up after accepting the cookies).
Here's an image that shows the effect with different backgrounds, and also rendered on Mac OS (the Mac OS screenshots appear smaller in the image):
As far as I can tell, this does not happen at all on iOS. On the Mac, I don't quite see the issue on the screen but it does become obvious when making a screenshot. This could, however, also be an artifact due to scaling on the screenshot.
This is what it looks like on iOS (I get the same blurriness on Windows when making the Window small enough to get the same layout as on mobile, so that's also not the issue causing this / fixing this):
The obvious question: Is there any way to fix this, and if so, how?
EDIT: This is in addition to the comment on Porter's answer (I can't add screenshots in comments, so I'm posting this here):
EDIT 2: While this article is about a slightly different issue, my guess is that what I'm seeing is really just a limitation of ClearType that is related to what the article outlines: Color-aware ClearType requires access to fixed background pixels, which is a problem if you don't know what the background pixels are, or if they aren't fixed
ClearType apparently doesn't work when the background color isn't known, and from what I'm seeing, it seems to be designed primarily for black text on white backgrounds, also works well with light colors on dark backgrounds but not really so much for red/blue/magenta backgrounds (and any font-color).
I am unable to reproduce this on a 1080p or 4K display, with either mobile or web view on Firefox and Chrome. Fonts do tend to blend with the background color, so not every pixel of the font is going to be the same color; It'll blend on the edges. The smaller the font, the less pixels it has to work with for blending. If you use a larger font, does the same problem occur?

Are there any quirks to mobile versions of Chrome or Safari dealing with transform:translate?

I have been looking around for some time today trying to find the solution to this. I have a working example that will move an image(technically a background of a div) up the page. This works beautifully on the desktop but on mobile, it doesn't move at all. I'm wondering if this is the fault of mobile not supporting the transform property on the specific element, or if there is something else going on in my code that would mess it up. I also have text on the page that moves down using the same transform property and it still works on mobile. Here's the example I have right now.
http://jsbin.com/qomepe/1
Is there something I just don't know about these mobile versions or is it something I may have messed up in the code?
Many of the mobile browsers do not support all the CSS3 translations and transformations. For instance, rotating text in a mobile browser does not always work, nor does skewing text. That's just the limitations of mobile. I recommend if you want to make it compatible, move the division with some Javascript and/or CSS2 instead.

Why does IE9 keeps repainting the page, causing unresponsiveness?

We've developed a web application that shows quite a bit of data in a somewhat fancy interface with a table. I can't show the page, but it has quite a big table, inside a fixed positioned element, with some images (mostly icons smaller than 2KB, PNGs with alpha transparency, and no more than 30 different images).
It's not that heavy, with less than 1000 elements in the page. It was developed mainly in Chrome, and works flawlessly in Chrome. And IE11, and IE10.
But when it comes to IE9, this happens:
Yes, that's IE11, because it offers decent analyzing tools. I'm using IE9 emulation, but that same unresponsiveness happens with IE10 in IE9 mode, and with "native" IE9, with high CPU usage - but steady memory usage.
In a lighter way, it happens in IE8 too:
But the repainting takes much less time (perhaps it repaints smaller parts of the page?) and the responsiveness isn't compromised.
As you can see, no script is running, just some random garbage collection. In IE10, IE11 and Chrome there's no repaint involved.
If I disable the images (did this in IE10, don't know how to do that in IE11), IE9 doesn't keep repainting, but if I disable or hide all the images through the style sheets it keeps hogging the CPU. Disabling hardware acceleration makes things even worse, as expected.
What may cause this odd behaviour in IE9 (and partially IE8)?
After a lot of investigations, I think I've found the culprit.
It seems to be a problem related to animated GIFs. Whether it's a <img> element, or set as a background image, or as the content of a pseudo-element, even after it was removed from the DOM the browser keeps on repainting the same portion of the page.
This can be a very intensive task, not only in older computers, especially when using larger GIFs. But even when using smaller ones, if the GIF is used as a background image or in a pseudo-element, IE9 repaints the whole area of the element, rather than just the area of the image.
That's why it keeps on repainting a huge area of 1750x1051 pixels in the screenshot. And I just used a crappy 64x64 spinner!
So... beware of spinners. And IE9.
Solution
I haven't found a simple and definitive solution yet (except ditching IE9 altogether). The first thing to avoid is using animated GIFs in background images and pseudo-elements.
If you have to show a spinner in IE9, you can either use a small one, or a static image. Alas, you have to animate it yourself because IE9 doesn't support CSS animations. And you can't rely on requestAnimationFrame either, just setInterval.
I just hope you can take advantage of jQuery. I couldn't...
For some reason, IE8 deals with animated GIFs much better, even if it's still not perfect.

Menu padding Issue since FireFox 4

I've checked other questions on here but I haven't found anything that will help me.
Since FireFox 4 was released I've been having an issue with the menu on my website.
www.ffxivinfo.com
As you can see, the menu is supposed to fit along the little graphic buttons so that each link is on the "button". In Chrome, IE8 (not checked 9) and FireFox 3.5 this looked perfect. However since FireFox 4 it has been displaying wrong.
It looks like it's a padding issue but I can't figure out where it is coming from. I have even removed the padding between each link so that they are close together (0 padding) yet the menu still stretches further to the right in FireFox 4+ than in other browsers.
I use the auto generated menus available at purecssmenu.com and I modified it to fit my own website.
Here is a link to just the nav code, I use a PHP include to insert it.
http://www.ffxivinfo.com/nav.php
And here is a link to the CSS for it.
http://www.ffxivinfo.com/navstyle.css
Basically I need the navigation to look the same in all browsers so that it fits into the graphic "buttons". I'm tempted to just scrap the current design and go with a simple gradient background and leave the menu wider in FireFox 4+ than other browsers but that's a bit defeatist.
Any help would be much appreciated. This is the first time a coding problem has sent me to a forum asking for help but I just can't figure this one out.
I believe the problem is not in your margins but due to the differences in text rendering between the browsers. In this case, Firefox is rendering the text slightly wider.
If I might suggest an alternative, rather than using an image background and hoping for pixel-perfect rendering (which is pretty unlikely given the diversity of browsers and operating systems out there) try styling the links themselves with background-color and border-radius.
I don't see the problem in FF6. However, I see you specify your font size in pt. pt is for print, not the web. Try changing that to px and see if that fixes your situation.
I might ignore the Firefox 4 issue.
FF is now on version 6.
Your issue does not appear in FF3.5 (the most widely used FF) or FF6, both of which have more browser share than FF4.
http://gs.statcounter.com/#browser_version-ww-monthly-201008-201108-bar

Why does webkit's (Safari / Chrome) page zoom break a fluid layout on zooming out

I have a web site that has had a fluid layout for years. That is the body's text size is defined and from there all other sizes are relative and are specified in terms of ems. This made the page fully scalable on IE 5.5 upwards, old FF versions etc. Nowadays it isn't really that important anymore since in modern browsers there is page zoom opposed to text zoom. Page zoom works on all browsers for me IE, FF, Opera and zooming in works on Webkit based browsers, too. But zooming out (to less than 100%) breaks the layout and I don't understand why that is.
here is an example page from the page as it stands to try this:
Why does the layout break in Safari (I used 5.0.5 to test) and Chrome when zooming out? In Chrome it works for like two steps of zooming out and then breaks. There is little use to zooming out so this is more of an academic question I guess. I'd like to understand what's happening.
Thanks.
It's might because of some default browser styles that are based on px instead of ems. For example, if you use the webkit inspector in Safari <ol class="navi_rechts"> has a user agent stylesheet that includes -webkit-padding-start: 40px. It might be worth using a CSS reset or checking for things like this on any messed up elements.
EDIT It may also be a rounding issue with some of your values. I'm not sure how many decimal places Safari will look at, but I'm guessing things like padding: 0.46154em 0em 0em 0.92308em; on h1.navi_parent_rechts might be too specific.