- From: Bailey, Bruce <Bruce_Bailey@ed.gov>
- Date: Tue, 16 Jan 2001 13:57:27 -0500
- To: "'Ben Canning'" <bencan@microsoft.com>
- Cc: "'w3c-wai-ig@w3.org'" <w3c-wai-ig@w3.org>
Ben, I too wanted to express my gratitude for your attention and contribution to this thread. The problem with omitting (or getting wrong) the doctype in FP2K is similar to the issues caused by posting invalid html. Yes, browsers are suppose to recover from these types of errors, but it is quite amateurish for an author to rely on this. It is pretty unexcusable for an automated tool to facilitate faults! We are quite intolerant of syntax errors in C and even PDF and Word documents. Why is HTML an exception to this rule? Early version of FP caused problems with Netscape because the doctype was misleading and inaccurate. Telling a lie with the doctype is at least as much a sin as omitting it! When MS became aware of the bug, rather than fixing it by producing valid HTML, MS chose to remove the doctype altogether. Very pragmatic, but not very comforting! In short: (1) FP should provide an easy mechanism for including a doctype (modifying the normal template doesn't count as "easy"). (2) FP should provide validation based on the doctype. (3) If the user insists on using deprecated code, FP should provide a warning and remove the doctype. Personally, I think there is a huge untapped market for a "WYSIWYG" html authoring package that doesn't pretend to do page layout. It would produce only valid HTML 4.01 strict. If a user wanted fonts, they would have to do this via style sheets. There would be no "indent" button (or it would be tied to CSS). Clicking the large "B" button would produce <em> and not <b>. There would NOT be a button for underlining. Your average home user doesn't care about valid html or accessibility. I would argue that the average site manager does. He (or she) doesn't want (or more likely, can't) to clean up after all the dozens of people that are trying to post content on his site. A tool that, by default, produced clean code without requiring users to know HTML would be most welcomed. FP and DreamWeaver impose barriers to writing valid and/or accessible code. BBedit and HomeSite are better, but they pretty much require one to know and understand HTML. Amaya has a very awkward UI. To summarize, there are NO easy tools for producing formally valid HTML -- even for simple straight forward documents. The other accessibility problem I know of with FP2K is image maps. The UI provides no mechanism for putting ALT text on the hot spots. I haven't tried this, but does FP do frames? If so, what does it do for the frame labels and the noframes section? Thanks again. Sincerely, Bruce Bailey ED OCIO Assistive Technology Team
Received on Tuesday, 16 January 2001 13:57:58 UTC