Validate your code
by Volker Weber
Wolfgang is still fighting with his website. It is killing Safari.
I just ran his code through the validator. Error number 604 (yes, sixhundredandfour) says: Line 233, column 6: end tag for element "FORM" which is not open. -- This really cries for a fix.
Update: Wolfgang has made tremendous progress with his code. If it were not for the missing doctype it would validate without a problem. The above link forces the doctype so it does validate. It turned out the problem is in his CSS code but that can also be fixed. Keeping out fingers crossed.
Comments
Volker,
thank you for the 'high standards' but actually I've never been much of a web developer and much less a web designer. I you were able to access my pages you'd know for sure.
With respect to the web I don't see any contradiction between a high standard and crappy HTML. You folks might make me run the gauntlet now but my position regarding the web is: If it displays correctly 95%, it's ok.
Why? Because I actually *have* high standards. These standards say: Something that *basically* relies on the idea of *mixing up code and data* has been a bloddy mess from the very beginning and can only get worse over time (it did, see inline JavaScript + ASP, inline Cookies..., proprietary tags...).
As with all crappy stuff we can't easily replace we simply should be glad to have a 95% working (t.i. correctly displaying) level. After all that's what the whole thing is about.
A perfect validating page would result in a 2% improvement to something that's a shi... mess by conception anyway so there's not much room for improvement there.
That's why your browser crashes... not because I have low standards but because HTML is basically such a low standard that it can't tell code from data. The rest simply is applied Murphy's law. Remember what Ford Prefect said about the story of Adam and Eve?
Of corse you are right to some extent and I'm really thankful for your engagement.
Part of the repeated minor 'errors' (using '&' in automatically generated URLs) could easily have been prevented but I fail to understand why the standard requires I should HTML-encode the '&' in URL's to '&' instead of URL-encoding them.
The preceding has indeed become an unlucky standard Domino attitude when using domino forms :-)
However an unexpected closing form tag should not crash your browser as well as an unexpected shouldn't, right?
Wolfgang
What a long answer. I really must have stepped on some toes there. :-)
I respectfully disagree however. Standards are a good thing, because you can just follow them. There is no need to break them deliberately. I moved from HTML 4 to XHTML 1 because it is generally much nicer if you have well formed documents that can be parsed easily. We have been doing some portal work and that requires a lot of translating from HTML to some other form of HTML. If you start off with something that's valid things are generally much nicer. It is not only about browsers.
And really, there is not much effort involved if you start off cleanly. I invite you to try my sandbox at wiki.vowe.org. As a user you can enter new stuff very easily and there is nothing you can do to make it not validate. There is a link to the validator under the bottom grey bar.
A good start is to include a DOCTYPE so that the browser does not have to guess what standard you are trying to follow. And Domino may produce crappy code from the outset because developers of the Domino Web Engine may have thought that 95% is good enough but it can be done as Ben Poole demonstrates. His site is not perfect but comes much closer to the standard.
And btw, he also has a dangling form tag. It does not break Safari.
I think we had this discussion about standards with the RSS feeds already. We finally agreed that they just have to validate no matter whether there are aggregators out there who can work around the unnecessary bugs. If we want to move further into the <gasp> semantic web with little things as trackback, auto discovery, foaf etc. we might as well stop producing crappy code by design. This is not about users who make sloppy typing mistakes. This is about content management systems that don't care.
Hi Volker,
I really enjoy reading your 'blog.
Regarding Wolfgang's site, I see a number of problems on that page. The one that seems to crash Safari, however, is in his CSS. The following line is a no-no, and it causes a segfault:
.vC:before{content:" "url(i_clock.gif)" ";}
I have created a slightly modified page. The HTML validates, but the CSS doesn't. I'm not sure what Wolfgang was trying to do with the "*=" and "^=" in the stylesheet.
The modified version is available at:
http://www.bitpuddle.com/safari/crash/css/SafariCrash.zip
Eric -
Eric, good one! Now that Wolfgang has fixed the HTML code he might also be able to fix the CSS.
Just loaded Wolfgang's stylesheet into TopStyle. Ouuch. There is a lot to clean up.
There is a lot of CSS weirdness out there, most of it designed specifically to "break" the browser so that one stylesheet can be used in all clients. (MSIE 5.0 has been given a value, then breaks when I do this, so I can put the real value for NS6 here and let the cascading rules...) Sounds like a good idea in theory, but relying on bugs to produce the expected result is ultimately a strategy aimed at failure. There's more maintenance involved in creating multiple stylesheets (or in computing stylesheet content), but if your platform can serve different stylesheets to different clients, that's the way to go.
Eric,
thank you for your help. I'll soon have a look at it today.
PS: The *= (attribute contains) / ^= (attribute starts) CSS3 selectors can be found here:
http://www.w3.org/TR/css3-selectors/#selectors
I also thought it would be possible to concatenate pseudo-selector's content and it works with Mozilla as intended (displays: blank + my.gif + blank). I expected other CSS capable browsers to possibly ignore it but not to *crash*...
Must say, I hate it. I want to publish content that's useful for the community, experiment a bit with Lotus Notes and I end up dealing with something completely different providing less value. That isn't what I expected with my blog (a quick public notepad)...
As for the general view on compliance, as pointed out by Volker, I'm probably giving my point of view later. Don't want to clog Volker's blog with my lenghty comments now.
Thank you for your support, everyone!
Wolfgang
Don't worry about the few extra lines. :-)
Wolfgang, if you are about content then cut back on the decoration. KISS should be the guiding principle. You have a very convoluted CSS and it does not validate. I would start with something rather easy and then add content. If you get bored you can add more fancy decoration. But every single step along the way, the code should validate. Once it does validate you can check whether it displays correctly on all browsers.
I have installed a second wiki. The feature set is not bad but unlike the first wiki I tried it does not produce valid code. Bummer.
And you are absolutely right. The browser should not crash, no matter what you throw at it.
I like KISS ;-)
Absolutely, the browser shouldn't crash just because some CSS feraks it out. But then of course, we mustn't lose sight of the fact that the browser in question is still in beta!
Have you logged a bug with Apple BTW?
Volker,
I use my site for both publishing and experimental purposes. Learning = pushing the limits, isn't that so? Well, I didn't expect that was on your (safari's) costs at first...
Tried a quick fix replacing the " "url()" " with padding so are you willing to accept another test crash now? :-)
PS: With respect to standards I say, there's a difference wether browsers access it for immediate display or wether 'arbitrary machines' need to. I don't care much if machines have problems evaluating my code, actually I try to prevent it because I write for humans.
You are walking a much too fine line here. Humans need machines to read their websites. In this case you are breaking a browser. I want to agree with you that it is a good thing if a website follows standards. Have it validate against that standard.
The browser vendor has to make sure that its product is able to dispay standard compliant pages. I know that their task is much harder because they also have to take into account the various flaws in other products and the work-arounds that have been applied by web designers to still make a site readable.
If you deliberately break standards so that "machines" cannot read your site, you are making life hard for a lot of people. If that is your real concern, I have a much better idea: Build a simple site with a lot of content, then lock it up with a password. Have people ask for that password and only those who have one can read your stuff. Problem solved.
I logged a couple of variations of that bug with Apple.
Problems like this are funny. They have two sides.
On the vendor side, no code should crash a browser. I don't care what you hand the browser, HTML or kiwi fruit, it shouldn't crash Safari. That is very clearly Apple and KDE's problem.
On the language side, however, the author must take some responsibility, too. I often baffle my colleagues with my complex spoken syntax, effectively crashing their lexical parsers. If the point of writing is to communicate, we really should make an effort to communicate simply and clearly. If the site doesn't render, both the browser vendor and the author have failed to communicate.
Looking at the site, that CSS seems overly complicated. Much of it appears to be boilerplate. In the end, the site may be easier to maintain with a more simple stylesheet.
Volker,
I know I'm walking the tightrope ...
I didn't indend to break browsers by purpose (except for harvesters using IE components but that's a different story). I'm talking about the true benefits of being/staying compliant and the efforts involved.
If my pages display properly in browsers and are indexed by search engines I still feel that's ok. The 5% having problems, well, it's harvesters anyway - I don't care for *their* problems. New browsers don't pop up every day and the Safari crash was a very rare exception.
Sometimes I think people claiming for 100% compliance are just compensating for a poor reality.
They stop working at projects that just perform ok but are far from perfect. In their code they do not catch every possible error or throw a helpful explanation every time. They often use workarounds instead of proper fixes. Their security often is by obscurity. Their UI could be more intuitive and they know it. They produce rather rudimentary help files and don't spend very much time on documentation. They don't bother much about correct spelling and grammar, even in their mother's tongue. When responding, they sometimes quote too much or too less. Their IMG ALT attributes sometimes are a helpful ... "A picture named a.gif". They display faked referrers for some time at least until they find time for a review.
They always compromise ... benefits/value added against efforts.
The name of these people are 'you' and 'me'. They may not always like acting that way but that's the way life goes.
But then some of them suddenly insist all HTML has to validate 100%???
Wolfgang
PS: My main view isn't accessible at the moment - corrupt ACL, I presume. Deep links will work however.
PPS: Being less compliant with standards may save your marriage, make your children happier and give you more of a life in general. *People* matter. Dixi.
@Eric,
"Much of it appears to be boilerplate. In the end, the site may be easier to maintain with a more simple stylesheet."
Full ACK.
However, The Holy Grale, there's quite some work involved to come closer. :-)
Wolfgang
Being less compliant with standards may save your marriage, make your children happier and give you more of a life in general. *People* matter
Absolutely. That is my quest for simplicity. If it ain't in there, it can't break. So it takes less time to fix.
It's also the reason why I don't use Domino for my blog. It would be way too much work to maintain it.
Simplicity... Volker, really, I don't have *that much* time!
Wolfgang
Hey, simplicity took only 3 (three) minutes to build. :-)
t's also the reason why I don't use Domino for my blog. It would be way too much work to maintain it.
Yes, Domino takes work. But be fair, the Domino weblog templates are pretty new, and certainly don't make for "mature" products in the way that MovableType does, for example.
