Haris Zulfiqar

Gutenberg Theme Styles Integration and almost WYSIWYG

Haris Zulfiqar

·

I am betting on Gutenberg.

WordPress desperately needed a modern editing experience to evolve from the blogging platform it was, to the CMS that it is now.

Competing with website builders like Wix, Squarespace, and Shopify that keeps chugging away at WordPress’s market share called for an obvious solution, an editor that made building websites easy. TinyMCE could never achieve this. Plugins and themes that built their own solutions helped but that required installing and configuring them to make WordPress ready to build websites.

Gutenberg fills this gap. It is an important gap to fill and I’m glad that this is taken seriously.

Recently, I’ve been trying to learn the reason behind the approach Gutenberg took in comparison to all the website builders out there. I asked this question on WordPress’s official slack channel. I wanted to understand the reason behind the choice of the backend approach of Gutenberg which requires writing CSS styles for both the frontend and backend, separately. I wanted to understand why Gutenberg didn’t take the approach of frontend editing experience from the get-go because that would offer tighter integration with the existing themes without additional requirements. We already have so many successful examples in the form of existing website builders.

I couldn’t find an answer to it. I understand that Gutenberg was critical and we might eventually get to the point where frontend editing experience might be offered but my current opinion is that even with the full-site editing experience, we will still have almost WYSIWYG editing experience which is actually an inconvenience for the developers and strange for the users.

According to the replies on the official WordPress slack, I was explained that this is simply a user-interface gap and Gutenberg blocks work similarly to the existing frontend editors (Elementor in this case). I understand their explanation behind the user-interface gap but this is a huge gap that doesn’t simply feel like a user-interface gap.

From the tech perspective, Elementor only requires frontend markup once to build its block. Gutenberg, on the other hand, requires building a view for both backend edit and frontend save.

For this same reason, I am hitting roadblocks in the development of my own Gutenberg plugin. I found an ugly workaround to match the styles in the frontend but it is still an almost WYSIWYG experience. This could have been avoided with a frontend editing experience. This causes inconvenience and a lack of full integration when developers don’t have full control over the theme’s style. To explain this further, theme editors need to update and build styles for Gutenberg blocks. In comparison to Elementor, this is not a requirement.

3 responses to “Gutenberg Theme Styles Integration and almost WYSIWYG”

  1. Matías Avatar
    Matías

    Great reflections, Haris. I’ll try to cover some of the points. The main reason for the edit / save split comes from the reality that the ideal and most semantic markup for rendering content to visitors is not necessarily the most semantic (and accessible) markup for rendering the interactive model of the block within the editor, particularly when there is a design emphasis on direct manipulation. It’s more evident on those blocks where the interactive capabilities are richer but I’d say it remains an important aspect for all blocks to consider.

    The mindset sort of follows these two thoughts: “what is the most meaningful and simple markup we can save” and “what is the most intuitive interface for manipulating the content”. I believe Elementor also generally has a render function (for the front) and a _content_template (for the editor) in its widgets for similar purposes.

    That said, I’d consider the “almost WYSIWYG” problem you outline a bit separate from the edit / save split because it is important that we get closer towards a single way to define how a block should look even if there are differences in the editing and viewing output. A related challenge has been that the editor, so far, doesn’t utilize an iframe to render the content, so a theme supplying styles to blocks needs to be transformed into styles that target only the content and not the surrounding interface. There is some good progress towards consolidating the way a block author or theme can declare styles for blocks so that it works simultaneously in both places (plus native mobile apps!), but it’s work that requires some stepping stones first to do it gracefully and reliably for both block authors and theme authors alike. I’d be curious to see what are the main challenges you have faced as well.

    Reply
    1. Haris Zulfiqar Avatar
      Haris Zulfiqar

      Hi Mattias,

      Thank you for responding, I appreciate it.

      I appreciate the explanation on `edit` and `save` being done separately and I understand that Elementor and other page builders offer the same features but it seems optional. The block editor does give a huge boost to the editing experience of the blocks and `edit` definitely makes sense in that regard. I don’t have the full technical scope of the limitations but from what I can understand, this can still be done on the frontend.

      In my view, editing on the frontend would offer a smoother integration between blocks and themes with requiring a major update from the theme or plugin developer. GB in its current form will require all plugins and themes to update and manually add compatibility for the backend views. I understand that this is necessary to provide a user-friendly experience to the users but in my opinion.

      I’d be happy to share my experience. I have a really good demo of the problem I am experiencing.

      Are you interested?

      Reply
      1. Matías Avatar
        Matías

        Absolutely, would love to check it out 🙂

        Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.