Indeed, I think your accessibility argument is spot-on. The same issues apply for making websites accessible. Thankfully, more often than not, it behooves a site to follow accessibility, because it falls in line with semantic web design, which in turn plays better with Google. Google search, in a way, is the regulatory body to keep sites semantic and accessible.

That's true, and at some point, I assume they'll make the site play well with noscript, but they've written the new version of the site from the ground up in six weeks with ten people. I'll give them some time to get things right.

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.

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?

Do tell.

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

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

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.

You realize, many countries, most importantly the U.S., have laws regarding making web sites accessible? Section 508 requires that they work with Javascript off. This applies mostly to government sites, but was also used in a case against Target, in which Target lost and was forced to make their website more accessible.

Target's situation was a bit of a special case, however, as it has a brick and mortar store, which the court found their website was essentially a component of. If your business is completely web-based, the question of whether section 508 applies to you is, as far as I know, untested.