<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 :-)
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 have a site, here, that I'm working on which uses some html5 and css3 elements which obviously do not load correctly on certain browsers and i have a few questions about what I can do and I don't have much experience with any codes like php or javascript. these questions are kind of a mess as well - I've been searching all over not really sure of what I should be looking for.
How would I go about creating a popup based on which browser is being used, if possible?
I understand that I can use conditional comments for IE but IE is not the only unsupported browser. Is there a way to activate certain elements, or div's depending on the browser?
How would I go about creating a version of the site that would be shown instead of the unsupported version?
Is there a better way to do this?
These questions may not be the right ones - if not and you know an answer to the question I'm looking for, please, go for it! Thanks!
There are a few tools I would recommend:
Modernizr
Feature detection, allowing you to target features in CSS and JS. It doesn't add features, just lets you test for them.
Includes HTML5shiv functionality Also does a lot more – if you don't use the other features, then don't use it, it does slow down page loads, but is worth it if you need it!
HTML5shiv
Very small, allows you to use html5 elements in IE, nothing else.
CSS3PIE
Lets you use border-radius, gradients and box shadow in older versions of IE. Also can allow PNGs in IE 6. Adds a noticeable delay to page load.
ie7.js (and ie9.js)
Gives you many CSS3 selectors, min and max width, multiple classes and fixed positioning. Also can have a png fix if you like. Doesn't seem to slow things down much.
You can use the moderizer script to bridge the gap for html markup.
I wouldn't really worry about CSS3 working or not in IE. If you have a supported browser you get an enhanced user experience and if you don't you would just get a normal one.
I have just started web development after a few years. Mostly in the past I would specify a style-sheet dedicated to IE6. Now, Chrome and Safari seem to be rendering elements better, over FireFox.
What is standard procedure for external style-sheets these days? IE6 (STILL?) - IE8? FF even?
It would be greatly appreciated if anyone has advice specifically catered to marketplace development, ie XHTML / Wordpress development.
There is no specified number of stylesheets. Usually it is one for IE and one for rest of the browsers. Note that there exist solutions such as ie7.js or CSS3 Pie to make IE behave like standard-compliant browser.
I personally use 2 stylesheets. One core one, and one for IE6.
Most of the modern browsers simply ignore anything that they don't support, and dont have quite the sheer number of behaviours that require hacks.
Given that a stylesheet isn't required at all, the answer is none. I would still say you need only 1 though. (If you've created your css properly and used a proper doctype). Technically you shouldn't need to have browser specific styles at all. And for the few times you might, you can use Star Hacks for IE...
I think question you're asking relates back to the much bigger topic of how best to handle cross-browser issues.
It's a wide and varied topic, but to help you with you're specific question about CSS branching (forking)... you may be interested in the following article from "A List Apart"
"Stop Forking with CSS3" http://www.alistapart.com/articles/stop-forking-with-css3/
Cheers.
I am trying to make my own website and it was coming along quite nicely. It looked beautiful in Firefox when opened and worked wonderfully. But then I run it in any other browser and it does not work. How can I fix this? Interner Explorer especially hates it =[
You just got to see it to know what I'm talking about so here is the link:
http://opentech.durhamcollege.ca/~intn2201/brittains/chatter/
Please give solutions that don't involve JavaScript.
Rendering differences between Firefox and Internet Explorer are really the daily trade of everyone who designs web pages.
You should start identifying which elements exactly cause the problem(s) and then formulate a question regarding exactly that. (or do a Google search, all those incompatibilities and how to fix them are documented somewhere on the net in some form.)
Also, I'd recommend you download a Tool like IETester and check out which versions of IE the site fails in. It looks pretty OK in IE8, but the inline frame looks bad in 7.
Then, really make sure your page is valid. (It probably shouldn't be XHTML, but have a HTML doctype.) This is not to conform with some rules, but because validation catches an awful lot of errors like unclosed tags that screw up the rendering. This isn't the case in your case right now, but still I'd recommend doing it.
On the long run, these tools are going to be very helpful:
Firebug in Firefox (Right-click any element on your page and choose "Inspect element..." it gives you heaps of useful information
The Web Developer Toolbar in IE8 (press F12 to open it) that is similar to, if not as powerful, as Firebug.
OK, I had a look at the page in IE6.
Some tips.
Try to avoid tables for layout. I admit that putting the fancy border around the "welcome" area, is much easier using a table than any other way, but the other tables are completely unnecessary, and the cause of your much of your problems, because browsers, particularly IE6 and IE7 like to do their own thing when deciding how to lay them out.
As bobince says, table-layout:fixed on the signupTable1 will help a lot
Also, for IE6, giving the td containing "welcome" a height of 100% helps.
The margin widths of the items in the cells in the signupTable1 are percentages of the cell width in FF, but percentages of the screen width in IE6. You should add some IE6 targeted css to compensate for this.
Finally, as far as I can see, your markup is immaculate polyglot HTML/XHTML and serving it as text/html and using an XHTML doctype should not cause any problems.
Your page declares an XHTML doctype, yet it is not valid XHTML:
http://validator.w3.org/check?uri=http%3A%2F%2Fopentech.durhamcollege.ca%2F~intn2201%2Fbrittains%2Fchatter%2F&charset=%28detect+automatically%29&doctype=Inline&group=0
Furthermore, it's returned with a content-type header "text/html", which is wrong for something that's supposed to be XHTML. Unfortunately, the correct content type will not work either.
So there are two things you have to do:
Don't use XHTML
Make your HTML validate
Then you can start thinking about actual browser incompatibilities.
It looks the same in Firefox 3.6.2 as in Internet Explorer 8. However the old browsers are the evil ones:
search the web for Internet Explorer + margin, because thats where Internet Explorer fails.
Simple trick: do not use margin.
position:absolute;
top: 80%
left: 100px;
And then... google for specific stuff :)
Ok I fixed 2 errors finally figured them out
changed
#loginForm {
float: right;
}
#loginTable {
margin: 20%;
margin-top: 14%;
}
to
#loginForm {
float: right;
margin-right: 5%;
margin-top: 2.5%;
}
#loginTable {
}
and added
<!--[if lte IE 7]>
<style type = "text/css">
#loginForm{margin-top:-157px}
</style>
<![endif]-->
not a solution I like but one I will have to deal with.
Ok still leaves the issue of I hear there is a 100% height problem and my horizontal borders wont stay the correct width.
First, make both your HTML and CSS to validate:
HTML validator: http://validator.w3.org/
CSS validator: http://jigsaw.w3.org/css-validator/
Then, if your valid code still fails in particular browser, find the problematic HTML element using the browser's debugging / inspection tools:
Safari / Chrome: built-in Inspector
Firefox: separate plugin, among the best is Firebug
IE8: built-in Developer Tools
IE6/7: must be downloaded and installed from Microsoft
Opera: built-in Developer Tools
As long as you use valid CSS 2.1, differences between modern browsers should be minimal or almost non-existent. Yes, modern browsers do very good job in implementing standards, especially if you avoid bleeding-edge not-yet-fully-standardized techniques (CSS3, HTML5). (We are forgiving and count IE8 as "modern" here despite its CSS 2.1-only support, PNG issues, slow JS speed, etc.)
Oh, one thing not related to validness: always remember that many UI elements (fonts, buttons, etc.) are not rendered in exactly equal sizes in different browsers / platforms. Also screen sizes may vary largely due to popularity of mobile browsing. That's why you should prefer elastic / fluid layouts and not rely on pixel-perfect rendering.
Most IE 6/7 bugs are the same old common ones repeating and there are plenty of resources about fixing them. Create separated stylesheet(s) for IE(s) and include them by using conditional comments.
As a final comment, as long as open standards / technologies are used, personally I couldn't care less supporting a decade old browser, except in form of graceful degration, unless I'm paid generously for that. Browsers are free to upgrade, there are no reasons not to do that. No excuses. World is not static, show must go on, you won't see HD with your old tube telly, etc.
I also think it's our responsibility as web developers to force the big masses to adopt new (open) technologies, because they save huge amount of our time, makes possible to create better end-user experience, etc., the list of benefits is endless. Again comparison to other industry: consumer electronics companies keep pushing out new things, although most people would happily use 20 years old tech unless forced to upgrade their (naturally conservative) mindsets.
The messed-up borders around the ‘welcome’ box and the wonky centering is because you're using ‘auto layout’ tables for page layout. This leaves you at the mercy of the auto table layout algorithm, which is complicated, unreliable, and a bit broken in IE.
For places where you must use tables for anything more complicated than simple data, set table-layout: fixed on the <table> and add explicit width styles on either the first row of <td>s, or on <col/> elements just inside the table. Columns you leave without a width style will share the remaining spare width between them. Set an explicit height on the rows containing fixed size images to stop them sharing the table height.
However, for the main page layout here you would be much better off using CSS positioning or floats rather than tables. You can use nested divs (each with a separate background image) to achieve the image border effect without resorting to tables.
If I were you, I would not bust my guts trying to make the site work for ancient browsers like IE 6.
Indeed, one could argue that you would be doing the world a favor if you made your site refuse to work with IE6. Anything that can help to push IE6 into the grave is a good thing.
If Google can say that IE6 is no longer supported ... so can you.
Now if you were building this site as a money-making exercise, and demographic included a significant percentage of IE6 users, maybe the pain of supporting ancient non-standards-compliant browsers would be worth it. But otherwise, I'd say it is not.