attr_list: add option to preserve attributes without value as-is

[FeldrinH]

Currently, if you have an attribute without value then attr_list defaults the value to the name of the attribute. For example:

[download](file.txt){download}

is rendered as

<a download="download" href="file.txt">download</a>

I would like to have an option to preserve it as simply download without value, so the output would be this:

<a download href="file.txt">download</a>

This would make the attribute list in markdown more consistent with the produced HTML.

PS: What was the reasoning behind the current behavior? I can't think of a scenario where I would want the attribute to have its name as the value.

[facelessuser]

IIRC it is simply how etree works. I don't Python Markdown especially cares about how it is output, they are just limited by the behavior of etree.

Attributes are defined with a key and value. You have to define something for the value:

>>> tag = etree.Element('div', {'download': ''})
>>> etree.tostring(tag)
b'<div download="" />'
>>> tag = etree.Element('div', {'download': 'download'})
>>> etree.tostring(tag)
b'<div download="download" />'

What's more correct? What would you suggest?

The only thing I can think of is having some sort of post processer to strip out values if desired, but then you have to know how to identify with the value is meant to be stripped or not meant to be stripped.

Anyway, I don't know that this is likely to change unless the document handler was changed and it supported a way to do what you want, and I doubt Python Markdown will be doing such a massive change like replacing the HTML handler at this point.

[waylan]

This is dependent on the output_format. Python-Markdown defaults to outputting XHTML for historical reasons and an attribute without a value is not valid XHTML. However, if you change the output_format to html then you get the requested behavior.

>>> markdown.markdown('[download](file.txt){download}', extensions=['attr_list'])
'<p><a download="download" href="file.txt">download</a></p>'
>>> markdown.markdown('[download](file.txt){download}', extensions=['attr_list'], output_format='html')
'<p><a download href="file.txt">download</a></p>'

There is an argument to be made that we could change the default here. However, we have avoided that because XHTML is still valid HTML5, but HTML5 is not always valid XHTML. If any users are still using this lib to generate strict XHML pages, then a change to the default would break their pages. However, leaving the default as-is breaks nothing while allowing those users who care to change the output to match their desired format.

[waylan]

@facelessuser as a reminder, we use our own custom serializer, not etree's built-in one. And that allows us to address things like this.

markdown/markdown/serializers.py

Lines 151 to 155 in 4260e7b

	if k == v and format == 'html':
	# handle boolean attributes
	write(" %s" % v)
	else:
	write(' {}="{}"'.format(k, v))

[facelessuser]

@facelessuser as a reminder, we use our own custom serializer, not etree's built-in one. And that allows us to address things like this.

Oh, right, I forgot about that. I'd say in modern day, XHMTL isn't used nearly as much anymore, but I get the desire to not change the status quo.

[FeldrinH]

This is dependent on the output_format. Python-Markdown defaults to outputting XHTML for historical reasons and an attribute without a value is not valid XHTML. However, if you change the output_format to html then you get the requested behavior.

>>> markdown.markdown('[download](file.txt){download}', extensions=['attr_list'])
'<p><a download="download" href="file.txt">download</a></p>'
>>> markdown.markdown('[download](file.txt){download}', extensions=['attr_list'], output_format='html')
'<p><a download href="file.txt">download</a></p>'

This inconsistency seems quite problematic. Modern browsers treat download="" and download as equivalent (AFAIK this is generally true for any HTML attribute without an explicit value), but download="download" is treated differently (it gives the downloaded file a default name of "download"). So the current behavior creates a situation where the behavior of the link changes when changing the output format from XHTML to HTML (again, AFAIK this is generally true for any attr_list attribute without an explicit value).

I argue that for consistency the default value of an attribute without value in XHTML should be the blank string (""), not the name of the attribute.

[waylan]

Modern browsers treat download="" and download as equivalent (AFAIK this is generally true for any HTML attribute without an explicit value), but download="download" is treated differently (it gives the downloaded file a default name of "download").

@FeldrinH can you point to where in the XHTML spec this behavior is specified? Or is this a situation where the browser acts correctly only if strict XHTML is used (proper headers and doc type forces browser to recognize a page as strict XHTML such that the page fails to render if the XHTML is not valid XML)? And is this the behavior for any key-only attribute or only the download attribute?

[FeldrinH]

I specifically meant that modern browsers treat download as equivalent to download="" in HTML. It is specified here in the spec for all attributes:

https://html.spec.whatwg.org/#attributes-2S

For XHTML attributes without values are not allowed, so my proposal is that download and other attributes without values should be output as download="" in XHTML, to match the behavior of modern HTML.

[waylan]

I understood you the first time. However, you are pointing at the HTML spec. If we are going to change the output for XHTML (as you are suggesting), then I want to see where the XHTML spec supports the proposed change. However, if you want valid HTML, then you should be specifying html at the output format and you will get valid HTML with no changes to the code being necessary.

[FeldrinH]

I don't quite understand what you are asking for. I am certain even without reading the spec that XHTML supports download="" and I don't see what else in the XHTML spec would be relevant.

[waylan]

So far you have not demonstrated that our output is invalid. If you can point to where the XHTML spec indicates that download="download" is invalid XHTML and download="" is valid XHTML, then we will make a change. Otherwise, we intend to leave the behavior as-is.

[FeldrinH]

Both are valid. My problem is that currently switching from XHTML output to HTML output changes the meaning of the generated HTML/XHTML document.

[FeldrinH]

[download](file.txt){download} is rendered as <a download="download" href="file.txt">download</a> in XHTML, but <a download href="file.txt">download</a> in HTML. These produce different behavior in the browser. My proposal would correct this inconsistency.

[waylan]

These produce different behavior in the browser.

Browsers only recognize XHTML as XHTML if the proper doc type is defined. Have you tested this properly? I don't know because you keep making assertions with nothing to back them up.