This web site is frame-free. Frames are often used to display the same
header, footer and menu for every page, but you do not need frames to accomplish
that.
This site shows the same header, footer and menu on every page without using
frames.
It is done with a template; All the pages are built from the same
template. If I want to change the content of the header, footer or menu, I only
need to change the template and update all the pages.
So, this was a frames-free site, created using a frames-free standard, being served inside a frame. That's ironic.
Frame forwarding is cheap and simple, but it is far from perfect. Truth be told, frames should never have made it into any web standard.
This particular site is built using XHTML 1.1, the strictest web
standard there currently is. While XHTML 1.0 still supports frames for backward
compatibility with old website designs, the XHTML 1.1 standard does not even
include frames.
So, this was a frames-free site, created using a frames-free standard, being
served inside a frame. That's ironic.
Using two hosts means having two points of failure.
An often overlooked problem with frame forwarding is that your site now has two hosts. In my case, the frame page was hosted by BulkRegister (now eNom), and the pages were hosted by XS4All. Using two hosts means having two points of failure.
During the years that the site used this set-up, it wasn't XS4All that failed to serve pages, it was eNom that failed to provide the frame forwarding. I have noticed the service being down more than once, and it probably was down another dozen times for every time I noticed. I have received several emails from visitors that site was down, or seemed flaky.
I was not impressed by eNom's frame forwarding service itself, and their response to server outages did not impress me either. The few times that I noticed it and contacted them about it, it often took them more than half an hour to restart their remarkably unreliable frame forwarding server.
I dare state categorically that eNom's frame forwarding service sucks. It costs just one dollar a year extra, but they should really be paying me to compensate for how unreliable their frame forwarding service is, and how poorly they respond to server outages.
Based on my own experience with eNom, I heartily discommend them. That's not only because of their craptacular service, it also because they do not even understand HTML.
I heartily discommend eNom. I will be taking my business elsewhere.
I take care to craft correct web pages. To be best of my knowledge, every page on this sites validates - to XHTML 1.1, the strictest web mark-up standard there currently is. In sharp contrast, the simple page eNom uses for page forwarding literally contains more errors than it has lines! Right now, the latest version of Marc Gueury's HTML Validator (version 0.8.5.9) reports 13 errors for a page 11 lines long, and one of these lines is blank.
Over the past few years, I've raised this issue with them more than once.
The so-called support crew at eNom does not seem to understand what HTML is or why
valid HTML matters. Their response is essentially we don't understand
and we
don't know how to fix it
, and then they bluntly hurry to close the
reported incident as solved
. I have
repeatedly pointed out that the issue had not been solved at all, after which they
once again did not nothing to solve it. The inevitable conclusion is that they
simply do not care about the quality of their service.
I heartily
discommend eNom. I will be taking my business elsewhere.
Back in the 1990s, when frames were introduced, it was done in such a way
that pre-frames browsers would not be confused. Those early browsers do not recognise
the frame tag, and they do not recognise the noframes tag either, but they do display
the content within the noframes section - while a frames-aware
browser will not.
Back then, the web crawlers used by search engines did not recognise frames
either, and would only see the noframes section. Those days are long gone. Most
web crawlers do recognise frames and do follow the links to the actual pages.
Besides, the frame forwarding page also links to the actual page within the
noframes section.
That's what you want, but not want you want; you do want the crawler to follow the link, but you do not want it to use the long cryptic URL. You want it to use the permalinks, to use the domain name you show to visitors.
Search engines prefer to show just one URL and to show the actual URL. So, it were the long, cryptic URLs, not the permalinks, that found their way into the Google index. Thus, visitors arriving from Google would be following the hard link, and perhaps even bookmark the hard link, not the permalink.
In 2009, Google, Yahoo! and Microsoft introduced the canonical
link element to let webmasters specify which URL should appear in the index.
That may sound like a solution, but it isn't. It, quite rightly, does not
let you specify a completely different domain. The canonical
link elements was created to resolve cases where multiple URLs on the same site
lead to the same content, it was not designed with frame forwarding in mind.
So, while I was using frame-forwarding to present a user-friendly and easy to
remember domain name, Google was undermining my efforts to use permalinks by
showing hard links to the XS4All web space instead.
That isn't the end of the world, but it is annoying. People would follow those
links to my site, which is great, but they also linked to my site using these
hard links, which isn't so great.
I had considered the possibility that people would arrive through a hard link. The site itself uses full URL for all internal links. So, once visitors on my site followed any other link, they'd be using a permalink. Well, that was the idea.
The idea behind using full URLs was that you'd not only get to see the right page, but that the address bar would change as well; from displaying a hard to displaying the permalink. Thus, if you, after some browsing around, decided to bookmark or link to the page, you would bookmark or link to the permalink.
However, some years ago, the behaviour of most web browser changed. Web browsers do no longer always show the URL you followed. If you right-clicked on a permalink, the address bar will still show the permalink, but if you simply click, the address bar remains unchanged! I personally consider the fact that clicking a link does not show the same URL as right-clicking that links to be a serious user interface mistake, but that is how it is nowadays.
The practical result of this change was that web site visitors, who followed a permalink, browsed around a bit, and then bookmarked a page, ended up bookmarking the page they started with instead of the page they were on.
Google's preference for hard links was a problem, but Google Alerts provided a solution. I took advantage of free Google Alerts to be notified of links to my site.
If I noticed anyone using a hard link, I mailed them to request that they use the permalink instead. That not only is a bit of a hassle to do every time it happens, it also is a partial solution. Google Alert does not alert you to every use of your search phrase. Moreover, people sometimes used a hard link on a platform such as a bulletin board that does not allow them to edit their post later.
The bottom line is that although I tried to make sure that everyone used permalinks, so that I could one day move the site without breaking their links, there still are some hard links to the old location out there. The final part of this article series deals with that issue.
Internet Explorer 9 is Microsoft Web Browser 1.0.
Intranet Explorer 8 isn't a web browser. However, after more than ten years of deliberately refusing to support web standards in their intranet browser, Microsoft finally decided to release a web browser; Internet Explorer 9, currently in Beta, is a true web browser. It supports web standards and supports them fairly well.
Older version of Internet Explorer do not support web standards, and therefore fail to display this site. Internet Explorer 9 does support web standard and can display this site. Internet Explorer 9 is Microsoft Web Browser 1.0.
The screenshot in the Internet Explorer 9 Beta article shows that the Beta worked. It displayed square corners instead of rounded ones, but that isn't a big issue. On 2011 February 10, Microsoft released the Release Candidate, and it displayed nothing but a white page. That is a big issue.
The problem isn't that Internet Explorer 9 RC cannot display the site. The problem is that Internet Explorer's frame handling is broken. One issue with using frames is that the framing page and the framed page need not be using the same HTML or XHTML version. In this case, the framing page was not even HTML 2.0, but merely some messy, low quality tag soup, while the framed page was valid XHTML 1.1. Every major web browser just deals with that, but the Internet Explorer 9 Release Candidate does not. This is a serious defect of Internet Explorer 9.
Now, the way in which Internet Explorer fails is such that if eNom had fixed
their broken frame forwarding service by replacing it with valid HTML, Internet
Explorer 9 would have displayed the site just fine.
And finally, if I had not decided to use frame forwarding, the site would not
suffer from either Internet's Explorer's limitations or eNom's bad HTML.
Three mistakes combined to not display the site; Internet Explorer 9's broken frame handling, eNom's low quality frame forwarding service, and my decision to use frame forwarding in the first place. Only one of those mistakes was directly under my control.
The decision to use frame forwarding was a mistake. It created a variety problems that would not exist if I had spend some money on proper hosting. The problem with the Internet Explorer 9 Release Candidate, which could display the site, but didn't because of the frame, was the final straw for me. I want visitors to be free to use any web browser they like, and Internet Explorer version 9 is a web browser. Sure, its frame handling is broken, but then again, I really should not be using frames. I decided to switch to proper web hosting.
Copyright © Tamura Jones. All Rights reserved.