[whatwg] Authoring Re: several messages about HTML5

----- Original Message ----- 
From: "Dave Raggett" <dsr@w3.org>
To: "Andrew Fedoniouk" <news at terrainformatica.com>
Cc: "Adrian Sutton" <adrian.sutton at ephox.com>; "Karl Dubost" <karl at w3.org>; 
<whatwg at lists.whatwg.org>
Sent: Thursday, February 22, 2007 3:09 AM
Subject: Re: [whatwg] Authoring Re: several messages about HTML5


| On Wed, 21 Feb 2007, Andrew Fedoniouk wrote:
|
| > I agree that HTML DOM is not suitable for WYSIWYG editing.
|
| I beg to differ. It is true that an editing style sheet may be
| needed to avoid problems with delivery style sheets that use the
| display and visibility properties to hide content, or which use CSS
| positioning to layer things in complex ways. But apart from that,
| The HTML DOM is just fine as it is.

So this means relaxation of requirements - strictly speaking
it will not be WYSIWYG anymore. If "editing style sheet may be
needed" then what you will see is not what you will get.

|
| Manipulating the DOM is a straightforward matter of tree walking
| algorithms. The really difficulty is understanding what the users
| would like to do. For example, you might type some text and click on
| the list bullet button. The enter key then starts a new paragraph
| within that list item, whilst enter followed immediately by another
| enter starts a new list item. Pressing enter on an empty list item
| closes the list. When it comes to the markup produced, you can
| conceptualize this in terms of a collection of critics that look for
| and fix particular problems, e.g. merging adjacent ul elements, or
| for moving leading and trailing whitespace out of inline elements.

In reality WYSIWYG principle has one hidden part:
What You See Is What You Will Get and What You Can
Change Consistently by Using Solely UI Facilities/Tools.
That is real meaning of modern WYSIWYG interpretation.

HTML and its DOM has logical/semantic elements that
have no visual representation at all. Think about DIVs that
are used for wrapping portions of textual data and has no
visual representation. Your style sheet may rely
on some containment in some DIV - so the same
sequence of editing actions made by the user produces
dramatically different (for the user) visual results.

Let's take a look on example you've provided:
"The enter key then starts a new paragraph within that list item"
So after enter you will have:
Case #1:
<ul>
   <li>First paragraph.
         <p>Second paragraph.</p>
   </li>
</ul>

*or*  Case #2:

<ul>
   <li>
      <p>First paragraph.</p>
      <p>Second paragraph.</p>
   </li>
</ul>

So even in this "simple" case you have two options how to make
mapping of "action -> dom structure".

And now imagine that you will get following markup:
Case #3:
<ul>
    <li>First paragraph.</li>
    <p>Second paragraph.</p>
</ul>

Visually and by default this is indistinguishable from the Case #1.
So looking on these two list items user has no clue of
what he/she just did by pressing "Enter". Enter press is the most
unpredictable action in all WYSIWYG editors in the wild.
For the simple reason: there is no single unambiguous way
of changing DOM for such an action. Again tree-alike
DOM is simply not suitable for that.

And now try to imagine that all this editing happens
in the presence of CSS, let's say following rule:
li:first-child { border-bottom: 1px solid blue; }

All three cases above will provide different rendering.
And now try to imagine of how you would explain
to the user why "that-blue-underline" appeared and
why exactly there. And what needs to be done
by the user to change it.

Beside of that , yes, "Manipulating the DOM is a
straightforward matter of tree walking algorithms.".

Andrew Fedoniouk.
http://terrainformatica.com


| p.s. one missing feature in CSS that would really help would be a
| means to add a forced line break symbol to the rendering of <br>
| elements. It is already easy to add a paragraph symbol, but CSS
| balks at <br> elements for inappropriate reasons.
|
|  Dave Raggett <dsr at w3.org> http://www.w3.org/People/Raggett
|
|

Received on Thursday, 22 February 2007 12:12:22 UTC