I'm trying to make a page that shows how to enable JavaScript in various browsers.
The users that view the page will not have JavaScript enabled, so I can't use JavaScript to detect the browser.
How can I detect the browser without using JavaScript, PHP or ASP.NET?
The idea I have in my head is that the page will show the appropriate instructions to enable JavaScript in the user's browsers with pictures and text.
Sorry for the bad english.
Thanks!
EDIT: Is it a bad idea to use conditional comments? Why not?
You can't. You need something on the back end to read the user agent.
AFAIK, there's no way, except asking the user:
If you're using Internet Explorer (nice image of the IE logo): click here;
If you're using Firefox (nice image of the Firefox logo): click here;
Your question doesn't leave much room for providing an answer, but I'll give it a shot:
You can use a <noscript> block to provide page content which will only be visible when JavaScript is disabled.
Alternately, you can also use a JavaScript onLoad method to remove an ordinary <div> or similar element from the page when JavaScript is enabled.
The <noscript> element is generally preferred, as it will simply not appear on the page if JavaScript is already enabled.
As far as detecting which browser they're using, you need some technology on the back-end which is capable of parsing the request headers that the browser sends. This can technically be done by the web server itself using server-side include and some clever rewrite rules, but it is actually harder that way than to just learn to use a server-side scripting language.
If you're doing this for a reason (i.e., you're using an embedded webserver with little to no free space), your best option if you only want to provide a static page (in other words, just an HTML file) is to have the page content include a <noscript> block at the top, and an invisible block at the bottom (<div> with hidden), then enable the hidden div on page load via JavaScript.
Include two or three blocks with <a> anchor tags which explain how to enable JavaScript in EACH browser, and have the user click the logo that looks more familiar (all inside your <noscript> block).
That being said, server-side scripting is easy to use, easy to set up, and completely worth learning. It's quite a bit easier and more predictable than doing everything with JavaScript.
I really want a way to have one single file for, for example, the navigation bar and the footer so that I don't have to go through all of my pages (only 20 or so, but anyway...) to update it. So I've realized that frames (iframes? What's the difference) can help me with this.
Additionally, I've heard a lot of places that frames are a no-go in web design for some reason. Is this to do with SEO?
Can I use (i)frames safely? Are there alternatives that keep the url http://www.domain.tld/pagename.html ?
Whatever you do, don't use frames/iframes for page layout.
Your best bet is to use a server-side scripting language to build your page. That way, you can have the individual components in separate files (which makes maintenance easy) and then compose them using the scripting language.
So I've realized that frames (iframes? What's the difference)
An iframe embeds a document in the middle of a page.
A frame is part of a frameset, which consists of an entire page.
can help me with this.
They could, but have plenty of drawbacks (mucking up linking, printing, causing scrolling issues, etc). Use an include (e.g. php or ssi) or template system (e.g. template toolkit's ttree) instead.
Adding to these two good answers, from the SEO point of view a frame based site is also might be a bad idea.
Google supports frames and iframes to
the extent that it can. Frames can
cause problems for search engines
because they don't correspond to the
conceptual model of the web. In this
model, one page displays only one URL.
Pages that use frames or iframes
display several URLs (one for each
frame) within a single page. Google
tries to associate framed content with
the page containing the frames, but we
don't guarantee that we will.
See this
As a side note, have yo considered 301 redirect? It is not precisely keeping the same address, rather the opposite but it might be what you want if I understood your concern.
Do iframes still fit the mold of current web standards? The technology is old but I am seeing them resurface - especially with the new youtube embed code being iframes and facebook just allowing custom tabs to be iframes as well.
My question is basically: Are the acceptable?
Have a look at this SO question: Are IFrames (HTML) obsolete?
In short: They are part of the HTML 5 draft and will be sticking around. If used correctly, I think they are acceptable. :)
I agree with everyone that they should be a last resort, but there are certain things that demand the use of iframes.
For instance, there's no better way to do ajax file uploading than posting to an iframe and then reacting to the iframe's onload event to handle it.
Yes, my company still uses iFrames to embed third-party content on our site.
They still have a place but, IMHO, should be a last resort.
A lot of components such as Facebook's social widgets or Youtube's embeded player use iframes.
I also use some, when needed. Of course I don't abuse it because it's not adapted for all situations.
Is there a way of including HTML pages without needing any javascript or server-side code, only HTML.
Basically I can't be sure if the server supports server side includes. I don't want to use javascript and I don't want to use any PHP or other server side functionality.
Is there any way to do this. At the moment I suspect not, but would be very interested if it were possible.
Use some frames in your page
HTML frames allow authors to present
documents in multiple views, which may
be independent windows or subwindows.
<iframe></iframe> is the tag you need to include inline floating frames.
Quick tip with iframes: Be sure you open and close the tag explicitly, if not some browsers will complain
You can use framesets.
HTML imports, part of HTML Components, aims to do exactly this.
HTML5rocks offers a great tutorial to get started with HTML imports.
According to can I use, only Chrome is supporting HTML imports today.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Getting contradictory messages about that, hope they're not.
I cannot imagine support for it would stop, since a gazillion sites use them.
Some additional questions about that:
Why should they phase out this tag?
Any alternative for it?
Support for <iframe> is still there in HTML 5, so I don't think this will change in the near future.
To answer your other questions:
<iframe>s (as frames in general) are most of the time not user-friendly:
They don't allow easy access of the content in the frame via an URL (without losing the content outside of the frame at least).
Most "technophobe" users are irritated by frames.
As far as I know they are slower to render for browsers
Alternatives include dynamic page generation (SSI, PHP, Rails and so on) and using JavaScript / AJAX to change contents of e.g. a <div>
To be clear: I'm talking about <iframe> as an interface element. Not a hidden element for loading other stuff like e.g. Google Mail does.
In my opinion the W3C jumped the gun in dumping iframes from the Strict HTML and XHTML doctypes. In theory you would use the <object> element to add foreign objects to your document, but browser differences and limitations have made this a nonstarter for many developers. With the much-more-pragmatic HTML 5 (which is still a draft), iframes are back and even have two new attributes: seamless, and the intriguing sandbox.
IFrames are not obsolete, but the reasons for using them are rare.
Using IFrames to serve your own content creates a "wall" around accessing the content in that area.
For crawlers like Google, It's not immediately clear that cotent in an iframe will be ranked as highly as if the content were simply part of the page. For many, this is reason enough not to use it.
It makes the DOM for the IFrame less accessible by tools like jQuery, prototype etc..
Reasons for using iframes:
It's great for walling off other people's stuff from other domains but it doesn't integrate smoothly. (stylesheets, javascript etc...)
Integrating multimedia can sometimes be done easier via an iframe as opposed to using the embed tag.
Really, really specialized cases like gmail's case where they are using it for sounds and history management.
I would also answer that there is no need for the removal of iframes, it's a needed tag and will be around for a while.
Iframes are obsolete for page layout. Never use them instead of good CSS layout, even table-based layout is better.
Good reasons for using iframes are:
ads: adwords for example uses this technique, it is good for encapsulating - ad css won't destroy your page.
hidden iframe: it can be used for hundreds usable things, like tracking, ajax-alternative, etc.
I've seen lots of forums that suggest the Object tag as a replacement for IFrame, which probably works in most cases.
For example, I had a PDF showing in an IFrame (because there were other things we need to show on the page besides only the PDF) and was able to get it to display fine using Object.
What was:
<iframe id="confirmed_pdf" class="current_pdf" src="/prescriptions/show_pdf?id=123" height="570" width="480"></iframe>
Became:
<object id="confirmed_pdf" class="current_pdf" data="/prescriptions/show_pdf?id=123" type="application/pdf" height="570" width="480">
<p>[Show this message if displaying the PDF did not work]</p>
</object>
But Object was not a suitable replacement to fill the requirement to be able to print ONLY the PDF portion of the page.
An IFrame is like its own window within the page (a window within a window, basically), and once you get the window object, you can call .print() on it, like:
jQuery("#confirmed_pdf").contentWindow.print();
IFrame has a contentWindow property, that's what makes printing only that part possible. Object does not have a contentWindow property, so there's no way to print only the section of the page.
So, it seems like if you're just using IFrame to display something, there's other tags like Object that can be used instead. But if you need to interact with the contents of the IFrame in certain ways, then IFrame may be necessary.
IFrames are used a lot with AJAX. GMail for example, uses nine hidden IFrames I believe.
IFrames are not dead, but Frameset/Frames are dying.
In the last 2 releases of IE (IE7/IE8) zooming in Frames (not IFrames) has created disastrous results.
By all means use IFrames, but IMHO stay clear of Framesets/Frames.
At my previous company, we provided a hosted application that customers would integrate into their own websites. At times, they would use an IFrame to do this, fitting our hosted page into their existing designs. Sometimes this was even done seamlessly (ie. the IFrame had no borders or scrollbars, it just looked like part of the page). I considered this to be a good use of the tag.
They can be extremely useful in some circumstances, but those are limited. In particular embedding common functionality across multiple sites.
For example I have a client who runs a number of Scottish goods e-commerce sites. As part of this we have developed a couple of simple applications to locate possible clan names from your surname or your choice of tartans (giggle if you wish but tartans are worth $700 million a year to our economy). The database behind this is surprisingly large (nearly ten thousand rows in the core names and tartans tables) and fairly regularly updated.
So we have the applications set up to run on one website and then embedded these into our other websites using an iframe, enabling simple javascript parameter passing so we can integrate the selection of a tartan or clan with functionality on the embedding site. The iframe is set as noborder so it appears completely seamless to the end user.
Of course there would be other ways of doing this, but the use of an iframe is simple and robust. And it's certainly not obsolete.
Horses for courses... <iframe>s are like anything else... for the right purpose they're the right tool; for the wrong purpose they're an ugly hack, or worse.
In Ajax, <div>s are often the more appropriate container. In some places the activity of passing-off external content as part of your own site, as supported by <iframe>s, is inappropriate.
My team used an <iframe> the other day as an ideal way to give users access to their HTML e-mail history - the e-mails were complete <html> pages which we wanted to insert easily into our web template. <iframe>s were absolutely perfect for presenting that data]'.
On the other hand, <iframe>s should almost always be removed or disabled in any user-submitted content which is output back onto the site, because in that context they are a major security issue.
The google gadget specification currently relies on iframes: http://code.google.com/apis/gadgets/docs/spec.html
Currently they are the only simple way to provide isolation for javascript apps that are pulled from multiple domains/providers.
Also many of the widgets that people embed on their websites from third-parties use iframes.
While they do have their drawbacks, iframes provide a pragmatic solution to common problems on the web. I'd have to guess that they will be around for some time to come.
Compliance and Security issues can also drive you to use Iframes; Shopping carts are popular IFrame-based implementations when you want to visually incorporate a shopping cart as part of some web pages without taking on full responsibility for the payment processing side of things.
We commonly deliver an Iframe to integrate our eCommerce stuff and clients like how turnkey it can be.
I work for a company that used frames for everything from pull down menus, lists, content blocks, etc just to cover the intricacies of .net web forms. The application is very slow and only runs on IE. Don't do this.