CSS
Two years ago when Web Tools was released, CSS Grid was not supported in its current form by any browser. Now it is supported by all of them. But, in my opinion, unlike most features of CSS that have come before, Grid needs some good tooling around it to help ease work with it in development. So I have started to work on some tools to help with Grid and along the way, I have been dabbling a lot with Grid.
Below is a basic experiment: reproduce the layout of the new App Store on iOS. Along the way, I also found good use for CSS Custom Properties — Variables. I hate that they aren’t called variables. — in setting the background of articles, the background and text color of the text block on each, and more.
CSS is getting more and more powerful. But, along the way, it is getting more and more simple. Where old layout techniques (tables, floats, flex box) were truly ill-suited for layout, CSS Grid is 100% made for layout. So go, dabble with Grid. Grab a comic book and reproduce the layout. Or a poster from the 70’s. Learn the ins-and-outs of it because this is the future of where front-end web development and web design is.
Permalink
I’m opinionated. If you’ve worked with me or hung out with me for any period of time, you know this. I’ve been building for the web since 2001, before JavaScript libraries, before CSS, before Web Standards. That is a lot of years of experience and with it, one learns a few things. The Standards movement was a major thing just as I was getting started freelancing. jQuery was just coming about as I entered and assisted in teaching a JavaScript class in college. Responsive Web Design was coined and defined as I started my first role at an agency in Chicago.
One learns a few things.
Of the last few years, I have pushed hard against using jQuery. Simply put, most browsers have solid support for new technologies that emulate many of the great features of jQuery. Those native features do it faster, better, and require less code. Remove jQuery and you remove 30+kb of resource load.
I have pushed against Bootstrap. It is a large beast of a library when most sites that include it use it for a grid system and not much else. A grid system can be written in less than 100 lines of CSS that’ll achieve the needs of your site specifically, so why include 200+kb of resources?
I have pushed against WordPress. It’s not good for the developer and offers a not-great experience for the client. There are better CMSs.
So this Summer and Fall, I decided to dabble.
I hadn’t built a website on WordPress in many years. The last one I built was before ACF took off. So I built a client a site in WP and I didn’t hate it. Much of what I have said against WP remains true. Especially after launching a large site on Craft earlier this year. But, for what it does well, it does well. Build a couple of custom plugins was a breeze. ACF made storing complex data from two third-party sources easy and displaying it easier.
I have never used Bootstrap but always maintained that it is best suited for prototyping and administration panels. So as I started building an admin panel for a current project, I decided to try Bootstrap. And I didn’t hate it. There are parts that I won’t touch. The grid system is actually one of them. The spacing utility classes, while useful if you are not writing a lick of CSS, are another. But, the component structure isn’t far from something like Atomic CSS and is actually a welcome thing for the needs of the project. Unfortunately, it requires that the page resources weigh over 300kb, which means I will likely scrap Bootstrap in a few weeks and rewrite with my own CSS.
We must, as developers, not become set in our ways and get dogmatic about certain things. There are things that we should be more opinionated about than others. I wasn’t necessarily wrong with either WordPress or Bootstrap. But, now that I have worked more with each, I can see the lure of them when it comes to getting something done quick and dirty. Atop that, I now have a more solid argument against some points of them.
So if you haven’t dabbled with something in a while or at all, maybe try. You may learn a few things.
Permalink
But the core principles and mechanisms [of CSS] are no more complicated than they were a decade or even two decades ago. If anything, they’re easier to grasp now, because we don’t have to clutter our minds with float behaviors or inline layout just to try to lay out a page. Flexbox and Grid (chapters 12 and 13, by the way) make layout so much simpler than ever before, while simultaneously providing far more capability than ever before.
Eric Meyer
I built my first couple of layouts with Grid over the last weeks. Hot dog. Things that would have taken me forever with floats took me just a couple lines of code with Grid. I’ve been using Flexbox for a while, to the point of mostly knowing the syntax, but Grid is a brand new beast.
It is astonishing that we have, for almost 20 years of CSS, never had a native layout system. Now we do. Instead of complex (and large) libraries like Bootstrap, we can now do complex layout with simple syntax. Hell, we can do far more complex, asymmetric and two-dimensional layout with Grid that we would never consider doing before. A renaissance in web design is coming. But are front-end developers up to snuff?
Permalink
The subtle difference between progressive enhancement and graceful degradation is lost on too many. Many of those that support “mobile first” don’t support progressive enhancement, which is an oxymoron.
Mobile first is progressive enhancement. Start with the most important part of any site: content. Mark it up. Semantically. Why? Because some readers experience your site without CSS. It’s true. Some just want the content. Screenreaders and search engines are the largest of these.
Then style the content. That’s the CSS. Mobile first says start with the LCD, the Lowest Common Denominator: mobile. But make sure that your CSS works in the LCD. That might be IE 9. It might be IE 11. Look at your analytics if possible. Progressive enhancement means add features when available. Progressively enhancing. You see? So if you are using a feature that is only available to IE 11 and better (Chrome, Firefox, etc.) and you need to support IE 9, make sure that the feature is not necessary for the user experience.
Then JavaScript. Understand that some have JavaScript disabled. Whether it be over-cautious IT departments, search engines that cannot handle rendering and parsing JavaScript, users with bad network connectivity that fails to load it, or most importantly screenreaders that help those with handicaps consume the content of the web. JavaScript is an enhancement. So long as you have the last two components set, your page works fine when JS is turned off. So, as features are available, use them.
But see, too many developers these days have abandoned this methodology that fueled the Web Standards movement. Instead, sites require over 300 kilobytes of JavaScript libraries and don’t load anything if JavaScript is disabled. Instead of starting with content, they start with jQuery, Angular, React, or whatever the library de jour is. Everything is built in JavaScript. This is graceful degradation, start with the Greatest Common Denominator. Except many aren’t even testing for the LCD. They aren’t turning off JS to make sure that their site will work for those that disable JS. Often they even break the most basic components of the web browser: the URL and the back/forward buttons.
We need to get back to progressive enhancement as the standard. We need to get back to the promise that the web is accessible to all, no matter the device they use.
Permalink
When every new website on the internet has perfect, semantic, accessible HTML and exceptionally executed, accessible CSS that works on every device and browser, then you can tell me that these languages are not valuable on their own. Until then we need to stop devaluing CSS and HTML.
Mandy Michael
Preach! It’s all I see these days in job descriptions. JAVASCRIPT! Ninja preferred. Rockstar acceptable. And then they produce crap frontend code. Their HTML and CSS is restricted to Bootstrap at best, custom crap with style attributes all over the place at worst. When I was their age, the emphasis of frontend was on the other side of the triangle: HTML and CSS. Without these, your JavaScript means nothing. Even if you are embedding your CSS and HTML in your JavaScript. Shudder.
Permalink
Remember faux columns? I just did equal-height columns with flexbox yesterday. The old days sucked.
Now if we could just convince the kids to stop putting HTML and CSS inside the JavaScript…
Permalink