Hacker News new | comments | show | ask | jobs | submit login

The objection to tables for layout was never on the basis of grid layouts being bad, it was on the basis of separation of concerns.

The primary problem with layout tables was that they involved tightly coupled inlining of your layout rules.

I have not found a project yet that I could divorce the layout from the content without the use of javascript. i gave css many attempts at this. mainly from the desire to make the content easy to manage for others. or just for aesthetics. but css was (is) too clunky to make that separation. yet people still argue that not limiting yourself to what css can provide you, thereby giving up on the purity of content vs layout separation debate, is somehow blind use of web standards. i've since assumed css's goal was lofty from the start.

Have you seen some of the amazing things that can be done even in css 2.1?

Honestly sure you need js for most interactions and animations still, but layout? I wouldn't merge any pr that uses js for layout. Including fully responsive layouts.

I'd agree it's not completely divorced, but it's much, much better than it used to be. If you've worked in environments where the only access you have is CSS (for instance, locked down CMSes, or editing subreddits), you'll find that many solutions are possible without manipulating HTML. CSS can be very powerful; especially with the advanced selectors of CSS3.

I think I'd rather just manipulate HTML with Javascript. At least then I only have one problem, which is HTML with inline styles. No separate CSS file to maintain or CSS rule precedence to worry about.

You forgot the performance problem....

And anyone who wants to browse with JavaScript disabled…

I stopped worrying about those users years ago. Don't even bother with <noscript> anymore. It's 2015 and all browsers support JS these days. If you disable browser features then you really shouldn't be surprised when functionality breaks. The same would happen if you disabled CSS or images.

Funny you should invoke turning off CSS and images -- a lot of people have actually worked pretty hard to make standards that would work for cases where visitors had them disabled, or want low bandwidth options, or had their own custom style sheets, or weren't using a visual user agent (or even, for that matter, directing the user agent manually).

A failure of function availability from turning off images or CSS is a failure of developers, not a failure of the platform or user agent. You can find sites even in 2015 that either straight up work or degrade gracefully when being browsed by Lynx (a browser that I don't think has seen even a dot-release update since 1999) because they were put together by thoughtful professionals who understand the platform.

If you're trying to deliver an application that absolutely requires client side computation or specific browser APIs, you can have a pass for choosing the have your site not work without JS.

If your site really is just a series of documents (either static or dynamically computed), though, there really isn't much of an excuse.

>a lot of people have actually worked pretty hard to make standards that would work for cases where visitors had them disabled, or want low bandwidth options

In cases like this, wouldn't it make more sense to have that information available in an API? Once you've removed all styling and interaction, it seems like something that would work better as simply sending raw data, and letting the client decide what to do with it.

Schema.org is a good example of how this would work with the modern web. Markup relevant data (eg. product ratings, movie times) and let the clients render it as desired. You can still provide CSS/JS for modern browsers.

Seems a lot more elegant to me than designing pages to gracefully fallback when JS/CSS is missing, as that would seriously restrict design.

When you say "simply send raw data, and let the client decide what to do with it," you're more or less describing the original vision behind delivering markup before we got obsessed with instructions of one stripe or another to control visual presentation.

The crucial question is probably what's considered "raw" -- or perhaps to talk more in terms of web-related philosophy, which media type you'd expect most user agents to be able to handle by default... and despite the (reasonable) popularity of JSON, the answer is pretty much HTML with some kind of microformat information embedded via attributes.

In other words, the schema.org approach is arguably pretty much what you're supposed to do in order to design pages to gracefully fall back. I'm not sure why you might think those two concepts are at odds. :)

People who disable features of their browser on purpose will always be getting a degraded experience. No way around that.

People have JS disabled without their intent. Corporate security standards, broken JS in CDN served libraries, mobile proxy browsers, the list goes on…

With the rate CSS is accumulating kludges and the fact that, when together with HTML5, it has already crossed the Turing-completeness threshold, I wonder how long it will take before companies start requiring browsers to disable subsets of CSS...

I think CSS Zen Garden still exists...

And this is absolutely the only place where "separation of content and layout" works. In real world, layout often is a part of content - but instead of accepting that, a lot of developers like to proclaim that their code is soo semantic, and the metric ton of grid layout divs in their "content" is not tables in disguise, but definitely has some important semantic meaning...

Seriously, I don't know what's more broken - CSS itself or the web developer community, with the amount of self-deception, cargo-culting and stockholm syndrome cases present there.

It worked perfectly fine for me from ~2004 and forward. I guess the bigger problem is that web tech is considered somehow not important so lots of developers did not really bother to unserstand CSS. I think around 2005 we had a golden times of the web. It went downhill since, sadly. Prolifereation of one-page web apps, stupid desire "to win mobile", mindless spawning of all kinds of frameworks turned out into complete mess :(

Funnily, 2005 was the time when people were misunderstanding JavaScript. I still have nightmares from all those animated snowflakes and rainbows following my mouse cursor, or date calculators embedded on every other page for no reason except to show off...

Unfortunately, CSS doesn't really fix that problem.

If you're writing it properly (i.e. not inline), it actually does. Even more so now with SASS & variables.

Check out http://camendesign.com/ The last time I looked it had no ids nor classes.

That's pretty nice, actually.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact