Hacker News new | ask | show | jobs
by jheruty 2007 days ago
I'll bite.

I'm not a fan of CSS. I learned it well enough to build a decent UI toolkit (draggable modals, collapsible, etc.)

I hate how CSS tries to mix layout and style. A million articles about not using tables for layout, and it took 20+ years to get a grid. I tried to do some fancy text and element alignment with CSS, and it was not having it (and, yes, I know about display: table). In the end I reverted to a table. It worked, and I moved on with life.

It is ridiculously hard to draw things in absolute positions. In many cases, it is easier to do a tiny bit of math and compute the positions of objects, rather than have to define parent/child relationships. But for true absolute positioning, you have to throw divs into a "portal" of some sort, and move that object into the root element. This makes doing things like pretty drag and drop extremely painful.

Browsers are buggy as hell, and often something works on everything but [insert your most hated browser]. That's a hint that the spec is too complicated.

I agree with your assessment, in that if you try to construct the world from scratch, you'll be "fighting the beast the whole way." I disagree that this is positive quality of the thing.

3 comments

>A million articles about not using tables for layout, and it took 20+ years to get a grid<

To be fair, CSS 2.0 (from 1998) has “display: table” which allows table layout in pure CSS. [1] The problem was not CSS. The problem was Internet Explorer 6; “display: table” was not viable to use until the early 2010s when IE6 usage finally plunged.

[1] Edit: CSS was designed for styled documents, such as online resumes or blogs. It was not designed to make interactive apps, which is why it doesn’t fit that paradigm well. Everyone thought Java applets would run the interactive web, and we would be making web applications in Java today if Microsoft had not killed Java on the web in the late 1990s with IE.

In my experience, "display: table" is not really identical to the behavior of <table>. I gave up on it for my project, though unfortunately I don't remember the specifics.

I think it's just a fundamental issue where CSS is trying to be both layout and style. Works great for basic document formatting, but once you try to do something complex, it all falls apart. Or, rather, it should fall apart, but we've spent the last couple decades duct taping it together.

Every JavaScript framework ultimately hits a wall where it has to interact with CSS. It can't be abstracted away.

I really do believe more money and effort should be spent looking for an alternative.

The biggest thing missing in “display: table” is “colspan”, allowing a table cell to take up multiple columns of the table. That can be a big deal with some layouts. One workaround is to use “position: absolute” inside a CSS table cell to have an element which can span more than one table column.
Why not use a <table>?
For layout?? Burn the heretic! [1]

The real reason we don’t use tables for layout (and only for the occasional tabular data) is because a table layout doesn’t work really well on the screen of an iPhone or Android phone, especially when they are vertically aligned. So, the workaround is to use media selectors: Desktops, laptops, and tablets get a table layout; phones get a simpler one-column layout.

I believe grid and flex layouts allow one to use a single design which will appropriately scale from a phone screen to an ultrawide monitor, but I use a two-layout or three-layout design for my web pages.

[1] In the days when the CSS Zen Garden was new, all of the web design blogs and comments felt using <table> for anything at all was heresy, since abusing <table> resulted in really ugly and hard to maintain webpages during the dot-com days of the late 1990s. It would be an extended discussion whether it was OK to even use <table> for clearly tabular data.

I think the don't-use-tables argument is from way before mobile devices were something web developers cared about. I recall it as being mostly about semantics, i.e. tables should only be used for tabular data, not setting up the layout of your entire page.
I have never seen anyone arguing <table> was not OK for tabular data.

I thought this was a myth on level of teenagers eating tide pods.

The Jeffrey Zeldman era of CSS.
These days you actually can use <table> without compromising accessibility, by adding aria-annotations. So if you prefer this to CSS, go ahead.

Most of the angst around <table> was before aria support, so using <table> purely for layout impacted accessibility, which meant it was not viable for most real-world scenarios.

That said, if you need stuff like colspans for a layout, you are probably better of using grid.

Exactly.

td supported vertical-align:middle since css1. But you're not suppose to use tables because... hmm. The user sees no difference. Google doesn't care. The browser has no problem with it. It's easier to code. Oh, but it's bad practice... how? I feel like we just listed what qualifies as good practice.

What is it called when following rules only leads to breaking rules? Hint: Sometimes it even leads to javascript.

CSS :)

That is not why you're not supposed to use tables for layout. It is for accessibility reasons. This is routinely ignored because approximately 0% of rich web apps are accessibility-friendly and people with screen readers have pretty much just learned to make do.
This is such an oversimplification. Since when did a table contribute to the richness of an application? Most modern sites are built with divs and remain inaccessible.

Tables simplify the code for simple content placement. That's it. It's only one of a long list of requirements to satisfy all sorts of requirements including screen reader compatibility. And if one were to use tables, it's only one of a long list of hacks and non-hacks that would break screen readers.

The root of the problem is with web designers not prioritizing accessibility-friendliness in their sites to begin with, for the basic reason that it prevents them from building the site that they need to build. And "what breaks or doesn't break accessibility" is not part of the spec description and is not enforced technically. We get recommendations, but it's up to us to test everything against everything else and compromise. Not just with accessibility but with everything else as well including backwards compatibility.

Wouldn't accessibility software back then have been able to deal with table based layout, considering most websites were constructed that way?
No, they weren't, at least not usefully. It was a major problem and made a lot of the internet unusable for vision-impaired people.
If you're a developer and someone decides to have a layout for the emails sent to customers, you probably still have to use tables.

I find that designers who create their own CSS are pretty rare. Most times I've seen frontend developers slice up designs. I think you need to have a workflow to do this properly. I needed someone to show me how to do it and I often preferred to just use an open source CSS lib like Bootstrap.