RE: Fw: Disturbing trend in tables

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