Android-FileBrowser-FilePicker icon indicating copy to clipboard operation
Android-FileBrowser-FilePicker copied to clipboard

InlineHTML <center> not treated as HTML correctly

Open ScriptPup opened this issue 1 year ago • 2 comments
trafficstars

If <center> has tags nested underneath it, the <center> tag is surrounded by <p> tags, breaking the HTML.

from markdown import markdown
text = """# My Header

<center>
Test
</center>

<center>
<div>Something</div>
</center>

<div>
Test div
</div>

<div>
<p>Some paragraph</p>
</div>

<div>
<article>Some paragraph</article>
</div>

Something else
"""
print(markdown(text))

Results in:

image

It seems like

works correctly, so not 100% why the difference.

ScriptPup avatar Sep 18 '24 00:09 ScriptPup

<center> should be treated as a block element (not wrapped in <p>). It's currently being treated as an inline element. It should also be noted that <center> is also a deprecated element that should not be used. With that said, since it is being used, maybe we should update the block element list to account for <center>.

facelessuser avatar Sep 18 '24 16:09 facelessuser

Our behavior matches exactly the reference implementation (markdown.pl). Specifically, we treat <center> as an inline tag because the reference implementation does. As the tag is deprecated, I'm inclined to not make any changes.

waylan avatar Sep 19 '24 15:09 waylan

@waylan treating center as inline is definitely a bug in the reference implementation. Yes, the tag is deprecated, but browsers will support it forever. Am I reading this correctly, that you're not considering fixing bugs that are present in the reference implementation for the sake of keeping compatibility with the reference implementation?

I'm asking, because the documentation of Python Markdown states the following goal:

Maintain a Python library (with an optional CLI wrapper) suited to use in web server environments (never raise an exception, never write to stdout, etc.) as an implementation of the markdown parser that follows the syntax rules and the behavior of the original (markdown.pl) implementation as reasonably as possible (see differences for a few exceptions).

IMHO, fixing this bug is definitely a reasonable request. Please know that I don't want to start a huge discussion – it is your project, and I absolutely respect that! I'm just interested what your long-term goal with this project is.

squidfunk avatar Jan 31 '25 05:01 squidfunk

As the tag is deprecated, I'm inclined to not make any changes.

I think it was simply a statement of 1) giving reasons as to why it is the way it is and 2) that since it is deprecated, people should be moving away and the thought was that there is not much value in changing it. With that said, it was also marked with needs-decision, essentially leaving the door a little open.

I don't think it was the end of the conversation, but little movement was made on this issue as there was no real pushback. I can put up a PR, it's a trivial change.

facelessuser avatar Jan 31 '25 05:01 facelessuser

PR up

facelessuser avatar Jan 31 '25 05:01 facelessuser

@facelessuser summed up my position quite well. As it is deprecated, I could care less if it is broken or not. I personally have no inclination to spend any time on it. The only reason I'm spending the time to make this comment is to clear up my position in general (on any deprecated elements). But, yes, If someone else wants to spend their time on a fix, they are welcome to.

waylan avatar Jan 31 '25 14:01 waylan