Emphasize that that using CSS in most of these ways is terrible practice

[ZachSaucier]

CSS was made to be a styling language and to be supplementary to the markup of a page, not vital to it. Use of practices such as the checkbox hack to replace functionality that should be done using JavaScript is bad practice as it creates bad semantics, wrecking the markup of a page.

This library to should emphasize the areas where these hacks should not be used, both in the README and each demo page where this is the case.

[TheJaredWilcurt]

I think if you can represent your markup semantically and have your CSS perform the same effect as what JS would do, it's a valid use case. If there are no downsides to the CSS route.

The issue with using CSS in fringe cases is that you have to do more browser testing to verify that it works as expected in a wide variety of browsers.

I think of lists like this one as more of ideas, or seeing how far you can push something. Most of them are not great for production purposes. The carousels can't lazyload images. The games can't save your progress. These CSS only routes have limitations. So if those features it can't do are things you may want in the future, they're not a good idea either.

[ZachSaucier]

Adding extra input elements is terrible for markup... I maintain an article reading extension that looks for content in pages and most of these techniques would leave unused, unstyled, seemingly random elements in the content I'm obtaining. My project is just one example of how web pages are not always viewed using the venues we plan for.

I agree with your other points. That's why this project and the examples should have a very noticeable disclaimer so that people getting into the field realize that these are not meant for production in most cases.

[Download]

I hear mostly theoretical issues with CSS 'hacks'.

Let me give a practical upside: Time-to-Interactive, or how long it takes for a page to load.

The problem with JS is that it has to start running at some point, which can't be too early (or DOM elements will not have parsed yet) but should also not be too late (because it will kill TTI). The best thing would be to run the script for a component right after the content for it has rendered, but that would mean littering your document with inline script fragments. Still, given the choice to litter the document with scripts or making the customer wait longer (and risk him taking his business elsewhere) I'll litter my document with scripts any day.

I have been working on/with this problem for years now and you just can't do it right. Load all scripts at the end of the page (which is what most people advise nowadays) and you risk looooooong TTI if the page has a lot of content. Loading on DOMContentLoaded works cross browser, but is essentially the same; your scripts only start to run when all markup has been parsed. onLoad takes even longer than the aforementioned two. Or you can litter tour document with inline scripts.

Or, just don't rely on scripts for basic functionality unless really needed. CSS-only components neatly bypass all these issues. As soon as a component has rendered it just works. That alone makes them worth investigating.

[ajvillegas]

I agree with @ZachSaucier, not only do they create bad markup, but some of these components – mainly any using the checkbox or radio hack – are not accessible and make it impossible for keyboard or screen reader users to access the hidden content. This alone is in my opinion, reason enough to not use these components in production. I see that they did add a note to the Readme that explains this, but it should be more clear.