Skip to content

Latest commit

 

History

History
126 lines (71 loc) · 9.48 KB

NOTES.md

File metadata and controls

126 lines (71 loc) · 9.48 KB
Raw

Notes

This file is a catch-all for ideas, problems, plans, and other miscellaneous notes. If something should instead be an issue, it should be made an issue.
Be aware that changes to this file might live in another branch until a release is done. (You're probably looking at the master branch right now.)

Miscellaneous

  • Update selection conversion screenshot to not be all about replies.

  • Try out MDH in other web-based rich-edit tools -- it'll surely work in some of them.

  • Test in Google Sites. I know it works to some degree, but need to fully test and document.

  • Automated test suite.

    • This isn't sexy, but important. Stuff has broken in the past because of browser changes, and it's inevitable that I'll make a change without sufficient testing everywhere. Regression tests are badly needed. (And would be good experience for me...)

  • Add a visual cue as to what action took place. Sometimes converts and reverts may be a little surprising if the user's selection is off. And sometimes their viewport won't show the entirety of what change occurred.

  • Internationalization.

  • If a selection conversion is inside a paragraph, then it shouldn't add a paragraph to the newly rendered text. That way the text flow won't be totally broken, and the user could actually render just part of a sentence or paragraph.

  • I've talked to at least one person who wants Markdown Here to be able unrender an email after it's sent. This would allow him to modify and re-send it, or allow his recipients to modify and send it.

    • This is a bit tricky, since all webmail clients (not Thunderbird) strip the data-md-original attribute from the markdown-here-wrapper element.
    • Idea: base64-encode the original MD, then set it as an inline-data src attribute for a very small inline image. The image won't display properly, of course, but the data will be intact and extractable.

  • Briefly highlight rendered and reverted blocks/ranges.

    • Probably use CSS transitions.
    • I started this in the transitions branch, but wasn't thrilled with how it worked. Might come back to it, though...

  • Add telemetry/usage statistics gathering. Optional, of course. It'd be nice to know how people use MDH.

    • Hotkey vs. button vs. context menu
    • Custom CSS?
    • Custom hotkey?

  • Detect unrendered MD when sending and warn.

Project stuff

  • Create a nicer info site than just the README (not that the README is bad, but...). Probably using gh_pages.

New renderers and render targets

Description

Right now Markdown Here takes content from a rich-edit element, turns it into plaintext, renders it from Markdown into HTML, and then replaces the content of the rich-edit element with the HTML. This flow is baked into the code.

There are at least two aspects of that flow that could be customizable.

The first is the source markup language, which is currently Github-flavored Markdown. There are many other excellent choices: Textile, ReST, LaTeX, and so on. There are also other flavors of Markdown, such as MultiMarkdown.

The second aspect is the "target", by which I mean the language that the source markup is rendered into as well as the element that the rendered value is put into. The target language is currently HTML, and the target element is the innerHTML of a rich-compose (contenteditable, designmode) element. But there have been requests (issues 36 and 43) for those aspects to be customizable: users would like to be able to render to BBCode or HTML and have the rendered value inserted as plaintext into a textarea.

Work

It will require a consider refactor to implement this, to say the least.

It'll also require some UI/UX thought and work to present this to the user in a coherent way. This includes options changes and in-app commands.

There might need to be some CSS-specific work as well, kind of how there's different CSS for syntax highlighting. Some markup languages will be special-purpose (like math stuff) and will need special/specific styles.

Maybe there should be separate projects for some of the structurally distinct components? Maybe other people could leverage, say, an email mutator extension where they just need to drop in the mutation code.

Links

  • MathJax is a JS LaTeX and MathML renderer.
  • Fountain is a screenplay markup language.

Advanced styling

My original intention with Markdown Here was make structurally complex emails easy to write and look pretty good, like I was getting with my README.md files on Github.

After seeing user Casey Watts's examples of how he uses (and styles) Markdown Here, I realized that there's another axis of functionality that MDH begins to address but could do much, much more towards: making stylistically complex emails easy to write, look great, and be consistent (over time and across people).

You still just write Markdown. While writing you might have your final styling in mind, but you have to make no extra effort.

As can be seen from Casey's examples, quite a lot of cool custom styling can be done -- and I don't think he has pushed it nearly as far as it can be pushed. There are limits, since this still has to be accepted as an email, but I think there's a lot of room to grow.

There's also an opportunity for users to share styles and themes. Casey does a rudimentary form of this by sharing his CSS via Github with the people he works with, so they can all send consistent looking email, but there's no feature in MDH at the present that facilitates this -- users are forced to copy and paste back and forth.

A small-ish point, but: There should also be the ability to fairly easily switch between themes (style sets). Users send email in different contexts and need them to look different ways.

The styling could also go beyond straight CSS:

  • Supporting LESS/SASS would be obviously good (I've wished for that already, while working on the default styles).
  • It would also be cool to provide the ability to JS pre/post-processing of the rendered output. For example, Casey wants to style paragraphs that follow a H1 differently from ones that follow a H2, but I don't think there's a way to do it without JS (although I suggested a horrible hack workaround to him).

I don't have a good sense for how widespread the appeal of this might be, but I suspect that it's pretty significant. (Although likely not so much among the coder crowd that I believe makes up the current user base.)

Lots of work.

Random

Clipboard Paste

In a Google Docs support issue (#28), a user suggested using paste to get the rendered Markdown into a GDoc. This seemed interesting, so I did some investigation.

  • Paste does work fairly well to get rendered Markdown into a Google Doc. (Although Paste vs. Paste and Match Style give different results.) Some massaging of the Markdown (<br> vs. <p>, maybe) might improve results.

  • Googling and experimentation suggests that pasting cannot be triggered from a Chrome extension. (Not to be confused with reading from the clipboard, which can be done in a background script.)

  • Pasting probably can be triggered in an old-style (non-Jetpack) Firefox/Thunderbird extension. But I suspect it can't be done in a Jetpack extension (as with Chrome).

  • (Probably also can't be done in a Safari extension.)

  • A common way for websites (including Github) to support copy-to-clipboard is to use Flash. The most popular seems to be ZeroClipboard -- but it doesn't magically provide pasting (even if I could figure out how to use it in an extension).

  • When pasting, the markdown-here-wrapper is lost. This means that reverting may not be possible (at the very least, it'll require another approach).

  • Copying arbitrary HTML to the clipboard is probably doable on all platforms (it is on Chrome, at least).

So, it seem that, at best, MDH could put the rendered Markdown HTML into the clipboard and then the user will have to manually paste it. This is not great, but is perhaps better than nothing.

Another really big outstanding question: Can MDH detect what's selected in the GDoc? Can it get the text? Can it change the selection? Can it delete or replace the selection? (Some simple getSelection() tests are not hopeful.)