leave HTML code as is

[Pomax]

Right now, marked will convert this:

...
<div className="note">
## take note:
the following text *should* be taken into account
</div>
...

into this:

...
<div className="note">
## take note:
the following text *should* be taken into account
</div>
...

that is to say: it doesn't convert it at all. It treats the <div> as somehow being meaningful syntax rather than "just text without any markdown syntax rules that match it" and so it refuses to convert the content of that div, despite the fact that markdown has no divs: it's just inert text that needs to be preserved.

[nerai]

First of all, to have a better chance of this working, you should put an empty line between the divs and any markdown. However, as far as I know, this library does not implement the required feature, sadly.

But: This library does implement this for spans instead of divs. That may be sufficient as a workaround for you. (It even works without the empty lines I mentioned, which I guess is nonstandard, not sure.)

<span>
# a
- 1
- 2
</span>

[Pomax]

that depends entirely on how robust the parser's written to be. That said I ended up writing a chunker in the interrim that just takes the input, chops it up into parts that should have markdown applied and parts that don't, and only then runs the parts that do through the conversion library.

[matt-]

A lot of specs (actually almost all) do have "raw" html tags like divs: http://spec.commonmark.org/0.27/#example-119 and GFM:

this is in a div

That said I believe it is correct that in a code block ``` it should return the html encoded version of this as http://spec.commonmark.org/0.27/#example-88 describes

[nerai]

@matt- Those are just ..., not ```

I've looked into this some more. First of all, I'm still not sure if this library is supposed to be implementing commonmark. If it does not, then not converting markup within divs is standard behavior as far as I know, and the case would be moot.

I got some interesting results when I tested this again. Inserting OP's example literally, I could not reproduce the problem:

But when I remove the trailing ..., I get only a partial result:

More tests:

<div style="background:red">
## x
</div>
.

yields

And

<div style="background:red">
## x
</div>

.

yields

This behavior looks wrong to me. Am I missing anything obvious?

[Pomax]

The original code was for terseness, using something more spaced out like

regular markdown content

<div className="note">

## take note:

the following text *should* be taken into account

</div>

more regular markdown content

generates:

<p>regular markdown content</p>
<div className="note">

## take note:

the following text <em>should</em> be taken into account

</div>

<p>more regular markdown content</p>

with the content of the div somehow treated as "I should skip over this" by the library. The real trick isn't whether it should always do one thing or another, this should be something one can toggle, where calling something like:

const converted = marked(content, { passoverHTML: true });

makes it copy HTML tags verbatim without doing anything to them, and without recognizing content between some <x> and corresponding </x> as anything other than "more text to be converted as markdown", because there are no doubt situations in which both behaviours are necessary.

In fact, and even better result would be to have an option like passOverHTML as well as a secondary finer level control:

const moptions = {
  passoverHTML: false,
  passoverAttribute:"passover",
  stripPassoverAttribute: true  
};
const converted = marked(content, moptions);

So that the content itself can indicate what the parser should do:

<div className="note" passover>

## take note:

This section will get converted normally, and because stripPassoverAttribute:true was
used, the "passover" keyword itself will be removed from the opening tag.

</div>

And this will be left entirely alone:

<div>
# this is what a markdown header would look like
</div>

more regular markdown content

[joshbruce]

#985