Gutenberg editor styling: more work for CSS developers?

Many agencies trying out Gutenberg early seem to have run into issues styling the editor. Keeping the front end and editor styles similar and in sync will be even more important with the new editor because of its visual nature, but it doesn’t seem like it’s going to be easy for developers.

In June, Marie Manandise wrote about her Gutenberg research at Studio 24. The post is quite long and worth reading even though Gutenberg development has progressed a lot since then. One of her main conclusions was quite scary though:

Were we to implement one of our current websites with Gutenberg now, we estimate that the extra CSS work required to style blocks in the editor and the complexity of updating block markup would more than double our development and QA time.

And that’s not counting the time to invest in coming up with internal best practices, build tools and a potential bank of re-usable components. 

“We tried converting a bespoke website design in WordPress with Gutenberg” on Medium

Luehrsen Heinrich‘s more recent experiences building a site for a game studio were overall positive, but they too mentioned this in WP Tavern’s article:

From a development perspective, Luehrsen said his team still struggles with the backend styles for the editor and that frontend and backend styles differ wildly because of that. They also haven’t yet found a maintainable, stable way of applying global styles to the Gutenberg editor.

“How a Munich-based Game Studio is Using WordPress and Gutenberg to Power Its Website” on WP Tavern

Exciting times. Hopefully there’s still time to do something about that now that 5.0 development has been pushed back to November.

Moving from CSS Frameworks to CSS Grid

This is a long-overdue blog post version of a talk I did at WordCamp Stockholm in November 2017.

I’ve been playing around with various CSS frameworks for the past eight years. All these frameworks like Foundation, Bootstrap and Blueprint have really only served one purpose for me: to disguise the fact that until now, layout in CSS has been a hack.

Continue reading “Moving from CSS Frameworks to CSS Grid”

Debugging SASS in Chrome

In Firefox, viewing the original SASS line number directly has been possible using Firebug and FireSass. Similar, or even better functionality has very recently arrived in the stable release of Chrome. I just tried this out and it works wonderfully. See here for instructions:

How to make Chrome understand the SASS/SCSS in your rails app

Don’t worry about the Rails stuff, these instructions work just as well for stand-alone SASS. If you’re using Compass like me, you need to set sass_options = {:debug_info => true} in the config.rb file of your project.

If you look at your css files after doing the above, you’ll see they are quite a mess. From a comment by Paul Irish in the above post I learnt better stuff is on its way thanks to the upcoming SASS 3.3, and Source Map support in Chrome:

Debugging SASS with Source Maps

Exciting times!

SASS, LESS and nesting overload

Both SASS and LESS are really nice tools for CSS developers. Both have the ability to nest selectors like this:


#header {
   h1 { font-size: 3em }
   p { font-size: 1.2em }
}

…which compiles to


#wrapper h1 { font-size: 3em }
#wrapper p { font-size: 1.2em }

Nesting is really useful, just don’t go more than 2-3 levels deep. I’m currently wading through a bunch of code which was generated from LESS files, and the (huge) stylesheet is full of selectors like this:


html body #wrapper #header #access div.menu-header ul.menu li.menu-item-home.current-page-item a:link { ... }

You have been warned!