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]-->
Related
I am writing an introductory HTML course. I remember discovering 9 years ago as I was learning HTML that both <img> and <image> worked as the tag for displaying images, at least in IE. Indeed, <image> still works in the latest versions of the 5 top browsers.
I realize that <image> is incorrect and will not validate with http://validator.w3.org. However, is anyone aware of a browser that will not display an image if <image> is used instead of <img>?
Furthermore, I assume the modern browsers display images created with the <image> tag simply because it is a common mistake that beginners make. Is this assumption correct?
Yes and no. As you point out <image> has been a synonym for <img> for a long time. I believe it was an early Netscape browser that first did this, possibly to compensate for user error, or possibly because there was dispute at the time whether the element should actually be called <image> or <img>.
Anyway, as pst points out, once it was implemented in a browser that dominated the market of the time, web pages came to rely on it. Its persistence is then down to commercial pressure on the browser manufacturers. If all the major browsers support it, then Browser A decides that although it supported it in Version V, it won't support it in version V+1, as soon as version V+1 is released, they get lots of messages saying "Site S is broken in your latest browser. You browser is rubbish. I'm going to switch to browser B".
The HTML5 parsing spec requires that the <image> tag is mapped to the img element at the tree construction stage, so there can never be any justification for using it.
I would be less concerned about browsers, than other HTML consumers, such as the lesser known search engines. I believe that the image for img synonym is not widely known, and the many such tools would therefore fail to pick up <image> as referencing an image resource.
They have different usages in SVGs. The image tag creates a specific element in an SVG and can not be replaced by the img tag.
Fiddle Example
I just finished debugging this problem, which I was committing, having not previously read the above answers.
While not full-blown browsers, an email client is often used as if it were a browser.
I discovered, the hard way, that the Android Gmail client, using naked HTML (with a default naked DTD specification), does exhibit this problem. It only responds to <img /> [i.e., not <image />]. gmail.com is fine with <image />, but not the Android gmail client.
While an email client isn't really a browser, I thought you might be interested anyway.
Indeed. Modern browsers will display code that is not valid in order to make sure that old websites still display correctly and slightly-invalid code doesn't screw up a page.
For example, forgetting to close a <tr> before you open a new one - all modern browsers will simply assume you closed it.
I'm not aware of a well-used, up-to-date browser that will fail to display an <image> tag, but will display an <img> tag.
Image is used by the DOM and is why it maps to the img tag in the html. Notice when you use background-image in css or drawImage in javascript, it is fully typed out.
Img is identified as an html tag referencing an image. A side note is that you can now use the <picture> tag besides <img> tag in the html.
The <picture> tag in HTML5 has/uses the properties that <audio> && <video> tags have. It helps remove issues with mobile device sizes and todays hi-res images.
What works well on desktop still renders properly when applied to a phone or table size screen.
See ~://quick over-view of picture vs. img
From this gist: https://gist.github.com/awesome/9947977, there are many options for adding the favicon graphic. Will many references to the tag slow down the page? Or is this just a bad idea?
Yes, but not that much.
Chrome and Firefox tend to load all PNG icons the first time they encounter the declaration, thus the "Yes". Subsequent browsing does not generate additional, unnecessary requests, thus the "not that much".
Also, I don't totally agree with the code you link to. In particular, all iOS PNG icons (such as favicon-57x57.png) are duplicated and won't be used (eclipsed by apple-touch-icon-57x57-precomposed.png in this example). But Chrome and FF will load them for no reason.
I rather advice you to use this favicon generator. The generated pictures and code support all major platforms and minimize overhead. Well, this is a matter of balance. Full disclosure: I'm the author of this site.
A hyperlink will not make the page load slower. if you want to display all of the icons on the page it will hardly effect the performance because of the low resolution.
I've read that putting CSS stylesheets outside of the document HEAD prohibits progressive rendering to avoid having to redraw elements of the page if their styles change, but why is this? Does it just check to see if any CSS stylesheets are outside the HEAD and delay the rendering? Why can't it just decide to load all the stylesheets first, regardless of the location within the HTML?
Well, I guess that browsers do not wait until they get the entire file (and linked files (.js, .css...)) from the server, for then to render everything in the background and then display it to the user all at once. If you have Firefox, Press F12 and check the last tab... there you can see how the browser loads things.
Unlike downloading a large file, say 200 MiB, browsers usually start displaying whatever they get from the server, as soon as they get it, while still downloading the html/php/whatever file.
You may not notice much of a difference nowadays, with fast computers and fast Internet connections, but I'm pretty sure that, if you throttle your Internet connection, you can simulate this behaviour (page slowly loading).
Having this in mind, it kind of makes sense that the browser would have to "re-render" everything, if the stylesheets were at the end of the page, doesn't it?
When a browser looks at HTML, it goes from top-to-bottom. It can't know whether there are stylesheets at the bottom before loading the HTML. The reason you load your stylesheets in the <HEAD> is so, as you said, it can progressively render the DOM objects with the styles you specified. When it sees the <link rel=stylesheet> it makes a request to get the CSS file. In terms of performance some pages would load really slowly if the browser had to scan through the whole html file for all the stylesheets, determine what styles needed to be applied, and THEN loaded the HTML. From designing-a-browser perspective, I think this only seemed logical.
In general, the idea is HTML provides content and CSS provides styling so they are to be kept separate. I guess browsers were designed so if they did not find a stylesheet, they'd just simply load the HTML anyways because in all honesty CSS isn't really "necessary". It's just eye candy which is an aesthetic that is important to us humans.
Having stylesheets at the top or in the <HEAD> gives the browser a "heads up" (haha!) knowledge of what styles you want to put so it looks nice and then once it reaches the bottom, it will see the stylesheet and then load it.
There is a really good blog post about how browsers work that might be useful.
Well, adding a <style> tag outside of the <head> isn't actually legal in HTML5.
Edited to add: unless you're using scoped styles, which only Firefox supports.
I've spent eons diving into #font-face issues for RTL languages, font-rendering on different browsers, PDF support, and so on.
My objective is to have CSS-compatible Arabic (a RTL language) text on an HTML document, which , when rendered into a PDF, looks, renders, and wraps exactly the same on the PDF as it did on the HTML webpage, regardless of the user's browser or platform.
I've been using #font-face but it turned out that Windows machines render fonts a little wider than they do on a Mac, while the PDF generator is browser-independent and seems to render fonts more like a Mac does. So what happens is that Windows users see one line of text, while the PDF ends up having the last word on that line wrapped over onto the next line, and so the PDF is not exactly what the Windows user expected it to be.
I thought at one point that Cufon could be the solution because apparently it looks the same cross-browser - but I think it doesn't support Arabic? I tried generation PDFs using wkhtmltodpf and PhantomJS, but despite being awesome 'virtual' browsers, both use Webkit QT, which renders text differently from Windows, so once again the PDF that was generated had line wraps or text width that wasn't the same as the original HTML document. Basically, my question is:
What's the best way to ensure that whatever the text the user sees on their browser is exactly what they will see on the PDF? I don't really need it to be exactly pixel-perfect, as long as the text at least follows the same line wraps, with a given width for the containing div. I think the only thing I really need to make sure of is that font hinting is uniform. Or does it all come down to using images?
On an aside, does HTML5 have some sort of cross-browser font-rendering?
I can suggest you two things:
Use em´s for the size of your fonts. em´s are a relative measure.
Don´t use sIFR or anything based on flash rendering due that it won´t work on mobile devices that doesn´t support flash.
There is no way to render the exact same thing across all existing web browsers, that will be like being in heaven. But as we are not there, what I suggest you too is to reduce a little bit the font until it fits your goal.
Regards.
<style type="text/css">
.hidden-image-container {
display: none;
}
</style>
<div class="hidden-image-container">
<img src="lulcats.png" />
</div>
I'm mainly interested in what mobile browsers make the optimization of not downloading an image that's in a hidden container.
This would allow me to signficantly reduce initial download time.
Related reference question about loading images across devices
Someone has tested this before:
http://www.w3.org/2009/03/image-display-none/test.php
Edit:
Looks like the list does not contain many mobile browsers (yet).
I would never call it an optimization for a browser to not download a hidden image. That might have dozens of good reasons and should (and will) still get downloaded by a browser. I don't have some table of numbers or browsers but I'm pretty much sure all mobile browsers will also download such an image as soon as the interpreter spots it.
I'm afraid there is no silver bullet to conditionally load <img> tags with just html/css. Right now you'll need at least a little piece of ecmascript, but as always, I'm very sure the stackoverflow community will correct me if I'm wrong here.
The <img> node has no property like .preventLoad (which would indeed be quite useful). Maybe it's time for a whatwg proposal, I'll join and support it :-)