10 Editing
Most editors are basically text editors with some facility to format. However, treating a page as just a mass of text makes editing unstable.
HTML is semantic, in that a page is not just formatted text, but a hierarchical structure of elements with text in them. However, those structures are defined by specially-formatted text, which means that a typing error while editing the file as text can break the structure. To get around this, some sort of visual editing paradigm is usually implemented to maintain elemental integrity in spite of what may be typed in.
Some online text editors allow embedding markup code to insert HTML elements, but they suffer from the same risk of breaking them, though the consequence is that they will not render rather than breaking the page. They usually only apply for simple formatting elements without attributes, so would not really work for complex rich-text structures.
I left the editing facility until late in the product development, in favour of getting the look-and-feel of the various pages types right. All our sites were originally maintained by me editing the XML data files. I then progressively built the management pages to take over more of the site administration, eventually getting to the editing page. It was obviously the most complex, and needed a lot of rules to govern its operation.
While the aim was always to maintain the hierarchical structure of the page, the initial design had too much emphasis on the structure to the point of almost hiding the content. While a paragraph of text was simple enough to recognise, the more formatting it contained, the more its visual coherence was lost as it became a vertical list of text boxes!
A more what-you-see-is-what-you-get visual take was required. It looked much like it does now, but with floating green boxes hovering over the end of each element, exactly like still exists with children listed in an element block. While this was a substantial improvement in that a page looked more like a page, the proliferation of little green boxes was still a distraction, in itself and in the their covering of part of the content. Even though I made a way of temporarily hiding the content of the green boxes, it still looked busy.
The final iteration was to make the floating boxes hidden until hovered over. This did mean that they could not include much beyond the name, mainly due to hovering over a box rendered later taking priority, meaning any controls in a box rendered just before another would never be accessible. The only control in them now is that at the start of those for the children of the current element, there is a checkbox that is used for the multi-delete facility.
The common element across these three iterations was the element block where all the editing functionality is invoked. This encapsulates the fundamental principle of the editing process, being that once created, an element and any of its ancestors cannot be broken by typing an incorrect character in it. There may be a nominal error, such as having an incorrect number of children, but they will not be broken per se. They will just be marked as in error, which is a rule applied rather than a fundamental fault in their structure.
The editing process is fractal, in that it appears and operates basically the same at each element level in the hierarchy. Each element has its idiosyncrasies, such as particular attributes or types and numbers of groups and children in them, but the way they are worked with is the same. The rudimentary element blocks are shown for each ancestor to the current element as well, so that the hierarchy is still obvious despite the flat nature of the visual rendering of the page.
Embedded characters△
While making everything into elements makes for a level of simplicity, it does not always work.
While CSS provides for automatic hyphenation, only Firefox provides it for anything other than English. So I created a soft-hyphen element and specified in the rules which elements it could be used in. That was easy, but they turned what was contiguous text of a paragraph into a mass of child text and soft-hyphen elements. Removing one required deleting its element, then merging the text elements that were either side of it. Clunky!
The other issue was that they only worked for rich-text elements, but would be useful for other text like table headings and labels. While Unicode does have soft-hyphen characters, and so could just be pasted in, they became invisible when trying to edit the text. The only time they became visible was if words required breaking at them. The solution was to make them into character sequences like hs^ for a standard soft-hyphen.
There is also sequences for Armenian and Mongolian versions. I could have made the soft-hyphen automatically change to the versions for those languages, but I could not be sure that that should be a hard rule, given that the US cultural influence that had persuaded many to use US quote characters rather than those traditionally applied for their languages did not also apply here.
Another issue was that mixing scripts that had opposite rendering directions would often not render correctly. This is because while letters are considered hard-direction, and so sequences of them render correctly, punctuation and other characters would only do so if surrounded by hard-direction characters, otherwise they would follow the enclosing element's flow. While wrapping some text in a bdo element with a dir attribute would work in some circumstances, others needed the use of the Unicode hard-direction characters. These are also invisible during editing, so they needed character sequences.
While Unicode includes direction characters for multiple levels of directional text bounding, I expect that many people would have trouble keeping track of those levels in a bunch of text, so I settled on only using those for left-to-right and right-to-left. Mixed scripts often require experimentation to get to render correctly, so the process needs to be kept simple. For such situations, it is often better to rearrange the presentation format of the text so that the scripts are kept separate.
Inline insertion△
While elements can be appended to a parent, or inserted after another, adding elements inline can be convenient.
Inline elements use special character sequences like online markup text, but with a more compact format, and endure as a separate element once created. This is especially important with right-to-left scripts as markup can get jumbled up by the rendering, making having to deal with them in every re-edit session problematic.
Any markup has to use special combinations and sequences of less-used characters, and these do not usually have a hard-direction, but have English text within them which has a hard-direction of left-to-right. This is why they can become jumbled up as they are being typed into right-to-left text. The trick is to just type the sequence in, but ignore what rendering quirks may be happening with each character typed.
Such editing situations may present difficulties for those with some neuropathies like autism, so having the elements endure saves them from having to deal with it every re-edit. If there are real difficulties, being able to append and insert at the element level bypasses them. Online markup systems do not provide a way around such difficulties as they do not provide an alternative way to create the embedded HTML elements so that they endure.
For markup systems that do allow attributes, the user has to explicitly know what are valid attributes and their values. The advantage of enduring elements is that an element can be created, and if there are any optional attributes, they are explicitly listed, and their values can be selected from explicit lists. Elements can even be created inline with minimal text (say the - character) and then have their opposite-direction text added after, bypassing trying to enter text of one rendering direction in the midst of that of the opposite direction, and hoping it stays intelligible.
Most online markup systems are created by people who speak English and use English text as the keywords in the markup. They only really work cleanly for left-to-right scripts like Latin or Cyrillic. These designers have probably never tested their designs on right-to-left languages like Arabic or Hebrew, or those with autism. Anyone designing user interfaces or online text markup systems should test them with mixed scripts and autistic people. Until that's done, any design is just wishful thinking!
Picking the codes△
It is tricky to pick the unique strings of characters that allow embedding within normal text.
The trick is to pick a sequence of characters that is very unlikely to appear in the text in which they are embedded. If they have a chance of appearing, even if only to describe the valid sequences themselves, there has to be another way to show them, typically by encoding them in other character sequences like HTML does, or being able to break up the sequences so that they do not get translated into the entity that they normally would. The latter is how the sequences referred to above are shown in the help documentation.