font-smoothing:antialiased Vs. transform:perspective(0); - html

I'm looking at the CSS for a site I'm working on and they're using
-webkit-transform: perspective(0)
on text, which is giving it the same appearance as
-webkit-font-smoothing: antialiased
I've created an example.
There are no transforms on the site, so I'm thinking it's purely for the better appearance.
I've never seen this hack and can't find any mentions of it online. Is there any reason why it would be used instead of font-smoothing?

The hack they are using triggers hardware accelerated mode. This has a side-effect of changing subpixel-antialising to standard anti-aliasing.
The reason for this behavior is that sub pixel anti-aliasing makes assumptions about the background of the text. When the text is rendered onto a hardware layer, those assumptions are no longer safe, and the text is rendered with standard antialiasing to avoid potential artifacts.

Related

Why do I sometimes need to use CSS hardware acceleration to prevent text flickering?

This is going to be difficult to ask because I cannot for the life of me produce a standalone example despite my best efforts, so I'm going to have to hope that someone is already familiar with this problem. Also, this issue doesn't seem to occur with system fonts, but does with fonts like Inter.
I'm using the Inter font on my website. It looks great but there is an issue where sometimes the text is rendered as bolder than it should be (it also sometimes momentarily flashes bolder during hover events). Eventually I figured out that I can fix this issue by applying the backface-visibility: hidden attribute on elements afflicted with this issue.
It seems random as to what elements it affects. The vast majority of the website works fine, but occasionally I'll find a tag that has this issue and I have to slap a backface-visibility: hidden attribute on it to fix it. Also, this doesn't happen on all browsers and operating systems. The issue is non-existent on Mac devices from what I've seen. On Windows it will sometimes appear while hovering over elements, etc.
Alright, so why not just apply this CSS rule to the root document so it applies to every element? Performance.
Apparently this rule forces some sort of GPU acceleration of some sort? I'm not entirely too clear on the details but the FPS on my website tanked when I applied this globally. However, there is still the issue where the few remaining tags it is on can cause FPS performance issues if there is enough of that element.
So my question: what is causing this, and is there a performant fix? I cannot simply apply backface-visibility: hidden to every element because it destroys the performance of my website, but even applying it to the few random elements that pops up causes performance issues. What is causing some elements to randomly have this weird bolded text effect?
I found this post which seeems to reference the flickering and the use of backface-visiblity hidden and its corresponding performance issues, but no solution as of yet.
Edit: After performing additional research, it seems that it's not just backface-visibility: hidden which fixes it, but any CSS property that elicits hardware acceleration. So, putting transform: translateZ(0); onto the element also fixes it, but also has the performance issues. What is still needed to know is why this graphical flickering happens with fonts like Inter but not system fonts, and only on some operating systems and browsers. Also, there seems to be some interaction with hover events that cause absolutely positioned elements to become visible causing later elements on the page to flicker.
I think you add this code
-webkit-transform: translate3d(0, 0, 0);
to the flickering elements, and thus rendering them in 3D on page load, they no longer had to switch.
This is the reference article.
The problem has to do with the rendering of those specific elements on the page. The parent elements in which those texts sit should be even numbers large (same even numbers).
Just make sure total height remains EVEN and adjust margins and paddings accordingly.

Which font embedding technique allows one to suppress anti-aliasing?

I'm bewildered by all the different font embedding techniques, Cufon, #font-face, FLIR, Typekit, etc., and don't know where to begin with this, especially since there's just one specific behaviour I need. Are there any font embedding techniques that will render a font without anti-aliasing/smoothing/ClearTyping?
I have always just designed to whatever my computer/monitor renders and haven't even thought about it twice. But with this particular site, I'm using opacity on a div that floats on a glassy PNG and the ClearType is just a disaster. The ClearType anti-aliasing on this background combo is standing out darkly, creating what's essentially a bolded font. If I apply an alpha opacity filter on IE8, it removes the ClearTyping, showing me just the single pixel strokes and it looks perfect.
So, do any of the font-embedding techniques allow one to disable anti-aliasing rendering on the font cross-browser? I know probably sIFR would, but would really prefer not to use Flash, as my target audience would most likely be the chief one out there who wouldn't keep it updated: B&M companies.
Technically speaking, no font-embedding technique will allow you to suppress anti-aliasing. What you need is a CSS property to tell the browser that you'd prefer if some elements on your page were not anti-aliased.
Now, whilst this may not be helpful to all your endeavours, especially if a large portion of your audience isn't using WebKit-based browsers, some WebKit browsers support something similar to the proposed font-smooth CSS property, as explained in Max Voltar's post on font-smoothing, using:
-webkit-font-smoothing: none;
Would be similar to the W3C proposed font-smooth property:
font-smooth: never;
Max's article also links to a demo page by Christoph Zillgens which shows you the effect in action, with a caveat that it only appears to work on OS X.
As Aram Kocharyan says above, it may well be that – right now – you can't rely on this property and would have to leave it to let the browser decide.
Some earlier Internet Explorer engines also alias the text if the opacity is set to anything other than 1 – you could try 0.999 as the value and see what happens there.

CSS3 vs Canvas for text rotation

I have an idea in my mind for a simple technical demo. It will have a good amount, maybe up to 100, different text labels with varying rotations and Z-orders. Also, there will be constant animation so the size, rotation and position of the labels will change.
This could be done using CSS3 or Canvas as far I can tell. The CSS3 approach should be more accessible but are there any other real differences to consider?
Edit: I also need be able to place labels quite accurately with their centre point.
Either should be fine. I'd start with making a CSS3 one and then make a Canvas one only if somehow unsatisfied. Some considerations:
As of today text in the DOM looks a lot better than text on Canvas for a lot of browsers. Some browsers don't do subpixel rendering on Canvas text (While others do) making it something written in the same font in the DOM and in canvas look very different. For visual consistency, CSS3 is better right now.
Ask yourself what you might want to do with this later, if anything. Turn it highly interactive? Increase the number of objects above 10,000? Then you'll want to do Canvas, in short because 10,000 DOM objects is a "bad thing".
I'm not sure which one would be faster with merely 100 text labels. It shouldn't be hard to write up a quick test on your target platforms to see.
The CSS one will probably be much faster to make.
Canvas text gradients don't work on all mobile devices last I checked
Canvas text rotation + scaling used to look AWFUL in Chrome and Opera. Chrome has it fixed since version 12, Opera still looks awful. You can check your target browsers here: http://simonsarris.com/misc/scaleText.html Opera sort of looks like this.
while css3 would be the nicest solution, you should at least consider svg too.
see a live example : http://jsfiddle.net/gion_13/DhqEN/show/
p.s. : a big minus for canvas, because it does not have text selection

Add a tint/color to a submit button in IE8 via CSS while retaining "glassy" look?

I'm writing a web app. It's only ever going to be used with IE8, so I'm not concerned with the behavior of any other browsers here.
So: I know how to custom-style a button using CSS properties e.g. background-color, border, and so on. However, when you apply styles that way, the resulting button looks like a blocky table cell, nothing like the nice, glassy-looking button that IE8 renders by default.
Is there some way to add a tint to the nice glass-looking button? I.e., it looks just like it normally does, but with a red outline instead of blue, and a red highlight on mouse-over?
Or is this something I'm going to have to do by hand with images? Again, IE8-specific methods are perfectly acceptable.
Thanks!
-dan
There isn't really a filter that will get you as close to the default in IE, though you can get pretty close using the button tag and standard css. It will not look the same in all versions of IE though.
Here's the filter reference though if you want to try other things.
Regardless of browser, one of the quickest, easiest, most widely tested methods for styling buttons via markup is Jquery UI's button It's a matter of adding a few tags to the class element, and you've got a button based on an link, button, or input field. For styling, you can handle styling via CSS, or via the very well done ThemeRoller option, where you can control everything from text size to background type via a simple gui interface--and you can change on the back end or even the user end on the blink of an eye, even via drop down.
One caveat, since IE is non-standards compliant, rounded buttons fail gracefully to square--with proper styling.
I realize that you have determined that you can use a proprietary solution for IE, and in your case it might be just fine over the long term. But in my experience, that's a really dangerous path to follow. What if the actual long term is longer than your anticipated "long term?" You're specifying that it's acceptable to be proprietary to a browser that's well behind the accepted standards, is already a version behind, and uses unsupported (by universal standards) solutions to solve problems. Conceivably, that version is going to get tougher and tougher to find, and if Microsoft holds true to their patterns, once you install IE9 it will effectively render your computer difficult of downgrading. And, I can't emphasize enough that IE's market share is dropping like a rock, which is scary considering basically 95% of the machines out there have it pre-installed. All it's going to take is one overzealous IT director with "security in mind" to render your programming efforts moot. Sorry for the rant, but IE proprietary code has bit me hard more than a few times...
I'd have to double-check, but you should be able to use a combination of a background color and use a transparent PNG or GIF as the "background image" to add the highlights.
All things being equal, I've rather embraced the flat, square button - finding ways to make it work well with the design - but then again I've always been a straight line, square edge kind of guy. :)
As others have mentioned, you do want to be mindful (within reason) of what you may have to handle. It's quite possible that before the next re-write you're going to have to deal with IE9 - writing code that works well in IE8 and IE9 would be the most prudent approach.
Have a look at http://www.webdesignerwall.com/demo/css-buttons.html and also http://css3pie.com/.
Combining those you can get nice looking buttons in IE as well..

What causes lazy/laggy scrolling in CSS?

I have a design I'm creating in CSS, and it has started to sort of, er, lazy scroll. By that I mean the scrollbar lags a bit when you are scrolling. What are common causes of this so that I can debug it from my site?
EDIT:
The document has very little content (not even a paragraph), so not much at all. No flash, two images.
EDIT:
I feel so stupid. Improperly formatted background: property was causing the issue. Thanks nonetheless, everyone.
It's likely to be due to heavy processing requirements via css.
(CSS does affect scrolling in every browser) I have seen this scenario many times (the worst case is with SVG). It usually hits browsers like Chrome hard because of it's AA.
There was a great website that detailed the heaviest to the safest properties to use in regards to CSS effects, sorry I don't have the link. Though from my experience I would say to consider:
Gradients: The more you feature or the larger the area they cover the more exponential the rendering calculations. Abusing stops and additional colors also adds to the mayhem.
Border-Radius: Is usually clipping off its internal content whatever it may be. I've noticed differences when excluded.
Opacity can be the main issue if coupled with other css effects. In certain scenarios I've found great improvements when removing opacity or reducing it's usage. As it's not just transparency it's driving it's also for some browsers anti-aliasing text.
Images: The way images can affect scrolling should be obvious, though I've discovered re-sizing imaged from it's native resolution can become a more noticeable factor.
Use of properties such as background-size:; draws huge power in certain situations, a workaround could be to scrap the div, replace with < img > and overlay with a blank div
containing text/ content.
Animations transitions & translations are obvious power eaters if abused, especially animation that loops continuously or re-sizes to the browser via percentages.
Bare in mind someone on a low spec celeron PC will have a terrible experience on a site that lags on your reasonably/ high powered PC/ mac