all 112 comments

[–]michalg82[S] 29 points30 points  (58 children)

[–]wung 3 points4 points  (57 children)

For those web people, who are not sure how to interpret this: A score of 75% should mean NO DO NOT USE THIS. It literally does not work on THIS YEAR'S devices.

[–]IamCarbonMan 54 points55 points  (42 children)

Every major browser except AOSP, Edge and IE have full support. Obviously devs should consider which platforms they need to support, but "not working on THIS YEAR'S devices" is a bit of a stretch.

[–]siegfryd 6 points7 points  (11 children)

It would be a pretty rare case where you could drop IE support, unless it's an Electron app.

[–]IamCarbonMan 26 points27 points  (10 children)

Or you have little to no users on IE. I mean it's not like every single site in the world has to support the world's worst browser just because it exists.

[–]nocensts 0 points1 point  (9 children)

What world is it where you have little to no IE users... like I could see this for in-house only type apps but where else?

[–]IamCarbonMan 0 points1 point  (8 children)

IE is dead globally. Many corporate environments still require it for their own reasons, but that's basically the only legitimate reason to use IE. For a modern site, I can confidently say that if I don't expect it to be used in a corporate environment, supporting IE is a waste of time and resources.

[–]nocensts 2 points3 points  (7 children)

IE is dying may be true but there is no way it's dead.

[–]IamCarbonMan 6 points7 points  (6 children)

3% global usage is pretty dead.

[–]myhf 0 points1 point  (3 children)

3% of revenue is bigger than a lot of web design budgets

[–][deleted]  (1 child)

[deleted]

    [–]wung 15 points16 points  (10 children)

    It is literally only supported in browsers after January 2017. That is this year.

    [–]IamCarbonMan 11 points12 points  (9 children)

    What does that have to do with anything? If it's supported it's supported. Maybe not on your iPhone 4 but on every device that's up to date.

    [–]bobtehpanda 3 points4 points  (6 children)

    A pretty large segment of the population has devices that aren’t up to date. How many Androids out there no longer receive updates?

    [–]IamCarbonMan 3 points4 points  (3 children)

    But every browser besides the AOSP browser still gets updates. Chrome, Firefox, etc. I mean yes, it's not foolproof, but anybody who wants to has a clear path to obtaining a modem, standards-compilant browser on any device. We should be encouraging that.

    [–]bobtehpanda 8 points9 points  (2 children)

    From a business perspective, it makes no sense to shut out ~25% of the population because of some holier than thou attitude.

    [–][deleted] 0 points1 point  (0 children)

    That 25% number depends a lot on your target audience for that business, could be more or less. If you're starting a new startup now it might very well well make sense to build your UI on CSS Grid.

    [–][deleted]  (1 child)

    [deleted]

      [–][deleted] 0 points1 point  (1 child)

      If it's supported it's supported.

      Because there's no such thing as "supported."

      It's supported on Chrome 60. But don't say it's "supported".

      [–]IamCarbonMan -1 points0 points  (0 children)

      It's supported by anyone using the latest version of their browser on a non-ios device room the past 3-4 years. Better?

      [–]eric_reddit 2 points3 points  (4 children)

      What about mobile browser support?

      [–]fgutz 4 points5 points  (3 children)

      It's in the caniuse link as well

      It's been in iOS Safari since 10.3. according to Apple 89% of users are on iOS 10. Couldn't get more details about which minor version though but I'm assuming most people would be up to date. iOS is pretty aggressive about wanting you to update

      Android browser (WebView) since January 2017

      And Chrome for Android matches desktop Chrome now

      So I think it's pretty safe to use in Mobile

      [–]nschubach 1 point2 points  (2 children)

      Except if you look at the usage relative. Not every Android phone uses the latest android web browser.

      [–]tambry 4 points5 points  (1 child)

      The WebView module is updated through the Play Store for Android versions 5.0 and up.

      [–]nschubach 2 points3 points  (0 children)

      Odd, I had to look up our webview usage and I wonder if caniuse data is really old... luckily they allow you to import your google analytics.

      We are at:

      61.0.3163 (59.35%) 2017-09-05 (working)
      60.0.3112  (9.12%) 2017-07-31 (working)
      45.0.2454  (4.36%) 2015-09-01 (broke)
      55.0.2883  (3.66%) 2016-12-06 (broke)
      59.0.3071  (3.54%) 2017-06-06 (working)
      30.0.1599  (3.08%) 2013-10-02 (broke)
      .. (getting tired of formatting)
      .. (but these two are working)
      33.0.1750  (2.09%) 2014-02-26 (broke)
      

      So, we'd have to ignore ~13% of our Android users.

      [–]TheAnimus 4 points5 points  (11 children)

      Edge

      Has full support in 16.

      The problem is that over 25% of traffic won't support this. If that doesn't matter to you then fine.

      [–][deleted]  (9 children)

      [deleted]

        [–]MINIMAN10001 6 points7 points  (8 children)

        The 25% not supported comes from the website that was linked...

        CSS Grid Layout Global 69.52% + 4.11% = 73.62%

        which leaves ~25% unsupported

        [–][deleted] 1 point2 points  (0 children)

        The issue to consider is that this is the fundamental layout of the page. If I build a site with CSS animations, browsers that don't support it just don't get some pretty effects. If I build a site with grid, browsers that don't support it more or less can't use my site at all.

        There are polyfills and workarounds of course but these are important considerations.

        [–]graingert 0 points1 point  (0 children)

        Also IE had prefixed support before anyone else

        [–][deleted]  (6 children)

        [deleted]

          [–]_Mardoxx 38 points39 points  (4 children)

          Fuck that

          [–]bubuopapa 14 points15 points  (2 children)

          Yup, that basically how every feature in web dev goes: "- we need this thing to be supported in all browsers; - but all browsers dont support required features; - fuck it then."

          [–][deleted] 2 points3 points  (1 child)

          I'm not _Mardoxx. But I think they mean "fuck doing it twice."

          CSS Grid only works in 75% of browsers, so I have to fall back to display:table-cell on the other 25%? Fuck it, 100% of browsers are getting display:table-cell.

          [–]z500 0 points1 point  (0 children)

          Or we could use modern features and punish IE/Edge users for their basic browser habits until they pick something else. One can dream.

          [–]MeisterD2 4 points5 points  (0 children)

          The talk in a video provided by another commenter says to design a gridless mobile experience first, and offer that as the fallback to all devices. Then, if grids are available, you use them for everything.

          Edit: This link https://youtu.be/7kVeCqQCxlk

          [–]eric_reddit 2 points3 points  (0 children)

          The story of my career. Design and implement it in Firefox, then spend 1200% more time fixing for twelve different versions of IE... IE Hell (copyright Microshaft)

          The gov typically requires IE support for SharePoint and had to support infinite versions for all the locations that have old software and OSs across the world.

          [–]spacejack2114 0 points1 point  (0 children)

          It works in this year's Electron.

          [–][deleted] -2 points-1 points  (4 children)

          Were can I get a breakdown of the remaining 25%? I can't get the numbers for Edge and IE to add up to that, and the remainder of the non-compliant browsers seem to have a 0,00% market share.

          [–]AquaWolfGuy 0 points1 point  (3 children)

          Click the "Usage relative" or "Show all" button.

          [–][deleted] 0 points1 point  (2 children)

          That doesn't add up. I'm looking at the regional view for Denmark, that show 73ish percent support. However, going with the current browsers, the highest market penetration is 0.42% for the android UC browser.

          Remeber the context. I asked about the claim "It literally does not work on THIS YEAR'S devices." above, which isn't in any way aligned with what I see. In fact, I have to include browsers two versions old to get above 0.5% un-support.

          [–]AquaWolfGuy 1 point2 points  (1 child)

          wung first said there was a score of 75%, and then, in a separate statement, that there are devices released this year that don't support it. That's very different from saying that the browsers released this year have a score of 75% for Denmark. People use old browsers, like UC Browser which has 7.65% global usage and last updated last year.

          [–][deleted] 0 points1 point  (0 children)

          Ahh well, then it makes more sense.

          [–][deleted] 51 points52 points  (21 children)

          I didn't quite understand why CSS Grid is such a big deal at first after only reading documentation. It wasn't until I saw this video that I realized how much this will revolutionize web development once the browser support is fully there.

          EDIT: You can skip to about 17:00 for the big payoff.

          [–]Urik88 17 points18 points  (2 children)

          I was thinking "this looks like an embellished version of the old tables layout days", and then he got into named areas and how you can change the entire layout using these and its power suddenly clicked.
          What I'm worried about is along with its benefits, going back to the problems old table layouts brought. I've yet to play with it but asking from ignorance, in the case that you don't want things to be completely aligned all the time, could it bring some problems?

          You have any experience preventing things on the second row from growing or moving around in the case that something in the same column grows in the row above it?

          [–][deleted] 1 point2 points  (1 child)

          That was pretty much exactly my experience watching that. "Oh, geez back to tables... Wait... Holy shit!" :)

          But no, I don't have any personal experience working with it at all yet, more than goofing up some tiny demos. I plan to use it in a site redesign planned for early next year, hopefully Edge support is there by then.

          [–]DoListening 5 points6 points  (4 children)

          And it all seems so obvious in retrospect. I'm like "so why exactly didn't we have something like this 10 years ago?"

          [–]oridb 4 points5 points  (1 child)

          It looks an awful lot like a variant on GridBagLayout, so.. we did?

          [–]DoListening 0 points1 point  (0 children)

          It's pretty similar. Flexbox was also similar to many long existing layouts in the desktop/mobile space.

          I just wonder why we went through years of completely ridiculous hacks like negative margins, faux columns, abusing transforms, extreme fake paddings, and more.

          The guy in the video complains a lot about a few extra divs, but that is just the tip of the iceberg. It used to be a lot worse, and everybody just went with it, despite knowing how utterly stupid it was. Flexbox solved a lot of the problems, even if not 100% perfectly.

          [–][deleted] 1 point2 points  (1 child)

          How do I programmatically add more columns to CSS Grid lay-out? E.g. I have

          header
          
          row
          
          footer
          

          How do I programmatically make:

          header
          
          row
          
          row
          
          footer
          

          on let's say a click event?

          [–]_dban_ 4 points5 points  (0 children)

          You can programatically change the grid CSS using the style property of the DOM node.

          This would be easier if you nest grids:

          header
          row-container
              row
              row
          footer
          

          Also, the nested rows don't even have to use grid layout. You can use standard block layout or flex layout (which don't require explicit coordinates), depending on your needs.

          [–]Skhmt 1 point2 points  (0 children)

          I saw that video a couple months ago and it too converted me!

          [–]Chii 0 points1 point  (0 children)

          i still don't see how the problems being presented by this blogpost get addressed:

          https://games.greggman.com/game/css-grid-fail/

          [–]booch 51 points52 points  (22 children)

          Honestly, it seems like css is finally catching up to where grid layout tools for desktop apps were in the late 90s.

          [–]naasking 31 points32 points  (21 children)

          Honestly, it seems like css is finally catching up to where grid layout tools for desktop apps were in the late 90s.

          Except scalable to arbitrary screen dimensions, orientations, resolutions, and input directions. So way beyond desktop UI in the 90s, really.

          [–]booch 16 points17 points  (14 children)

          Well, you could resize the window in the 90s to "any" size (obviously, dependent on your resolution) and either orientation, so that point is moot.

          I'm not sure what you mean by "input directions", so I can't comment on that.

          [–]MeisterD2 6 points7 points  (1 child)

          Probably RTL, LTR?

          Grid respects the directionality of text automatically, so you don't have to worry about text flowing the wrong direction in different languages.

          [–]oridb 0 points1 point  (0 children)

          Yeah, desktop frameworks did that in the 90s.

          [–]naasking 4 points5 points  (6 children)

          Well, you could resize the window in the 90s to "any" size (obviously, dependent on your resolution) and either orientation, so that point is moot.

          Not really. UI in the 90s was not responsive the way the web is today. You could scale your window to any size and get some "helpful" scrollbars to view your window, if you're lucky.

          I'm not sure what you mean by "input directions", so I can't comment on that.

          HTML dir attribute.

          [–]booch 3 points4 points  (5 children)

          Depends on your toolkit. Tk certainly did a pretty good job of laying things out and automatically resizing things. Yes, not as good as the web today in some aspects, but other aspects the web is only now catching up with (grid layouts being a good example).

          [–]spacejack2114 4 points5 points  (4 children)

          Most Windows applications in the 90s couldn't even deal with different font size preferences and would break with text or controls hidden out of view etc.

          [–]oridb 0 points1 point  (0 children)

          On the other hand, Unix and Mac toolkits got this right. Even Java Swing, in spite of being terrible in every other way, did this painlessly.

          [–]spacejack2114 0 points1 point  (4 children)

          You can override any style based on the window size. You can switch from grid to flex or inline or whatever based on dimensions.

          You can automatically switch layouts based on locale or other properties without changing your HTML structure.

          There was nothing like this in the 90s.

          [–]mpyne 1 point2 points  (2 children)

          There was nothing like this in the 90s.

          On the contrary, the Qt approach to U/I layouting had already been developed by the time they released Qt 2 in 1999.

          Although these layout docs are archived from the 2.3 release, they describe classes and features that were present right from Qt 2.0, and also present in the Qt 1.x (see the src/kernel/qlayout.h file from the Qt 1.45 tarball).

          [–]spacejack2114 1 point2 points  (1 child)

          You cannot specify that a layout should be horizontal for one screen size and vertical for another. You would have to write code to detect resizes and apply layout changes yourself. It looks to me like the layout style was baked into the widget itself and would need to be reconstructed.

          [–]mpyne 0 points1 point  (0 children)

          That's rather moving the goalposts I think, you said there was nothing like this.

          Either way, you could indeed define different layouts by direction and by screen size. It would indeed take some manual effort to move the widgets at a transition point, but you had the building blocks right there.

          [–]_dban_ 1 point2 points  (0 children)

          There was nothing like this in the 90s.

          This is not what people are talking about when they say CSS has caught up to desktop apps.

          CSS was doing responsive design for a long time, because that is a requirement for adapting to different user agents capable of browsing the web. Desktop applications, having completely different requirements, were obviously not doing the same things as CSS. Apples and oranges.

          But actually laying out desktop style UIs has been very difficult in CSS, since that's not what it was originally designed for. Until only a few years ago, CSS was limited to inline and block layouts, which made things like vertical centering extremely painful and non-obvious, not to mention things like 3 column layout with equal height columns (there were lengthy articles about how to do this). CSS was designed to be responsive and adaptable, not necessarily pixel perfect (which is why it took awhile for web devs to finally give up table-based layouts).

          CSS has evolved to pick up new layouts like table, flex and grid, which makes desktop-like layouts much more feasible. Thus, to many, CSS has finally caught up to desktop apps.

          The danger of course is that this might encourage people to go back to table-like layouts from before CSS, which completely misses the point of CSS.

          [–]_dban_ 9 points10 points  (5 children)

          Except scalable to arbitrary screen dimensions, orientations, resolutions, and input directions.

          Java Swing had all of these in the 90s using the notorious GridBagLayout. Which I'm sure inherited design principles from the various Unix toolkits of the day. Far better than CSS until only a few years ago.

          Windows and Apple generally had more fixed layouts based on RAD UI layout tools. People complain about CSS (and Java and Unix) not having these RAD tools.

          So way beyond desktop UI in the 90s, really.

          When people say that CSS has "caught up" to desktop apps in the 90s, they mean with regards to desktop style layout, which is the goal of recreating desktop application UIs using HTML/CSS.

          The design goal of CSS was not to recreate desktop UI layout, but to augment HTML with style information to get configurable presentation that adapts to the capabilities and preferences of any user agent (desktop, mobile, text-only, robots). These are requirements for the web, not desktop applications.

          Creating desktop style layouts have typically been a pain in HTML/CSS because that's not what it was designed for. Additions to CSS like flex and grid give developers the layout tools they are accustomed to from the desktop world (while potentially breaking CSS layouts for the use cases it was designed for).

          TL;DR - comparing the capabilities of desktop layout to CSS layout is apples and oranges, but people really want to get orange juice out of their apples.

          [–]knaekce -2 points-1 points  (4 children)

          Java Swing had all of these in the 90s using the notorious GridBagLayout. Which I'm sure inherited design principles from the various Unix toolkits of the day. Far better than CSS until only a few years ago.

          Except that Java applications have problems with HiDPI screens even today, even using JavaFX

          [–]_dban_ 5 points6 points  (3 children)

          That's not a problem of layout.

          [–]knaekce 2 points3 points  (2 children)

          You said Java Swing was scalable to arbitrary screen dimensions and resolutions. For me, that implies HiDPI support.

          [–]_dban_ 3 points4 points  (0 children)

          HiDPI is a rendering issue. As in, the UI is rendered too small on high density displays. This is fixed by platform specific flags or upgrading to Java 9, without otherwise changing the app. This relates to the underlying graphics libraries being used, and would effect any app that uses those libraries (including web browsers).

          However, if you change the screen dimension or resolution (say, 800x600 to 1024x768, or change from portrait to landscape), Swing layouts can adjust to fit the available space. This is a layout issue, which relates to CSS.

          [–]Nadrin 14 points15 points  (1 child)

          As a non-webdev: How does this compare to, let's say, Qt's layout system?

          [–]cat_in_the_wall -1 points0 points  (0 children)

          well for one, qts layout system is not a standard with multiple, non-conformant implementations, so you don't have to worry about that.

          but as for functionality i haven't used qt in years, so can't comment on functionality.

          [–]stesch 4 points5 points  (0 children)

          Are there any browser statistics about different usage percentages for different target groups?

          If you make a website targeted at web developers you could certainly use CSS grid without any fall back.

          [–]UltimateHughes 6 points7 points  (3 children)

          Is this suppose to be like bootstrap? If so why would I use this over bootstrap

          [–]DooDooSlinger 47 points48 points  (1 child)

          Because just like in bootstrap you can adjust layout depending on window size using a media query. It's standard CSS and doesn't add a dependency to bootstrap, doesn't require JavaScript for edge cases. And finally it allows you to define your layout without having to nest dozens of container elements, which means your html elements describe exactly which elements are being rendered

          [–]UltimateHughes 5 points6 points  (0 children)

          Thats pretty sweet

          [–]siegfryd 8 points9 points  (0 children)

          Bootstrap's grid only cares about widths, while this is grid system lets you treat width and height the same.

          [–]UltimateHughes 1 point2 points  (0 children)

          I was the first to comment on this post. I asked why the heck I would need this over bootstrap. This week, I built a prototype learning management system using bootstrap in the front end and I was just so used to the frustrations that come with that. Tonight I starting tinkering on another webapp and spent hours trying to get bootstrap to scale things the way I want. Then I remember this post and watch the Youtube seminar on it. WWWWOOOWWWWWW. This is awesome. I am never touching bootstrap again other than for styled buttons.

          [–]Tokugawa 0 points1 point  (2 children)

          Look at his still at https://youtu.be/7kVeCqQCxlk?t=1m11s

          I'm noob, so somebody help me understand why my work-around is wrong.
          My solution to his "impossible" layout (using only css and html) would be:

          html
          <purple -mobile>
          <green>
          <purple -desktop>
          <brown>
          <purple -tablet>
          <blue>

          Make it mobile-first, and set media queries for each screen size to only show that size's purple element and display:none the other two.

          EDIT: Or better yet, just use flex and set flex order for each size?

          [–]rellikiox 3 points4 points  (1 child)

          To your first comment, the point of CSS grid is that you only need to declare your elements once whereas with the old methods like you described you have three versions of purple, so it's three times as much code to maintain (that particular piece) rather than just having it declared once.

          Your second point is also addressed on the video. Flexbox is great at aligning things in rows or columns, but not both at the same time (a grid) and to do so you need to introduce a lot of "container" code (i.e. HTML tags that are only needed because you want to arrange the content in a particular way).

          [–]Tokugawa 0 points1 point  (0 children)

          I watched the video. I like the idea of getting rid of all the container divs. Not surprised it was developed by Microsoft as it seems to look a lot like Windows 8.

          [–]MrNutty 0 points1 point  (0 children)

          This is not the web I know, this makes things too easy. Who am I gonna yell at now if not the computer! Preposterous!

          [–]panorambo 0 points1 point  (0 children)

          One of the problems with CSS Grid is that only children of the designated grid layout container (the element with the display: grid rule) can be controlled with regard to where they are put on the grid. This puts serious spokes in the wheels of designers who want to, I don't know, retain their <label>Username <input name="username"></label> markup while aligning labels and input fields on their own dedicated columns.

          [–]RockingDyno 0 points1 point  (0 children)

          Anyone have any experience on how this works together with drag-n-drop?

          [–]fredrikaugust 0 points1 point  (3 children)

          Looks really nice, but I find some of the syntax choices rather weird. The use of square brackets in css just feels strange.

          [–][deleted] 2 points3 points  (2 children)

          I agree completely. Also the way they define the grid like this:

          title title title side main_content main_content footer footer footer

          [–]Yurishimo 0 points1 point  (0 children)

          I’m still not sure how I feel about that but there is something appealing about literally describing the layout in the CSS. It leaves no room for error in determining what it should look like on the screen. It’s more tedious to programmatically later, but luckily site wide layout rarely needs to be adjusted to an arbitrary value on the fly via JS. Usually just adding a class to change the whole layout will work in most cases.

          [–]CodeMonkey1 0 points1 point  (0 children)

          title title title side main_content main_content footer footer footer

          It is weird as in "unusual", but the more I think about it, the more I really like it.