428149 (29) [Avatar] Offline
#1
An entire chapter is devoted to Grid Layout: at present, only 0.3% of browsers support this properly, so it will start to become usable in around 2027.

Conversely, all browsers use normal CSS, and very good layout tools such as Susy and Lost exist already. LostGrid would be particularly worth mentioning because it runs on PostCSS, along with Autoprefixer (which you mention briefly elsewhere).

I'm struggling to work out why you mentioned Grid Layout - in detail - but didn't mention LostGrid at all. Maybe that will be in chapter 8...

**********************

According to this informal online survey, the overwhelming majority of web designers agree with me that Grid Layout will be unusable until 99% of users' browsers support it. That will be in around 2027.

http://www.webdesignerdepot.com/2017/01/poll-when-will-you-start-using-css-grid-layout/
Jeremy Wagner (15) [Avatar] Offline
#2
For what it's worth, Firefox 52 went out the door yesterday. It has full support for Grid, as do the upcoming versions of Chrome, Safari and Opera. Partial support exists in Edge. Because of the nature of rolling updates to browsers (which are opt-in, by default), we'll see a significant jump in support across the board inside of this year.

In the meantime, feature queries are a reasonable mechanism for incorporating grid. A non-grid mobile layout can be created (as most web users are statistically mobile users) and then we can scale up gracefully for will likely be a sizable chunk of users on modern, grid-supporting browsers in the near future. Once Chrome has rolled out version 57, we'll be looking at a huge jump in support for users across the globe.

Writing a book takes serious effort and time, and part of the challenge is being able to divine the future somewhat. By the time Keith's book comes out, CSS Grid will be highly relevant, and Keith's book will cater to that growing interest.

-j
428149 (29) [Avatar] Offline
#3
>>For what it's worth, Firefox 52 went out the door yesterday. It has full support for Grid, as do the upcoming versions of Chrome, Safari and Opera. Partial support exists in Edge. Because of the nature of rolling updates to browsers (which are opt-in, by default), we'll see a significant jump in support across the board inside of this year.

A quarter of people use MS browsers, and these haven't even started to implement it properly. And who knows whether, if they ever do implement it, they will do so properly. A feature such as a grid, which breaks the entire page if it's not supported, can't be used until virtually 100% of browsers support it. This won't be for another ten years.

>>In the meantime, feature queries are a reasonable mechanism for incorporating grid. A non-grid mobile layout can be created (as most web users are statistically mobile users) and then we can scale up gracefully for will likely be a sizable chunk of users on modern, grid-supporting browsers in the near future.

Why even use a feature that's not supported by 99.7% of browsers, when we can use LostGrid, which is 100% compatible, is more powerful and is easier to use?

>>Writing a book takes serious effort and time,

I know: I have written books myself.

>>and part of the challenge is being able to divine the future somewhat.

You are assuming that people will still be using this book in five or ten years' time. Most computer books are out of print well before that. If it doesn't sell in its first year Manning won't leave it on the shelf for a decade on the off-chance that it eventually becomes relevant.

>>By the time Keith's book comes out, CSS Grid will be highly relevant

It's due for publication in 2017, not 2027. Anyone trying to implement a layout using CSS will have to look elsewhere.
Keith J Grant (30) [Avatar] Offline
#4
I spend the opening pages of the chapter explaining why Grid will be ready for prime time very soon, including partial support back to IE10. This is punctuated by the fact that both Firefox and Chrome have released updates that support Grid in just the past three days. I then spend the final section of the chapter explaining how to provide fallback behavior for old browsers. I have had my ear to the ground on this one for quite some time.

Grid is going to change how we design for the web. It will happen this year, and it has already begun.
428149 (29) [Avatar] Offline
#5
>>I spend the opening pages of the chapter explaining why Grid will be ready for prime time very soon, including partial support back to IE10. This is punctuated by the fact that both Firefox and Chrome have released updates that support Grid in just the past three days.

CSS features don't become usable just because the latest versions of browsers support them: they become usable when virtually all browsers in the wild support them. That won't be for many years.

>>I then spend the final section of the chapter explaining how to provide fallback behavior for old browsers.

But why introduce a technique which needs fallback for virtually all browsers, when you could explain another, better, technique, which is compatible with all browsers without any fallback?

>>Grid is going to change how we design for the web. It will happen this year, and it has already begun.
It may or may not change 'how we design for the web': we will have to see. It certainly won't happen until virtually all browsers support it properly and consistently. Microsoft browsers haven't even started implementing grids properly, so this will be many, many years in the future.

I have worked in web design since 1996, and have seen many, many fads come and go. You might be too young to remember Java applets, Silverlight, Active X or Adobe Flex. The one constant is that we have to use technologies which are sufficiently well-established to be usable on the vast majority of browsers. Web sites that fail on even 10 - 15% of browsers aren't acceptable.




Jeremy Wagner (15) [Avatar] Offline
#6
http://dowebsitesneedtolookexactlythesameineverybrowser.com

The fundamental assumption you make in your analysis is that all sites must look the same in all browsers and at all breakpoints, and your definition of "failure" hinges on it. When new features find purchase in browsers and percolate through the ecosystem, we have methods for getting around/falling back to alternative methods.

We've been fighting this battle to use new features in earnest for nigh on 20 years, the first 15 of which we suffered the mindset that all browsers had to display a given page exactly the same way. That mindset has changed, and we no longer have to make these assurances for clients. Build it mobile first using widely compatible means, therefore satisfying what is statistically likely to be the largest segment of your audience. *Then* use a feature query to find support for the layout mechanism of your choice.

IMO, even if "only" 50% of users support grid a year from today (which they likely will, given that Chrome has just rolled out support for it this week), I will use a feature query to serve a grid layout to capable browsers, and have all others fall back to the default mobile styling if the feature is unavailable, or if the feature query itself fails. Most users are on mobile devices anyhow, and it allows us to cut out the cruft and overhead of onerous frameworks that must be shed in the name of performance. These grid frameworks developed in the wild have shown us how useful a grid system can be. So much so that browser vendors are responding by incorporating them as native features which will allow us to eventually strip out framework overhead and improve rendering performance.
428149 (29) [Avatar] Offline
#7
>>The fundamental assumption you make in your analysis is that all sites must look the same in all browsers and at all breakpoints,

Most clients would expect precisely this, not some mixture of experimental techniques and failures. The last site I worked on paid Google $100,000 a year in advertising to create traffic. Even 3% of potential clients not being able to see the site would have been completely unacceptable. I can't imagine that a large corporation would accept more than 1% failure.

>>nd your definition of "failure" hinges on it.

My definition of 'failure' is when the page completely breaks. This happens when a page which depends on some technology for an essential part of its navigation or page layout doesn't have that technology in the browser.

>>When new features find purchase in browsers and percolate through the ecosystem, we have methods for getting around/falling back to alternative methods. ,

Sometimes we do, sometimes we don't. Each piece of new technology has to be considered carefully to see what happens if a browser doesn't support it. Sometimes polyfills exist, sometimes they don't.


>>We've been fighting this battle to use new features in earnest for nigh on 20 years, the first 15 of which we suffered the mindset that all browsers had to display a given page exactly the same way. That mindset has changed

I'm not aware of any clients who are happy with websites which only work for half their users. If you have some like that, good luck. As soon as they start to get phone calls saying that their website is 'down', they will start looking for a new web designer.

>>Build it mobile first using widely compatible means, therefore satisfying what is statistically likely to be the largest segment of your audience. *Then* use a feature query to find support for the layout mechanism of your choice.

In the case of layout, we can certainly do that - by duplicating the entire layout system using a technique which works in all browsers, plus some 'cutting-edge' technique such as CSS Grids, which is used in just 0.3%. However, this doubles the amount of work. A more sensible approach is to use technology which actually works in all browsers.


>>IMO, even if "only" 50% of users support grid a year from today (which they likely will, given that Chrome has just rolled out support for it this week), I will use a feature query to serve a grid layout to capable browsers, and have all others fall back to the default mobile styling if the feature is unavailable, or if the feature query itself fails.

So it fails on 50% of desktop browsers? What do users see? Blocks of text randomly strewn around the page?

>>Most users are on mobile devices anyhow

Most serious work is done on desktops: this will continue to be the case for the foreseeable future.

>>it allows us to cut out the cruft and overhead of onerous frameworks that must be shed in the name of performance.

No it doesn't. Somehow - using a CSS framework, using an HTML grid, or doing it by hand - websites have to be usable on all platforms and on all but the very oldest browsers.

Jeremy Wagner (15) [Avatar] Offline
#8
Should I not use border-radius because caniuse says 6% of users may not support it? border-radius is a W3C candidate recommendation. Speaking of which, Grid is one. It's not fleeting. It's here to stay, and its support by browsers will only grow (and well before 2027, by the by). It's been covered in a myriad of materials beyond Keith's book. Any CSS publication worth its salt will cover this feature, because it is forward-thinking to do so. If your argument is that Grid should not be covered in this book because it won't be useful or well-supported, then I don't buy it, and we will simply have to agree to disagree.
428149 (29) [Avatar] Offline
#9
>>Should I not use border-radius because caniuse says 6% of users may not support it?

Nothing is going to break if boxes don't have curved corners. However, the entire layout will break if the CSS Grid isn't recognised. Moreover, there are polyfills for curved corners: there isn't for CSS Grid.

>>Speaking of which, Grid is one. It's not fleeting. It's here to stay, and its support by browsers will only grow (and well before 2027, by the by).

Let's hope that eventually it becomes usable in production: I will certainly use it when it is. For the next few years, though, we will have to wait for those users who don't upgrade their browsers to ditch their old computers and buy new ones and for companies whose intranets depend on a particular old version of IE to go bust. And also for Microsoft to a) adopt it and b) adopt it properly. Given Microsoft's track-record of breaking browser standards over the years, b) may be a long wait.


>> Any CSS publication worth its salt will cover this feature, because it is forward-thinking to do so.

I agree that it should be mentioned. However, not at the expense of technologies such as PostCSS or SASS which are core skills any CSS designer needs in 2017. Moreover, he should add much clearer 'health warnings' about Grid, Flexbox and other new technologies. Newbies might well not understand the risks of using them. If he added a chapter on PostCSS and referenced the relevant plug-ins throughout the text then the problem would be solved.

>>If your argument is that Grid should not be covered in this book because it won't be useful or well-supported, then I don't buy it, and we will simply have to agree to disagree.

Grid can be covered - perhaps in an appendix of technology to look forward to over the coming years.