TL;DR: Is it possible to load other images based on media-query from svg included via img tag?
I generate a bunch of svg files with have tables with text and icons inside. A PDF would be semantically a better container, but I need to keep such "documents" as images for seamless embed/preview and it probably won't solve my problem. So the story is about icons.
I wrote inline styles with media queries picking icons corresponding to user's screen DPI. Icons are already bundled into sprites, so I use pattern/image[xlink:href] + fill:url(#id). Everything works as needed when I embed svg directly into HTML (DOM islands). But if I embed svg via img tag (i.e. <img src="foo.svg">), it doesn't load icons at all, let alone showing them.
I understand, that I can embed icons via data-URL, but embedding icons for all supported screen dpis seems too much. The irony is that icons are raster ones, hardly vectorizable pixel-art, so I cannot have one set of icons for all DPIs.
Is there a way to have proper icons picked by media query w/o embedding them all?
You can't load external files from an SVG used in an <img> tag (or used in other "image" contexts, like CSS background images). For security and performance reasons, SVG used as image has to behave like any other image -- a single file, no secondary resources and no scripts.
If you don't want to use inline SVG, you might consider embedding an SVG file with an <object> tag or <iframe>. However, I recommend that you actually test carefully to see whether browsers are downloading the image files even if they aren't using them because of CSS.
So since it's not possible to load conditionally: either embed or not, I should do some clever detection about raster sets. Technically not a direct answer, but in case someone needs.
I decided to go with cookies. People visit normally the same site that hosts those SVG.
I'd set a cookie for their DPI and then all SVGs served would pick proper DPI images.
For people who haven't visited the site yet, I'd go with UA sniffing: mobiles and macs get 2x, others 1x. Or just 1x for everyone.
Related
My manager tells me not to use icon fonts on our websites, as it is another http request plus the extra kBs to download. Also because I would have to use content before for the font (I can't change the html), he prefers background images so it works in IE7.
Personally I love the little things, so nice and crisp and resizeable!
I get it if we only use a couple of icons on a website but if I would use, say 5 icons on a site - what do you guys think? Is it worth using an icon font or is he right thinking that it is not?
I am just a sucker for anything new and exciting, and this year it is the retina display.
Icon fonts and high density screens
Using icon fonts will be more and more relevant as more high resolution/density displays become available.
A 16×16px icon can look horrible on a high density display (>300ppi). It may either display incredibly small or unsharp due to automatic scaling. A 1em font icon on the other hand will render correctly and sharply regardless of screen density.
It of course all boils down to your
application users and
your requirements (IE7 seems to be the major breaker)
For now sprites are the way to go.
Downsides?
Icon fonts have a different problem as well. All icons are single colour. There's no font standard as of yet to have multi-colour capability. And it likely won't be. At least not for fonts. There are possibilities of doing multi-colour using SVG fonts which isn't a font standard/format per se but can be font container and used as a font delivery mechanism in your browser. Doing multi-colour icons as SVG fonts makes it possible to have colourful scalable icons (thanks to #Joey).
Vectorised icon images would better suit full colour resizeable icons.
Requests and font icons
Your boss' argument about additional request are simply false. It doesn't really matter whether your icons are part of a file or (in best case) part of a sprite image.
Both yield an HTTP request to fetch the resource. File size heavily depends on complexity and format but it may be that sprite image will be smaller. But having a few kilo larger font file doesn't really make much difference. They both get cached on the client afterwards.
I personally use Font Awesome as my primary resource for fonts, In my case I load it from the CDN hopping other pages that use it already fetched it and this was cached by the browser.
If file size is a concern, I can recommend to you this incredible awesome tool
http://fontello.com/
It allows you to merge several fonts into one single file, and only includes the icons you actually use.
http://www.icnfnt.com/ does the same for fontawesome, but I kinda like more fontello because it allows to use more fonts.
icon fonts is the way to go honestly in my opinion...
EDIT I lately have being using this app a lot too: http://icomoon.io/
When you use fonts, different browsers on different platforms will give different results. PNG files will give stable and independence results.
I have implemented a font icon library using icomoon and it works well on all the browsers including ie7. For small sets of icons this is a suitable practice, the font's scale properly, can be changed to any colour you require and you don't have to worry about PNG/GIF transparent background colours matching.
However... If your library becomes larger (mine is now around 40 icons), it becomes increasing difficult to maintain. If the designer ceases to work on the project, or you need to change the icons, it is a laborious process to update the fonts. Everything then needs to be retested. It is also difficult to dynamically icons using CSS (for ie7).
So, given the difficulty of maintenance, I'm considering switching back to a series of sprites (of different colours). The reasons being:
Any designer can easily add a new icon to the set.
The CSS doesn't need to be retested or altered.
You don't have to screw around with javascript workarounds for IE.
You don't need javascript at all.
For retina displays, simply create a verion of the sprite at twice the size,. You will probably need to have a different version of the CSS for retina regardless, as all the other images on your site will have the same density problem.
I would recommend 2 solutions to your problem these is what i would use for best customers support like they wanna change the text, size or other stuff
Use Fontsquirrel to make a webfont and embed it in your website trough your css and add it in your ftp directory if thats not getting pretty then use google web fonts
If non of that looks like it should i would go for the image solution your boss said..
All this also depend on which amount of time you have to solve your problem and such
Btw if you cant access the html i thought you could access the css which you can do trough most backends, if you cant then go for the image!
Last but not least, if you decide to go with the image solution, make a sprite which you direct trough on a background position. This way you only have to load 1 picture for all your little icons.
He's right. I'd use css sprites in this case. And if you have to support ie7 (I'm so sorry) you don't really have any options. Exploring those things on your own - of course, you never know what will come in handy or when.
I am a newby to design and looking now into the use of background instead of foreground images, which is a common practice.
I look at the techniques used, and see that:
you usually need to explicitly state the dimensions of the image (and set the foreground element to these dimensions)
you need to make the foreground element to somehow disappear with css tricks.
All this looks really hackish. So, I wonder, why on earth do all this instead of just using the native element? I am sure there is a good answer
(I did go through this When to use IMG vs. CSS background-image? , and could not figure out a clear answer)
One thing to consider as a benefit to using CSS for images is that you can load all your design images (images for UI elements, etc) with one http request rather than an http request for each individual image using a sprite. One large image that contains a grid of all your images.
As its been stated before, content images should use the img tag which also helps for people using various accessibility options when visiting your site/app. For example, if they are using a screenreader, the screenreader knows its an image and can read the img alt name or title, but if its just a div with a background image they get nothing.
The main difference is that in the img tag the image is hardcoded.
With CSS you can create different designs, switch between them, redesign the page, without altering the source code. To see the power of CSS, check http://www.csszengarden.com/, all the pages use the same HTML source, but with different CSS layout.
As #Shmiddty noted, if img is for embedded images (actual content, for example a gallery, or a picture for an article), and CSS is for design.
Also, the question you referred to, has nice list of all the use-cases: When to use CSS background-image.
The goal is to separate content from presentation. HTML should contain just content, and all presentation should be moved to the CSS. Once you achieve that, you gain a few useful side effects:
The CSS (presentational code) is cached by the user's browser, and each HTML file requested is smaller. This also has some SEO benefits (decreased code fluff).
Screen readers have to muddle through less when interpreting your page for visually impaired users. Making sure your HTML contains just content means visually impaired users reach what they're looking for much quicker.
CSS makes it possible to display the same content in different visual configurations, which is the cornerstone of the responsive web design movement. Properly delineating your content and presentation means being able to use the same HTML files across multiple platforms (desktop, tablet, smartphone).
However, there are times when images are content on a specific page. In those cases, you want to use an IMG tag, and moving the image to the CSS is actually a wrong move. A great discussion of when and where to use text to image replacement is at When to use IMG vs. CSS background-image? Basically, my personal litmus test is something like: Is this image going to be used multiple times on the site? If it is, it's probably part of the design. Once-off images are generally content.
If you're looking to move your design images to the CSS, congratulations :-p You've adopted a healthy amount of work, but started doing something worthwhile to the long-term health of your website as part of the web ecosystem. I would highly recommend looking into using the SASS/Compass system to manage your design images as sprites (see A List Apart:CSS Sprites and Spriting with Compass).
One of the main points of image replacement is to use your site title in a h1 tag for good SEO, and then hiding the text and replacing it with a custom logo.
This also makes your site more accessible. Say for example, your user has CSS disabled for whatever reason (screenreaders, maybe). They would still see the textual representation of your site title, whereas normal users would see the custom graphic.
I have created the layout of the website (template). I used Photoshop to design the picture and sliced it to create the divs. It gave me an HTML file including the HTML and CSS code. I separated these in two files HTML and CSS. The background images were being called inside the <div id="idName"> tags as <img src=... tags. I changed this. I loaded the images in the CSS file as
idName { background-image: url(URL); }
All the images in the site are loaded like this creating the background as a whole.
Now my question is: Is this a bad practice? because if I leave the images inside the <div> tags I wont be able to put my content on top of the image. With the background-image attribute in the css file I can put my content anywhere, not having to worry about the background.
No, this is perfectly fine, and actually may be a best practice for background images. Moving the image declarations into the style sheet means the images may be downloaded a little bit later, but most browsers should have enough other resources to load in the meantime, and you'll want prioritize HTML and stylesheets before background images anyways.
Just don't use CSS backgrounds for actual images: If the fallback background color would significantly change the meaning (i.e. the image is content), you should use <img> elements with an alt= attribute. If you're not sure whether this is a good idea, consider this question.
To increase performance (by reducing the number of HTTP requests), you may want to consider using CSS sprites.
Ok, So I designed a responsive layout that doesn't show images for very small screen sizes, using media queries and display: none;.
So far so good. But these images still download on these devices, causing an increase in bandwidth.
What is the proper way to make these images not download on the specified devices?
Any response would be much appreciated!
Two options I can think of:
Detect small devices on the server using browser-sniffing, and send them different HTML that doesn’t reference the images.
Display the images via CSS instead of HTML (in style attributes if you like), using either background-image or :before/:after and content (not supported by IE 6 or 7), and wrap that CSS code in media queries so that it’s only displayed by devices with larger screens.
The only accessible solution right now is to wrap the image with <noscript> tags, then pull the image out later with javascript. Cookies don't work on first page load (HTMLPreloadScanner), nor with CDNs. Browser-sniffing is useless if your images aren't always 100% of the viewport.
Slimmage.js implements context-friendly responsive images in 3KB of vanilla JS.
The markup is pretty simple as well:
<noscript data-slimmage>
<img src="http://z.zr.io/ri/1s.jpg?width=150" />
</noscript>
Of course, you can make a server-side helper to even abstract this away.
If you don't mind a javascript dependency you could check window.innerWidth and insert image tags for sufficiently large screens.
Images would only be requested if javascript is enabled and the window big enough.
If you don't have any issues using additional JavaScript, then you may try THIS. I've stumbled upon it while searching and learning about media queries.
I have an image that I use many times. In several cases I want to shrink its size, but obviously it loses sharpness when I do this in HTML.
Is there a way to fix this? The image is located elsewhere and I can’t save it locally.
Thanks
As dheerosaur states, SVG graphics can be used when you need to have the same image in multiple sizes but don't want to compromise quality.
Another thing to do is use an online service, such as Resize.co. You pass them the URL for your image file, the attributes and they take care of everything else.
You cannot control the way the browser renders images when they are resized. Images will look better when being passed through Photoshop's filters (or those in another tool) upon resize.
There is three way that I know to reduce an image file size in bytes :
Convert the file into a format using lossy compression algorithm such as JPG. Obviously the image will lose sharpness
Convert the file into a format using lossless compression algorithm, like PNG. Only works if the image contains lots of region with flat colors
Resize/resample the image using Photoshop or GIMP. If the new image dimension (width x height) is exactly the same as the displayed image's dimension in HTML, then web users will still see a sharp image
Firefox and Internet Explorer actually do have CSS properties that adjust the way images are rendered when resized via HTML attributes or CSS properties:
Firefox: image-rendering
Internet Explorer: -ms-interpolation-mode
These won’t work in other browsers, and may not work great in all (or any) versions of IE and Firefox.
But it might be worth experimenting with them as a fallback in case resizer.co causes any issues.