(no title)
iheartmemcache | 8 years ago
Generally though, you don't need the table or graph to be "readable" if you're the one constructing the content for others to consume, since you've already modeled the structure of the content within your head. Those -item1, -item2, --subitem1 demarcations are already internalized in your head. (Though, if we're talking about a platform for capturing data/mind-mapping/outlining/note-taking, this may not be entirely true, I admit.)
Even Adobe opts for a non-WYSIWYG DITA/SGML for their professional content management systems if only because publishing a book or magazine becomes a editorial nightmare. (In publishing, they have separations of controls just like we have separations of concerns. Our graphics and front-end guys have control over the .css and what-have-you, while our data guys will have control of the schema, and our app guys will have control of the binary; likewise, they'll have someone in charge of typesetting, someone who performs the layout management so the interstitial ads look consistent within your magazines theme or whatever, someone generating the content, and then an editor who finally signs off on it.[3]) Now that I think about it, a magazine has many source-control-management problems quite similar to what we have.
Magic sequences are pretty brilliant, I'll give you that. If it 'degrades gracefully' (i.e., when copied into a standard instance of notepad.exe or Nano, it's still grokable), that hybrid solution might be the closest panacea we have. Keep on working on that project, it has tons of interesting, orthogonal avenues to explore[4]
=====
[1] https://github.com/knsv/mermaid
[2] https://www.amazon.com/3DX-700040-3Dconnexion-SpaceMouse-Pro... Pretty much the paragon of HIDs for CAD, in my limited use. For the last 10% of touchups it's second to none, but at the project level it's still slower than using the LISP derivative once you build up a sufficient set of macros.
[3] https://en.wikipedia.org/wiki/Desktop_publishing ArborText and Framemaker Server are the two industry standards at least in my experience.
[4] I.e., take say, chemists who want to share their findings with people in their dept. Being able to design their own markup for Lewis diagrams, multiple representations of orbitals, degenerates states, etc -- then have them real time render the observed values -> a generated chart rendered in a consistent theme (a la Jupyter Notebook, but..better...) I'd imagine would be quite powerful.
c-smile|8 years ago
Given HTML/CSS as input you can render it precisely (produce pixels on the screen). Mathematically speaking, the task of rendering is determined.
But WYSIWYG editing essentially is an opposite task: by given/desired set of pixels to synthesize HTML/CSS structure. And that task is not determined - different HTML/CSS constructs can produce the same set of pixels. That's why there are no acceptable/usable "WYSIWYG web site editors" - WYSIWYG is feasible only on reduced scope -limited set of HTML/CSS constructs that you can use to achieve 1:1 source/rendering ratio.
And that is what Markdown is all about, again, mathematically speaking - its rendering is in 1:1 relationship with its source.
I am experimenting with Markdown too: https://notes.sciter.com/2017/09/24/markdown/
but it is far from ideal either.
c-smile|8 years ago
As any tool it is good for its purpose. De facto it is a DSL (domain specific language) in the same way as Markdown or Emacs editing system in general.
It works if creation of graphs is what you do for living. But for occasional usage (say once in a quarter or year) people usually prefer Visio - you do not need to keep in mind (limited resource) mermaid syntax - just do drag and drop - actions common to all WYSYWYG systems.
Even with Markdown - each site has its own conventions - that's why occasional users prefer WYSIWYG if it is available.