Splitting and joining <li>s

[Steven Pemberton-3]

A problem that I regularly have to deal with (typically turning a text  
file into HTML) is what happens when splitting <li>s.

Take this situation (| is the cursor positioned before "two" within an  
<li>). I want to split the <li> into two <li>s:

        * One |two
        * Three

1. hit return

        * One
          |two
        * Three

2 So far so good; this I expect. Hit return again (here is where it goes  
wrong):

        * One
          |
          two
        * Three

3 This is not what I had expected. However, hit return again:
        * One
        * |
        * two
        * Three

4 Now you have to do a backspace:

        * One |
        * two
        * Three

And you have the result I wanted. I would expect that hitting return in  
step 2 would give me step 4.

The reverse, joining two <li>s works exactly as I would expect it to work.  
Starting from step 4:

* One
* |two
* Three

Hitting backspace gives step 2:

* One
   |two
* Three

Backspace again give step 1:

* One two
* Three

So in short, I would like these two (splitting and joining) to work  
symmetrically.

Thanks!

Best wishes,

Steven Pemberton

[Laurent Carcone-2]

Hello Steven,

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>.
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.

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.

Hope this helps,

Laurent Carcone


Steven Pemberton wrote:

> A problem that I regularly have to deal with (typically turning a text
> file into HTML) is what happens when splitting <li>s.
>
> Take this situation (| is the cursor positioned before "two" within an
> <li>). I want to split the <li> into two <li>s:
>
>     * One |two
>     * Three
>
> 1. hit return
>
>     * One
>       |two
>     * Three
>
> 2 So far so good; this I expect. Hit return again (here is where it
> goes wrong):
>
>     * One
>       |
>       two
>     * Three
>
> 3 This is not what I had expected. However, hit return again:
>     * One
>     * |
>     * two
>     * Three
>
> 4 Now you have to do a backspace:
>
>     * One |
>     * two
>     * Three
>
> And you have the result I wanted. I would expect that hitting return
> in step 2 would give me step 4.
>
> The reverse, joining two <li>s works exactly as I would expect it to
> work. Starting from step 4:
>
> * One
> * |two
> * Three
>
> Hitting backspace gives step 2:
>
> * One
>   |two
> * Three
>
> Backspace again give step 1:
>
> * One two
> * Three
>
> So in short, I would like these two (splitting and joining) to work
> symmetrically.
>
> Thanks!
>
> Best wishes,
>
> Steven Pemberton
>
>

[leif halvard silli]

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