Tony, Thanks for the pointer. The extension uses CKEditor4 which we decided against because it is pretty heavy weight and used iframes, making styling consistency more difficult. I see that CKEditor5 which does not use iframes is now available. We might look into CKEditor again although they make it difficult to look at the code if there are problems. The editor we chose, Quill, <https://quilljs.com> is relatively lightweight. Plus, I think the argument for their internal document model rather than just using html is good.
I can address your point about things getting messy when using the jupyter-wysiwyg extension that tries to keep everything in markdown and the questions others have asked about why I think jupyter needs a new cell type simultaneously. I have been thinking about this very seriously as I play with and debug the code we have written so far. I too would prefer not to change the notebook format if possible. However, I have concluded that if we want to continue making Jupyter easier to use and have it be useful over the long haul the notebook format will have to continue to evolve. Ease of use considerations: 1. As you (Tony) have noted things get very messy in a markdown cell if you try to include formatting beyond the basic formatting supported in markdown. This is a problem for lots of users. Only if you are comfortable writing and editing html and are familiar with all the css embedded in Jupyter does this work OK. Others (including myself) find it frustrating to get the formatting I intend. 2. Unless you use markdown a lot it is easy to forget exactly what to do to get specific formatting. I and many users of Jupyter do a lot of other things and only use Jupyter for cases where we need to do particular kinds of coding or data analysis. This means making useful annotations in the notebook is almost always a frustrating experience. Also having to execute the cell to see if the formatting is what you actually want is frustrating. This is where WYSIWYG shines. 3. I think we want people to be able to concentrate on the work they are trying to do in Jupyter. Some examples where I do not think the users are likely to be interested in writing html code, but may need to format explanatory text more extensively than can be done with pure markdown: data analysis, code development, and my use case. My use case requires undergraduates to answer questions in a Jupyter notebook used for direct collection of lab data into the notebook. Freshman students taking chemistry do not need the added cognitive load of having to learn markdown to provide answers to chemistry lab questions. Additionally, the instructors who create the worksheets want to be able to use more formatting of their instructions than is available in markdown and do not know how to code html or markdown. 4. From a user perspective I do not want a cell that I just edited using full WYSIWYG editing to open by default as a markdown cell. I want it to open as a full WYSIWYG editor when I double click on it. To be consistent with the way Jupyter works this means that the WYSIWYG cell is a different type of cell and as such has to be defined separately in the notebook format. 5. Related to the issue above is that getting clean conversion back and forth between markdown (with embedded html) and WYSIWYG is not easy. This stems in part from the ambiguity (which provides flexibility as well) of html. If the cell types are different, people have to explicitly choose to convert between the two and are more likely to accept and be prepared to deal with small inconsistencies. 6. The above also suggests that to make Jupyter easier to use Jupyter should also support a toolbar (that can be hidden) for markdown cells containing buttons and menus for just the formatting options markdown supports. Github does something like this. As part of the idea of markdown is that you can "just type it", I am not sure that a WYSIWYG version of a markdown cell is appropriate or necessary. I think WYSIWYG should be reserved for a rich text cell as done in the Jupyter fork I am working on. Jupyter longevity considerations: 1. The currently chosen json format for the stored notebooks is admirably flexible much as xml/html and likely to have good longevity. The only issue I see is that people might want an automatic way to bundle up external files used in a workbook, sort of a zip archive. Embedded images are already handled cleanly as base64 encoded binary in the json strings. 2. The major issue is with the cell definitions. The idea of a code cell probably has staying power. However, a markdown cell is dependent upon a very specific type of coded input. Based on the number of text formatting schemes I've seen in my 35+ years of using computers, I do not have much confidence that markdown will be particularly popular in even 5 years. Therefore, to remain relevant long term, I believe that Jupyter will eventually have to add a cell type to replace markdown. 3. I do not think any of us can predict exactly what future needs will be. Jupyter should be prepared to update the kind of cells it handles while maintaining the ability to open older cell formats and convert them to newer formats when appropriate. 4. As presently coded the notebook format that includes the WYSIWYG cell accepts all V4 cell formats without any conversion. Additionally, the python code is available <https://github.com/forgeworks/quill-delta-python> (although not yet implemented in Jupyter) to convert the WYSIWYG json code into html that can then be used to make a markdown cell when downgrading to V4. The key idea is that although this adds to the specification of a notebook it does not take anything away. If we were to default to opening unrecognized cells as rawNBconvert, older versions of Jupyter could open this extension without problems as well (is there a security reason for not doing this?). In conclusion based on ease of use and longevity I think the Jupyter notebook and Jupyter need two changes: 1. Addition of a toolbar to markdown cells. 2. Addition of the new cell type WYSIWYG. Jonathan On Tuesday, August 6, 2019 at 12:00:28 PM UTC-5, Tony Hirst wrote: > > Just for completeness (?) on this thread in sense of cross-referring to > other attempts at notebook wywiswg tools, I'm not sure how the > https://github.com/genepattern/jupyter-wysiwyg extension handles things > (it seems to drop HTML into an enabled markdown cell, which can get really > messy after a bit...) > > --tony > > -- You received this message because you are subscribed to the Google Groups "Project Jupyter" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/2f8b6e45-84fb-41fc-b88a-29bd70f1da75%40googlegroups.com.
