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

I also find it crazy how there was a huge campaign to remove use of the table tag for layout. 'It's non semantic! You're mixing layout and content!' people would cry over and over.

.. But then we've ended up with bootstrap and it's grid layout, where we're doing exactly that, and for some reason it's perfectly fine.

The problem with tables for layout is that the layout algorithm is incredibly complex. People seem to think it's simple, because it kinda does the "right thing" in many cases, but it's actually ill-defined, varies between browsers, and has only a work-in-progress spec [1]. Width calculation is defined in terms of linear interpolation between the closest of four "candidate guesses" which bound the available width. And that's the simple case, when no colspans are involved; check the WIP spec for details on the recurring sequence that is involved when there are column spans…

Regardless of how you feel about CSS 2.1, it's indisputably better than the table-based layout we had before. Speaking as someone who has implemented both table-based layout and CSS 2.1, it's really unfortunate to see people want to return to the bad old world.

[1]: http://dbaron.org/css/intrinsic/

A basic rule of universe is that complexity remains, you can merely shift it around. The table layout algorithm might be incredibly complex, but I'd rather have a browser writer have the headaches than me.

> The table layout algorithm might be incredibly complex, but I'd rather have a browser writer have the headaches than me.

Completely disagree. The Unix philosophy is right when it comes to layout: you want to be simple, fast, and predictable.

This attitude is also why we are in a situation where the Web is slow compared to native platforms. Simple things tend to be fast things. Complex things tend to be slow things.

And the things you do to properly align stuff in CSS are anything but simple. You took the complexity from the place where it could be well-defined and heavily optimized and have it to the hands of every developer to do it in their own, broken way.

I fail to see how centering something in flexbox is complex. It's literally one property once you've switched to the new mode. And absolute centering is really simple once you understand how containing blocks work.

Your implications that table layout can be "well defined" or "heavily optimized" are both false. The problem is that table layout is ill-defined: it's really a pile of hacks upon hacks that were invented at Netscape a long time ago and still not standardized or consistent between browsers. And, speaking as someone who optimizes layout engines for a living, complexity is the #1 enemy of "heavy optimization". Spec complexity is the #1 reason why layout is so slow, because it makes layout engines large, complex, and brittle.

The attitude is the result of a thing that just keeps annoying people. It's certainly not a cause of a slow web.

Given that the problem is not simple, I'm happy to have fast and predictable.

A basic rule of universe is that complexity remains, you can merely shift it around.

You can always increase complexity. For instance, by doing all math in Roman Numerals. Thus, in at least some cases you can decrease it. So your statement doesn't hold.

I think you were referring to something like inherent complexity, but then you would have to somehow prove that all this complexity is inherent.

> A basic rule of universe is that complexity remains, you can merely shift it around.

Not really. CSS grid systems (like in Bootstrap) require some ugly and non-semantic markup, but they're not very complex.

They don't require non-semantic markup -- as I said in a comment that was downvoted for some reason. There's a whole set of best practices that people aren't mentioning in this thread.

If you write your styles in the same preprocessor as the Bootstrap package you chose (Less by default, but optionally Sass), you can mix Bootstraps grid classes into your own semantically meaningful classes, and drop all the col-xs stuff from your markup. Your markup elements can have class names that are purely semenatic. Almost every modern grid system offers preprocessor mixins that can be used in this way.

There are methodologies like BEM that are great for providing a semantically meaningful layer of classes in your markup.

It's true that the complexity remains and is shifted. The important part is that it's no longer interlaced with the complexity that describes the fine-scale structure of the page.

There have been some huge deficiencies in CSS over the years. It is frustrating to have to use complex sets of counterintuitive rules to achieve seemingly simple effects. But there are techniques for helping to manage it in modern web development.

Also, [0], since “All problems in computer science can be solved by another level of indirection, ...”.

[0]: https://www.ostraining.com/blog/coding/bootstrap-right-way/


No, what he really meant by complexity is information content - will always remain - you can compress it (akin to writing complex code) or uncompress it (akin to writing more code), but whatever you wanted to express you'll still have to express. This principle you can also find in all domain specific languages and in all frameworks that started out as easy and lightweight and become groteskly inflexible and ugly monstrosities after a while when the rest is being added to make them complete in all respects.

> because it kinda does the "right thing" in many cases, but it's actually ill-defined, varies between browsers, and has only a work-in-progress spec

Which is completely not like using CSS at all, right?

Like I said, I've implemented both. CSS 2.1 was much easier than tables. Almost everything I implemented in CSS 2.1 made sense (with some notable exceptions, such as the hypothetical box, margin collapse, and border collapse). Tables were nonstop backwards compatibility hacks.

Thank you for saying that. The last 15 years have seen tremendous heat and noise exhausted in fantastical debates the end result of which brings no obvious improvement. If we were honest, we would say something humble, such as "Sir Tim Berners-Lee is a great genius, and we are all grateful for what he gave us in 1989, however, since that time, we have learned many things, and the technologies proposed then did not give us what we actually need. HTML strains to fulfill two discordant goals, one is to give us structured documents, and the other is to give us a GUI for TCP/IP. But we now realize these two goals would be better served by two separate technologies, and HTML should be retired."

> But we now realize these two goals would be better served by two separate technologies, and HTML should be retired."

This. And the confusion around those two goals is what drives a lot of useless arguments with people who have Stockholm syndrome towards HTML and CSS. Those arguments can often be summarized like this:

- Hey, we're complicating things too much, how about just focusing on rendering a text communicating a message?

- No no no, the web is not just about documents, it's so much more now! It's about applications.

- Ok then, so let's drop the nonsense about separation of concerns, that you can have layouts separate from content.

- No no no, HTML is for describing documents, and CSS is for describing its layout!

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.

Open up any webpage and count how many divs with no other purpose but to serve as CSS anchors there are. We traded in non-sematic tables for non-sematic divs.

The <div> element has no semantic meaning, screen-readers don't read them and they have no intrinsic behaviour unless associated with an aria tag.

Why couldn't we just have made non-semantic tables? In addition to the semantic tables, I mean.

Divs with display:table/table-row/table-cell _are_ non-semantic tables.

except divs lack colspan

I came across this issue recently and was surprised after all these years there still isn't colspan support. Ended up having to create additional containers when I should be able to style it using CSS.

There's (almost) always a way round a problem. In the case of colspan, try this:


Which would actually be somewhat helpful, come to think of it...

adding role="presentation" to a <table> element will tell screenreaders to treat the element and its required children as non-semantic. I still say using a table for layout (of non-tabular data) is should be a last resort but it's easy for me to say since making a layout is rarely my job.

Except that div have no semantics by definition.

I agree and it really bothers me that all the markups in modern web pages are littered with COL, span, md, lg, xg, 1/2 2/3, with gibberish nestings. Semantic web went out the window, in favor of responsive web.

The whole web is fad-driven, so I'm glad at some point, pendulum will swing back.

Meanwhile, I'm just happy parallax fad is dying out.

Allowing an arbitrary website to work on a phone isn't really a fad, though. In a few years time, there's not going be a huge sigh of relief as everyone gets back the fixed-width websites they've been crying out for.

"Allowing an arbitrary website to work on a phone isn't really a fad, though." Agreed, but current implementation is mostly terrible, with 6 break points, 1-2MB downloads, everything = single page app, etc. So the concept of write-once, run everywhere is not a fad, but the implementation is very fad-driven.

Ah, that's fair enough; I was thinking at a more conceptual (or even just CSS rather than JS) level.

Browsers should e.g. allow tables to be sorted by clicking column headers. They can't, because tables aren't always tables.

How about an opt-in attribute to enable ordering then?

<table sortable >...</table>

Tables nested in tables nested in tables was a fate worse than divs. Even in the simplest case (one box) a table stinks: <table><tr><td></td></tr></table>. I personally found that trying to debug which table a <td> belonged to was hell on earth.

Just starting to realize how out of touch HN readers are with CSS. This mindset does not belong in a conversation about CSS in 2015.

This owes at least in part to the fact that tables are not optimized for page layout. And that was especially true 10 years ago. Popular browsers couldn't render partial tables, and you had even more performance problems nesting them.

Grid based layouts are obviously useful but the table tag isn't the right tool.

Kinda. I used to agree with you for the longest time, but I can relatively easily make a CSS bootstrap page responsive, because I can override the bootstrap CSS, but there is no way to override the behaviour of <table>.

You can use semantically meaningful class names and use the mixins from the Bootstrap source. Even though it's probably common practice and great for you know, bootstrapping, I don't think it's good for maintainability to leave the column classes in the markup. In a large, modular, front-end heavy project, proper separation of content, presentation, and other cross-cutting concerns really pays.

and I wonder how the <ul><li> somehow survived unscathed and free from the semantic witch hunt of yore. shouldn't we replace them with:

<div style="display:list-type; type-of-list:unordered"> <div style="display:list-item;">


The "semantic witch hunt" against using tables for page layout exists not because the table tag is a semantic tag, but rather because pages are not tables. Likewise, ul and li tags are semantic, and I think most people would advise against using them for something other than unordered lists and list items.

Of course, the issue would probably come up rarely, since the browser stylesheets for those tags don't do anything particularly useful for anything other than lists and list items.

This comment doesn't make any sense. A list is a thing, just as a table is...

What are you trying to say?

Down vote for "doesn't make sense". It made perfect sense to me.

The phrase you were looking for is " I don't understand what you're saying."

Then perhaps you would like to explain it? The most meaningful interpretation I can see is that the commenter completely misunderstood the nature of the "semantic witch hunt" to which he referred. It seems charitable to assume that something was lost in translation and to ask for clarification rather than to assume that the commenter was just saying something stupid.

Very true, and such charity doesn't help the discussion. Insisting on the polite path, "I don't understand" instead of "your comment makes no sense" wrongly assumes that all comments written on forums are carefully considered and fact-checked before posting. It's taking the long way to resolution of that point, and you might never get resolution if bogged down in overly-polite discourse for fear of being "negative".

The phrase the poster was looking for was that "the example provided was hyperbole." Your comment is far too confrontational.

If you go down that path, there are no semantic elements left at all.

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