A few weeks ago I made a comment on Twitter about how underpriced every WordPress page builder is and one of the more exciting replies was from WordPress founder Matt Mullenweg:
It’s no secret that I’ve been a vocal critic of the Gutenberg project. To me, the vision of “for everyone” is an impossible vision that more or less guarantees that the block editor experience won’t be fantastic for anyone.
Beyond just the workflow experience, though, I can’t get interested in any dev tool or workflow unless one major thing is accounted for. Maintainability.
Building and maintaining a website are two very different things. In my estimation, creating a site that’s not maintainable is not an accomplishment. If you check one essential box (publishing), but fail to check the other (maintainability), you’ve failed as a developer.
This is why I’ve been equally critical of page builders like Elementor, Divi, and Beaver Builder. These page builders encourage users to build websites that aren’t easily maintainable because they don’t provide the necessary functionality to ensure maintainability.
If you’re not sure what I mean by maintainability, here are some videos you can watch:
- PB101: L07 – CSS Variables & “DRY” Development Principles
- PB101: L08 – DRY Development With Classes & Global Styling
- PB101: L12 – Styling With Color (& Scalable Color Management)
- PB101: L14 – Proper Dynamic Content Management in WordPress (CPTs, Custom Fields, Loops, & More)
- BEM 101: How to Make Web Design Organized & Scalable
- Utility Classes vs Custom Classes: How to Build Maintainable Websites Like a Pro
Since this is a topic of mandatory importance, I pressed Matt on the concept of maintainability with Gutenberg.
This is basically Matt saying, [You can build custom, maintainable websites with Gutenberg] “…since the release of the Twenty Twenty-Four theme.”
That intrigued me. Perhaps the block editor was further along than I previously thought.
So, I decided to try it by seeing if I could replicate “Feature Section Victor” from my Frames library. It’s an intermediate-level layout with feature cards that reveal an image on hover.
This is a layout that I can build from scratch in Bricks Builder in under 15 minutes and that almost any modern page builder can handle with ease. But what does the workflow look like in the Block Editor?
Is the WordPress Block Editor really “for everyone?”
I’m not new to front-end development. I’ve been building websites since I was twelve and using WordPress since 2005. I have had a successful agency for years and have published hundreds of hours of front-end development training videos.
The thing I’m definitely new to, though, is the Block Editor. All of my work is done in page builders. Namely, Bricks Builder.
My goal was to record myself trying to build Feature Section Victor. If the Block Editor is “for everyone,” then a front-end developer with tens of thousands of hours of experience should be able to use it without issue, right?
You’d think so. But it didn’t go so well.
Why I want the block editor to succeed
Contrary to what many believe, I want the block editor to succeed. I think WordPress is a more robust platform when it has a capable native builder attached to it. I also believe that having so many different page builders with so many different workflows makes things more difficult for the average user and more difficult for clients to find capable agencies using sustainable tools.
If the block editor ever manages to check all the essential boxes, I can see myself using it. I can see myself switching over to it, even. Doing everything natively in WordPress feels better from a philosophical standpoint.
The execution has to be there, though. I’ll never switch based on a positive outlook alone. Or philosophical visions. Or any other nebulous mumbo jumbo.
I love Kirby Smart’s line, “You’re either elite or you’re not.”
That’s how I treat page builders. You’re either elite or you’re not. And right now, as is true with most things in life, there is a toddler-sized handful of elite page builders.
If the block editor wants to be in that category at some point, the Gutenberg team has a lot of work to do.
Issues I knew I’d run into
I did some prep work to familiarize myself with the native blocks and Site Editor. I didn’t want to go in 100% blind, but I did want it to be a “first build” situation, so I refrained from actually building anything. I just wanted to get a lay of the land.
Here are some of the significant issues that I knew I’d experience:
- No stylable classes. The Gutenberg project doesn’t seem to believe that one of the most fundamental tools in web design – classes – are important.
- No unique semantic elements. There’s no
sectionelement, for example. So there’s no way to define global styling for a specific semantic context. - Poor HTML flexibilty. Groups can’t be converted into unordered lists or list items, for example. This makes building with semantic HTML next to impossible.
- No CSS Grid. You’re forced to use inferior flexbox controls for all layouts (unless you do what I did and write custom CSS).
- List view issues. The list view not staying available at all times has been a problem since list view was introduced.
- No partially-synced patterns. This is coming, I know. And I’m stoked about it. It’s the only thing that provides an important level of maintainability. Alas, it’s not here yet.
That’s not all. There’s a laundry list of other missing items that are essential to professional work that I didn’t even get to because the section I was building didn’t happen to require them.
Issues that surprised me
There were a few issues that I didn’t expect to run into during the build:
- Custom CSS is only available in the Site Editor, and the experience is atrocious. Keeping two editors open at all times is a bad workflow and a no-fly zone for people using single monitors or small screens. Additionally, the fact that the CSS editor lacks every fundamental feature, down to the lack of tab indent support, tells me that the Gutenberg team doesn’t ever want to see you writing CSS. The minute you take your coat off, they crank up the air conditioning. The message is clear, “Go somewhere else.”
- No element-based custom CSS. All custom CSS has to be global, it seems. You can’t attach CSS to specific elements on specific pages and certainly can’t attach custom CSS to classes placed on elements. This is a tremendous limitation.
- Some of the default styling is way too specific. I had to use
!importanton three separate occasions during this simple layout build. Not only that, I had to spend a bunch of time wondering why things weren’t working because it never clicked in my brain that the CSS I was writing was being overridden. Why? Because there’s zero logical reason for why it would be. Default styling should have zero specificity to allow the user total development freedom. - There is no way to share the pattern I made. While I can save the pattern I built to the pattern library, the fact that it required custom CSS in a separate stylesheet makes it unshareable. This defeats the purpose of the pattern library. I build custom layouts in Bricks, add them to Bricks’ pattern library, and push them out to thousands of users without issue every single week. This is not currently possible in Gutenberg.
- Most of the controls are unintuitive. The block spacing dial was set to “0,” but there was still spacing until I touched it. Everything requires too many clicks. Too much stuff is hidden and abstracted away. Fundamental names are changed, which requires experienced developers to relearn basic terminology. I could probably keep going.
- No width controls on any elements. Seriously? Wait. Seriously?
- “Content Width” vs. “Wide Width.” I still don’t know what “wide” is for. The only thing that matters in web design is content width. Beyond content width, users should be able to set a custom width value on any element. I can’t think of a single use case for a “wide” element unless it’s designed to break out of its parent container. However, I’ll defer to someone who finds this feature valuable – please explain why it exists so I can get in on the secret.
- Group vs. Stack control changes. It seems to make zero sense that I lose the “inner blocks are content width” setting when I change a Group to a Stack. The whole “Group, Row, Stack” concept is nonsensical in the first place. In web design, everything is a box. Any box can flow in any direction. We don’t need separate elements that can all behave like each other, and we certainly don’t need different elements that lose or gain fundamental settings when their flow direction changes. What does the flow direction have to do with whether or not an element is full width or content width?
- I couldn’t align my text to the left on mobile devices. The intro content is centered on the desktop, but the design calls for it to be left-aligned on mobile. Since there are no breakpoint controls in Gutenberg, this was a requirement I couldn’t fulfill without going back to custom CSS (something I didn’t bother with in the video).
Again, these are only the issues I experienced trying to build one relatively easy section.
“But Kevin, just build custom blocks!”
This will be the argument that many use. To which I say: Then it’s not “for everyone,” is it!?
Sorry, but your average front-end developer isn’t custom coding blocks in React. And why should they be doing such things when page builders like Bricks and Cwicly allow them to build anything they want with nothing more than decent CSS fundamentals?
You’re telling me that any time someone needs to do something more advanced than padding and flex alignment, they have to custom-code a block? Is this the “for everyone” experience? Is this the true vision of the WordPress block editor?
Not only is that not plausible, it’s wildly inefficient and impractical. Imagine stopping your entire workflow to build a custom block simply because you needed a card that reveals an image on hover.
“Custom blocks” is a terrible argument.
Now, if you have a different argument for how we should be using the block editor to build maintainable websites, I’m all ears! Please, show us!
Is the block editor a page builder?
One issue I’ve had with all this is that I don’t think most people even know what the vision of Gutenberg is supposed to be, officially. Is it supposed to replace page builders, or am I using it wrong?
I polled my audience on Twitter (which is relatively small since I just started actively using it recently), and it seems they’re just as confused as me.
66.7% of people think it’s supposed to replace page builders and 1/3 of the ecosystem thinks it’s not supposed to.
If it is supposed to replace page builders, then it’s failing pretty badly, especially considering the 5+ year development timeline.
If it’s not supposed to replace page builders, then what’s it for?
Update: Block Editor Demonstration Entries
First, here’s my demo of doing it Bricks Builder for comparison:
The following people have submitted respectful and thoughtful demonstrations of their approach to this layout in the block editor. I would recommend watching these to see their perspective and understand what’s required different from Bricks. You also might learn something new!
NOTE: Only post thoughtful, respectful comments if you choose to engage with these users.
Brian Coords (@briancoords)
Read Brian’s block editor thoughts as well.
Danielle Zarcaro (@QueerDevPerson)
Final thoughts
My basic conclusion matches my premise: the Block Editor isn’t for everyone.
And here’s the worst news: It stands almost no chance of being for everyone at any point in the future.
To build a good product, you have to pick a primary audience. Being “for everyone” is the fastest and easiest way to fail. Front-end developers and your average Joe Business Man are radically different people with different needs. Creating one editor that they both find intuitive and capable is an impossible task.
So, all that’s left to ask is: Who is Gutenberg for, then?
At the moment, it’s for three types of people:
- People who need to assemble a blog post. That’s what I’m using it for right now and what it’s best at.
- Developers who are going to custom-build almost all their essential blocks.
- Lay people or low-level freelancers/agencies who want to swap content in a pre-determined theme.
It’s NOT for:
- Beginner web developers who want to learn how to build websites.
- Intermediate web developers who want to build custom websites.
- Advanced web developers who want to build custom websites.
- Most agencies & freelancers (unless they’re committed to building custom blocks).
I want to like it, I really do. As it stands now, though, the only viable way to use the block editor to build a custom site is with third-party tools. Native ain’t cutting it.
What do you think? The comments are open. Sound off!
37 comments
N
Just fyi the first 3 PB101 video links don’t point anywhere.
Peter Jankowski
I find this all baffling. I tried many page builders and none suited my needs. With a combination of Wordpress, Toolset Blocks and Kadance Blocks I can build what ever I want without writing a line of code.
Faster, easier to manage and update and barely any restrictions on implementation of design. I’ve been building simple and complex website for decades. It’s never been as easy as it is now with Gutenberg. Page builders hold me back. Gutenberg sets me free.
Alisha Thomas
I think you missed the point of the article. He is talking specifically about using Gutenberg only with out any additional block editors or add ons. Of course those make it much easier! But Gutenberg by itself is a trash can.
Steven Gliebe
I’ve been experimenting with recreating my classic themes from scratch as block themes, using the new Editor. I’ve been able to accomplish maybe 80% similarity without custom CSS. All in all, I’ve found designing with blocks (and zero third party plugins) to be a success. Two years ago, no way… but I’m finally ready to take the new Editor prime time with my users. Designing with low-code natively is awesome.
That said, the Editor UI felt like a jungle for the first few months. It needs to be made more straightforward. The tools are good, but they way you get to them is somewhat convoluted and unintuitive. It’s really a whole new WordPress and no doubt people are going to have a hard time making that shift in their head. It’s easier now for designers (versus coding a theme from scratch) but harder for end users.
I want to see some kind of simple mode that will let users make the common changes like colors, fonts, logo, etc. on a single screen (as theme makes have been doing with the Customizer) without 9,000 other options striking terror in their heart. I might end up making an “Easy Design” screen under appearance to keep my less-savvy users from having to use the Editor at all.
Robert
Much ado about nothing. Was it ever possible to build a technically clean layout of medium complexity with WordPress without plugins, themes or manual programming in 2005, 2010, 2015, 2020? No. Can you do it now? Apparently still not, as the blog post shows. Did WordPress ever promise that with Gutenberg? Not really.
WordPress did not and does not impress out-of-the-box with its range of functions. It’s like the base plate of the LEGO system. It comes with the crucial “nubs” on which you can build anything you want, from a gingerbread house to a shopping center. If WordPress came with more than “nubs” as standard, there wouldn’t be 50,000 plugins.
Well, after years on the market you sometimes feel the urge to reinvent yourself, both inside and out. At WordPress, this was called Gutenberg Editor. According to Matt Mullenwang, it is defined as a “framework” and as a showcase, they gave the framework such counterproductive gimmicks as the “spacer block” from the point of view of serious developers. Other developers such as Louis-Alexander Désiré or Tom Usborne do more sensible and usefull things.
If professionals want to save time with WordPress thanks to visual support, a few years ago they turned to Oxygen, nowadays to Bricks, Cwicly and for special preferences or cases also Pinegrow, Builderius etc.. And if you miss something in Bricks, you can add extensions. And if you want to save even more time, you can add a CSS framework such as ACSS, Core, etc. That’s the game.
And the situation is similar with WordPress as a CMS. The basic functionality is rather poor. So there are ACF, Metabox and so on to create a useable interface for database entries.
The large market share of WordPress is due to its flexibility, its LEGO functionality, its accessibility for semi-professional developers (themes and page builders save this group PHP knowledge) and the law of increasing returns.
It is in line with the philosophy of WordPress and its ecosystem that the native Gutenberg editor is of little use to professional developers. So what?
Julian
Hey I am a complete noob here, with limited knowledge of code, have been building wp websites with wordpress from 2009, using themes and some page builders. the approach that wordpress took from years ago with gutenberg is the worst, at least the classic editor gave you basic understanding using the wysiwyg method and some html but with the introduction of gutenberg it all became unintuitive and basically a pain in the you know what to build in wordpress. So not only for devs its a horrible experience but for people who do not know anything and need to adapt to a faulty system, thanks to Kevin, many of people like me are elevating core skills and working towards a more reliable environment while still having the chance to compete with experienced developers, as a designer I take the page builder route as a viable one, so its great that someone with enough knowledge stand and say what’s needed to be said.
Kevin Geary
I agree, thanks for sharing.
Kevin Geary
Sounds like you didn’t read the tweet exchange. And sounds like you haven’t read enough into the future of the block editor and what their vision is. And how they plan to try and squeeze out page builders like Bricks.
This post and video relate to both the present and the future.
Robert
First of all, I like Bricks, ACSS, and your role as an evangelist of scalability, maintenance and clean code. And from a marketer’s point of view, I like your smart and entertaining way of developing your own personal brand. So you wrote: “… they plan to try and squeeze out page builders like bricks”. And you mentioned in your tweet how underpriced page builders are.
Well, Bricks was launched in 2021 when Gutenberg was already on its way. How many or how few sites run with Oxygen compared to the number of all WordPress installations in 2021 was just as obvious as Automattic’s “vision”. WordPress page builders are at the penultimate end of a chain of dependencies (at the very end are their add-ons). They are mainly aimed at people who have weaknesses in HTML, CSS, JS or PHP. And these Bricks customers don’t usually sell five or six websites a year at $20,000 — at least not in the beginning. If you earn that much with WordPress, you have no problem paying $1000 or more for Bricks.
Is it underpriced? I would agree. But a cleaner who cleans up other people’s mess is, in my opinion, just as heavily underpaid compared to a notary, for example, who notarises more or less the same sample contracts his entire professional life. I don’t like capitalism, but when you operate in such a market, people have to deal with its mechanisms. Wordpress is an ecosystem for the masses with a lot of “cheap”, and in not so few cases “underpriced” products. On the other side due to this ecosystem you can sit with your PC e.g. in Chișinău, Moldova, where the average monthly income is about $200 and you can get involved in digital business.
David Robertson
I first tried (or toiled) Wordpress in the mid 2000’s for a while then lost the need for a website. When I decided my photography portfolio could benefit from having a portfolio I finally plumped for SQSP for ease (and laziness!).
Since retiring from my day job I am starting to develop several website ideas and my photo site is long overdue for a refresh. Time to try try WP again. Now I am not a stupid man and I have a technical brain as well as being a creative (retired airline ‘capitan’) but I gave up trying to understand the philosophy that FSE is promoting.
You list many developer/builder shortcomings Kevin, most of which are beyond my present understanding, but I’m getting there. My frustration starts with just navigating the theme editor buried pages/templates/patterns…thats where the header hides, before I even start to try and build pages and posts.
To me it has not changed from being a blogging site blackbone in the 2 thousand and something and it still is today. 20-20-4 even loads a blog archive as its opening presentation.
I like the concept, its a huge company with millions of installs which dwarfs the likes of Bricks in size and employees. The latter risks all our hard work going up in smoke if it goes under as its not backwards compatible.
I cannot code much, I’m just starting to understand clamp, and I have half a dozen site ideas…but I still plumbed for Bricks. I am only scraping the surface but it is a whole lot easier to understand, better engineered and more fun that Wordpress!
Just a penny’s worth of my non-dev thoughts from Brighton UK (or maybe that should be cents in this hallowed company 😁).
David
Gaurav Tiwari
This ‘experiment’ is going to change WordPress site building in a big way! Thank you for doing this.
Tom
Gutenberg is just WP’s version of a “Page Builder”. I don’t see the third party ones ever disappearing with how it is turning out. In a way it reminds me of WP implementation of custom fields. No one uses those anymore and instead uses ACF, Metabox, etc…
One thing I don’t understand is why Gutenberg doesn’t have any built in responsive controls. I am surprised it doesn’t come up more often (unless I am clueless and really missed seeing the controls some where).
Anne McCarthy
Hey Kevin!
Thanks for making this video. Like Riad, I’m a sponsored WordPress contributor (sponsored by Automattic for transparency) and ran the FSE Outreach Program for 3.5 years. You touch on many of the main points we continue to see and are continuing to work on. Here are some of the top items on my mind that overlap with what you raised:
– Expanding and simplifying layout: https://github.com/WordPress/gutenberg/issues/42385
– Show style hierarchy: https://github.com/WordPress/gutenberg/issues/49278
Improve pattern management: https://github.com/WordPress/create-block-theme/issues/287
– Add more clarity around global vs local changes (this cuts across a number of issues): https://github.com/WordPress/gutenberg/issues/55025 & https://github.com/WordPress/gutenberg/issues/53483
In case you’re game, I’m going to drop open GitHub issues for you that Riad didn’t already cover to chime in on or just read about (or ignore). I’ve chimed in for you in a few places and am happy to do the same for the rest but it always helps to hear directly from folks.
You mention frustration around where and how the + button shows up which touches on the following: https://github.com/WordPress/gutenberg/issues/26404
>The list view not staying available at all times has been a problem since list view was introduced.
You mention a desire to have List View and the Inserter open at the same time. I commented on the following issue with your feedback: https://github.com/WordPress/gutenberg/issues/29468 I’m assuming this is what you meant by the above in your write up but let me know if not.
>Double save button. Command + s should probably not show you the save confirmation step and just saves all (maybe it could be a preference)
Add ability to turn off double confirmation multi-entity saving screen: https://github.com/WordPress/gutenberg/issues/38714
>Lack of text alignments on groups/containers.Lack of width controls (block support)
Add text alignment control to group block: https://github.com/WordPress/gutenberg/issues/47942
>Support layout (flex, grid) for list blocks.
Opened this to cover Riad’s actionable note there: https://github.com/WordPress/gutenberg/issues/57272
>Additionally, the fact that the CSS editor lacks every fundamental feature, down to the lack of tab indent support, tells me that the Gutenberg team doesn’t ever want to see you writing CSS.
Global Styles Custom CSS: Add inline code completion and linting to input box similar to customizer: https://github.com/WordPress/gutenberg/issues/47945
Added a comment linking your blog post and sharing a quote for good measure.
>Most of the controls are unintuitive. The block spacing dial was set to “0,” but there was still spacing until I touched it. Everything requires too many clicks. Too much stuff is hidden and abstracted away.
Styles: show a hierarchy of styles clearly: https://github.com/WordPress/gutenberg/issues/49278
>It seems to make zero sense that I lose the “inner blocks are content width” setting when I change a Group to a Stack.
Keep width settings when transforming to container blocks (row, stack, group): https://github.com/WordPress/gutenberg/issues/40059
In terms of interactivity, I did want to mention the Interactivity API: https://make.wordpress.org/core/2023/03/30/proposal-the-interactivity-api-a-better-developer-experience-in-building-interactive-blocks/ Check out the following 6.5 roadmap for a better sense of what’s coming up ideally for the next release: https://make.wordpress.org/core/2023/12/07/roadmap-to-6-5/ The site https://wpmovies.dev/ helps show off the possible future of this API and I think touches on nicely with some of what you’re trying to accomplish here.
As you have more unanswered questions, ping anytime. I’m @annezazu in WordPress.org slack and am always keen to help connect dots here around important feedback so we can continue iterating on the right places.
Anne
P.S. on the topic of page builders, I think you’ll find Matt’s response to overflow state of the word questions helpful: https://make.wordpress.org/project/2023/12/12/overflow-questions-from-state-of-the-word-2023/#comment-439
Nico Morgan
Really great to see such proactive feedback from the team itself. Thanks Anne.
Hank
One of the major pet peeves about Gutenberg is the shift in canvas size when one uses the ‘Block Inserter’ Toggle. The whole canvas shifts and it is very jarring, distracting, and annoying. Unfortunately, the ‘Block Inserter’ Toggle in Gutenberg also opens up panels for Patterns and Media. Thus one has to constantly deal with a shifting canvas.
Page builders have been very successful in the WordPress ecosystem, and outside of it.
What is common among all page builders? From the most popular page builder, Elementor, to the newest professional page builder, Bricks, or any other page builder outside of Gutenberg?
The canvas size doesn’t shift. It is a constant. No matter what settings are being toggled or which panels are being used, the canvas doesn’t shift.
This is how it must be. This is the ideal.
The general layout of any modern page builder within WordPress is that there are two panels on either side.
The Elements/Style panel on the left and the Structure panel on the right, with the canvas in the middle.
It has been a tried and tested UI/UX for almost a decade now and it has widespread market adoption. There is no need to reinvent the wheel in this sphere. Webflow uses a variation of this with the style panel on the right and the element panel on the left with a structure panel that doesn’t remain open at all times, a flaw.
Elementor, and especially Bricks, have nailed this UI/UX.
It would be ideal if the Canvas in the middle remains untouched and is impervious to shifts, no matter what elements, patterns, media, toggles, or any other settings a user clicks in the editor.
This is a major pain point in Gutenberg and if it can be addressed that would be a major win.
Kevin Geary
Wow, Anne, thank you. I appreciate your thorough response. I will read through these links over some of the holiday break. Cheers.
Saxon Fletcher
Feedback on the layout issue would be helpful in particular. The POC branch adds width/height controls for example and takes steps towards content and wide options being treated more like predefined width values.
The POC branch is here for testing https://github.com/WordPress/gutenberg/pull/53455.
Better grid support is also on the radar but ideally can do this in a more intuitive way via canvas interactions.
Riad Benguella
Hi There! Gutenberg contributor here. Thanks for making this video, there’s some really good feedback on it that hopefully will make its way into Core.
It seems like the big frustration is that you’re trying to apply your developer knowledge to the editor (prefers grid over flexbox, wants to use BEM css, automatic.css, control the markup) while the editor tries to talk to users in general (without specific code knowledge) creates a lot of valid frustration.
I wanted to address some of the things that could have helped you along the way that exist in the editor already:
– Applying semantic markup is possible (section, main) under the advanced section of group blocks.
– Shortcuts for inserting blocks exists (option+command+y and option+command+t or just “Enter” for text blocks)
– Switching between global styles and block instance sidebar in the site editor is possible (to avoid having to use two tabs).
And here are the potential actionable items that I extracted from the video:
– Lack of text alignments on groups/containers. (Seems like an easy win)
– Lack of width controls (This is planned but have some backward compatibility aspect to it that may have delayed it https://github.com/WordPress/gutenberg/issues/28356)
– Lack of custom CSS at a block instance level https://github.com/WordPress/gutenberg/issues/56127
– Partially synced patterns https://github.com/WordPress/gutenberg/issues/53705
– Maybe in large screens, have a way to keep both list view and inserter open
Double save button.
– Command + s should probably not show you the save confirmation step and just saves all (it could be a preference)
– Support layout (flex, grid) for list blocks.
– Sanitize the custom classname input.
– Grid block is already there but is experimental for now (until we’re ready to commit to forward compatibility forever)
Kevin Geary
Thanks so much for your reply. Just a quick note on something: I know you can change the semantic tag on the group block. I did that in the video, actually. But that’s not a good solution as I’ve detailed in the past. I can share more details on why a physical section element is extremely important if anyone on the core team is interested in having that discussion. But again, thank you for the reply – that’s all very helpful insight.
Mike Kelly
Hi Kevin, can you elaborate on what you’d like to see for semantic tags? The output when you choose `section` for a Group is:
I don’t like that semantic HTML is “advanced” and hidden. It should be encouraged. It would be nice to type `/Section` and insert a Group with `section` pre-selected. I am going to open a ticket in the repo for that.
Any other changes you would like to see?
Mike Kelly
My code got stripped. But the output is an HTML `section` element with the class set to `wp-block-group`.
I tried typing `/section` in the Editor, and Group does appear. It doesn’t appear for `/main` or `/aside` though. It seems this is because the Group block has set a `keyword` for “section”.
What I think it should do is use the Variations API to support named blocks for each semantic element and also set the correct attribute on them. This would make semantic HTML more prominent in the Editor.
https://developer.wordpress.org/block-editor/reference-guides/block-api/block-variations/
I am going to submit a PR for this.
Mike Kelly
PR submitted.
https://github.com/WordPress/gutenberg/pull/57299
Kevin, is this an improvement? What would make it better?
Kevin Geary
It’s a good start, Mike. To me, though, a Section element is more than just a box with a semantic section tag. This video explains: https://youtu.be/s5zmRePNN0A?si=P-HxQRY-lUHb8Mh4
David
What I don’t understand is, isn’t one of the reasons for the extreme popularity of WordPress the huge ecosystem with a large selection of page builders? And those page builders in turn result in thousands of other addons, templates, etc. Why would WordPress want to put all those builders out of business? Seems totally counterproductive.
Kevin Geary
They want to consolidate everything into the block editor and a single API.
Richard Hawkins
There’s a lot of frothy Gutenberg hatred out there. Devs that looked at it once, when it came out, hated it, and are still complaining about things that got fixed a long time ago. Thank you for not making one of those videos Kevin!
I wanted to flag two Gutenberg tickets I submitted recently, that I think would have saved you about 10-15 minutes:
1. So there is a “section/group width” option in the toolbar (that doesn’t appear in the sidebar) that I think would have entirely saved you creating a new “Full width” template. However, it doesn’t appear in the sidebar, and is therefore just a solitary icon and is super easy to miss: I watched several users do this recently in tests… there are several other important options for other blocks in a similar situation. I submitted a ticket to ensure all toolbar options appear in the sidebar, here: https://github.com/WordPress/gutenberg/issues/55993
2. On your point about the number of clicks. I appreciate why the WP devs have tried to simplify the interface as much as they have (given the nature of the user base), but I really don’t see why more experience users shouldn’t have an option to have all sidebar settings appear by default, so everything is there like most other builders, this would have saved you SO MANY clicks. Ticket for that is here: https://github.com/WordPress/gutenberg/issues/55994
A couple of the issues you’ve flagged—css editor shitness, list view disappearance and the block spacing zombie default—have been irritating me for ages and I hadn’t even managed to put them into words!
Having said all of this, and having been involved in a lot of user testing recently, I think we would probably all be surprised by the results if we plonked a few experienced non-builder Wordpress developers into Bricks with only a bit of prep and the same task…
Ron Amick
FYI, Re List View (which was a fantastic breakthrough when it was added): there is a preference setting for always opening List View. It does not, sadly, cure the problem of taking List View’s place when the block chooser panel is invoked (with the blue + or when you choose “see all” elsewhere). But at least it opens the List View by default for any page or post.
Kevin Geary
Thanks for the detailed reply! I appreciate it.
I’d love to see a talented front end developer who has never used a page builder try Bricks. I think most of the complication would just be in familiarizing with the UI rather than saying, “Why does this super important feature not exist and why are the names for everything dumbed down?”
In my experience, if you understand the fundamentals of front end web design, Bricks is insanely easy and intuitive to use. Gutenberg is the opposite. No matter how much experience you have or how much you know, Gutenberg will confuse you.
Richard Hawkins
Yeah, this seems true *and* I would appreciate more devs engaging with the challenges of making a product for such a massive (80+ languages?!) user base. That is just hard, even though I agree with you that “for everyone is for no-one”.
Matt Eastwood
Hey Kevin, thanks for taking the time to do a deeper-than-I-had-the-patience-for-so-far-dive into Gutenberg. During the premiere, I voiced my confusion about who this is for: it very obviously wants you to just use the pre-made blocks and shut up. Trying to do any advanced page building with it feels like a square-peg/round-hole situation. Still, I seem to hear a lot about Gutenberg for page building. I’m surprised to see that I’m not alone with my confusion. I thought I simply hadn’t been paying close enough attention, but apparently, a ton of people are just as confused as me.
A month ago, I was at the first WP Meetup in Saarbrücken, Germany. The keynote speaker was adamant that page builders are gonna die out, with Elementor being the last to go because they have the most money.
Um, no and also, wtf?
Joe Fletcher
Same thoughts, Matt. There’s a lot of optimism that Gutenberg can do all the things, but I have yet to see any kind of proof that there are real web developers building real quality websites with the kind of speed, efficiency, and UX joy that something like Bricks Builder delivers.
If I’m wrong, let’s see a head to head comparison / competition of a Gutenberg user vs. a Bricks user building the same page. Let a Gutenberg fan propose the matchup so there’s no excuses.
Kevin Geary
Yes. I think that’s the issue. A8c can’t be antagonistic toward page builders while also providing a dysfunctional editing environment.
António Carreira
You might have missed the advanced tab. In there you can add CSS classes to any element, and can also set a group to be a div, section, header, footer, aside, etc.
I agree that Gutenberg is still not for everyone, and specially not for unexperienced users. The way I see it is: it can be a replacement for a page builder, if you know what you’re doing and don’t mind using a few additional classes and some custom CSS.
But, for most users it’s a replacement for the classic editor. That’s where it really shines. I would never give my clients control over Bricks or Elementor or whatever page builder. For my clients, Gutenberg has been a great experience, they learn the basic blocks quite fast and they can produce complex layouts within their content. Of course they won’t be building layouts, that’s not their job, they just want to create and edit content, and for that Gutenberg is just perfect.
From a developer point of view, I can build my layouts using Gutenberg as a page builder. A few years ago I was building them with PHP and no page builder, so it’s more or less the same.
Page builders can make a huge difference when it comes to advanced features, that’s undeniable. I probably wouldn’t be able to use Gutenberg without a few custom blocks here and there. And, while I agree that it’s not easy to get onboard with React to build custom blocks, after a while you start to have your own block library, that perfectly fit your needs. And let’s be honest, how many custom blocks do you need? A content/image slider, a content/image carousel, an advanced lightbox gallery and a few more? A few months into developing custom blocks, I can now reuse most of the blocks I created and add some new features whenever needed.
I have nothing against page builders, and I still recommend them to some users. For me, Gutenberg works great and brings me closer to the WordPress core.
Kevin Geary
It sounds like you didn’t watch the video or read the article.
Matt Eastwood
Kevin uses the Advanced tab in the video. While watching, I felt like I was back in my Beaver Builder days. That builder allowed me to assign classes, too. But I then had to go to a different area to write mile-long stylesheets, because BB had no way to style those classes or do anything with them, really.
At the moment, from what I’m seeing (and the times I’ve experimented with it), Gutenberg unfortunately isn’t for me. However, I find it encouraging that you have a good experience with it. As you say, it brings you closer to the WP core and that’s an important thing.
António Carreira
I agree that it’s far from perfect for most users.
I can build most layouts with some auxiliary classes. If you enqueue your stylesheet in the editor and make some adjustments to theme.json, you’ll get a much better experience on the editor, and it’s not far from the end result on the frontend.
Using Core Framework, for instance, will make it even better, since you’ll get auto-complete and real time preview for all the classes.
Having used several page builders for a few years drove me away from WordPress, and that’s what made me look into Gutenberg. A lot of people talk about the poor performance of Elementor and other page builders, but that can be easily fixed. But when it comes to performance on the backend, all those seconds it takes to open a page builder editor or go through the dozen of tabs, you’ll never get those seconds back, and that’s what really messes with my workflow.
I’m not saying Gutenberg is for everyone or that is it the best tool for the job. I’m just saying it’s not as bad as most people think, and if you know your way around it there’s no limit for what you can build with it.
Kevin Geary
Automatic.css has real-time preview in Gutenberg along with right click context menus that Core doesn’t have. It’s still not a good experience because Gutenberg is not a class-based editor and doesn’t have any usable inputs for variables.