Closed Antagony1060 closed 3 years ago
Also, the only way I can presently get the clue lists to display formatted text, rather than just the HTML tags, is to refresh the entire page. Could a routine perhaps be added to convert tags into formatting upon the clue being deselected?
I think adding the complexity of wysiwyg editing to clues and annos would be too much work and is not really deeply crossword-related. Of course, you've not asked for that :-)
I'll look into adding keystroke combinations (ctrl-B and ctrl-I) that will toggle \<b>\</b> and \<i>\</i> around the currently selected text fragment in the clue/anno. Caveat: I may give up on the idea if it looks like it will bring in too much code/complexity.
The clue lists not getting updated promptly seems like a bug. That I'll definitely fix.
I've fixed the anno-update issue (in my local copy, not yet published).
The ctrl-B/ctrl-I stuff requires some more thinking/discussion/research. In Chrome, there's already a built-in editor that does reasonable things with ctrl-B, ctrl-I, ctrl-U. It's very tempting to just leverage that (that would turn the clue/anno text spans into wysiwyg-editable areas, adding very little complexity to my code).
The problem is that Firefox does not behave the same way (ctrl-B opens a Bookmarks panel :-)). Looking to see if there's a way to coax Firefox into behaving the same way.
Thanks for the fix, I look forward to that getting published.
It's clearly possible to usurp key combinations in Firefox – I just italicised ‘possible’ with ctrl-I – but I have no idea how difficult implementing that would be. Are there no open source WYSIWYG libraries you could use?
Thinking about it some more, although it would be nice to use the standard text formatting key combinations, I'm sure users could easily get used to different ones if necessary. AFAICT in Firefox there is no default action assigned to Ctrl-Alt-B or Ctrl-Alt-I. Ctrl-Alt-S doesn't seem to do anything either, so maybe that could be used for strikethrough? It's also occurred to me that I use the definition highlighting tags – \~{definition}\~ – in every single clue, so maybe the clue text area could have Ctrl-Alt-D to add those?
Interesting.. I arrived at similar conclusions :-) and had implemented ctrl-alt-B/I/U.
I've added ctrl-alt-S looking at your message now (which is different as ctrl-S is not "strikethrough" in Chrome, whereas ctrl-B/I/U are bold/italic/underline in Chrome).
I don't think I should do ~{def}~ with ctrl-alt-D as for the other commands I can now use the native wysiwig-editing in the browser, whereas for ~{def}~ I would have to implement something new.
One positive (mostly, I think) side-effect is that you can now add line-breaks too, for poetic clues.
Please take a look at my draft here. I'll check it in after more testing, tomorrow. If you find some issues, lmk.
https://viresh-ratnakar.github.io/exet-test.html
(Looks like github pages is slow to publish new files right now. The link currently 404s for me. Hopefully it will come up soon enough).
Aargh… I've tried testing with your draft site and it seems I was wrong about Ctrl-Alt-I doing nothing. Unfortunately, I previously only tested it in Firefox outside of a text area, where it had no noticeable effect, but within text areas it just overwrites the selected text with an accented ‘í’. This is apparently a Windows ‘feature’ to add a grave accent to any vowel, so Ctrl-alt-U doesn't work either I'm afraid. I already knew the right Alt key (Alt Gr) + \<vowel key> did this, but it transpires Ctrl plus the left Alt key does the same thing. Who knew?
Ctrl-Alt-B and Ctrl-Alt-S seemed to work, although I also found a weird issue with these: intermittently – I'm afraid I can't reliably reproduce this as yet – after toggling the style on/off the text becomes deselected and focus either leaves the text area altogether or the caret jumps to another seemingly random point within it!
I'm sorry this has turned out to be so much more complex than I anticipated. Perhaps another approach is warranted: instead of trying to reinvent the wheel, leave the text areas as they were but provide an adjacent button that pops open a frame with the content copied into a full WYSIWYG editor like Quill, say? That way all of the cross-platform work has already been done for you and the formatted text can be just copied back or cancelled.
Well, updates on this :-).
Re: using Qull or some other wysiwyg editor: I'm really really reluctant to do that. For both Exolve & Exet, I've tried to maintain zero dependencies on packages/frameworks/libraries. A quick summary of the rationale is that dependencies create complexity, make it hard for the developer as well as user (version conflicts, updates, obsolescence, etc.), and generally lead to headaches over time, especially so for web apps. Of course, I appreciate that this over-cautious approach may not be the best choice always. I can imagine making an exception for some very stable and limited library that I can completely copy into my code (with due credit given, of course), such as, say, some small function to compute MD5 checksums.
OK, given that contenteditable had taken me fairly close to a good wysiwyg editor, I played around and improved the situation quite a bit. I got rid of the keyboard shortcuts and added buttons. I solved most of the cursor-jumping issues. I had fun, and here's the current state: https://viresh-ratnakar.github.io/exet-test.html
But here now is the bad news. I think the added complexity is not worth it. Especially as Document.execCommand() has recently been classified as deprecated. This was the key enabler for wysiwyg editing (though I'm sure Quill etc. will update their code and work around it).
I think I will retreat to my position that most general rich formatting is not really core to constructing crosswords. One can always add HTML to the generated Exolve file. However, adding crossword-specific short-cuts, like these, is probably a better idea:
And I'll go back to the raw HTML being visible and editable in the clue and the anno.
Of course, am happy to discuss further :-)
I like the buttons on your test site and I could live without the keyboard shortcuts if they're really too complex to be worth it. They would be a nice touch of course, especially for people like me with a general aversion to needing to click on things while I'm typing, but it's not like I'm writing crosswords on a daily basis – others may be, I don't know – so it's not the end of the world.
As for the zero dependency stuff: I knew you wanted that in Exolve and I agree it makes perfect sense for that project which users are expected to download and install to their own hosting environs, but I'm not sure I understand why it's quite as important for Exet. I would have thought most users would treat it as a service and just use your installation rather than download it for themselves. At least that's what I've been doing, but it's possible I've misunderstood something and I'm doing it wrong?
I think the main reason I hadn't clocked your desire to avoid dependencies in Exet was the fact you have lots of third party sites embedded and hooked up to in the assistant tabs below. In hindsight I guess there's a distinction to be made between framed external content and embedded code libraries, although I confess I'm getting a little out of my depth here.
Anyway, if you change your mind, there is another open-source editor I found called SummerNote, which has a rather nice option you may be interested in – and/or could perhaps borrow from – called ‘Air-mode‘, which ‘pops up‘ a button toolbar upon selecting text rather than displaying it permanently. See the example given here.
I have pushed out v0.34 that implements some formatting shortcuts, PTAL.
I liked the idea of only displaying the formatting shortcut buttons when some text has been selected, and have implemented it like that.
I was also able to get keyboard shortcuts to work (it was only a matter of suppressing their default actions, which I did and is fine as those actions are only suppressed when you're editing a clue/anno).
I did not go for WYSIWYG editing because of issues noted earlier. However, I added a panel showing a rendered preview (shown when you hover on the button).
Please do go through the documentation updated here: https://github.com/viresh-ratnakar/exet/blob/master/README.md#formatting-clues-and-annotations
Thanks for prompting this! Suggestions for improvements are welcome, as always.
Ha, I knew you'd like the pop-up button bar idea! It keeps the interface nice and clean until/unless it's needed. The CAP and AlTs buttons are a nice touch too.
And that's great news that you've figured out the keyboard shortcuts. Dinosaurs like me will be celebrating up and down the land! :\^)
I do seem to have a couple of minor issues though:
I was going to suggest you could probably fix both issues by making the clue editing area as wide as the tabbed area below the grid, but then I realised that with the window wide enough you move that tabbed area up and alongside the grid, so that wouldn't work. Short of keeping the tabbed area below, I'm not sure what the answer is, but I'm sure you can figure something out…
"Tabbed area below the grid" :-) I guess I've been oblivious to this and have been working with my own set-up's screen/window resolution, where the tabbed area is to the right of the grid (see screenshot shown in the README file: https://github.com/viresh-ratnakar/exet/blob/master/starting-screenshot.png).
What's your typical screen/window width & height? You can open a JavaScript console in the browser with ctrl-shift-I and type window.outerWidth and window.outerHeight to get them (my set-up has 1600x872). Can you also perhaps share a screenshot of it? I'll try to mimic it and then hopefully fix the issues that you see.
Yeah, I'm probably not a typical user as I really don't like running any application full screen. I'll have them full height, but I like to save room on the right for e.g. popout video/info windows, small utils, etc. So my browser window is 1100 wide x 1200 high.
Rather than give you the clue from the new grid I'm currently working on – just in case you want to solve it when I eventually post it to reddit – I've used an old AOTW clue of mine with fully explained anno:
As you can see, there is no button bar visible and the whole section is overlapping the grid. Interestingly, however, I initially put it into an across clue and that still didn't show the button bar, but it didn't overlap onto the grid, instead it went up off the screen.
By the way, I was also thrown a bit by the input caret being positioned to the right of the closing tag after formatting operations. I can see the logic of what you've done, but I was expecting selected text to remain selected. I think that's the usual convention in editable fields, the rationale being that you can toggle it back straight away again if you don't like the look of the edit.
I've pushed out a new Exet release (v0.35 -- actually also needed a couple of tweaks in Exolve, pushed out in Exolve v1.09) to address these issues. PTAL. Here's a copy of the CHANGELOG:
That's all excellent work, thank you! Making the clue editing section fixed height with a scrollbar when necessary is the perfect solution. I realise my usage may be an edge case for desktop computers, but I imagine users with small screen laptops or tablets would have had similar issues.
It's a good idea to grey the underlying title/setter/preamble fields when they're overlapped, but I think it still tends to look a bit confused. It also detracts from the formatting buttons if/when they appear. I wonder if hiding them behind an access button at the top left might be a clearer/cleaner option than greying them out? Just a thought…
Thanks!
I'm not enamoured of the idea of hiding the title behind an access button: I like the title to be present, as a reassuring reminder of which crossword I'm working on. Also, the narrow layout is (I think) not the typical use-case. But I do agree that the blurring wasn't doing enough to reduce clutter.
I've pushed out another update (v0.36) to improve the blurring in a few ways: the grayed out text is much more closer to white now, the outline is gray instead of green, and spellcheck has been turned off in those elements, removing any squiggly underlines. Also, overlap detection is now more aggressive, aware of the possibility of format buttons appearing on top.
(FYI: github pages is lagging, v0.36 has not yet propagated. Soon enough, hopefully).
Fair enough. I'm just pleased that you've managed to get everything done that I asked for and more! So thanks again for making it work. I think it's a big improvement to Exet's usability.
I often use bold, italics, strikethrough, and external links – mostly in the anno, but occasionally in the def too – and it's a pain having to type out the HTML tags manually. In fact, for anything complex, such as aLtErNaTe formatting, I still open VSCode and use multi-select and ‘Emmet Wrap with Abbreviation’ to do the work.
But since the goal of Exet is presumably to eliminate the need for external tools, could you perhaps provide keystroke combinations and/or buttons to insert – or better still, toggle on/off – these basic tags around any selected text?