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.
Related
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.
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'm developing the CSS file for the mobile version of the website my group are working on for our web design coursework, and I was wondering if it was possible to design a site for touch based browsers using the currently ratified specification of HTML and CSS, as the other member are doing for the desktop variant, or am I going to have to use the draft specification of the new language. I'm not intending to use anything too elaborate, I'm only attempting to allow the user to navigate the site with their finger, and the current implementation allows me to activate a dropdown menu on the desktop, but when I try to navigate on my Android handset, nothing happens.
The menu button gets illuminated in the way that all links in my browser do when they get pressed, but nothing happens. The research I've done since this revelation has led me to the conclusion that I'm going to have to experiment with the new spec, though since this is coursework, I'd rather stick with current standards than experimental drafts of new ones.
P.S. I'm only developing an informative site, not an application.
Yes, you can use older versions of HTML. iPhone, Palm OS, Android, and recent versions of the Blackberry OS all use Webkit, which is the same rendering engine that Chrome and Safari use.
In fact, the very first page on the World Wide Web will work just fine.
We'd need to see your code for your navigation bar to troubleshoot, but it's probably something along the lines of using a hover event to display the navigation (touchscreens can't have a hover event).
I can browse to any site on my iphone using the touchscreen. The language is not the problem. Most mobile browsers on smartphones can handle html(4)/css(2) fine. You should be more worried how to show the content so it will be easy to navigate on the site using a (small) touchscreen. Usability testing is your friend here. Browsing a website made for desktop can be very frustrating (not impossible) on a small touch screen.
Also the size of images and stuff shouldn't be to big. Since loading those can be a pain. At least the t-mobile(Netherlands) g3 network is slow, if available at all.
Note that the 'currently ratified' version of CSS is CSS1 (from 1996), CSS2.1 isn't yet a W3C Recommendation. So from that point of view the standards your other members are using for the desktop variants are not much more ratified than HTML5 and CSS3.
For sure do it! just ensure links are larger for fingers. Also allow the site to resize.
Most mobile sites are HTML1.0.
You would be silly using html5 + css3 unless you knew that it was only going to be used on an iphone eg. webapps.
And don't forget you can still use JavaScript!
Go For It!
I want to generate a thumbnail of a web page in the browser, so I can have multiple scaled down iFrames within a single page.
IE can do this using filters. Mozilla can do this inside a <canvas> with drawWindow() if you have Chrome privileges (like an installed plug-in).
Is there any way to do this in WebKit? Is there any generic cross browser way to do it?
I know you're looking for a client-side way to do this, but considering the spotty support across the board you may want to look into generating the thumbnails on the server.
khtml2png allows you to generate webpage images from the command line. It's not the prettiest solution, but with a little scripting it would allow you to generate thumbnails on the fly, and you wouldn't have to worry about browser compatibility.
WebKit's nightly build (41944 from March 24 2009) has support for transforming elements (including scaling) as well as other goodies like CSS gradients.
There is more information on the WebKit blog and here.
I'm guessing this features are also available in Safari 4 but I haven't checked.
edit: It looks like this is also making its way into Mozilla as -moz-transform.