feat(nuemark): inline span support, inline and block html nuemark tag support

[nobkd]

Adds basic support for inline spans:

• hello [.green "*content*"] etc -> hello <span class="green"><em>content</em></span> etc
• hello [.myclass] -> hello <span class="myclass"></span>

Adds support for native html tags with block and inline nuemark tags:

• hello [del "content"] -> hello <del>content</del> (inline)
• [del "content"] -> <del>content</del> (empty block with _ attribute)
• [section.sub]\n hello -> <section class="sub"><p>hello</p></section> (block)

---

to be done:

• inline span support, through anonymous tag (hi [.classname] -> hi <span class="classname"></span>; hi [.c "hi"] -> hi <span class="c">hi</span>)
• other inline html tags ([i "content"] -> <i>content</i>) (without manual component)
• other html block tags for block scope nuemark tags (without manual component)
• test custom attributes on nuemark html tags (a [.hello world "content"] -> a <span class="hello" world>content</span>)
• fix lone/starting unordered lists for named tags (maybe other pr? See feat(nuemark)!: proposal for unambiguous nuemark yaml tags #476)

[goblinfactory]

Are the quotes entirely necessary?

hello [.green "*content*"] etc -> hello <span class="green"><em>content</em></span> etc

could also be made to work as follows, without requiring quotes

hello [.green *content*] etc -> hello <span class="green"><em>content</em></span> etc

Which is cleaner and easier to read when there might be use cases where a lot of tagging of content in a particular paragraph is required.

[nobkd]

Yes, you need the quotation marks, though you can also use single (') ones. otherwise it would be an html attribute. (though I'm not sure, if it gets rendered.)

If you have e.g. an emphasis around the content, it might work (on single words?), but i wouldn't bet on it.

[nobkd]

Added support for native html tags using nuemark tags

Edit: Lone lists will still fail, even with the fix from #472. I might take a look in or after this one.

[tipiirai]

Looks solid. So block tags are still rendered as divs by default?

[nobkd]

The anonymous / unnamed block tags? Yes.

[goblinfactory]

Yes, you need the quotation marks, though you can also use single (') ones. otherwise it would be an html attribute. (though I'm not sure, if it gets rendered.)

If you have e.g. an emphasis around the content, it might work (on single words?), but i wouldn't bet on it.

Hi @nobkd I'm not saying it shouldnt be this way, just wanting to know why?
I dont see how it should be an html attribute, can you provide an example to show what you mean?

e.g. do you mean?

hello [.green foo bat "*content*"] -> hello <span class="green" foo bat><em>content</em></span>

or something else?
My noobie brain is wondering why it can't simply work as follows (below); this seems intuitive.

hello [.green foo bat *content*] -> hello <span class="green">foo bat <em>content</em></span>

I'm sure I've misunderstood so just hoping you can clarify with a simple example, txs,
A

p.s. My reaction to the "" around content, is that it suggests that CONTENT must sometimes look like programmer strings and other times must simply be content. Attributes are uncommon in content, so the default rule in my opinion should be that "content" is never quoted inside markdown, unless you're deliberately disambiguating something, e.g. a span where with attributes (the exception, not the rule), so the exception becomes

this is [.drop drop-here "*drophere*"] -> hello <span class="drop" drop-here><em>drophere</em></span>
Please forgive the awful example.

This would be ugly to read inside markdown, but would leave the "normal" case much easier to read, when you simply want to [.red highlight] a particular word in a secondary or other styling that double star (**) would work.

Compared to ;

This would be ugly to read inside markdown, but would leave the "normal" case much easier to read, when you simply want to [.red "highlight"] a particular word in a secondary or other styling that double star (**) would work.

With the quotes, at a quick glance highlight looks like a special attribute, distinct from content, so that's jarring.

also, I've seen some implementations use

when you simply want to [.red]highlight[/] a particular

as an approach?

Just mentioning all of these so that we've captured the discussion somewhere and I can understand the rationale.
Txs,
Alan

pps; I know these comments are not technically related to this PR, so apologies for that, and it should possibly? be made another issue. I'll create a new issue with a copy of this depending on the reply and answer. (If we agree it's worth discussing further)

[nobkd]

@goblinfactory

Yes, exactly. Your first example shows how it is with this pr.

The non-quoting could work for anonymous / unnamed tags (though there might be some issues with parsing), but for other islands / layout components not so much, as they use mainly attributes.

I understand your reasoning, but:

1. I just built on the existing foundation and used the parsed data
2. There can be cases where these cases would be hard to disambiguate: [.myclass he said "hello"] (and yes, this is definitely a crafted example)
   • <span class="myclass">he said <q>hello</q></span>
   • <span class="myclass" he said>hello</span>

[.class]content[/] could be a way forward, but would have to be implemented, and could be hard to parse. (and is imo not really pretty) Would there always have to be an end tag, even though I maybe just wanted a empty span? Tags within tags could be hard to parse. (not even sure, if that currently works for inline)

I think a new issue / discussion for this would be better :)

---

Edit:
Vague idea: make your parsing the default for unnamed / anonymous tags, and keep current behavior for named ones. Something like:

• [.blue this is all "content"] -> <span class="blue">this is all <q>content</q></span>
• [span.blue this is not all "content"] -> <span class="blue" this is not all>content</span>

Not sure, if the same should be for anonymous block tags too, (if they have no children, of course)

[goblinfactory]

txs @nobkd Lets see after this gets merged how the usage on bigger projects feels and if it looks like it's worth discussing as a priority I'll create a new issue for discussion and copy notes from here. Txs for the work. Alan

[nobkd]

Thinking about splitting this pr in two.

One for unnamed inline spans and another one for named html tags (block and inline).

Would probably be easier to review and smaller in scope for both, even though they're tightly related.

I'll sleep this night over it, and might open 2 new PRs tomorrow, if I still think this decision is right.

Edit: also waiting what will happen with #476