4 ms·

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

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.

pikzen 11y ago
>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?
- moron4hire 11y ago
  Have you read a lot of C++ code? That's exactly what people do, especially in the embedded world.
  - pikzen 11y ago
    >especially in the embedded world. 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 ?
    - adrusi 11y ago
      No. 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.
      - nly 11y ago
        > 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).
    - pikzen 11y ago
      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.
  - spinlock 11y ago
    Isn't that the old joke about C++: no one uses more than 10% but every team uses a different 10%.
- deleted 11y ago
  [deleted]
- watersb 11y ago
  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.
CM30 11y ago
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.
kabes 11y ago
In addition, a lot of selectors used are known to be quite slow (compared to just adding another class).
na85 11y ago
As a web user, I wish fewer developers thought like you did. The web is better without JavaScript. I can't wait until it is looked down upon as hamfisted and passé, as Flash is now.
- jaywunder 11y ago
  Why is the web worse with javascript? I think one if the main reasons flash was bad because it's proprietary, whereas js isn't. Also, you didn't address any of OP's points about the separation of styling and function.
- orthoganol 11y ago
  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.

pikzen 11y ago

>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?

moron4hire 11y ago
Have you read a lot of C++ code? That's exactly what people do, especially in the embedded world.
- pikzen 11y ago
  >especially in the embedded world. 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 ?
  - adrusi 11y ago
    No. 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.
    - nly 11y ago
      > 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).
  - pikzen 11y ago
    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.
- spinlock 11y ago
  Isn't that the old joke about C++: no one uses more than 10% but every team uses a different 10%.
deleted 11y ago
[deleted]
watersb 11y ago
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.

CM30 11y ago

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.

kabes 11y ago

In addition, a lot of selectors used are known to be quite slow (compared to just adding another class).

na85 11y ago

As a web user, I wish fewer developers thought like you did. The web is better without JavaScript. I can't wait until it is looked down upon as hamfisted and passé, as Flash is now.

jaywunder 11y ago
Why is the web worse with javascript? I think one if the main reasons flash was bad because it's proprietary, whereas js isn't. Also, you didn't address any of OP's points about the separation of styling and function.
orthoganol 11y ago
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.