Fine tune markdown editor toolbar

[wxiaoguang]

1. Remove unnecessary btn-link muted classes
   • Link is link, button is button, I can't see a real requirement to make a button like a link.
   • If anyone prefers it, please help to show some real examples from modern frameworks / websites, how and why they do so.
   • No need to duplicate a lot of class names on similar elements
   • Declare styles clearly, for example, markdown-toolbar itself should have display: flex, but not use gt-df to overwrite the display: block.
2. Remove unnecessary role attribute
   • The role code is never executed in base MarkdownButtonElement github/markdown-toolbar-element#70
   • The markdown-toolbar-element does want to add role=button, but there is a bug.
   • So we do the similar thing as upstream does (add the role by JS), until they fix their bugs.
3. Indent markdown-switch-easymde (before it doesn't have a proper indent)

Screenshot:

[silverwind]

Just to note, the role=button is added purely for a11y. I do find the addition via JS sub-optimal when we can do the same via HTML. If the mentioned bug is fixed and the element self-sets the role, it'll be fine as well.

[wxiaoguang]

If upstream fixes the bug, or the JS code causes any problem, I will do following fix.

[silverwind]

I think we should generally prefer setting attributes via HTML. It works even when JS is disabled and is instantly correct on page load.

[wxiaoguang]

1. The JS approach is the same as upstream, it doesn't cause any problem , no performance problem.
2. It's easier to maintain, if upstream fixes the bug, just delete these 2 line JS code
3. It makes the template code clearer, no more duplicate code
4. Does "works even when JS is disabled and is instantly correct on page load" make sense? Without JS, does any button work?

[silverwind]

Keep in mind there is still a minority of users who run Gitea with JS disabled. We don't really support them, but I wouldn't make their life harder knowingly by moving stuff to JS.

[wxiaoguang]

If we want to make their life easier, for example, the relative-time component should show user-friendly date/time as its text content (at least, yyyy-MM-dd HH:mm:ss +TZ), but not use UTC ISO 8601/RFC3339 as its text content.

[silverwind]

I suppose custom elements don't work at all with JS disabled and I don't think it's worth the effort trying to render some placeholder for such cases.

[wxiaoguang]

So you see, I do not think " wouldn't make their life harder knowingly by moving stuff to JS." makes sense either.

ps: "I suppose custom elements don't work at all" , actually , the text content just works, that's the default content without JS for end users , if you want to support them.