additions...
...web design — in accordance with standard...
which standard…?
I'm all for standards—W3C standards that is, so this isn't about whether to follow standards or not. It's about whether or not our design-efforts get through to our visitors, and standards provides no guarantees. They help a lot though.
This web page validates as xhtml 1.0 Strict, and acts as if there never was such a thing as "web standards".
Some browsers receive it as a perfectly good standard-compliant web page, while some misinterpret it and treat it as good old prehistoric 'tag soup'. The difference is of course caused by the presence of this little line of code: <?xml version="1.0" encoding="utf-8"?>, that I found to be so nice-looking that I wouldn't delete it. Ask Microsoft about it...
Ok, so all browsers will run this page through their 'tag soup' recovery/correction engines, really. The difference between this and most other pages on the web, is that this page isn't in need of any recovery/correction in order to turn out just fine.
This page is technically flawless, so there must be an absurd bug involved if something doesn't render as intended. Whether that's a nasty browser-bug, or an ordinary human bug from the author's hand, is not always clear. It tends to be the former though.
acid CSS…
The additional CSS is crossing so many barriers that the W3C CSS validator chocked on it, so no use running it through that one again.
If you sent it through the validator anyway, then you only have yourself to blame. You can't say I didn't warn you.
The CSS wouldn't look so bad if this was an ordinary web page, but it is taking part in a well-organized test of all browsers around, so you will just have to excuse its acid ingredients. It's all for a good cause.
give me a break…
You wouldn't believe what this simple web page has to go through on its way across the web towards your browser. It has been hand-coded, styled, cleaned up, validated and served as tag soup. It's a wonder it has survived all this and still manages to stay in one piece in most browsers.
Ok, I know this page is broken by some older browser-versions, but what did you expect? There's a limit to what a poor little web page can manage on its own. Be kind: give it a break and a new, standard-compliant, browser.
transitional vs. strict…
I don't write a doctype myself – that's HTML Tidy's job. Sometimes I do add in a dummy-element that'll prevent HTML Tidy from upgrading to a Strict doctype.
I am no longer adding these enforced doctype triggers to my pages by default, but you may still find many pages with a Transitional doctype. They're perfecly valid, and most are just as valid when given a Strict doctype.
I'm generally not too concerned when it comes to Transitional vs. Strict, and I am well aware of the differences. I write my markup and make sure no mistakes are made – that's where HTML Tidy is most useful, and then my creations just has to work.
No doctype and validation can guarantee that a creation works, so that's my department. I can assure you: that department is run well.
xhtml served as text/html…
There's a whole page, with duplicates, that goes slightly more in depth on the subject of serving XHTML1.0 correctly – as application/xhtml+xml or something. Sure, I know how to do that, but once a page is ready for launch it is quietly downgraded to text/html and ready to meet the public.
Some say this page shouldn't be served as text/html. That's fine, but that's about the same as to say that it shouldn't be served at all. That's no big deal either, but I need better reasons than those given. This is just ordinary HTML 4.01 that's been slightly reformulated to valid xhtml 1.0, and browsers treat it as HTML 4.01 without any further help from me.
I like that <?xml version="1.0" encoding="utf-8"?> too much to let go of it without a really good reason. It looks better than a comment on top of the source-code since I usually wants IE6 to revert to Quirks mode – without affecting IE7. The rest is more or less answered by W3C: HTML and XHTML Frequently Answered Questions, and that's about it on the matter at the moment.
even higher standard…?
No, not yet. Some improvements are needed in some "yet to be recommended" standards before I see any point in coding for higher standards. Right now there's nothing but a number-change and some more restrictions, and that's of no use to me in daily life (see above).
Once some real gains can be observed, and some ordinary standard-compliant browsers are responding to it, then it's time to change a few bits and pieces here and there and code in accordance to a higher standard.
Such an upgrade will also mean goodbye to legacy-browsers, as I can't see any point in upgrading if I am to downgrade it again. This is no concern of mine yet though.
I am satisfied with the way browsers are treating this page – now, and will look at the issue again when there's a real gain in changing anything. May take a few years...
tag soup browsers…
Legacy-browsers or 'tag soup browsers' — it's the same thing. Others may discuss wording, as I couldn't care less about all the quasi-academical noises around semantics and well-formedness and so on. Legacy-browsers treats everything as tag soup – or not at all, no matter the terms used.
The entire web is in a transitional period, and only God knows how long that'll last or if we ever get out of it. No good signs up ahead, so I'll relax on the matter.
Serving this (and all other) web page(s) as text/html, is perfectly valid. How the browsers treats web pages served as text/html is not my problem. Those who make browsers have to take care of that.
My part in it is to keep an eye on the results, and see to that it is palatable for as many visitors as possible. Since others have made it impossible to reach all by creating buggy software, those others will have to solve what's left.
conform to standards…
No problem conforming to standards, as all I have to do is to launch a page that doesn't challenge any standard. Not even those who write standards are able to do much within the limits of all of them at the same time, so they keep on creating holes and convenient exceptions in all standards.
Think I'll wait, and observe, till they have created enough holes and exceptions in those standards so the entire web can get through. Guess it'll only take a few more years before they reach that point, and then they'll probably reverse it.
Lets hope some body can put some common sense into it before it's too late. There's always a glimmer of hope if you close your eyes, you know.
standard fonts…
It's time to play a game of ♙ ♘ ♗ ♖ ♕ ♔. Hope you understood that one, as I see no point in translating one standard into another one...
Ok, I'll explain the "riddle" above. Depending on the capability of your browser and the installed fonts available to it, the 'non-letters' above will either be seen as a number of chess-game pieces or some signs telling you that your browser is unable to present them. This is all being decided at your end, and there's nothing I can do about it.
Just look at this lineup of ordinary 'non-letters': ♯ ♮ ♭ ♬ ♫ ♪ ♩ ♨ ♧ ♦ ♥ ♤ ♣ ♢ ♡ ♠ ♟ ♞ ♝ ♜ ♛ ♚ ♙ ♘ ♗ ♖ ♕ ♔, and see how many that comes out at your end. Should be all, really.
I don't think capabilities and choices at the user-end is my responsibility in a case like this, so I shouldn't have to tell any visitor about this, really. Besides, there are no reliable ways to present alternatives for these 'non-letters' anyway, so I can either include them according to standards and leave it there, or the standards behind them are completely useless for the time being.
standards and practicality…
There are millions of web users, and there are at least that many hardware and software solutions around. If web designers are to leave out every bit of standard-progress until every single user can get them through their own solution-package, then there's not much left to create web design with, and no need for progress in standards. Can't be much future in that.
I wouldn't dream of accepting such a limitation, and neither would other sane web designers. The solution is to go as far as standards allow for, and—if necessary—continue from there until we have created something we think is good enough to be released.
If standards have to be broken in order to reach the end-result, then, sorry, but it's 'no big deal'. Maybe tomorrow we'll get some improvements to standards that'll let us design what we want within their limits. There's always hope...
Have fun now ♬
sincerely 
Hageland 14.sep.2005
last rev: 16.jul.2006
additions...
