-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement toolbar buttons for text mode #569
Comments
See also:
|
Whether the Quicktags are going to stay or not, worth reminding any UI control should be properly labeled. Currently, just the content of the button is available to assistive technologies and in most of the cases, it doesn't help so much users as it's just For example, the plugin: |
No firm decision have been made yet. Philosophically I'm leaning towards them staying. Back when we started on this adventure I did a little very anecdotal research on how people use the editor, and though not very many people used the HTML editor (did not ask specifically about quicktags), those that did use it used it all the time and were very, very passionate about it. Since we are doing such major changes to the editor, I feel like the text editor might serve as the one holdover from the old world, a 0,0,0 coordinate in a universe that's about to change a lot. And for that reason alone, I'm reluctant to rethink that too much. |
I'm one of those people. I agree that text mode mostly unchanged would be a stability point, but really, it's the only way I can see what's actually in the content and make it say exactly what I want. Don't remove features from the one tool I rely on. |
I think no one wants to remove the text editor 🙂 it is also an a11y very important feature, since only a native textarea is really fully accessible. Just wondering about the buttons to insert opening/closing tags. They're hard to use, and very few uses them. |
I was referring to the buttons, not the text editor. The very small sample of respondents to that survey had very few who used them. But as part of the stability thing, I think they should be left as is. |
We're creating a new programming language in a very real sense. Why not make the text view an IDE. For basic editing it looks plain with a few small enhancements. Maybe we somehow indicate where the blocks are (poorly, for example, with colored backgrounds) and dim the block comments, etc… When someone accidentally mangles their blocks they will get an immediate visual response right there. We could even emphasize certain spans of text according to certain knowable properties of it from the parse. For advanced editing we turn on syntax highlighting and error messages. This view would feel more at home to people with some coding skills and the error messages could provide a good environment for a developer/agency to go in and recover a messed up post. |
@jasmussen clearing from milestone as it'd be good to have only actionable tasks there that have been decided. |
They've disappeared in the latest build I'm using a0e5933 |
Yes, we removed them because they were just dummies. That doesn't mean they can't still be built, just that it was misleading to have them when they didn't work. |
Related: #4803 |
In the last versions, all the buttons were removed from the text mode. This issue can be closed. Worth opening a new one to consider to add a few buttons for the main functionalities related to authoring content (e.g. Insert Link and Add Media). |
About the editor text mode, currently (April 28th) the plugin displays a toolbar that visually mimics the "quicktags" buttons.
Given the presence of the "close tags" button, I'm guessing it's going to replicate also the quicktags functionalities.
None of the buttons works so far, that's perfectly understandable since the plugin is in a heavy development phase, so there's not so much to test. However, I'm wondering if replicating the current functionalities is a good idea in the first place.
Maybe worth considering removing most of them, also taking into consideration what emerged from the editor survey:
https://make.wordpress.org/core/2017/04/07/editor-experience-survey-results/
47.2% No
34.9% Sometimes
17.9% Yes
Has this ever been discussed? Any plans I may have missed? Any new ideas of improvements planned?
The text was updated successfully, but these errors were encountered: