Hacker News Reader

Comment by crispyambulance | Hacker News Reader

CSS grid, where were you 15+ years ago?

CSS was such a mess for so long because of the complete lack of a consistent easy-to-understand layout mechanism. This has spawned the creation of countless workarounds and javascript gizmos, JUST SO you could stick something on a webpage where you want to go and have it behave in a sane way under resize and different browsers.

I welcome CSS grid, it reminds me of the sane layout managers we're used to from writing desktop applications. It makes me wonder why we had to wait so long for this functionality to be part of the CSS standard.

As for the generator, I think it's nice. Most folks will get the hang of banging out arbitrary css grid layouts very quickly. This tool will accelerate that for many.

View on HN

Because HTML was a document format, not an application container. Try positioning something exact in Latex.

I am not going to start using Latex, but sadly this:

  <table border="0" cellpadding="0" cellspacing="0"><tr><td>...

still works just as well for layout than anything I've seen using CSS/HTML. Even worse, all I want to do is tab over from some text:

  <code>(SUB X Y)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code>subtract<br>

That reminds me of this gem from back in the day:

http://okcancel.com/comic/98.html

... When people realized that you could, painfully, use CSS for layout and dump layout tables altogether.

Serious question: Why can't I use tables and define cells sizes in terms of vh and vw?

Tables are totally fine if what you're visualising is data that belongs in a table. Tables for layouts are not semantically correct and breaks a lot of expected behaviour for people with assisting technology.

Html shouldn't consider layouting, that's for css to do.

You haven't looked hard enough and aren't aware of all the issues with using tables for layout.

In addition, the attributes you show are now obsolete and non-conforming: https://html.spec.whatwg.org/dev/obsolete.html#non-conformin...

Yeah, you're right, but for how many years did we fit the square-peg in the round-hole using html/css for "web-applications"?

And anyway, how long did we have to use browsers before people realized it's not exactly a piece of A5 paper?

It's hacky and not good practice, but LaTeX supports things like:

  \hspace*{0.75cm}

which I've had reason to use on occasion.

I often hear this argument but I haven't been able to grasp its meaning. Is SVG a document format or an application container? I'd say it's definitely not the latter. But it does allow for precise positioning, right? The same goes for PDF or XPS or any such thing, starting from PostScript.

Besides, HTML does allow precise positioning, but nobody really needs it. What everybody needs is a high-level language that fits the domain: fluid 2D interactive layout. CSS is simply not a good attempt to solve it. It's not even bad per se, because a similar model works quite well with XSL-FO. But XSL-FO is always an intermediate step: you take a custom document format (some XML), transform it with XSLT into XSL-FO, and then process XSL-FO to produce a PDF. The HTML lacks this transform step and tries to bolt-on CSS model directly to what must be a custom XML format and this is why it's so awkward.

I remember in the late 90's when XML was hot stuff and there was of xsl and it's simpler cousin, xslt, and a capable mechanism for keeping everything "honest", the xml-schema. For whatever reasons, that never took off.

It was promising, but it was mired in over-engineered complexity, the w3c docs looked like a nightmarish "design by committee" mess. I believe the intention was never to actually have to see XML let alone write it by hand. Along with the jetpacks of the year 2000, we were promised magical CASE tools that would handle the details. That fizzled out. Instead XML just became a means for encoding configuration that people typed in by hand, sometimes aided by a crappy intellisense-guided schema. We all grew to hate it.

CSS was a great idea on the surface. Compact, not too complex looking: hook into elements by type, class or id, and style them as needed. But for many years it was a half-measure. Browsers behaved differently, and layout was counter-intuitive.

And THAT is what I just can't understand. We had models for how layout on user interfaces should work for many years on desktop applications. CSS just didn't care, it was poor for newspaper-like layout and poor for web-app layout.

CSS grid is such a refreshing step in the right direction, but why so long in coming?

> why we had to wait so long for this functionality to be part of the CSS standard

The history of it was written up by Igalia here:

https://blogs.igalia.com/mrego/2017/03/16/css-grid-layout-is...

> CSS grid, where were you 15+ years ago?

Hiding under the pseudonym 'table'.

I think this is related to the sibling comment, i.e. the document vs application container question.

I wonder if the 'using table for layout is bad' principle of the web should have been reevaluated in the context of SPA web apps in the same way that, for example, 'separate markup, behavior and styles' was.

I know all these things are still controversial and no consensus has been reached, but I'd suggest that this might have been a good idea if we'd started trying it 5ish years ago, in some usecases. Without doubt, css grid is better, but as you suggest we've always had the means to do the job with 'table' right there.

display: table isn't bad for layout (it's fine, and a perfectly reasonable approach, but please use table-layout: fixed); the table element is bad for layout, because it's an accessibility nightmare (and accessibility tools end up with weird heuristics to determine whether a table is there for tabular data or layout).

Reply on news.ycombinator.com