views:

368

answers:

2

BACKGROUND: WYSIWYG HTML editors tend to be both "intuitive" and "smart". Intuitive means someone can reasonably edit HTML without knowing the inner guts of how HTML tags actually work. Smart means that the user does not have to worry about adding the HTML or HEAD or TITLE tags, because the editor does that for them.

PROBLEM: These days, you can no longer assume that someone editing HTML is actually working with a stand-alone HTML file. With content management systems, for example, someone may be editing HTML inside a TEXTAREA control of a web browser.

Moreover, the HTML in the textarea may not be a complete HTML document, but just a fragment of HTML where the HEAD and TITLE tags dont need to be supplied, because they are coming from within the content mangement system or somewhere else.

QUESTION: Is there a WYSIWYG HTML editor out there that is smart enough NOT to put HTML and HEAD and TITLE tags into an html fragment, for cases where the user is needing to supply only a fragment of the BODY of an html page?

+1  A: 

Not an answer to your question (I don't actually know an answer to your question), but a possible solution: after composing your page, could you drop into "code mode" and strip out the un-needed tags?

Or the corollary to that, copy/paste the "guts" that are needed?

Edit: Looks like I misunderstood the question initially, but maybe I can help ... I've had to use eWebEdit, and it sucks less than some others.

Adrien
Yes, the problem is I am not implementing the editor for myself, but for customers who do not want to even look at the raw HTML. These are non-technical people, which is why the concept of a WYSIWYG even comes up. If it were me, I simply would edit the raw html myself directly.
dreftymac
Sorry, I misunderstood the question, I think. Edited my answer to reflect this.
Adrien
+1  A: 

Any structure-aware SGML or XML editor can edit documents whose root is any element defined by the DTD. The DOCTYPE declaration at the start of the file declares which element the document is using as its root.

I use XMLMind XXE. It can edit XHTML at the div level or Docbook at the section or chapter level, for example. It can also be launched by WebStart or used as a component and embedded in a larger content management solution.

I've also used Framemaker to edit SGML.

Another approach I've used for several websites is to separate the content of each page from the navigation and branding around the content (what I call "chrome"). I edit the content as plain, unadorned, unstyled HTML and have a build process that uses an XSLT transform to extract the content of the body from the unadorned HTML, wrap the chrome around it and add CSS styles. When editing content, I can concentrate on the content itself and not care about styling and chrome.

I've done the same for dynamic content by serving it in XML format with an <?xml-stylesheet ...?> processing instruction and relying on client-side XSLT stylesheets to turn it into interactive HTML. However, that's something I've only tried on Intranet sites. Dealing with browser compatibility has put me off trying it on public websites.

Nat