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.

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.

So we compensate for a lack of CSS libraries by mixing presentation layer with content layer. Nice.

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.

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).

All CSS solutions, including yours, require vertical margins on all page elements to be 0px, which is clearly an obscure and senseless restriction.

Such as?

Sticky page footer.

That requires a whopping 3 lines of trivial css, what are you talking about?

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 :)

Do tell.

Sticky footer - an element that sits at the bottom of either window or the content area, whichever is furtherest down.

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.