5 ms·

I'm tired of having this argument over and over again, so let's approach this Javascript issue from a different angle: It is bad practice to couple content (th

I'm tired of having this argument over and over again, so let's approach this Javascript issue from a different angle: It is bad practice to couple content (the "what") with functionality (the "how"). The content itself should not depend on how it is displayed. From an engineering standpoint, this makes your code unmanageable and unmaintainable in the long run. These stupid shortcuts of forcing users to have Javascript on just to display content only cause me minor inconvenience, but it will cause you much more harm when it's maintenance or upgrade time. But you or everyone else on the JS bandwagon don't need to listen to me - I'll "temporarily allow" only the minimal amount of scripts on your page to see what I want to see and I will move on. You will need to live with this code during the next update cycle.

eps 14y ago
There are certain design elements that translate into a single line of JS, but require a couple of pages worth of CSS voodoo. Guess what's more maintainable.
- mirkules 14y ago
  So we compensate for a lack of CSS libraries by mixing presentation layer with content layer. Nice.
  - eps 14y ago
    You brought up the maintenance angle, and the response to that is that in some cases it's far more practical to use js for atyling than to rely purely on css. I gave an example below - a sticky page footer - do show me how to do it in the confines of your abstraction model. Abstarting things for the sake of abstracting is a rather naive approach. It's a good starting point, but some abstractions complicate things way beyond what's needed.
    - mirkules 14y ago
      While I agree that exceptions in very rare cases are needed, exceptions are becoming the norm and, like I said, are coupling functionality and content. This is why CSS was created, to decouple style from content, and now? We are are throwing all that work away because an entire generation of web devs are just too lazy to look it up. By the way, a quick search for sticky page footer on Google turned up this as the first result -- no JS needed, and it didn't even look that hard (http://www.cssstickyfooter.com/using-sticky-footer-code.html http://www.cssstickyfooter.com/using-sticky-footer-code.html).
      - huhtenberg 14y ago
        All CSS solutions, including yours, require vertical margins on all page elements to be 0px, which is clearly an obscure and senseless restriction.
- papsosouid 14y ago
  Such as?
  - eps 14y ago
    Sticky page footer.
    - papsosouid 14y ago
      That requires a whopping 3 lines of trivial css, what are you talking about?
      - tripzilch 14y ago
        Not to mention, they're annoying as hell, especially on a 1366x768 screen. I wish I could get rid of them by simply turning off Javascript :)
      - eps 14y ago
        Do tell. Sticky footer - an element that sits at the bottom of either window or the content area, whichever is furtherest down.
freehunter 14y ago
What if the "what" goes hand in hand with the "how"? A distinctive layout could be of more value than the content, especially when it comes to social media (where the content is roughly the same everywhere you go). What's better, a site that doesn't display until you enable JS (then it displays perfectly) or a site that works without JS, but looks awful and drives away users? If you can't understand that the site doesn't load because you have JS disabled, you won't understand that the site looks like shit for the same reason.
mistercow 14y ago
That's a rather egregious false dichotomy. You can separate your content completely from your JavaScript code, but that does not mean that your content is formatted as plain HTML. In fact, I would argue that storing your content within a page's HTML structure while separating content and functionality is exceedingly difficult, and that if you want to maintain that separation of concerns, you need to store your data in a totally separate format, and then write code that generates the HTML structure based on that format. Then, taking that HTML and enhancing it with JavaScript (aka progressive enhancement) is also a violation of separation of concerns, and I would argue against it in any but the very simplest of cases. Instead, you should use JavaScript to operate on the raw data and display it to the user. You can then also write server-side code that generates a plain-HTML rendering of that same content, but that is more work, and that means it's a trade-off. And I think in many cases that trade-off is worthwhile. But this idea that it somehow saves you time in the long run and doesn't end up costing you is pure fantasy. >But you or everyone else on the JS bandwagon God, that's annoying. My pointing out a flaw in a particular argument does not imply that I am "on the bandwagon" opposing that argument. I think that making your content accessible without JavaScript is a good idea whenever possible, but I do not think it is useful to pretend that you can do so without trade-offs. I don't have to agree with an argument just because I agree with its conclusion.

eps 14y ago

There are certain design elements that translate into a single line of JS, but require a couple of pages worth of CSS voodoo. Guess what's more maintainable.

mirkules 14y ago
So we compensate for a lack of CSS libraries by mixing presentation layer with content layer. Nice.
- eps 14y ago
  You brought up the maintenance angle, and the response to that is that in some cases it's far more practical to use js for atyling than to rely purely on css. I gave an example below - a sticky page footer - do show me how to do it in the confines of your abstraction model. Abstarting things for the sake of abstracting is a rather naive approach. It's a good starting point, but some abstractions complicate things way beyond what's needed.
  - mirkules 14y ago
    While I agree that exceptions in very rare cases are needed, exceptions are becoming the norm and, like I said, are coupling functionality and content. This is why CSS was created, to decouple style from content, and now? We are are throwing all that work away because an entire generation of web devs are just too lazy to look it up. By the way, a quick search for sticky page footer on Google turned up this as the first result -- no JS needed, and it didn't even look that hard (http://www.cssstickyfooter.com/using-sticky-footer-code.html http://www.cssstickyfooter.com/using-sticky-footer-code.html).
    - huhtenberg 14y ago
      All CSS solutions, including yours, require vertical margins on all page elements to be 0px, which is clearly an obscure and senseless restriction.
papsosouid 14y ago
Such as?
- eps 14y ago
  Sticky page footer.
  - papsosouid 14y ago
    That requires a whopping 3 lines of trivial css, what are you talking about?
    - tripzilch 14y ago
      Not to mention, they're annoying as hell, especially on a 1366x768 screen. I wish I could get rid of them by simply turning off Javascript :)
    - eps 14y ago
      Do tell. Sticky footer - an element that sits at the bottom of either window or the content area, whichever is furtherest down.

freehunter 14y ago

What if the "what" goes hand in hand with the "how"? A distinctive layout could be of more value than the content, especially when it comes to social media (where the content is roughly the same everywhere you go). What's better, a site that doesn't display until you enable JS (then it displays perfectly) or a site that works without JS, but looks awful and drives away users? If you can't understand that the site doesn't load because you have JS disabled, you won't understand that the site looks like shit for the same reason.

mistercow 14y ago

That's a rather egregious false dichotomy. You can separate your content completely from your JavaScript code, but that does not mean that your content is formatted as plain HTML. In fact, I would argue that storing your content within a page's HTML structure while separating content and functionality is exceedingly difficult, and that if you want to maintain that separation of concerns, you need to store your data in a totally separate format, and then write code that generates the HTML structure based on that format. Then, taking that HTML and enhancing it with JavaScript (aka progressive enhancement) is also a violation of separation of concerns, and I would argue against it in any but the very simplest of cases. Instead, you should use JavaScript to operate on the raw data and display it to the user. You can then also write server-side code that generates a plain-HTML rendering of that same content, but that is more work, and that means it's a trade-off. And I think in many cases that trade-off is worthwhile. But this idea that it somehow saves you time in the long run and doesn't end up costing you is pure fantasy. >But you or everyone else on the JS bandwagon God, that's annoying. My pointing out a flaw in a particular argument does not imply that I am "on the bandwagon" opposing that argument. I think that making your content accessible without JavaScript is a good idea whenever possible, but I do not think it is useful to pretend that you can do so without trade-offs. I don't have to agree with an argument just because I agree with its conclusion.