Lachlan Hunt wrote:
Gunlaug Sørtun wrote:
An added advantage of including the 'xml declaration' is that IE7
won't be triggered by it. IE7 will simply skip it and treat 'xhtml
1.0' in 'Strict mode'. Therefore we have a built-in filter to
avoid feeding IE6 styles to IE7, when our IE6 styles are using the
old '* html' hack that IE7 will ignore when in 'Strict mode'.
* html is supported by IE6 in any mode, there is no need to trigger
quirks mode for it to be used. In fact, I have found no reason at
all to ever intentionally trigger quirks mode in IE, and I'd be
interested to know your reasons for doing so.
I wrote that in the part you left out...
- Depending on the task; it may often be easier to make IE6 "appear" to
follow standards when we _do not_ allow that browser to use its 'Strict
mode' (which I personally call the 'anything-but-standard mode'). -
I could of course add examples, but they won't do anyone any good since
they are based on personal preferences. I am not implying that we can't
make 'Strict mode' work just as well in IE6, but why bother to work
around problems in a dead and pretty predictable browser when it doesn't
help it perform any better?
IE6 is "dead" in development-terms, and its replacement won't suffer
when we keep IE6 styles out of its reach. I don't even bother to use
'conditional comments' for serving corrective stylesheets to IE/win,
since there is - and should not be - any need for those anyway.
All this "back and forth" is based on 'xhtml 1.0' served as
'text/html' and _treated as_ 'html 4' by every browser on earth.
That's how I code and serve 'xhtml 1.0' today, with or without an
'xml declaration', and there are no actual problems involved when
done right and assisted by 'HTMLTidy'.
This is one of the myths I've been talking about in this thread.
There are significant differences between text/html and
application/xhtml+xml when it comes to handling scripts, stylesheets,
erroneous markup and encoding information.
It is not "a myth" that 'xhtml 1.0' served as 'text/html' is treated as
'html'. How browsers are supposed to treat scripts and css when we serve
proper 'xhtml' as 'application/xhtml+xml' is known to me, but it's a
completely different matter since we're talking 'text/html' here - and
will be for a long time to come.
Well made and well prepared 'xhtml 1.0' with an 'xml declaration'
is also ready for the next step - serving it as
'application/xhtml+xml'.
That is assuming any scripts and stylesheets have been developed and
tested with XHTML rules in mind.
Of course. We have to play by the rules.
No advantage in that for the general web page/site at the moment,
since no browser released (or to be released in the near future) by
Microsoft will support 'xhtml 1.0' served as anything but
'text/html'.
It is expected that IE8 will support XHTML, but the expected release
schedule for it is (AFAIK) not publicly known, nor expected any time
soon. My estimate is about 3 years away, with IE7 being about 6-12
months away.
Let us hope the final IE7 is at least up to the task when served
'text/html' and _standard_ CSS. I wonder what will happen to the
different 'script-standards' (quirk/Strict) though.
We may use the time from now until the arrival of a 'functional
xhtml-support' in a future version of IE, to prepare our skills so we
can serve 'proper xhtml' as 'proper xhtml' and expect it to be treated
as such by the majority of browsers. Would be nice - even if it breaks a
few times while trimming.
So, we have a choice whether to allow for the less demanding and
not future-prepared 'html 4' to affect our coding-practices, or
learn how to prepare for the future with well-formed 'xhtml 1.0'.
Could you please explain what future needs to be prepared for with
HTML 4? Are you expecting that browsers will drop support for it
some time in the future, thus leaving any page not converted to XHTML
inaccessible?
No. I didn't write 'not future-proof' - I wrote 'not future-prepared'.
There is more than 'html' in that future, and 'html' can by definition
*not* perform well outside its defined boundaries. So either 'html' has
to be reformulated (which it already is through 'xml' into 'xhtml'), or
some hybrids will have to add performance to 'html'.
Are you expecting browsers to start choking on invalid HTML 4?
No, browsers still swallow old 'non-standard html' every day, and won't
drop support for 'garbage' until there's nothing left of that stuff on
the web (which will probably never happen). So no problems with 'html 4'
- apart from that browsers will still eat that and any other 'text/html'
almost regardless of how bad it is created.
"Don't lead me into temptations" might be a good reason for not
promoting 'html 4' to anyone new to this "game", although I'm extremely
well aware of the fact that one can mess up 'xhtml' just as bad when
serving it as 'text/html'. We will just have to counteract that in this
transitional period, if we want standards to succeed.
Are you expecting something else about HTML processing to
significantly alter the way existing documents are treated and
rendered?
No, but there's no need for improvements in standards or browser-support
if we all should "play it safe" and keep on adding new documents based
solely on how today's documents are supported across browser-land.
While I do believe XHTML will play a big part in the future, the
future is not here yet and we have a long way to go before then.
The future will be even further away if we don't actively push a bit
forward, or at least head in that direction. If we are on the way to the
future, then we should at least prepare the bits and pieces we can do
anything about and with - *now* - and move forward from there.
We should also help others see that future, instead of telling them that
they better wait by the roadside until _all_ quirky bits are leveled on
the road towards it. If left ignorant they may forget all about what
that future has in store, with the result that it will never come to them.
-----
So, although we probably agree (more or less) about "status quo" and
"lack of support for 'xhtml' served as 'xhtml'" and "whatever the future
has in store", we seem to point to different routes for a safe passage
forward.
I don't believe in "playing it safe", because of the lack of progress in
such an approach. I believe *improved knowledge* is the answer to
everything that _can_ be answered in life, and that goes for web
development too.
Thus, I rather tell beginners that the road might be a bit bumpy for a
while because of the steep learning-curve and the sketchy and buggy
support for just about everything, but that the future looks brighter up
ahead.
I don't think you'll disagree (all that much) with such an approach -
even if you don't seem to preach it at the moment. I believe you will -
once the road is leveled a bit more, and a few more facts about the
future is revealed. Crystal balls are out of fashion, I think, so the
future may look at least a bit "unclear" at the moment.
I don't have time to wait for a "smooth ride". I guess I'm too old in,
and for, this "game", and maybe too old altogether. Time does that to us
whether we like it or not.
regards
Georg
--
http://www.gunlaug.no
******************************************************
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
******************************************************
