Browser Information
Browsers
I am a Microsoft Word MVP, not an Internet Explorer one – and, of course, there aren't Microsoft MVPs for
non-Microsoft products such as Firefox. I don't do web pages very well and I am trying to learn as I go. Having
tried a few things that didn't work to my satisfaction, I have decided to put all browser-related notes on a
separate page, here. This will include information about what I believe works, what I believe doesn't work, and
why, when I know why. As a perpetual student I am always happy to receive criticism and suggestions: please
e-mail mee-mail me [link to e-mail the author at mailto:Tony@WordArticles.com].
One thing that is clear is that every browser is different and that no web page can possibly be considered fit for purpose if it doesn't work with, at the very least, all the major ones. I am trying, at the moment, to ensure that my pages work with Internet Explorer versions 6 and 7, Firefox version 2, and Opera version 9. I don't have any other browsers installed, though am happy to try any, and I don't have Mac or *nix environments to test their browsers so am having to hope they're alright.
If you are viewing these pages in IE6, you may see, when you first load them, pictures superimposed on much of the text. If this happens, press F5 to refresh the page and all should be well.
My suspicion is that this is caused by some of the images being on the large side and IE6 not recalculating everything properly when it discovers the size. When a page is first loaded, the browser leaves an arbitrary amount of space for the pictures about which it has no knowledge; when it, then, loads the pictures and finds out their actual size, it should adjust the rest of the page accordingly; it appears that IE6 doesn't do this correctly. When a page is loaded a second time, the pictures are already in the browser's cache and it makes the correct calculation immediately, obviating the need for the later recalculation.
I believe I can solve the problem by explicitly specifying the height of each picture so that the browser doesn't
have to recalculate but I am not inclined to do so. IE8 is in beta as I write this and IE6 is getting old; modern
browsers deal correctly with the situation and the ‘fix’ for IE6 is easy. If you cannot resolve the
problem, or if you think I should deal with it, as always, please e-mail mee-mail me [link to e-mail the author at mailto:Tony@WordArticles.com].
[link to download IE at http://www.microsoft.com/windows/downloads/ie/getitnow.mspx]
This is the ‘biggie’. Whatever I think, or anybody else thinks, Internet Explorer is, by far, the most-used browser. It is also, in some ways, the most forgiving browser, whilst at the same time managing to be the most obstinate one, and, in trying to provide what it thinks people want, it is sometimes lax about application of standards; this does seem, however, to be slowly changing.
As a regular visitor to Microsoft pages, I have been obliged to use IE, and I have been generally happy as a user of version 7. I do look forward to the day that Microsoft's apparent disdain for other browsers changes and I can view their pages in whatever browser I happen to be using at the time, but it doesn't, unfortunately, seem imminent.
As the one pre-loaded on most computers, it has, perhaps, the least technical user base of any browser, and is the one most likely to be out of date. I, therefore, see support for version 6 as necessary in the medium term and it is this that is causing me the most headaches. The display of my pages is more likely to be wrong in IE6 than in almost any other environment.
I have not, at the time of writing, tried the beta of Internet Explorer 8. I am hoping that it won't cause me any significant problems.
[link to download Firefox at http://www.mozilla-europe.org/en/products/firefox/]
The nature of Firefox, the fact that it is open source and constantly being tweaked, and its generally technical user base, mean that it tends to adhere to standards fairly strictly. This should mean that it is the easiest to work with. The trouble I find is that the standards themselves take some understanding and what I think ought to work, often doesn't!
For some years, Firefox was my browser of choice, but since the release of IE version 7 in particular, I have been more fickle. Firefox is a good browser that can easily be enhanced by the many available add-ons; for all that I sometimes feel it is over-hyped and not the leader of the pack it once was.
There may be an option to switch it off — I've never felt need to look — but Firefox updates itself periodically by default. This has two effects that impact on trying to support old versions: firstly, there are many of them, but secondly they are less likely to be ‘in the wild’. I do not maintain old versions and make no attempt to support them.
[link to download Opera at http://my.opera.com/community/download.pl?ref=TonyJollans&p=opera_desktop]
Although I did use Opera for a while, it was never my favourite browser. There was nothing about it that I could quite put my finger on, and nothing actually wrong with it, it just wasn't my favourite. I have re-installed it recently to ensure compatibility but am not overly familiar with it. It has some nice features but I have not yet fallen in love with it and, unfortunately, many sites, including some I visit regularly, don't work at all in it, due to its generally fairly strict imposition of standards.
Opera is, I suppose, a niche browser; nonetheless I think it widely enough used to warrant supporting. It is, in general, the most standards-compliant browser of all, which makes it a good browser to test with, and I am committed to making my pages work properly in it; it would be nice if others were equally committed.
Tell me what they are!Tell me what they are! [link to e-mail the author at mailto:Tony@WordArticles.com] Tell me what you use and what, if
anything, doesn't work in it. I will do my best to correct any shortcomings.
If you are in an environment other than Microsoft Windows, I'll do my best, but I am not, at the time of writing, able to see what you see, or to test what I write.
I am not a designer, and my graphics skills are very limited, so there isn't much to say on this subject.
Especially since the advent of wide screens, I abhor web pages that appear as a single narrow column in a wide
empty space. It's easy to create them that way, of course, but not, in my humble opinion, very professional.
Whilst realising that many people don't want page content flowing to the very edge of the screen, I do try to use
the whole screen. If something is meant to be on the right hand side of my page, I expect it to appear at the right
hand side of the viewer's screen, whatever size and shape that may be. Please tell metell me [link to e-mail the author at mailto:Tony@WordArticles.com] if you think I'm wrong.
I've given my pages a background colour as white can be a bit harsh sometimes, and have generally themed the site
in shades of blue, blue being Word's colour as it were. I am aware of, but not very knowledgeable about,
accessibility issues and have tried to keep a reasonably soft feel with high contrasts. As always, please
tell metell me [link to e-mail the author at mailto:Tony@WordArticles.com] if I have failed, or you have any other problems
with the site.
I have tried to create an organised and tidy site, and I have tried to stick to standards. All my pages are coded
in XHTML strict mode and validated against the W3C standard (see this W3C pagethis W3C page [link to the W3C QA Tools page at http://www.w3.org/QA/Tools/] for more information). I am not a web designer and I have failed to find any really satisfactory way of laying out
the source of a web page; I have tried, however, to keep my code reasonably neat and make it as readable as
possible. My son, who is a web designer, laughs at my efforts and jokes that my code looks like Cobol; he, of
course, is too young to know what good Cobol looks like. In the final analysis, it is for others to judge whether
I have been successful in my aim, and, indeed, whether the aim is worthy.
Recognising that print is a fundamentally different medium from the screen and expecting, given the nature of what I am presenting here, that people may wish to print it out, I have set up a print-specific style sheet so that article content prints out in monochrome text and without the various peripheral graphics. The integral graphics are still in colour and I do intend to provide monochrome versions of them eventually. There is probably more I could do in this area.
I did have an issue with printing <hr> elements from Opera, but I seem to have resolved it. I did, however, spend some time looking at the rendering of these elements, and have tried to document my findings, not least so that I don't forget them.
<hr> (horizontal rule) tags define lines, or rules, across the screen or page; they are the web page equivalent of drawn lines across a page. The W3C standard doesn't have much to say about these lines, except that all their formatting attributes are deprecated and that they should be styled using CSS attributes.
The W3C standard is, however, reasonably clear on two important aspects of the CSS: background colour and height. Background applies to all elements: the standard describes it as the rendering surface and goes on to say that it refers to the background of the content, padding and border areas. The background can be transparent, it can have a colour specified, or it can be an image. I am not aware of any order of precedence specified, or specifiable, between colours and images but images are normally, if not always, rendered in front.
Height, the standard says, applies to all elements [in visual media] but non-replaced inline elements, table columns, and column groups. As <hr> elements are block elements, height applies to them. Height specifies the content height of boxes generated by block-level elements, and content is the area inside the padding box (in turn inside the border area). Height is always constrained by min-height and max-height.
The one thing that is not defined, unfortunately, is what, exactly, the content of a horizontal rule is. It seems crystal clear to me, however, that a line, which, if drawn on paper, would be drawn with the same pen or pencil used for writing the surrounding text, could only be considered to be a foreground object, and should be coloured as such.
Considering all the above, it seems to me that a horizontal rule should be a line in foreground colour, whose height and width are as specified. It should be surrounded by an area in background colour (and/or with any specified background image), the size of this on each side being as specified by the padding property values. The padding, in turn should be surrounded by a border, the style, colour, and size of each side of which may be independently specified. Where the style of the border is such (dotted, for example) that a background is visible through it, the background should be the same as that used for the padding. Finally, subject to rules for collapsing them, the whole shebang should be surrounded by margins as specified, through which the background of the containing element should show.
I have not tried to consider the effects of positioning of any elements other than as static, that is, in the normal flow. Beyond a cursory look into the void, I have also not experimented with expressions of sizes as percentages, whether allowed by the standard or not. Sticking with fixed lengths, that of the above which isn't clearly defined strikes me as no more than common sense. Common sense, as so often, however, proves to be somewhat less than common and all I can do is report the behaviour I have observed. It is always possible that I have overlooked some setting that has affected my results but I have tried to fix everything I think may have a bearing on this.
Although they are noticeable on smaller scales, the browser-dependent effects are best seen with large blocks of colour that, I suspect, would deter readers. I have, for the moment at least, decided to refrain from providing visual examples and leave it to the interested reader to experiment. I am still considering how I can best address this and may provide an example later; meanwhile I simply present my findings textually.
Opera:
Firefox:
Internet Explorer:
In summary, Opera and Firefox can produce what I want with the same markup. IE7 can also present what I want, but not with the same markup. Although the differences are minor, I do have a trick up my sleeve and shall use IE’s conditional comments (which I may write about later) to supply different markup for IE. This has the added bonus of not requiring me to enter both colour and background colour as the same colour in the same style and so removes a warning from validation of my CSS.
Just a brief note on these, as it is a relatively minor issue, but Firefox appears to be different from other browsers.
HTML does not have a comment construct of its own, but it accepts a form of SGML comments, SGML being, if you like, HTML’s parent, and a very complex and little understood parent at that.
SGML statements begin with a left angle bracket followed by an exclamation mark - shriek, bang, whatever you want to call it - (<!), followed immediately by a token; the token can be a keyword, a comment delimiter, or, rather pointlessly, an end of statement mark, a right angle bracket (>)
SGML comments are delimited, front and back, by two consecutive hyphens, from which, incidentally, it follows that nested comments are not possible. A single SGML statement can contain any number of SGML comments.
Most browsers choose to accept only an SGML statement consisting of a single comment, and even that in a slightly restricted form: the familiar ‘HTML’ comment, delimited by <!-- and -->.
Firefox, however, takes a more literal, and what I suspect is a more correct, approach and considers occurrences of two consecutive hyphens within SGML statements to be comment delimiters. Text occurring between comment end and (next) comment start is, thus, non-comment SGML; I believe browsers are obliged to ignore markup they don’t understood in order to ensure a measure of resilience, and the perceived SGML code is, certainly, ignored.
If the comment delimiters are not correctly matched, large parts of a page can be ignored by Firefox. I am trying to ensure that I don’t use the delimiter string anywhere within my comments, simply to avoid the issue; it is not, for the most part, a great hardship but I do have to be careful when using IE's conditional comments.
One final note on comments in IE, which I may expand later. IE treats comments - wrongly, I believe - as document elements. An effect of this is that the CSS construct for consecutive elements (element1_identifier + element2_identifier) doesn't work if the two elements are separated by a comment. Opera and Firefox do not do this.
© Tony Jollans 2007 - 2023