Firefox not anti-aliasing scaled background svg - css

I'm working on a responsive design that requires the header graphic to scale with the width of the viewport. I've gone for an svg thinking that this would scale well. (I test for svg support in the full site, and replace a gif with the svg).
In Firefox (13.0 on Windows 7) it's not antialiasing it at small sizes. It occassionally looks good at some sizes, and does if I fix the dimensions, but I want to avoid doing that.
Chrome and Safari do anti-alias the image, and it looks good.
I'm setting the background-size: 100% 100% to scale to the container, I've tried things like cover as well, but seems to make no difference.
I've tried adding image-rendering: optimizeQuality; as well, but this doesn't seem to have helped.
I've set up a test page at http://axminster.digital.linneydesign.com/svg/ - the top one is the background image, and the one beneath is exactly the same file, but added in the html directly as an img. Scaling the browser down to small sizes, you'll see the top one pixelate, but the bottom one will stay smooth.
Any thoughts on how I can smooth this background image without fixing its dimensions?
thanks.

Give the outer <svg> element in the svg file (sophie-conran.svg) a width and height of 100%.
What happens is that the svg image is rasterised at the width and height you give it i.e. 1000px x 350px and that bitmap is then converted to the required size. If you make the width and height percentages then the bitmap is created at final size and there's no bitmap scaling.
Update:
This is all moot with Firefox 24 and beyond though, you can do what you like and it will always work properly i.e. without pixellation.

The solution is to include the SVG as a tag, not as an external file.
Firefox will apply the anti-aliasing correctly.

Related

How to Resize Background Images to fit iPad Screens

I'm running into a problem. When I view my website on a computer and phone, it's built perfectly; but, when I pull it up on an iPad, the background images are like blown up. My website is http://www.zwdalpha.com/, any help will be very appreciated! Also, my Github is https://github.com/zcsmouse970/zwdalpha
To address the issue, you first need to understand what is happening. Background image sizes are handled with the background-size attribute, which you currently have set to cover. cover is great for large screens because it makes sure the image "covers" the height of the element. This allows for clipping on the sides to make sure it fills from top to bottom. contain is the opposite of that. It makes sure you can see the entire image at all times. It does this by making sure the width is 100% and the height is left to clip or expand. When you see on tablets and smaller that the images are "blown up", the CSS is making sure that the entire content area is filled with the image, and it does this by making sure the height of the image fills the content pane. Here's where we get a little more detailed.
You have your images setup as fixed. Obviously this was the effect you were going for, but lets think about what needs to happen here. Now the image needs to be covering the screen from top to bottom because it is able to be viewed anywhere the content pane is while being fixed. So now your image is covering the entire viewport. You can see the changes it makes when you change it to background-attachment:scroll;. It instead fits the image into the content pane instead of the viewport.
All of that being said, the way you can change this is by implementing media queries and switching backgrounds to cropped versions that are more appropriate to the viewing dimensions.
Your issue appears to be to do with background-attachment: fixed not behaving as expected.
Try background-attachment: scroll

Icon font rendering inside auto centered div is blurry/crisp based on browser width

i wanted to jump on the icon font train, but was quickly put off by the renderer.
When an icon is sitting inside a div that has either percentage width or is automatically centered the icon can be aligned to a half pixel causing it to be rendered blurry.
I was in contact with Icomoon support who intoduced me to a bug that said it is Chrome specific. (https://bugs.chromium.org/p/chromium/issues/detail?id=426333) unfortunately I was able to reproduce the issue in all of the major browsers.
The recommendation I got was to avoid auto margin and to use only float left which in today's world isn't really possible. And even if I do that i'd still clash with precentage widths.
Question
Is there any way to preven't the blur from occuring? I guess using inline-svgs would be an option right? But that kinda beats the whole purpose of the Icon Font. Or having a script that rounds everything up to whole pixels but that sounds extreme as well.
Steps to reproduce the issue
I have created a 24px set of icon on Icomoon, downloaded the set which comes with a demo.html. Then I just to the main wrapper of the demo, and gave it a fix width and margin 0 auto. Then by resizing the browser width I was able to make the icons blur or be crisp..
Chrome
Blurry:
Crisp:
Firefox
Blurry:
Crisp:
Opera
Blurry:
Crisp:
Edge
Blurry:
Crisp:
Internet Explorer
Blurry:
Crisp:
If someone can provide evidence that this is what's actually happening in the browser implementations that would be ideal, but this answer is based on your even/odd pixel values you mentioned in the question and is what I believe to be the most likely cause.
Fonts and Icon Fonts are Vectors
On a basic level, icon fonts are vectors. This allows the icons to scale regardless of font size and not become blurry. Blurriness can however occur when the edges of the vectors do not line up with the edges of pixels.
Vector vs Pixel Rendering
To steal from the Font Awesome Icon Design Tips Guide, you can see two demonstrations below. The top image is a vector with a bunch of 1px wide lines, spaced 1px apart, but they're offset by 0.5px. When rendered as pixels without being zoomed in, this causes them to become blurred as the pixel must take 50% of the line colour, and 50% of the background colour.
Vector edges that don't line up with the pixel edges. (The blue representing the 0.5px offset from the pixel edge).
On the other hand, the image below has the vectors lined up, so that either edge of the lines/bars, lines up with the edges of the pixels. Therefore when rendering at a pixel level, no pixels have to merge the background and line colours.
Correctly aligned vectors
To see more examples to explain this in more detail, I'd recommend reading the full guide which also explains crisp diagonal edges too.
Browser Rendering and High DPI Screens
Browsers now have to deal with high DPI/retina screens, which make it really easy to have "centered" text because you have 2 actual pixels per CSS px width; therefore you can draw crisp lines every 0.5px.
Judging by your images, you're using a regular DPI screen to view the fonts, and therefore when the browser is forced to render the icon at a 0.5px value, the edge of the vector lies in the middle of a pixel, rather than half way, meaning that pixel has to take 50% of the background colour, and 50% of the icon colour, causing the blurred edge.
As for a solution, I sadly don't have a lower res monitor on hand to test. Your aim is to make the edge of the icon render on the edge of the pixel boundary which will require some fiddling, but here are some things you could try:
Setting your icon to display: inline-block instead of the default display: inline that text tends to have. (Unlikely to work, but it might).
Wrapping your icon in a fixed-width div just larger than the icon size that can then be centered.
If using the div method, try the difference with left aligning or center aligning the text.
In my experience, blurry fonts are often the result of how the icon was created. Font Awesome has some good tips on designing crisp icon fonts.

Using a larger image than container for better quality with css

I've noticed that when displaying small images with a scale of 1:1 they often look blocky. I can overcome the problem when using the <img> tag by using a larger scale image and setting the desired size with css.
But, I'd like to load my images with css with background: url(...)
When doing this if I set my element size to less than my image size then the image is only partially displayed, I can overcome this using background-size but I understand that this isn't very cross browser compliant?
Take a look here to see what i mean http://jsfiddle.net/uSqJW/
yes you can do this by background-size property but you need to remove that background position or make it 0px 0px from left and top respectively. This property will not be functional below IE9.
AFAIK background-size is the only way to set the size as there is no ratio option, but it is well supported - see http://caniuse.com/background-img-opts
This is a good article about the benefits and machanisms of loading higher resolution images http://www.html5rocks.com/en/mobile/easy-high-dpi-images/

Background Image not scaling in td

I am on a team trying to convert our Flash Application into HTML5 and Css, and I am running into a bug affecting WebKit and wanted some help trying to figure it out. The basic idea is that there is a table with a single cell with a background image and a background color and for whatever reason when the image is exactly the right size background-size: 100% 100% the image actually shrinks to reveal the background color. This also repeats if I use pixel values instead of % values.
Before anyone tells me to just use a div (since its only one cell anyway), this content is authored by other people who are using an existing tool to create a custom xml document that gives us tables and I have to get my solution to work on the pre-existing content we already have.
This is the fiddle which shows it and follows are image in various browsers:
http://jsfiddle.net/CEvnx/2/
Flash (Reference)
Firefox (working)
Chrome (the image shrinks)
Safari (the image grows)
P.S. Ignore the height and font differences as those aren't in any way relevant to the problem.
has to do with the table's border-width, if you set border-width at 2px or less the background sizes correct (in Chrome/Safari). Quite strange that Chrome shrinks and Safari grows. There must be some odd math or image resize logic in webkit and probably worth submitting a bug report.

CSS image down-scaling

I'm putting together a book flip where I flip pages using CSS, JavaScript and HTML. It works very well, except for this one thing.
Every image has a block-level parent. The block-level parent's dimensions has the same ratio as the image but it's scaled down to fit inside the window. Every image has a width:100%; and height:100%; declaration making it fit directly inside its block-level parent.
Now, this works great but when I start sliding the pages the animation's VERY slow and laggish because I scale the images down. If I remove the width and height declaration from the images the animation runs smoothly but the images exceed their block-level parent's dimensions.
What can I do to fix this? Creating a new image with new dimensions isn't an option since I want the images to fit inside every screen resolution.
The animation is only slow in the following browsers/OS'es:
Opera 10, Mac
Chrome 6, Mac
Firefox 3, Windows
Safari 5 and Firefox 3 on Mac and IE7 on Windows handle the animation very well but there are some browsers, where the performance gets killed when scaling down images.
I'm not sure if this will work in your use-case, but have you tried setting the images/blocks to display: absolute or display: fixed?
Because absolute and fixed elements are not in the flow, they do not cause reflows when their properties change, so that can drastically help speed things up, depending on the circumstances.
Could we see a little code, or maybe a live example?
Some browsers are very slow at image scaling. Chrome 8 is the worst at this, in my experience, being about 5x slower than FF3.6 when resizing large images.
You can use Canvas as a workaround on browsers that support it. It's not faster at the actual scaling (yet), but it lets you guarantee that you only scale the images once, when they're loaded, instead of over and over during rendering.

Resources