search

w3c / input-events

Input Events
https://w3c.github.io/input-events/
Other
23 stars 16 forks source link

Should there be "deleteOrderedList"/"deleteUnorderedList" inputTypes? #44

Open whsieh opened 7 years ago

whsieh commented 7 years ago

Browsers may have ways for the user to explicitly "downgrade" a list item into a regular text node.

johanneswilm commented 7 years ago

Do we have a browser that does that? Some JS editors allow changing the blocktype of the current block: paragraph, ul, ol, code, headline 1-6, etc. If we have a browser that provides this, maybe we could formulate as such a more general feature?

whsieh commented 7 years ago

The Touch Bar in Safari has a special configuration for text editing. One of the buttons in the touch bar when it is in this state can revert a list (ordered or unordered) into separate lines.

johanneswilm commented 7 years ago

From your description of it, it sounds like we should have a beforeinput event to change the block type. Do you think that would cover it in a reasonable way? Is there a way I can test the functionality of the touch bar (without buying a new laptop)?

...... Btw: The JS editor devs recently discovered this touch bar "feature" and they seem somewhat less than enthusiatic about it [1]. If you guys decide to add such "improvements" in the future, I think it would be a good idea to at least give a warning to all the editor projects once it is released, so they know what kinds of problems they will have to deal with next without having to buy all the newest devices from all the companies.

But now that this is out there -- I agree, we need to be able to deal with it. The top priority of the editor devs seems to be to add a way of removing it. But right after that I would say we should have a way to deal with it in terms of beforeinput events.

[1] https://twitter.com/reinmarpl/status/815891989581492224

whsieh commented 7 years ago

CC @rniwa

we should have a beforeinput event to change the block type

Just so I have a better understanding, could you elaborate on what this entails? For Safari, I think this might work, since we don't have a way of inserting nested lists using the Touch Bar when we're already in a list (e.g. if we're in an unordered list and we tap the unordered list button, that will delete the unordered list).

However, if another browser has a way of specifying that we want to insert a list when we're already in a list, I'm imagining we will need insert- and delete- inputTypes for each block type to differentiate changing the block type from inserting or deleting a list item. But maybe it's enough for now to have a beforeinput event to change the block type.

Is there a way I can test the functionality of the touch bar (without buying a new laptop)?

You can launch the Touch Bar simulator from Xcode -- here's some more detail about it: https://help.apple.com/xcode/mac/8.1/#/dev7a8cb8a8c

rniwa commented 7 years ago

A command to block-format an element isn't going work for lists regardless. When you're turning a paragraph of text into an ordered list, you need to wrap it in OL and LI elements, not just OL or LI so you'd need a special handling of these events anyway.

johanneswilm commented 7 years ago

Just so I have a better understanding, could you elaborate on what this entails?

It would be something corresponding to execCommand's formatBlock. In general I would imagine editors to do something like this when the browser triggers this inputType.

For each inline node within the target ranges (except space-only text nodes), take the lowest level parent block node and turn its blocktype into the blocktype specified by the data attribute.

In the case of UL/OL, they'll have to wrap several LI-elements in a UL/OL.

But how exactly they will do this (fx: Merging or not merging with lists above or below it?) is quickly getting to be a very complex question that each editor will have its own answer to. Aach JS editor will probably spend a few thousand hours with its users, trying to come up with a good and intuitive DOM change as a result of this -- or decide to disable it entirely.

This isn't anything the browser makers should have to worry about.

However, if another browser has a way of specifying that we want to insert a list when we're already in a list

They would use the insertOrderedList and insertUnorderedListinputTypes that already exist, right? And later when "destroying" the list(s), the user would likely click on an icon that turns a list into a paragraph.

You are right that we don't currently have a way of differentiating between "turn lowest level list into a paragraph" and "remove all levels of lists and turn all the contents into paragraphs that are all at the same level".

I don't think I have seen the second option in an editor so far. Maybe we could wait with that until we have a UA offering such a button? So far we have mainly defined behavior for actions that already have some native UI connected to it, with a small number of additional actions for consistency.

I also don't get how having both "deleteOrderedList" and "deleteUnorderedList" would help us much with several levels of lists. I guess in a situation like the below we a "deleteUnorderedList" inputType would make it clear that both levels of lists should be removed. But if we had several list levels of the same list type, this wouldn't be of much help, would it?

<ul>
    <li>
      <ol>
        <li>so[met]hing</li>
      </ol>
    </li>
</ul>
rniwa commented 7 years ago

This is why insertOrderedList and insertUnorderedList toggles in execCommand. When executed inside a list, it removes the list instead of inserting the nested list. Nested lists are inserted by indent execCommand inside a list.

One option is to add a new event type like removeList as suggested by Wenson. Another option is to add a boolean argument to insertOrderedList and insertUnorderedList indicating whether the list must be inserted or removed.

johanneswilm commented 7 years ago

This is why insertOrderedList and insertUnorderedList toggles in execCommand. When executed inside a list, it removes the list instead of inserting the nested list. Nested lists are inserted by indent execCommand inside a list.

One option is to add a new event type like removeList as suggested by Wenson. Another option is to add a boolean argument to insertOrderedList and insertUnorderedList indicating whether the list must be inserted or removed.

If the selection is inside a numbered list, and I click on the bullet list icon, I would usually expect for the numbered list item to turn into a bullet list item. See for example the TinyMCE demo [1]. How would this be handled if we only have these two new delete* inputTypes? What if someone wants to turn a list into a codeblock, or a Headline into a quote?

I now also notice that there is a difference between insertParagraph in execCommand and how we have defined it in input events: In the context of execCommand it is meant to turn something into a paragraph, whereas in the context of the inputevent, it signals that the user wants to start a new paragraph (as opposed to inserted a line break).

Maybe it would be best if we removed insertUnorderedList/insertOrderedList, renamed insertParagraph to a less confusing name, and added a universal command to change the block type (such as formatBlock). It seems like that should cover more situations rather than making new inputTypes for every possible blocktype switch from/to combination. Or am I missing something?

[1] https://www.tinymce.com/

johanneswilm commented 7 years ago

One other button I have seen in some editors in connection with list is an "outdent" button [1]. Is this what you have added to the mac toolbar? If so, I would agree, this should have its own inputType. It should then also work if you have multiple list levels. But it should be enough to have just one such outdent inputType to cover both list types, shouldn't it?

[1] Try to make a list in the demo on http://prosemirror.net/ and you'll see an outdent button appear.

whsieh commented 7 years ago

One other button I have seen in some editors in connection with list is an "outdent" button [1]. Is this what you have added to the mac toolbar?

There is no UI to increase/decrease the indent level in the Safari Touch Bar.

rniwa commented 7 years ago

There is no UI to increase/decrease the indent level in the Safari Touch Bar.

That doesn't mean there won't be one in the future. Indenting & outdenting a paragraph of text is a very common editing operation especially since virtually every word processing app has this feature.

Really, we need to consider the possibility that these APIs will be used for the next 10, 20, or even 50 years on the Web.

Maybe it would be best if we removed insertUnorderedList/insertOrderedList, renamed insertParagraph to a less confusing name, and added a universal command to change the block type (such as formatBlock).

No, as I mentioned earlier, insertUnorderedList and insertOrderedList would require wrapping the paragraph in OL/UL in addition to LI, unlike formatBlock which requires wrapping the paragraph with a single element.

I would object to any proposal that involves deprecating / removing insertUnorderedList and insertOrderedList from the input types. They need to stay.

johanneswilm commented 7 years ago

There is no UI to increase/decrease the indent level in the Safari Touch Bar.

Have you guys tried the link I provided above [1]? It's not outdent in the classic sense, as editors today are often centered around semantic ways of editing. The button means "Lift out of parent block", which in the case of a list of the first level turns it into a plain paragraph. This sounds like the same that you do with your touchbar. Sorry, my wording may have been confusing.

Another example is CKEditor [2] which calls the buttons "increase indent" and "decrease indent", but which has the same functionality for lists as explained above, and which also sounds like it fits your single level list-removal feature.

No, as I mentioned earlier, insertUnorderedList and insertOrderedList would require wrapping the paragraph in OL/UL in addition to LI, unlike formatBlock which requires wrapping the paragraph with a single element.

I think what we need are user intentions to express a wish to "increase the list level" and for that it is important whether this next level is of type bullet or numbered. Going the opposite direction, we don't need to differentiate between the two, because all we need to do is remove the last list level. What DOm changes that results doesn't really mattr, and it will differ from editor to editor.

Additionally I wonder if formatBlock may be helpful. But really, Safari is the only one adding these various formatting buttons right now, so unless you are planning on adding buttons to turn a bullet list into a numbered list or a headline, we may not need this right now. Or does your UI already allow for the switch between bullet and numbered list type by hitting a single button?

[1] Try to make a list in the demo on http://prosemirror.net/ and you'll see an "outdent"/"lift out of parent block" button appears. [2] http://ckeditor.com/

johanneswilm commented 7 years ago

There is no UI to increase/decrease the indent level in the Safari Touch Bar.

That doesn't mean there won't be one in the future. Indenting & outdenting a paragraph of text is a very common editing operation especially since virtually every word processing app has this feature.

Really, we need to consider the possibility that these APIs will be used for the next 10, 20, or even 50 years on the Web.

Absolutely. None of us can know what kind of editing buttosn people will want in 20 years, so we should make sure it's extensible to add new inputTypes.

whsieh commented 7 years ago

On Jan 8, 2017, at 12:42 AM, Johannes Wilm <notifications@github.com mailto:notifications@github.com> wrote:

You can launch the Touch Bar simulator from Xcode -- here's some more detail about it: https://help.apple.com/xcode/mac/8.1/#/dev7a8cb8a8c https://help.apple.com/xcode/mac/8.1/#/dev7a8cb8a8c Ok, I dusted off a Mac and installed XCode, etc. but then it seems like this touchbar simular is only available within projects I write myself, not Safari. Correct? Could maybe someone with a Macbook pro make a demo video of all the contenteditable features in Safari? I think that would be helpful also for other editor developers.

It works for me if I launch the Touch Bar simulator from Xcode and then open Safari and focus a contenteditable element. I can upload a demo video. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/w3c/input-events/issues/44#issuecomment-271138386, or mute the thread https://github.com/notifications/unsubscribe-auth/ABYZZxe03g1H0wGE5RPZTtEo-XpCqRb8ks5rQKFxgaJpZM4KkLB2.

johanneswilm commented 7 years ago

It works for me if I launch the Touch Bar simulator from Xcode and then open Safari and focus a contenteditable element. I can upload a demo video.

Yes, sorry. I realized I had the wrong macOS build version for it to work. I am working on getting it all set up now,

johanneswilm commented 7 years ago

OK, I managed to get the touchbar emulator working.

Lists

For lists it seems to contain these action options:

Is this correct or is there more to these buttons? If it is correct, I would argue that:

Justification

There is a text justification option that hasn't been covered so far: "Full justification" (even margins)

We should also have a inputType for this, and we need a way to remove all the justification buttons from editors that don't allow this.

Colors

We need a way of turning this off. The color siwtching should already be covered by the inputType formatFontColor.

Emojis

The emoji button seems to only insert unicode characters into the text, similar to a keyboard, so this should probably be covered by the insertText inputType.

However, there are many emojis and there is no guarantee that all fonts in all browsers will have these characters defined. Also, emojis are not appropriate in a lot fo written material, so you should probably find a way to remove the emoji menu.

Bold, Italic, Underline

These are among the more common inputTypes, and they are all defined already. Nevertheless, not all editors will allow all three of them, so you need to add a way to remvoe them.

[1] In macOS native TextEdit, and the unwrap seems to work slightly different than in Safari. It unwraps all levels rather than just one in case of a multi-level list item.

an234747 commented 5 years ago

Input event