How to make QR code render crisp when shown large? - html

Here is a QR code which encodes "sup":
And here is a simple HTML snippet to render that larger:
<img style="width:400px" src="data:image/gif;base64,R0lGODdhFQAVAPAAAAAAAP///ywAAAAAFQAVAEACT4QPoRfozJpMdJrZKrY6YSgpWeVpI/ItC3l5I3eiZCxnofU+1IzvLCtSBX0bUatl+xyDmxLTxbxFnxdOVRZRoU7TnHBrDBt9xE7EBW2eRQUAOw==">
Unfortunately, this renders in browsers as a larger blurry image:
I know that I could recreate the image at a large resolution. But I am from the school of thought that images should not be upsized for presentation purposes.
Can I do anything to render this without being fuzzy?

You can apply a CSS rule to change the scaling algorithm.
img.qr {
image-rendering: pixelated;
}
This has decent browser support. https://developer.mozilla.org/en-US/docs/Web/CSS/image-rendering
What I prefer to use instead is SVG for QR codes. Then, they can be saved for other purposes elsewhere.

Try adding the image-rendering: pixelated; CSS style to that element. This will preserve the pixels as it scales.
Keep in mind that there’s different cross browser support for this tag though, e.g. Chrome and Firefox require different tags to get this to work. More info here

Related

Print background images and colors in IE without checking “Print background colors and images”

I have added a media="print" stylesheet, I have added *{-webkit-print-color-adjust: exact;}
But only chrome displays backgrounds (images and colors)! Is there a solution to fix it without checking “Print background colors and images” ?
As noted on MDN
This feature is non-standard and is not on a standards track. Do not
use it on production sites facing the Web: it will not work for every
user. There may also be large incompatibilities between
implementations and the behavior may change in the future.
As such it should not be relied upon, indeed support in Chrome is marked as 'Buggy', all other browsers are not supported, note that the use of the -webkit- vendor prefix denotes intended 'support' in webkit browsers, IE does not use the webkit engine.
Typically, you are not able to determine / override / code the option to print background colors and images. One approach is to utilise other properties / elements, such as using img elements for actual images, or using pseudo elements with extremely wide borders to mimic background colors. However, often neither is practical.
Unfortunately support of even the print or paged media modules accross browsers is terrible. Indeed, the CSS working group has a large discussion around the whole topic

Render identical text in all browsers

I am stuck in a problem and require your guidance.
We want to display 100% same text in Mozilla, Chrome and IE11.... same word spacing, line height etc.
So far what I learned is all 3 browsers use different render engines and different font file extensions.
Is there anyway we can force all three browsers to use same font rendering engine or same font extension to achieve 100% accurate results?
Already tried the following trick in CSS but no result:
text-rendering: optimizelegibility;
The only way to control the rendering engine used is to make pre-rendered images of text and use those instead of real text. Use alt attributes on the images, so screen readers and search engines etc can make sense of it too.
Even with images, browsers on different systems may scale it slightly differently. You cannot guarantee every pixel will be identical (and you shouldn't try).

Need to have different CSS for safari, chrome and firefox

I've realised that my css won't work the same way in different browsers. Especially width and position differentiates between the browsers.
I've come to understand that telling the browser to chose different stylesheets depending on which browser's used isn't preferable. But how do I code things otherwise if I am to do it all in the same stylesheet?
Right now I'm struggling the most with an .mouseenter and .mouseleave animation where I can't position things to work even somehow correctly in all browsers.
I'm using em's to define distances/sizes, in case that would matter.
Some ideas for your reference:
It's really true that Self-created css and javascript may not support different browsers very well all the time, that's why ppl shift to use css framework(such as bootstrap) and javascript libraries (jquery etc).
but if you don't want to use framework, then u may do css hack to your css.
such as css piority overrides,
browser compatibility / detection tags is widely used.
#media query & reloading page for different css on different resolutions (used in many responsive sites)

Icon Font vs. SVG caching and network concern

Setup
The topic SVG vs. Icon Font is well covered in the web. But even after long searches, I did not find advice concerning my special situation.
I have a site served by a CMS. On one page, I have elements containing several icons. These elements are repeated over the page. So each icon shows up a lot of times on the page. Now I have a hard time to figure out how to realize those icons best.
Inline SVG
In general, I totally see the benefits of using Inline SVG. It's most simple and straightforward, and you can do the most with it. On other, non-repeated places on my website I already use it and I love it.
But: Repeating the exact same svg markup over and over again seems like blowing up the document unnecessarily.
Referenced SVG
I could use the SVG via the <img>, <object> or <embed> tag. Doing this, the SVG would be referenced and therefore only data that is unique is transfered via the web.
But: Besides things like using the side CSS for the SVG ist not possible, I have several extra HTTP requests.
Icon Font
I could use an Icon Font. Only one HTTP request and content is referenced.
But: Bad markup, bigger file than the SVGs.
SVG Sprites
I could use a SVG sprite. Only one HTTP request and reference.
But: It's quite comlicated and feels as much as a hack as using the Icon Font does. Plus I have the impression that background-SVG ist not so easy to use.
Conlusion
To come up with the best solution, I think the following questions are relevant:
Is repeating the SVG markup so bad compared to the other solutions? It's what I do with the HTML markup anyway. A SVG-Icon are about 30 lines / 1.6kB of code
Networkwise: Are several small HTTP requests (referenced SVG) or one big (bigger than the small ones combined, icon font) request faster?
Which advantages do I really have using SVG sprites compared to using an Icon Font? I guess it's at least as much CSS-fiddeling as an Icon Font.
Please note: I use AJAX, so only content is transferred. The icon font would load with the first request of my website (and then be cached), the referenced SVGs would load with the first call of this special page and then be cached. Inline SVG would be transferred on each call of this page, as content is not cached in the browser.
My feeling is an icon font or inline SVG would be best. But I am thankful for every contribution and aspect of this topic.
Why would you repeat exactly the same markup when you could use <use> elements to reference and display multiple instances of that markup? Here's a link to an example.
As for <img> <object> etc browsers can cache these if you set Expires and Cache-Control appropriately in your http responses.
Using Icon fonts would seem like you're shoehorning into something inappropriate for your use case.
In all given your requirements, <use> elements would seem most appropriate.
There might not be a best fit answer to this situation beyond weighting out the pros and cons of each.
I personally tend to go on the all inline approach, especially if the combined file footprint is smaller than a font or one huge svg.
using <img> is great if the browser can cache them (especially if you have lots of repeat visitors)...but you end up giving up on the styling and interaction options. you also need to add a bit extra mark up for some older browsers to serve a png file in the case that svg is not supported.
If you are interested, here is a hack I use for serving pngs vs. svg basically it fixes IE:
<!--[if lte IE 8]><img src="img/youricon.png" /><![endif]-->
<!--[if gt IE 8]><img src="img/youricon.svg" /><![endif]-->
<!--[if !IE]> --><img src="img/youricon.svg" /><!-- <![endif]-->

Change font size in HTML [duplicate]

I have a CSS declaration like this:
font-family: font1, font2, font3;
where font1 is an embedded eot/ttf font, but the problem is that this font is smaller than the other fonts so I want to have a different font-size (1.8em) for this font (font1). All other fonts (font2, font3) stay untouched.
The problem is, that I cannot verify if the user's browser uses font1, font2 or font3. Is there any css declaration which allows different font-sizes for different families?
Thanks.
There is a way to do this, but it's as of now very badly supported. The CSS property you are looking for is font-size-adjust - a new CSS3 property introduced specifically to address this problem. The specification says:
In situations where font fallback
occurs, fallback fonts may not share
the same aspect ratio as the desired
font family and will thus appear less
readable. The font-size-adjust
property is a way to preserve the
readability of text when font fallback
occurs. It does this by adjusting the
font-size so that the x-height is the
same irregardless of the font used.
However, it is only supported in Firefox as of now, so you might want to look for alternatives.
For examples of how to use it, see:
http://webdesignernotebook.com/css/the-little-known-font-size-adjust-css3-property/
https://developer.mozilla.org/en/CSS/font-size-adjust
http://www.fonttester.com/help/css_property/font-size-adjust.html
http://www.w3.org/TR/css3-fonts/#relative-sizing-the-font-size-adjust-pro
I know it has been a while, but recently I stumbled upon the very same problem as described by the OP. As font-size-adjust is still very poorly supported, I'd like to share another solution that worked for me:
Note: The following solution does only work if the fonts are embedded using the #font-face-declaration.
In that case just include e.g.
size-adjust: 90%;
in your #font-face-declaration. The relevant font will appear at only 90% the size of the specified size.
Browser support
Browser support is currently at 74% with all major browsers supported except for Safari and IE. I know this is far from optimal. But as this problem is "just" about design and not about functionality, I suppose it is better than nothing.