CSS font antialiasing is "inventing" new colors? - css

I have two texts with, according to the "Computed" CSS properties, the same CSS properties. One antialiases in greyscale, the other in color. On the left we have Vuetify v3, on the right Quasar v2. Vuetify renders the text a bit nicer (although opions could vary..). Both are rendered in Chrome 109. I've tried to add -moz-osx-font-smoothing: grayscale;, but I believe that this is an outdated property, and Chrome seems to ignore it alltogether.
Quasar did not have the text-rendering property, so I added text-rendering: optimizelegibility !important; here myself. This however, did not seem to change the output.
The only thing I could not control for is the font itself. Both Vuetify and Quasar come with Roboto prepackaged.
Computed CSS properties:
What is going on here, why are these text rendered differently? and how can we force the anti-aliasing to not "invent" these extra colors?

Related

OpenType Stylistic Sets with a Canvas element

I am trying to use an OpenType font with an alternate stylistic set to draw to a canvas element. I have it working with the standard html and fonts with
font-feature-settings: "ss01";
However, I also need to write the font to a canvas element. Is there anyway to do this? Or is this not supported?
As of right now you still can't, not with font-feature-settings nor with font-variant, and for that matter it's not even in the specification yet for Canvas.
But it might be someday: https://github.com/whatwg/html/issues/592

Resolve FontAwesome text rendering differences

Please see the above image. I'm using the icon font 'FontAwesome' on my website. In the website header, I'm using them for navigation icons. Each of these icons are links, that have the 'fa' and 'fa-2x' classes attached.
I'm not overruling any default font sizes or rendering modes for FontAwesome, so this is a clean state. All screenshots are from Windows 8.1, testing several browsers. Here are my findings:
Firefox: perfect rendering, optimal balance between legibility and anti-aliasing
Chrome: font rendering too thick and harsh, hurting legibility
Safari: reasonable legibility, yet a bit too thin and harsh
IE10: Very close to FF, acceptable as-is
Opera: Same as Safari
Mu ultimate goal would be to have ideal rendering across browsers, as per the Firefox example. A perhaps more realistic goal is to beat Chrome into submission, as it presents the biggest issue.
Font-Awesome by default has this applied:
-webkit-font-smoothing: antialiased;
I've tried setting this to the other text rendering modes, yet none seem to make a meaningful difference, the same is true for setting the text-stroke property, even at 0 the 'thickness' problem remains. That problem is best seen from the 'members' icon.
You can see the rendering live at www.jungledragon.com
Any clues/tips on how to improve rendering quality and consistency?
That's old issue I can see, but I had similar problem with FontAwesome and discovered that weight of these icons can be different depending on font-weight attribute (that's a font, after all).
So, my problem was that narrow holes in icons becomeing invisible in my app and the solution was setting the font-weight attribute to normal in CSS.
For my liking, icons in Chrome version of your issue are just "overweighted" that way.

Compass: Syntax error: Undefined mixin 'user-select'

I get the follow error when trying to use the mixin 'user-select'. I'm using version 0.12.2 which I'm pretty sure supports user-select from compass. So why can't I use this mixin?
Error
Syntax error: Undefined mixin \'user-select\'
Includes
// css3
#import "compass/css3";
#import "partials/deposit";
Call
//File: partials/_deposit.scss
#include user-select(none);
So why can't I use this mixin?
From the #import "compass/css3/", this is the list of the imported things:
Appearance – Specify the CSS3 appearance property.
Background Clip – Specify the background clip for all browsers.
Background Origin – Specify the background origin for all browsers.
Background Size – Specify the background size for all browsers.
Border Radius – Specify the border radius for all browsers.
Box – This module provides mixins that pertain to the CSS3 Flexible Box.
Box Shadow – Specify the box shadow for all browsers.
Box Sizing – Specify the box sizing for all browsers.
Columns – Specify a columnar layout for all browsers.
Filter – Specify the (image) filter for all browsers.
Font Face – Specify a downloadable font face for all browsers.
Hyphenation – Mixin for breaking space and injecting hypens into overflowing text
Images – Specify linear gradients and radial gradients for many browsers.
Inline Block – Declare an element inline block for all browsers.
Opacity – Specify the opacity for all browsers.
CSS Regions – Specify CSS Regions for supported browsers.
Text Shadow – Specify the text shadow for all browsers.
Transform – Specify transformations for many browsers.
Transition – Specify a style transition for all browsers.
From this, we can say that Compass User Interface (css3/user-interface) isn't bundled with compass/css3 thus you need to call it also, after the css3 call:
#import "compass/css3"
#import "compass/css3/user-interface"
//other imports
Update
Compass 0.13.alpha.10 onwards
Looks like the 0.13.alpha.10 Compass imports user-interface as well since the documentation page was updated:
User Interface – Declare an element inline block for all browsers.
Also was added animation as well:
Animation – Specify the CSS3 animation property and all its sub-properties.
Therefore just #import "compass/css3" is enough now.

CSS cascading priority confusion

I'm confused about why the <h1> on this website has a font-family of Helvetica (at least when viewed in Chrome).
From Google Developer Tools, it looks like the font-family is being inherited from the Bootstrap CSS's body rule (see bootstrap.min.css).
Shouldn't the names.css file take priority? That sets a font-family of Lobster on the h1 tag explicitly.
It's not a selector priority problem: Chrome won't accept the inherit property for font-family as a fallback. Remove it and you'll get your font as expected.
The standart says that font-family accepts a list of fonts, or the inherit special value, but not a mix of the two. I'm fairly sure that if no font is found in the list, it'll fallback to inherit, though.
When I open that webpage, Chrome gives me a yellow exclamation triangle on that line, so it does not process that CSS font specification.
Did you declare a #font-face {}? It looks to me like the font is not installed correctly, because Chrome doesn't know what to do with it.
EDIT:
Removing the inherit solves the problem.

IE8 CSS Body background color

I have a page that works fine in most browsers(Safari, FF, Chrome, IE9) but on IE8 it won't show the body background color. It shows the Body bgcolor as white. In the Developer Tools, I see that it is overriding all the CSS and getting some background-color:#fff from somewhere.
I have my scripts (jquery 1.6.2) just before the closing tag as is suggested on the HTML5 Boilerplate (html5boilerpate.com) - not sure if not having the scripts in the head section causes this behaviour?
Anyone any ideas ? This is really weird.
A couple things to try.
Toy with the load order of your css files. Whatever is loaded last will be the style if you don't specify !important
Inspect your rendered html for inline <style/> blocks as they could be causing trouble and not show up in the style tab as a specific css file.
When in doubt target background-color directly as background will
sometimes be overridden by a background-color property
body{background-color:#e6e6e6}
If that doesnt work you could force
override it with body{background-color:#e6e6e6 !important}.
Background color not working on Internet Explorer (IE)
IE apply some filter before rendering web page . that's why some page colors changed .
you can add following line in your CSS file to avoid it.
filter: none !important;
Scanning through the blueprint css, it looks like the background color #fff is being set in two different locations: textarea and in a select box. Try removing the background color property from textarea and see if that helps, or even better comment out the blueprint references to see if that's causing the problem. Seems like 9 out of 10 times a property gets overridden in IE its because a third party library is assigning a diff property to the same element.

Resources