Why HTML elements don't properly align to grid columns.
https://pbs.twimg.com/media/BqaoDBzCMAEzcTG.jpg:large
IT IS IMPORTANT TO NOTE that CSS Gradients are not 100% reliable visualizations of your grid, so do not be concerned if your items do not line up to the visualization. If they are off by a little bit, assume that they are aligned correctly and your visualization is off. Webkit browsers, and especially Google Chrome, seem to be the worst with the gradients, whereas Firefox seems to be the best.
Source: https://github.com/Team-Sass/Singularity/wiki/Creating-Grids#grid-backgrounds-may-be-inaccurate
Also, read this: http://www.palantir.net/blog/responsive-design-s-dirty-little-secret
And Singularity author's reply: http://snugug.com/musings/on-responsive-designs-dirty-little-secret
Related
I am using elements of width 1.5 to connect elements. This all looks fine but if the image is dynamically scaled down to show more of the diagram then some of the lines eventually disappear in Firefox but not in Chrome. Is this a problem in the Firefox SVG support, or some difference in default settings that I can change?
Rather than present any code, I can point to an example in a blog-post at: https://parallax-viewpoint.blogspot.com/2018/12/further-travels-of-walking-boots.html. Scroll to the bottom of the post and there's an embedded SVG "family tree" image that uses the JavaScript pan-zoom library to dynamically scale the diagram.
On the default setting, in Firefox, not all lines will show -- probably dependent upon whether they fall on a pixel boundary or not. As the image is gradually scaled up, you will notice that the lines will eventually all show. Contrast this with Chrome where the lines always appear to show.
New information from Firefox support: there is a pronounced "redraw" fluctuation for all transformations (+ or -) from the initial position. The lines are markedly thinner after the redraw, and this suggests some sort of rounding error is occurring.
The suggestion of using double lines (one with non-scaling-stroke and one without) runs into a few issues. If the line elements have stroke-opacity less then 1 then the superposition shows through. Also, with SVG 1.1, it does not appear to be possible to encapsulate the drawing of two lines in a single group/symbol if the line lengths are related but not equal. Unequal lengths are necessary to prevent corner gaps where orthogonal lines don't reach fully into the corners. Using calc() to adjust one length relative to a 100% length doesn't work with line elements because they use pairs of coordinates rather than lengths. I tried using a rect in place of a line but Firefox did not support CSS control over its width/height in order to use calc().
The solution was simply to use opaque lines (stroke-opacity=1.0), suggesting that the disappearance of the lines was due to Firefox's handling of stroke-opacity < 1.0. It may be the case that lines will eventually disappear at minute scales, but the reported problem was specifically that Firefox lost them much earlier than it should, and compared the situation with Chrome (which worked OK).
I have a site that I have built, with a colour scheme based around the companies graphic. This has a gradient from left to right, fading to white. I use the image at the top of the pages.
To provide the same gradient down the page, I took a pixel or two wide cut from the bottom of this image, which I them repeat down my page. This works perfectly well, giving me the right gradient across my screen.
In firefox, there is no break between the bottom of my header image and the top of my repeated background gradient - which is as expected. The colours match, so they should appear continuous. However, in IE7, the top image appears very slightly lighter than the rest of the background. I initially thought that this was because I think IE does not always render style colours correctly, but then I realised that it is not a style, it is an image. I cannot understand why these two images are being rendered differently.
Unfortunately, because of who my client is, I cannot include pictures, and I accept that this will make it harder for anyone to answer, but if there are any suggestions, I would love to know why this is happening.
Thank you.
Try saving them in a different format. I think this has to do wkth color calibration performed in certain computers (can be set up in Windows fo example, but as I am writing this on the go from my mobile I cant/wont do more research). I think JPEG des not care about this setting and PNG do, or the other way around. Someone else can probably describe it way better..
In a design that I'm working on, there is a recurring image background shape that appears several times in different sizes throughout the site. For example, one page uses it as a huge background images, where the top and bottom part of this image is cut off by the browser edges.
It's not an easy pattern to create with canvas, but as far as I know it's possible. Here's what it looks like.
Am I better off making several images of this same pattern or is this background image easy to recreate through canvas? If it is appropriate for canvas, how do I go about recreating it in the various sizes? I wish I knew how to begin something like this using canvas but it's above my skillset.
I've converted your shape to an SVG shape here: https://gist.github.com/1321653 — use it as you'd like.
According to caniuse.com, SVG is supported on all common browsers except for IE8 and earlier.
For IE8 and earlier you might be able to combine canvg, a SVG-to-canvas library, with explorercanvas, a canvas emulator for IE8 and earlier. Or you could display a rectangle with a background color — IE users might not miss the splat.
Edit: You could also get creative with CSS3 background gradients, ala http://www.ecsspert.com/ (famous logos created with only CSS), but compatibility is low across browsers.
On the left is the original PNG and on the right are versions reduced to roughly half the original size using width and height.
Why does the resized image look so fuzzy in Firefox? Is there anything I can do about it without changing the image file? The fuzziness is particular annoying if the image contains large amounts of math or text.
I know this is late, but you can trick firefox into rendering the image better by applying a oh-so-slight rotation. I tried to translate() the image to get the same effect... to no avail.
CSS
.image-scale-hack {
transform: rotate( .0001deg );
}
Javascript
if( "MozAppearance" in document.documentElement.style ) {
$('.logo img').addClass('image-scale-hack');
}
I avoid browser sniffs at all cost. I borrowed this sniff from yepnope.js and I don't feel bad about it.
Also noteworthy, this same trick can be used to force sub-pixel image rendering in both webkit and firefox. This is useful for very slow animations - best explained by example:
http://jsfiddle.net/ryanwheale/xkxwN/
There is a longstanding bug ticket filed in Bugzilla related to Firefox image downscaling. You might like to keep an eye on the ticket to track its eventual resolution or contribute a patch yourself if you feel able to.
The best workaround is to use the transform CSS property to apply a tiny rotation to the problem image and force sub-pixel rendering, as detailed in Ryan Wheale's answer.
The image-rendering documentation linked from the Firefox blurs an image when scaled through css or inline style answer which Su' referenced includes instructions for using image-rendering:optimizeQuality (which corrected the issue in my testing on FF4) - example:
I think your answer is in the link from above https://developer.mozilla.org/En/CSS/Image-rendering:
'Currently auto and optimizeQuality are equal by default, both result in bilinear resampling.'
'default value IE8+: bicubic (high quality)'
Next see:
http://www.codinghorror.com/blog/2007/07/better-image-resizing.html
'When making an image smaller, use bicubic, which has a natural sharpening effect. You want to emphasize the data that remains in the new, smaller image after discarding all that extra detail from the original image.'
I can think of a couple of possible workarounds, but neither are simple:
Resize the image on the server. Either serve it up at half size, and allow Firefox to scale it up to full (which presumably it will be ok at), or have different URLs for the different sizes of image.
You may be able to make this work in the browser with plugins (but the example I found doesn't actually do what you need, so I've removed it).
TL;DR: Image scaling is not likely to be fixed soon. About anywhere.
Longer version:
Eris Brasseur has a page that deals nicely with the broader question "Why is just about any image scaling software so bad?"
http://www.ericbrasseur.org/gamma.html
Since W3C's position on this matter is roughly that it's better to have an incorrect but equally incorrect implementation everywhere, they shun any proper dealing with Gamma (which would complicate matters slightly). Thus anyone accustomed to web standards is likely to continue ignoring Gamma, leading to the effects described by Eric and in this thread. This ensures that even downscaling is far from being well-defined, as Jeff Atwood puts it in an Article linked in another answer.
In such an environment, methods like Lanczos thrive whose claim to fame is mostly that they perform quite well even if implemented incorrectly.
In other words, browsers are the software equivalent of McDonald's burgers, and that fact will stay. Its implications need not, but the odds are skewed.
Now (2017) the bug is closed 2 years ago. A short Test:
FF, 50%:
FF, 25%:
A workaround for this issue is just to resize the original image with an image editor to the desired size and to use the image as it is, without defining it's width and height in the style sheet.
I'm trying to optimize my site for speed. I used images for the rounded corners before but now I've changed them with border-radius and -moz-border-radius css rules. Which way is the best for speed? I used to think that css rules are faster but I've seen a lot of sites talking about css sprites and I'm a bit confused now. Oh and I don't care about IE compatibility so you can suggest any method you want.
The speed goes like this: CSS > sprites > separate images.
The sprites is when instead of having separate images for the corners you use a single image and slice/position it with CSS. It's fatser, because you only download one image then. CSS is the fastest, because it doesn't need to download anything.
For those browsers that support radius CSS properties, use those. They are definitely faster, because no image needs to be loaded and they can be rendered by the browser's native engine.
For those (older) browsers that don't, apply an image-based workaround.
Don't worry too much about this stuff, though. The speed improvements reachable through optimizations in this area are very, very minuscule.
Both are exactly the same, except that because CSS3 specifications has yet to be finalized, Mozilla implemented border-radius with the -moz- vendor prefix. You'll need that, and the -webkit- version for rounded corners to function on Webkit (Chrome, Safari) and Mozilla (Firefox) browsers.
As for speed.. it is unclear whether you are talking about transfer or rendering speed. In either case I would suggest that the difference is negligible, and you should use all three for maximum browser support (minus IE, of course)
I would recommend CSS Sprites. This is a good tutorial: http://bavotasan.com/tutorials/simple-rounded-corners-with-a-css-sprite/