CTS logo
hazy blue Catskill Mountains in distance


Give our new Discussions area a try!

PDF::Builder v3.024 Released, 12 September 2022
   Please see the CPAN listing, GitHub entry.

PDF::Table v1.003 Released, 05 July 2022
   Please see the CPAN listing, as well as the GitHub entry.

A Thought…

If you live long enough, you’ll see that every victory turns into a defeat.

   — Simone de Beauvoir

Intelligent WYSIWYG

Posted on 2017-Dec-29 at 10:31:57 by Phil

I would like to start a discussion about WYSIWYG (What You See Is What You Get) editing with more “intelligence” to it. Currently, the problem with offering WYSIWYG editing to the unwashed masses is that they have no idea how to use it. For example, I once had a page where an HTML file was embedded to allow the site owner to update the content themselves. No problem, right? Well, it included an ordered list <ol> with 4 items, and the site owner wanted to add a new item 5 to the end, using something like FrontPage. What did they do? Create a new paragraph, type in bold 5., type in the text, and complain that the new item didn’t left align with the rest of the list!

The problem here is that the site owner, like probably 99% of all owners, didn’t know squat about HTML, and the WYSIWYG editor they used didn’t enforce any restrictions. If they wanted to extend an ordered list, the editor should guide them into adding a new list item <li> rather than allowing them to do just anything. I could envision an editor where the cursor is over the ordered list, and the background changes slightly and there is a pop-up telling the user that they are over an ordered list — would they like to change, move, delete, or add an item? It would not permit (at least, not without a lot of pain and confirmation messages) them to add a paragraph at an arbitrary location. If they were within a list item at this point, they would be reminded that they are creating a paragraph within that list item, rather than adding a new item.

Of course, lots of people don’t pay attention to notices and warning signs. it’s still possible that somehow they will force a paragraph for a new item 5, so it needs to be possible to 1) warn them that they may be breaking the structure, and 2) make it easy to correct their mistake, by turning the paragraph into a <li>. We should probably leave responsibility for deleting the hard-coded item number to the person doing the editing.

Is it feasible to enforce (or at least, firmly guide) having compatible markup so that list structures, etc. can be maintained? The editor would have to know where they are on the page, and within what control structures, to know what things are allowed. It should be possible, at least with some annoyance and pain, to do almost arbitrary things, such as splitting a list item into paragraphs. That’s legitimate, but it should not be easy to accidentally do that when the intent is to add a new list item, for example. Remember — most people editing a page will have no idea what the underlying HTML structure is.

Posted on 2017-Dec-29 at 10:41:57 by Phil

Another issue with WYSIWYG is CSS and styling. Today, the proper way to style a page is with CSS, and the WYSIWYG editor should be aware of what CSS is in use for this page, and style it (during editing) appropriately. That is, someone editing a page should see exactly what will appear in a browser, rather than having a surprisingly different look to it once they save and display the page! Most WYSIWYG editors were conceived back before CSS became a major factor in display appearance, and don’t do a good job of showing just how it will look with CSS applied.

This also brings up the point of whether (and how) an editor should add or change CSS. If you are editing a page, and decide that there should be a little more top margin on a list item, should that be local CSS for this page (which could end up being just a fragment of a larger page), or should it be global (changing CSS files)? You don’t want a person editing a page to use HTML markup (blank lines, font changes, etc.) to style the page, especially if different CSS might be applied to it later. You also don’t want the editor to clutter up the page with lots of superfluous font changes, etc., to get the styling effect you want. The HTML and CSS should be taken together to ensure that What You See during editing is really What You Get when the page is viewed in a browser.

Posted on 2017-Dec-29 at 11:17:04 by Phil

Visibly marking the (possibly nested) areas of text that the cursor is over would help immensely with that constant irritant of WYSIWYG editors: not knowing exactly where an effect such as bold begins and ends. I can’t tell you how many times I have wanted to insert some normal text right after a bold word, and have ended up having the new text also bold, because I had positioned the cursor a few pixels too far to the left!

This brings up something else that an editor should always do: toggle easily between WYSIWYG editing and markup (tagged) editing, so that you can do things which may be very complex in WYSIWYG, but easy if you can see the tags. It also permits easy adjustment and changing of tags entered in WYSIWYG mode, to fine tune the edit. So many times have I been forced to use a WYSIWYG-only editor, and found myself unable to do something as simple as split a quote block in the middle. System designers who make it so you have to use WYSIWYG for everything should be beaten senseless with a bundle of hot spaghetti.


All content © copyright 2005 – 2022 by Catskill Technology Services, LLC.
All rights reserved.
Note that Third Party software (whether Open Source or proprietary) on this site remains under the copyright and license of its owners. Catskill Technology Services, LLC does not claim copyright over such software.


This page is https://www.catskilltech.com/intelligent-wysiwyg.html

Search Quotations database.

Last updated Sat, 09 Apr 2022 at 4:43 PM

Valid HTML 5

Sat, 24 Sep 2022 at 7:22 PM EDT