Slick: Cloned slides removing IDs on nested elements

[maxence33]

I am not sure this is an actual bug or a bad configuration from me.
I tried to make slides made of multiple sub-divs : one for image, but also some for texts, etc ..
Some of these subdivs have CSS set with an ID.

My problem happens when my infinite carousel process one of these slide containing sub divs: I see the image sliding but some other content of the sub-div only appear when the image is fully slid. Same for CSS. It is processed only when the image is fully slid.

Slick 1.6.0.2

[maxence33]

I am sorry for not having developped it enough.

But I have managed to create a fiddle : https://jsfiddle.net/maxence33/g8eozw8w/1/

Maybe you can verify the issue and confirm if real bug or not ..

[leggomuhgreggo]

Thanks for the fiddle, I see what you mean. I will try to look into it more soon.

In the meantime, I'd recommend avoiding IDs if possible.

[maxence33]

Many thanks. I was wondering if it is because of using SlickNext instead of normal arrow. Not sure.
( I can create a new issue. Properly set up this time, with Fiddle, all information needed.. if you wish)

[leggomuhgreggo]

Appreciate you being willing to help. I'm realizing that this isn't quite a bug, as much as a cumbersome feature. For reasons of HTML validation compliance, when the library clones slides it removed IDs, the thinking being that there should only be one element with a particular ID.

I think a reasonable enhancement would be to snag the styles associated with an ID selector, but that's a bit hairy. It's somewhat debated, but its a generally accepted best practice to avoid using IDs in general.

I'd look into stripping them in your markup if you can.

Thanks!

[maxence33]

Many thanks. I used to prefer ID for elements that don't iterate... I will use classes instead or put the styling in the markup.

[leggomuhgreggo]

I don't feel super ideological about the subject, but, much as I understand the use of IDs in that way from an organizational perspective, I think you'll find life gets easier when you forego them, because it ends up creating problems like this, it's also slower for the browser, and complicates selection hierarchies. Moreover there's really no real difference in using the unique string identifier that you would in the ID attribute, and the same identifier's used as a class.

Best of luck and thanks

[NickHooked]

But what if you want a label and a input, in that case you need to have an id.

[jmiln]

leggomuhgreggo

In the meantime, I'd recommend avoiding IDs if possible.

I've been bashing my head against this for 2 days now, thank you for posting this... Newish to web dev stuff and holy heck this was annoying