Add inputTypes for Safari and use 'data' to pass argument #32
Comments
chong-z
changed the title
|
According to Safari's context menu and font panel, I think we should add following inputTypes:
As well as actions require a parameter (which should be put into
|
|
@choniong Yes, we need to discuss this. The other option is to remove these options from the Safari menus.For a lot of this, JS editor developers may prefer for it to be removed rather than to add the inputTypes. I didn't add "writing direction" because they don't actually do what they claim to do, at least not in the understanding of lay people. Turning on right-to-left does not suddenly make European script go in the opposite direction. Those of us who understand CSS and some more technical aspects can figure out what is going on there, but we don;t really need richtext editors. The other menus with colors and fonts I couldn't get to work, and my communication with JS editor developers indicates that they haven't dealt with these menus because the Apple users tend to not know of their presence. If Apple insists to keep these menus, I would agree to do as you say and add these with the data. But I would still urge Apple to add a way to remove these menus entirely, as many/most/all editors will disable at least parts of the options in these menus. |
|
As for fonts: Is there a way for the JavaScript to specify which fonts can be chosen, or does it simply automatically offer all fonts installed on the system? Or those used on the webpage? |
I guess we should do both: 1. Support these features and 2. allow opt-in/opt-out.
Well I have no idea how RTL script works... But I guess we should support them as they are modifying DOM.
Yes it don't work on Safari currently, but Safari has the entry and it works on other macOS native apps. |
|
@choniong Testing: Google Docs: The rightclick menu is disabled, and those of the options that are available in the top menu are not working. Microsoft Office 365: same as Google Docs: The rightclick menu is disabled, and those of the options that are available in the top menu are not working. CKeditor 5: Right-click menu available, but none of the options work. CKeditor 4: right-click menu unavailable, some of the other options work. (communication with developers indicate that the working options are working because CKE 4 ignored this user action and contenteditable made the change automatically) TinyMCE: Same as CKeditor 4. Prosemirror: Right-click menu visible, some simple options work (capitalize, turn to capital letters). Others have no effect (change fonts, etc.).Edit: changing from ltr to rtl causes a JavaScript error and a breakdown of the collaboration process if connected with other users QuillJS: At least some of the options in the right-click menu initially seem to work. But when one then tries to combine with UI controls inside the editor, for example the li tool, it quickly breaks down and either the paragraph direction is lost, or the list number is printed underneath the paragraph. Facebook status update: turn-to-caps works, changing paragraph-direction seems to have no effect. Bold and other styling has somehow been disabled. Font selection is still there, at least one can get one menu into it, but then it doesn't go any further. |
If we can get a opt-in/out mechanism, like the one I suggested or a different one that accomplishes the same goal, that could work. But I should also add that I have received remarks from people working with JS editors questioning the usefulness of having many of these options altogether as they feel that it is much easier for them to add buttons for extra options such as adding emojis, choosing fonts that they really want to be available, adding rtl-buttons, etc. . But again -- if we can get this opt-out mechanism, I'm ok with that.
I don't either, and I agree that we need to support those users. But the button as it is seems confusing for users of ltr-scripts. Even I, somewhat technically inclined, would initially expect that the option would turn my English language text into a mirrored version that runs right-to-left. So if these menus really are needed, I think we need to be very careful in the description of these events to explain what they really do.
Ok, sure. Have we found any editor on the web where all of these work? |
Well I'm not sure when/how Safari is gonna implement it though, but I agree we should.
Nope. :p But with |
|
@choniong: I now notice that also Chrome has a "writing direction" option in the right-click menu, and also this breaks ProseMirror. Do we have any documentation for how this feature is supposed to work?
True. But if the menus aren't working now, and neither Google Docs nor Office 365 have bothered about trying to get at least some of the options to work, maybe that is an indication of users and developers not looking for these features in those menus and therefore not complaining. |
|
Here's a concrete proposal. New Input TypesAdd the support for "backColor", "createLink", "fontName", and "fontColor" to These new input types respectively sets the background color of text, wrap content with a hyperlink, change the font face, and change the font color when the user expresses an intention to do so (as in execCommand of the same names). "backColor" and "fontColor" specifies the color of the background and the font face respectively using the CSS color unit in "fontName" specifies a single family name or a single generic family name as used in the CSS font-family property in "createLink" specifies the URL relative to the base URL of the context object's document in New Content AttributeAdd new content attribute The The supported input actions of an element specifies a set of input types for which a When the
|
|
Interesting! Is there a way currently to create a link using browser UI or keyboard shortcuts? |
|
@johanneswilm : Yes, we have this feature called smart link which automatically linkify URL whenever user types in an URL and then inserts a space / enter. Because this feature is pluggable via extensions, etc..., there could be a third party app e.g. to linkify their app link. |
|
I think this could work, if we can figure out of a way to dynamically enable/disable the undo/redo menu entries so that we don't need to rely on feature enabling/disabling for these. @rniwa Does this mean that you don't see a need for other new inputTypes for safari at this stage? |
|
I've omitted things like making letters uppercase and smart quoting because those things can be treated like spellchecking features and user replacing text via input methods. It's better to have a fewer primitives that websites need to support instead of adding dozens of new types.
I'm not sure about manipulating undo/redo arbitrarily but the idea is to not even insert things into undo stack if an action is not supported so that should work as long as author explicitly specifies the actions they'd like to support. e.g. if bold isn't supported and user tries to bold text, that attempt won't be inserted into the undo stack.
What I've listed in #32 (comment) is what's minimally required to support the basic features. There's some bidi related features but I think that could wait for now. |
If you mean the ltr/rtl switch, I noticed that Chrome has that as well, and it seems to break at least one editor and be of little use in other editors that for example only target users using Latin/Cyrillic script. Or at least it would make sense to be able to turn this off for those users who only write languages where such a menu might cause confusion. So I would think this should should be added as an inputtype, if that means it's also something we can disable. |
|
@rniwa @choniong @garykac @gked @travisleithead #32 (comment) makes sense to me. Y'all good with that? If so, let's spec and implement? |
|
@ojanvafai: Are you ok with also adding the options that are in the right-click "Writing direction" menu on Chrome and and "Paragraph direction" in safari? |
|
MSIE has recently removed the support for mutating |
|
Note that some UA may still insert BDI, LRM, RLM, etc... Unicode control character via |
|
@rniwa I don't know enough enough about bidi to know whether they are useful. I am mostly concerned about being able to turn them off for pure English text.
OK, but those will be unicode characters that come in through a beforeinput event. That's different than this menu which adds a style-tag to a paragraph, especially if it doesn't emit a beforeinput event for this DOM change. Also, entering those unicode characters wouldn't be something that someone who doesn't anything else than ltr would enter accidentally, would it? |
|
I don't know. I defer to @choniong. :) |
|
@rniwa I don't know enough enough about bidi to know whether they are useful. I am mostly concerned about being able to turn them off for pure English text.
OK, but those will be unicode characters that come in through a beforeinput event. That's different than this menu which adds a style-tag to a paragraph, especially if it doesn't emit a beforeinput event for this DOM change. Also, entering those unicode characters wouldn't be something that someone who doesn't anything else than ltr would enter accidentally, would it? |
|
I can tell you that being able to change the block direction of text is extremely important for bidi users. They can't meaningfully use text editors without this feature. What I mean is that UA could implement that menu item by inserting LRM and RLM instead so I'm not certain if we can guarantee that all UAs would use the newly added input types. Having said that, it is true that mutating the direction of an existing text is a conceptually different operation from inserting LRM, RLM, BDI, etc... as users type new text into a text field / editor. |
This would happen through a beforeinput, inputType = insertText event, right? That would be more acceptable. At least it would not be causing a DOM change that doesn't go through a beforeinput event. If a browser would do that, then I think I could wait with getting a specific inputType just for that, even though I still think it may be confusing to end users to see such a menu entry if they aren't familiar with anything else than ltr text. |
FWIW, what each vendor puts on their browser UI is outside the realm of what this task force is chartered to spec. |
|
@rniwa Right, but we need to deal with what browsers actually have. So if the browsers that exist today that have the direction-changing menu entry all agree that they can change the functionality so that they only add or remove characters of text nodes, and that they would prefer that to creating one or several new inputTypes for their writing-direction menu entries, then I would say that would be a workable alternative for now. I think we all agree that every DOM change in the editing area needs to have a beforeinput event. So if the writing-direction menu entries change the DOM, they need to do this through some beforeinput event, right? I don't care too much which one we pick, but I would prefer if we could have one that would express the user intent as much as possible. |
|
Yeah, I think the easiest path forward is to add those input types for now. |
|
Ok, so what should we call it? "setBlockDirection" with values "ltr", "rtl" and "default"? Other suggestions? |
I think this goes somewhat counter to the idea of contenteditable=typing, contenteditable=caret, etc. : The idea with these modes was to disable the browser's automatic handling of these events, so that instead the JavaScript editor would listen to all the beforeinput events and do all the needed changes to the DOM itself. For contenteditable=typing, the idea was that the browser would only handle keyboard typing and IME input and the JavaScript would handle everything else. That wouldn't work if we turn off a lot of the inputTypes for this mode, as that would mean that the relevant menus would disappear and presumable the beforeinput events wouldn't be triggered either for keyboard shortcuts, etc. . I am fine with all the rest of it. I think we should probably take the discussion about the alternative contenteditable types at the next meeting after the one tomorrow and focus on beforeinput/input tomorrow. |
|
+1 to punting on contentEditable=typing until we've solidified beforeInput, supportedInputTypes, inputmode and inputmode-action. Those four are by far the most common author requests we get. We should still explore contentEditable=typing/events/etc, but given limited resources, we can punt unless some browser vendor really needs it sooner rather than later. |
|
If we're going with a new input type, I'd suggest
|
|
@rniwa Just a followup to #32 (comment).
I believe there is no objections in TPAC, we could just add them to spec.
There seems to be some disagreement about the If I understand correctly your proposal is:
But the problems are:
|
They have now been added.
Right, but these restrictions are only about the alternative contenteditable modes. The overall model for being able to turn of features this way seemed to be uncontroversial. The UA will now which actions should be available, and it alone decides what changes it will make to the UI based on this knowledge. However, in cases like iOS and the native menu that overlaps everything, it is to be assumed that Safari will solve this in a way that makes the menu smaller or go away entirely, as this seems like the easiest solution for them, and it will allow their users to use webbased editors more easily. |
The proposal is that only the list of input types explicitly listed in
I think you misunderstood our proposal. The proposal is to have a sensible default value for I think it's also useful to have a shorthand for common sets of input types. For example, if you wanted to allow typing, deleting, replacing text, etc..., then something like |
Having a shorthand for combinations would be useful, but this shorthand would then be used in the attribute that specifies the allowed actions, right? In your initial proposal:
It sounded as if contenteditable=typing should only allow 7 input actions and no delete actions. contenteditable=typing should only allow default handling of these inputTypes, but should still trigger beforeinput events for other inputTypes. That's why we postponed discussion/decision on this part of your proposal. |
|
Just using shorthand in |
I think the confusion is how do you define It could be defined as either:
|
|
Oh, it certainly needs to do 2 because the whole point of |
Exactly, so back to the 2 problems in #32 (comment):
|
I don't think JS editors are OK with it if this means that the overlay menu on iOS cannot be removed because some menu items will always be there. Other than that, it doesn't seem to be much of an issue. The urgent need for being able to remove support for actions seems to be quite directly linked to the iOS Safari menu, and maybe to a lesser degree to the Mac OS X Safari menus, although it seems to be a smaller problem to ignore those. So far I have not heard any of the JS editor developers complain about other browsers/OSs, so whether or not the copy can be turned off in the Android or Windows Mobile menus seems to be less of a concern. |
Yeah, I don't think those are input actions. They're more of selection features so we should be discussing in a different avenue (e.g. in the selection API). Also, disabling copy doesn't really make sense on Linux where middle button click is supposed to copy & paste things from any app to any other app. |
Agreed. But that also means we need to find another solution for this:
or this:
|
|
@choniong @rniwa How about if we add copy to the list and potentially others and define it so that if an input action is not enabled, the corresponding beforeinput event is not triggered and the default action of that beforeinput event is not taking place if there is a corresponding beforeinput event. So in the case of copy, where there is no corresponding beforeinput event, only the UI elements are disabled/removed, but because there is no beforeinput event, nothing is canceled. |
|
Preventing copy doesn't really make sense in that any text that's selectable should be copyable on iOS and Mac. Not allowing copy would result in a serious UX degregation. We should be able to disable cut & paste when the corresponding input events are not listed in |
|
@rniwa True, but the point is to get the menu out of the way because it overlaps with the editors menus. So I would imagine either one adds one's own buttons that then create a copy action (which should be event easier to do with the updates that have been announced for the clipboard api), and/or the JS code adds and removes the copy from the list continuously to make the UI show at certain times and not show at other times, to prevent overlapping. |
I don't understand what that even means. On iOS, the way to copy text is by selecting text and tapping on "Copy" on the popover that shows up. On Linux, there is an implicit copy whenever selection changes on any app because the user can press a physical middle button on his mouse to initiate the paste on any other app, and the original app that put the content into the clipboard doesn't even get notified. So this idea of overriding a way to initiate a copy can't even be implemented on some platforms even in native apps without breaking the fundamental UX of the platform. |
See the two screenshots in #32 (comment) . This is what JS editors seek to avoid in some way. And this turning off of features was the way we hoped to get there, but if the copy entry won't go awya that way, then we need to find another way. |
AFAIK, the overlapping problem is exclusively a Safari/iOS issue. That's the only ones we have heard complain, anyway. Android and Windows phone don't seem to have this issue. I don't think it matters how it's fixed to the editors who have this problem, so if there is some other way that is more compatible with your platform, then that should work just as well. |
|
The only way to disable that would be to disable text selection entirely. |
OK, but the point seems to be that they want to show their own menu when text is selected, the reason being that they offer actions the browser native menu doesn't provide, so they cannot easily use the one that comes with the browser. Maybe we need to think in some completely different way to resolve this, how about one of these:
|
This is probably a good idea. Because on Mac, there is an autocorrection bubble that shows up as user types. On almost all non-mobile platforms, input methods' candidate window almost always overlaps with autocompletion feature websites provide. |
|
The issue is apaprently getting worse with this touchbar feature. We should probably move a bit faster with this: https://twitter.com/gigasoft/status/815256495046660097 |
After discussing a bit with editor devs, this seems like not so important after-all. At least for now the IME sessions mean that the editor cannot do that much during IME, which also means that the IME controls don't bother them as much. At the same time, also Android in some (newer?) versions seems to have a context menu with clipboard actions that overlaps the editor, and while it annoys me personally, from what I gather there isn't much of a protest wave among users of the web editors. So in the end, clipboard actions may be OK in an overlapping context menu. |
|
I'm on iOS 16 and |
Safari has context menus for more editing operations that have not been covered within inputTypes so far:
The text was updated successfully, but these errors were encountered: