RE: NVU, child of Mozilla Composer (Windows & Linux)

> -----Original Message-----
> From: Isofarro >
>
> Geoff Deering wrote:
>
> > I don't know about the rest of you on this list, but I'm really
> disappointed
> > with the quality of WYSIWYG based editors and the markup they
> generate.  I
> > don't understand why it is so bad.  I'm disappointed in most of
> our tools
> > actually.
>
> I'm disappointed when I see a wysiwyg editor that has toolbar buttons
> for bold, italic, colour, text alignment, font size and font selection.
> IMO, it ignores the concepts of structured markup. The positive side is
> that people find them easy to use, because they can relate it to word
> processing.

Yes, I agree with this too.  What I feel all the developers are overlooking
is a sense of good engineering architecture to allow a tool to be
customisable.  This would allow standard users to use their tools of choice,
but another set of toolbars and rendering engine would be engaged when
someone wanted to work in Strict/Transitional/HTML4 or XHTML.  So the tool
becomes very flexible, and does not make old dedicated users to quirks mode
upgrade if they can't justify going that way.

This is where I am REALLY disappointed in Macromedia (and many others).  I
don't believe that they have done such a poor job on the rendering and code
generation engine that they are stuck with the legacy of quirk mode, and
having to clean that up if you want standards based code.  Using DW, even
that latest versions, that is the feeling I get.  They had the ability to
produce different code bases for IE & Netscape back in the late 90s, so
their engine was abstracted to a certain level, but why not now, with all
the feedback and input from this community?

If you haven't built your rendering engine on a level of abstraction that
follows good design abstraction to identify generating code to various
specifications, you have made a VERY big mistake at the design phase of the
software architecture.  This seems to be the problem with many authoring
tools and user agents.  Even in the early stages, they should have done
this, but they didn't, now everything becomes a hack.

Many of the user agent engines have fix this to varying degrees, and they
would need an abstraction layer in their software architecture to be able to
deal with rendering various DTDs, DOM, etc.  But I don't think we have seen
this in authoring tools, to any level, at all.

From what I see in DW it doesn't really do this, it just tends to best guess
and try and clean up the code, but you are left with pseudo standards code,
nothing anyone here would be really satisfied with if not tweaked (my
assumption).

What they should have done is kept their standard way of working, to keep
their main client base, but build a completely different set of toolbars and
rendering engine into the application that could be switched to at the ease
of a preference setting; 1) Strict XHTML 2) Transitional XHTML 3) Strict
HTML4 4) Transitional HTML4 5) Quirks Mode... whatever.  So the user chooses
the way the tool works and how it generates code.  Then it would become a
very flexible tool.

When I look at DW, and when people say that it conforms with Standards and
aids accessibility, it appears to me you still have to have that knowledge
in order to be able to use it to accomplish those ends.  It is not going to
help the novice designer feel they can use such a tools and it will produce
the level of code that is required to meet standards and accessibility,
without a knowledge of quality code.

These are the things I feel NVU need to address, and as Steven Dale said, it
is / can be a problem when they are working from the original code base.  It
does mean that they do have to go back and re-engineer the rendering engine
in order to target the code generation for each specific DOCTYPE.

> Once in a while I have a look at web-based / javascript wysiwyg editors,
> and the one's I've seen all go down this visual-orientated approach.
>
> I have thought of trying to write a structure-focused wysiwyg editor -
> offering buttons for paragraph, headings, lists, and generic containers
> with classes. But I can't visualise a UI that makes as good sense as the
> above-mentioned tools.

Yes, but those type of Toolbars do make sense to standards based developers.
Maybe as I have mentioned above, the need is for a selection of toolbars and
approaches.

> The drawback, I feel, is that it requires a knowledge of HTML (well,
> structured markup techniques) to be able to produce good markup from a
> wysiwyg.

It sure does.

> Is it even possible to create a structured-orientated editor that's as
> easy to use as a visual-based wysiwyg? The more I think about it the
> more Wiki-style syntax is preferable.

I don't know.  I'm looking at XML editors are present, and none of them I
think are ready for the mainstream, even as WYSIWYG XHTML editors.  XMLSpy
is too complicated for a standards users.  I'm try to work with Docbook in a
few other editors, and do hope that OpenOffice 2.x shows much more ability
to easy integrate with the XML world.  It's getting there, but the HTML
writer is just another sign of where application developers think the world
of markup is:-((

Geoff

Received on Saturday, 19 June 2004 20:04:29 UTC