There is some algorithm of showing "loading" indicator in browsers.
There are even some techniques to trigger this indicator, such as:
Display *browser* loading indicator (like when a postback occurs) on ajax calls
Is there any documentation of it from any of the browser teams?
I assume it's user-agent business and there is nothing in w3c specs about it.
Is it connected with document readiness (value of readystatechange) and how?
What about xmlhttprequests? Initial resource loading?
This is a pretty good rundown of what browsers do what, based on what sorts of actions Browser Busy Indicators.
The bottom line is that regular ajax requests rarely trigger busy states (which is generally a good thing) but content loading in iframes will in some browsers. Generally, the IEs, Safari, and most mobile browsers stay as "quiet" as possible, not even acknowledging page loads in iframes.
I haven't been able to find good discussion or documentation of what the rationale is browser to browser, and it's certainly not a standard that I'm aware of. Vendors just sort of pick and choose.
Related
assume we have the following scenario:
We have an application which supports only firefox only. The applications uses GWT. Some customer requires that the application should also support chrome browser as well. New permutation was compiled for chrome as well.
Question: What should be tested to ensure that we have same functionality on the new browser and how? Should we just start application with the new browser and check page by page and function by function?
Like you say, you would need to check each page and function.
In my experience, when the app does not explicitly style a visual element, the browser's base style for that element is used, and in some cases that can differ a little between browsers, as each browser has a slightly different base CSS. So, depending on your app, you might find things sized or positioned or colored differently.
It shouldn't be necessary to test any differences.
From GWT's overview:
Its goal is to enable productive development of high-performance web applications without the developer having to be an expert in browser quirks, XMLHttpRequest, and JavaScript.
So, unless you do some fancy things, all should work the same way, no matter which browser is used.
The "postMessage" is an HTML5 API, it is available in all major browsers including IE8/9. What I am trying to do is to create a popup window from a page, and be able to talk to the popup window using "postMessage". This works in every browser except IE8/9. Disappointed!
It looks like IE8/9 only allows the communication between iframes, but not between two windows, even the windows are within the same hierarchy.
I found that .postMessage() in IE9 was unreliable unless I used Strings.
My workaround was to simply call .postMessage(JSON.stringify({object: 'data'})) and use JSON.parse() in the onMessage() function on the other end.
The .postMessage method works, you just need to understand how it works from IE8 and up. Unfortunately, for IE8 and IE9 it will not do what you're seeking (though it does in IE10). While you can send messages between frames in IE8/9, you cannot send messages to a separate window.
There is a work-around that works in some instances. Martin Beeby discusses it in the last paragraph of his blog post on the issue: PostMessage Popups and IE.
For more on this, and a few other caveats, see Eric Lawrence's post on MSDN.
A friend of mine threw a website I made through the tool at http://analyze.websiteoptimization.com/ . When he came back to me, he insisted that my browser was preloading tons of unrelated images on only the homepage of the site.
I came back to him, insisting that YSlow (and other 'network' tabs in browsers) prove that only specifically-displayed images and content gets loaded on the homepage-- nothing else. I insisted that the statistics from that site are only for a complete visiting of the site, and downloading all the required images.
However, he's not convinced, believing that some browsers (i.e. IE) will pre-load that unrelated content regardless. For that reason, he uses a global CSS stylesheet, and then applies changes to individual pages by loading a separate stylesheet.
I thought it was best practice to minimize requests to the server, not to add more, which is why we have CSS sprites. I also thought browsers never load images unless they're needed to display the page.
I don't believe I can accept an answer without healthy discussion.
Am I correct in that the browser's not loading EVERYTHING on every page?
Is the above tool incorrect?
Is the lesson my friend's learning from the tool's results incorrect?
Thanks.
The browser will generally only load what's actually shown in the page. (There may however be exceptions in some exotic browsers, like Opera Mini.)
The WebSiteOptimization tool will only look at what images are referenced in the HTML and in the CSS, not which images are actally used in the page.
When I analyse my own webpage, which has eight different background images that are shown one at a time by random pick, the tool says that all eight images are loaded, just because they are in the CSS. Checking the network traffic in Firebug and IE developer tools shows that they aren't.
According to me
Browsers do load cached images at time but newer updates can check if the image has changed. Also there are permissions which coders can set to allow browser caching or not.
when using yslow or Google page speed which is a better tool try and use control+f5 to refresh your page so the site is forced reloaded without any offline files.
You can also set Brower permissions based on your preferences.
I also want to add a little about your last line a browser will load all images linked in the code even if there css property is hidden.
It always loads thing in the img tags first and then all images in the css code.
It will also process the image request in sequential order ie first come first server
I hope this help.
I am in the process of updating my business website and I've decided to use HTML5/CSS3 (with some PHP) for the whole thing and it works fantastic in every new browser (IE9, FF6, O11, S5, C13) with or without JS.
Now I am not sure what I should do about every other browser version. I imagine I have a small amount of leeway with most of the browsers (atleast the previous version) except IE8 (I have the IE shiv, but it doesn't cover non-js browsers.). Most of the features degrade nicely, but there will always be issues with older browsers.
I know nonJS browsers are probably a minority, but it would be nice
to cover them as well
This list is ordered in the order of current preference to cover the
largest number of browsers(nonJS/JS) but time to implement hasn't been
considered.
Only considering web-browsers, plan is for a mobile site for mobile browsers
Here is the list:
Build a really dodge version of the site using tables^, etc. and redirect the users there if they have an old version of the browser (server-side) and have a warning on there about upgrading.
Use Javascript to fix up the bits they don't work (like the shiv). This doesn't really cover the nonJS browsers which as stated are probably a minority.
Build a static old browser page to redirect the old browser users to a page with links to upgrade download links. This is a real copout solutions, but is quick to implement
Assume the only users that have old browsers are IE users, and use conditional comments to implement one of the previous options. Assumptions are always bad
Pretend users have the most upto date browsers and make no attempt to fix the site at all. Not really a practical option
Rebuild the website for HTML4 and use it accross the site. Bit of a waste of current work. As well as it looks a bit dissappointing if a webdeveloper has a site using old technologies, which was the driving force for the upgrade
What are your thoughts/solutions to the HTML4/5 limbo? Is there anything you've done in current projects to combat this?
Cheers,
Steve.
P.S. Being a member of the 'I hate IE6 and don't care for it's existance' club, I'm pretending that IE6 (or less) never existed.
Update (to clarify)
^ - by tables, I mean are really slapped together version of the current website, using either a table/non-table based layout. But something that may not look pretty when the source is viewed, it's really just there to fill the compatibility void.
It's perfectly acceptable to have features in some browsers and no features for an older browser. See Here.
However, it should be noted that whenever a fix is doable, you should have it. Unless a website is a JavaScript based app, it should be working without JavaScript, note that working != working perfectly.
if you have a hover state with a cool transition, which Chrome 23423 will support, but IE7 won't, then you can either emulate it using Modernizr and jQuery, or leave it as is, and IE7 won't enjoy the goodness. BooHoo.
You must however, give older browser users a message to encourage them to upgrade to a better ones, especially talking about IE<=7.
You built the website in the wrong direction.
If you want to support older versions, instead of building a cutting edge website and then trying to get it to work in older browsers, you need to build a basic site that works everywhere, then use advanced CSS and Javascript feature detection to add features for the newest browsers.
I am writing a complex tab based web application where each tab is unrelated to each other in the sense that there is no interaction. So for ease of development i want I want each tab to be a separate html page viewable on its own and at later stage I can assemble them via tabs or may be menus or trees
so question or questions are:
I am planning to use iframes, does all major browser support them?
Are iframes going to be deprecated, so what are alternatives e.g. is object tag supported by all major browsers?
May be i can use some better strategy instead of iframe/object?
But what I love about iframes is that it can be totally modular, so each page doesn't know about other.
Note: i selected the answer which explain well but still i am not sure why not iframes
question iframes vs ajax may answer that.
Yes, all major desktop browsers support iframes. So do many mobile browsers, including IEMobile, Opera Mobile, and Safari on the iPhone. The only major browser I know of that doesn't support iframes is the BlackBerry Browser.
The object tag is supported by most browsers, but the implementation is extremely inconsistent across the various browsers.
What's wrong with just having a flat page with an ordinary navigation menu? If you are only displaying one page at a time, and the only interface element being placed outside of the iframe is a tab menu, then why not just integrate the tabs into the page layout and do away with the frames?
Frames of any sort tend to break the familiar browser behaviors that people are used--like the forward and back navigation buttons. And they completely disable the use of bookmarks. When building a website, you should try not to restrict or dictate to visitors how they're allowed to browse your site. If the user wants to open a link a new tab, they should not be left without a navigation menu. If they make their browser window a particular size, the page content should fill that area, not a predetermined area specified by the dimensions of the iframe.
Frames are inherently user-unfriendly, which, unsurprisingly, makes them search-engine-unfriendly; which is why so few professional websites use frames/iframes. Cheap broadband is widespread enough these days that reloading a few extra kilobytes of navigational data makes no difference to the overall user experience.
If I were you, I would use jQuery UI Tabs instead of my own solution.
it looks like your website is not static, so i don't see why you're doing it with bare HTML.
I'd use ASP.NET and CustomUserControl as each of your tabs, that they all the tab would be truly independent and you can reuse them anywhere in your application
For the separate pages in each tab, you can as well use server includes.
To answer your first 2 questions:
iframe is supported across all the latest web browsers however i am not sure about mobile browsers. Opera mobile yes, dont now about iPhone.
the next major iteration of html is being led by WHATWG and the iFrame will be supported. It is also supported in xhtml
As far as different approaches, that very much depends on what you are going to be doing with the tabs. if each tab is going to have a lot of information on it or take a while to load then separate iFrames is probably best. Also, if you are going to reuse the code as independent pages else where then iFrames are also a good option.