That is a misconception. There are differences to the way a rendering parsing engine will work with the different doctypes.
Ok, let's narrow down the field to the core issue: what are the rendering differences between XHTML1.0 Transitional and XTHML1.0 Strict?
Ok, now the clincher: provided that these differences are not show stoppers (i.e. all of a sudden a browser trying to render XHTML1.0 Transitional makes everything disappear, overlap, scale down to infinitesimal size, etc), how are they having a majorly detrimental effect on accessibility?
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
Not talking design (as in visual design), but features relating to the markup/content itself (i.e. the start attribute on OL).
But it makes no sense to use Transitional where Strict does exactly the same job.
In certain edge cases (like this one we're discussing) I think it does indeed make sense. By dropping "start" you are losing semantic information.
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 do. Did a redesign on a fairly large University site and rolled out the first phase as XHTML1.0 Transitional, and only later moved to Strict once the legacy systems were changed to spit out clean markup. Most of the web authors across the University are still using my Transitional template (for various reasons - mainly them having their own legacy systems to contend with). No problems in maintenance (over 1 1/2 years now) and no reports of accessibility problems on the grounds of my DOCTYPE choice.
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.
If we're talking purely from a visual layout point of view, of course settling for Strict is the only way to fly. However, this discussion revolves around the accessibility. I still haven't seen any evidence that Transitional (which, granted, can have subtle differences in its *visual* rendering) is less accessible than Strict (all other things being equal, i.e. tableless layout, no use of deprecated or presentational elements, etc). There's no killer feature in Strict which instantly makes it more accessible. Nada.
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.
Again, just because the attributes are in the DTD, doesn't mean that I have to use them. I can write Transitional avoiding all the presentational attributes, and it's still Transitional if I so declare it. The main point is that there are a few things (like the "start" attribute) which have been thrown out of the window in Strict which are *not* presentational. Yes, in the utopian world of W3C standards, CSS will take care of things like numbering. However, for accessibility reasons, the page still needs to make sense without stylesheets...so, in actual fact (and bringing it down to the concrete example again) using <ol> without start and relying on CSS in Strict is *less* accessible than using <ol start="..."> in Transitional.
Please explain why you would use a transitional DTD where a Strict one is valid and works just as well?
That's the point: in this instance, it does NOT work just as well.
-- Patrick H. Lauke _____________________________________________________ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com ****************************************************** The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help ******************************************************
