On 9 Feb 2005, at 00:49, Geoff Deering wrote:

Patrick H. Lauke wrote:
There are *no* inherent benefits to tableless, css
driven layouts in XHTML strict versus tableless, css driven HTML (strict
or transitional) or even XHTML transitional.

That is a misconception.

Provided the XHTML document has been "extended" and that the correct content-type header has been sent for the document (application/x…) there are *no* benefits. Pages don't load faster because no current browser will incrementally load the page. Mozilla themselves even recommend that you do *not* send it as application/xhtml+xml because of the slower rendering.

With a HTML document (strict or otherwise) the rendering occurs incrementally

There are differences to the way a rendering
parsing engine will work with the different doctypes.

No. There are differences in the way things such as box models are handled and the like. This is to do with Quirks mode and not to do with benefits of XHTML strict over HTML strict.

That's also
why this list exists, because, from what I can see is that most of us need a
list like this so that we can deal with the bugs that are in the parsers and
rendering engines.

If you think that this list will deal with parsing and rendering bugs you are probably mistaken. You could probably discuss them and talk by all means but the real work gets done when you submit bug reports to bugzilla and the like.

But I'm also talking about working with bug free
parsers, even if that is in the future.In that case there is quite a bit
of difference with the way a parser will work with the same design in Strict
as it will in Transitional.

Considering that Internet Explorer are reported to have said that they didn't want to change the IE engine because it would 'break the WWW' and also considering that Mozilla even chose to *have* a quirks mode I think that you will see the existence of quirks mode for a long time to come.

But it makes no sense to use Transitional where Strict does
exactly the same job.

Reverse this statement and realise that it means nothing.

In particular, when served
as text/html rather than application/xhtml+xml, and when not mixing in
additional "X" technologies, for all intents and purposes XHTML is
simply HTML with a slightly funkier syntax (self-closing elements for
instance) which older browsers treat like broken HTML. There is no added
benefit to the user. All the things you mention (switching stylesheets
for different layouts, etc) can be done fine in transitional.

You are missing my point completely. Try maintaining or redesigning large
content sites that need to meet web and accessibility standards that are
caught in this dilemma.

I have seen some real messes in my short time and I know that HTML transitional can be just as accessible as XHTML strict. All the elements available to XHTML strict are available in HTML transitional. A perfectly validating XHTML strict document has just as much chance to be inaccessible as a HTML transitional.

Try creating an XHTML Strict document which validates and then convert it to a HTML document (by removing the forward slashes from self-closing elements) and then change the DTD to HTML transitional. Open both in a text only browser and compare them. If you see any differences then let me know.

I really see it as something
basic that web developers who take accessibility and web standards as their
core approach would understand that to redesign sites that meet valid strict
(either HTML or XHTML), are much easier to rework than Transitional.

Once again you are saying that a HTML transitional document can't contain all the same elements as an XHTML strict document.

Please explain why you would use a transitional DTD where a Strict one is
valid and works just as well?

As before, reverse the two subjects and see that the statement is still true:
"Please explain why you would use a Strict DTD where a transitional one is valid and works just as well?"

Paul Connolley
AccessPlanIT – LWDP Data Manager
Phone – 01524 389541, Email – [EMAIL PROTECTED]

The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help

Reply via email to