Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm modifying a browser (Chrome or Firefox) to work in the Sahara desert - or any environment with very poor connectivity. I can configure the browser, recompile it, or even insert a custom coded proxy. The goal is to make it operate well with spotty, slow connectivity.
I've found the biggest problem to be that even when you get the main page, the browser will often hang, waiting for the CSS and JS etc to load. How can I force the browser to "Render the page right away, don't worry about other resources?"
The page isn't waiting for the resources to render, browsers generally always render HTML as soon as they have it available. However, the CSS and JS files are likely being sent before the generic HTML for the page, as web designers don't generally like their page to go through multi-step formatting processes while the CSS page loads in, nor do most users. You're likely getting almost none of the HTML until after the CSS or JS loads. Presumably, if you have full control of the browser's functionality, you may be able to tell it to skip these or save the address to load in later? I wouldn't recommend this behavior though, as it could break a lot of functionality, especially with JS.
If images are missing, they should show the alt text. If they're loading, they may not. Again, with full control of the browser, I don't see why this should be a problem for you.
There is no 'generic' CSS. CSS rules are largely customized based on classes and identities defined by the author. More modern webpages which make use of newer HTML5 elements have more semantic information available to guide display without a stylesheet. Short of this, you need the accompanying stylesheet for proper display. You could attempt to guess or reengineer, but the vast majority of the time this will fail, as there was little to no convention prior to HTML5 bringing in more semantic elements.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I use a website that recently changed its layout, which I (and a lot of other people) extremely dislike. I checked over the changes, and I believe that most of the changes involve a simple css change.
I own a domain that I would like to display the contents of this website, but with my own css, however I am unfamiliar with the web. I am open to all solutions that would do this (embedding, reflecting, etc.) I would like to do this without paying money.
*Note: the reason I am avoiding using a userstyle is because I would like to be able to access this website on any computer, anywhere, anytime, and let others do the same.
The website in question is http://www.scarsdaleschools.org/, and I would like it to look like this.
I know there might be some conflicts with the using the old css on the current website, it is okay as long as it is usable.
I will give an additional 50 point bounty if the solution does not involve me hosting my own website.
Clarification: I am not looking to create a mirror for the website, I would like a client to access scarsdaleschools.org directly, only replace all css documents with my own css, thus all content is accessed directly from scarsdaleschools.org.
EDIT: This was put on hold as too broad. I am looking for a method by which I can accomplish what I am trying to do.
According to the help center:
There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow down the answer set or to isolate an issue that can be answered in a few paragraphs.
Chances are, there is probably only one way (or a small few ways) that can answer my question. Regardless, my question does not require a few paragraphs, but just a simple name of a technique (and hopefully a small explanation of how I would use this technique).
Well if you don't mind having to put some insane amounts of !important in your CSS for it, the iframe tag is actually powerful enough to do it (doesn't even need the proposed-then-cancelled seamless attribute).
I'd still suggest using something like a portable browser on a flashdrive/CD, and having your userstyles installed on that, instead, as it's a little less red-flag-inducing (your site may be flagged as a potential attack site w/ the iframe trick). Added bonuses, it dodges corpsec spyware and update restrictions, and has all your bookmarks/addons.
But simply iframeing the website from your own with your stylesheet (loaded with !importants) will suffice, so long as you can get around any framekiller they use (if any).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
In a fully working website, with the looks and functions working just the way a client wants BUT loaded with tons of illegal HTML...what are the adverse effects of those illegal HTML?
My question might seem a bit simple, but I am trying to look beyond the obvious...Nowadays, web browsers ignore (or correct) illegal HTML. Is there a SEO penalty, or some other kind of problems besides slower loading time?
Aside slower loading time, making fixes on such page by another developer/designer might take unnecessary long time for such person to understand the flow.
Also, come to think of a situation when you jQuery to 'backdoor' pick-up (or inject) some elements on (or into) your page, this can also lead to BIG bug.
There is no harm in proper planning of tag usuage and lots.
super!
A big reason is to help you be sure that it will render correctly in different browsers and be understood correctly by other html readers, such as web crawlers.
Whilst HTML5 has increased specification for standardized error handling, that is still not going to guarantee that it will appear exactly the same to every browser, and there are increasingly too many browsers to test them all.
Also, good code is not just about validation but about semantic markup. Letting search engines know what your content is by the correct use of markup can only help your site be understood correctly by the search engines, which is what SEO should be.
Browsers will, as always, try to correct badly written HTML. The problem is that different browsers will "correct" the markup in different ways. Some may get it right, while others will fail in more or less subtle ways. Badly written HTML (and also CSS and Javascript) may result in:
important content disappearing from the page,
overlapping or unreadable content,
forms that cannot be submitted,
missing form elements,
dead links and buttons,
the author looking like an ass.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
My girlfriend is making a website for her exam.
She is not good at HTML - at all! (Me neither). But for making it easy for her, I told her to use frames. It's easy and manageable.
But the problem is that the website have to live up to the standard HMTL5. That's a requirement. I don't think frames does that because it's deprecated. Am I right or wrong?
So.. What to do? It has to be as simple as possible. I don't think the other solutions I could find are something she can do herself :( Any ideas?
(Sorry, if my english sucks :) )
You should definitely try not to use deprecated elements. They will behave inconsistently, and probably won't work in the future. There's also a very good reason why frames are deprecated.
You probably need to rethink how you're structuring your data. An HTML page should be as simple and to-the-point as possible. If you have to pull in a significant amount of content from other web-pages using frames, you're doing it wrong. In most cases it's better to simply link to the extra content.
If you're trying to use frames to pull in the <header> or the <nav>, so you don't have to simply copy them across multiple pages, although I applaud you for trying to be DRY, this is the wrong way to do it. Just copying these sections into all your documents is a better solution than using frames.
Ideally though, you'd use a server-side templating system of some sort. The simplest one (depending on your setup) may be Server-Side Includes.
Having said all that, if you really need frames, the <iframe> element is perfectly valid in HTML5 and may help you out.
Don't use frames, very old and not needed at all
Make sure all your style stuff is made in CSS and it's loaded through a CSS file.
Then make each html page with the information needed in it. Use links for navigation to another page.
With the external CSS you can change the look of your site in one file (the CSS file), and it will automatic update for each html page.
You are correct in assuming that frames do not conform to the HTML5 draft (to the extent that it makes sense to speak of conformance to a draft). HTML5 is not a standard, though it may one day become W3C Recommendation. It does not use the term “deprecated” but “obsolete” and “non-conforming”, but in any case, frameset and frame elements do not conform.
The iframe element (“inline frame”) conforms, however. Using it instead of “normal” (old-style) frames is clumsy and limited, but possible to some extent.
I think this answers the specific, on-topic questions asked. The rest is mainly opinion-based and hence off-topic at SO.
P.S. If “living up the the standard HTML5” is a requirement, then the teachers would need a crash course on the basics of HTML5 process. The requirement means that a page that is “standard HTML5” in the morning may become non-conforming before lunch. After all, HTML5 is a draft that may change at any moment without prior notice, and it says itself: “It is inappropriate to cite this document as other than work in progress.”
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I haven't used frames since 1998. They seem like a bad idea and in all my development I've never had a situation where frames were the right solution, or even a decent solution.
However, I'm now working with an internal web application written by another group and the entire site is built in a - header, left side menu, right side content - frameset.
For one, when VPN'd to my network I constantly get a "website.com/frames.html" cannot be found." error message. This doesn't happen when I'm on the internal network.
Second, the app has a built in email/messaging system. The number of unread messages is shown in the left side menu frame as "Messages (3)" but the count doesn't update as I read the messages. The developer told me since it was in a frame I needed to right click on the menu and 'Refresh'. Seriously????
So, my programming related question is, what reasons do you have for not using frames in a website?
Although they solved a problem at the time they were created (updating part of a "page" while keeping in place a non-updating part), framesets were criticised in terms of usability pretty much from the start, as they break generic functions of the browser, such as:
bookmarking, and copy-and-pasting URLs to share
printing the page as displayed on the screen
reloading the page: since the URL has generally not changed, you will often be taken back to the site's homepage or default frameset; manually reloading some frames is possible, but not obvious to the user
back and forward buttons are ambiguous: undo/redo the last frame change, or take you to the last time the URL bar changed?
The heaviest burden of avoiding framesets - including the same content on every page - is trivial to solve if you are using any server-side language to generate your HTML, even if all it provides is a "server side include". Unlike framesets, a server-side include could occur anywhere on the page; building a site with a server-side scripting language or templating system has other obvious advantages too.
There is still an advantage to being able to update small areas of the page without reloading the entire content, which can be achieved via AJAX. This sometimes leads people to create interfaces with all the problems of framesets outlined above, but that is hardly an argument in favour of framesets. Again, a site built with well-designed AJAX functionality can achieve things which framesets don't even begin to address.
One good reason to avoid frames today is they have been deprecated in HTML 5: Chapter 11 Obsolete features
11.2 Non-conforming features
Elements in the following list are entirely obsolete, and must not be
used by authors:
[...]
frame
frameset
noframes
Either use iframe and CSS instead, or use server-side includes to
generate complete pages with the various invariant parts merged in.
The #1 reason? Users hate them.
Even if they offered advantages in other areas (separation of code, application design, speed etc) they are part of the user interface. If users don't approve, don't use them.
Frames were vaguely useful when you had a static web site, to avoid repeating navigation menu in all pages, for example. It also reduced the overall size of a page.
Both these arguments are obsolete now: sites don't hesitate to serve fat pages, and most of them are dynamically built so including such navigational parts (or status, etc.) has no problem.
The "why" part is well answered above, partly by your own question (you hit a limitation, although it can be overridden with a bit of JS).
My number 1 reason not to use frames is because they break the bookmark (aka favorite) feature of browsers.
With the technology that exists today, frames have become obsolete. But if your legacy project still uses them, you can make the messages update with some ajax.
Just because of the cell phone iPad craze doesn't mean that highly functional full featured sites are suddenly "obsolete", and those who decided to make framesets obsolete seem to be the same complainers who never figured out their full potential in the first place, or maybe they're the lobbyists of the mega-corporate cell-phone and tablet makers who couldn't be bothered to make a decent frames capable browser for their itty-bitty screens.
Admittedly, iFrames can handle simple jobs like scrolling and/or displaying independent segments within a single page pretty well, and I use them for that inside my own frames based website, but to get them to work as well as the foundation for a site itself is a nightmare. Trust me, I know because my website is one of the most sophisticated frameset based sites on the Internet and I've been looking at the pros and cons of transposing it all to iFrames. Nightmare is an understatement.
I can already hear the whiners saying, "Well why did you build it that way in the first place then?" ... and the answer is A: Because I'm not lazy. and B: Because a frames based site is the most functional, visually appealing, and user friendly format for an information based site with hundreds of pages of content that doesn't have to rely on a server. By that I mean all but the external advertising can be viewed straight off a flash drive. No MySQL or PHP needed.
Here's some of the issues I've encountered:
The objection to orphaned pages can be easily handled with JavaScript.
The objection regarding bookmarking is irrelevant unless you use no frames all.
Content specific bookmarking can be handled with an "Add Bookmark" JavaScript function
The objection regarding SEO is easily handled by an XML sitemap and JavaScript.
Laying out dynamically sized frames is far easier and more dependable with standard framesets.
Targeting and replacing nested framesets from an external frame is easier with standard framesets.
In-house scripts like JavaScript searches and non-server dependent shopping carts that are too complex for cookies don't seem possible with iFrames, or if they are, it's way more hassle to get them working than using standard frames.
All that being said, I like the single page appeal of iFrames, and when they can actually do all the same stuff for my site as easily as standard frames does now, then I'll migrate. In the meantime, this nonsense about them being "obsolete" is as irksome as the other so-called "upgrades" they've foisted on us over the years without thinking it all the way through.
So what does all this boil down to for the question of whether or not to use framesets? The answer is that it all depends on what you want your site to do and on what platform it will mostly be viewed on. At some point it becomes impractical to make a multi-page site work well without some frames or iFrame integration. However if you're just creating a basic profile page that displays well on a cell phone or tablet, don't bother with framesets.
They almost always make people angry. What more do you need?
Frames are really useful in some occasions. If you are creating a local webpage that serves only for reading, no interactivity involved and the website will not be public on the internet, all the reasons on not to use frames are removed. For example a user manual for an application that is developed solely in html, frames are really useful in keeping a table of contents on the left in a simple and easy to code way. Also if you have proper navigation within the website then the back button ambiguity is removed completely
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
The community reviewed whether to reopen this question 6 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
Somewhere along the line I picked up the notion that using iframes is 'bad practice'.
Is this true? What are the pros/cons of using them?
As with all technologies, it has its ups and downs. If you are using an iframe to get around a properly developed site, then of course it is bad practice. However sometimes an iframe is acceptable.
One of the main problems with an iframe has to do with bookmarks and navigation. If you are using it to simply embed a page inside your content, I think that is fine. That is what an iframe is for.
However I've seen iframes abused as well. It should never be used as an integral part of your site, but as a piece of content within a site.
Usually, if you can do it without an iframe, that is a better option. I'm sure others here may have more information or more specific examples, it all comes down to the problem you are trying to solve.
With that said, if you are limited to HTML and have no access to a backend like PHP or ASP.NET etc, sometimes an iframe is your only option.
They're not bad practice, they're just another tool and they add flexibility.
For use as a standard page element... they're good, because they're a simple and reliable way to separate content onto several pages. Especially for user-generated content, it may be useful to "sandbox" internal pages into an iframe so poor markup doesn't affect the main page. The downside is that if you introduce multiple layers of scrolling (one for the browser, one for the iframe) your users will get frustrated. Like adzm said, you don't want to use an iframe for primary navigation, but think about them as a text/markup equivalent to the way a video or another media file would be embedded.
For scripting background events, the choice is generally between a hidden iframe and XmlHttpRequest to load content for the current page. The difference there is that an iframe generates a page load, so you can move back and forward in browser cache with most browsers. Notice that Google, who uses XmlHttpRequest all over the place, also uses iframes in certain cases to allow a user to move back and forward in browser history.
It's 'bad practice' to use them without understanding their drawbacks. Adzm's post sums them up very well.
On the flipside, gmail makes heavy use of iFrames in the background for some of it's cooler features (like the automatic file upload). If you're aware of the limitations of iFrames I don't believe you should feel any compunction about using them.
Having worked with them in many circumstances, I've really come to think that iframe's are the web programming equivalent of the goto statement. That is, something to be generally avoided. Within a site they can be somewhat useful. However, cross-site, they are almost always a bad idea for anything but the simplest of content.
Consider the possibilities ... if used for parameterized content, they've created an interface. And in a professional site, that interface requires an SLA and version management - which are almost always ignored in rush to get online.
If used for active content - frames that host script - then there are the (different) cross domain script restrictions. Some can be hacked, but rarely consistently. And if your framed content has a need to be interactive, it will struggle to do so beyond the frame.
If used with licensed content, then the participating sites are burdened by the need to move entitlement information out of band between the hosts.
So, although, occaisionally useful within a site, they are rather unsuited to mashups. You're far better looking at real portals and portlets. Worse, they are a darling of every web amateur - many a tech manager has siezed on them as a solution to many problems. In fact, they create more.
Based on my experience a positive side for iframe are when calling third party codes, that may involve calling a javascript that calls a has a Document.write(); command. As you may know, these commands cannot be called asynchronously due to how it is parsed (DOM Parser etc). An example of this is http://sourceforge.net/projects/phpadsnew/ I've made use of iframes to help speed up our site as there were multiple calls to phpadsnews and the site was waiting for the response before proceeding to render different parts of the page. with an iframe I was able to allow the site to render other parts of the page and still call the Document.write() command of phpads asynchronously. Preventing and js locking.
There are definitely uses for iframes folks. How else would you put the weather networks widget on your page? The only other way is to grab their XML and parse it, but then of course you need conditions to throw up the pertenant weather graphics... not really worth it, but way cleaner if you have the time.
The original frameset model (Frameset and Frame-elements) were very bad from a usability standpoint. IFrame vas a later invention which didn't have as many problems as the original frameset model, but it does have its drawback.
If you allow the user to navigate inside the IFrame, then links and bookmarks will not work as expected (because you bookmark the URL of the outer page, but not the URL of the iframe).
It's worth noting that iframes will, regardless of the speed of your users' internet connection or the contents of the iframe, cause a small (0.3s or so) but noticeable slowdown in the speed your page downloads. This is not something you'll see when testing it locally. Actually, this is true for any element added to a page, but iframes seem to be worse.
When your main page loads in HTTP protocol and parts of your page need to work in HTTPS protocol, iFrame can beat jsonp hands down.
Especially, if your dataType is not natively json and needs to be translated on server into json and translated on client back into e.g. complex html.
So nope - iFrame is not evil.
They are not bad, but actually helpful. I had a huge problem some time ago where I had to embed my twitter feed and it just wouldn't let md do it on the same page, so I set it on a different page, and put it in as an iframe.
They are also good because all browsers (and phone browsers) support them. They can not be considered a bad practice, as long as you use them correctly.
I have seen IFRAMEs applied very successfully as an easy way to make dynamic context menus, but the target audience of that web-app was only Internet Explorer users.
I would say that it all depends on your requirements. If you wish to make sure your page works equally well on every browser, avoid IFRAMEs. If you are targeting a narrow and well-known audience (eg. on the local Intranet) and you see a benefit in using IFRAMEs then I would say it's OK to do so.