Raw HTML blocks proposals -- comments wanted

I’ve been working on a new spec for HTML blocks, and C code that parses it.
I have something working now in the newhtml branch of jgm/cmark.

You can see the diffs here.

Comments welcome.

2 Likes

I have removed the newhtml branch. The raw HTML spec revisions have been pushed to master, in both cmark and CommonMark. Comments still welcome, but I’m convinced that this is better than what we had.

Rule 7 for HTML blocks says that a block begins with an open tag with no other non-whitespace content on that line. I think one should exclude void elements. Otherwise this rule leads to some (at least for me) unexpected behavior since
<br> **foo**
and
`


**bar** ` will be code blocks.

Well, the <hr/> case would be covered under rule 6 anyway.
I think it’s probably simplest to treat the <br/> case the same way, as it currently is. Raw HTML should be separated from other content by a blank line.

As reported in https://github.com/jgm/CommonMark/issues/352, current spec cause wrap iframe into <p> tag (for example, when you copy code of youtube video).

IMHO it’s safe to announce iframe as block tag - i never seen it as inline element.

It would be good to get comments on this iframe issue. As noted in the issue, iframe can legitimately be used in inline (phrasing) content, according to the HTML5 spec. So it is currently treated like ins and del – if you want it to be treated as a block-level tag, put it on a line by itself. This is the consistent, principled behavior. But vitaly is certainly right that users will frequently paste iframe tags that are not on a line by themselves (e.g. cutting and pasting from youtube). Putting iframe in the list of always-block-level tags would help fix this common case. The cost would be that it would become impossible to use iframe in an inline context. This makes me hesitate – I don’t like inexpressibility. Are there any real use cases for iframe in inline/phrasing contexts, e.g. inside paragraphs?

1 Like

If anyone wish to use inline iframes in future, we could add kludge later, something like "<IfRaMe> should be inline". And now we could fly forward with blocks.

<ifRaMe> wouldn’t work, because all of our tag matching is case-insensitive.

But you could always force inline by putting the <iframe> inside a span:

<span><iframe>this is inline</iframe></span>

Just as you can now force block by putting it inside a div…

That’s implementation issue, not spec issue. Can be solved. But i don’t think anyone will really request inline iframes support. IMHO it’s safe to announce iframe as block tag, and i’d suggest to do it as soon as possible.

I’d still like to know whether there are legitimate uses of iframe in inline contexts (and how common they are).

I found a few examples. Only the first of these really needs to be in a paragraph:

In theory, users can insert inline buttons and prices. But IMHO that’s very bad and non-semantic markup. Also, iframe freeze page rendering (it’s not lazy). Users, who do such tricks are usually unexperienced and don’t understand what they do.

Wrapping <iframe> tags in a <p> element makes it very difficult to style at times, especially since you can’t modify a parent tags CSS definition based on the inner tag.

I used to work for Condé Nast helping to move their Traveler website onto a new publishing platform based on markdown. In the process I had to convert all the old HTML into markdown so I wrote Dr Sax to help with this. We noticed though that markdown renderers that added <p> tags made the pages flow poorly due to the CSS definition we had for the <p> tag, creating a ton of styling meant for paragraphs to be applied to the iframe.

We ended up using marked which “conforms” to Gruber’s original implementation by NOT wrapping the <iframe> tag.

Additionally, it makes it very hard to round-trip markdown to html and back again since it starts adding duplicate line-breaks to the source which continue to grow

I have made the change, adding iframe to the list of block tags.

1 Like