Cleaning Up After WYSIWYG Editors
[<== Previous] | [Up] | [Next ==>]
TIP: If you must use a WYSIWYG editor, at least try
to clean up after it.
If you insist on using one of those "WYSIWYG" ("What You See Is What You Get"... though
what you see might well not be what users of other
systems or browsers might get)
editors that shield you from true HTML coding, you should know about some of the junk they tend to
insert into your documents. This stuff is very familiar to anyone who's
tried to clean up the mess left behind by running a web site through
one of those site-mangling editors.
In the main menu of this site, I refer to WYSIWYG editors as "not very well housebroken." This
implicit comparison of these programs to dogs is actually not particularly fair to the
canine population; in fact, dogs are quite fussy about where they poop, while WYSIWYG editors
don't appear to show this degree of discretion.
(The one exception I've found so far is Dreamweaver, which seems to leave your code alone
for the most part; thus, it's the best program to use if you insist on going "WYSIWYG", though
it's a bit pricey. Nevertheless, even Dreamweaver produces code
that sometimes makes me wince. At least it generally leaves alone any
hand-developed code instead of automatically re-parsing it into some ugly
mess, like the other programs do.)
Here are a few things to look for during such a cleanup job (using a
regular text editor, since the WYSIWYG editors can block the user from
seeing, and fixing, the HTML code itself).
Unnecessary Meta Tags
Watch out for inserted tags like:
<META HTTP-EQUIV="Content-type" CONTENT="text/html; charset=iso-8859-1">
Some of the WYSIWYG editors stick this at the start of each document.
What the above line means is "The character set for this document is ISO-8859-1."
Actually, this is the most common default character set anyway, and used
to be explicitly designated as such by HTML standards (and still is the official default
in the standards for the HTTP protocol). However, the HTML standards changed
as of version 4.0 (perhaps out of a "politically-correct" desire not to favor one language's characters
over another), so there actually is some use to this line.
Unfortunately, the addition of a "META charset" line causes
some browsers to clear the screen after loading the document and re-draw it (presumably in the
newly-set character set, same as the old one), producing an annoying flicker effect.
If you remove this line, you'll eliminate the flicker effect, but to be standards-compliant you still
should specify a character set. The proper place to do it is in the server-generated headers. Depending
on your system administrator's settings, you may or may not have the ability to control this; ask your
administrator for more details. On some systems, you can put a .htaccess file in each directory
to control the content type settings within that directory and its subdirectories. The specific details
depend on what server software is in use and what platform it's running on. Note that even if you don't
specify a character set, most browsers will do OK with a document in the standard ISO-8859-1 character set,
anyway. If you don't use characters above #127, the 7-bit range, an even wider range of browsers won't
have problems with it, since that part of the character set is the even older standard US-ASCII and is
generally common to pretty much all character sets now in use (barring EBCDIC and Commodore PET-ASCII).
You may also want to remove the META tags inserted by almost all editors
that advertise which editor was used. Do you really want to announce
to the world (or, at least, the HTML buffs who view the code of your
pages) that you use one of those goofy editors? (Actually, if you're
planning on giving your web pages to another web developer eventually
to fix up the mess your editor caused, leaving in this line may be
desirable so the other developer knows which particular
quirks to look out for!)
But do leave in the META tags giving descriptions and keywords for
search engines; see my description elsewhere.
Despite the importance of those tags, some editors may make it difficult
for you to insert them, while they go and insert all sorts of unnecessary
or even destructive tags themselves.
Useless Inserted Characters
Some editors will stick in all sorts of bizarre things that have no use,
and may even mess up your layouts in some browsers. For instance,
Netscape Navigator Gold likes to pepper your document with
That's a "non-breaking space," a special kind of space character that doesn't
word-wrap (and, though this isn't part of the official standard, also
doesn't generally collapse if more than one is used in a row, so it can
be used to add extra horizontal whitespace). Netscape's editor seems to
think very often that the user wants to have an extra non-breaking,
non-collapsing space, for instance at the end of each text line. Maybe
it first converts the carriage returns to spaces in its initial parsing
of the document, then decides that these need to be "hard spaces" and so
. That's the best I can figure out
the possible "thought process" it goes through, but the result is to stick
those silly, unnecessary characters all over the place. They make the
document bigger in disk space and transfer time than it needs to be, make
it harder to understand and maintain in a regular text editor with all this
extra junk in it, and on occasion, these extra spaces will even find their
way to a spot that screws up the layout, like at the beginning of a table
row making it fail to line up with the other rows.
You can go through your document and get rid of those funny space characters,
and then deal with the possible ruining of your layout if some
of them actually were necessary to make things line up.
Of course, a WYSIWYG editor might also insert worse than useless
characters, which violate character encoding standards; if your editor
inserts "curly quotes", em-dashes, or the ellipsis (...) character using 8-bit characters from the
proprietary Windows character set or bogus numeric references in the range from #128 to #159 (reserved
in the standards for control characters), then your document is in violation of the standards.
Useless Inserted Tags
Other wasteful things editors will insert include formatting tags applied
to empty spaces, like:
<CENTER><DIV ALIGN=CENTER><P ALIGN=CENTER><FONT
This whole big mess of code serves only to insert a blank paragraph
for vertical spacing, accomplishable via
All the other tags are useless. They're added because the editors are
so dumb that if you have stuff like font settings enabled they insist
on adding them even to blank spaces. The editors are also pretty dumb
about failing to collapse redundant tags. Even if the various
font changes above were actually needed to make sure that blank
space was rendered correctly, you could have done it with:
<P ALIGN=CENTER><FONT FACE="Arial,Helvetica" SIZE="+1"
Note how the three different centering tags were reduced to an attribute of
the single paragraph tag, and the three different font settings were made
into attributes of one FONT tag. This produces a shorter, cleaner, more
logical piece of code, showing the advantages of coding by hand instead
of using some silly editor!
WYSIWYG editors will also stick some weirdo oddball attributes into tags,
NATURALSIZEFLAG in the
This is not part of any HTML spec that I am aware of, is not used by any
browser that I know of, and I haven't the slightest idea what it means,
but some of those editors like to stick it in.
As was pointed out to me in e-mail from Stewart Gordon, if you do lots of copy-and-paste moves of
things that are part of hyperlinks, you might end up with the link split up. That is,
if you have
<a href="http://www.example.org/">This and That</a>, and paste
another word into the middle of the link text from a different hyperlinked phrase elsewhere in your page,
the editor might turn it into something like:
<a href="http://www.example.org/">This and</a><a href="http://www.example.net/">
The Other Thing</a><a href="http://www.example.org/"> and That</a>, with the link
split into three pieces that don't even all go to the same site. That happened
on this site, for instance.
Watch the syntax of the HTML tags generated by your editor. Many of them do improper
things like failing to put quotes around attribute values that require them (any that
include characters other than letters, numbers, and hyphens; for instance, "100%" and
"+1"), failing to properly nest blocks (you should use closing tags in the reverse
order of the opening tags), etc.
Sometimes some of the editors will insert code that works in one browser
but doesn't have the same effect on another. Microsoft FrontPage has the
tendency to produce code that's fine for MS Internet Explorer but not
so nice in Netscape. One example is how FrontPage will change all
centering tags to
<P ALIGN=CENTER> even
if you originally inserted them as
While, in most cases, using an ALIGN attribute is more logical and
elegant than the awkward CENTER tag, there are places where the only
reliable way to center something is to use
like for centering tables and form submission buttons. These aren't considered
part of a paragraph by Netscape (since a paragraph, by the HTML specs,
can contain only character-level content such as text or inline images),
so they won't be centered by
Internet Explorer seems to be rather more liberal in what it'll consider
to be part of a paragraph, and FrontPage follows this attitude by using
only the paragraph centering attribute even when editing a page that
was created using a different tag. The result is a page with some
elements not properly centered in Netscape, and every time you try to
fix it, FrontPage will "helpfully" keep changing it back.
If you don't watch out, your editor might insert links and graphics in the form
of hardcoded URLs of files on your hard disk instead of the proper relative URLs
that work on the actual web server. Look for such code as:
<IMG SRC="file://C|/www/sitefiles/mypic.GIF" WIDTH=200 HEIGHT=300
ALT="Picture of me">
All such URLs starting with "file:" are invalid for use on public web sites, since they
point at your local hard drive and nobody else has access to that but you. Editors will
tend to stick in such URLs quite often (sometimes using operating-system-specific characters
like backslashes instead of the proper forward slashes, making the syntax not even valid).
This is a hard error to track down as long as you're using a WYSIWYG editor to hide your
actual HTML code from you, and you're only viewing your site from your own system, on which
the hard-drive references work fine. You'll need to view your pages in a normal text editor
to see which URLs are screwed up and fix them.
Various editors have been reported to muck up URLs in other ways, such as stripping
trailing slashes from links to subdirectory indices... speaking of which, there's the
Inelegant Links Back To Home Page
Elsewhere I give reasons why you should link back to your main
home page with
<A HREF="./"> instead of explicitly naming
your index page (e.g.,
index.html), and similarly, to link to subdirectory
indices with the directory name instead of the explicit index filename. No WYSIWYG editor that
I've encountered yet does links in this manner; instead, they all seem to force these links
to be in the form of explicit filenames, and may even change your properly-formed directory-name
links to a hardcoded "index" reference without you knowing it.
By default, many WYSIWYG editors fill in sections of code that are useful to users in
"non-standard" browsing situations with un-helpful content. I'm referring to things
like the ALT text in images, and the NOFRAMES section of framed sites. These are useful
to users of older browsers, text-only browsers, text-readers for blind users, and, don't
forget, the search-engine indexing robots. The use of meaningful content in these sections
is important to the overall accessibility of your site, but too many users let these things
be filled in by their editors in a "default" manner. This results in the NOFRAMES section
saying nothing but "This site requires frames and your browser does not support them", and
the ALT text of images containing something pointless like the filename and byte size of
the image. See my sections on frames and images
to find out what you should be putting there.
Weird Filenames and Tangled Directory Structures
Since WYSIWYG editors let you add stuff to your site with a point-and-click interface,
they encourage you to pay little attention to your filenames and directory structures.
If you don't watch out, you'll wind up with a tangled mess with graphics scattered over
lots of different directories, filenames with random mixtures of uppercase and lowercase
letters, and other chaotic things you'd probably not do if you did it by hand.
(See my comments on directory structures.)
All WYSIWYG editors tend to use lots of tables for page layout. Some, most notably
NetObjects Fusion, go further and generate tables from hell, with enormous numbers
of rows and columns with specific, finely-set pixel widths and heights in order to (attempt to)
achieve a highly precise layout. The result, in addition to a site that is probably highly
sensitive to the user's browser version and screen width and unlikely to degrade well on
any "nonstandard" platform, is incredibly convoluted HTML code that's almost impossible
to maintain in any other manner than in the editor that created it in the first place. So
if you expect to ever switch editors or fine-tune your pages by hand, you
had better not start designing them in an editor that generates this sort of code.
Even in the less-Byzantine tables generated by a more "run-of-the-PageMill" editor, watch
out for bad style such as hardcoded table pixel widths that won't work well when users have
screen widths different from your own.
Lapses of Logic
Since WYSIWYG editors create HTML code based on the visual appearance
of the document rather than its logical structure (even though HTML
is a markup language intended to represent logical structure), it's likely
to fail to "get the point" of your document's structure and mark it up
logically. You may well end up with your main headers being marked up
with font sizes instead of
H1 and other header tags,
while other parts of your document may have non-header content marked
H tags because the editor decided that was the best way to
do a font effect. Your paragraphs may be broken with
<P>. The result may well look the
same as a logically-marked-up document (at least in the browser versions
the editor is coding for), but text-mode browsers, blind speech readers,
search engine robots, and other programs that try to interpret your logical
structure in a manner other than the graphical rendering you're used to,
are likely to get lost. (For instance, the content of your
header is often weighted heavily in search-engine indexing, while the same header
marked up merely with a font size will probably be treated as much-less-important
Screwed-Up Rearrangements of Your Own Prior Lapses of Logic
If a page has incorrect HTML syntax to begin with, an editor can really make a mess of it. Whether this bad syntax was inserted by another editor, was created through a careless error on your part (or by an
earlier developer working on the site), or was done on purpose to achieve some presentational
effect (on some browsers), it might "not compute" to the new editor you're using, which will
then apply its own error-correction rules. This may produce a nonfunctional page. In
particular, incorrect tag nesting can produce totally messed-up sites after running through
an editor. For instance:
<FORM METHOD="post" ACTION="https://www.dan.info/cgi-bin/form.pl">
Your Name:</TD> <TD><INPUT TYPE="text" NAME="Name"></TD></TR>
<TR><TD>Your E-Mail Address:</TD> <TD><INPUT TYPE="text" NAME="Email">
The above code is illegal, because the FORM element begins within one table cell and ends
within another. Some editors will take this code and move the closing tag for the form
to the first cell, and the input fields in other cells will not be submitted with the form,
causing lost data. The solution is to move the opening and closing tags of the form
outside the table altogether. Unfortunately, this doesn't permit you to
have several forms at different points in the table if they each extend across multiple
I really can't blame the editors for making a mess of HTML code that's invalid
to begin with. Be more careful about the code you create, and you won't have as many
worries about it causing problems for any editor you might eventually use.
(Some editors have been known to even crash or hang when given particularly messed-up
HTML syntax. This at least has the virtue of not leading the author to think everything
is fine when in fact the page has been hopelessly messed up.)
Stuff Pasted In from Other Places
(suggested by Stewart Gordon)
One thing a lot of programs that generate HTML do is try to preserve every last detail of the formatting
of anything you might paste in from somewhere else, like another Web page, a word-processing or desktop-publishing
document, a spreasheet, and so on. The stuff in the "copy" buffer might have grotesquely-complex underlying code
created by some other program (even if it looks simple on the screen), and that tends to get preserved, or even
complexified further, by the editor program you paste it into. It's aiming to keep the content you're pasting looking
exactly like it did in the original program, but perhaps you didn't really need this; maybe you just wanted the text
content. The preserved formatting might even detract from the content by causing it not to match the other content
of the site you're creating.
You can defeat this by copying and pasting into a plain-text editor (e.g., Notepad or UltraEdit) and then copying
and pasting from there into the web editor, but then you lose all the formatting, even simple stuff
like bold or italics.
Some Other Notes
WARNING: The "Save As" feature in MSIE, if used with the "Web Page, Complete"
option, does a lot of the same bogus stuff to the HTML code that WYSIWYG editors do,
including "correcting" bad syntax in ways that might render the page inoperable. It
also puts all the graphics for each page in their own subdirectories (possibly creating
many copies of a single graphic that's used in multiple places), and defaults to using
really messy filenames taken from the page titles which usually have characters like
spaces in them which are illegal in URLs. So don't use this feature to retrieve Web
pages you want to edit and re-upload to the server; use FTP instead, or use "Save-As"
with "Web Page, HTML Only" selected (which doesn't mess with your syntax) and
right-click on each graphic individually to save it.
So, do you really want to use those editors? They may
seem to be saving you some time when you're first starting to set up a
site, but in the long run, you'll be spending a lot more time fixing
up the problems they cause.
NOTE: If you decide to edit your pages using a plain text editor, it doesn't
have to be Windows Notepad, which is rather primitive and limited. You can
get a good text editor that handles large files, highlights syntax elements in different
colors, does global replaces across multiple files, and has other useful features.
There are several such editors; lately, I've been using UltraEdit
and like it very much.
Here are some of the specific things I know about that certain individual
- Generates Tables From Hell to (attempt to) achieve
- Is, in fact, incapable of generating pages that aren't all contained in a big table,
with an absolute pixel width. You can't make your pages resize gracefully
to different screen widths, even if you're aware of this issue!
- Uses its own bizarre directory structure full of weird filenames, and offers no
option to override it with your own desired structure.
- Sticks in lots of blank spacer graphics all over the place and doesn't have the
decency to put an empty
ALT="" attribute so they're suppressed in text-mode browsers
like Lynx, leading to "
[INLINE][INLINE][INLINE]" all over the place.
- Does a really lousy job of letting you import or export web pages between NOF and
other editing programs, even though their marketing hype claims you can. Pages imported
from another editor will have their HTML code screwed around with so it probably doesn't
function as originally intended. Pages exported to another editor will make that editor
go through conniptions trying to render the convoluted table structures NOF creates.
- Doesn't use logical, structured HTML elements; when you choose a Level 1 Header,
it doesn't use
<H1> as is logical, but a
tag instead. When you choose a block quote, it gets rendered not by the proper
BLOCKQUOTE element, but by a misused
UL tag. The
creators of NOF go way beyond the call of duty in avoiding any semblance of logicality in
their tag usage. (See my discussion of physical and logical tags.)
- While it has a pretty neat feature called "stacked pages" that lets you generate a whole
bunch of pages from a database file (e.g., a list of your products you want to create
web pages about), it fails to provide any method of getting decent titles
on the pages. By default, they all say "Untitled Stacked Page," a pretty stupid title. If
you tweak a few settings, you can make it put something else, but whatever you do gets
replicated on all the stacked pages of the set; there's no way to get individual titles for
the pages (like by making one of the database fields be the title). This is pretty rotten
for search-engine indexability.
Netscape Navigator Gold / Communicator:
- Loves to add extra characters, especially at the end of lines, in some cases
messing up your formatting.
- Doesn't put the required quotes around attributes like
- When you save a site, by default it copies all the graphics into
the same directory you saved the page, even if they were originally in other
directories or even on other servers, and change the
IMG SRC references accordingly.
Thus, if the site had the graphics neatly placed in a separate directory to begin with,
once this editor got hold of it they'll end up strewn all over the place in all the
directories you ever edited HTML files in. You can wind up with lots of copies of the
same graphic wasting space on your server.
Even CGI-generated graphics like counters tend to get changed into static graphics by
- If you choose to "maintain links" when you start editing a site, it changes them all
to absolute instead of relative
URLs, regardless of how you'd like to keep them.
Microsoft Front Page:
- Will change your
CENTER tags to
whether you like it or not, and even in circumstances where the latter won't work in some
- Loves to insert its weird "PageBot" elements all over the place, and add in features
that only work if your provider's server has FrontPage extensions installed.
- Like all Microsoft products, it doesn't mind using nonstandard characters like
so-called "smart quotes" that aren't part of the official standard character set, and might
show up as something weird on a non-Windows system.
- Still, it does seem to be making at least a half-hearted attempt to create logically structured HTML, which
is better than most WYSIWYG editors, and the latest version gives you a mode where you can
edit the raw HTML (though, in some cases, Front Page will change it back to its own desired
- ...At least, I thought it attempted to keep your HTML logical... recently, somebody asked me to find
out the cause of a Front Page-generated web page being completely empty when viewed in
Netscape, and when I viewed the source, it turned out that it had the closing
tag of a table before the opening
<TABLE> tag, so that it
was closing a table that hadn't opened yet, and then never actually closing the real table
once it started. Netscape can't cope with that sort of bogus code, though Microsoft Internet
Explorer is somewhat more tolerant. The author swears that the code is exactly as
Front Page generated it and he didn't mess around with it using any other program, though
I have trouble believing that even Microsoft would generate HTML this bad.
- WARNING: DON'T create FrontPage webs in the root directory
of your hard disk... if you use FrontPage later to delete them, it could wipe out your entire
hard disk! This bug has been acknowledged by Microsoft... FrontPage treats the entire directory
you place web documents in as being part of that web site, and so will delete everything there
if you delete them within Front Page. This means that if you use your system root as the
place to put your files, everything will get wiped out (including subdirectories,
hidden and system files, etc.) if you remove it!
Front Page Express
- Does a lot of the same stuff as the full-fledged Front Page.
- If you have a
<basefont> tag, it replaces it with a
<font> tag for
- When creating a link, it insists on closing all character formatting
tags and then reopening them inside the link.
- Like Net Objects Fusion, this is another program that goes for the "Tables
From Hell" approach to page layout, producing messy, convoluted code that's very difficult
to work with outside the program.
- It puts in the
<HEAD> section the following line:
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
What this is saying is that the Windows character set is being used (or, at least, version 1252
of it; I'm not sure what other Windows character sets exist). At least this program is honest
about that, unlike some other Microsoft software which blithely uses the nonstandard Windows
characters like so-called "smart quotes" and then sticks in an ISO-8859-1 character set identifier
to claim to be using the standard character set. However, the use of platform-specific
character sets is a bad idea when the ISO and Unicode standards exist to represent special
characters in a manner understandable across the net.
- The sites I've seen generated with MS Publisher are notable for their complete absence
of ALT text in images and imagemaps. I don't know whether MS Publisher fails to provide a
means of putting these attributes in, or if the users are just not bothering to do it.
- One user reports that this program converts all your JPEGs to GIFs, and he couldn't
find any way to override that. This is the only web editor I know of that messes around
with the user's graphic files (other than renaming them and moving them to different
directories, which several other editors do).
- In some circumstances, it will convert an entire block of text into a big graphic!
- It seems to like to needlessly create imagemaps out of images you want to make into
links; if an entire image is used as a link, a simple
<A HREF> tag
surrounding it is the logical way to do it, but Publisher would rather create an imagemap,
a less-elegant method with reduced browser compatibility.
Microsoft Office 2000:
- Saves documents in its own bizarre pseudo-XML / pseudo-HTML format that doesn't
correctly follow the standards of either XML or HTML. No DOCTYPE is included,
HTML tag has proprietary attributes that seem to be an attempt
to identify the document format in place of the DOCTYPE (making use of "URNs",
a format for stable document addresses that's been proposed for years but never
standardized; this seems to be a Microsoft-specific adaptation of them),
and some "kinda-sorta-XML" content is embedded within an HTML comment declaration
to encode various MS-specific attributes.
- This all appears to be an attempt (typical for Microsoft) to produce documents
that are "best used in" Microsoft products, embedding tons of proprietary "features"
that don't work on anybody else's software, instead of producing portable, standardized
- Produces really bloated code, with lots of repeated inline style elements that
would be better off placed in an external stylesheet.
- Tends to use hardcoded point sizes for fonts, which refuse to scale in MSIE to reflect
user preferences. Hence, ironically, the pages are "best viewed in Netscape" (or other
competing browsers) if you have difficulty reading small text and wish to enlarge it.
- If you filter out rows in Excel, they still get saved to the HTML document, marked as
hidden. This is one more cause of bloated document size, as well as possibly letting you
make sensitive information public without realizing it -- somebody with a browser that doesn't
recognize the "hidden" property, or anyone who views the source of the document, can see all
of the hidden stuff.
Serif PagePlus 11
(Reviewed by Stewart Gordon)
- Like NetObjects Fusion, it is incapable of creating pages that don't have
a hard-coded pixel width.
- However, rather than Tables From Hell, it uses DIVs From Hell. If the text zoom is increased (in a
browser that correctly scales point sizes), the DIVs end up overlapping
- Like NOF, it has an aversion to logical HTML tags, instead using DIV and
SPAN almost exclusively. It even eschews table markup, using DIVs to mark
up tables instead.
- If an image is inserted, it will copy it into the folder where the pages
are published. There appears to be no way to tell it to leave them where
they are. Although the Import Picture dialog box gives the option of "Embed
picture" or "Link picture", it appears to have no effect.
- The documentation claims that it converts all PNG images to JPEGs. In
fact, it gives the option of leaving all images (GIF, JPEG and PNG alike) in
their original format or converting them all to any of these formats. Like
many programs, it will often mangle the names of image files in the process.
- There appears to be no way of setting an image's ALT attribute. It will
just set it to the filename of the image, be it the original name or one of
its auto-generated names. It also puts title="" on all images for no
- Like MS Office, it inflicts a fixed point size on all text. The "Force
absolute text size" option in the web site properties appears to have no
effect except to cause it to specify the size in pixels instead of points.
- The user interface is confusing in a few ways. It took me a while to
figure why I couldn't get my text to word-wrap, until I realised that I was
using the Artistic Text tool (represented by a letter A), when I should have
been using the Standard Frame tool. If no text is selected, then the Insert
Hyperlink command is enabled and displays a dialog box, but only when you OK
it do you find out that it has had no effect.
Serif Weblus 10
(Reviewed by Stewart Gordon)
- Does many of the same things as PagePlus, including generating pages that
fail to scale gracefully to different window widths and font size settings.
- Will often change a block of text into an image.
- If it decides that the text in a block is too big to fit the block's
dimensions, it will silently truncate the text.
- While it has an otherwise neat feature, a facility for creating navigation
bars, it is fundamentally flawed in that there is no way to get sane ALT
attributes on the images it generates. It seems capable only of
mislabelling them as purely decorative images.
- Will often generate many copies of the same images, e.g. in the
aforementioned navigation bars, wasting server space and bandwidth.
- Another problem with the navigation bar facility is that it generates
- Sites can come out rather messy if viewed with CSS disabled or in a
non-graphical user agent, with blocks of text appearing out of
- Generally a pretty good editor, which leaves your HTML code alone and doesn't introduce
bizarre code of its own. It's the best choice if you insist on having a WYSIWYG editor.
However, some versions are apparently intolerant of unknown character entities (including numeric
characters past #255, which in the latest HTML standard represent Unicode characters from
various specialized and foreign character sets), and change them to something else when
they are encountered.
- Apparently, each new release gets a little worse in the area of leaving HTML
code alone, as they're falling prey to the same mindset of the rest of the software
world, of making the software do everything for the user, presumed to be too stupid to do
anything right themselves. As a result, newer versions do sometimes muck with your code
and change or insert silly stuff you didn't want.
Make your site better by looking at other sites that show, by example, what
not to do!
NOTE: The inclusion of a site in my "Hall of Shame" links should not
be construed as any sort of personal attack on the site's creator, who may be a really great
person, or even an attack on the linked Web site as a whole, which may be a source of
really great information and/or entertainment. Rather, it is simply to highlight specific
features (intentional or accidental) of the linked sites which cause problems that could
have been avoided by better design. If you find one of your sites is linked here,
don't get offended; improve your site so that I'll have to take down the link!
- NoIDNoSale is symptomatic of a whole heap of sites created under
a particularly bad misfeature of FrontPage; under certain configuration settings, that awful program generates
a heap of silly code with proprietary "conditional comments" so that under MSIE the site renders normally, but under
other browsers it shows up as a horrendous heap of text-as-graphics that actually looks worse than normal
plain text, and has hyperlinks that don't work. This seems to be a sinister Microsoft conspiracy to make other
browsers look bad, when it's actually MS's own fault.
- My review of Net Objects Fusion (Epinions)
- Macromedia, makers of DreamWeaver.
- Microsoft FrontPage
- Demoroniser -- corrects some of the errors
introduced into HTML documents saved by Microsoft products.
- HTML Tidy -- A program from the W3 Consortium
to clean up messy HTML code.
- GOHTM -- an online service that converts various
file formats to HTML. I haven't yet tested it to see how good the quality of the HTML is.
- XStandard is an editor designed to plug into content management systems;
its creators claim it produces standards-compliant code.
See this page as it looks after being run through different editors!
[<== Previous] | [Up] | [Next ==>]
This page was first created 29 Nov 1997, and was last modified 10 Mar 2012.
Copyright © 1997-2018 by Daniel R. Tobias. All rights reserved.