- From: Geoff Deering <gdeering@acslink.net.au>
- Date: Sun, 20 Jun 2004 09:54:03 +1000
- To: "Isofarro" <lists@isofarro.uklinux.net>
- Cc: <w3c-wai-ig@w3.org>
> -----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