CSS Grid – Table layout is back. Be there and be square • Hacker News Board

Re: CSS Grid – Table layout is back. Be there and be square

#111

Post by StavrosK » Tue, Jan 31, 2017, 12:02 PM UTC

amiga-workbench wrote: post #51

lomnakkus wrote: post #40

Earlier quoted context omitted.

While that would probably work fine for display and layout, but it doesn't work so well with the semantic document model that the web is built on. For example accessibility would suffer greatly unless every "jquery" (using your analogy) out there were to implement its own accessibility. (That's not to say things are absolutely peachy wrt. accessibility these days, but they'd get a lot worse if everybody had to implem…

I don't know if developers even care about semantic markup anymore, just have your 5 meg of JavaScript squirt out a bundle of divs and to hell with accessibility.

I got tired of this exact thing, so I started making an informational site:

http://www.lightentheweb.com/

It's very very not ready yet, but I'd appreciate some pointers or PRs.

Re: CSS Grid – Table layout is back. Be there and be square

#112

Post by TeMPOraL » Tue, Jan 31, 2017, 12:03 PM UTC

andybak wrote: post #93

HalfwayToDice wrote: post #86

Earlier quoted context omitted.

Screen readers haven't been confused by tables since about 1998.

There was a particularly extreme trend back then (well - probably more during the 90s) where websites were mainly big Photoshop images sliced up into a lot of nested tables of dizzying complexity. Screen readers off course struggled with that as it was rather hard to determine the order of the content. I'm not sure how much trouble they have with more minimal use of tables for presentation.

> where websites were mainly big Photoshop images sliced up into a lot of nested tables of dizzying complexity

Replace "nested tables" with "nested divs", and this is exactly how web development today still looks, at least if your company employs a designer. Slicing is still a thing.

Re: CSS Grid – Table layout is back. Be there and be square

#113

Post by konschubert » Tue, Jan 31, 2017, 12:04 PM UTC

But does the Grid layout change flow responsively? I mean, will the sidebar move below the content if the size of the screen is reduced?

With flexbox I can do that implicitly without Media queries

Re: CSS Grid – Table layout is back. Be there and be square

#114

Post by e12e » Tue, Jan 31, 2017, 12:09 PM UTC

einr wrote: post #79

e12e wrote: post #69

Earlier quoted context omitted.

It's not. There were a few arguments against "table layout", some of which apply to hn as well IMNHO. Added tags without semantic value (just as your div-soup above also illustrates). Layout speed (in reality not much of an issue now - and also an issue with deeply nested tags with complex layout). Both are fixed in modern html5 which moves (back) towards simple, semantic, document layout (html-body-article-heading-e…

I look forward to trying modern flexbox and grid layouts. I have not had the privilege (?) to work with either yet; our customers are not necessarily on the bleeding edge of browser releases so I have to stay a little behind the curve. Hence, a lot of div soup and ridiculous indentation levels. Honestly, for what I'm doing (a pretty complex web app with an almost desktop-style GUI with a bunch of buttons, text inputs…

The "container" is common, but typically not needed.

Sometimes it's a redundant stand-in for "body > .content" or similar (eg: divs dropped directly in body) - and is prevalent because developers don't understand and care about css selectors (or there's that one person on the team that doesn't -- don't get me wrong -- I realize the real world is full of real co-workers, and making a change isn't always easy).

And partially it can be an artifact of abusing floats for "grid layout". Most typically though, the "container div" just ends up being a completely redundant extra "body" element.

Re: CSS Grid – Table layout is back. Be there and be square

#115

Post by drinchev » Tue, Jan 31, 2017, 12:12 PM UTC

TeMPOraL wrote: post #104

drinchev wrote: post #66

Earlier quoted context omitted.

Number of unhappy front-end developers : 1 ( me, so far ). Hope nobody will have to modify your stylesheets.

Because they're much simpler than the usual div-based layouts, and so the frontend dev will get bored out of their brains?

Tables are meant to be used for ... tables. Not layout. The downsides are enormous.

From hard-to-find bugs through SEO-penalty to code-maintainance [1].

I lived the time when there was no CSS at all. Back then we used tables for everything. I'm happy those times are over.

1: http://stackoverflow.com/questions/83073/why-not-use-tables-...

Re: CSS Grid – Table layout is back. Be there and be square

#116

Post by pilif » Tue, Jan 31, 2017, 12:15 PM UTC

bgarbiak wrote: post #109

pilif wrote: post #49

Earlier quoted context omitted.

> it should be available for 95%+ of users within a year only if you don't have enterprise customers. Those will continue to run IE11 for the foreseeable future as IE11 will remain supported in Windows 10 until 2025. While Microsoft is pushing Edge as an IE replacement, Edge is still lacking features and looks too different from IE for companies to feel comfortable pushing it to their users without retraining them.

It's not a problem in this particular case, as CSS Grid was introduced by Microsoft, in IE10. So, more or less, four years ago. I chuckle when Google announces that Chrome will support this feature as the next big thing, while it was clear years ago that this approach is much better than flexbox. But, I'm glad it finally lands in all browsers.

The version of CSS Grid that's supported by IE isn't the version that's in the standard and supported by all other browsers. Same with Flexbox.

Re: CSS Grid – Table layout is back. Be there and be square

#117

Post by kagamine » Tue, Jan 31, 2017, 12:18 PM UTC

yoz-y wrote: post #107

kagamine wrote: post #78

Earlier quoted context omitted.

That's a problem for sure but last week I looked into creating a family tree with the basics of HTML and CSS and the following nested lists seems to be the best solution according to forums. Now, try to add into these nested lists some siblings(the people kind) and some new branches as you discover people in census reports from 100 years ago. Now add in a newborn. Is this the best we can do? (apologies, but I haven't…

How could this be done better though? Unless using a DSL it seems to me that this problem is quite complex to begin with.

It is, but it also illustrates the problem of drawing a simple diagram for the web. It was in response to user mattmanser's illustration of diabolical nested tables and user einar's nested divs. HTML is problematic for anything complex. I suppose the best way to represent the data is to not use HTML at all, but instead use an image (SVG? for scalabilty) or a big PDF that opens a new tab?

I googled for a solution that I could add to and maintain myself and this was what The Internet threw up as the best solution, but it is far from good.

Re: CSS Grid – Table layout is back. Be there and be square

#118

Post by eriknstr » Tue, Jan 31, 2017, 12:22 PM UTC

TheAceOfHearts wrote: post #63

matt4077 wrote: post #35

This is excellent. And with the fast pace of browsers, and the improved habits of users (or automatic updates), it should be available for 95%+ of users within a year (It's in the current Safari Technology Preview, so Safari should get it with the next macOS point update). This is also a good moment to remind people that you don't need Bootstrap and the like as much as you used to. Grids were 90% or the reason people…

Since you included the element in your list, something I wish browsers provided is a way to automatically format time elements based on user's preferences. I just want to provide the value in ISO8601, and let the browser take care of it. Luckily, Intl.DateTimeFormat [0] seems to finally allow a reasonable degree of i18n in the browser. If you can live with the limited Safari availability, of course. [0] https://devel…

>something I wish browsers provided is a way to automatically format time elements based on user's preferences

That'd quickly get awkward. I live in Norway where the default format is DD/MM as opposed to MM/DD used in the US. This works fine for us in general, we know to expect the first one when we read something in Norwegian and the second one when we read something in English. If a computer formatted a date based on a default preference and considering that most websites probably don't specify the lang attribute, I think it'd get messy quickly. Also, different date formats will lead to different sentence structures making sense. For example you might say "ever since 9/11 something something" but you wouldn't naturally write "ever since 11. September 2001 something something" (you'd write "ever since the 11th of September 2001 something something") and likewise you also wouldn't naturally write "ever since 2001-09-11T08:46:40-0400 something something".

Re: CSS Grid – Table layout is back. Be there and be square

#119

Post by tannhaeuser » Tue, Jan 31, 2017, 12:26 PM UTC

I don't know how to say it politely but what has been achieved by using ad-hoc syntax such as this gem (and similar complex CSS syntax):

    display: grid;
    grid-template-rows: 150px [nav-start]
        auto 100px [nav-end];
    grid-template-columns: [header-start]
        minmax(200px, 3fr) 9fr [header-end];

CSS fans for some reason seem to think that its somehow better to have rendering/presentational properties in an ad-hoc language. Originally, plain markup attributes where designed to accomodate rendering properties, with type checking and all. The naive dichotomy established by putting "semantics" into markup and "presentational" properties into CSS was accidental, and it didn't make sense back then, nor does it now.

Re: CSS Grid – Table layout is back. Be there and be square

#120

Post by swalsh » Tue, Jan 31, 2017, 12:31 PM UTC

My first experience as a young kid in the 90's doing web design was taking the msn.com home page (I thought it looked nice back then) looking at the source, and learning. Turns out layout was done using tables. Cool, putting it into practice though it was really really hard.

The primary force you were always fighting against was inconsistency between browsers. You might get everything perfect in IE, then load it in Netscape and there's huge gaps between your awesome solid colored navigation side blocks. Then making it adjust to the size of the browser was another struggle. After a while I learned to just make everything fixed size. Then content inside continues to nest you have to keep subdividing, and things would start to get out of whack. You adjust one block here, and the side suddenly has these weird gaps. A large part of it was almost certainly the fact that I was about 13 or 14 years old at the time, and I learned only by looking at example code... but It was really difficult.

flexbox doesn't really seem to suffer from the problems that made table layout really suck. I use it mostly indirectly by using the library Bulma, but it's really wonderful.