francky wrote:
> My conclusions and lessons: Apparently different browsers have
> different "auto correcting machines" (or not) to handle incorrect
> html. Extra reason to write good html...
Indeed :-)
As I have mentioned a few times on css-d lately: browsers 'error
recovery' is not reliable. Complete and valid markup works much better.
> And when strange differences occur between browsers: validate with
> different validators! Small warnings in one validator, ignored by an
> other validator, can have big consequences. Banging heads! ;-)
Confused, and confusing, validators are not of much help with the
details. Don't know if "banging heads" is of much help either :-)
I made a similar conclusion a few years ago, and have kept on
fine-tuning my own methods since then. The result is that I hardly ever
write HTML anymore, but instead work with the much less forgiving xhtml
markup - from the top down.
I normally use only one tool: HTML Tidy, and I don't trust any set-up
for Tidy that others have made. In fact: I don't use a single extension
or tool for anything - unless I have tested it to death. Thus all my
tools are "old" - just like me ;-)
To keep it *on topic* for this list: the way browsers render CSS styled
pages vary for a few elements - depending on how pages are served. A lot
of other factors vary too, and since I don't like avoidable catastrophes...
Forget all about "broken" xhtml, or "smart" xhtml which basically is
garbled HTML with left-out optional HTML-parts and some added
backslashes. Plenty of those around - and the validator(s) ok a lot of
it, I'm afraid.
What I'm working with is 'true and working' xhtml.
I do serve my work as "broken" (x)HTML finally - just like most others,
and I couldn't care less that my pages are depending on 'error recovery'
since xhtml isn't html no matter which way it is served.
It is working - and because of the following steps it will continue to
work if I start serving those pages as they should be served - one day.
I use HTML Tidy with my own, tested, set-up for xml, served, and tested
across browser-land, as 'application/xhtml+xml'[1] with CSS and all.
Sometimes I take the resulting page(s) to the W3C html validator, just
to be on the safe side. I don't trust the validator all that much, but
it may pick up something that is of use to me.
Then I back-step and serve the result as 'text/html'[2] so IE/win and
other old browsers can render it as I want, and that's usually it. Not
much chance that the validator or browsers choke on it, but it does
happen :-) Most of the headaches are in the past though.
From there I can make things line up with CSS as much as I like across
browser-land. Not much to worry about apart from buggy or missing CSS
support in browsers. I even intentionally use non-valid hacks for bad
browsers, so I can let the CSS validator point them out for me at a
later date. Saves me from having to remember or comment each hack, but
I'm not sure if such an approach is "kosher".
Georg
[1]http://www.gunlaug.no/contents/wd_1_06_03.xhtml
[2]http://www.gunlaug.no/contents/wd_1_06_03.html
--
http://www.gunlaug.no
______________________________________________________________________
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
