Empty dd tags in horizontal definition list are causing wrong order

[kapexx]

In horizontal definition lists, empty dd tags seem to have no size and are causing issues. Any dd tags following an empty one, move up so that they are displayed next to a wrong dt tag, i.e they stack on the right side, ignoring the positions of the terms.

It can be fixed by adding a clearfix:

.dl-horizontal { 
    dd { .clearfix(); }
}

[mdo]

That doesn't seem to fix it, nor would I expect it to. In addition, using a dl and not having a dd for your dt doesn't make much sense to me. If that fix works for you, continue to use it, however, we won't be changing it.

[kapexx]

Well, just as the bootstrap example shows multiple consecutive dd tags, it's also possible to use consecutive dt tags, which results in the same issue.

My empty tags are created by a cms where a user just didn't provide a description for a term. I think it's not that unusual, probably more common than multiple dd/dt tags. It implies different semantics than in the example with consecutive/omitted tags but may be easier to fix than supporting consecutive dt tags.

[BrindleFly]

Not sure why this issue is closed. Just try this simple example. You will see the "100m" appears under the dt "Shape". This can't be intentional, right?

Color:

red

Shape:

Distance:

100m

[haslinger]

@markdotto: kapep's fix actually works for me. He was not talking about a missing dd, but about an empty dd.
+1 for opening the issue again, thanx to kapep for the nice fix!

[mitfik]

Fix worked also for me. Thanks a lot.
+1 for opening the issue agian

[lamont-granquist]

just hit this bug, another +1 for re-opening it.

[lulalala]

+1 for re-opening this
related issue: #4107

[pollingj]

another +1...agree this should be fixed and the suggested fix does work

[pivotal-blueprint]

+1 here. We're having this problem, fix worked, would be awesome if this was the default behavior.

[mck-]

+1 - fix worked

[jlberglund]

+1 fix worked

[arjan0307]

+1 fix worked, please re-open this.

[cvrebert]

I would suggest filing a new issue and including a jsFiddle this time.

[phillipp]

.dl-horizontal dd {
  min-height: 20px;
}

Works too...

[hayksaakian]

my preferred fix

 .dl-horizontal > dd:after {
    display: table;
    content: "";
    clear: both;
  }

[bloomdido]

+1

It is very common to have a list of properties where the value is nil, resulting in an empty dd element. Without this fix, .dl-horizontal will completely screw the pooch in these cases.

Is there a case where adding a clearfix() here will break something else?

[vnenkpet]

+1

This should be definitely fixed. Even if it is considered incorrect to provide an empty dd tag, this is definitely an unexpected behaviour.

[humbroll]

@hayksaakian nice solution!

[webprofusion-chrisc]

This does require a formal fix. Empty dd is valid html (even if not valid semantics) and should therefore have valid rendering.

The use case for this is a page displaying data for various fields, some of which have a null or empty string value. The use of dt/dd within columns makes this type of page easy to create quickly (rather than faking a read-only form etc). This page would typically then link to an Edit feature to go to a full editor.

I used the fix suggested by @hayksaakian

[cvrebert]

This should no longer be a problem in v3 thanks to 37f4a25.

[webprofusion-chrisc]

@cvrebert that's interesting thanks, I've prepared a jsFiddle to demonstrate using 3.1.1:
Fullscreen: http://jsfiddle.net/52VtD/4017/embedded/result/
Code: http://jsfiddle.net/52VtD/4017/

[kapexx]

@webprofusion-chrisc It worked last in 3.0.3 http://jsfiddle.net/52VtD/4025/ but doesn't in 3.1.0 any more. It seems at some point the fix 37f4a25 got broken or removed.

[hnrch02]

This was fixed in b99be29 (see this JS Bin) and will ship with the next version (see #12736).

#12753, #12756: Ensure the .clearfix is applied on .dl-horizontal dd by moving it out of the media query (Less doesn't respect :extend() within media queries).

[mizzao]

I confirm this was fixed in 3.2.0 after updating from 3.1.1.

[cvrebert]

Great! Locking since this is 2 years old and resolved.