Re: Splitting and joining <li>s

Laurent Carcone On 09-09-11 17.27:

> Indeed, the behaviour is different in XML editing mode if the cursor is 
> positioned at the end of an <li> or within an <li>.
> In the first case, a return creates an empty <p> and a second return 
> creates a new <li>.

> In the second case, a return creates a <p> with the right part of the 
> <li>, a second return creates an empty <p> and a third return creates an 
> <li>.


This is incorrect. First case, caret at start of list item:
* Single return + Save = this:
     <li><p>Paragraph text.</p></li>

* Twice return + Save = this:
     <li></li><li>Paragraph text.</li>

Second case, caret centere of list item:
* the *third* return creates *two* <li> elements:
     <li>Paragraph </li><li></li><li>text.</li>

Viewed from different angles:

1) First case. Caret at list item start. Single return + Save:
  a) this is the _displays_ in Amaya - **note the break**:
     *
       Paragraph begins below the "*"

  b) for which users perhaps would expect this source code:
     <li><br />Paragraph begins below the "*"</li>

  c) however, as told above, Amaya _actually_ generates this:
      <li><p>Paragraph begins below the "*"</p></li>

  d) which if you look at in a Web browser, displays like this:
     * Paragraph begins below the "*"

2) Second case. Caret in list item center. Single return + Save:
  a) Amaya and Web browsers same display [empty line = margin]:
     * Paragraph begins

       below the "*"

  b) for which *I* would expect this source code:
       <li><p>Paragraph begins </p><p>below the "*"</p></li>

  c) however, Amaya actually generates this code:
      <li>Paragraph begins <p>below the "*"</p></li>

The Amaya output could have some CSS styling advantages in legacy 
web browsers. However, semantically it seems highly illogical.

Amaya ought to output b)

> So, if I am right, a return when the selection is on an empty element 
> creates a new "upper level" element in the structure and a return when 
> the selection is on a non-empty element creates a new element at the 
> same level.
> I don't know if this behaviour can be modified for some specific cases, 
> we'll discuss it.

(1) The simplest way to _for the developers_ would probably be to 
add the <li> element as one of the options in the Insert menu. Do 
you need to discuss that? Currently there are *direct* insert menu 
items only for OL, UL, DL, DT and DD - nothing for <li>.

Justification: Amaya has a fairly consistent behavior for what 
happens when an element is inserted. Thus, once a <li> is 
inserted, I would expect the current <li> to be closed 
simultaneously. We, the users, would then be able to split the 
<li> by using the shortcut/menu item for the <li> element.

(2) A general "split this element" command could also work.

> A possible go-round in this case is to switch to 'Text' editing mode 
> (the text area at the bottom right of the window) to split the <li>in 
> one hit, then to switch back to 'XML' editing mode.

A way to insert <li> would be my priority.

However, a shortcut and/or menu item for switching between text 
and XML mode would make this workaround  more efficient. (Mac OS X 
lets users themselves create/change shortcut for menu items.)

> Steven Pemberton wrote:


>> 1. hit return
>>
>>     * One
>>       |two
>>     * Three
>>
>> 2 So far so good; this I expect. 


The code here probably isn't what you expected:

      <li>One
       <p>two</p></li>
      <li>Three</lli>
-- 
leif halvard silli