Oh yeah, your talking only about frontpage ;)

Anyhow, anyone who thinks taht wysiswyg or vi is the answer is old-skool
anyhow.  The real direction to go is to take design as far away from
content.  :)  CSS is one step to that, taking content *out of * html is
also good.

* ^chewie <chewie at wookimus.net> [000908 12:10]:
> On WYSIWYG...
> 
> Pro's
>     * Environment similar to WYSIWYG word processors
>     * Able to view the page as you're creating it
> 
> Con's
>     * You don't learn anything about the structuring of the underlying
>         markup.
>     * The markup the WYSIWYG generates is often filled with bugs and
>         bad assumptions, and is not often formatted for viewing by
>         standard text editors (i.e. standard tab stops or no stops,
>         good formatting, and less than 80 columns -- no long lines).
>     * Very few WYSIWYG's actually use advanced tools such as Cascading
>         Style Sheets (CSS), and in effect, litter the HTML markup with
>         unnecessary tags and options.
>     * Adding HTML markup not standard with the WYSIWYG functionality
>         is often a pain to use, a pain to edit, and a pain to view.
>     * Most WYSIWYG's use key bindings similar to environments designed
>         for point-n-click interface, which may be fine for the average
>         joe user, but for those who are more comfortable with a
>         keyboard than a mouse, it's a pain in the ass.
> 
>         In other words, I WANT MY VI BINDINGS!
> 
> <rant>
> Main arguments against WYSIWYG's...
> 
> The most common application of WYSIWYG's, such as document editors,
> whether it be Word format or HTML, is that they assume you are
> creating ad hoc documents or "one-timers."  The problem with this
> assumption is that businesses use these applications to run their
> business and formal processes, processes that use a standard form or
> set of forms for their everyday practices.
> 
> I hold this statement to be truth in all cases: "If you use a form
> (letter, report, memo, etc) more than three times, or if more than two
> people need to use the form, it should be formalized and controlled."
> The best way to do so is to create an on-line forms application, a web
> application.
> 
> The con to this is that when people have WYSIWYG's to their disposal,
> "one-timers" or "one-offs" begin to perpetuate.  Soon, you've got 8
> flavors of a given form floating around the office.  You don't know
> who controls it, where it came from, or what you're supposed to do
> with each version.  Then you run into the problem of compatibility;
> not everyone uses the same tools all of the time...
> 
> If you can't tell, this is a problem that I'm running into at work at
> the moment.  I can't stress enough the importance of creating
> client-independent web-based forms applications for ANY formal
> business process or policy that gets used on a regular basis.  
> 
> Anyway, </rant>.
> 
> -- 
>   Chad "^chewie, gunnarr" Walstrom <chewie at wookimus.net>
>               http://wookimus.net/chewie


> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tclug-list-unsubscribe at mn-linux.org
> For additional commands, e-mail: tclug-list-help at mn-linux.org

-- 
Scott Dier <dieman at ringworld.org> #nicnac at efnet 
http://www.ringworld.org/  finger:dieman at destiny.ringworld.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 233 bytes
Desc: not available
Url : http://shadowknight.real-time.com/pipermail/tclug-list/attachments/20000908/70a1c463/attachment.pgp
-------------- next part --------------
---------------------------------------------------------------------
To unsubscribe, e-mail: tclug-list-unsubscribe at mn-linux.org
For additional commands, e-mail: tclug-list-help at mn-linux.org