Does IE have the same problems with XHTML 1.0 Transitional as it does with HTML Transitional?

Hello,

I have read about the problems that IE has when using a doctype of HTML
4.01 Transitional. I was advised to use Strict wherever possible.

My question is, does the same apply to XHTML 1.0 Transitional? I develop
sites using ASP.NET, which emits valid XHTML 1.0 Transitional, but not
XHTML 1.0 Strict (for example, it includes a hidden form field with the
name of _VIEWSTATE, which isn't valid in Strict, but is in
Transitional).

Anyone any comments? The framework is brilliant, but I'm a bit stuck
trying to produce 100% valid code. Am I likely to have any browser
problems with XHTML 1.0 Transitional?

TIA

--
Alan Silver
(anything added below this line is nothing to do with me)

On 20 Feb 2006 07:45:11 -0800, "Steve Pugh" <steve.grumpy (AT) gmail (DOT) com>
wrote:

My question is, does the same apply to XHTML 1.0 Transitional? I develop
sites using ASP.NET, which emits valid XHTML 1.0 Transitional, but not
XHTML 1.0 Strict

It should be possible to make .net extrude whatever code you want it
to. It's a fairly crap tool if it doesn't.

According to a colleague I spoke to at lunch today (well, actually he
was doing most of the speaking), "fairly crap" is being kind. Apparently
..net does the typical Microsoft trick of thinking it knows better than
the developer, and spontaneously changes working files into non-working
files. He was an exceedingly unhappy bunny.

--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/

In article <997kv1l0l9vedlnuf3cdnee99td4nf03r4 (AT) 4ax (DOT) com>, Stephen Poley
<sbpoleySpicedHamTrap (AT) xs4all (DOT) nl> writes

On 20 Feb 2006 07:45:11 -0800, "Steve Pugh" <steve.grumpy (AT) gmail (DOT) com
wrote:

My question is, does the same apply to XHTML 1.0 Transitional? I develop
sites using ASP.NET, which emits valid XHTML 1.0 Transitional, but not
XHTML 1.0 Strict

It should be possible to make .net extrude whatever code you want it
to. It's a fairly crap tool if it doesn't.

According to a colleague I spoke to at lunch today (well, actually he
was doing most of the speaking), "fairly crap" is being kind. Apparently
.net does the typical Microsoft trick of thinking it knows better than
the developer, and spontaneously changes working files into non-working
files. He was an exceedingly unhappy bunny.

In that case, I suggest he learns a bit more about how to use it
properly. The comment you have reported is inaccurate to say the least.
The framework doesn't do anything with your files. If he hasn't written
his files right in the first place, then you can't blame the framework
for not being able to work with them. With extremely few exceptions,
working files will carry on working. I'm assuming he's talking about
upgrading from one version of the framework to another. If he's talking
about going from ASP to ASP.NET, then he would be foolish in the extreme
if he expected them to work. It's a totally different environment and
barely compatible.

I'm not saying ASP.NET isn't without issues, but this simply isn't one
of them. It also depends on what version he's using. Any 1.x version is
asking for trouble. Version 2.0 is a whole new world. It emits valid and
accessible code for one thing!!

--
Alan Silver
(anything added below this line is nothing to do with me)

On Mon, 20 Feb 2006 22:58:13 +0000, Alan Silver
<alan-silver (AT) nospam (DOT) thanx.invalid> wrote:

In article <997kv1l0l9vedlnuf3cdnee99td4nf03r4 (AT) 4ax (DOT) com>, Stephen Poley
sbpoleySpicedHamTrap (AT) xs4all (DOT) nl> writes
On 20 Feb 2006 07:45:11 -0800, "Steve Pugh" <steve.grumpy (AT) gmail (DOT) com

It should be possible to make .net extrude whatever code you want it
to. It's a fairly crap tool if it doesn't.

According to a colleague I spoke to at lunch today (well, actually he
was doing most of the speaking), "fairly crap" is being kind. Apparently
.net does the typical Microsoft trick of thinking it knows better than
the developer, and spontaneously changes working files into non-working
files. He was an exceedingly unhappy bunny.

In that case, I suggest he learns a bit more about how to use it
properly. The comment you have reported is inaccurate to say the least.
The framework doesn't do anything with your files. If he hasn't written
his files right in the first place, then you can't blame the framework
for not being able to work with them. With extremely few exceptions,
working files will carry on working.

So there are exceptions then ...

I'm assuming he's talking about
upgrading from one version of the framework to another.

Well, you know what they say about assumptions.

If he's talking
about going from ASP to ASP.NET, then he would be foolish in the extreme
if he expected them to work. It's a totally different environment and
barely compatible.

No. The stuff was written for .NET.

I'm not saying ASP.NET isn't without issues, but this simply isn't one
of them. It also depends on what version he's using. Any 1.x version is
asking for trouble.

That's a pretty sudden bit of backtracking. We didn't go into details -
it may have been 1.x.

Version 2.0 is a whole new world. It emits valid and
accessible code for one thing!!
--

Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/

Alan Silver wrote:

Of course the whole concept is bogus; but it's what's happening, so,
bogus or not, we have little choice than to use it.

Bogus in what way?

The Doctype states which language the document is authored in. Browsers look
at this (specifically at the collection of characters that make up Doctype,
not at the language the Doctype claims the document is written in[1]) and
use it to choose between following the specifications (mostly CSS, not even
the spec that the Doctype actually relates to!) as closely as possible and
intentionally getting parts of it wrong.


[1] e.g. A Doctype for HTML 4.01 Transitional may or may not trigger
standards mode depending on the presence or absence of a URL in the
Doctype.
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

In article <q4nmv1dsqhce0cpdn0dqd7bm18b7cac7dl (AT) 4ax (DOT) com>, Stephen Poley
<sbpoleySpicedHamTrap (AT) xs4all (DOT) nl> writes
<snip>

With extremely few exceptions,
working files will carry on working.

So there are exceptions then ...

I'm sure there are. I said it that way to cover myself against someone
pointing one out. As far as I have seen, a working file will carry on
working.

I'm assuming he's talking about
upgrading from one version of the framework to another.

Well, you know what they say about assumptions.

True, but if he isn't then I haven't a clue what your comment was
supposed to mean. Maybe there are other circumstances in which working
files can suddenly stop working, but other than an upgrade (which
shouldn't stop anything working), I can't see what.

Given the very vague nature of the description, it was hard todo
anything other than assume ;-)

If he's talking
about going from ASP to ASP.NET, then he would be foolish in the extreme
if he expected them to work. It's a totally different environment and
barely compatible.

No. The stuff was written for .NET.

Well then, he shouldn't be having problems with files stopping working.
Unless he's done something wrong of course, but you don't seem to
consider that a possibility.

I'm not saying ASP.NET isn't without issues, but this simply isn't one
of them. It also depends on what version he's using. Any 1.x version is
asking for trouble.

That's a pretty sudden bit of backtracking. We didn't go into details -
it may have been 1.x.

Why is it a backtrack. As far as I am concerned, 2.0 has been out long
enough for anyone doing serious ASP work to upgrade. AFAIK, there aren't
any upgrade issues, and 2.0 offers so many benefits over 1.x that
there's every reason to move.

Anyway, as this is OT for this group, I suggest we drop the subject. If
your friend is having the kind of problems you describe, I suggest he
hops over to the ASP.NET newsgroups and asks there.

Ta ra

--
Alan Silver
(anything added below this line is nothing to do with me)

David Dorward <dorward (AT) yahoo (DOT) com> writes:

Alan Silver wrote:

(Alan Flavell wrote [about doctype sniffing]

Of course the whole concept is bogus; but it's what's happening, so,
bogus or not, we have little choice than to use it.

Bogus in what way?

In every way.

The Doctype states which language the document is authored in.

No it does not. It just specifies the document's own, unique formal
grammar (or to say it with /the makers of/, 'The element, entity, and
short reference sets') in its declaration subset and declares the root
element for the following document instance set.

That's one good reason why the whole concept of sniffing for per
definition arbitrary strings is rightout laughable.


--

|| hexadecimal EBB
o-o decimal 3771

--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011

On Wed, 22 Feb 2006, VK wrote:

Alan Silver wrote:

[about DOCTYPE sniffing...]

Bogus in what way? As I said, I'm no expert on this, so would be
grateful for any extra information you can provide.

Unless I'm totally out of the loop here:- "bogus" means that IE
doesn't support XHTML and doesn't plan to do it in the any near
future:

Heavens, no: DOCTYPE sniffing isn't about HTML versus XHTML - it's
about rendering in quirks mode versus standards mode.

At the superficial level, it's bogus to suppose that by inspecting
some details of an author's DOCTYPE, one could deduce whether he wants
his web page to be taken seriously as standard HTML+CSS, or just
treated as an attempt to do visual DTP relying on the (known and
unknown) misbehaviours of old and buggy browsers - nowadays most
particularly MSIE.

It's doubly-bogus that the quirks v. standards heuristic test is done
on the DOCTYPE in the HTML, whereas quirks v. standards has most of
its *effect* on the interpretation of CSS, not of HTML.

It's kind of sad that when MSIE was originally introduced, it
attempted to emulate the known bugs of the then-available Netscape
version, whereas nowadays the Mozilla folks have wasted a substantial
amount of time and effort on emulating the known bugs of later
versions of MSIE. A pity they couldn't just have concentrated on
implementing to specifications, considering all the things that are
in the specifications but still waiting to be implemented.

At a deeper level, the supposition that the DOCTYPE even declares
which "version" of HTML the author thought they were using, is
fundamentally flawed. It doesn't matter, and 99.9% of readers won't
want to know or care, but the matter is examined in depth (and this is
an answer to David Dorward's apparent misconception about this
underlying principle) in an article linked from the already-cited
http://hsivonen.iki.fi/doctype/ , namely
http://groups.google.com/group/comp....e53dee2c152a81

No offence meant to David - it's a very popularly held misconception,
indeed in practical terms it really doesn't have any impact on us as
web authors. But nevertheless, as it says there (written in 1998,
in an SGML context, of course):

___
/
Have I made my point? DOCTYPE declarations tell you nothing about the
class of documents of which a document is a member. Nothing.
[...]
This means that there is a BIG PROBLEM: for the last 10 years,
something we thought we were doing turns out to not be that at all.
We have all been living a lie for the last 12 years.
\___


And he goes on to discuss Architectural Forms - which XML tossed
aside, and later re-invented in a different way. But I digress.

On Thu, 23 Feb 2006, VK wrote:

Alan J. Flavell wrote:
DOCTYPE sniffing isn't about HTML versus XHTML - it's
about rendering in quirks mode versus standards mode.

Right.

An important notice though: DOCTYPE by itself is *nothing*
whatsoever:

There's the difference between what it *is*, and what it *gets used
for*.

What it *is*, is defined by SGML, in theory. But in practical terms
it gets used for something else altogether. And that's why DOCTYPE
sniffing is being characterised as "bogus" - no matter that we need to
use it in practice, since this bogosity seems to have been widely
adopted.

At a deeper level, the supposition that the DOCTYPE even declares
which "version" of HTML the author thought they were using, is
fundamentally flawed.

It did not!

(Does not parse.)

Until IE 6.0 DTD at the top of page was an equivalent of supporter
sign on your jaket during the election campain.

Again you're confusing the question of what it /is/, with what it gets
(or got) used for.

But it may affect significally on the page appearance for 60%-90% of
your visitors.

Visual appearance is no concern of SGML :-}

As I said before - this *SGML* feature is being (mis)used in *HTML* in
order to influence a browser's interpretation of *CSS*. That's at
least *double* bogosity, if not multiple. Still, we have no
alternative in practice than to follow it, no matter how bogus we may
consider it to be.