[Irl-dean] Opinions: HTML Transitional and WCAG Double-A

[Joshue O Connor]

>> The only element that is still widely used in the transitional DTD
>> > that isn't in the strict DTD is APPLET, but that can be implemented
>> > using OBJECT. There are lots of deprecated elements, such as DIR,
>> > MENU, FONT, etc., but these are not so common, and fail other
>> > checkpoints (such as 3.3: use style sheets to control layout and
>> > presentation, and 3.6: mark up lists and list items properly). Most of
>> > the attributes that have been deprecated either belong to deprecated
>> > elements (such as alt for applet), or are presentational (align,
>> > valign, bgcolor, etc.). The only exceptions to this are language
>> > (script), start (ol), value (li), and version (html).
> 
> Thanks Gez - that's very helpful.

It is very helpful!

So have we reached a con census? Can we say it is better to recommend
use of an HTML strict doc type for most web development tasks? Or as
Eoin suggested some doc type switching within a web application as
needed? What about strict doc types for XHTML? Will using a strict doc
type for either HTML and XHTML have a negative impact on legacy user
agents or if we recommend to other developers to use strict DTD's for
either markup languages will it in fact be the push they need to
_really_ separate content/presentation/behaviour?

>  On the other
>   hand ... support for these CSS features has historically been
>   fairly "mixed"

To say the least. Consider that the CSS1 specification was published in
1997 and Microsoft have only now with IE 7 started to support much of it
- properly.

Josh

********************************************************************

NOTICE: The information contained in this email and any attachments 
is confidential and may be privileged.  If you are not the intended 
recipient you should not use, disclose, distribute or copy any of 
the content of it or of any attachment; you are requested to notify 
the sender immediately of your receipt of the email and then to 
delete it and any attachments from your system.

NCBI endeavours to ensure that emails and any attachments generated 
by its staff are free from viruses or other contaminants.  However, 
it cannot accept any responsibility for any such which are 
transmitted.  We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email 
and any attachments are those of the author and do not necessarily 
represent the views of NCBI


********************************************************************