CSS techniques like this display some impressive ingenuity, but I wonder if anyone actually uses them in production. I would never let this kind of code into a production application because a) it mostly involves things I would call "hacks" and require other developers who maintain it to go beyond typical CSS knowledge, b) there is no separation of behaviour from styling, and reading the CSS it is not obvious which CSS rules are "just styling" and which are behaviour, and c) if and when you hit some barrier where the component/UI needs feature X and you can't do it in CSS, you need to scrap a bunch of your code.
I would love to hear from anyone who actually uses this kind of code for large web application.
Well, I've used the checkbox trick and stuff similar to that slider control on real sites. Much better to do it that way than to mess around with a bunch of extra Javascript code.
But usually, browser compatibility is the biggest reason stuff like this isn't so common in production environments. A lot of large companies use outdated browsers that don't support much in the way of modern CSS or HTML 5 stuff, and they don't usually like being told that their CSS only tab system or progress bar doesn't work in their browser cause they're using IE8 or something else that's equally outdated.
But I have used this sort of stuff before on real websites and applications.
>require other developers who maintain it to go beyond typical CSS knowledge
Maybe the typical CSS knowledge is way, way too low considering CSS itself is really not complicated and that it'd actually be a good thing that your developers actually know the language they're using, no ? You wouldn't hire a C++ guy telling you he only knows the C-compatible parts of the language, would you?
I consider myself a web front-end beginner, and I find most of this CSS to be quite readable. Certainly more understandable than some JavaScript I've been asked to maintain.
I think that web developers should spend less time playing the latest JavaScript framework, and more time getting to know XQuery selectors.
But I realize that this sounds like an "Old man yells at clouds" argument.
But then that's a very specific requirement, which pretty much requires you to use only the C features. Embedded development is probably 5% of the entire C++ jobs. Should the 95 other percent ignore C++'s features because the other 5% do ?
First of all, embedded probably constitutes more than 5% of all C++ jobs. Second, embedded is not the only area where C++ is essentially written like C. It might be changing no, but for decades, that's how most C++ was written.
In games, for example, it's common to see the only C++-specific features used being operator overloading for vectors and matrices and maybe a couple templates.
In highly-regulated safety-critical domains, the language is restricted by style guides that essentially limit the available features to a subset of C.
And beyond that, writing C++ as just "C with some extra features I want" is a popular style. GCC, for example, uses only destructors and templates, and is otherwise just C.
It's not a bad thing. It's not clear that C++ is an improvement over C in terms of ease of use or maintainability. Projects written in C++ tend to develop complexity faster than those written in C.
> GCC, for example, uses only destructors and templates, and is otherwise just C.
Well, to be fair, that's because the GCC codebase was written in C and later switched to bootstrap in "C++ mode". Introducing C++ features in to an existing production-ready, 30 year old, C codebase is not going to happen quickly. Both Clang and LLVM, on the other hand, use C++ features pretty readily.
> It's not clear that C++ is an improvement over C in terms of ease of use or maintainability. Projects written in C++ tend to develop complexity faster than those written in C.
Complex projects can grow complex because they're... well, inherently complex. So maybe inherently large, complex projects just require the power of C++?
We both clearly have a personal bias one way or the other. Personally, I despise C. As well as a lot of the things I like, pretty much everything I hate about C++ comes from C (header files, implicit integer narrowing, and undefined behaviour wrt signed types, for example.). Cs lack of power and expressiveness has also lead to pervasively poor, lazy API design (libc and most of the POSIX APIs, for instance, are total garbage).
Following up on adrusi's comment because max comment depth is reached:
But you KNOW those features. You know that you shouldn't use overloading because of perf reason A, or that templates are bad for reason B (in the case of your project). However, if you saw those two features in code, you'd know how to interpret it, how they work, etc. The typical C++ knowledge is not just C.
The OP to which I replied to implied that counter() (or any of the other features that are part of the standard) isn't typical CSS knowledge. Well then the typical CSS knowledge is terrible and should be fixed, because they're not exactly obscure functions, and CSS isn't exactly a huge monstrosity like C++ is.
I don't think taking JS out of small UI pieces is a 'victory' for those who don't like JS, since the main engine behind the JS trend is building apps with 'native experience,' single page style apps, and that's a web development paradigm in itself centered on JS.
However I do believe JS will lose most of its popularity when web technology gets even faster. The slight performance boosts that JS gives you now - which is the predominant reason it's become so popular - won't matter as much; if things are so fast that you don't need an ajax architecture, you won't need front end JS frameworks.
I came up with similar techniques, like using radio inputs as buttons etc.
I worry about implementing such techniques in production because JavaScript options in legacy browsers are clear, where nuances in CSS between browsers can be fuzzy and polyfilling CSS3 selectors is not reliable.
I made a purely css library with techniques similar to this in case anyone is interested, http://picnicss.com/ . The main shortcomming is the already mentioned uglyness of some html, but I haven't found js compatibility an issue.
For example, to toggle a button is really similar to set a rule like $("button.cta").on("click", fn); vs $("input.cta").on("change", fn);
Sometimes I think making things super "cool" actually inhibits usability. Example: The "Advanced toggle switch" shown here. To me it's completely ambiguous; I have literally no clue whether I am switching the option "On" or "Off". I've encountered exactly this problem in the wild and it may be cool but it's also incompetent.
I'll just copy and paste my response from the Reddit discussion:
Without JavaScript these cannot be web components, as there is no declarative standard for custom elements yet. You need JavaScript to at least call document.registerElement, and usually to create and populate a shadow root.
I guess the author meant UI components (widgets) which are used in web development but he called them instead erroneously web components but you're right that they are not web components in the strict sense of the term.
Do you have to manually add a list item for each slider tick? Really clever, but I hope I'll never end up as the poor sap who has to maintain this kind of code.
I would love to hear from anyone who actually uses this kind of code for large web application.