2.4.2
https://jsfiddle.net/mysticatea/528857L9/1/
<dt> and <dd> without their end tags by turns in a template (except DOM template). For example:<dl>
<dt>Title 1
<dd>Details 1
<dt>Title 2
<dd>Details 2
</dl>
The DOM tree will become:
<dl>
<dt>Title 1</dt>
<dd>Details 1</dd>
<dt>Title 2</dt>
<dd>Details 2</dd>
</dl>
The DOM tree became:
<dl>
<dt>
Title 1
<dd>
Details 1
<dt>
Title 2
<dd>Details 2</dd>
</dt>
</dd>
</dt>
</dl>
Normal behavior, you should close your HTML tags.
@Kocal, no, it's not, according to the HTML specs dt and dd should self-close in this scenario, nice catch @mysticatea.
Quote from specs:
A dt element's end tag can be omitted if the dt element is immediately followed by another dt element or a dd element.
A dd element's end tag can be omitted if the dd element is immediately followed by another dd element or a dt element, or if there is no more content in the parent element.
Well, it works as expected with <li> and <p> closings, so it would make sense to support <dt> and <dd> but Vue actually asks you to not omit element closings:
[email protected]:485 [Vue warn]: Error compiling template:
<dl><dt>dt<dd>dd<dt>dt2<dd>dd2</dl>
- tag <dd> has no matching end tag.
- tag <dt> has no matching end tag.
- tag <dd> has no matching end tag.
- tag <dt> has no matching end tag.
(found in <Root>)
same error happens with <p> and <li> (even if they work).
So I am not sure if we want to add <dd> and <dt> support considering it's pretty different from existing ones and it's impossible to predict what tag is going to be returned from component when compiling the template. @yyx990803, do we want to support "correct" <dd> and <dt> behaviour?
Sure, I thought Vue.js supports auto-closing of <li> and <p>, so I opened this issue. If those are a deprecated feature, "won't fix" is no problem to me.
Just I have found it while I'm rewriting vue-eslint-parser to report HTML syntax errors in eslint-plugin-vue. This case is not a syntax error.
Technically even li and p are errors sincd Vue template compiler shows error in the console even when working as expected, I think we need to support them and disable Vue errors because code like <p><div>hey</div></p> will work as expected by HTML. I suggest supporting all html specific closings officially, but need to find out what Evan thinks about that.
Ah, sorry, I found that the behavior which reports lacking end tags as errors has been added in v2.2.0. So it looks to be going to deprecation. Please feel free to close this issue.
@mysticatea, I still it should be changed because at the moment it works differently from HTML specification, according to specs it should not be possible to have dd or dt inside dd or dt.
So, the rules about omitting end tags in HTML5 is rather case-by-case. For p and li it's more straightforward since they just close themselves when another one of itself is encountered, however for dt, dd, tr, td and options etc., each of them can be terminated by an open tag of itself or some other element, so if we want to strictly adhere to the spec we'd have to hard-code all these possibilities, which imo is not worth it just so that users can intentionally write spec-compliant but (imo) sloppy HTML.
Since we already have the closing tag warning in place, we are essentially enforcing Vue templates to be a (slightly) stricter subset of HTML, which imo is fine considering the tradeoff here.
Most helpful comment
So, the rules about omitting end tags in HTML5 is rather case-by-case. For
pandliit's more straightforward since they just close themselves when another one of itself is encountered, however fordt,dd,tr,tdandoptionsetc., each of them can be terminated by an open tag of itself or some other element, so if we want to strictly adhere to the spec we'd have to hard-code all these possibilities, which imo is not worth it just so that users can intentionally write spec-compliant but (imo) sloppy HTML.Since we already have the closing tag warning in place, we are essentially enforcing Vue templates to be a (slightly) stricter subset of HTML, which imo is fine considering the tradeoff here.