feature(parser/render): Multiple roles for images. #669
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This also includes bug fixes for parser. We've tried to
emulate most, but not all, of the quirks found in asciidoctor
with respect to images.
(Following commentary not in the git log:)
This PR refactors (and removes) some of the logic intended to make verseblocks and quoteblocks work like asciidoctor. Apparently asciidoctor treats [quote] differently from [verse] when process image blocks. Both of these cases are actually pathological, since imageblocks should never be the content of a verse or a quote (the result was actually undesirable as well -- leaving source markup in the output). In order to bring some sanity, we treat them both the same, and assume that any attributes ahead of an image:: block really are meant to apply to the image.
We also noted that the handling for inline attributes vs. block attributes is inconsistent, in strange ways. Both use the positional parameter as the "alt" for the image, but inline does not permit shorthand role or ID elements (I think this was noticed as a bug that I filed against asciidoctor), and the 2nd and 3rd positional parameters for height and width are only honored in the inline attributes (in block attributes they are ignored.)
Trying to find some sanity here, we opted to consistently treat the 2nd and 3rd parameters as width and height, regardless of where they are. We do treat the alt tag (first positional parameter) differently as that seemed like it might break existing documents if we did otherwise (though documents that rely on that might be considered defective). Note that as a consequence of this, it is impossible to apply multiple roles to an inline image. (We would encourage fixing this, and making inline attributes more strictly follow the block attribute list rules -- that can be a follow up PR.)
There is some strangeness around the acceptance or not of whitespace in attribute lists. The grammar fixes here are meant to make us conform more tightly to what asciidoctor does, but again it's not 100%. The places where differ are very pathological -- and easily worked around.