Tags that are void elements and phrasing content should be considered inline elements. #810
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
As discussed in #806, CommonMark lacks specifications for handling void elements. Since void elements are defined in HTML specifications as lacking closing tags, CommonMark should also define behavior that treats them specially.
Ref. https://html.spec.whatwg.org/multipage/syntax.html#void-elements
The existing specification can accommodate block elements. However, for inline elements (phrasing content), the current specification sometimes interprets them as HTML blocks, which is odd. Specifically, this affects five elements:
br,embed,img,input, andwbr.Proposed Change
As with the changes in this pull request, it is sufficient to add a specification stating that these elements should not be treated as block elements during the seventh processing phase of HTML blocks. Adding this specification alone will ensure these elements are correctly interpreted as raw HTML within paragraphs.
Adding this specification would maintain compatibility in the test suite and is not a breaking change. Implementation adjustments and additional test cases would be necessary, but these can be addressed later.
Reason for the 5 Elements
The elements targeted this time are
br,embed,img,input, andwbr.Reviewing the HTML specification, these are the only five elements among the 13 void elements that are also classified as phrasing content without special conditions. (
area,link, andmetaare excluded because they are classified as phrasing content only under specific conditions.)Ref:
While more might be added in the future, based on past changes, it's probably not worth worrying about. If we add these to the specification now, the likelihood of further changes appears to be low.
In the real world, it's rare for a
wbrelement to appear alone on a line, but for consistency in the specification, this approach is acceptable.