list based slider - Githubissues

qasimalyas commented 10 years ago

From the time i've spent so far with the plugin I think its great and very flexible. I have however run into an issue which, whether this is or not.

It doesn't seem that one can create a slider based upon an unordered list:

<ul>
    <li>item one</li>
    <li>item one</li>
    <li>item one</li>
</ul>

Is there a reason for this? Would be nice if markup didn't matter.

willdavidow commented 10 years ago

You can do this already, you just need to use the 'slide' config option:

$('.slider').slick({
    slide: 'li'
    // other options
})

http://jsfiddle.net/davewillidow/z943d/3/

qasimalyas commented 10 years ago

Ok that works but it kind of destroys the semantics of the markup. The generated output is now:

<ul>
    <div>
           <div>
               <li></li>
               <li></li>
               <li></li>
           </div>
    </div>
<ul>

kenwheeler commented 10 years ago

Those div elements get wrapped around your stuff after the page loads, via JavaScript , so anything that measured semantic value would never see it.

MattDiMu commented 9 years ago

@kenwheeler I doubt, that "anything that measures semantic value" never sees the generated dom:

Crawlers from google DO execute JavaScript
the accessibility api from modern browsers is based on the dom, not the source code, afaik
the browser itself: according to MDN, li MUST have ul/ol/menu parent elements: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/li

IMO there should be a way to stay semantically correct when using slick on lists (which are probably most slideshows).

kenwheeler commented 9 years ago

Crawlers do not execute javascript, they have an escapedFragment callback that allows developers to serve a rendered page independently of the original source

MattDiMu commented 9 years ago

@kenwheeler thx for your reply. I still think, however, that (at least Google) does nowadays execute JavaScript when crawling:

Traditionally, we were only looking at the raw textual content that we’d get in the HTTP response body and didn't really interpret what a typical browser running JavaScript would see. When pages that have valuable content rendered by JavaScript started showing up, we weren’t able to let searchers know about it, which is a sad outcome for both searchers and webmasters.

In order to solve this problem, we decided to try to understand pages by executing JavaScript.

Source: http://googlewebmastercentral.blogspot.co.at/2014/05/understanding-web-pages-better.html

paslandau commented 8 years ago

@kenwheeler fyi escapedFragement is deprecated since a few days ( see http://googlewebmastercentral.blogspot.de/2015/10/deprecating-our-ajax-crawling-scheme.html ).

Cheers Pascal

qikkeronline commented 8 years ago

I also believe this should be adressed, I think a semantically correct output regardless of wether crawlers do not parse the JS would be great (wich they do for quite a while already). Another use case: people with screen readers.

qikkeronline commented 8 years ago

Wouldn't a simple config flag do the trick? All we need to be able to do is set the .slick-track element type e.g. trackType: 'ul' or so

lsterling03 commented 8 years ago

I arrived here looking for this solution as well. I agree with qikkeronline -- would be great to be able to set the slick-track element as a ul to keep it semantic with the li slides.

schnubb commented 7 years ago

so, any chance to see this issue reopend with an updated pov from today?? :) @kenwheeler your statement was right, two years ago, but today is another time.

qasimalyas commented 7 years ago

@schnubb I personally do think that this should be reopened and addressed. Personally i've moved on to using other solutions which keep original HTML structure and with options provide aria support too.

greenandlonely commented 7 years ago

Adding my name to the list of people who'd love to see this addressed. Slick is great but, for me, this is the only flaw.

MichaelJGW commented 7 years ago

+1

kenwheeler commented 7 years ago

Ok gang, sold.

kenwheeler commented 7 years ago

@simeydotme @leggomuhgreggo thoughts? should we let any tag be specified and then just hit it with a couple of styles that undo any tag based style defaults that could disrupt things? Or just switch to uls? or make it an enum?

simeydotme commented 7 years ago

I don't know man... if you allow <ul> and <li> I can see the plethora of issues relating to padding/margin cockups by over-zealous frameworks 😛
That said, however, maybe set an option for slick-track to be a dom-reference, and if it is, it's direct-children should be the slides? (as https://github.com/kenwheeler/slick/issues/212#issuecomment-222533953 said) Still need to wrap it in a container, though

footnote: anyone talking about semantics should take a long think about having a carousel on their site. usability, readability and accessibility should be higher up your concerns than semantics of lists 😆

kenwheeler commented 7 years ago

lol

qikkeronline commented 7 years ago

<sarcasm> @simeydotme So you're contributing to a caroussel js repo, but you think that serious developers shouldnt use a caroussel at all? That seems like a constructive relationship. </sarcasm>

Adding this feature will only improve accessibility IMHO. An <ul> is much more screenreader friendly then a couple of nested <div> elements.

I agree, usability, readability and accessibility are valid concerns. But that's what we're trying to improve here right? I believe carousels have become a valid UX pattern and users by now know how to use them, so we can't simply say "serious developers shouldn't use a carousel" anymore.

To me there are 2 valid choices here:

Simply adding the option to just pick the .slick-track element could suffice. So don't reset the styles of the <ul> and <li> elements. If the developer has the insight that his carousel needs to be more accessible / he doesn't like the semantics of it, then I also think he would get around resetting those styles himself.
Make Slick use an <ul> element by default, and do reset the styles. Possibly still add the option for people to be able to set the slick-track element (just for customisation purposes). Personally I'm all up for this, as it would improve accessibility for everyone implementing Slick from here on.

Rafaelki commented 7 years ago

Thank you for reopen this issue. I made the trick basically modifying the line 521, wrapping the element with the slick-track div instead of appending it: _.$slideTrack = _.$slider.wrap('<div class="slick-track"></div>').parent(); Then with some changes here and there I make it work with perfect semantics. I have only tested this parameters: dots:true, arrows: true, slidesToShow:4, slidesToScroll:1, autoplay: true, autoplaySpeed: 4000, vertical: true/false, slide: 'li'. I hope this help. slick.js.txt

johnrom commented 7 years ago

Here's my two cents (glad to see this reopened). This shouldn't introduce any breaking changes to existing sliders. I think it's important to accept a callback function for this in the event that sliders cannot be identified otherwise (think CMS widgets).

The Source

<div class="slider">
    <ul class="slider__list">
        <li class="slider__slide">
            <img src="/image.jpg" alt="">
        </li>
    </ul>
</div>
<script>
    $('.slider').slick({
        track: function() { return $(this).children('slider__list'); }
        // etc
    });
</script>

The Result

<div class="slider slick-initialized slick-slider">
    <div aria-live="polite" class="slick-list draggable">
        <ul class="slider__list slick-track" style="opacity: 1;" role="listbox">
            <li class="slider__slide slick-slide slick-cloned slick-active" role="option">  
                <img src="/image.jpg" alt="">
            </li>
        </ul>
    </div>
</div>

Option accepts: selector, element, jquery element, callback

track: '.selector' track: document.getElementById('selector') track: $('.selector') track: function() { return $('.selector'); }

leggomuhgreggo commented 7 years ago

@johnrom definitely think that's the best approach. I can't say this is at the top of our list of priorities and I'm wary of expanding the API, but if you whipped up a PR I think it could work.

Thanks!

congson95dev commented 5 years ago

@johnrom solution doesn't worked for me.

johnrom commented 5 years ago

@saxsax1995 my comment above is a suggestion for how the API for this could look. I have a PR that implements this, but it was never merged in.

garrettrathbone commented 5 years ago

Has there been any progress on this and getting the PR merged in?

puttykitties commented 5 years ago

5 years and ongoing, is this supported now and any progress made? Thanks for the hard work though.

johnrom commented 5 years ago

I haven't heard anything and I've migrated to using component based sliders like the creator of this project's own https://github.com/FormidableLabs/nuka-carousel

Honestly, I think this project will need to be deprecated as the majority of major organizations (who support development) will have moved on to component-based Angular, React, Vue by now.

Just my opinion and may not be shared by the author.

babymamapat commented 3 years ago

This should be solved by now :/

kenwheeler / slick

list based slider #212

The Source

The Result