QYAY
A Collection of Answers to Questions You Asked Yourself (QYAY) While Designing Web Pages
... but never dared to ask somebody else.
Ever felt dumb sitting in front of a screen? Did you feel like knowing almost everything since years that could possibly happen within a computer? And now you sit there knowing youv'e done it again: the most stupid error you could eventually make - but which one? Welcome to the club!
Making fools out of ourselves is not always our fault, though. Every manual and almost every lecturer does make the same errors: It or he or she does not explain the obvious. Why should one explain obvious things? Many things are obvious to one guy, or to a closed community, such as one of the miriads of W3C-commitees. Coming from another community, you hear the same words and read same terms you're ever used to. But you don't understand them any more. After a while, you'll find out these new terms have different meaning than you're used to. To grasp the new meaning, you must first be familiar with all the other terms, which, of course, have a context-depending meaning of their own.
Take my early days as a lecturer of C-programming, back in the mideighties. I was afraid of explaining the most basic grounds we are going to build on. Why should I explain, as exaggerating examples, what a variable is and what a constant, beside many other the audience should know even better than myself? The audience always was a bunch of convertites from other programming languages. They already made their living from programming in one or more of the then popular languages (Pascal, Cobol, Fortran, even assembler) and they just wanted the hear about the merits C promised to them. They would have felt offended, should I explain to them what a variable is - I thought. I did not realize "variable" and "constant" are just terms. Terms, that change meaning like chamaeleons colours when the environment changes they are living in. Terms are containers, that can collect content of different kind, much like a party-bowl. Of course, I soon faced misunderstandings, conflicts, explanations, discussions.
What I've done to my audience in those times, happens to me, as a late punishment, every time I learn a new facette of IT, for example when I started with Java or lately with webdesign. Starting tackling a new field, I usually would just study the "Get Started"-page of some tutorial and off I go hacking in my own, new stuff. And a new series of misunderstandings begins.
QYAY are those questions you often ask yourself, but that seem so stupid you would never dare asking somebodey else. This is a collection of questions that other and myself asked me. It usually takes some time to find the answer wich is close to be correct. Maybe, it will save you some time, when I publish the questions here. seeing a silly question published somewhere already helps a little bit, like a placebo. I hope, the answers will help even more and are not too misleading. I really stress the answers are personal, as is the way that leads me to answers: My own learning - which is not necessarily the straightest one.
Let's start with an easy subject: character encoding, which isn't only of concern to non-english sites.
Should I use UTF-8 or ISO-8859?
My first HTML-pages once showed the line
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
in the HTML-head. My site must be German and English, so it was logical I used the ISO-8859-1 set. I would also try UTF-8. But I learned quickly that this can create errors (I don't remember the errors, but display of the German umlauts wasn't correct).
Later I learned, today's experts program in XML (eXtensible Markup Language), which means writing well formed content and using CSS (Cascading Style Sheets). Thus, the first line of my pages had to read:
<?xml version="1.0" ?>
Which again fouled up my umlauts. Trying
<?xml version="1.0" encoding="iso-8859-1"?>
cured the problem, and let me feel like an expert, indeed. Everything worked nicely. I could have lived well with my site.
The moment came when my site was in good shape and I should uploaded it to the server. I just wanted to validate everything again. I validated my pages in Dreamweaver MX for XHTML 1.0 strict until there were no warnings any more. Then, that Validate-Current-Document-as-XML-menu-selection I've never used before stroke me. I tried it out, what brought me into real troubles: "An exception occurred! Type:TranscodingException, Message:Unicode char 0x2022 is not representable in encoding ISO-8859-1 " (the offending character 0x2022 is the little black dot I use in the content header- and footer-lines). Sure enough, replacing the ISO-code by Unicode did away with that error:
<?xml version="1.0" encoding="utf-8"?>
Now I was sold on UTF-8 because the umlauts this time seemed correct, and using Unicode means beeing prepared for the future. I 'insert-replaced' all my site and updated the hot pages on the server.
When I started Dreamweaver the next day and loaded one of my German pages, there was desaster. Only few lines of code were left on each page, the rest had gone. All my German pages were corrupted, lost. The same pages viewed in IE6 (or was it NS7?) at least one of them showed the page garbled, as Dreamweaver did) showed complete text, though. I heavely googled through the world trying to find some relation between ISO, UTF, Dreamweaver and my lost pages, something which could explain what was up. No usable result. One of my largest trial-and-error-battles began. It took me more than one day to find THE great solution to the small problem (No, don't tell me anymore I could have found an even better solution, in less time, thereandthere!).
The desaster's cause, experts might guess it, but they don't read this column: I left the meta-tag with the charset still set to ISO in the HTML-head, when I also used the encode-parameter in the opening ?xml-declaration. This doesn't matter for English text, but obviously lets Dreamweaver crash at the first umlaut.
Recommended actions:
Go for UTF-8, unless you would have problems to convert your content for applications that don't handle UTF-8.
Whatever character set you decide on, clearly state its encoding on the introducing <?xml ... ?>-line.
Set the charset-parameter in meta-tag to the same character set you stated for encode= on the first line.
For Dreamweaver, go to Edit>Preferences>New Document and set Default Encoding to your preferred character set.
Answer
Thus, my choice now is
<?xml version="1.0" encoding="utf-8"?>
....
<head>
....
<meta http-equiv="Content-Type" content="text/html; charset=utf-8;"/>
....
although UTF-8 is the default encoding character set for XML, I state the encoding in the declaration to make it clearly visible. I think, I can remember myself having read somewhere setting the charset by meta-tag isn't necessary any more, if you state the encoding in the first-line-xml-statement. However, the charset is necessary to correctly encode the Link-names. In a link "Überblick" the'Ü' will appear garbled, while all other umlauts in the ordinary text are displayed allright, if you don't set charset to utf-8 (or to the same character set you state in the first line, respectively).
Why can't I produce a decent web page with no JavaScript?
There is HTML 1.0 through 4.x, XHTML and CSS which should be enough to produce a nice-looking page. Why must I bother with JavaScript (or Perl, or Python or what have you)?
You wouldn't need JavaScript or anything else. I once was proud of my site here and I cood shout: Look Ma, no script! Almost none. I always needed some little script to detect the browser type and do some browser-specific adjustments. Otherwise my pages looked ugly, either in IE6 or NS7 or both.
The beginning of Internet was the easy, electronic exchange of scientific texts among universities and government agencies by e-mail. Later, a browser was used to display the text in some Notepad-like window. Typesetting, different fonts, graphics, database-content and all today's goodies were added later, in steps. Browsers evolved to interprete the message in one-way or the other, always one step late. It was unavoidable different browsers would interprete the different elements in different message in a different way and then make some legible display out of it. Thus, standardisation was the answer. The standars did standardise not only the presently known elements but also those that might desirable in the future. There was always much leadway for the browser developers to interprete those future features in there own specific way.
This site has to work with Internet Explorer 6.05 (IE6), since most users now use either IE5 or IE6. I made my very first HTML-steps with IE5. That one didn't exactly know the different meaning of margin, border and padding. The programmers just got the standard wrong. You could expect that be corrected in IE6. However, because Redmond is the natural centre of the universe (world - mondo - ..mond), the standard must be wrong, eventually, not IE5 or IE6. That means, if your markup is compatible with the IE6, it will not be compatible with browsers that closely follow (here, my first typing was 'foolow'. Freud?) the standard, such as Netscape 7.0 (NS7). Your page will look differently, garbled or wrong, possibly.
On this site, I faced at least two time consuming problems:
1. Margin plus border plus padding plus width gives the overall witdh (and height, espectively) of a box, as the standard. IE6 calculates the total width as margin plus width, ignoring border and padding. If no measures to compensate for this Microsoft-bug would have been taken on my site, the side-menues would look ugly either in IE6 or in NS7. JavaScripting (or an ugly CSS-trick) is necessary to compensate.
2. IE6 does not handle the z-index correctly. If an element has a higher z-index than the other, it is displayed "in front" of the other. The extratext that pops up off some of my side-menu-items, should be displayed at the right-hand side of the menu item, overlaying part of the content-area, when using a higher z-index than the content (the middle column). However, this is possible only in NS7, but not in IE6. This is the reason I let the text pop-up below the side menu. If I wanted to correct for this, specific javascripting would be necessary.
These two observations have nothing todo with the "quirks layout mode" of Modzilla-derived browsers. If you bring IE6 into quirks mode (by removing the first line of the HTML code starting with "<?xml version....") then IE6 got really into troubes with the moseover-event. Also, the width of XHTML-boxes are even wronger than in "normal layout mode" mode, whatever this is. See a treaty on quirks here.
When your page displays correctly within IE6, your markup is potentially wrong. You could ignore this fact, since you are lined-up with the centre of the universe and most of users will not notice it - or, being stupidly and hopelessly old-fashioned, you can correct your markup. Latter is only possible either with some crooky HTML- or CSS-code, or using a JavaScript.
Answer
If you want your markup displayed the same way in IE6 and NS7, you often need JavaScript at least to find out which browser-type is active and to take the consequent actions.
Why doesn't your menu hover correctly?
On my pages, when you enter the yellow marked menuitem, which stands for the current page, the help-text that describes the respective page pops up, but sometimes it doesn't. More precisely, if you approach the item from below, the helptext pops up, if you approach the current item from above, the text doesn't pop up. When the text pops up and you leave the item via the left or right border, the text stays there, albeit it should disappear.
Answer
This doesn't happen in Netscape 7.0, so I think this is one of the many Microsoft Internet Explorer "mouse-over"-bugs that have been reported.
Where can I ask stupid questions?
Answer
If it's really a stupid one, and only then, give me a try.