<li> .clone(), .show() .appendTo() force-sets display to list-item

[lautaro.dragan@…]

See  http://jsfiddle.net/BHCcy/2/

Tested in -Firefox 12 -Chrome 19.0.1084.46 m -Safari 5.1.7

Not sure if bug or feature (insert fry here), but this didn't happen in 1.7.1.

[anonymous]

 http://jsfiddle.net/BHCcy/4/

Replying to lautaro.dragan@…:

See  http://jsfiddle.net/BHCcy/2/

Tested in -Firefox 12 -Chrome 19.0.1084.46 m -Safari 5.1.7

Not sure if bug or feature (insert fry here), but this didn't happen in 1.7.1.

[mikesherov]

If you call show on an item that isn't yet appended to the DOM, it will set the display value to whatever the default display for that element is. This is correct behavior and is a feature.

[rnortman]

Replying to mikesherov:

If you call show on an item that isn't yet appended to the DOM, it will set the display value to whatever the default display for that element is. This is correct behavior and is a feature.

Why is this a desirable feature? It is causing me substantial headaches, because then it overrides whatever is in my stylesheets for the element. My application often calls show/hide for elements not currently in the DOM. I could certainly redesign it not to, but why?

Why not set display to the empty string instead of setting it to the browser default? That avoids overriding stylesheets. (This is a change in behavior since jQuery 1.6, which my app was originally developed against.)

[mikesherov]

rnortman, what if you have a style rule like:

li {
display: none;
}

Setting display to empty string here doesn't show the element, to answer your question.

When an element is not appended, it is not part of the cascade, and there is no way to know that it'll eventually be appended to the set of elements that are inline-block. and not list-item.

[rnortman]

That makes sense, and after submitting my comment I ran into exactly that problem when I tried to monkey-patch jQuery to have the behavior I wanted, and ended up breaking the datepicker (which sets display: none in its CSS).

I would suggest updating the documentation of show/hide to make it clear that the behavior may be surprising if used on elements not currently part of the DOM. Or alternately, make those functions unwilling to operate on elements not in the DOM (make it a no-op with a warning logged). For my application, I am going to have to quit using JQ's show/hide and make my own routines instead -- or else re-factor the code to execute the show/hide after the elements get added to the DOM (which makes things more complicated).