> Patrick H. Lauke wrote:
> I think what Andy meant (as I've got a feeling he's well in the know
> when it comes to css and separation of content and presentation) is what
> the advantages are if you can effectively write strict code while still
> declaring a transitional doctype. Yes, transitional doesn't make certain
> elements illegal, but that doesn't mean that developers can't do nicely
> separated content/HTML and presentation/CSS which happen to have a
> transitional doctype. 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.  There are differences to the way a rendering
parsing engine will work with the different doctypes.  Just as a C
programmer thinks "what will the compiler do with this code", there needs to
be some understanding of what is happening at the parser level.  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.  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.  If we fail to understand that we are failing to
understand what is happening with DOCTYPE parsing and rendering.

I can understand why you'd use Transitional, where you could use Strict, ie
where there may be a lack of browser support for a particular design
implemented in Strict, but not supported properly, so you'd use
Transitional.  But it makes no sense to use Transitional where Strict does
exactly the same job.

> 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'm surprised both of you, who have more knowledge than I do in the design
area, have not come across this very problem.  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.

And it has very little to do with the deprecated elements.  The real lose is
the attributes for elements found in both DTDs, which are not part of
Strict, because they are presentational by nature.

> XHTML (and strict in particular) being more accessible than HTML (and
> particularly transitional) is a myth. Conscientious coders can use
> exactly the same approach (tableless etc) in both.
> 

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

Regards,
Geoff Deering

******************************************************
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