ckeditor4-plugin-a11ychecker
ckeditor4-plugin-a11ychecker copied to clipboard
cksource
Provide a subtle highlight also in listening mode
Overview
Actually I came with that idea while working on #27.
We might leave subtle highlight for issue elements in listening mode. That will allow end users to have a better orientation on errors, keeping him focus on his job, rather than toggling between states all the time.
I created following screens that demonstrate the idea:
Checking mode:
Listening mode:
We cold have the original highlighting, but the exactly reason we decided not to have it is because it is hard to have it right. People will start breaking highlight paragraphs and mess up with it and we gonna have troubles.
I don't think we should have this, especially at this stage. If there is any chance to have it, let's talk and plan this for after v1.
In order to not break the undo manager, the idea could be to use a chain of :nth-child() in an automatically generated stylesheet. The stylesheet could also be updated live on editor#change if you can somehow keep references (not using attributes) to the incorrect elements (although, it sounds like undoable).
BTW. Why closing this issue? It's still a valid issue, though, not fixable at the moment.
In order to not break the undo manager, the idea could be to use a chain of :nth-child() in an automatically generated stylesheet.
It was what I also thought would be the best. But the more I think about it the more desperate it looks. It does not provide solution for enter key, as well as interaction with other commands, clipboard, etc.. It's a very rough problem.
BTW. Why closing this issue? It's still a valid issue, though, not fixable at the moment.
:+1:
It was what I also thought would be the best. But the more I think about it the more desperate it looks. It does not provide solution for enter key, as well as interaction with other commands, clipboard, etc.. It's a very rough problem.
Of course. The stylesheet needs to be updated on change. Then it will be integrated with enter key and all other kind of actions. However, I think that it will be very hard to achieve that - you need to get the data, pass through the a11ychecker engine, process back to an HTML format and then find the addresses to incorrect elements. All that must be done without touching the editable's DOM.
We closed this issue today because I have the feeling that this is a overly complicated issue that may have lots of still not clear issues and therefore we don't plan to work on it at this stage as the current solution is sufficient.
As you pointed out, the solution seems to be fairly complex. And we have lots of other stuff to do.
It's my understanding that some of us find this feature useful, so I think it make sense to keep it open so we'll eventually come back to it one day.
Just to underline my position: I find this very useful... it's just impractical to have it implemented right.
Btw, there is no point to make it "subtle". If we will ever implement this, we should just keep the original check highlights when in listening mode.